[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Antonio Goncalves commented on CDI-4:
-------------------------------------
[~martinkouba] There was a maintenance release during Java EE 7 for the [JSR 250|https://jcp.org/en/jsr/detail?id=250], it can be updated again on Java EE 8 if needed.
> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
Re: [cdi-dev] With the end of Java Config...
by Werner Keil
Pete/all
Thanks for the clarification. It seems, otherwise he would not have pointed
out the issue in the first place, Anatole is also not able even as a Co
Spec Lead to take a driving seat on that.
I am Co Spec Lead of JSR 363 - Unit of Measurement (which especially in the
SE implementation optimized for SE/EE 8+ seems like there are synergies for
a typesafe definition of config elements;-) ) so other than assisting one
or the other Spec Lead found for this I do not see reason to take more than
one Spec Lead responsibility at a time, otherwise, jut look at the misery
of JSR 310 or 107;-D
Are there any observers/experts here or in EE 8 that would feel like
helping lead such a JSR?
Anatole and I also spoke to CloudBees (a company you sure know well) and
there was general interest, but I recall they had slightly different views
on some things, but as EG Member both they and maybe other players (e.g.
Pivotal or someone from DeltaSpike both with an approach to config) would
be qualified EG Members or Co Spec Leads for this.
As you know it would be best if a true Individual who is self employed
(e.g. Antonio?;-)) did this, otherwise an employee of a company, even more
if they have something to do with Java could run into IP and patent
troubles, I talk from the experience in EC and IP WG of JSR 358;-)
Anybody willing and able to help?
I'll be at JavaZone next week, speaking with e.g. Arun or (EE EG Member)
Jeff Genender, so if there is no sound interest in this list, we can
certainly talk about it in Oslo, too.
Werner
On Fri, Sep 5, 2014 at 4:50 PM, Pete Muir <pmuir(a)redhat.com> wrote:
> I would just like to note that we definitely support the idea of a Config
> JSR. And we would provide strong EG representation, and help with RI/TCK.
> However we are unable to take a lead role in it right now, due to having
> many other things going on.
>
> On 5 Sep 2014, at 15:43, Werner Keil <werner.keil(a)gmail.com> wrote:
>
> > You got a point, but so far both Oracle and Red Hat dismissed the idea
> of a separate Config JSR. Anatole was in touch with both of them and either
> their resources or interest seemed to lack.
> >
> > It is quite a shamble, that e.g. JSR 107 already went down the path of a
> completely separate Config sub-system (
> https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cach...)
> while pruning other much more importent (especially for true EE 8 value)
> features like Transaction Support in line with JTA, etc.
> >
> > If CDI2 needed a config sub-system, too, we better avoid their mistake
> or (for EE 8 since it is considered for inclusion) look at ways this may
> work together in some unified way.
> > Whether it's a separate JSR or "Module" of CDI 2 I don't really care,
> but we must not fall into the same "Not invented Here" trap as Java SE did
> with all its redundant and bloated features like JavaFX having its own
> Date/Time same as java.util.Date (which aside from JSR 236 also is the only
> one relevant to EE, JDBC, etc.) or the extra package java.time.
> >
> > JCache already went in the wrong direction here, as it is final there is
> probably not a lot to do, but do we really want to end up with
> > - JCache-config
> > - CDI-config
> > - MVC-config
> > ...
> >
> > ??;-O
> >
> > Werner
> >
> > On Fri, Sep 5, 2014 at 4:24 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> > Send cdi-dev mailing list submissions to
> > cdi-dev(a)lists.jboss.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > or, via email, send a message with subject or body 'help' to
> > cdi-dev-request(a)lists.jboss.org
> >
> > You can reach the person managing the list at
> > cdi-dev-owner(a)lists.jboss.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of cdi-dev digest..."
> >
> >
> > Today's Topics:
> >
> > 1. [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event
> > observers (Martin Kouba (JIRA))
> > 2. Re: cdi-dev Digest, Vol 46, Issue 16 (Werner Keil)
> > 3. Re: With the end of Java Config... (John D. Ament)
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Fri, 5 Sep 2014 10:24:37 -0400
> > From: "John D. Ament" <john.d.ament(a)gmail.com>
> > Subject: Re: [cdi-dev] With the end of Java Config...
> > To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <
> CAOqetn8UrpdWEFV8LJJ57hJ+z-iAFNjEEzyqsfPXFUQutuqT8A(a)mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Agreed w/ Antonio. JAX-RS did the right thing by making MVC a separate
> > spec. While we can provide a way to wire up beans externally w/ an XML
> > DSL, I don't think we should get into the business of config
> properties,etc.
> >
> >
> > On Fri, Sep 5, 2014 at 10:08 AM, Antonio Goncalves <
> > antonio.goncalves(a)gmail.com> wrote:
> >
> > > One wise man* once said "EJB was a hype specification, we added too
> many
> > > things to it, it became bloated. The next hype specifications are
> JAX-RS
> > > and CDI, careful with them"
> > >
> > > Either we get this idea of "parts" right, or CDI will endup being
> bloated.
> > >
> > > Antonio
> > >
> > >
> > > *David Blevin
> > >
> > >
> > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand <
> > > antoine(a)sabot-durand.net> wrote:
> > >
> > >> Hi all,
> > >>
> > >> You may have followed the rise and fall of the Java Config JSR (
> > >>
> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-...
> > >> ).
> > >> Anatole in CC was leading this initiative and I proposed him to join
> us
> > >> and explore if some part of his late-JSR could be done in CDI.
> > >>
> > >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or
> > >> related solution. If we achieve to have a majority of specs to
> integrate
> > >> with CDI, our configuration solution would therefore become a
> configuration
> > >> system for all spec based on CDI 2.0.
> > >>
> > >> Antoine
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> cdi-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>
> > >> Note that for all code provided on this list, the provider licenses
> the
> > >> code under the Apache License, Version 2 (
> > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > >> provided on this list, the provider waives all patent and other
> > >> intellectual property rights inherent in such information.
> > >>
> > >
> > >
> > >
> > > --
> > > 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>
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider licenses the
> > > code under the Apache License, Version 2 (
> > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > > provided on this list, the provider waives all patent and other
> > > intellectual property rights inherent in such information.
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/2ab10644/at...
> >
> > ------------------------------
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> > End of cdi-dev Digest, Vol 46, Issue 17
> > ***************************************
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
9 years, 8 months
Re: [cdi-dev] With the end of Java Config...
by Werner Keil
You got a point, but so far both Oracle and Red Hat dismissed the idea of a
separate Config JSR. Anatole was in touch with both of them and either
their resources or interest seemed to lack.
It is quite a shamble, that e.g. JSR 107 already went down the path of a
completely separate Config sub-system (
https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cach...)
while pruning other much more importent (especially for true EE 8 value)
features like Transaction Support in line with JTA, etc.
If CDI2 needed a config sub-system, too, we better avoid their mistake or
(for EE 8 since it is considered for inclusion) look at ways this may work
together in some unified way.
Whether it's a separate JSR or "Module" of CDI 2 I don't really care, but
we must not fall into the same "Not invented Here" trap as Java SE did with
all its redundant and bloated features like JavaFX having its own Date/Time
same as java.util.Date (which aside from JSR 236 also is the only one
relevant to EE, JDBC, etc.) or the extra package java.time.
JCache already went in the wrong direction here, as it is final there is
probably not a lot to do, but do we really want to end up with
- JCache-config
- CDI-config
- MVC-config
...
??;-O
Werner
On Fri, Sep 5, 2014 at 4:24 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event
> observers (Martin Kouba (JIRA))
> 2. Re: cdi-dev Digest, Vol 46, Issue 16 (Werner Keil)
> 3. Re: With the end of Java Config... (John D. Ament)
>
> ------------------------------
>
> Message: 3
> Date: Fri, 5 Sep 2014 10:24:37 -0400
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: Re: [cdi-dev] With the end of Java Config...
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAOqetn8UrpdWEFV8LJJ57hJ+z-iAFNjEEzyqsfPXFUQutuqT8A(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Agreed w/ Antonio. JAX-RS did the right thing by making MVC a separate
> spec. While we can provide a way to wire up beans externally w/ an XML
> DSL, I don't think we should get into the business of config
> properties,etc.
>
>
> On Fri, Sep 5, 2014 at 10:08 AM, Antonio Goncalves <
> antonio.goncalves(a)gmail.com> wrote:
>
> > One wise man* once said "EJB was a hype specification, we added too many
> > things to it, it became bloated. The next hype specifications are JAX-RS
> > and CDI, careful with them"
> >
> > Either we get this idea of "parts" right, or CDI will endup being
> bloated.
> >
> > Antonio
> >
> >
> > *David Blevin
> >
> >
> > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand <
> > antoine(a)sabot-durand.net> wrote:
> >
> >> Hi all,
> >>
> >> You may have followed the rise and fall of the Java Config JSR (
> >>
> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-...
> >> ).
> >> Anatole in CC was leading this initiative and I proposed him to join us
> >> and explore if some part of his late-JSR could be done in CDI.
> >>
> >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or
> >> related solution. If we achieve to have a majority of specs to integrate
> >> with CDI, our configuration solution would therefore become a
> configuration
> >> system for all spec based on CDI 2.0.
> >>
> >> Antoine
> >>
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2 (
> >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual property rights inherent in such information.
> >>
> >
> >
> >
> > --
> > 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>
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/2ab10644/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 46, Issue 17
> ***************************************
>
9 years, 8 months
Re: [cdi-dev] cdi-dev Digest, Vol 46, Issue 16
by Werner Keil
Antonio/all,
I fully agree. Looking at some of the highly redundant stuff (like
improving and extending java.util.Calendar, beside adding JavaFX with its
own isolated Date/Time solution and an almost identical Duration type in
JSR 310, which itself is full of redundancies and bloating, adding ~2MB or
more to the JDK without any new business value that isn't archieved by the
other 3! Date/Time APIs JDK already has including FX) in Java SE 8, we must
get a better solution for CDI 2, even without Jigsaw or any JDK
modularization (where if done right, you could then chose to add JavaFX,
JSR 310 or other stuff or just leave the "bloatware" if your app doesn't
need it;-D)
JSRs like MEEP 8 (on the ME side) or 363 (also modular and portable across
both ME 8 and varous SE versions) demonstrated how this can work, and
Agorava, a "fallout" of JSR 357 using many aspects of CDI 1.x and
DeltaSpike already are great examples how this could work for CDI 2, as
well.
Regards,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Java
Godfather
Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social |
#DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
* JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member,
JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and
the Internet of Everything"
* JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC
Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or
FOE"
* JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC
Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps",
"JSR 363"
* Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany.
Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache
DeviceMap" (GER)
* ApacheCon Europe: 17-21 Nov 2014, Budapest, Hungary. Werner Keil, JCP EC
Member, Apache DeviceMap Committer will present "Apache DeviceMap"
On Fri, Sep 5, 2014 at 4:08 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Tools : Google Drive vs Asciidoc and Github (Pete Muir)
> 2. Re: Tools : Google Drive vs Asciidoc and Github (Mark Paluch)
> 3. Re: Tools : Google Drive vs Asciidoc and Github
> (Antonio Goncalves)
> 4. With the end of Java Config... (Antoine Sabot-Durand)
> 5. Re: Tools : Google Drive vs Asciidoc and Github (Thorben Janssen)
> 6. Re: With the end of Java Config... (Antonio Goncalves)
>
> ------------------------------
>
> Message: 6
> Date: Fri, 5 Sep 2014 16:08:03 +0200
> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Subject: Re: [cdi-dev] With the end of Java Config...
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CA+ZZq9-2mNdubTWztFM5kqLOi+AKRM4RLB0pcDY-NP5WKUVFPQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> One wise man* once said "EJB was a hype specification, we added too many
> things to it, it became bloated. The next hype specifications are JAX-RS
> and CDI, careful with them"
>
> Either we get this idea of "parts" right, or CDI will endup being bloated.
>
> Antonio
>
>
> *David Blevin
>
>
> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
>
> > Hi all,
> >
> > You may have followed the rise and fall of the Java Config JSR (
> >
> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-...
> > ).
> > Anatole in CC was leading this initiative and I proposed him to join us
> > and explore if some part of his late-JSR could be done in CDI.
> >
> > I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or
> related
> > solution. If we achieve to have a majority of specs to integrate with
> CDI,
> > our configuration solution would therefore become a configuration system
> > for all spec based on CDI 2.0.
> >
> > Antoine
> >
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> >
>
>
>
> --
> 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>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/a30fb658/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 46, Issue 16
> ***************************************
>
9 years, 8 months
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Martin Kouba commented on CDI-4:
--------------------------------
[~agoncal] {{javax.annotation.Priority}} has {{@Target(value=TYPE)}} so we can't use it for observer methods :-(
> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
Collaboration between @Inject 2.0 and CDI 2.0
by Antoine Sabot-Durand
Bob, Juergen,
The work on CDI 2.0 is starting this week. As we said before we would really like to collaborate with you on a true DI java standard.
I understand you’re both quite busy right now, but as we need to have some ideas of coming features in the new @Inject specification we’re proposing to do the first move.
So we’re planning to write a document providing feature we’d like to have in this new specification. We hope this doc will be a good helper to start discussion around the spec.
Again you’re welcome on the CDI EG or if don’t feel like going official with JCP on our Mailing List : https://lists.jboss.org/mailman/listinfo/cdi-dev <https://lists.jboss.org/mailman/listinfo/cdi-dev>
Thanks for your time
Antoine Sabot-Durand
———————————————
Twitter : @antoine_sd
CDI co-spec lead & eco-system development
Agorava tech lead
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-456:
-----------------------------------
Jozef NO IT DOES NOT!
beanclass -> Bean<T> is NOT 1:1 if you register different Bean<T> in each of the 3 WAR files.
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-458:
-------------------------------------
Fix Version/s: 2.0 (discussion)
> Give the possibility to deactivate an observer in ProcessObserverMethod
> -----------------------------------------------------------------------
>
> Key: CDI-458
> URL: https://issues.jboss.org/browse/CDI-458
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 (discussion)
>
>
> Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{(a)WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage.
> We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-458:
----------------------------------------
Summary: Give the possibility to deactivate an observer in ProcessObserverMethod
Key: CDI-458
URL: https://issues.jboss.org/browse/CDI-458
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Events, Portable Extensions
Affects Versions: 1.2.Final
Reporter: Antoine Sabot-Durand
Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{(a)WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage.
We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-456:
-------------------------------------
{quote}There are situations where the type of the class is not enough to determine the module.{quote}
As long as you use the right class as the bean class, which often is not the bean type, this works for producers and custom beans.
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
