RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Well, I believe I have found the crux of the issue.
I currently have two things deployed to my Jboss server, both which use
commons-lang (my non-OJB app is a Tapestry app, and is using langs1.0).
When my non-OJB app is deployed, I get the issue. However, when I
undeploy that app, and my OJB app is the only one deployed, and I can
redeploy as often as I would like.
So, obviously this is one of those infamous Jboss ClassLoader issues
(flat classloader space), and as such, I trying to figure out a
workaround. So, it seems like OJB really has no issue, but it was just
the brunt of the Jboss issues.
Thanks for all the help...and once I have found a working solution, I
will post it for all to see.
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 5:29 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
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
Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
I get the same thing pretty much every time I redeploy with Orion Application Server. Any idea what causes this? Is there any way to stop it? Thanks -Clay 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.getDefaultKe y(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersi stenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker( Unknown Source) at org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSessio nPBImpl.java:79) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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+file 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.getDefaultKe y(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersi stenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker( Unknown Source) at org.osn.persistence.PersistenceSessionPBImpl.getBroker(PersistenceSessio nPBImpl.java:79) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
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]
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+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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Armin, Could you clarify for me what you mean by I think that some jar files changed between rc6 and 1.0. 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(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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
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(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
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(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
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
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! -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
Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote: 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. Agree, think 'old' libraries can't cause the issue. Between rc6 and 1.0 many changes are made in source (e.g. OJB startup behavior), but again I can't believe that these changes are responsible for your issue. Do my best, but now I'm stumped. Good luck in bug-hunting! Armin 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
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
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
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
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
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
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
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
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
Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Clute, Andrew wrote: 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. Hope you don't mind if I hop in :-) A couple of weeks ago we unified class and resource loading in OJB into the ClassHelper class, which per default uses the class loader of the current thread. So perhaps the problem here is that the SerializationUtils class does not use this class loader (it is known to happen that the classloader that class.forName uses is not the same as the one of the current thread, e.g. when writing Ant tasks). However in OJB we cannot change this, so perhaps you could create a modified version of commons-lang to verify this, and if this is true, then you probably should file a feature request with the commons-lang folks ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
That's a good idea about trying a modified version of commons-lang. However, I am not sure what they will be able to do about it since they are using ObjectInputStream to do the serialization, and that is Sun's code. Either way, I will see if there is a workaround. On the other hand -- why is OJB using this method to do what looks like is a simple clone routine? If commons-lang method is known to be non-complaint with J2EE (especially JBoss) classloading, wouldn't OJB want to change the way it clones those descriptors? -Andrew -Original Message- From: Thomas Dudziak [mailto:[EMAIL PROTECTED] Sent: Fri 8/13/2004 6:34 PM To: OJB Users List Subject: Re: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it? Clute, Andrew wrote: 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. Hope you don't mind if I hop in :-) A couple of weeks ago we unified class and resource loading in OJB into the ClassHelper class, which per default uses the class loader of the current thread. So perhaps the problem here is that the SerializationUtils class does not use this class loader (it is known to happen that the classloader that class.forName uses is not the same as the one of the current thread, e.g. when writing Ant tasks). However in OJB we cannot change this, so perhaps you could create a modified version of commons-lang to verify this, and if this is true, then you probably should file a feature request with the commons-lang folks ? Tom - 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]
