I am working on a JSF application that was written overseas and it has some performance issues.
Ive been trying to understand why the application might run slow and ive noticed that every backing bean is session scoped, and many beans use other beans, so they are likely all instantiated.
There are maybe 40 backing beans each containing around 4000 lines of code and lots of moving parts.
Can someone confirm or deny my hunch that all this crap in each session is making the application sluggish?
I don't think that this may be the cause of performance issues. Session scoped beans are only created once for a session. So subsequent requests won't create new instances of these beans. But of cause making all beans session scoped is far away from good practice! :-)
Related
I'm a little confused by the mixed use of JSF2+Spring+EJB3 or any combination of those. I know one of the Spring principal characteristics is dependency injection, but with JSF managed beans I can use #ManagedBean and #ManagedProperty anotations and I get dependency injection functionality. With EJB3 I'm even more confused about when to use it along with JSF or if there is even a reason to use it.
So, in what kind of situation would it be a good idea to use Spring+JSF2 or EJB3+JSF2?
Until now I have created just some small web applications using only JSF2 and never needed to use Spring or EJB3. However, I'm seeing in a lot of places that people are working with all this stuff together.
First of all, Spring and EJB(+JTA) are competing technologies and usually not to be used together in the same application. Choose the one or the other. Spring or EJB(+JTA). I won't tell you which to choose, I will only tell you a bit of history and the facts so that you can easier make the decision.
Main problem they're trying to solve is providing a business service layer API with automatic transaction management. Imagine that you need to fire multiple SQL queries to perform a single business task (e.g. placing an order), and one of them failed, then you would of course like that everything is rolled back, so that the DB is kept in the same state as it was before, as if completely nothing happened. If you didn't make use of transactions, then the DB would be left in an invalid state because the first bunch of the queries actually succeeded.
If you're familiar with basic JDBC, then you should know that this can be achieved by turning off autocommit on the connection, then firing those queries in sequence, then performing commit() in the very same try in whose catch (SQLException) a rollback() is performed. This is however quite tedious to implement everytime.
With Spring and EJB(+JTA), a single (stateless) business service method call counts by default transparently as a single full transaction. This way you don't need to worry about transaction management at all. You do not need to manually create EntityManagerFactory, nor explicitly call em.getTransaction().begin() and such as you would do when you're tight-coupling business service logic into a JSF backing bean class and/or are using RESOURCE_LOCAL instead of JTA in JPA. You could for example have just the following EJB class utilizing JPA:
#Stateless
public class OrderService {
#PersistenceContext
private EntityManager em;
#EJB
private ProductService productService;
public void placeOrder(Order newOrder) {
for (Product orderedproduct : newOrder.getProducts()) {
productService.updateQuantity(orderedproduct);
}
em.persist(newOrder);
}
}
If you have a #EJB private OrderService orderService; in your JSF backing bean and invoke the orderService.placeOrder(newOrder); in the action method, then a single full transaction will be performed. If for example one of the updateQuantity() calls or the persist() call failed with an exception, then it will rollback any so far executed updateQuantity() calls, and leave the DB in a clean and crisp state. Of course, you could catch that exception in your JSF backing bean and display a faces message or so.
Noted should be that "Spring" is a quite large framework which not only competes EJB, but also CDI and JPA. Previously, during the dark J2EE ages, when EJB 2.x was extremely terrible to implement (the above EJB 3.x OrderService example would in EJB 2.x require at least 5 times more code and some XML code). Spring offered a much better alternative which required less Java code (but still many XML code). J2EE/EJB2 learned the lessons from Spring and came with Java EE 5 which offers new EJB3 API which is even more slick than Spring and required no XML at all.
Spring also offers IoC/DI (inversion of control; dependency injection) out the box. This was during the J2EE era configured by XML which can go quite overboard. Nowadays Spring also uses annotations, but still some XML is required. Since Java EE 6, after having learned the lessons from Spring, CDI is offered out the box to provide the same DI functionality, but then without any need for XML. With Spring DI #Component/#Autowired and CDI #Named/#Inject you can achieve the same as JSF does with #ManagedBean/#ManagedProperty, but Spring DI and CDI offers many more advantages around it: you can for example write interceptors to pre-process or post-process managed bean creation/destroy or a managed bean method call, you can create custom scopes, producers and consumers, you can inject an instance of narrower scope in an instance of broader scope, etc.
Spring also offers MVC which essentially competes JSF. It makes no sense to mix JSF with Spring MVC. Further Spring also offers Data which is essentially an extra abstraction layer over JPA, further minimizing DAO boilerplate (but which essentially doesn't represent the business service layer as whole).
See also:
What exactly is Java EE?
JSF Controller, Service and DAO
#Stateless beans versus #Stateful beans
There's no real easy answer here as Spring is many things.
On a really high level, Spring competes with Java EE, meaning you would use either one of them as a full stack framework.
On a finer grained level, the Spring IoC container and Spring Beans compete with the combination of CDI & EJB in Java EE.
As for the web layer, Spring MVC competes with JSF. Some Spring xyzTemplate competes with the JPA interfaces (both can use eg Hibernate as the implementation of those).
It's possible to mix and match; eg use CDI & EJB beans with Spring MVC, OR use Spring Beans with JSF.
You will normally not use 2 directly competing techs together. Spring beans + CDI + EJB in the same app, or Spring MVC + JSF is silly.
This question probably does not fit SO rules, but I'll ask it anyway. Answers might help other people struggling with JSF.
We are using JSF (MyFaces, PrettyFaces, PrimeFaces and Spring) on one of our biggest project for two years now (migrated from Tapestry 3). I can say that we are "recovering" from this migration to this day.
In my opinion one of our major mistakes was misunderstanding of JSF's VIEW SCOPE. JSF offers two basic mechanisms how you can persist VIEW STATE - CLIENT and SERVER. We went for the SERVER method, which was our first mistake as ViewExpiredException never stopped coming from that moment on. The next mistake was to store data on VIEW SCOPE as that prevented us from easily switching to CLIENT state saving method.
So I was thinking whether there are some best practices and guidelines on what should and shouldn't be stored on VIEW SCOPE (and thus serialized into VIEW STATE). Official documentation and specification does not provide that. But I came to a quite nice conclusion:
You should only store on VIEW SCOPE such information that you would normally (without JSF) pass as request parameters.
When you have a basic CRUD application without JSF, you would do this:
state of the form is preserved between requests by form values in POST parameters
state of the list (filtering, sorting, paging) is preserved between requests by query parameters
Is my conclusion correct? Do you have any other guidelines on what to store and what to never store inside VIEW SCOPE? Do any component frameworks have such guidelines?
i use the following Guidelines:
avoid VIEW SCOPE as it is only available for Faces Manages Beans.
better: avoid the usage of Faces Managed Backing Beans. use CDI Managed Backing Beans to ensure portability. (sure, this is only possible if you have any cdi container available... in Java EE 6 and newer...)
avoid AJAX with JSF. (or only use it with caution for simple UIs...)
Is there a difference using a singleton class and an application scoped managed bean to hold application data?
I need to lookup certain JNDI ressources such as remote bean interfaces and therefore I wrote myself a singleton to cache my references and only allow single references. (ServiceLocator)
I opened my website in two different browsers and that singleton got only initialized once. So I assume its application scope?
Any other benefits of a application scope managed bean then being able to access its properties in jsf?
Singletons are not unit testable nor abstractable nor extendable. Singletons are also unnecessarily complex to reliably create and maintain if your sole purpose is to have application scoped data (at least, if you really want a fullworthy singleton for it for some reason -most starters don't even exactly understand what a singleton is supposed to be).
"Just create one" like an application scoped managed bean is much simpler to develop, test and maintain. JSF as framework will guarantee that only one instance will be created and reused during web application's lifetime.
See also:
Singleton vs Just Create one
How to choose the right bean scope?
I've been developing my first Java EE app, which has a number of JPA entity classes, each of which have a corresponding EJB class for dealing with the business logic. What I've done is changed one of those beans from Stateless to SessionScoped, so I can use it to allow a user to work their way through a series of form fields, all of which are rendered on a JSF form.
However, I'm starting to think this is clearly wrong, as I'm doing things like implementing methods such as "submitStep1" and "goBackToStep2" in my EJB. These methods set indicators which are used by render elements of various tags on the JSF page, so they are clearly "presentation logic".
My question is, how should I re-structure my code? I'm thinking that I should just have one SessionScoped (or should that be stateful?) bean, which deals with the presentation logic of my JSF page, and is able to use all the other ejbs (and by extension my JPA classes). This bean would be in the presentation-tier level of my app, meaning my business logic tier wouldn't need any Session Scoped Session Beans.
Now this all makes sense to me, and is what I am probably going to do. However the reason for my question is that on my JSF xhtml pages I use JSF EL tags a lot to refer to EJB content. Are there any JPA-related pitfalls I need to watch out for when writing presentation tier classes?
I know my question is pretty vague, and not really related to a specific example. And although I've found quite a lot out about Stateful v Stateless beans on this and other sites I just want to know my intended structure is the best one.
Why don't you use backing beans for presentation purpose, as they are intended for it, and you can easyly configure its scope, and leave the EJBs to business tier?
When using entities directly on the presentation tier, you should be aware of the transaction scope, specially regarding lazy relationships. That is, normally it is used one transaction per request, what will mean that amongst different requests, the entities will become detached, so you will need to reatach them to be able to load lazy relationships. You could use a filter that does it automatically each request or handle it by hand. You could also keep the same transaction during different requests but a long transaction is normally not a good idea, specially if there are updates/creations in the DB during this transacion.
Has anyone had success building a SEAM Application without using Stateful session beans? There is some confusion on a new project in which I think several stakeholders have essentially 'banned' stateful session beans... but some development is being done in SEAM.
Most of the literature on SEAM encourages the use of Stateful Session Beans. Thoughts?
You can absolutely use Seam without stateful session beans. You don't need any type of EJB at all, if you don't want them. Seam can be deployed on a variety of app servers, including Tomcat which doesn't support the use of EJBs. Seam has the ability to mimic a lot of the functionality that EJBs provide -- session scope, transactions, etc. -- without actually using an EJB.
Using Seam with Tomcat, for example, you can have a very robust application without EJBs that is lightweight, but acts in a manner similar to an application deployed on JBoss or Websphere that does make use of EJBs.