I am almost certain that is a ClassLoader issue. Yes, my deployment looks almost the exact same as Stephen's (in fact, I chimed in when he first posted that stating that is already how I was doing it, and it worked fine).
Now, something I forgot to mention: We have only started seeing this since we upgraded to 1.0 from 1.0RC6. We see the problem on both our dev server that is on Jboss 3.2.3, and on my development machine that is on Jboss 3.2.5. Are there any known parts to the OJB Metadata and Configuration stuff that lives through redeployments (i.e. is static)? -Andrew -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:14 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Hi Andrew, think this is a ClassLoader problem. Maybe ojb.jar itself or one of the jars OJB depends on is not correctly reloaded. Did you follow the instructions made by Stephen Ting http://db.apache.org/ojb/docu/guides/deployment.html#Packing+an+.ear+fil e regards, Armin Clute, Andrew wrote: > I am running OJB 1.0 with JBoss 3.2.5. > > On *occasional* redeployments of my EAR file (with nested Jars and > Wars) I will get a nasty ClassCastException that is only fixable by > restarting Jboss. This happens in the MetadataManager.buildDefaultKey() method. > > The top part of the stack trace is posted below. From what I can tell, > the exception stems from not that it is the wrong class attempting to > be casted, but it is an instance of a class that is from a previous > deployment (and thus classloader) that is trying to be casted in to > the same class type in a new class loader. > > I have taken a quick look at MetadataManager, and don't see anything > terribly obvious as to the cause -- which I would assume is a static > instance to the Collection of JdbcConnectionsDescriptors. There is a a > ThreadLocal variable, but I don't think that is the cause. > > So, my question is: has anyone else seen this? Can anyone think of why > on a undeployment that not all of the OJB classes are removed from the > VM? > > Thanks! > > Here is the stacktrace: > > 2004-08-11 13:24:22,923 ERROR [org.jboss.ejb.plugins.LogInterceptor] > RuntimeException: > java.lang.ClassCastException > at > org.apache.ojb.broker.metadata.MetadataManager.buildDefaultKey(Unknown > Source) > at org.apache.ojb.broker.metadata.MetadataManager.init(Unknown > Source) > at org.apache.ojb.broker.metadata.MetadataManager.<init>(Unknown > Source) > at > org.apache.ojb.broker.metadata.MetadataManager.getInstance(Unknown > Source) > at > org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.getDefault > Ke > y(Unknown Source) > at > org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPer > si > stenceBroker(Unknown Source) > at > org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroke > r( > Unknown Source) > at > org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSess > io > nPBImpl.java:79) > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
