Perfect. Added to the bullet about the failed deployment.
thanks,
-marina
On 3/6/13 12:51 PM, Jeremy Bauer wrote:
> +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>_
> <mailto:marina.vatkina_at_oracle.com>
> To: _jsr345-experts_at_ejb-spec.java.net_
> <mailto: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>_
> <mailto:marina.vatkina_at_oracle.com>
> To: _jsr345-experts_at_ejb-spec.java.net_
> <mailto: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
>
>
>
>
>
>