Hi Jeremy,
Thank you for reviewing it quickly.
On 3/5/13 10:46 AM, Jeremy Bauer wrote:
> Hi Marina,
>
> Thank you for adding this section to the specification. An great late
> addition. A couple of things -
>
> 1) Bullet: Except for the programmatic timers in the Persistent EJB
> Timer Service group, EJB Container must detect that an application
> depends on a feature that is not supported and fail deployment of the
> application.
>
> Minor: missing "the" before EJB container
added.
>
> Question/concern:
>
> This behavior was previously undefined for EJB Lite and may result in
> compatibility issues with existing implementations of EJB Lite. Let's
> say an application includes a bean with a @Remote interface, but a
> client never actually makes a remote call to the bean. A
> container/embeddable container implementation may have allowed the
> application to deploy and run without issue. With 1), the container
> would now be required to fail during application deployment.
I can see @Remote as being tricky. But then you can argue that you can
deploy an MDB or even a BMP and not use it, correct?
>
> I realize this was previously unspecified behavior, so it wouldn't be
> an explicit break in compatibility. I do believe there are
> features/groups that should fail to deploy (the use of automatic
> persistent timers) and others that could fail at runtime if a function
> in an unimplemented group is used. The problem is sorting through the
> various features and sifting through the combinations that fall into
> one category or another.
Yes, that's the problem. And the simpler the rules, the easier they are
for the users and the compatibility testing. But I'm also interested in
what others think...
> Singling out persistent timers is great because it eliminates that
> requirement from the MDB group and allows runtime rather than
> deployment failures for programmatic usage. I just wonder if we
> want/need to make exceptions for any other features? Rather than
> making it a hard deployment failure, we could consider making the
> behavior unspecified with the recommendation to fail during
> deployment. Other opinions? I know we don't have much time here, but
> I wanted to raise the concern.
>
> 2) Pg 418, bullet 7: To use a session bean written to the EJB 3.x AP -
> missing an "I"?
Fixed.
thanks,
-marina
>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net,
> Date: 03/04/2013 07:47 PM
> Subject: [jsr345-experts] Adding support for optional feature groups
> ------------------------------------------------------------------------
>
>
>
> 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
>
>
>
>