[jdom-interest] Impact of removing Element.addContent(CDATA)
in Beta 9
jhunter at servlets.com
Tue Nov 18 12:08:40 PST 2003
> The class loading algorithm used by both JBoss and JRun
> (and quite possibly many others) mean that the version
> of JDOM they supply is used in preference to any supplied
> by an application.
The servlet specification took pains to make it clear that an app server
shouldn't expose its internal classes to the servlet environment. To do
so is a recipe for portability problems. If each servlet environment
sees a different class world, you can't help but having problems.
> The result is that the same application cannot work in both
> of these environments.
Yep, that's the purest definition of a portability problem.
> While you can update the JDOM supplied by the application servers
> you run the risk of both breaking their code as well as other
> applications running within them.
> As application server vendors (and perhaps application vendors)
> are very slow to upgrade their dependant libraries it is unwise
> to make API changes such as this as it can have far reaching
> implications ...
Per the Servlet Spec public draft #2 section 9.7.2:
"The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. It
must not allow the WAR to override J2SE or Java Servlet API classes. It
is further recommended that the loader not allow servlets in theWAR to
access theWeb container’s implementation classes. It is recommended
also that the application class loader be implemented so that classes
and resources packaged within the WAR are loaded in preference to
classes and resources residing in container-wide library JARs.'
Both JRun and JBoss are ignoring this advice.
More information about the jdom-interest