I am wondering if it has something to do with the fact that SerilizationUtils uses ObjectInputStream to serialize/desearlize the objects, and ObjectInputStream on the deserialization does a Class.forName() to create the new object -- which in the J2EE classloader world can cause problems. I think that would explain why it would use the previous versions. I am posting a message to the Jboss group to see if my hypothesis is correct.
-Andrew -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 5:25 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? > So, now I need to figure out why this is happening. Something thing > looks weird for the after-serilization version after redploying, since > the url for that class is null. Not sure where it is loading it from, or > why it has a stored copy of it. > I must admit that I don't have a clue... Did you checked commons-lang.jar? SerializationUtils is part of commons-lang and if this jar wasn't redeployed it will use the 'old' class-loader. Or is commons-lang duplicated in classpath? regards, Armin Clute, Andrew wrote: > Well, I have narrowed the issue down further, but still do not have a > solution yet. In ConnectionRepository.getAllDescriptor(), the > JdbcConnectionDescriptor's that are in the current repository are > cloned > (seralized) into another list and returned. I made the guess (and I > was > right) that when this error is exposed, the JdbcConnectionDescriptor's > that are returned from the Serilization are loaded in a different > classloader than the ones that OJB creates! > > To prove this, I changed the code for that method from: > > [code] > public List getAllDescriptor() > { > return (List) SerializationUtils.clone(new > ArrayList(jcdMap.values())); > } > [/code] > > To: > > [code] > public List getAllDescriptor() > { > > Iterator it = jcdMap.values().iterator(); > while (it.hasNext()){ > Object o = it.next(); > System.out.println("ClassLoader for " + > o.getClass().getName() +" before Serialization: " > +o.getClass().getClassLoader()); > } > > List returnList = (List) SerializationUtils.clone(new > ArrayList(jcdMap.values())); > it = returnList.iterator(); > while (it.hasNext()){ > Object o = it.next(); > System.out.println("ClassLoader for " + > o.getClass().getName() +" after Serialization: " > +o.getClass().getClassLoader()); > } > > return returnList; > } > [/code] > > And as I assumed, the first time my application is deployed, the > classloader for the Connection is the same for both what OJB uses, and > what SerilizationUtils uses: > > 17:02:09,592 INFO [STDOUT] ClassLoader for > org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before > Serialization: [EMAIL PROTECTED] > url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear > ,addedOrder=37} > 17:02:18,811 INFO [STDOUT] ClassLoader for > org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after > Serialization: [EMAIL PROTECTED] > url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear > ,addedOrder=37} > > > But, after redeploying it, the classloader for OJB changes (as I would > assume is correct), but the classloader for SerilizationUtils stays > the same as the previous version! Oops! > > 17:03:04,780 INFO [STDOUT] ClassLoader for > org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before > Serialization: [EMAIL PROTECTED] > url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56537OSNCore.ear > ,addedOrder=38} > 17:03:11,280 INFO [STDOUT] ClassLoader for > org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after > Serialization: [EMAIL PROTECTED] > url=null ,addedOrder=37} > > So, now I need to figure out why this is happening. Something thing > looks weird for the after-serilization version after redploying, since > the url for that class is null. Not sure where it is loading it from, > or why it has a stored copy of it. > > -Andrew > > -----Original Message----- > From: Clute, Andrew [mailto:[EMAIL PROTECTED] > Sent: Friday, August 13, 2004 3:53 PM > To: OJB Users List > Subject: RE: Jboss and ClassCastException (MetadataManager and > JdbcConnectionDescriptor) -- anyone else have it? > > Just for giggles, I changed my EAR to use the Application.xml file to > denote the dependant jar files, and took it out of the Manifest file > for my Ejb jar, and it still is causing the issue! > > Ughh. Might be time to post this to the Jboss forums -- but they are > not nearly as helpful! :) > > -Andrew > > > > -----Original Message----- > From: Clute, Andrew [mailto:[EMAIL PROTECTED] > Sent: Friday, August 13, 2004 3:22 PM > To: OJB Users List > Subject: RE: Jboss and ClassCastException (MetadataManager and > JdbcConnectionDescriptor) -- anyone else have it? > > I don't fill out the application.xml entries, since I Thought it was > an either-or situation (either Class-Path in the manifest file, or > entries in Application.xml) > > > > -----Original Message----- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Friday, August 13, 2004 3:18 PM > To: OJB Users List > Subject: Re: Jboss and ClassCastException (MetadataManager and > JdbcConnectionDescriptor) -- anyone else have it? > > Clute, Andrew wrote: > > >>Upgrading to the newest versions of the lib files for OJB did not fix >>the problem. >> >>I wish there was someway I could figure out what was keeping the >>reference to the previous classes around that would conflict with the >>new classloader. Ugh! >> > > > last-ditch attempt ;-) > Did you check the entries in application.xml too? Or was this file > auto-generated too? > > Armin > > >>-Andrew >> >> >> >>-----Original Message----- >>From: Clute, Andrew [mailto:[EMAIL PROTECTED] >>Sent: Friday, August 13, 2004 2:50 PM >>To: OJB Users List >>Subject: RE: Jboss and ClassCastException (MetadataManager and >>JdbcConnectionDescriptor) -- anyone else have it? >> >>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(Unkn >>>>>o >>>>>w >>>>>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.getDefa >>>>>u >>>>>l >>>>>t >>>>>Ke >>>>>y(Unknown Source) >>>>> at >>>>>org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.default >>>>>P >>>>>e >>>>>r >>>>>si >>>>>stenceBroker(Unknown Source) >>>>> at >>>>>org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBr >>>>>o >>>>>k >>>>>e >>>>>r( >>>>>Unknown Source) >>>>> at >>>>>org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceS >>>>>e >>>>>s >>>>>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] >> >> >>--------------------------------------------------------------------- >>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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
