Fred,
I would remove all the JTA/transaction factory stuff and assume a clean JPA
bootstrap. For completeness, can you kindly send me your Hibernate
configuration file? The stuff in that configuration file should move to the
persistence.xml file instead.
If you do end up needing to feed Hibernate a custom transaction factory, David
and the other OpenEJB guys are probably the best people to help with that since
they wrote the thing...but let's give this a spin first.
Cheers,
Reza
=============================
Author, EJB 3 in Action
Expert Group Member, Java EE 6 and EJB 3.1
Resin EJB 3.1 Lite Container Lead
freeway wrote:
Hi Reza,
Thanks for the quick response.
I just tried placing the following persistence.xml file in the webapp's
WEB-INF/classes/META-INF/ directory, but received the same runtime error
from JTATransactionFactory.
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";>
<persistence-unit name="myapp" transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>jdbc/LsBpmDS</jta-data-source>
<properties>
<property name="hibernate.ejb.cfgfile" value="hibernate.cfg.xml"/>
</properties>
</persistence-unit>
</persistence>
This file references the same hibernate.cfg.xml file included in my previous
post to obtain all Hibernate properties. I can see from the OpenEJB and
Hibernate log files that this configuration was found and loaded at Tomcat
startup. However, it still executes the class
org.hibernate.transaction.JTATransactionFactory and fails to retrieve the
UserTransaction object in the same way.
Do I need to use a different OpenEJB-provided transaction factory class, or
override the Hibernate-provided one myself? Or is my above configuration
simply incorrect for using JPA in OpenEJB?
Thx in advance,
Fred
Reza Rahman-2 wrote:
Hi,
I might have lost some context here, but have you tried simply defining
your OpenEJB JTA data source persistence.xml instead of using
hibernate.cfg? I am thinking this issue might be best resolved simply by
going through the OpenEJB/JPA compatibility layer of Hibernate. Are you
planning on using the JPA APIs or native Hibernate with OpenEJB? Note,
the Hibernate team itself recommends JPA, you can configure Hibernate
via persistence.xml and you can always get access to the native
Hibernate session via EntityManager.getDelegate() if you really need it:
http://bill.burkecentral.com/2007/07/06/co-existence-with-hibernate-jpa-and-ejb3/.
It's certainly a lot simpler to use JPA with EJB 3.x instead of trying
to inject native Hibernate objects directly.
Hope it helps,
Reza
=============================
Author, EJB 3 in Action
Expert Group Member, Java EE 6 and EJB 3.1
Resin EJB 3.1 Lite Container Lead
freeway wrote:
I have made some progress sorting out general configuration errors from
my
Tomcat 6 environment, and can restate the transaction problem in more
specific terms that will hopefully lead more directly to a solution.
The specific errors mentioned in my first post were mainly the result of
Tomcat classloader problems, resulting from various dependent classes
deployed wrongly in the webapp WEB-INF/lib/ directory, Tomcat lib/
directory, or both. Many of the errors raised as a result of these
problems
are generic and misleading messages such as 'cannot instantiate
class...',
'document error...', etc. (Classloader problems seem to be the root of
all
evil with things Tomcat.) However, after fixing these problems I am
still
unable to retrieve the JTA transaction properly from Hibernate 3.
I have configured the environment to move the transaction-managed JDBC
data
source configuration from Tomcat's server.xml into openejb.xml, as
follows.
<Resource id="jdbc/LsBpmDS" type="DataSource">
JdbcDriver com.mysql.jdbc.Driver
JdbcUrl jdbc:mysql://localhost:3306/qadworkflow?autoReconnect=true
UserName ...
Password ...
JtaManaged true
InitialSize 0
MaxActive 20
MaxIdle 20
MinIdle 0
MaxWait -1
</Resource>
My hibernate.cfg.xml configuration is as follows (irrelevant settings
omitted).
<property
name="connection.datasource">java:comp/env/jdbc/LsBpmDS</property>
<!-- Proposed workaround suggested on Hibernate forums to work
around bug in UserTransaction retrieval, that causes stack overflow -->
<property name="jta.UserTransaction">UserTransaction</property>
<property
name="transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
<property
name="hibernate.transaction.manager_lookup_class">org.apache.openejb.hibernate.TransactionManagerLookup</property>
With the above I receive a stack overflow error at runtime when
attempting
to retrieve the JTA transaction.
java.lang.StackOverflowError
at java.lang.Character.digit(Unknown Source)
at java.lang.Character.digit(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.text.MessageFormat.makeFormat(Unknown Source)
at java.text.MessageFormat.applyPattern(Unknown Source)
at java.text.MessageFormat.<init>(Unknown Source)
at java.text.MessageFormat.format(Unknown Source)
at org.apache.naming.StringManager.getString(StringManager.java:121)
at org.apache.naming.StringManager.getString(StringManager.java:144)
at org.apache.naming.NamingContext.lookup(NamingContext.java:770)
at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137)
at javax.naming.InitialContext.lookup(Unknown Source)
at
org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:162)
at
org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:172)
at
org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:172)
...
Here is an associated nested exception.
java.rmi.RemoteException: The bean encountered a non-application
exception;
nested exception is:
java.lang.StackOverflowError
at
org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException(EjbTransactionUtil.java:152)
at
org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:174)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
I have also tried setting the JNDI context factory to the OpenEJB
implementation by adding the setting below, but it does not change the
error.
<property
name="jndi.class">org.apache.openejb.client.LocalInitialContextFactory</property>
The stack overflow error in itself is well-known Hibernate behavior
resulting from repeated unsuccessful attempts by Hibernate to retrieve
the
UserTransaction object. From other postings, I know that Hibernate's
JTATransactionFactory class always attempts to read the UserTransaction
object, regardless of the TransactionManager being used; and that
apparently
OpenEJB does not create a UserTransaction object inside its own JNDI
store.
Is this the root cause of my problem??
Also, I ran across the class
'org.apache.openejb.tomcat.common.UserTransactionFactory' inside one of
the
OpenEJB JAR files, and tried configuring a UserTransaction myself in
server.xml as follows.
<Transaction
factory="org.apache.openejb.tomcat.common.UserTransactionFactory" />
This change seemed to have no effect at runtime. I could not even find
any
Tomcat log entries verifying that it was used.
Finally I don't know how relevant it is, but I am also puzzled how
Hibernate
is able to retrieve the OpenEJB-managed data source
'java:comp/env/jdbc/LsBpmDS' at all, given that this is the JNDI name
used
by Tomcat when it was still configured in server.xml. (It is now
unreferenced in both server.xml or the webapp's context.xml.) My
understanding from other OpenEJB forum postings is that the JNDI name
used
by OpenEJB from outside an EJB would be 'java:openejb/Resource/LsBpmDS'.
However, if I change the connection.datasource property value in
hibernate.cfg.xml to ''java:openejb/Resource/LsBpmDS'', I receive a
different JNDI lookup error when using either the OpenEJB JNDI context
factory or the default.
javax.ejb.EJBException: org.hibernate.HibernateException: Could not find
datasource
at
org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:212)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
...
I have reviewed Hibernate, OpenEJB, and Tomcat debug logs and can at
least
verify that the Hibernate settings that I have tried are being used at
runtime. However, these logs have not been of much help diagnosing the
problem.
Please suggest config changes that I made need, or point me to any custom
class implementations that might help.
Reza Rahman-2 wrote:
Let me see if I can help here, it'll take me a couple of days,
though...I'm swamped at the moment. I would think David could help
too...
Cheers,
Reza
=============================
Author, EJB 3 in Action
Expert Group Member, Java EE 6 and EJB 3.1
Resin EJB 3.1 Lite Container Lead
Jacek Laskowski wrote:
On Mon, Jan 11, 2010 at 4:32 AM, freeway <f...@qad.com> wrote:
To close this message: I have seen many (rather confusing) posts and
partial
examples regarding the use of the config files persistence.xml,
services-jar.xml, and/or openejb-jar.xml files to define data source
resources, Hibernate properties, and transaction managers more
explicitly
inside OpenEJB. However, it seems to me based on other doc I have
read
that
using openejb.xml, ejb-jar.xml, and the native Hibernate files should
be
enough for a seemingly straightforward case like this one. If this is
wrong, please steer me in the right direction.
I'm so glad you're building the stack with OpenEJB, but alas I won't
be able to help you out with the problem at hand. I hope there're
people in the mailing list who will share their findings with similar
configurations and will provide a viable solution.
Jacek
