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(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]
--------------------------------------------------------------------- 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]
