Lest anyone panic -- v2.1.1 is only changing the version of JDK that is
included in the HA release bundle. We will continue to build with and
support JDK 5. GF v2 will still implement Java
5. We presume
that some of our users will stick with JDK 5 and some will even
purchase Java for Business.
Sorry to jump into your
discussion thread, but I just wanted to make
you aware of a point that v2 is
switching to Java6 soon as Java5 goes EOL.
Not sure if that will make any
difference for v3 compatibility decisions
but since the "difference factor"
is what jdk is running, soon v2 and
v3 will both be shipping only
with Java6. So any logic programmed to
decide "Java5 = v2" while "Java6
= v3" may need to be "rethunk."
"v2.1.1 (v2.1-Patch#6) is going
to switch over to JDK 6, as JDK5 is going to be EOL'ed by Oct'09."
> If I were a
product owner, I would worry more about compatibility than
> spec
compliance. Anyway, that's a perspective difference I suppose. As a
> user, I prefer
#2 for the simple reason that my application is already
> fine with the
old visibility mode, why switch to a new mode for an
> existing app.
If I am writing a new app, I will certainly worry about
> portability and
hence I like the default being new mode.
>
> BTW, should we
make this an upgrade option? In any case, I suggest we
> make this
configurable and then we can just decide what is the default
> value based on
feedback.
>
> Finally, on a
second thought, I think we can rename the deploy option
> from
"jarVisibility" to something like "compatibility" so that we can
> use the same
flag any other compatibility issues. Then, we don't need
> yet another
option when move to next version. We can just have
>
--compatibility=v3 while running in v3++.
>
> What do people
think?
>
> Thanks,
> Sahoo
>
> Jerome Dochez
wrote:
>> this does
pose a number of significant compatibility issues. For
>> instance,
take an upgrade scenario, where applications (using that
>> behavior)
were deployed successfully will not be able to be upgraded
>> to V3
without requiring the usage of the flag.
>>
>> So we
seem to be stuck between two equally bad choices :
>> 1. we
don't run the upgrade redeployment with the flag and
>>
applications that were not flagged as using a deprecated or incorrect
>> feature
in V1/V2 will fail to be upgraded correctly.
>> 2. we run
with the flag which mean that we automatically upgrade and
>> run the
already deployed applications in an incompatible mode.
>>
>> Even in
normal re-deployment scenarios, applications will fail to
>> redeploy
with confusing errors (class not found exceptions most
>> likely)
while they deployed without an itch in v2. We seem to be
>> breaking
basic binary compatibility.
>>
>> To come
back to upgrade, as a product owner, I prefer 1), spec writers
>> will
prefer 2), users will be confused anyhow :)
>> votes ?
>>
>> jerome
>>
>> On Aug
18, 2009, at 11:47 AM, Bill Shannon wrote:
>>
>>>
Roberto (and Sahoo) are exactly right.
>>>
>>> The
version number in a deployment descriptor does *not* mean "this is
>>> the
version of the platform I'm expecting". It only means "this is the
>>>
version of the data file format you're about to read". Changing the
>>>
behavior of the platform based on the data file format is a mistake.
>>>
(Sadly, it's a mistake we've made a few times, but not one we should
>>> keep
making.)
>>>
>>>
Ideally, the CTS would test that the behavior is correct independent
>>> of
the deployment descriptor version number.
>>>
>>> Using
a deployment property to explicitly override the normal visibility
>>> rules
is allowed by the spec in this case, and is an appropriate
>>>
solution.
>>>
Providing a way to set this property in a product-specific deployment
>>>
descriptor would also be acceptable.
>>>
>>>
>>>
Roberto Chinnici wrote on 08/18/09 11:24:
>>>>
Typically we don't base container behavior on the version of the
>>>>
deployment descriptor present in an app or module.
>>>> It
seems to me that the "EE 6 restrictions" should be honored
>>>>
regardless of the descriptor version.
>>>> The
property in (3) could then be used to override the restrictions
>>>> for
apps that either don't have a descriptor or have an EE 5 one.
>>>>
--Roberto
>>>> Tim
Quinn wrote:
>>>>>
On the arch mailing list this past spring we started this
>>>>>
discussion but never closed on it. I followed up with a message on
>>>>>
that list on Aug. 7 but heard no response so I am moving the
>>>>>
discussion to this list and proposing a path forward that was
>>>>>
talked about in this week's v3 engineering meeting.
>>>>>
>>>>>
The Java EE 6 platform spec imposes stricter requirements than EE 5
>>>>>
on what JARs are to be visible to the various submodules of an
>>>>>
application. Sections EE 8.3.1 (web), 8.3.2 (EJB), and 8.3.3 (app
>>>>>
client) in particular list the JARs that submodules must, may, and
>>>>>
must not have access to.
>>>>>
In particular, and of particular interest to me, the spec mandates
>>>>>
that app clients must not have access to EJB JARs or other JARs in
>>>>>
the EAR unless references using the standard Java SE mechanisms
>>>>>
(extensions, for example) or the EE library-directory mechanism.
>>>>>
>>>>>
In GlassFish v2 and earlier, in addition to these JARs app clients
>>>>>
had access to EJB JARs and any JAR at the top-level of the EAR.
>>>>>
(This feature predated the Java EE 5 library-directory feature for
>>>>>
EARs.)
>>>>>
>>>>>
The proposal from today's engineering meeting is this:
>>>>>
>>>>>
1. GlassFish v3 will inspect the schema version referenced in the
>>>>>
application.xml (if present). If the schema is for EE 6 then
>>>>>
GlassFish v3 will honor the EE 6 restrictions. If the schema is
>>>>>
for EE 5 or earlier then GlassFish v3 will behave as GlassFish v2.
>>>>>
>>>>>
2. GlassFish v3 will treat an application with no descriptor as an
>>>>>
EE 6 app and will enforce the EE 6 restrictions.
>>>>>
3. Users might have existing apps which depend on the v2 behavior
>>>>>
and which do not have descriptors. To handle this case the deploy
>>>>>
command will support a property that overrides the schema version
>>>>>
(whether explicit as in #1 or defaulted as in #2).
>>>>>
We did not discuss how to name this property. Some options:
>>>>>
>>>>>
deploy ... --property jarVisibility=javaee5 (or javaee6)
>>>>>
[referring to the EE spec version]
>>>>>
>>>>>
deploy ... --property jarVisibility=v2 (or v3) [referring to the
>>>>>
GlassFish version]
>>>>>
>>>>>
>>>>>
Because part of the solution is to examine the schema version in
>>>>>
application.xml (which is related to the Java EE version) it might
>>>>>
be clearer to have the property refer to the EE version also.
>>>>>
>>>>>
>>>>>
Please respond to this message with feedback, concerns, questions,
>>>>>
etc. Ideally we would take care of this issue this week before the
>>>>>
soft code freeze (next Monday).
>>>>>
>>>>>
Thanks.
>>>>>
>>>>>
- Tim
>>>>>
>>>>>
---------------------------------------------------------------------
>>>
>>>
>>>
---------------------------------------------------------------------
>>
>>
>>
---------------------------------------------------------------------
>>
>
>
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net