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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] From: "Raev, Kaloyan" <[EMAIL PROTECTED]> To: "General discussion of project-wide or architectural issues." <wtp-dev@eclipse.org> 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=220929> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229893 <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 <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:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> www.sap.com P Save a tree - please do not print this email unless you really need to! _______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev <https://dev.eclipse.org/mailman/listinfo/wtp-dev>
_______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
