Since JSF managed beans are not part of a bean container, who manage them for example like Spring beans. Also how managed bean achieve the dependency injection with out a bean container?
How JSF would be a better replacement for Spring with out a bean managed container and with other functions Spring provides?
JSF is basically an MVC framework focused in the view layer. When comparing it with Spring, it could be an equivalent to Spring MVC, but never to the whole Spring framework, which has much more functions.
For your question of who manages the dependency injection, the own JSF framework used to do that, for me, as an example, I'm using Tomcat which is just a servlet container, so I use JSF for that work (this means I can only inject other managed beans and not a Service or a DAO).
In other cases, for JavaEE servers as JBoss or Glassfish, the server itself has an embeded container (which acts like the Spring framework) so you could delegate the injection to its CDI implementation.
Finally you tell about JSF being an Spring replacement. As I've said before, this makes no sense. JSF is a part of JavaEE specification and it's being oriented to be used with CDI injections. Spring MVC, being part of the Spring framework, could be the best choice if you manage your application with Spring instead of with a JavaEE container, although you could also use JSF instead of it.
Anyway, remember there's always the discussion of going with Spring or JavaEE. The first one, being a non-standard, offers a faster support and improvement releasing. On the other hand, JavaEE follows the Java specification, with all the benefits of that.
See also:
Spring 3.0 vs Java EE 6.0
Using JSF as view technology of Spring MVC
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.
It's a question about Spring Framework and its architecture. I have read a lot about Spring in the middle-tier or in the layer scheme. But, I need to know which is the role of this framework inside the MVC pattern.
I must clarify I'm not talking about Spring MVC, but about the entire framework.
For example:
View: JSP, JSF, etc...
Controller: Servlets, Spring?, etc...
Model: Spring?, Hibernate, JPA, etc...
I don´t know where can I locate this framework.
If you use Spring Framework (context, core, aop, tx, jdbc) for inversion of control, transactions, aspect oriented programming, JDBC support you definitely use it in M.
If you use Spring MVC for your web controllers you definitely use it in C.
If you use Spring jsp tags, you also use it in your V.
Below url would be helpful to you.
http://www.tutorialspoint.com/spring/spring_overview.htm
It is possible to use Google Guice (any other DI framework) for injecting EJBs in Java EE 5? By default Java EE 5 uses JNDI to injecting EJBs.
I have no direct experience with Guice - but yes, it's possible to use other frameworks for injecting EJBs in a JEE5 application. For instance, Seam does just that. So in principle, it should be possible as there isn't an inherent restriction in the kind of objects that can be injected, as long as the framework takes care of all the lookup details.
UPDATE:
Take a look at this post detailing how to inject EJBs using Guice.
For example, we have the next bunch: Struts, Spring, Hibernate. Can you help me understand the role played by each of the elements?
I know that Hibernate is responsible for all on the database.
But, what role Struts and Spring in this case?
Thanks.
Struts is web application framework - used to give you the possibility to expose your application through web interface without dealing with low level classes. When using struts you should be careful as there often bad advices on using you application logic inside struts classes. Don't do this, struts is just web front-end.
Spring is general application framework that in first place helps you decouple classes from one another using dependency injection. But this is not the only reason for using spring, it provides tons of other features: http security, aspect oriented programming, out-of-the-box integrations and support of different frameworks. So this gives you a fast start on using different technologies.
Hibernate is object relational mapping. Using it you map your classes to database relations and avoid working with SQL requests.
My guess:
Struts is used for presentation purposes. Spring is used for AOP, and Depency Injection. Hibernate is obvious: persistence.
Spring:
Dependancy injection
Transaction Management.
Open Session in View Filters
Spring Security.
or in other words nice clue to between application layers.
Struts:
Model and view Design pattern.
Simplifies web flow.
Struts is for webapplication preparation. It has great form validation f/w, and tiles f/w to create webapplication in a great way.
Spring has 6 modules. It provides abstraction on the java-j2ee application. Spring MVC provides abstraction for struts.
This question already has an answer here:
Difference between Request MVC and Component MVC [closed]
(1 answer)
Closed 6 years ago.
I haved used Struts framework in all my past applications and for the new application,my client has requested to use either Spring MVC or JSF? I am not familiar with these two frameworks but our timelines are strict. So, I am not sure which framework I will choose to build the application.
Can anyone please suggest me which framework will be easy to learn in quick time?
Thanks
Of course, it's going to be different for everyone, but I'd suggest Spring MVC, as it's a request-based framework like Struts. Of course, you'll want to learn about core Spring stuff like Inversion of Control / Dependency Injection (but I'd consider that a plus...) and whatever you're going to use for database access (just JDBC? Hibernate? iBatis? etc.).
JSF is component-based, which is a bit different paradigm from request-based frameworks. If you do plan to go the JSF route, I'd suggest looking at Seam from JBoss. It's more of a front-to-back framework that uses JSF as the web/presentation end and EJB as the backend. And pretty much all the people who've used it claim it makes JSF and EJB more usable than they are by themselves.
Good luck on whichever technology you choose, though. (Sounds like you'll need it - strict timelines and a client that's prescribing web frameworks?)
I'd suggest SpringMVC, because of the timeframe:
you need something with less steep learning curve. SpringMVC is more like Struts than JSF
in order to use the power of JSF you need to get familiar with many "tricks", while SpringMVC is more or less straightforward
I'd suggest JSF + Primefaces component library. I am using this combination to build most of our projects. As I remember, I spent one week to learn the technology and finished my first project in one month. The development time at least 30% faster than Struts.
SpringMVC is not a bad technology and it's quite popular.
Really depends on which one your like the most.
JSF is just the view layer of the MVC and wil need to be used with other technologies like Spring/Hibernate or EJB for a full MVC.
I have been using the Spring MVC for about 1 months now, whilst it's probably not the latyest version of SpringMVC I've found it a little annoying that we have so much XML to deal with. All the managed beans and DAO has XML config to it. Also everything seems to have to go thorugh a method called onSubmit().
JSF with something like EJB is far simplier in my opinion... Everything can be done using Annotations so simply use #ManagedBean=theBean in your backing bean and in your JSF put {thebean.param} and you have access to the backing bean's data. Also you can use the Session beans of your EJB as the backing beans for JSF then have direct acces to the DAO (Model layer) Entity bean. Again simply by using the #Entity annotation and the EntityManager class
Spring MVC is a web framework inside the Spring framework. It does provide features as those in JSF 2.0:
ajax-support
validation
dependency-injection etc
Yet, you can use Spring (not Spring MVC) together with JSF 2.0, with spring providing the dependency-injection, aop, transaction management mechanisms, and JSF providing the web layer.
Of course, you'll want to learn about core Spring stuff like Inversion of Control / Dependency Injection (but I'd consider that a plus...)
JSF is indeed based on IoC, and much simpler than the Spring learning curve.