Fwd: JSR-346 Public Review Draft
by Pete Muir
FYI, I submitted the PRD.
I'll push the api to maven central when the JCP confirm the PRD is posted.
Begin forwarded message:
> From: Pete Muir <pmuir(a)redhat.com>
> Subject: JSR-346 Public Review Draft
> Date: 26 October 2012 18:31:09 GMT+01:00
> To: spec-submit(a)jcp.org
>
>
>
> 1) Please see attached
> 2) 30 days
> 3)
>
> A. Does the specification include software codes
> in the following format:
> Binary : No
> Source (compilable) : No
> Javadocs : Yes
> B. Do the codes or the spec call on, contain, use
> or demonstrate encryption technology? No
>
> 4. Licensing is unchanged
> 5. 12 February 2013
> 6. Version: 1.1, Release Date: 15 March 2013, Spec Lead: Red Hat, Inc. 1801 Varsity Drive, Raleigh, North Carolina 27606. United States.
> 7.
>
> • The public can read the names of the people on the Expert Group (ie, not just JCP Members)
>
> http://jcp.org/en/jsr/detail?id=346
>
> • The Expert Group business is regularly reported on a publicly readable alias.
>
> http://lists.jboss.org/pipermail/cdi-dev/
>
> • The schedule for the JSR is publicly available, it's current, and I update it regularly.
>
> https://github.com/jboss/cdi/wiki
>
> • The public can read/write to a wiki for my JSR.
>
> https://github.com/jboss/cdi/wiki
>
> • I have a discussion board for my JSR and I regularly read and respond to posts on that board.
>
> http://lists.jboss.org/pipermail/cdi-dev/
>
>
> • There is an issue-tracker for my JSR that the public can read.
>
> http://issues.jboss.org/browse/CDI
>
> • I have spoken at conferences and events about my JSR recently.
>
> Yes, e.g JavaOne
>
> • I am using open-source processes for the development of the RI and/or TCK.
>
> Yes. https://github.com/weld & https://github.com/jboss/cdi-tck
>
> • The Community tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR.
>
> Yes
11 years, 6 months
[JBoss JIRA] Created: (CDI-132) Clarify which initial info AnnotatedType should contain
by Mark Struberg (JIRA)
Clarify which initial info AnnotatedType should contain
-------------------------------------------------------
Key: CDI-132
URL: https://issues.jboss.org/browse/CDI-132
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Mark Struberg
The spec is not exactly clear about the initial content of AnnotatedType.
When initially building the AnnotatedType (e.g. before handing it over to the Extensions) we need to pre-fill them with the info from the annotations from the classes.
Should this AnnotatedType:
1.) contain no annotations from superclasses?
2.) contain all annotations from superclasses?
3.) contain @Inherited annotations from superclasses?
I think the other questions already got cleared up in CDI-70:
Should AnnotatedType contain derived public? protected? private? methods/fields from a superclass?
Imo it should contain all information which would be available by manually parsing any annotations. In other words: it should be possible to completely modify or emulate annotations of a parsed type.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-18:
-------------------------
Fix Version/s: 1.1.PRD
(was: 1.1 (Proposed))
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Priority: Critical
> Fix For: 1.1.PRD
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-18:
------------------------------
Please review https://github.com/jboss/cdi/pull/129
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Priority: Critical
> Fix For: 1.1.PRD
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] Created: (CDI-123) Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification
by Richard Hightower (JIRA)
Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification
-----------------------------------------------------------------------------------------------------------------------------
Key: CDI-123
URL: https://issues.jboss.org/browse/CDI-123
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Concepts
Affects Versions: 1.1 (Proposed)
Reporter: Richard Hightower
Fix For: 1.1 (Proposed)
Using Seam's CDI XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification.
Annotations and Alternatives should always be the first line of offense for doing injection, decoration and interception. However, there are times when you want to configure things that don't fit well into this model. This is also useful for testing.
This is not to give up type safeness via annotations, but to have some additional flexibility.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
CDI site
by Pete Muir
I've asked Jason Porter to get together a site for CDI, similar to that which beanvalidation has - beanvalidation.org.
The idea is to take beanvalidation.org as a starting point:
* spec links
* news
* proposal
* roadmap
and add a couple more areas:
* a FAQ
* the CDI ref guide extracted from the Weld reg guide, with links to everyones tutorials for getting started with CDI
I'm working with Red Hat legal to register a domain name - I'm currently looking at cdi-spec.org, unless anyone objects.
If anyone wants to help out, then please poke Jason, or has ideas :-)
Pete
11 years, 6 months
Resolving CDI-129
by Pete Muir
All,
I suspect we aren't going to come to a consensus on CDI-129, which revolves around the question of whether @ApplicationScoped is per-WAR or per-EAR.
Therefore, I want to understand how the CDI community would like us to resolve the issue. We've already seen that an an open poll of the community has been indecisive (I'm unwilling to take such a small margin on this, as it's hard to know how representative a sample we took!). This, I think, leaves us with two options:
1) We take a vote in the EG, with one vote per company/organisation and one vote per individual member. Currently this is:
Organisations
-------------------
* Red Hat (Pete Muir)
* IBM (Joe Bergmark)
* Morocco JUG (Faissal Boutaounte) #
* Serli (Jerome Petit)
* Oracle (JJ Snyder)
Individuals
---------------
* Norman Erck #
* Rick Hightower
* Werner Keil
* Antoine Sabot-Durand
* Mark Struberg
* Daniel Sachse #
Note that George Gastaldi now works for Red Hat, so I've removed him from the voting list. I've also substituted Siva with JJ for Oracle.
If I have marked your name with a #, then it means I have not heard from you recently on CDI (either in person or on the EG), and I would appreciate a quick ping back to confirm you are active. If
(a) we take a vote, AND
(b) you have a # next to your name, AND
(c) I have not heard from you by the end of the vote period
then I will mark you as MIA, and your vote will be ignored when we tally votes. The simple way to address this is to send me a quick ping back, so that I hassle you when it comes to voting time :-)
2) We leave the issue as unresolved for CDI 1.1
If you have a preference for option (1) or option (2), then please say so!
Pete
11 years, 6 months
[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ]
Pete Muir resolved CDI-43.
--------------------------
Fix Version/s: 1.1.PRD
(was: 1.1 (Proposed))
Resolution: Done
Resolved
> Allow Extensions to specify the annotations that they are interested in
> -----------------------------------------------------------------------
>
> Key: CDI-43
> URL: https://issues.jboss.org/browse/CDI-43
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Assignee: Pete Muir
> Labels: FAQ
> Fix For: 1.1.PRD
>
>
> Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like:
> public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat)
> This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months