Hi Marina,
With a clarification in the 2.x group, what is in 17.1 will suffice.
Thanks!
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
Cc: Jeremy Bauer/Rochester/IBM_at_IBMUS
Date: 03/07/2013 03:58 PM
Subject: [jsr345-experts] Re: Adding support for optional feature
groups
On 3/7/13 12:49 PM, Jeremy Bauer wrote:
A comment regarding the EJB 2.x API group. Does/should implementation of
this group require support of 2.0 (and earlier?) deployment descriptors?
DD's prior to 2.0 did not provide local interfaces so it wouldn't make
sense to support them with EJB lite + 2.x API group unless the remote
group was also provided.
Yes. 2.x group is required to support all but CMP/BMP. I'll add Components
to it to be explicit. Only 3.x remote is a separate group to be able to
add it to the EJB Lite directly.
Section 17.1 currently reads:
Full EJB 3.2 implementations must support EJB 1.1, EJB 2.0, EJB 2.1, EJB
3.0, and EJB 3.1 deployment descriptors for applications written to
earlier versions of the Enterprise JavaBeans specification.
that's still correct.
EJB 3.2 Lite implementations must support EJB 3.0, and EJB 3.1 deployment
descriptors for applications written to the EJB 3.x versions of the
Enterprise JavaBeans specification.
yes.
Depending what is decided, this section may need an update. To keep
things simple, I think 2.x feature group should require pre 3.0 DD's to be
supported. If the server does not support features defined in a DD (ex.
remote), the app will fail to deploy or at runtime.
It should follow all other rules. I.e. if EJB Lite detects a remote EJB in
the DD, it should fail deployment (unless the product...).
Let me know if and how exactly to you want to change those statements if
you still don't think they are clear enough?
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To:
Cc: jsr345-experts_at_ejb-spec.java.net
Date: 03/06/2013 07:06 PM
Subject: [jsr345-experts] Re: Adding support for optional feature
groups
One quick note: I think I incorporated all requests (including packaging
and JAX-RS) in the updated table.
-marina
On 3/6/13 4:26 PM, Marina Vatkina wrote:
Experts,
The document on the spec download page named " EJB API Groups Definitions
and Rules with Embeddable Container" contains the updated version of the
16.1 section up-to the updated section 18.3.1 in the Embeddable Container
to make sure no one expects it to support .war files by default.
Unfortunately the FrameMaker didn't allow me to pick and choose the pages
to save as a pdf file. So the pages that you need to pay attention to are
2-4 (417-419) and the last one (435).
If you have any concerns, please say so ASAP.
thanks,
-marina
On 3/4/13 5:46 PM, Marina Vatkina wrote:
Experts,
I've written the rules for adding support for EJB features in addition to
the EJB Lite, i.e. to allow EJB containers some flexibility in-between EJB
Lite and EJB Full requirements. Those of you who were asking for it,
please do your part and review it asap.
The proposed changes are in the section 16.1 "EJB Lite" and the
corresponding part of the spec is available in the project download area
under the title " EJB API Groups Definitions and Rules".
The changes span only 3 pages, with the changes on the 1st page are to
remove "3.2" version from the text. I.e. it shouldn't take long to review
them ;)
The major changes are on the pages 2 and 3 (417 and 418). They include
replacing the table 19 “Required contents of EJB Lite and Full EJB API”
with a new table (also #19) called “EJB API Groups”. These are the groups
of features that can be supported only as a whole group, and EJB Lite
being just one of them. The section 16.1.1, “Support for Other EJB API
Groups in an EJB Lite Container” defines additional rules.
One side effect of this change is to remove fine-grained options for the
BMP/CMP support defined in Chapter 2 of the optional document (i.e.
BMP/CMP should be supported all or none).
Unless I hear otherwise in the next day or so (the PFD submission date is
this week), I'll include the proposed changes into the spec and adjust the
optional doc accordingly.
Best,
-marina