Hi Kevin,
Please see further below....
On 2/12/15 7:25 AM, Kevin Sutter wrote:
> Linda DeMichiel <linda.demichiel_at_oracle.com> wrote on 02/11/2015
> 07:44:07 PM:
>
> > From: Linda DeMichiel <linda.demichiel_at_oracle.com>
> > To: jsr366-experts_at_javaee-spec.java.net
> > Date: 02/11/2015 07:49 PM
> > Subject: [jsr366-experts] Re: [javaee-spec users] Re: Java EE 7 MR
> >
> > Hi Kevin,
> >
> > On 2/11/15 12:25 PM, Kevin Sutter wrote:
> > > Thanks, Linda. I missed this query from Bill. My preference is
> > > "B. Any class that also supports injection (table EE-5.1)" from Bill's
> > > original inquiry. Bill's note indicates that the responses to his
> > > inquiry were mixed between B and D. But, it looks like this MR is
> going
> > > with option
> > > "C. Any class in the application package (ear/war/jar file)"? Are we
> > > too late to re-open this discussion?
> > >
> >
> > Well, yes and no....
> >
> > This clarification was intended to resolve an ambiguity in the spec,
> > where some sections (specifically 8.5.2) indicated that all
> > classes that are part of the application package need to be
> > scanned, but others (e.g., 5.2.5) made reference to classes supporting
> > injection.
> >
> > We believe that option C is therefore the most consistent with the
> > intent of the spec, as well as the more straightforward to implement,
> > particularly since at deployment (before CDI kicks in) one may not be
> > able to easily identify what is or is not a CDI managed bean.
> >
> > -Linda
>
> Linda,
> Thanks for the background on the ambiguity. But, my preference would be
> to either leave the ambiguity as-is for this MR, or somehow indicate
> that Option B (any class that supports injection) is the "minimum"
> requirement. If you can't tell, we've been limiting our annotation
> processing to only those classes that support injection. We have a
> concern about the performance impact of this additional scanning. And,
> we have a concern about backwards compatibility -- items that
> accidentally skated by in the past may now be flagged by this additional
> annotation scanning. This change seems to be introducing too much
> impact for an MR. I would prefer that we wait for this type of change
> until Java EE 8.
>
> Thanks, Kevin
>
This isn't a new requirement in the spec. Section 8.5.2 already
requires this annotation scanning, and the RI already implements it.
We are clarifying what appears to be a weaker statement in section
5.2.5. The wording in section 5.2.5 is problematic in view of the
difficulty in determining what classes support injection. For
example, superclasses of the classes listed in table EE5-1 may request
injection. (Note that it not required that all such classes be
packaged in the same module as their component subclasses.) Any
managed bean supports injection. Any of the locations listed in
section 8.5.2 can be a bean archive (implicit or explicit). Even in
the case of an implicit bean archive, if CDI extensions are used, you
can't know that unannotated classes cannot be beans in view of CDI's
programmatic registration facility.
Given that all classes need to be scanned anyway to find the managed
bean classes, option B doesn't imply scanning fewer classes. It only
implies collecting less data during the scanning that has to be done
anyway. We are concerned that setting only a "minimum" requirement,
with unspecified behavior beyond that, will result in portability
problems for applications.
Note that if you are concerned about compatibility problems with
previously ignored annotations causing problems, the spec does allow
you to have a deployment option to ignore errors from unmapped
resources, which should allow such applications to be deployed
compatibly.
-Linda
> >
> >
> >
> >
> > >
> >
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> > > Kevin Sutter
> > >
> > >
> > >
> > >
> > >
> > > From: Linda DeMichiel <linda.demichiel_at_oracle.com>
> > > To: jsr366-experts_at_javaee-spec.java.net
> > > Date: 02/11/2015 01:58 PM
> > > Subject: [javaee-spec users] [jsr366-experts] Re: Java EE 7 MR
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > > Hi Kevin,
> > >
> > > It means any class in the ear/war/jar, depending on how the application
> > > is packaged. It does not include classes in external libraries.
> > >
> > > Please see
> > > https://java.net/projects/javaee-spec/lists/jsr366-experts/
> > archive/2015-02/message/1
> > > for further on this.
> > >
> > > -Linda
> > >
> > >
> > > On 2/11/15 11:49 AM, Kevin Sutter wrote:
> > > > Hi Antonio and Linda,
> > > > Does this "on any class in the application package" really mean "any
> > > > class"? Or, is this just trying to expand the current wording
> to also
> > > > include other component classes like CDI beans that are in the
> > > > application? I'm concerned about the implication of scanning every
> > > > class in the application for annotations.
> > > >
> > > >
> > >
> >
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> > > > Kevin Sutter
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
> > > > To: jsr366-experts_at_javaee-spec.java.net
> > > > Date: 02/11/2015 05:27 AM
> > > > Subject: [jsr366-experts] Re: [javaee-spec users] Java EE 7 MR
> > > >
> ------------------------------------------------------------------------
> > > >
> > > >
> > > >
> > > > Hi Linda,
> > > >
> > > > I like the "on any class in the application package." makes it
> clearer
> > > > and simpler.
> > > >
> > > > Thanks for that
> > > > Antonio
> > > >
> > > > On Mon, Feb 9, 2015 at 10:39 PM, Linda DeMichiel
> > > > <_linda.demichiel_at_oracle.com_
> <mailto:linda.demichiel_at_oracle.com>> wrote:
> > > >
> > > > We've been accumulating a few fixes to minor errors in the Java
> > > > EE 7 specification along with some clarifications that we've been
> > > > discussing recently in the group. We plan to submit these to
> the JCP
> > > > as part of the spec Maintenance process. I've attached a list
> of the
> > > > proposed changes below.
> > > >
> > > > Note that because these changes do not impact the RI or TCK, but
> only
> > > > update the current specification document, they do not define a new
> > > > spec version, but rather result in a "Rev A" of the Java EE 7
> > > > specification.
> > > >
> > > > I plan to submit these to the JCP at the end of the week to initiate
> > > > the Maintenance Review process. Please let me know before then if I
> > > > missed anything or if you have any comments.
> > > >
> > > > For your convenience, I have uploaded a draft of the spec
> > > > that includes the proposed changes to our project downloads area,_
> > > > __https://java.net/projects/javaee-spec/downloads_.
> > > > The changes are flagged with changebars in the relevant chapters.
> > > >
> > > > -Linda
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Antonio Goncalves
> > > > Software architect, Java Champion and Pluralsight author
> > > > _
> > > > __Web site_ <http://www.antoniogoncalves.org/> | _Twitter_
> > > > <http://twitter.com/agoncal>| _LinkedIn_
> > > > <http://www.linkedin.com/in/agoncal> | _Pluralsight_
> > > >
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> > > > _Paris JUG_ <http://www.parisjug.org/> | _Devoxx France_
> > > > <http://www.devoxx.fr/>
> > >
> > >
> >