[GLASSFISH-13134] Allow to override javax.* packages on the web application level Created: 26/Aug/10  Updated: 23/Aug/11

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: v3.0.1
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Jakub Podlesak Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: Linux

Attachments: Text File overrideablePackages.patch    
Issuezilla Id: 13,134


While there is a good reason to disallow applications to override e.g. the
standard Servlet API implementation in GlassFish, it could make perfect sense
for other Java EE APIs. For instance there is already a custom tag in
sun-web.xml to allow using custom JSF API classes bundled with a web application
to override the default version bundled with GlassFish. I would like to make
this possible also for JAX-RS API, and also at the application level.

Currently, one could use the following command:
asadmin create-jvm-options

together with <class-loader delegate="false"> in the sun-web.xml

This, however, works only at the application server level and does not allow
control at the application level as in the JSF case. The drawbacks are obvious:
if you do not control the whole container, you are out of luck. Also to change
this just for one application, you would need to restart the whole server
and interrupt also the other running applications.

I am going to attach a patch to allow to specify a list of overriden
Java packages in the GlassFish specific web application descriptor,
sun-web.xml or glassfish-web.xml, so that the application could
configure use of it's own bundled Java packages belonging to the protected
javax.* space.

Following is an excerpt of how the web application bundling it's own
JAX-RS implementation should look like after the patch is applied:

<class-loader delegate="false">
<property name="overrideablePackages"

Comment by Jakub Podlesak [ 26/Aug/10 ]

Created an attachment (id=4745)

Comment by survivant [ 02/Feb/11 ]

please check the Issue http://java.net/jira/browse/GLASSFISH-15741

for a sample that doesn't work.

Comment by gfuser9999 [ 23/Aug/11 ]

user comment
1) This issues is for http://java.net/jira/browse/GLASSFISH-15741
is not differently related to this issue.
The testcase in http://java.net/jira/browse/GLASSFISH-15741
is due to classloading but this fix enhancement
is neccesary to provide per-webapp isolation
of Jersey and others.

2) For example with adding "-Dcom.sun.enterprise.overrideablejavaxpackages=javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext" and where the sun-web.xml have
delegate="false", the above same app will fail after
a deploy <app>, undeploy <app>, deploy <app> cycle.
and you will hit http://java.net/jira/browse/JERSEY-660

3) The reason w/o the override seems to be that the JAXRS
Single RuntimeDelegate will point to the undeployed
WebappClassLoader. And By default GF31
WebappClassLoader will clear internal references.

If the above system property exists, then it should
be working fine. In fact as the system property
is global, it is not fine grain. It seems to me
that the request to have the overridePackages in
sun-web.xml would be Good as it is the same
trick as useBundledJsf or useMyFaces switch tries
to achieve.

So +1 for this.


WebappClassLoader seem to have a coding bug:
On GF311, Line 1886->1903, the "If statement" is
wrongly done – triggering wrong condition to
clear-reference. (It also does not check loadedByThisOrChild()).

Generated at Fri Mar 24 05:29:10 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.