We Keep Coding

EJB injections vs only JSF managed beans

I don't know may be my question is completely meaningless, but I can't find any straight information about it.
I had my JSF + Tomcat application and it worked just fine. I want to implement Restful services and JAAS logic. In order to do that, I switched to TomEE++.
Switching to TomEE means that my server will now be more heavy and I'm afraid than it will require more cpu and ram resources than I have in my Amazon AWS micro instance.
The question is: Will the performance drop down if I switch from only JSF managed beans to JSF + EJB?
The sub-question is: what EJB injections can do, and JSF managed beans can not do? (JSF does not allow cyclic injections for example)

Will the performance drop down if I switch from only JSF managed beans to JSF + EJB?
Measuring is knowing. But generally, this concern makes no sense.
what EJB injections can do, and JSF managed beans can not do? (JSF does not allow cyclic injections for example)
Generally, they are not intented to be interchangeable. Each have their own clear responsibility. You use JSF bean management annotations to manage beans for front-end (JSF pages). You use EJB bean management annotations to manage beans for business services (BOs/DAOs). That's it.
To learn how JSF+EJB(+JPA) are supposed to work together head to the concrete examples and explanations shown in the following answers:
JSF Service Layer
JSF managed-bean EJB injection
Filter do not initialize EntityManager
JSF request scoped bean keeps recreating new Stateful session beans on every request?

CDI and EJB, security issues?

I am reviewing my code from since I picked up on JSF.
One of the most complex issues has come up once again. The decision between CDI and EJB.
I am using three layers and I wonder which type of annotation to use on each of them:
- Backing beans (the Controller as defined in MVC)
- The service layer
- DAO's
My backing beans are using CDI, as long as I don't need anything from EJB.
But I am stuck on those other two. I remember reading about using EJB beans because of the pooling functionalities, which would prevent massive loads of requests (or attacks, if you will).
So in short, is there ANY reason to use EJB (Stateless, Stateful, LocalBean et cetera), considering security or anything else (excluded ViewScoped)?
Thanks in advance.

You're making a conceptual mistake here. CDI is absolutely not an alternative to EJB. CDI in its default trim doesn't offer transaction management at all. CDI is a bean management and dependency injection API, not a service layer API. In order to manage transactions in CDI, you've to add another API along with a bunch of another annotations.
CDI can replace for example JSF managed bean annotations, but definitely not EJB annotations.
So there's no means of a valid "CDI vs EJB" question. Both have their own completely distinct purposes. Note that you can perfectly inject EJB based service classes in CDI based managed bean classes.
As to security, it's not clear why you mentioned that part in the title and the tags, but the decision between CDI and EJB has nothing to do with security (simply because there's no means of a valid "CDI vs EJB" question in first place).

Yes when you require out-of-box support for transactions, concurrency, pooling etc.

Adding rest service to a struts application

I'm trying to add rest services to a struts application using jersey.For this i need to segregate the java code in such a way that it can be commonly accessed by both the struts and rest api.This is done so that the code is shared between both rest and struts,and any change will reflect in both the services.I would like to know , how much of this idea is feasible and weather this is how usually people design rest services .

