What language is this guy talking.... ha ha.
This has got to be for a thesis or something.... or its attempted suicide ;)
----- Original Message -----
From: "Michel Betancourt" <[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
Sent: Thursday, January 17, 2008 3:33 AM
Subject: Tomcat 5.5 classloading behavior
Hi,
I am wondering if someone may be able to point me in the right direction
here... after reviewing the J2SE spec, and the Servlet 2.4 Spec, its not
too clear whether circular dependecies such as the one I am investigating
below are legal or supported by Tomcat. Sun J2SE 5.0 classloader does not
seem to support such initialization although the Tomcat classloader (v5.5)
seems to an operation such as my example below.
An exert of the Java specification states:
12.4.2, #3 If initialization is in progress for the class or interface by
the current thread, then this must be a recursive request for
initialization. Release the lock on the Class object and complete
normally.
You know what you should do... find a little custom class loader example on
the web and run it through a debugger.
They look simple but when you actually watch them work, and how reentrent
the things are, this will hopefully all start to make sense.
I think most guys havnt even started thinking about this...
ClassCircularityError Wow!.... dont trap that in my code ;)
This is what I think.... the normal system classloader, and the tomcat
classloader when it comes to threads and reentrant code will
behave exactly the same... the reason is that one class loader inherets from
another and thus one can expect the behavior to be similar.
The only diffirence is where the tomcat classloader will look for jars and
class's.
ie the same stuff is happening but when it comes time to find "Your
Class"... it will look for it in the web-app, after that i think
its much of a muchness.
Thats different because outside of web servlets... class loaders are not
allowed to work like that... they always ask the classloader
"above" them if it has the class already, if not the parent class loader
tries to find it, and ONLY if it cant find it, will the "child" classloader
try and get it.
If you watch a cl working you'll see that recursive request stuff
happenning... and I'm no academic, in plain talk it just means
that all those dependencies must be gotten out of the way, before the next
thread can come in and ask for a class to load.
So if A -> B -> C and thread one is busy with A, and thread 2 really just
wants C.... it has to wait, because otherwise
C would load... and then A would eventually get to it and it would load
again because its already kicked off that recursive pattern.
Then because C is waiting.... A will actually will have done it already...
and the cl will then just say... thread 2, you lucky, class is loaded, you
can go now.
Normal CL or Tomcat.... no diffs.
The other thing with these examples is that yes I guess it is possible to be
surprised in the way STATIC variables are inited in complex
class structure... but remember is LOADING, not INSTANTIATING the class,
that comes later outside of the CL, so in most cases
it not an issue one would even encounter.
I dont think its possible to make an ClassCircularityError error with a
modern IDE... I dont think it will let you compile the code
Class A extends A
so if you actually making these classes and compiling them.... I dont think
its possible to simulate it without hacking byte code.
.... be interesting to hear if anyone ever seen that.
Thanks... I never ever thought about static variables before... and I've
never seen it in practical code.
ie I think in normal code a programmer may go.... what the... I thought
static A was going to be 5, why is it 10, or whatever...
and then eventually see the curcular RELATIONSHIP.... but I doubt that would
cause an error.
If its compiling... I dont think you can break a classloader... short of it
just cant find the Jar....
interesting things these classloaders... good luck.
If its practical stuff... I can help you a little, heavy specs and theory...
you on your own ;)
Servlet 2.4 spec says that Classloaders need to follow the J2SE
specification.
So as I am investigating the Tomcat 5.5 classloader I am wondering if
either
one of these situations are legal for Tomcat 5.5 or whether I should be
observing a ClassCircularityError... debugging my App shows the following
behavior:
Examples :
Class A {
static {
System.out.println(B.somefield); // debugger shows that A is checked and
the
static block is invoked. B is loaded which initializes B.somefield
through
the constructor of A.
}
}
Class B {
public static final A somefield;
}
and/or circular dependecy from Parent static initializers
Class Parent {
static {
System.out.println(B.somefield); // debugger shows A is checked, Parent is
loaded which loads B which loads somefield through the constructor of
class
"A"
}
}
Class A extends Parent {
}
Class B {
public static final A somefield;
}
Thanks in advance.
Best Regards,
Mich
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
