+1
I don't think we should be specific about the exception type. For
example, if 2.x homes and/or remote are ignored by an EJB lite
implementation, a vendor may not bind the home and/or remote interface in
JNDI. An attempt to look them up would typically result in a naming
exception.
-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/05/2013 05:06 PM
Subject: [jsr345-experts] Re: Adding support for optional feature
groups
Would adding something like this work:
"A product may offer a deployment option to force deployment of
applications that use EJB features not supported by the product. Use of
these features must fail at runtime."
I can also be specific about the EJBException as the cause of the runtime
failure.
thanks,
-marina
On 3/5/13 2:07 PM, Jeremy Bauer wrote:
Re: 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?
Correct. This is does get messy. I can see where not having an MDB
available to process messages would be a problem for one configuration and
ignoring it is the desired behavior for another.
-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/05/2013 01:09 PM
Subject: [jsr345-experts] Re: Adding support for optional feature
groups
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".
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