While our presentation layer isn't Struts based (usually it's either Spring Web MVC or JSF), we use Spring 3.0 + Java EE 6, specifically, EJB 3.0 and JPA 2.0 for such situations.
EJB 3.0 stateless session beans work great—they can have declarative (annotation-based) dependency injection and transaction demarcation, or they can manage their transactions, dependencies and resources themselves using whatever traditional mechanism. They seamless integrate with JPA 2.0 and are easy enough to unit test. The main advantage over pure Spring beans is that they can be deployed independently of the Web application (as an EJB JAR).
On the front-facing Web services, we also use Jersey/JAX-RS. Because Jersey/JAX-RS dependency injection is broken (it doesn't use Weld/CDI like the rest of Java EE), we've had to resort to Spring DI to 'wire' up the front-facing REST resource classes with the 'back-end' EJBs. The good thing is this works well enough to inject the EJBs into our MVC controllers and can also be used with JSF managed beans. Alternatively, you can write your REST-ful resources using Spring alone (either way has its own pros/cons, but in general both do the job well).
I know I glossed over the whole thing but I'd be glad to share more details upon request.
EDIT: Some more details, as per request.
You're first stop for learning Jersey/JAX-RS would have to be the Jersey User Guide. There are also several tutorials/examples you can easily find across the 'Net.
While you should be able to package Jersey/JAX-RS resources into the same WAR as your Struts pages, we went with the simpler alternative of deploying them separately.
Now, when deploying to Glassfish 3.1, we hit this bug, also documented here. The bottom line is that #EJB injection didn't work for us as expected.
So, instead, we fell back on to Spring using the jersey-spring contrib module, following this example.
Anyway, the rest of it is standard Java EE 6 / EJB 3.0. We identify and place all common functionality into a 'service' layer which are largely implemented as #Stateless EJBs.
Persistence is handled through JPA #Entitys accessed through a JPA inject EntityManager. Transactions are declaratively demarcated using #TransactionAttribute.
Here's a quick illustration of a typical EJB + JPA service bean:
#Stateless
public class WidgetServiceBean implements WidgetService {
#PersistenceContext
private EntityManager em;
#Override
public List<Widget> findWidgetByName(String name) {
return em.createNamedQuery("Widget.findByName", Widget.class)
.setParam("name", name).getResultList();
}
#Override
#TransactionAttribute(TransactionAttributeType.REQUIRED)
public void removeWidgetById(int id) {
em.find(Widget.class, id).remove();
}
}
(Obviously not production quality but just shows how 'lean' they can be.)
The service layer and entities are packaged as an EJB JAR which can be deployed separately, and made available to all other modules via global JNDI lookup. Or, they can be deployed within the Struts or JAX-RS WAR and as of Java EE 6 (Glassfish 3.x) they will be found, deployed as part of the module and made available to other components within the same WAR.
Some might argue that it's simpler to just use Spring beans if you're using the Spring container anyway. I would say, probably, but then you also have to use Spring's persistence framework, and Spring's transaction framework. (Spring also provides declarative transactions and persistence.) If you're already heavily invested into Spring then that might be an easier path.
OTOH, EJB 3.0, JPA 2.0 and JTA have also been radically simplified from their predecessors and are part of the Java EE standard so it's an architectural decision with a lot of dimensions.

sharing spring aspect class between two webapplications

I have application consisting two web apps and EAR level jar files.
One web app (Lets say SPApp) is built using Spring and another using Struts (STApp).
I want to share the Aspect class SystemArchitecture of SPApp as defined here spring aop
6.2.3.3. Sharing common pointcut definitions
in STApp.
I have added SystemArchitecture class in EAR level jar file and gets invoked from SPApp but doesn't execute when STApp is accessed.
So then I moved the aspect class SystemArchitecture inside STApp and surprisingly it worked.
I am not sure what is going wrong when I place SystemArchitecture in EAR level lib.
Please help.
Thanks,
Hanumant

Spring AOP will not work outside spring. The Spring implementation of AOP is based on dynamic proxying where the spring bean factory will proxy advised classes to inject your pointcuts. What you are after is what's called "load time weaving" in where a java agent is used to intercept the ClassLoader and decorate advised classes when they are loaded. This is an AspectJ functionality, not a Spring AOP. Read more here: http://www.eclipse.org/aspectj/doc/released/devguide/ltw.html
Spring and AspectJ can play together as well, but it's limited to spring driven applications: http://static.springsource.org/spring/docs/3.0.0.RC2/spring-framework-reference/html/ch07s08.html
Still, if you want "true" AOP, independant of Spring then you need to go load-time weaving and AspectJ.
EDIT: may have misread your question. You say it works in your struts app only when you put your advise class in the app itself. From that I read that your Struts app is Spring driven as well. It's hard to give an answer without knowing your config. Specifically, web.xml (both), application.xml and your spring configs.

Using pure servlets (Java Servlet, no framework) in a project using the Spring framework?

We've got some Pure Servlets (pure Java classes following the Servlet API, no framework) that we'd like to include in a project that relies heavily on the Spring Framework.
What's the best way of including these servlets in the project, when all the new code we're writing is making heavy use of Spring 3 features?

your servlet container can run multiple servlets, spring is just one of them. why not just include your servlets in the web.xml and see if it works? it should work. spring is not that intrusive, yet (but obviously it already intruded the minds of many developers)

If you declare servlets in the web.xml, alongside the Spring front controller, it most certainly will work.
You just have to be careful when you declare which URLs map to the servlets. If you send "/*" to the Spring front controller, none of your requests will reach your other servlets. Be specific about what you need to send to each one.

As you might know, servlets cannot be configured as Spring beans. If your question is about colloborating with spring beans from a servlet, do refer this thread and also this

Spring provides a couple of classes to make this bridging easier.
ServletForwardingController
Spring Controller implementation that
forwards to a named servlet, i.e. the
"servlet-name" in web.xml rather than
a URL path mapping. A target servlet
doesn't even need a "servlet-mapping"
in web.xml in the first place: A
"servlet" declaration is sufficient.
Useful to invoke an existing servlet
via Spring's dispatching
infrastructure, for example to apply
Spring HandlerInterceptors to its
requests.
ServletWrappingController
Spring Controller implementation that
wraps a servlet instance which it
manages internally. Such a wrapped
servlet is not known outside of this
controller; its entire lifecycle is
covered here (in contrast to
ServletForwardingController).