A third party short summary of Classloader woes - aren't they all caused by..

[Jim Rudnicki <jd...@pacbell.net>]

org.w3c.dom? Level 1 and Level 2 (and the like)

After watching this most informative debate about classloaders, I've
converted to Costin's side.  Of course my web app shouldn't be able to
choose classes over those provided by the system.  I've been given so many
good ideas: if I could just get my own "special" copy of java.util.Hashtable
before the system's... or maybe slip my jdbc driver inplace of the
system's...

But I'm still left with this nagging problem that I feel is the ignitor of
many people's problems (not that it is the sum of the powder keg, just a
little spark): the aformentioned DOM level 1 and 2.

So can I collect any agreement on the issue of org.w3c.dom?  Despite the
good intentions of ostensibly intelligent people, it is not a good thing to
put two different packages under the same package name?


Jim

Re: A third party short summary of Classloader woes - aren't they allcaused by..

[Costin Manolache <Co...@eng.sun.com>]

> The particular issue with the XML classes can be solved in a way
> completely
> separate from the class loader ordering issue.
>
> The reason that this is a problem is that Tomcat 3.2 currently makes its
> own
> classes, and the classes that it depends on, visible on the system class
> path
> (and therefore visible to web applications).  A solution to that problem
> would
> be to not do so -- arrange that Tomcat's own classes, and whatever XML
> parser it
> wants to use, to *not* be visible on the system class path.  This change

And how do you plan to deal with next versions of JDK where XML parser
will be included in the JDK ?




> That way, the sysadmin can install or not install an XML parser as a
> shared
> system library, and the web app will either override or not override
> that
> library depending on the resolution of the ordering question -- which
> needs to
> be done in the spec so that it is implemented consistently.

Unfortunately it's not a servlet-spec issue - but a JVM issue,
plus a number of specs that are in the same situation ( J2EE is
in the same situation with EARs, and J2EE spec does have
a clear distinction of roles that will have to be changed quite
a bit to move the drivers on the application developer's role ).

What classes are available from the server container is also not
a servlet-spec issue as long as it allows the servlet container to be
embeded in applications - again, the embeding app will have it's
own classes ( and I suppose you can't force them to change )

Costin

Re: A third party short summary of Classloader woes - aren't they allcaused by..

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Jim Rudnicki wrote:

> [snip]
> So can I collect any agreement on the issue of org.w3c.dom?  Despite the
> good intentions of ostensibly intelligent people, it is not a good thing to
> put two different packages under the same package name?

The particular issue with the XML classes can be solved in a way
completely
separate from the class loader ordering issue.

The reason that this is a problem is that Tomcat 3.2 currently makes its
own
classes, and the classes that it depends on, visible on the system class
path
(and therefore visible to web applications).  A solution to that problem
would
be to not do so -- arrange that Tomcat's own classes, and whatever XML
parser it
wants to use, to *not* be visible on the system class path.  This change
was
recently implemented in Catalina, but I cannot work on it for Tomcat 3.x
until
next week (after returning from the O'Reilly Open Source Conference).

That way, the sysadmin can install or not install an XML parser as a
shared
system library, and the web app will either override or not override
that
library depending on the resolution of the ordering question -- which
needs to
be done in the spec so that it is implemented consistently.

>
> Jim

Craig McClanahan

Re: A third party short summary of Classloader woes - aren't they allcaused by..

[Costin Manolache <cm...@yahoo.com>]

> So can I collect any agreement on the issue of org.w3c.dom?  Despite the
> good intentions of ostensibly intelligent people, it is not a good thing to
> put two different packages under the same package name?

My argument was about class ordering and the security ( and about using
class loader to prevent downcasting instead of using the design patterns).

About what gets into the server classpath - and the DOM version, that's
something else. We can fix tomcat to not use DOM ( there is only one
class in jasper, and it can be changed to sax easily), and have only
SAX in classpath.

Keep in mind that a next version of JDK will ( probably)
include JAXP and a parser, so the DOM will be part of the "system"
( and I do hope no class loader will override the system classes ).

My impression was that DOM2 extends DOM1 and ( according to
java versioning docs) you should be able to use DOM1 apps with
DOM2 parser. I have to check that, but if so we'll just need to make
sure a DOM2 parser is included.

If not - then we're in trouble ( and again, since this will be part of JDK
we are in a dangerous case if we override it ). I hope this is not the case.

Costin