Howdy! I'm a Spring newbie, been reading the official reference documentations as well as learning from the web tutorials for half year but I haven't come to a success point. Now that a project from work is in the need to implement Spring under the following circumstances:
- projects will be deployed in Apache Tomcat (version 7 to be specific), no future plan to migrate to application servers such as GlassFish;
- views will be DOM-based (utilizing org.w3c.dom.*) in plain JSP which produce either XML or transformed XSLT (HTML), hence we don't quite need to incorporate full Spring Web MVC;
- what we need from Spring Framework is the Spring Data JPA support due to all of the above: No application server (just servelt container) but still in the need for JPA.
- Can we eliminate writing @Controller class(es) totally!? Actually, we've tried to achieve this after doing a few researches; we're just not sure if we're on the rite path (see below for current configuration).
- Are we using/configuring everything correctly!? Have we over-configured things we actually don't need and/or have we miss-configured things, please advise!
- The result is either:
org.apache.jasper.JasperException: /index.jsp (line: 1, column: 95) The value for the useBean class attribute tw.com.nani.tsj.entity.EmployeeDAO is invalid. org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:443) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:149) org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1237) org.apache.jasper.compiler.Node$UseBean.accept(Node.java:1182) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428) org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2434) org.apache.jasper.compiler.Node$Root.accept(Node.java:475) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376) org.apache.jasper.compiler.Generator.generate(Generator.java:3503) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250) org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
- JDK: 1.7.0_21 (1.7.0_9 on deployment server)
- Tomcat: 7.0.40 (7.0.33 on deployment server)
- NetBeans IDE: 7.3
- MySQL: MariaDB 5.5.28 (I don't think this is relevant to the questions or issues but, what the heck)
- JPA provider: We first tried EclipseLink due to its community supports on the web, but we didn't have any success so recently switched to OpenJPA 2.2.2!
- pom.xml (New Project... and Add Dependencies...):
Note that there's a few customizations (such as version number of plugins) compared to IDE generated default values.
- /WEB-INF/web.xml (New Standard Deployment Descriptor...):
As explained earlier, we want the views to be handled in plain JSPs, hence the <welcome-file>index.jsp</welcome-file>.
- /WEB-INF/dispatcher-servlet.xml (New Spring XML Configuration File...):
Since we're aware that some schemas are not required by now, we've decided to check them all just to be safe and manually rule out the unused ones when deploying. Another thing to be noted is we prefer annotation-based container configuration.
We favor High Concurrency JDBC Pool as suggested from Improving the performance of the Spring-Petclinic sample application and hope the following PU can benefit from this (we were told that a few JPA providers such as EclipseLink features built-in DBCP but we prefer keeping it container-managed to avoid vendor-specific configuration, if possible).
The account to access database was created:
GRANT ALL ON *.* TO 'username'@'%' IDENTIFIED BY'password'; FLUSH PRIVILEGES;
- /WEB-INF/web.xml (again):
Added <resource-ref/> for JNDI DataSource resource.
Up until this point, a /jdbc.jsp was created to verified the above steps are configured correctly.
- classpath:/META-INF/persistence.xml (New Persistence Unit...):
- New Entity Classes from Database...
- Frankly, we're lazy to write boilerplate code, so we use this great feature (New JPA Controller Classes from Entity Classes...) of the IDE to generate the DAOs for us:
a few modifications required on tw.com.nani.tsj.entity.*JpaController of course:
- Rename tw.com.nani.tsj.entity.*JpaController to tw.com.nani.tsj.entity.*DAO (Refactor > Rename).
- Remove interface Serializable implementation.
- Rename private field emf to entityManagerFactory, following the convention.
- Add @Repository annotation to the DAO classes.
- Add @PersistenceUnit annotation to private field entityManagerFactory.
- Generate Getter and Setter methods (attached source did not have this generated but we actually did this in the real project).
- <resource-ref/> is required when we used to acquired JNDI in plain JDBC before, do we still need it now in order to implement JPA and/or Spring w/ JPA?
- If the PU acquires DataSource from context resource like we did while JTA is in place, do we still have to set defaultAutoCommit="false" in /META-INF/context.xml?
- Is there any dependency we don't need? Suspicious candidates are:
- junit-*.jar Suppose we don't need testing support.