[jdom-interest] Impact of removing Element.addContent(CDATA) in Beta 9

[Jason Hunter]

> 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.

-jh-