I've be asked to create a new website and I have to use JSF (Primefaces) and Eclipselink JPA. I haven't created an application from scratch for a couple of years and I've forgotten the best way to structure the application.
Is the following tutorial a go example of setting everything up?
I can't figure out if I need to use Spring. Personally I can't get my head around Spring and don't see how it can benefit my app. If I am wrong, let me know.
I'm also trying to get my head around bean injection. I don't see the point of it. The current website that I've been maintaining doesn't use it. I've personally used it in the past but can't remember it's purpose.
I've searched for these answers but can't find anything.
It's not a good idea to specifically warp your project to fit a specific IDE. IDEs are notoriously subject to change. For my projects, it's a requirement that I be able to do a full build on a machine without any IDE at all, so I typically use Maven. Which, alas, also warps projects, but is less subject to being wrecked by new versions. Eclipse can adapt pretty much any project to be Maven-friendly while still getting the benefits of the IDE.
I'm going to reverse your questions, since it may make more sense that way.
JSF is built using principles of the Inversion of Control (IoC) paradigm. Using IoC, instead of program components going out and looking for other program components (for example, Service Locators), the IoC framework delivers those components to the seeking components. The advantage to this is that you don't have to explicitly code the seeking logic into components. That means that JSF components can often be implemented as POJOs, which makes them more re-usable, easier to test in isolation, and more independent of the internals of the subsystems that they are working with.
JSF itself, however, only provides IoC for Managed Beans. It doesn't really support non-JSF beans. The Spring Framework, however, does, and by means of the appropriate JSF plugin, you can integrate the Spring IoC system and the JSF IoC system seamlessly, thus providing "one-stop-shopping" for bean injection.
My primary use for Spring in most JSF webapps is to manage the ORM. I'm using JPA, and Spring provides services such that the grunt work of managing transactions, handling exceptions and other tedious and repetitive jobs is done by Spring itself. I also leverage it to make systems more testable, though. For example, it's not uncommon for my webapp to create and send emails. By implementing the email service as a Spring-injected component, I can use a dummy mailer for testing and switch to the live mailer for production. Since Spring is handling the wiring-together of my beans, it's a minor change to the Spring config file to do this instead of a Java source code change.
An IDE is no substitute for an Intelligent Developer.
Pretty much if you know Spring JPA, you can easily adapt it to work with JSF. JSF makes no unusual demands of Spring JPA.
Spring itself constructs and injects the EntityManagers into the DAO objects of your ORM layer. I actually maintain 2 separate ORM layers myself (3, if you count the Object Model as a layer).
The DAO layer handles single-table operations. Brute-force mechanics such as "find", "save", "delete". DAO objects have EntityManagers injected into them.
The Service layer handles business-aware operations. These operations typically retrieve and save "working sets" of related objects. I have, for example, a Bus Route webapp where there's a service for editing routes. The Route object contains a collection of Bus Stop objects. They're all fetched and stored as a unit in a single database transaction. My webapps maintain their transactional boundaries at the external methods of the service components.
There are 2 ways to manage transactions and object model attachment in a webapp. It is very common for developers to configure in a component that keeps ORM objects attached for the life of an HTTP request/response cycle. I don't do that myself, however, I do it the other way, which is to make the service objects return detached objects.
The reason I prefer detached objects for the higher levels of the webapp have to do with the fact that if they're detached, I don't have to worry about some apparently-unrelated function at the rendering phase of the request/response cycle accidentally nuking data. Since the data is detached, any damage done won't leak back to the database. Plus, this keeps persistence code - both explicit and implied (lazy-fetch) out of the rendering phase. I pay a price for that, since it means I must precisely determine my working sets instead of simply being able to go grab stuff at will, but I sleep better at night.
Beyond that, there's a simple faces-config.xml option that joins the EL resolver for Spring to the EL resolved for JSF. It looks like this:
With this component wired into JSF, EL references to Spring JPA beans can be made in the same way as EL references to JSF managed objects. So you can use ManagedProperty to inject the ORM services components into the JSF backing beans for their use in persistence.
JPA, Spring and JSF are all fairly complex (and often quirky) systems to learn, but they make industrial-grade webapps a lot easier to create and maintain.
Joined: Jul 04, 2011
Thanks for you help.
I came across the following tutorial which I found gave me a good visual of how everything works.
Tim, been years since I used Spring, never used Hibernate. But given that JEE 6 seems to have stemmed from Spring and Hibernate, does Spring still require all the xml-from-hell configuration stuff? Or is it more annotation friendly like JEE6/7 is for configuring things.. like injecting resources, beans, etc?
You've missed a lot. Spring is definitely well-supplied with annotations these days and wiring JPA resources into JSF is a dream. And not only Spring, since Hibernate JPA is also annotatable without resorting to XML.
My current webapps have very small Spring config files that mostly handle the EntitityManager tie-ins to the webapp's container-supplied DataSources (via JNDI). Everything else is annotated, and often autowired as well.
You can still use XML, and you can use XML to override annotations so that you can re-use or customize components without touching source code, but for general purposes, you can annotate and keep everything simple and in one place.
Joined: Nov 14, 2011
Nice! I figured they must have gone that direction. I am still torn though.. which is better JEE6 (and now 7) or using Spring/Hibernate. Most shops I've interviewed with seem to lean heavily towards Spring and Hibernate, but JEE 6/7 is so nice and at least for me GlassFish 4 is rock solid and easy to work with. Unzip, create a domain, start it, ready to deploy into it with all the JEE services ready to go. I went back to using @ManagedBean because I wanted to make sure my app could run in Tomcat if need be, but then all my @EJB stuff would no longer work, hence why I want to start looking back at Spring/Hibernate to understand them as well so that I can deploy my app in Tomcat (or Jetty) and not need the EJB layer or have to deploy a separate EJB tier into a JBoss or Glassfish container and work with remote calls and such. Seems like Tomcat + Servlet/JSF + Spring/Hibernate offer a pretty solid solution if you don't want the full JEE stack.
"JEE" isn't particularly well-loved these days. Although I think that depends on how you define "JEE". JSF is part of JEE and I like it. I also like JPA, which is a subset of EJB3.
The main difference between Spring JPA and EJB3 is how the entityManager gets injected. In JEE/EJB, the EntityManager is injected directly by the container - which rules out Tomcat. In Spring/JPA, Spring itself handles the injection. So the amount of change required to go from one to the other is fairly slight.
Joined: Jul 04, 2011
I've started creating the business logic and DAO classes in my application.
I'm trying to set up me applicationContext.xml.
I need to set it up so it uses Glassfish connection pooling and connects to a MSSQL 2008 database using Eclipselink JPA.
I can't find an example anywhere of such a configuration. Do you have any examples?
I don't have anything specifically like what you are using, but here's a sample from one of my apps running under Tomcat:
This is for Tomcat, so it's not using EJB-injected entity management. If you need that, the Spring docs should cover it. I've also included some of the support beans that make life more pleasant by automatically scanning and wiring persistence components together.
This probably isn't totally clean - I think the persistence manager is looking in places it doesn't need to, but it has mutated over time and I'm too cowardly to go in and meddle with it when I have bigger problems to address. It works, that's all I can say.
Why does this tutorial not require an applicationContext.xml file?
The last time I did a spring project (2010), you had to specify all the beans in the applicationContext.xml file. This does not seem to be required anymore by using the @AutoWired annotation?
Joined: Jul 04, 2011
See my code below. I've set up a test. All I'm trying to do at the moment is make sure I can retrieve data from the database (I haven't included the interfaces). Can you provide any tips?
I'm using spring 3.1.
There is something wrong with the configuration. I'm getting the following error:
Exception in thread "main" org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class: URL [jar:file:/C:/Workspace/test.jar!/com/mb/AAATestBean.class]; nested exception is java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
My test bean to output the brands in the database: