[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| RE: [wtp-dev] Mixing spec levels in EAR. Opinions? | 
Monday works for me.
Monday sounds better, so we (or me at least) don't forget 
what we have talked about during the weekend :-)
 
If there are no objections by others, can you send the 
telecon number and access code?
 
Thanks, Kaloyan
Yes sorry - I can do it tomorrow or 
Monday. Any preference? 
Thanks - Chuck
Rational Java EE 
Tooling Team Lead
IBM Software Lab - Research Triangle Park, 
NC
cbridgha@xxxxxxxxxx  Ph: 919-254-1848 (T/L: 444) 
  
  
    | From: | "Raev, Kaloyan" 
      <kaloyan.raev@xxxxxxx> | 
    | To: | <konstantin.komissarchik@xxxxxxxxxx>, "General discussion of 
      project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>, Chuck 
      Bridgham/Raleigh/IBM@IBMUS | 
    | Date: | 07/10/2008 01:24 PM | 
    | Subject: | RE: [wtp-dev] Mixing spec levels in EAR. 
      Opinions? | 
I think we have lost the thread 
here... Chuck, what is the soonest 
day you can organize a telecon in the  8:00 AM to 9:00 AM PDT 
timeslot?   Greetings, Kaloyan 
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] 
On Behalf Of Konstantin Komissarchik
Sent: Thursday, July 03, 
2008 7:17 PM
To: General discussion of project-wide or architectural 
issues.; Chuck Bridgham
Subject: RE: [wtp-dev] Mixing spec levels in 
EAR. Opinions?
Next week works ok for me and I suppose I can do 8 AM PDT if that's 
absolutely the only time that makes sense for everyone else.   - Konstantin 
  
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] 
On Behalf Of Raev, Kaloyan
Sent: Wednesday, July 02, 2008 9:21 
AM
To: Chuck Bridgham
Cc: General discussion of project-wide 
or architectural issues.
Subject: RE: [wtp-dev] Mixing spec levels in 
EAR. Opinions?
Hi Chuck,   Does this mean you can organize the telecon any day after 
Thursday from 8:00 AM to 9:00 AM PDT?   
Greetings, Kaloyan 
From: Chuck Bridgham [mailto:cbridgha@xxxxxxxxxx] 
Sent: Wednesday, July 02, 2008 4:58 PM
To: Raev, 
Kaloyan
Cc: General discussion of project-wide or architectural 
issues.
Subject: RE: [wtp-dev] Mixing spec levels in EAR. 
Opinions?
Hi, 
This Thursday doesn't work for me, but I can meet next week, any day 
at the same time mentioned. 
Thanks - Chuck
Rational Java EE Tooling Team Lead
IBM 
Software Lab - Research Triangle Park, NC
cbridgha@xxxxxxxxxx  Ph: 
919-254-1848 (T/L: 444) 
  
  
    | From: | "Raev, Kaloyan" 
      <kaloyan.raev@xxxxxxx> | 
    | To: | Chuck Bridgham/Raleigh/IBM@IBMUS, 
      "General discussion of project-wide or architectural issues." 
      <wtp-dev@xxxxxxxxxxx> | 
    | Date: | 07/02/2008 08:13 AM | 
    | Subject: | RE: [wtp-dev] Mixing spec levels in EAR. 
      Opinions? | 
It really 
seems we need a phone call... 
 
Chuck, I remember we had phone calls when 
discussing JEE5 more than year ago. Is it possible to use the same 
teleconference for this topic? 
As far as I remember the time slot was on Thursday, 8:00 
AM - 9:00 AM PDT. 
 
Greetings, 
Kaloyan 
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: Tuesday, 
July 01, 2008 7:13 PM
To: General discussion of project-wide or 
architectural issues.
Subject: 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 
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Raev, Kaloyan
Sent: Tuesday, July 01, 
2008 5:41 AM
To: General discussion of project-wide or architectural 
issues.
Subject: RE: [wtp-dev] Mixing spec levels in EAR. 
Opinions?
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 
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: Friday, 
June 27, 2008 7:14 PM
To: General discussion of project-wide or 
architectural issues.
Subject: RE: [wtp-dev] Mixing spec levels in 
EAR. Opinions?
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 
 
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim deBoer
Sent: Thursday, June 26, 2008 
10:07 AM
To: General discussion of project-wide or architectural 
issues.
Subject: Re: [wtp-dev] Mixing spec levels in EAR. 
Opinions?
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
_______________________________________________
wtp-dev mailing 
list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev