Issue Details (XML | Word | Printable)

Key: GLASSFISH-10496
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Hong Zhang
Reporter: abien
Votes: 0
Watchers: 5

If you were logged in you would be able to see more operations.

Global V2 Compatibility Mode For GF v3

Created: 22/Oct/09 12:43 AM   Updated: 12/Jun/13 11:56 AM
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Time Tracking:
Not Specified


Operating System: Mac OS X
Platform: Macintosh

Issuezilla Id: 10,496
Participants: abien, Bill Shannon, erpomata, Hong Zhang, ludo, Tim Quinn, Tom Mueller and vince kraemer

 Description  « Hide

Glassfish v3 comes with compatibility feature: asadmin deploy --property compatibility=v2 foo.ear

The problem: this feature is only available from the CLI. There should be global e.g. setting (in
domain.xml) and accessible from the admin UI (EJB container node) to be set persistently. A local setting,
e.g. in the deployment descriptor: sun-*.xml .

Reason: a majority of GF v2 projects is using Hudson + Maven / Ant for deployment. Most of the projects,
are not 100% Java EE compatible but can be deployed to GF v2 without any problems. The migration even
of such projects should be as smooth, as possible.

Hong Zhang added a comment - 28/Oct/09 12:50 PM

Taking the ownership of this. I will talk with Jerome to discuss the plan for this.

Downgrading it to P2 as it only happens for applications which are packaging in
an incompatible way defined by the spec.

The reason we did this clean up in v3 is we want to encourage the compatible
packaging by the spec.

abien added a comment - 28/Oct/09 01:01 PM

I understand your intention, but from customer perspective it causes a lot of trouble. I had to argue a lot
why an application worked on v2, but not on v3.

I would reverse the settings and provide a "JavaEE strict" mode, instead of setting the strict mode as

Hong Zhang added a comment - 28/Oct/09 01:02 PM

also adding bill and tim to the Cc

vince kraemer added a comment - 28/Oct/09 10:04 PM

A reference to the sections of the spec that are being violated would be very helpful.

Tim Quinn added a comment - 29/Oct/09 05:33 AM

Read EE 8.3.x. Near the end of each container-specific section is a statement
like this (this one is from the app client container section, EE 8.3.3):

"Components in the application client container must not have access to the
following classes and resources, unless such classes or resources are covered by
one of the rules above.

• Other classes or resources in the application package. For example, the appli-
cation client should not have access to the classes in other application client jar
files in the same ear file, nor should it have access to the classes in web appli-
cations or ejb jar files in the same ear file. "

The details vary among the different containers discussed in EE 8.3.x.

ludo added a comment - 29/Oct/09 07:46 AM

Adam, are you talking about App Client apps or EAR apps?

Can you add more info in the bug? Is is related to the class-path entry in the
webapp manifest inside an ear file?

abien added a comment - 29/Oct/09 11:57 AM


0. asadmin deploy --property compatibility=v2 foo.ear solved the problem
1. It was an EAR-only deployment
2. The app, as many others GF v2 apps were deployed in Java EE incompatible way - but worked perfectly
in GF v2. Maven was used to build the archive the application. It ignored the class-path entries in

The point is: it is hard to explain to the customers, why something worked with GF v2 but doesn't work
with GF v3 any more. Suggestion: GF v3 should behave as v2, and be optionally more restrictive.

vince kraemer added a comment - 29/Oct/09 12:04 PM

OK. So these are Java EE 5 apps... right?

Which part of the Java EE 5 spec were they violating?

If they were not violating the Java EE 5 spec, then we may have another way to decide how we want to treat
these apps, wrt to the compatibility flag...

Java EE 6 apps should default to 'strict'. Java EE 5 and J2EE 1.4 apps should default to 'compatible'...

Hong Zhang added a comment - 29/Oct/09 12:48 PM

I see. So it's a combination of NB/Maven which produces this type of ear packaging.

This is what EE5 spec defined for the bundled libraries:

Section 8.2.1 Bundled Libraries

2. A .ear file may contain a directory that contains libraries packaged in JAR
files. The library-directory element of the .ear file’s deployment descriptor
contains the name of this directory. If a library-directory element isn’t spec-
ified, or if the .ear file does not contain a deployment descriptor, the
directory named lib is used. An empty library-directory element may be used to
specify that there is no library directory.
All files in this directory (but not subdirectories) with a .jar extension
must be made available to all components packaged in the EAR file, including
application clients. These libraries may reference other libraries, either bun-
dled with the application or installed separately, using any of the techniques
described herein.

