Thanks, Jim!
We asked another user the same time we asked you and they also
reported no luck in getting EclipseLink to work deployed under the WEB-
INF/lib.
This sounds like something a lot of people would waste a lot of time
on. At minimum we can add an EclipseLink page to our documentation
and mention this restriction.
Looking at the EclipseLink doc it seems they have a restriction about
splitting the eclipselink jar from the jar that contains the
javax.persistence libraries. Since we have that library in our javaee-
api jar which effectively gets added to Tomcat/lib that explains why
EclipseLink doesn't work in the WEB-INF/lib/ directory.
http://wiki.eclipse.org/EclipseLink/Examples/JPA/Tomcat_Web_Tutorial#EclipseLink_JAR_location
The doc doesn't explain *why* EclipseLink has such a strange
limitation. I've not heard of any other JPA provider with the same
limitation.
If you get around to asking them, definitely post a link to the
thread. My curiosity is definitely peaked.
-David
On Aug 30, 2009, at 1:30 PM, JimOR wrote:
David,
Apologies for the late follow-up, not sure how I missed your second
reply
from the 17th...
David Blevins wrote:
Hey Jim,
Wonder if this might be your situation too:
http://www.nabble.com/rg.apache.openejb.OpenEJBException%3A-Unable-to-determine-the-module-type-of-tp24921373p25013439.html
See my followup and mod the "EMFProvider" class you have and have it
do the getResources() check I mention there.
That may help us narrow down your issue.
My getResources() call shows a single jar. But I played around with
various
combinations of deploying EclipseLink under WEB-INF/lib and under
Tomcat/endorsed.
The only 'clean' initialization was with the Eclipselink API and
Impl jars
at Tomcat's level.
I put clean in quotes because there seems to be a Log4j classloading
issue.
(I have 1.2.15 deployed to Tomcat, openejb webapp lib has 1.2.12) I
seem to
recall a Tomcat classloader configuration adjustment that might
address
this, and everybody(webapp, Eclipselink, OpenEJB) happily logs, but
here's
what got spit out:
[2009-08-30 12:54:00.812] INFO-
org.apache.openejb.util.Log4jLogStream.info(Line:70) - Assembling app:
C:\EclipseGalileoBase\.metadata\.plugins\org.eclipse.wst.server.core
\tmp0\wtpwebapps\sample
[2009-08-30 12:54:00.828] INFO-
org.apache.openejb.util.Log4jLogStream.info(Line:70) -
PersistenceUnit(name=sample,
provider=org.eclipse.persistence.jpa.PersistenceProvider)
log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
assignable to a "org.apache.log4j.spi.Configurator" variable.
log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded
by
log4j:ERROR [org.apache.openejb.core.tempclassloa...@11498ba]
whereas object
of type
log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
[null].
log4j:ERROR Could not instantiate configurator
[org.apache.log4j.xml.DOMConfigurator].
[2009-08-30 12:54:01.484] INFO-
org.apache.openejb.util.Log4jLogStream.info(Line:70) - Deployed
Application(path=C:\EclipseGalileoBase\.metadata\.plugins
\org.eclipse.wst.server.core\tmp0\wtpwebapps\sample)
Also, it seems that I must supply a <non-jta-data-source>. Running
stand-alone, I can provide persistence.xml <properties> or a map
passed to
createEntityManagerFactory() for JDBC connection information, but
trying
that with OpenEJB embedded, I get:
SEVERE:
java.lang.UnsupportedOperationException: Not supported by
BasicDataSource
at
org
.apache
.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:902)
at
org
.eclipse
.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:135)
at
org
.eclipse
.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:94)
at
org
.eclipse
.persistence
.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:
162)
at
org
.eclipse
.persistence
.internal
.sessions
.DatabaseSessionImpl
.loginAndDetectDatasource(DatabaseSessionImpl.java:583)
at
org
.eclipse
.persistence
.internal
.jpa
.EntityManagerFactoryProvider
.login(EntityManagerFactoryProvider.java:227)
at
org
.eclipse
.persistence
.internal
.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:255)
at
org
.eclipse
.persistence
.internal
.jpa
.EntityManagerFactoryImpl
.getServerSession(EntityManagerFactoryImpl.java:111)
at
org
.eclipse
.persistence
.internal
.jpa
.EntityManagerFactoryImpl
.createEntityManagerImpl(EntityManagerFactoryImpl.java:163)
at
org
.eclipse
.persistence
.internal
.jpa
.EntityManagerFactoryImpl
.createEntityManager(EntityManagerFactoryImpl.java:150)
at pool.data.dao.impl.EMFProvider.getEM(EMFProvider.java:31)
...
Adding a <non-jta-data-source> element and resources to my Tomcat's
openejb.conf corrected that.
David Blevins wrote:
On a side note, that EMFProvider would make one great Singleton bean:
import javax.ejb.Lock;
import static javax.ejb.LockType.READ;
import javax.ejb.Singleton;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.PersistenceUnit;
@Singleton
@Lock(READ)
public class EMFProvider {
@PersistenceUnit(unitName = "daosample")
private EntityManagerFactory emf;
public EntityManager getEM() {
return getEMFactory().createEntityManager();
}
public EntityManagerFactory getEMFactory() {
return emf;
}
}
The result is an bean which is scoped at the app level just as if it
was a static. It's more thread safe -- the previous getEMFactory()
code could result in many EntityManagerFactory instances being
created. You also no longer need to actively clean up the
EntityManagerFactory as the container will do that for you.
You're right.
--
View this message in context:
http://www.nabble.com/Eclipselink-JPA-RESOURCE_LOCAL-PersistenceUnit-with-Tomcat-embedded-tp24746512p25215458.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
