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
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 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. 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"?
-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".
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