Re: [cdi-dev] Choosing a date for next CDI Face to Face meeting
by Werner Keil
+1
Depending on how soon that F2F would be, Vienna sounded OK. I am in
Northern Germany till late May, but then moving on to a more Central
project...
How many of you (I know at least Antoine will be there) come to DevoXX UK
btw.?
I have a speaking and Java track duty at DWX (Nuremberg also Central
Europe) in the same week, so I have to commute between those places after
the JCP EC F2F, but depending on who came to London on Tuesday, I'd be
there till that afternoon.
I know at least Anatole who has a talk on the Java track will be at DWX,
too. He just spoke in Vienna, so while Brno may not be too far from there,
it would require everyone outside Vienna or Prague to fly to either of
these airports first and take a bus or train ;-|
Werner
On Thu, Apr 16, 2015 at 2:02 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: Shutting down CDI Instances (Antonio Goncalves)
> 2. Re: Best way to specify for spec that CDI contexts should be
> available? (Antonio Goncalves)
> 3. Re: Choosing a date for next CDI Face to Face meeting
> (Antonio Goncalves)
> 4. Re: More about SE/EE splitting (arjan tijms)
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 16 Apr 2015 11:17:10 +0200
> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Subject: Re: [cdi-dev] Choosing a date for next CDI Face to Face
> meeting
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CA+ZZq9_+uHvRdJA6aNGXww5NE6PUBfWR4-NkquwAnTsUzVGKOQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> I'm catching up with emails, sorry... I have two questions :
>
> - why Brno ? It's quite a difficult place to go to (in terms of
> transports). If you want to stay in Central Europe, what about Vienna or
> Prague ?
> - why just one day ? If we do a face to face, why not target 2 days ? We
> could start work on a Friday morning, and end a Satuday evening. Again,
> that would be easier to do in Vienna or Prague as we could easily fly
> there
> on a Friday morning.
>
>
> My 2 cents
> Antonio
>
> On Thu, Mar 19, 2015 at 3:38 PM, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
>
> > Don't be shy. If you have concern with the date or other point let me
> know.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://cdi-development-mailing-list.1064426.n5.nabble.com/Choosing-a-date...
> > Sent from the CDI Development mailing list mailing list archive at
> > Nabble.com.
> > _______________________________________________
> > 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.
> >
>
> ------------------------------
>
> _______________________________________________
> 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 53, Issue 16
> ***************************************
>
9 years, 6 months
Shutting down CDI Instances
by John D. Ament
All,
In discussion today w/ Jozef, we found that the way of shutting down a
container in the proposed SE API precluded the notion that multiple
containers could be running. While we're not necessarily going to handle
multiple containers right now, we don't want to preclude the idea either.
With that said, there were three different approaches though up to handle
how to shutdown a launched container. it obivously would only work with an
SE booted container, but part of this does give a pointer in how we may
implement initialize.
Option 1 - Subclass CDI. The returned CDI instance when bootstrapped would
return this subclass of CDI that has shutdown capability.
Option 2 - Add method to CDI. Add the shutdown method to CDI directly, and
throw an exception if called in an EE environment.
Option 3 - Return a different object all together when initializing.
Return something else from initialize, e.g. CDIContext, which has a
shutdown method when you initialize. That class would also have a getter
for the CDI instance backing it.
Let us know your thoughts.
Thanks,
John
9 years, 6 months
Java SE / EE split, link to the generated spec
by Antoine Sabot-Durand
Hi all,
After a lot of do, undo, redo, I sent, this morning, a PR containing a first draft of this split.
To give an idea of the final result, the generated spec doc is available here : https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html <https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html>
The goal of this splitting is to have an EJB free version of the spec to provide an official Java SE support for CDI. It’s also the 1st step to introduce parts in the spec, should we decide to do it.
Thanks for your feedback, here, in the pull request or in the corresponding Jira ticket : https://issues.jboss.org/browse/CDI-160 <https://issues.jboss.org/browse/CDI-160>
Antoine
9 years, 6 months
Fwd: More about SE/EE splitting
by Antoine Sabot-Durand
You can also check the diff in the pull request : https://github.com/cdi-spec/cdi/pull/241/files <https://github.com/cdi-spec/cdi/pull/241/files>
> Le 16 avr. 2015 à 09:27, Antonio Goncalves <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com>> a écrit :
>
> Reading my emails upside down, just found the link : https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html <https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html>
>
> Antonio
>
> On Thu, Apr 16, 2015 at 9:25 AM, Antonio Goncalves <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com>> wrote:
> Antoine, I've lost track of this topic. Is the document somewhere ? Can we easily see the diffs ?
>
> Managed Beans are already confusing.... turning it to "bean" can be even more confusing.
>
> Antonio
>
> On Wed, Apr 15, 2015 at 5:08 PM, Pete Muir <pmuir(a)redhat.com <mailto:pmuir@redhat.com>> wrote:
>
> > On 15 Apr 2015, at 13:31, Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote:
> >
> > Hi all,
> >
> > Rethinking of this task and reading the feedback on this, I really think we should go step by step on this splitting.
> >
> > What I have produced here is a full extraction of EJB in the spec to put it in EE part.
>
> Yes, this is a great start.
>
> > There are still Java EE references in core with EL, JSF, Servlet.
>
> I’m least worried about EL, most about JSF and Serlet.
>
> >
> > The more problematic part is the Contexts chapter: hard to remove servlet ref without rewriting all...
> >
> > And yes, I did some rewording that could be no very nice.
> >
> > In some places I replaces "Managed Beans or Session Beans" by the generic term "bean”.
>
> This is definitely not ok, as you expanded the scope of the sentence to include built-in beans, producer methods, producer fields, and custom beans. I would suggest providing list of these changes, so we can review each one.
>
> > Java EE component was replaced by component (yes, I'm not sure it is very meaningful)
>
> I also think this is problematic. A Java EE component is a specific thing. I would suggest providing list of these changes, so we can review each one.
>
> >
> > In the EE part, I added changed all "session bean" occurrences by "EJB session bean”.
>
> Ok, I don’t think this is a problem.
>
> >
> > The step I see are:
> >
> > 0) Validate that we're all ok with the principle of splitting
> > 1) validate that all EJB references are removed from core
> > 2) Correct bad terminology that I introduced
> >
> > And then we should continue the splitting by rewriting the contexts chapter and EL references in Core.
>
> +1
>
> >
> > Antoine
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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/>
>
>
> --
> 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/>
9 years, 6 months
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Antoine Sabot-Durand reassigned CDI-4:
--------------------------------------
Assignee: Antoine Sabot-Durand (was: Pete Muir)
> 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: Antoine Sabot-Durand
> 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.11#6341)
9 years, 6 months
[JBoss JIRA] (CDI-160) Split specification into "core" and "Java EE integration"
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-160?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-160 started by Antoine Sabot-Durand.
------------------------------------------------
> Split specification into "core" and "Java EE integration"
> ---------------------------------------------------------
>
> Key: CDI-160
> URL: https://issues.jboss.org/browse/CDI-160
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Antoine Sabot-Durand
> Priority: Critical
> Fix For: 2.0 (proposed)
>
>
> In order to better support implementations of CDI such as Weld SE, Errai, and OpenWebBeans which are currently not certifiable by JSR-299 (as they don't implement any of the Java EE integrations) we should split the spec into core and Java EE integrations, and offer two modes within the TCK as well.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 6 months
Re: [cdi-dev] Specializing producer methods & qualifiers
by Werner Keil
Christian,
Here's a case that matches your @MyQualifier question in Agorava:
https://github.com/agorava/agorava-socializer/blob/develop/src/main/java/...
uses:
@Inject @LinkedInprivate NetworkUpdateService updateService;
This is the @LinkedIn "MyQualifier"
https://github.com/agorava/agorava-linkedin/blob/develop/agorava-linkedin...
It uses a Meta-annotation @ProviderRelated
https://github.com/agorava/agorava-core/blob/develop/agorava-core-api/src...
to declare the service provider (like "LinkedIn" or others) but no
@Inherited.
@Antoine, good luck with the tutorial at DevoXX France and CU soon,
Werner
On Tue, Apr 14, 2015 at 8:55 AM, <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. No meeting today (Antoine Sabot-Durand)
> 2. [JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for
> dependent bean instances not created by the same Instance object
> (Martin Kouba (JIRA))
> 3. Specializing producer methods & qualifiers (Christian Kaltepoth)
> 4. Re: Specializing producer methods & qualifiers (Jozef Hartinger)
> 5. Re: Specializing producer methods & qualifiers
> (Christian Kaltepoth)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 7 Apr 2015 14:53:22 +0200
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] No meeting today
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <DAB22B90-65CE-4B50-84EC-3A718DA040FC(a)sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
>
> I?ll be on Devoxx France rehearsal today (giving a 3 hrs university
> tomorrow) and won?t be available for the meeting.
>
> See you next week
>
> Antoine
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150407/95cc5f91/at...
>
> ------------------------------
>
> Message: 2
> Date: Thu, 9 Apr 2015 05:18:18 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-519) Instance.destroy() cannot be
> used for dependent bean instances not created by the same Instance
> object
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12567996.1428571044000.66471.1428571098459(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
> Martin Kouba created CDI-519:
> --------------------------------
>
> Summary: Instance.destroy() cannot be used for dependent bean
> instances not created by the same Instance object
> Key: CDI-519
> URL: https://issues.jboss.org/browse/CDI-519
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
>
>
> 5.6.1. The Instance interface:
> {quote}
> The method destroy() instructs the container to destroy the instance. The
> bean instance passed to destroy() should be *a dependent scoped bean
> instance*, or...
> {quote}
>
> I think this should be more obvious. E.g. this wouldn't work correctly
> even though it doesn't violate the spec:
> {code:java}
> @Dependent
> class Bar {
> }
> class Foo {
> @Inject
> Instance<Bar> instance;
> void ping() {
> instance.destroy(CDI.current().select(Bar.class).get());
> }
> }
> {code}
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.11#6341)
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 14 Apr 2015 06:13:01 +0200
> From: Christian Kaltepoth <christian(a)kaltepoth.de>
> Subject: [cdi-dev] Specializing producer methods & qualifiers
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <
> CAEXeC6yYV-NmJ35M0v8d8icjtM57Zw20EuF92Bq2jVc80EPpzQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hey all,
>
> I've a question regarding specializing qualified producer methods. It would
> be great to get your opinion on this.
>
> Imaging this producer method:
>
> public class MyProducer {
> @Produces
> @MyQualifier
> public Something produce() {
> // ...
> }
> }
>
> Now imagine the producer method is specialized like this:
>
> public class MyExtendedProducer extends MyProducer {
> @Override
> @Produces
> @Specializes
> public Something produce() {
> // ...
> }
> }
>
> Please not that I NOT added @MyQualifier to the specializing producer
> method.
>
> Now for this injection point:
>
> @Inject
> @MyQualifier
> private Something something;
>
> What is expected to happen according to the spec? Will the specialized
> producer be used or not?
>
> Thanks
>
> Christian
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150414/023eaca3/at...
>
> ------------------------------
>
> Message: 4
> Date: Tue, 14 Apr 2015 08:26:11 +0200
> From: Jozef Hartinger <jharting(a)redhat.com>
> Subject: Re: [cdi-dev] Specializing producer methods & qualifiers
> To: Christian Kaltepoth <christian(a)kaltepoth.de>,
> cdi-dev(a)lists.jboss.org
> Message-ID: <552CB303.1080904(a)redhat.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Christian,
>
> yes, the specializing producer inherits all the qualifiers of the
> specialized producer. Furthermore, if the specialized producer had
> defined a name, this would have been inherited as well (even without
> explicit declaration on MyExtendedProducer.produce()). See
>
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#direct_and_indirect_spec...
> for details.
>
> Jozef
>
> On 04/14/2015 06:13 AM, Christian Kaltepoth wrote:
> > Hey all,
> >
> > I've a question regarding specializing qualified producer methods. It
> > would be great to get your opinion on this.
> >
> > Imaging this producer method:
> >
> > public class MyProducer {
> > @Produces
> > @MyQualifier
> > public Something produce() {
> > // ...
> > }
> > }
> >
> > Now imagine the producer method is specialized like this:
> >
> > public class MyExtendedProducer extends MyProducer {
> > @Override
> > @Produces
> > @Specializes
> > public Something produce() {
> > // ...
> > }
> > }
> >
> > Please not that I NOT added @MyQualifier to the specializing producer
> > method.
> >
> > Now for this injection point:
> >
> > @Inject
> > @MyQualifier
> > private Something something;
> >
> > What is expected to happen according to the spec? Will the specialized
> > producer be used or not?
> >
> > Thanks
> >
> > Christian
> >
> >
> > --
> > Christian Kaltepoth
> > Blog: http://blog.kaltepoth.de/
> > Twitter: http://twitter.com/chkal
> > GitHub: https://github.com/chkal
> >
> >
> >
> > _______________________________________________
> > 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/20150414/25b037a6/at...
>
> ------------------------------
>
> Message: 5
> Date: Tue, 14 Apr 2015 08:55:39 +0200
> From: Christian Kaltepoth <christian(a)kaltepoth.de>
> Subject: Re: [cdi-dev] Specializing producer methods & qualifiers
> To: Jozef Hartinger <jharting(a)redhat.com>
> Cc: cdi-dev(a)lists.jboss.org
> Message-ID:
> <CAEXeC6yno=tr=
> rm2rfg5HDap8Aw7anV9jfatSioEhbckpabuGA(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Jozef,
>
> thanks a lot for your response. So if I read this correctly, the qualifier
> doesn't need to be annotated with @Inherited for this behavior. Is that
> correct?
>
> Christian
>
>
> 2015-04-14 8:26 GMT+02:00 Jozef Hartinger <jharting(a)redhat.com>:
>
> > Hi Christian,
> >
> > yes, the specializing producer inherits all the qualifiers of the
> > specialized producer. Furthermore, if the specialized producer had
> defined
> > a name, this would have been inherited as well (even without explicit
> > declaration on MyExtendedProducer.produce()). See
> >
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#direct_and_indirect_spec...
> > for details.
> >
> > Jozef
> >
> >
> > On 04/14/2015 06:13 AM, Christian Kaltepoth wrote:
> >
> > Hey all,
> >
> > I've a question regarding specializing qualified producer methods. It
> > would be great to get your opinion on this.
> >
> > Imaging this producer method:
> >
> > public class MyProducer {
> > @Produces
> > @MyQualifier
> > public Something produce() {
> > // ...
> > }
> > }
> >
> > Now imagine the producer method is specialized like this:
> >
> > public class MyExtendedProducer extends MyProducer {
> > @Override
> > @Produces
> > @Specializes
> > public Something produce() {
> > // ...
> > }
> > }
> >
> > Please not that I NOT added @MyQualifier to the specializing producer
> > method.
> >
> > Now for this injection point:
> >
> > @Inject
> > @MyQualifier
> > private Something something;
> >
> > What is expected to happen according to the spec? Will the specialized
> > producer be used or not?
> >
> > Thanks
> >
> > Christian
> >
> >
> > --
> > Christian Kaltepoth
> > Blog: http://blog.kaltepoth.de/
> > Twitter: http://twitter.com/chkal
> > GitHub: https://github.com/chkal
> >
> >
> >
> > _______________________________________________
> > cdi-dev mailing listcdi-dev@lists.jboss.orghttps://
> 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.
> >
> >
> >
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150414/289a422b/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 53, Issue 11
> ***************************************
>
9 years, 6 months
Specializing producer methods & qualifiers
by Christian Kaltepoth
Hey all,
I've a question regarding specializing qualified producer methods. It would
be great to get your opinion on this.
Imaging this producer method:
public class MyProducer {
@Produces
@MyQualifier
public Something produce() {
// ...
}
}
Now imagine the producer method is specialized like this:
public class MyExtendedProducer extends MyProducer {
@Override
@Produces
@Specializes
public Something produce() {
// ...
}
}
Please not that I NOT added @MyQualifier to the specializing producer
method.
Now for this injection point:
@Inject
@MyQualifier
private Something something;
What is expected to happen according to the spec? Will the specialized
producer be used or not?
Thanks
Christian
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
9 years, 6 months
[JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object
by Martin Kouba (JIRA)
Martin Kouba created CDI-519:
--------------------------------
Summary: Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object
Key: CDI-519
URL: https://issues.jboss.org/browse/CDI-519
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.2.Final
Reporter: Martin Kouba
5.6.1. The Instance interface:
{quote}
The method destroy() instructs the container to destroy the instance. The bean instance passed to destroy() should be *a dependent scoped bean instance*, or...
{quote}
I think this should be more obvious. E.g. this wouldn't work correctly even though it doesn't violate the spec:
{code:java}
@Dependent
class Bar {
}
class Foo {
@Inject
Instance<Bar> instance;
void ping() {
instance.destroy(CDI.current().select(Bar.class).get());
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 6 months
No meeting today
by Antoine Sabot-Durand
Hi all,
I’ll be on Devoxx France rehearsal today (giving a 3 hrs university tomorrow) and won’t be available for the meeting.
See you next week
Antoine
9 years, 6 months
