Yes, The problem is happening at redeployment but I deploy using a build script in a packaged ear file. I have not added the commons-collections and pool jar but I will go ahead and add them and check how it works.
JBoss has TRACE logging options of the class loader but I could not make any sense of it. I will give it a try. Surprisingly everything works in hibernate when I switch the persistence.xml. Moreover my partner is able to deploy as a jar with openJPA. Even if I use openJPA, I still have to keep the hibernate jars in the lib path of JBoss because its services uses it extensively. I wonder if anyone has deployed openJPA in JBoss and completely gotten rid of hibernate. On Fri, Feb 29, 2008 at 11:35 AM, Kevin Sutter <[EMAIL PROTECTED]> wrote: > I also did some quick searches on this specific exception and it sure is > "popular" on jboss and jboss-related forums. So far, I haven't found the > solution. Many of the answers seem to indicate that "we moved to a newer > version of some software and the problem went away". Not very helpful. The > problems posted do seem to be related to re-deployment of an application. > Is that your scenario as well? > > The Geronimo* jars should not be necessary, if they are provided by the > jboss environment (persistence, transactions, etc). > > You mentioned commons-lang and commons-logging, but we also have > dependencies on commons-collections, and commons-pool. > > Within WebSphere, we have some tracing options for classloaders. Does jboss > have anything like that? > > Thanks, > Kevin > > > > On Fri, Feb 29, 2008 at 8:50 AM, nitros <[EMAIL PROTECTED]> wrote: > > > > > > > Kevin Sutter wrote: > > > > > > The JPA spec requires a global jndi name, which would require a name > > along > > > the lines of "jdbc/EswaadAppDS". I know that WebSphere allows the use > > of > > > a > > > component-level name, but that would be along the lines of > > > "java:comp/env/jdbc/EswaadAppDS". Not sure what namespace you are going > > > after with just "java:/EswaadAppDS". Maybe it's something unique with > > > jboss that I am not familiar with. > > > > > > > According to JBoss, the above DS is in the Namespace but is not exposed as > > a > > Global JNDI as it is not recommended to expose the DS. > > > > I agree that the openjpa.MetaDataFactory and openjpa.jdbc.DBDictionary is > > not really needed and hence it is removed. > > > > The problem still exists and I also posted the exception in JBoss forums > > but > > failed to receive any response from the community. So far, I am doing my > > development in hibernate but our intention is to move away from it and > > adapt > > openJPA > > > > I would appreciate if anybody can figure out what is causing the problem. > > I > > only have Serp.jar, common-lang.jar. log4j.jar, openJPA.jar and all of > > standard JBoss jars in the JBoss lib classpath. The Geromino.* are not > > there and I don't think it is needed > > > > > > -- > > View this message in context: > > > http://www.nabble.com/Help-needed-with-JBoss-and-openJPA-tp15603051p15760089.html > > Sent from the OpenJPA Users mailing list archive at Nabble.com. > > > > > -- Sincerely, Shibu Gope Tel: 704-900-3126 Fax: 866-699-9215 www.eSwaad.com
