tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Rahman <r...@rahmannet.net>
Subject Re: Transaction Problems with OpenEJB-Hibernate on Tomcat
Date Tue, 19 Jan 2010 01:17:08 GMT
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 <fwy@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
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>     
>>>>         
>>>   
>>>       
>>
>>     
>
>   


Mime
View raw message