I just took Simone's patch and applied it to the 3_0 branch. it did not
work. Here is the stacktrace. ...
Cause: java.lang.ClassCircularityError: java/lang/String
07:57:09,416 ERROR [STDERR] at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:307)
Hi Dave,
I just took Simone's patch and applied it to the 3_0 branch.
Do you mean what I committed to HEAD 2-3 hrs ago ?
it did not
work. Here is the stacktrace. ...
Cause: java.lang.ClassCircularityError: java/lang/String
I catch CCE in the new code, how come you get it back ?
Cheers
On Wed, 2002-06-05 at 08:36, Bordet, Simone wrote:
Hi Dave,
I just took Simone's patch and applied it to the 3_0 branch.
Do you mean what I committed to HEAD 2-3 hrs ago ?
yes version 1.12
it did not
work. Here is the stacktrace. ...
Cause: java.lang.ClassCircularityError:
Hi Dave,
Cause: java.lang.ClassCircularityError: java/lang/String
I catch CCE in the new code, how come you get it back ?
I thought you would know that ;-). Anything I can do to help the
debugging?
Yes, can you track down from where exactly the CCE comes from ?
It seems from your
Well after alot of tracking down it looks like it is comming from the
JVM itself. Looking at the code snippet it checks to see if the class is
in the table *before* calling the classloader. I can not generate a
stack trace for the life of me anywhere ... Any other pointers ..
On Wed, 2002-06-05
Actully does not this part of the JVM spec basically say it all ...
5.3.2 Loading Using a User-defined Class Loader
The following steps are used to load and thereby create the nonarray
class or interface C denoted by N using a user-defined class loader L.
First, the Java virtual machine
Hi Dave,
Well after alot of tracking down it looks like it is comming from the
JVM itself.
Yes, CCE are only thrown from the JVM code.
Sorry, I was not clear before.
I see you are using JMX to invoke some method, yes ?
Let's call it target method, you call it from
OK. wrapped up the target method in CCE. These are thrid party libs and
I believe smoewhere in the bowels they use forName() and newInstance().
What I don't understand is why I do not see it going through the UCL. or
at least a classloader.
Here is the bt
11:48:58,960 ERROR [STDERR]
Hi Dave,
Actully does not this part of the JVM spec basically say it all ...
5.3.2 Loading Using a User-defined Class Loader
The following steps are used to load and thereby create the nonarray
class or interface C denoted by N using a user-defined class loader L.
First, the Java
Hi Dave,
OK. wrapped up the target method in CCE. These are thrid
party libs and
I believe smoewhere in the bowels they use forName() and
newInstance().
What I don't understand is why I do not see it going through
the UCL. or
at least a classloader.
I guess because they're using
I have decompilied it before to make some sense of it. I now there is a
class.forName and a newInstance but I don't think they use there own
classloader.
All of the classes are in the deploy directory not in the jboss lib dir.
The -sevice.xml file that starts this is has them in a classpath def
Hi Dave,
I have decompilied it before to make some sense of it. I now
there is a
class.forName and a newInstance but I don't think they use there own
classloader.
Uhm.
All of the classes are in the deploy directory not in the
jboss lib dir.
The -sevice.xml file that starts this is has
From my CCE catch block
catch(ClassCircularityError err)
{
err.printStackTrace();
System.out.println(com.candata.gateway.EncryptionService
+com.candata.gateway.EncryptionService.class.getClassLoader().getClass().getName());
Doh ..
13:49:07,802 INFO [STDOUT] com.candata.gateway.EncryptionService
org.jboss.mx.loading.UnifiedClassLoader
13:49:13,210 INFO [STDOUT]
com/entrust/toolkit/x509/policies/ClientSettings
org.jboss.mx.loading.UnifiedClassLoader
13:49:13,224 INFO [STDOUT] com/entrust/toolkit/util/ByteArray
:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Friday, May 31, 2002 11:15 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
|
|
|I think that is too simplified but the seperation between the CL invoked
|to do the class loading by threads vs
is if you payed me, you always try and fix it of
course
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Dave
|Smith
|Sent: Monday, June 03, 2002 6:19 AM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
|
|
|It's
Hi,
so I dug into the hotspot code for JDK 131, and I found the problem. I am too tired
now to think for a solution, this is for you brave guys :)
The problems arises from a 20 lines of code in
src/share/vm/memory/systemDictionary.cpp (attached), method
resolve_instance_class_or_null(...).
Are you sure? From your desription it would seem that the reason
loadClassInternal is syncronized is to stop this case from happening.
The way you are describing it it would not make any differnce, and the
resolve_instance_class_or_null is not thread safe.
On Fri, 2002-05-31 at 12:13, Bordet,
Hi,
Are you sure?
No, I *think* so.
From your desription it would seem that the reason
loadClassInternal is syncronized is to stop this case from happening.
I think the main assumption of the JVM code is that noone waits during a
loadClassInternal() call on the classloader itself, thus
of the code.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Bordet, Simone
Sent: Friday, May 31, 2002 1:19 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi,
Are you sure?
No, I *think* so
Technology Officer
JBoss Group, LLC
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 31, 2002 10:41 AM
Subject: RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
I hope I'm not being really stupid here. Couldn't
I was stupid. Having one master CL would break JNDI ENC.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
M Stark
Sent: Friday, May 31, 2002 2:15 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ClassCircularityError - PROBLEM FOUND
.
|
|
|Scott Stark
|Chief Technology Officer
|JBoss Group, LLC
|
|- Original Message -
|From: Bill Burke [EMAIL PROTECTED]
|To: [EMAIL PROTECTED]
|Sent: Friday, May 31, 2002 10:41 AM
|Subject: RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
|
|
| I hope I'm
| I hope I'm not being really stupid here. Couldn't you have one master
|class
| loader that delegated to a UCL. Then you wouldn't need all this funky
| locking and hacks and workarounds. Switch the ULR and UCL. ULR delegate
|to
| UCL instead of the other way around
|
| Again, maybe I'm
24 matches
Mail list logo
