[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-dev] Mixing spec levels in EAR. Opinions?
|
I still haven't heard a viable argument for why this
restriction is necessary. Allowing ear facet version changes does not
completely address the scenario that I presented. In a large and complicated
app, the user may not be ready to upgrade the ear spec level. That may be quite
an undertaking. Regarding the relationship between facet version and descriptor
schema, anything other than strict 1-to-1 relationship can lead to all sorts of
problems in both WTP and adopter code. It should be considered an error case.
Sounds like we need a phone call.
- Konstantin
Tim, Konstantin, thank you for your comments.
I agree with Tim that the facet version of the EAR should
be considered as the max spec level of the modules that this EAR can include.
This sounds nice in terms of validation.
On the other side I agree with the scenario given by
Konstantin. At the moment the users really cannot upgrade an existing EAR 1.4 to
EAR 5 and add EE 5 modules to it.
So, the solution in this situation I see to be that we
allow upgrading the facet version of EAR projects. Then we can do a strict
validation/filtering based on the EAR's facet version and at the same time have
the Konstantin's scenario possible. How hard would it be to introduce this? I
even see two possible option:
1) upgrading EAR facet version without upgrading the
DD (should be quite simple)
2) upgrading EAR facet version and upgrading the
DD
Greetings,
Kaloyan
Here are my views on the subject...
Given that the spec is ambiguous, the question that should
be asked is "is there at least one runtime that supports this scenario"? If the
answer is yes for at least one runtime, then in order to follow WTP charter and
not preclude proper integration of that runtime with WTP, we have to take a more
allowing stance on this. There is indeed at least one runtime that has no
problem with this scenario. I just had someone verify that WLS does in fact
support it.
The situation is made worse by the fact that we still have
no support for spec level changes, so users can get stuck. The following
scenario is not that uncommon:
1. User has an existing j2ee 1.4 app.
2. User needs to add a new module.
3. User wants to take advantage of java ee 5 features in
new code.
We should not be getting in the way of this scenario. If
particular servers do not support this, then server adapters for those servers
can perform that validation and alert the user.
- Konstantin
Hi Kaloyan, Thank you for raising this issue. I agree we are
inconsistent in parts, and although we don't necessarily need to resolve all of
the issues immediately we should at least have a common definition of what is
'correct' and may eventually be supported by WTP. Among the IBM committers we generally agree with #2, but
have made an interesting distinction: the schema used by a DD is only a bottom
boundary on the spec level of the EAR or module. As an example, a '1.4' EAR that
contains an EJB 3.0 module is really just an EE 5 EAR (or EE 6.0 or ...) with an
older DD. Likewise, EJB 3.0 annotations within an EJB module is an indication
that the EJB is at least EE 5/EJB 3.0, even if the DD still points to the EJB
2.0 schema. If DD schemas and spec
API usage are just a bottom boundary, it means that there is nothing within the
contents of an EAR or module that can precisely determine its level. So how do
we tell if it is valid for a user to add an EJB 3.0 module to what currently
looks like a 1.4 EAR? Was it really an EE 5 EAR all along, do they want to
uplevel the EAR, or is the user simply making a mistake? The solution we came to is using facets. Facet versions
allow the user to tell us which spec level they expect an EAR/module to be at,
and gives us something to tool for and validate against. The versions are set on
project creation or on import based on what we initially find in the modules.
>From there, the facet version of an EAR determines the maximum spec level of
modules that can be added or which servers it can be run on, and validation can
show errors for invalid modules or if the DD points to a schema above the level
of the facet. If you agree with the
original distinction (that true EAR 1.4s can't hold EJB 3 modules, but the
schema used by the DD is only a bottom boundary on the spec level), then I think
you'll eventually come to the same conclusion we have. Please feel free to let
me know what you think and others can chime in, or we can discuss on one of the
WTP calls. Thanks,
Tim
deBoer
deboer@xxxxxxxxxx
| From:
| "Raev, Kaloyan"
<kaloyan.raev@xxxxxxx>
|
| To:
| "General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
| Date:
| 06/26/2008 09:04 AM
|
| Subject:
| [wtp-dev] Mixing spec levels in EAR.
Opinions? |
Hello,
I want to bring up again an issue
that was discussed some time ago in
Bugzilla. It is about mixing of spec
levels of EAR and included modules.
There are two bugs
related:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=220929
https://bugs.eclipse.org/bugs/show_bug.cgi?id=229893
Everybody agree that EAR with spec level X could include modules
with
spec level X or lower. Example: EAR 5 can include EJB 2.1.
But there
is no consensus of opinion on EAR with spec level X to include
modules with
spec level higher than X. Example: EAR 1.4 to include EJB
3.0. There are two
contrary opinions:
1. EAR 1.4 can include EJB 3.0
2. EAR 1.4
cannot include EJB 3.0.
The supporters of opinion 1 says that it is not
forbidden by the Java EE
spec.
The supporters of opinion 2 says that it
is (at least indirectly)
forbidden by the spec. This is because the contract
of the Java EE spec
says that a deployment module compliant with spec level X
must always be
able to deploy on an application server compliant with spec
level X. Now
let's look again at our example of EAR 1.4 including EJB 3.0.
EAR 1.4 is
a J2EE 1.4 deployment module and it is guaranteed by the spec that
it
will deploy on all J2EE 1.4 compliant servers. But if we try to
deploy
it on an J2EE 1.4 compliant app server, that is not at the same
time
Java EE 5 compliant, then our deployment will fail, because of
the
included EJB 3.0 module (which is Java EE 5 spec level).
At the
moment there is an inconsistency in several dialogs in WTP
regarding this
issue. For example the Java EE Module Dependencies
property page of an EAR
1.4 project filters Java EE 5 modules for
selection, while at the same time
the project creation wizard allows a
EJB 3.0 project to be added to an
existing EAR 1.4 project.
I suggest that we discuss this problem and
hope we will have an
agreement for WTP 3.0.1. I invite all application server
vendors
represented in this mailing list to express their support for
either
opinion 1 or opinion 2.
Greetings,
Kaloyan Raev
Eclipse
WTP Committer
<http://www.eclipse.org/webtools/people/person.php?name=raev>
Senior Developer
NW C JS TOOLS JEE (BG)
SAP Labs
Bulgaria
T +359/2/9157-416
mailto:kaloyan.raev@xxxxxxx
www.sap.com
P Save a tree - please do
not print this email unless you really need
to!
_______________________________________________
wtp-dev mailing
list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
