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_
> <http://java.net/projects/ejb-spec/downloads/download/p416-435.pdf>"
> 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_
> <http://java.net/projects/ejb-spec/downloads/download/p416-418.pdf>".
>
> 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
>
>
>
>
>
>