Bill Shannon added a comment - 29/Oct/09 01:47 PM

The app was non-portable. It depended on behavior that was not specified
by the Java EE 5 spec, and was not specified by the GlassFish documentation,
but which happened to work in earlier versions of GlassFish. This was not
a "Java EE 5 app". At best it was a "GlassFish v2 app". If there's a way
to know from the packaging of the app that it intends to depend on GlassFish
v2 behavior, we could use that to control the compatibility mode.

Really, this is a bug in GlassFish v2 that was fixed in GlassFish v3 to align
with a more complete specification of this behavior in Java EE 6.

vince kraemer added a comment - 29/Oct/09 02:17 PM


You seem to have ignored EE 8.2.1 (item 1), which is the way NetBeans configures
modules in an ear to reference bundled libraries.


there is plenty of evidence that an app might have deployed and run on v2...
the doctype of any sun-*.xml files
the doctype or version of any platform descriptors that are in the app
the absence of any Java EE 6 apis

You are right. This is a bug in our servers that appears to have been 'in
place' way back in the SJSAS 8.x days. We need to clean up our act. I am not
sure we want to force users to clean up their apps that are 'done' (not under
active development)

Tim Quinn added a comment - 29/Oct/09 02:44 PM

Just a minor point of clarification... The "allow visibility to the top-level
JARs" behavior, as I understand it, originated in Sun Java System App Server 8.x
– long before the library-directory concept appeared in Java EE 5 – and was an
implementation-specific way to accomplish essentially the same thing. As such
it seems to have started as a "feature," evolved into an "artifact" in the
GlassFish v2/Java EE 5 timeframe, and now seems to have graduated to "bug" status!

The Java EE 5 spec language listed approved ways of constructing references to
other JARs in the app but did not state that other ways of doing so were
forbidden or needed some explicit mechanism to do so. Java EE 6 has added this
restriction. (In each EE 8.3.x section is wording to this effect about
visibility of "other" JARs:

"Other classes or resources contained in the application package, and specified
by an explicit use of an extension not defined by this specification."


The --property compatibility=v2 feature is such an explicit, platform-specific
mechanism to which the spec refers. So would a possible addition to

IMO checking the DTD or schema versions declared in descriptors does not meet
the requirement in the EE 6 spec for an explicit extension provided by the app
server implementation.

vince kraemer added a comment - 29/Oct/09 03:21 PM


a little bit of further clarification... as far as I know, the 'standard'
NetBeans EAR project (based on ANT) has never leveraged 'The "allow visibility
to the top-level JARs" behavior' and has used the spec prescribed method (EE
8.2.1 (number 1) [in the Java EE 6 spec] of referencing other jars since that
method first appeared in the J2EE 1.4 spec...

Hong Zhang added a comment - 29/Oct/09 05:29 PM

Right, from the further information provided by the user, the NB (ant) is doing
the right packaging (item 1 of Section 8.2.1). The user case was NB (maven).

Hong Zhang added a comment - 31/Oct/09 07:23 PM

I have checked in the changes to add a compatibility element in the
sun-application.xml. This will provide a way for autodeploy/JSR88 to set the
compatibility flag to have v2 jar visibility behavior. I will keep the issue
open but downgrade to P3 for further enhancements on providing useful warning
messages for the cases where we could detect such packaging.

Hong Zhang added a comment - 10/Dec/09 07:15 AM

One more request that's related to this property came from this forum thread:!reply.jspa?messageID=375716

Seems in v2, we also added module root level jars to the classpath, we should
probably also provide this jar visibility through the property in v3.1

kenaiadmin made changes - 26/Nov/10 12:08 AM
Field Original Value New Value
issue.field.bugzillaimportkey 10496 42100
Tom Mueller added a comment - 06/Mar/12 09:56 PM

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Tom Mueller made changes - 06/Mar/12 09:56 PM
Fix Version/s not determined [ 11149 ]
Fix Version/s 3.1 [ 10968 ]
erpomata added a comment - 12/Jun/13 11:56 AM

Any new about this issue?