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]
