tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <Costin.Manola...@eng.sun.com>
Subject Re: A third party short summary of Classloader woes - aren't they allcaused by..
Date Thu, 20 Jul 2000 18:16:32 GMT
> 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


Mime
View raw message