Ahh, I don't think that is the case, since my Class-Path setting is dynamically generated when I produce the EAR by taking all of the jars in my lib directory and adding it to that setting.
Now, I did not update my commons-* jar file for 1.0 -- and you are saying that there was some upgrades? I wonder if that could be the issue. Thanks! -Andrew -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 2:48 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: > Armin, > > Could you clarify for me what you mean by "I think that some jar files > changed between rc6 and 1.0". sorry, my bad English ;-) I mean the names of some jars are changed, e.g. commons-collections-2.1.1.jar instead of commons-collections.jar. Maybe you have a jar in classpath that doesn't match the Class-Path setting. regards Armin Are you saying that dependencies were > removed that rc6 had that 1.0 doesn't need? My Class-Path entry from > my EJB jar file contains the following entries: > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.6.1 > Created-By: 1.4.2-b28 (Sun Microsystems Inc.) > Built-By: andrew.clute > Class-Path: Merlia.jar OSNHtml.jar antlr.jar commons-beanutils.jar com > mons-collections.jar commons-dbcp.jar commons-digester.jar commons-fi > leupload.jar commons-lang.jar commons-logging.jar commons-pool.jar co > mmons-validator.jar db-ojb-1.0.0-src.jar db-ojb-1.0.0.jar jakarta-poi > -1.5.1.jar p6spy.jar > > Are you thinking that there are unnesscary entries in it? I guess am > not sure what the cause or solution would be based on your statement > to look for. Thanks! > > -Andrew > > > > -----Original Message----- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Friday, August 13, 2004 2:34 PM > To: OJB Users List > Subject: Re: Jboss and ClassCastException (MetadataManager and > JdbcConnectionDescriptor) -- anyone else have it? > > Clute, Andrew wrote: > > >>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)? > > > As far as I know the ClassLoader take care of static instances too. > Did you check all jar names and Class-Path entries in your config files? > > I think that some jar files changed between rc6 and 1.0 > > Armin > > > >>-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+f >>il >>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(Unknow >>>n >>>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.getDefaul >>>t >>>Ke >>>y(Unknown Source) >>> at >>>org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPe >>>r >>>si >>>stenceBroker(Unknown Source) >>> at >>>org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBrok >>>e >>>r( >>>Unknown Source) >>> at >>>org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSes >>>s >>>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] >> >> >> > > > --------------------------------------------------------------------- > 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] > > > --------------------------------------------------------------------- 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]
