The following technical details and design issues are random observations about the JPA API and Java in general. I try to verify through experimentation every fact that appears here - but use this list at your own risk.
DI1: An EntityManager instance is not thread safe @ThreadSafe by design - however a container managed entityManager that is transactional (with default EE PersistenceContextType.TRANSACTION and default EE scoped transaction-type="JTA") is thread safe because you deal directly with a proxy wrapper provided by the enterprise container ($ProxyNN). The container is able to manage simultaneous access to the referenced EntityManager as well as provide services via bytecode instrumentation/weaving like change tracking, security, resource management and transactions. Therefore I recommend a container managed entityManager where possible.
DISCLAIMER: This page reflects investigation into how ORM/JPA developers can use the Java Persistence API (part of Java EE 5/6) and the Spring Framework inside existing WebLogic and Spring releases. It does NOT imply any formal certification from SpringSource, IBM, RedHat or Oracle on any technical details or configuration within this document.
This content is undergoing an expansion as of 20101220 in enhancement # 332953from an EE enthusiast.
Purpose
A portion of enterprise development uses the Spring framework which is an alternative to traditional JEE/EJB distributed transactions(1.0), local transactions (2.0) and transactional SE frameworks (3.0). Spring has grown into as large a framework as JEE6 from its original goal of providing a simpler less verbose enterprise MVC framework. The spring framework can be used in conjunction with or as a replacement for EJB 3.1 technologies.
This document is for Spring developers that wish to use EclipseLink JPA as their persistence provider or for Spring developers that are migrating from another ORM/JPA provider.
An open source persistence provider framework can be the JPA or ORM provider for Spring beans in Spring based applications.
The API provided by the Spring framework can range from using the dependency injection (DI) features along with the Aspect Oriented Programming (AOP) support - all the way to using declarative transactions and management of remote resources.
In this tutorial page we will concentrate on providing support for developers and projects that wish to use JPA with Spring applications and we will demonstrate a very simple web application that uses a JTA or local RESOURCE_LOCAL persistence unit and use Spring's @Autowired, @Controller, @RequestMapping, @Repository and possibly the '''AOP''' @Aspect and @Around annotations as required.
JPA Enterprise Application running on Spring inside WebLogic Server
As most enterprise applications that use Spring will do so via a web application - instead of a Web/EJB EE combination - we will concentrate on Web (WAR) applications.
WebLogic offers the following services to Spring applications
Runs Spring 2.5.3 applications out of the box
Provides a simplified deployment model surrounding the Application Context - we will also use this.
Provides Spring DI and AOP support to non-Spring applications
Provides spring MBeans for runtime configuration details - We will verify this shortly
The primary use case we will prototype for this tutorial is one where the application uses Spring (either managing its' own local transactions, or using the transaction manager in WebLogic for distributed transactions) as the enterprise container on WebLogic Server. WebLogic currently support Spring 2.5.3 and Dependency Injection using Spring in non-Spring applications via the open source Pitchfork project.
Therefore theoretically we should be able to use Spring AOP and other DI annotations in our application without any extra configuration - we will verify this.
A secondary use case will be migration of a SpringSource Tool Suite 2.5.0.M3 (based on Eclipse 3.6 and Apache Tomcat 6.0.20) based native Hibernate project to one that uses EclipseLink JPA.
JEE and Spring correspondence
Spring can be used in parallel with formal EE specification technologies like IIOP Remote Session Beans and Transactions or as an alternative to them using Spring's remote RMI/JAX-RPC/WS proxying and declarative transactions/rollback support.
However, Spring does not provide native distributed transaction support or native ORM support - in both these cases JEE must be used.
Distributed transactions via transactions that occur across remote session bean methods
ORM persistence is provided via JPA using either http://www.eclipselink.org or www.hibernate.org as the provider - or via native ORM for either of these persistence providers.
Using the Spring framework as the EE container allows the user to run enterprise applications on simple JSR-154 Servlet containers like Tomcat, Jetty, WebSphere CE, Spring TC or Spring DM/Virgo
The spring framework treats all EE artificts as Spring Beans.
Architecture
There are 3 standard tiers to our web application.
presentation/view layer (JSP/JSF pages)
controller layer (Controller Servlet)
integration/data-access layer (Spring beans)
The cross-cutting concerns are
The data model (Entities)
Logging
Transaction Management (Spring beans)
We will be using standard JPA Entities for our data model domain objects.
The domain objects will be managed by Spring beans that act as Data Access Objects between our Entities and the persistence store
Installation
WebLogic 10.3.4.0
Oracle WebLogic http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html officially supports Spring 2.5.x - we will be verifying this July 2008 statement in the http://www.oracle.com/technetwork/middleware/ias/downloads/oracle-wls-certification-10gr3-matr-129284.xls System Requirements and Supported Platforms for Oracle WebLogic Server 10.3 spreadsheet - page 2.
In WebLogic 10.3.3.0 there exists 3 spring jars in the modules directory - these are internally wrapped API that support the 2.5.3 version of Spring as indicated. We may upgrade these to work with Spring 3 as long as we do not encounter issues between 2.5.3 and 3.0 dependency injection. The http://www.springsource.com/products/pitchfork/pitchfork-faq pitchfork jar is part of the combined Oracle and SpringSource open source project for metadata translation of http://www.jcp.org/en/jsr/detail?id=250 JSR-250 annotations for both WebLogic ans Spring - started by Rod Johnson of Interface21 and Michael Chen of BEA under both the Apache and EPL licenses.
WebLogic has used Spring as its AOP (Aspect Oriented Programming) engine since June 2005 to provide support for DI (Dependency Injection) of resources and functionality in a Proxy' implementation on the server that contains a reference to the actual business object (Bean or EJB). The container uses Spring AOP to bytecode weave - at runtime - the proxy so that cross-cutting concerns can be architected properly. By instrumenting a business object at runtime using http://en.wikipedia.org/wiki/Aspect-oriented_programming AOP we are able to provide dynamic functionality before and after a client operation in support of pre and post operations for transactions and security for example. http://oss.oracle.com/projects/pitchfork/ com.bea.core.repackaged.springframework.pitchfork_1.3.0.0_2-0.jar
com.bea.core.repackaged.springframework.spring_1.1.0.0_2-5-3.jar com.bea.core.weblogic.spring.instrument_1.2.0.0.jar
The notable thing about using the '''com.bea.core''' namespace is that it will not confict with any com.springsource Spring versions shipped with Spring EAR applications.
From what I can see there is a bit of history on Spring and WebLogic cooperation
The wlserver_10.3/server/lib/weblogic-spring.jar contains WebLogic specific integration with the above 3 spring jars
The wlserver_10.3/server/lib/console-ext/spring-console.jar contains WebLogic specific http://download.oracle.com/docs/cd/E12839_01/web.1111/e14453/enable_console_ext.htm#CIHCAIBE integration with the WebLogic admin console
WebLogic 10.3.3.0 Default Spring Support
If you try to deploy a Spring framework based application - you will see the following CNFE (ClassNotFoundException) or similar depending on what Spring JSR-250 annotations or XML markup you use.
_21-Dec-2010 3:52:51 o'clock PM EST_ _Error_ _HTTP_ _BEA-101371_ _There was a failure when processing annotations for application F:\wse\view_w35e\org.eclipse.persistence.example.jpa.spring.weblogic.enterpriseWeb\WebContent. Please make sure that the annotations are valid. The error is org.springframework.web.servlet.DispatcherServlet_
_21-Dec-2010 3:52:51 o'clock PM EST_ _Error_ _Deployer_ _BEA-149265_ _Failure occurred in the execution of deployment request with ID '1292964771051' for task '1'. Error is: 'weblogic.application.ModuleException: Failed to load webapp: 'springhypercube''
weblogic.application.ModuleException: Failed to load webapp: 'springhypercube'
at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:393)
at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:517)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:297)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:270)
at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:64)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
In my case, this is because of the standard Spring DispatchServlet which replaces your own FrontController, FacesServlet or StrutsController - single point of control in web.xml FrontController org.springframework.web.servlet.DispatcherServlet contextConfigLocation/WEB-INF/servlet-config.xml
The reason that the '''org.springframework.web.servlet.DispatcherServlet''' class cannot be loaded by WebLogic is either that it is unavailable or that there is another version in the classpath (not likely or we would get a ClassCastException).
The DispatcherServlet is inside org.springframework.web.servlet-3.0.5.RELEASE.jar
You therefore need to distribute the Spring jars or place them on the server as explained in the section
Systematic Inclusion of Spring libraries in WebLogic
The goal is to get the latest Spring 3.0.5 working with the latest WebLogic 10.3.4.0. Hopefully we do not need to revert to using the supported Spring 3.5.3 or 3.5.6 versions.
The following ClassNotFoundExceptions are being eradicated one at a time usually be easily matching the class with the appropriate 1 of 20 Spring module. It would be nice to use some sort of OSGI support for dynamic module loading - we are only using PDE at this point.
org.springframework.web.servlet.DispatcherServlet is in org.springframework.web.servlet-3.0.5.RELEASE.jar
org.apache.commons.logging.Log is in commons-logging.jar
org.springframework.web.util.UrlPathHelper is in org.springframework.web-3.0.5.RELEASE.jar
org.springframework.context.ApplicationContext is in org.springframework.context-3.0.5.RELEASE.jar
org.springframework.beans.factory.ListableBeanFactory is in org.springframework.beans-3.0.5.RELEASE.jar
org.springframework.core.io.support.ResourcePatternResolver is in org.springframework.core-3.0.5.RELEASE.jar
Alright, we are now deployed and at the point where we are looking for the persistence unit - which is not properly configured yet.
Caused By: java.lang.IllegalArgumentException: No persistence unit named 'spring' is available in scope springhypercube. Available persistence units: []
at weblogic.deployment.ModulePersistenceUnitRegistry.getPersistenceUnit(ModulePersistenceUnitRegistry.java:132)
at weblogic.deployment.BasePersistenceContextProxyImpl.(BasePersistenceContextProxyImpl.java:39)
We are currently running on a modified server (so we do not have to ship the Spring modules with the EAR/WAR) with the following change to $WLS_Server/wlserver_10.3/common/bin/commEnv.cml:151
set SPRING_CP=C:/opt/spring305/dist
set WEBLOGIC_CLASSPATH=%SPRING_CP%/org.springframework.web.servlet-3.0.5.RELEASE.jar;C:/opt/spring3/commons-logging.jar;%SPRING_CP%/org.springframework.web-3.0.5.RELEASE.jar;%SPRING_CP%/org.springframework.context-3.0.5.RELEASE.jar;%SPRING_CP%/org.springframework.beans-3.0.5.RELEASE.jar;%SPRING_CP%/org.springframework.core-3.0.5.RELEASE.jar;%JAVA_HOME%\lib\tools.jar;%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;%FEATURES_DIR%\weblogic.server.modules_10.3.4.0.jar;%WL_HOME%\server\lib\webservices.jar;%ANT_HOME%/lib/ant-all.jar;%ANT_CONTRIB%/lib/ant-contrib.jar
2) And manually enter the jars below...
Instead of picking individual jars - just add everything from the dist directory to your in-Web lib directory, or directly on the server on either your domain lib or the modules dir of the server.
\user_projects\domains\base_domain\lib
\modules
There are several options for getting the Spring framework enabled for your Spring WAR in WebLogic Server. I have ordered them in decreasing impact on the WebLogic server config and increasing application managed state.
Option 1: Spring library jars highest in WEBLOGIC_CLASSPATH var in commEnv.cmd script - in use
This option will override anything on the server and deployed WAR's (except prefer-application-packages overrides). It will deal with most classLoader and CNFE issues. Later we may want to refactor how the Spring modules are packaged to minimize server impact.
Option 2: Spring library jars in WebLogic modules directory
Option 3: Spring library jars in WebLogic Domain lib directory
Option 4: Spring library jars in shared separate EAR library
Option 5: Spring library jars deployed with EAR APP-INF/lib directory using '''prefer-application-packages''' override
Option 6: Spring library jars deployed with WAR lib directory
Eclipse 3.6 Setup Standard Eclipse 3.6 EE
Spring must be configured as follows. SpringSource Tools Suite 2.5.1
Spring will run out of the box on Apache Tomcat 6.0.20 JNDI Datasource Setup EclipseLink JAR Spring JARs
Create Enterprise Projects
*Possible configurations of the projects are...
*Using the default http://download.oracle.com/docs/cd/E12839_01/web.1111/e14453/simplified_configuration.htm#BABBJEDI WebLogicJtaTransactionManager
SC1: WAR only project with entities/beans inside war jar.
SC2: WAR only project with entities/beans inside separate domain jar.
SC3: EE EAR project with entities/beans inside the war project
SC4: EE EAR project with entities/beans inside separate ejb.jar project
SC5: EE EAR project with entities/beans inside separate domain jar project
Object Model
Following Scenario SC3 we will place our entities inside Dependency Injection
@Controller
@Autowired
@RequestMapping
@Repository
@Transactional
Declarative transaction management - like http://www.jcp.org/en/jsr/detail?id=220 JSR-220 / http://www.jcp.org/en/jsr/detail?id=318 JSR-318 EJB 3.0/3.1 transactional stateless and stateful session bean annotations via the javax.ecj.SessionSychronization package updated for non-remote calls (2.0) and non-EE (SE) clients in (3.0)
Web.xml
The version of the xmlns:web namespace must be 2.5 not 2.4
Add a persistence-ref for this application managed persistence unit persistence/em spring
org.eclipse.persistence.jpa.PersistenceProvider
The SPI file javax.persistence.spi.PersistenceProvider containing the text org.eclipse.persistence.jpa.PersistenceProvider must be placed at the root of where the entities/beans are off of META-INF/services
Persistence.xml servlet-config.xml application-config.xml
If you were using a Hibernate SessionFactory for ORM you could describe your entities in the AnnotationSessionFactoryBean bean element to match the class elements from persistence.xml - if auto-discovery was not enabled
Transaction Manager Configuration
If we use the default WebLogicJtaTransactionManager we get the following Spring beans by default when the application context is wrapped in a parent proxy by WebLogic
ref="transactionManager" - a subclass of org.springframework.transaction.jta.jtaTransactionManager Configuration MBeans
On WebLogic Server we get the following Spring beans by default when the application context is wrapped in a parent proxy.
Both of these MBeans should be running off the platform MBeanServer - I will need to verif this.
ref="editMBeanServerConnection"
ref="runtimeMBeanServerConnection"
Servlet Client Start Server Publish EAR Console Output Browser Output
Change Log
20101220 - start tutorial using Spring 3, SpringSource Tool Suite 2.5.0, AspectJ 1.6 weaver at 3019.
This UML Class diagram describes a portion of the EclipseLink 2.0 API both internal and external classes and interfaces and more specifically the JPA 2.0 Metamodel API
This UML Sequence diagram illustrates the core of batch writing in EclipseLink
WebLogic Console and JPA Persistence Providers:
WebLogic ships with support for JPA providers such as EclipseLink and Kodo. In order to use EclipseLink you will either want to set the <provider> to org.eclipse.persistence.jpa.PersistenceProvider or enable EclipseLink as the default JPA provider for your WebLogic domain.
Once your EE application is deployed, you may view which persistence units are available either as container managed persistence units via the EJB container or application managed units via the Web container.
Extended properties such as the container defined JTA data source here can be verified here as well.
GlassFish JPA Deployment:
Issues:
EJB module ordering in the application.xml deployment descriptor of your EE EAR is significant in GlassFish - See EclipseLink bug 323148 and comment # 9 of EclipseLink bug 293191. This issue is that weaving/bytecode-instrumentation will not have been run yet on the persistence unit in an EJB module if the WAR module that uses/injects a session bean (itself injected with a persistence context) is processed first. This EAR module order in the order of use looks to only be an issue with JSF applications.
Debugging JPA container managed transactional applications in WebLogic Server from Eclipse
If you are regularly debugging client EE or server code running on WebLogic server from an IDE like Eclipse Galileo - you will need to increase the default transaction timeout from 30 seconds to something like 300n seconds.
Otherwise you will see a transaction timout exception like the following - for example during a standard entityManager persist on a stateless session bean that uses a transactional @PersistenceContext injection of the persistence unit.
Stacktrace:
javax.ejb.EJBException: Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 34 seconds
at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1733)
at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1578)
at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1900)
at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:1488)
at weblogic.transaction.internal.WLSTimer.timerExpired(WLSTimer.java:35)
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
nested exception is: weblogic.transaction.internal.TimedOutException: Transaction timed out after 34 seconds
at weblogic.ejb.container.internal.EJBRuntimeUtils.throwEJBException(EJBRuntimeUtils.java:148)
at weblogic.ejb.container.internal.BaseLocalObject.postInvoke1(BaseLocalObject.java:567)
at weblogic.ejb.container.internal.BaseLocalObject.__WL_postInvokeTxRetry(BaseLocalObject.java:427)
at org.eclipse.persistence.example.jpa.server.business.ApplicationService_5ptwty_ApplicationServiceLocalImpl.query(ApplicationService_5ptwty_ApplicationServiceLocalImpl.java:193)
at org.eclipse.persistence.example.jpa.server.weblogic.enterprise.presentation.FrontController.processGliderCommand(FrontController.java:293)
The following WebLogic console page is used to increase the transaction timeout : Domain|Configuration|JTA
Tomcat Deployment:
Even though Tomcat is only a web container and does not supply a transactional EJB container - we can still deploy JPA applications using application managed sessions.
64 Bit Tomcat: Since tomcat is almost entirely a java application and therefore uses 32/64 bit agnostic bytecode we can run either version on 64 bit operating systems. The only difference between the 32 and 64 bit versions of tomcat is for the non-java based windows services executable and dll (tcnative-1.dll and tomcat7.exe). If you run tomcat from the command line then both versions are the same.
Customization:
Referencing Remote Persistence Archives:
Normally the persistence classes (Entities, MappedSuperclasses, Embeddables and Transient classes) are either part of the module containing the persistence.xml descriptor or in a separate jar that is packaged with the application (whether standalone SE or server based EE).
1) Separate Entity jar
For example, in the client SE jar we define persistence.xml in the location /src/META-INF/persistence.xml and reference entities that can be shared between modules.
2) And manually enter the jars below...
