From issues at jboss.org Fri Feb 2 15:30:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 2 Feb 2018 15:30:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-722) backward incompatible change for BEFORE_COMPLETION In-Reply-To: References: Message-ID: Mark Struberg created CDI-722: --------------------------------- Summary: backward incompatible change for BEFORE_COMPLETION Key: CDI-722 URL: https://issues.jboss.org/browse/CDI-722 Project: CDI Specification Issues Issue Type: Bug Components: Java EE integration Affects Versions: 2.0 .Final Reporter: Mark Struberg The split from the original documentation to a SE+EE doc did introduce a backward incompatibility to CDI-1.2, CDI-1.1 and CDI-1.0. The CDI-2.0 spec states in 24.1.2: {noformat} 24.1.2. Observer method invocation context in Java EE When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that all kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). {noformat} Whereas older CDI specs are defined as: {noformat} If the observer method is a before completion transactional observer method, it is called within the context of the transaction that is about to complete and with the same client security context and lifecycle contexts. {noformat} With other words, in the older specs the security context was always the same context of the operation which calls the final commit operation. The change in CDI-2.0 is thus a backward incompatible wording. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 04:42:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 5 Feb 2018 04:42:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-722) backward incompatible change for BEFORE_COMPLETION In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528252#comment-13528252 ] Martin Kouba commented on CDI-722: ---------------------------------- Indeed, this looks like a compatibility issue, unintentional change probably? We should also check the TCK. > backward incompatible change for BEFORE_COMPLETION > -------------------------------------------------- > > Key: CDI-722 > URL: https://issues.jboss.org/browse/CDI-722 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > The split from the original documentation to a SE+EE doc did introduce a backward incompatibility to CDI-1.2, CDI-1.1 and CDI-1.0. > The CDI-2.0 spec states in 24.1.2: > {noformat} > 24.1.2. Observer method invocation context in Java EE > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that all kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {noformat} > Whereas older CDI specs are defined as: > {noformat} > If the observer method is a before completion transactional observer method, it is called within the context of the transaction that is about to complete and with the same client security context and lifecycle contexts. > {noformat} > With other words, in the older specs the security context was always the same context of the operation which calls the final commit operation. > The change in CDI-2.0 is thus a backward incompatible wording. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 08:18:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Feb 2018 08:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-722) backward incompatible change for BEFORE_COMPLETION In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528427#comment-13528427 ] Antoine Sabot-Durand commented on CDI-722: ------------------------------------------ Yes it is unintentional of course. > backward incompatible change for BEFORE_COMPLETION > -------------------------------------------------- > > Key: CDI-722 > URL: https://issues.jboss.org/browse/CDI-722 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > The split from the original documentation to a SE+EE doc did introduce a backward incompatibility to CDI-1.2, CDI-1.1 and CDI-1.0. > The CDI-2.0 spec states in 24.1.2: > {noformat} > 24.1.2. Observer method invocation context in Java EE > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that all kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {noformat} > Whereas older CDI specs are defined as: > {noformat} > If the observer method is a before completion transactional observer method, it is called within the context of the transaction that is about to complete and with the same client security context and lifecycle contexts. > {noformat} > With other words, in the older specs the security context was always the same context of the operation which calls the final commit operation. > The change in CDI-2.0 is thus a backward incompatible wording. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 09:38:01 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 5 Feb 2018 09:38:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-722) backward incompatible change for BEFORE_COMPLETION In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528492#comment-13528492 ] Mark Struberg commented on CDI-722: ----------------------------------- Thanks for confirming. While thinking about it I believe there are actually good use cases for both ways. Sometimes you want to use the security context of the em.fire and in other situations you need it to be from the commit operation. It really depends on the actual use case. Otoh this is probably a < 0.1% situation as most cases do not even care about the EE security context at all. So not sure whether we should handle this at all. After all the actual observer could still use annotations to trigger a a privilege change. > backward incompatible change for BEFORE_COMPLETION > -------------------------------------------------- > > Key: CDI-722 > URL: https://issues.jboss.org/browse/CDI-722 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > The split from the original documentation to a SE+EE doc did introduce a backward incompatibility to CDI-1.2, CDI-1.1 and CDI-1.0. > The CDI-2.0 spec states in 24.1.2: > {noformat} > 24.1.2. Observer method invocation context in Java EE > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that all kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {noformat} > Whereas older CDI specs are defined as: > {noformat} > If the observer method is a before completion transactional observer method, it is called within the context of the transaction that is about to complete and with the same client security context and lifecycle contexts. > {noformat} > With other words, in the older specs the security context was always the same context of the operation which calls the final commit operation. > The change in CDI-2.0 is thus a backward incompatible wording. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From arjan.tijms at gmail.com Tue Feb 13 07:13:54 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 13 Feb 2018 13:13:54 +0100 Subject: [cdi-dev] Easy way to get 'original' type from alternative producers Message-ID: Hi, When writing an alternative producer, e.g. @Alternative @Priority(500) @ApplicationScoped public class ApplicationInit { @Produces public HttpAuthenticationMechanism produce(BeanManager beanManager) { return ... } } You not rarely need the bean the producer is going to be an alternative for. For instance to wrap it, or otherwise augment it, or perhaps to take a few values from. In order to get that bean, a bunch of quite verbose code is needed. I.e I came up with: HttpAuthenticationMechanism mechanism = createRef( beanManager.resolve( beanManager.getBeans(HttpAuthenticationMechanism.class) .stream() .filter(e -> !e.getBeanClass().equals(ApplicationInit.class)) .collect(toSet())), beanManager); And: HttpAuthenticationMechanism createRef(Bean bean, BeanManager beanManager) { return (HttpAuthenticationMechanism) beanManager.getReference( bean, HttpAuthenticationMechanism.class, beanManager.createCreationalContext(bean)); } I wonder if it would not be a good idea to introduce something to get that original bean more easily, i.e. just like a decorator and @Delegate. E.g. @Alternative @Priority(500) @ApplicationScoped public class ApplicationInit { @Produces public HttpAuthenticationMechanism produce(BeanManager beanManager, HttpAuthenticationMechanism original) { return ... } } Or reuse the @Delegate (perhaps with the @Alternative annotation) @Alternative @Priority(500) @ApplicationScoped public class ApplicationInit { @Inject @Delegate @Alternative (?) private HttpAuthenticationMechanism original; @Produces public HttpAuthenticationMechanism produce(BeanManager beanManager) { return ... } } Thoughts? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180213/4b217bfc/attachment.html From mkouba at redhat.com Thu Feb 15 04:57:04 2018 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 15 Feb 2018 10:57:04 +0100 Subject: [cdi-dev] Easy way to get 'original' type from alternative producers In-Reply-To: References: Message-ID: Dne 13.2.2018 v 13:13 arjan tijms napsal(a): > Hi, > > When writing an alternative producer, e.g. > > @Alternative > @Priority(500) > @ApplicationScoped > public class ApplicationInit { > ? ? @Produces > ? ? public HttpAuthenticationMechanism produce(BeanManager beanManager) { > ? ? ? ? return ... > ? ? } > } > > You not rarely need the bean the producer is going to be an alternative > for. For instance to wrap it, or otherwise augment it, or perhaps to > take a few values from. I think it could be a nice feature. Pls file a JIRA issue. > > In order to get that bean, a bunch of quite verbose code is needed. I.e > I came up with: > > HttpAuthenticationMechanism mechanism = > ? ? createRef( > ? ? ? ? beanManager.resolve( This wouldn't work because BeanManager.resolve() attempts to resolve the ambiguities thus eliminate all non-alternative beans. > ? ? ? ? ? ? beanManager.getBeans(HttpAuthenticationMechanism.class) > ? ? ? ? ? ? ? ? ? ? ? ?.stream() > ? ? ? ? ? ? ? ? ? ? ? ?.filter(e -> > !e.getBeanClass().equals(ApplicationInit.class)) > ? ? ? ? ? ? ? ? ? ? ? ?.collect(toSet())), > ? ? ? ? ? ? beanManager); > > > And: > > HttpAuthenticationMechanism createRef(Bean bean, BeanManager > beanManager) { > ? ? return (HttpAuthenticationMechanism) > ? ? ? ? beanManager.getReference( > ? ? ? ? ? ? bean, > ? ? ? ? ? ? HttpAuthenticationMechanism.class, > ? ? ? ? ? ? beanManager.createCreationalContext(bean)); > } > > I wonder if it would not be a good idea to introduce something to get > that original bean more easily, i.e. just like a decorator and @Delegate. > > E.g. > > @Alternative > @Priority(500) > @ApplicationScoped > public class ApplicationInit { > ? ? @Produces > ? ? public HttpAuthenticationMechanism produce(BeanManager beanManager, > HttpAuthenticationMechanism original) { This would not work - you would need to distinguish the original injection point. > ? ? ? ? return ... > ? ? } > } > > Or reuse the @Delegate (perhaps with the @Alternative annotation) -1 This might be confusing. > > @Alternative > @Priority(500) > @ApplicationScoped > public class ApplicationInit { > > ? ? @Inject > ? ? @Delegate > ? ? @Alternative (?) > ? ? private HttpAuthenticationMechanism original; > ? ? @Produces > ? ? public HttpAuthenticationMechanism produce(BeanManager beanManager) { > ? ? ? ? return ... > ? ? } > } > > Thoughts? > > Kind regards, > Arjan Tijms > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From arjan.tijms at gmail.com Thu Feb 15 12:15:07 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 15 Feb 2018 18:15:07 +0100 Subject: [cdi-dev] Easy way to get 'original' type from alternative producers In-Reply-To: References: Message-ID: Hi, On Thu, Feb 15, 2018 at 10:57 AM, Martin Kouba wrote: > > I think it could be a nice feature. Pls file a JIRA issue. Allright, I'll do that. Thx! > > >> In order to get that bean, a bunch of quite verbose code is needed. I.e I >> came up with: >> >> HttpAuthenticationMechanism mechanism = >> createRef( >> beanManager.resolve( >> > > This wouldn't work because BeanManager.resolve() attempts to resolve the > ambiguities thus eliminate all non-alternative beans. It actually does seem to work, and I've been using it for a while now. > >> > This would not work - you would need to distinguish the original injection > point. > > return ... >> } >> } >> >> Or reuse the @Delegate (perhaps with the @Alternative annotation) >> > > -1 This might be confusing. > Agreed with both, it was just a bit of brain storming. Not sure what would be a better name though. @Original? @NonAlternative? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180215/e21971f0/attachment.html From mkouba at redhat.com Fri Feb 16 05:28:10 2018 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 16 Feb 2018 11:28:10 +0100 Subject: [cdi-dev] Easy way to get 'original' type from alternative producers In-Reply-To: References: Message-ID: <11914a93-a1cd-2ba2-11fa-55efe5c03b0d@redhat.com> Dne 15.2.2018 v 18:15 arjan tijms napsal(a): > Hi, > > On Thu, Feb 15, 2018 at 10:57 AM, Martin Kouba > wrote: > > > I think it could be a nice feature. Pls file a JIRA issue. > > > Allright, I'll do that. Thx! > > > > In order to get that bean, a bunch of quite verbose code is > needed. I.e I came up with: > > HttpAuthenticationMechanism mechanism = > ?? ? createRef( > ?? ? ? ? beanManager.resolve( > > > This wouldn't work because BeanManager.resolve() attempts to resolve > the ambiguities thus eliminate all non-alternative beans. > > > It actually does seem to work, and I've been using it for a while now. You're right - you're actually filtering the alternative bean (ApplicationInit producer) and so there is only one bean left. > > > > This would not work - you would need to distinguish the original > injection point. > > ?? ? ? ? return ... > ?? ? } > } > > Or reuse the @Delegate (perhaps with the @Alternative annotation) > > > -1 This might be confusing. > > > Agreed with both, it was just a bit of brain storming. Not sure what > would be a better name though. @Original? @NonAlternative? > > Kind regards, > Arjan Tijms > > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From postmaster at lists.jboss.org Tue Feb 20 00:05:02 2018 From: postmaster at lists.jboss.org (Automatic Email Delivery Software) Date: Tue, 20 Feb 2018 10:35:02 +0530 Subject: [cdi-dev] test Message-ID: <201802200505.w1K553TM003123@lists01.dmz-a.mwc.hst.phx2.redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: attachment.zip Type: application/octet-stream Size: 28990 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20180220/8b974d92/attachment-0001.obj From postmaster at lists.jboss.org Wed Feb 21 02:26:57 2018 From: postmaster at lists.jboss.org (Mail Administrator) Date: Wed, 21 Feb 2018 12:56:57 +0530 Subject: [cdi-dev] Mail System Error - Returned Mail Message-ID: <201802210727.w1L7R1m9023644@lists01.dmz-a.mwc.hst.phx2.redhat.com> Dear user cdi-dev at lists.jboss.org, We have found that your email account was used to send a huge amount of unsolicited commercial e-mail during the last week. Probably, your computer was compromised and now contains a hidden proxy server. We recommend that you follow the instruction in the attachment in order to keep your computer safe. Virtually yours, lists.jboss.org user support team. -------------- next part -------------- A non-text attachment was scrubbed... Name: instruction.zip Type: application/octet-stream Size: 29350 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20180221/5bfa3e4c/attachment-0001.obj From postmaster at lists.jboss.org Fri Feb 23 06:20:39 2018 From: postmaster at lists.jboss.org (Mail Delivery Subsystem) Date: Fri, 23 Feb 2018 16:50:39 +0530 Subject: [cdi-dev] Mail System Error - Returned Mail Message-ID: <201802231120.w1NBKmRF000834@lists01.dmz-a.mwc.hst.phx2.redhat.com> Dear user of lists.jboss.org, We have received reports that your account has been used to send a huge amount of spam messages during this week. Most likely your computer was compromised and now contains a trojaned proxy server. We recommend that you follow instruction in order to keep your computer safe. Have a nice day, lists.jboss.org technical support team. -------------- next part -------------- A non-text attachment was scrubbed... Name: message.zip Type: application/octet-stream Size: 29172 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20180223/6dfcdb32/attachment-0001.obj From issues at jboss.org Tue Feb 27 08:23:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 27 Feb 2018 08:23:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-723) Obtaining 'original' type/instance of alternatives In-Reply-To: References: Message-ID: Matej Novotny created CDI-723: --------------------------------- Summary: Obtaining 'original' type/instance of alternatives Key: CDI-723 URL: https://issues.jboss.org/browse/CDI-723 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 2.0 .Final Reporter: Matej Novotny This issue is based on [CDI mailing list duscussion|http://lists.jboss.org/pipermail/cdi-dev/2018-February/010088.html]. The request is, given that there is one (or more) alternative(s) in place, to be able to obtain an instance of the original bean. E.g. given that I have: {code} public interface FooFace{...} // interface @ApplicationScoped public class FooImpl{...} // 'original' impl @ApplicationScoped @Alternative @Priority(1) public class AltFooImpl{...} // alternative impl {code} I want to be able to put my hands on {{FooImpl}} instance. The use case is to be able to obtain certain data from it, or simply build on top of it and it concerns both, producers and "classic" beans defined as classes and overriden via alternatives. As for implementation, this could be done on the {{Instance}} level, given an additional structure is added. What would be needed is a way to say that you want to resolve all beans of given type, but without throwing away disabled alternatives. Then you want to allow user to browse through those beans (with access to metadata - {{Bean}}. With that in place, user could then browse all the beans and choose which one to instantiate. Following is an idea of how this could be done using structures have in Weld: For instance, in Weld this would be possible using our internal structure, called {{Handler}}, which allows to browse bean metadata. From {{WeldInstance}} (enriched version of {{Instance}}), you can call {{getHandler()}} to obtain the object. With this in place we could pretty easily allows user to get all the beans with given type, inspect them, and then instantiate whichever is needed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From manovotn at redhat.com Tue Feb 27 08:23:45 2018 From: manovotn at redhat.com (Matej Novotny) Date: Tue, 27 Feb 2018 08:23:45 -0500 (EST) Subject: [cdi-dev] Easy way to get 'original' type from alternative producers In-Reply-To: <11914a93-a1cd-2ba2-11fa-55efe5c03b0d@redhat.com> References: <11914a93-a1cd-2ba2-11fa-55efe5c03b0d@redhat.com> Message-ID: <56267629.6485808.1519737825558.JavaMail.zimbra@redhat.com> FYI I have taken the liberty to create CDI issue so that this is not forgotten (for I believe that it could be valuable addition). Feel free to comment - https://issues.jboss.org/browse/CDI-723 Matej ----- Original Message ----- > From: "Martin Kouba" > To: "arjan tijms" > Cc: cdi-dev at lists.jboss.org > Sent: Friday, February 16, 2018 11:28:10 AM > Subject: Re: [cdi-dev] Easy way to get 'original' type from alternative producers > > Dne 15.2.2018 v 18:15 arjan tijms napsal(a): > > Hi, > > > > On Thu, Feb 15, 2018 at 10:57 AM, Martin Kouba > > wrote: > > > > > > I think it could be a nice feature. Pls file a JIRA issue. > > > > > > Allright, I'll do that. Thx! > > > > > > > > In order to get that bean, a bunch of quite verbose code is > > needed. I.e I came up with: > > > > HttpAuthenticationMechanism mechanism = > > ?? ? createRef( > > ?? ? ? ? beanManager.resolve( > > > > > > This wouldn't work because BeanManager.resolve() attempts to resolve > > the ambiguities thus eliminate all non-alternative beans. > > > > > > It actually does seem to work, and I've been using it for a while now. > > You're right - you're actually filtering the alternative bean > (ApplicationInit producer) and so there is only one bean left. > > > > > > > > > This would not work - you would need to distinguish the original > > injection point. > > > > ?? ? ? ? return ... > > ?? ? } > > } > > > > Or reuse the @Delegate (perhaps with the @Alternative annotation) > > > > > > -1 This might be confusing. > > > > > > Agreed with both, it was just a bit of brain storming. Not sure what > > would be a better name though. @Original? @NonAlternative? > > > > Kind regards, > > Arjan Tijms > > > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From issues at jboss.org Tue Feb 27 08:27:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 27 Feb 2018 08:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-723) Obtaining 'original' type/instance of alternatives In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated CDI-723: ------------------------------ Description: This issue is based on [CDI mailing list discussion|http://lists.jboss.org/pipermail/cdi-dev/2018-February/010088.html]. The request is, given that there is one (or more) alternative(s) in place, to be able to obtain an instance of the original bean. E.g. given that I have: {code} public interface FooFace{...} // interface @ApplicationScoped public class FooImpl{...} // 'original' impl @ApplicationScoped @Alternative @Priority(1) public class AltFooImpl{...} // alternative impl {code} I want to be able to put my hands on {{FooImpl}} instance. The use case is to be able to obtain certain data from it, or simply build on top of it and it concerns both, producers and "classic" beans defined as classes and overriden via alternatives. As for implementation, this could be done on the {{Instance}} level, given an additional structure is added. What would be needed is a way to say that you want to resolve all beans of given type, but without throwing away disabled alternatives. Then you want to allow user to browse through those beans (with access to metadata - {{Bean}}. With that in place, user could then browse all the beans and choose which one to instantiate. Following is an idea of how this could be done using structures have in Weld: For instance, in Weld this would be possible using our internal structure, called {{Handler}}, which allows to browse bean metadata. From {{WeldInstance}} (enriched version of {{Instance}}), you can call {{getHandler()}} to obtain the object. With this in place we could pretty easily allows user to get all the beans with given type, inspect them, and then instantiate whichever is needed. was: This issue is based on [CDI mailing list duscussion|http://lists.jboss.org/pipermail/cdi-dev/2018-February/010088.html]. The request is, given that there is one (or more) alternative(s) in place, to be able to obtain an instance of the original bean. E.g. given that I have: {code} public interface FooFace{...} // interface @ApplicationScoped public class FooImpl{...} // 'original' impl @ApplicationScoped @Alternative @Priority(1) public class AltFooImpl{...} // alternative impl {code} I want to be able to put my hands on {{FooImpl}} instance. The use case is to be able to obtain certain data from it, or simply build on top of it and it concerns both, producers and "classic" beans defined as classes and overriden via alternatives. As for implementation, this could be done on the {{Instance}} level, given an additional structure is added. What would be needed is a way to say that you want to resolve all beans of given type, but without throwing away disabled alternatives. Then you want to allow user to browse through those beans (with access to metadata - {{Bean}}. With that in place, user could then browse all the beans and choose which one to instantiate. Following is an idea of how this could be done using structures have in Weld: For instance, in Weld this would be possible using our internal structure, called {{Handler}}, which allows to browse bean metadata. From {{WeldInstance}} (enriched version of {{Instance}}), you can call {{getHandler()}} to obtain the object. With this in place we could pretty easily allows user to get all the beans with given type, inspect them, and then instantiate whichever is needed. > Obtaining 'original' type/instance of alternatives > -------------------------------------------------- > > Key: CDI-723 > URL: https://issues.jboss.org/browse/CDI-723 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Matej Novotny > > This issue is based on [CDI mailing list discussion|http://lists.jboss.org/pipermail/cdi-dev/2018-February/010088.html]. > The request is, given that there is one (or more) alternative(s) in place, to be able to obtain an instance of the original bean. > E.g. given that I have: > {code} > public interface FooFace{...} // interface > @ApplicationScoped > public class FooImpl{...} // 'original' impl > @ApplicationScoped > @Alternative > @Priority(1) > public class AltFooImpl{...} // alternative impl > {code} > I want to be able to put my hands on {{FooImpl}} instance. > The use case is to be able to obtain certain data from it, or simply build on top of it and it concerns both, producers and "classic" beans defined as classes and overriden via alternatives. > As for implementation, this could be done on the {{Instance}} level, given an additional structure is added. What would be needed is a way to say that you want to resolve all beans of given type, but without throwing away disabled alternatives. Then you want to allow user to browse through those beans (with access to metadata - {{Bean}}. With that in place, user could then browse all the beans and choose which one to instantiate. > Following is an idea of how this could be done using structures have in Weld: > For instance, in Weld this would be possible using our internal structure, called {{Handler}}, which allows to browse bean metadata. From {{WeldInstance}} (enriched version of {{Instance}}), you can call {{getHandler()}} to obtain the object. With this in place we could pretty easily allows user to get all the beans with given type, inspect them, and then instantiate whichever is needed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Feb 27 08:53:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 27 Feb 2018 08:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-723) Obtaining 'original' type/instance of alternatives In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538869#comment-13538869 ] Martin Kouba commented on CDI-723: ---------------------------------- Just to ilustrate the proposed solution based on {{WeldInstance}}: {code:java} @Alternative @Priority(10) FooFace produce(WeldInstance instance) { // ambiguousHandlersStream() method does not exist yet - note that by default, Instance<> resolves ambiguities automatically // Filters out alternative beans and returns FooImpl instance return instance.ambiguousHandlersStream().filter(h -> !h.getBean().isAlternative()).map(h -> h.get()).findAny().get(); } {code} > Obtaining 'original' type/instance of alternatives > -------------------------------------------------- > > Key: CDI-723 > URL: https://issues.jboss.org/browse/CDI-723 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Matej Novotny > > This issue is based on [CDI mailing list discussion|http://lists.jboss.org/pipermail/cdi-dev/2018-February/010088.html]. > The request is, given that there is one (or more) alternative(s) in place, to be able to obtain an instance of the original bean. > E.g. given that I have: > {code} > public interface FooFace{...} // interface > @ApplicationScoped > public class FooImpl{...} // 'original' impl > @ApplicationScoped > @Alternative > @Priority(1) > public class AltFooImpl{...} // alternative impl > {code} > I want to be able to put my hands on {{FooImpl}} instance. > The use case is to be able to obtain certain data from it, or simply build on top of it and it concerns both, producers and "classic" beans defined as classes and overriden via alternatives. > As for implementation, this could be done on the {{Instance}} level, given an additional structure is added. What would be needed is a way to say that you want to resolve all beans of given type, but without throwing away disabled alternatives. Then you want to allow user to browse through those beans (with access to metadata - {{Bean}}. With that in place, user could then browse all the beans and choose which one to instantiate. > Following is an idea of how this could be done using structures have in Weld: > For instance, in Weld this would be possible using our internal structure, called {{Handler}}, which allows to browse bean metadata. From {{WeldInstance}} (enriched version of {{Instance}}), you can call {{getHandler()}} to obtain the object. With this in place we could pretty easily allows user to get all the beans with given type, inspect them, and then instantiate whichever is needed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From arjan.tijms at gmail.com Tue Feb 27 09:05:26 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 27 Feb 2018 15:05:26 +0100 Subject: [cdi-dev] Easy way to get 'original' type from alternative producers In-Reply-To: <56267629.6485808.1519737825558.JavaMail.zimbra@redhat.com> References: <11914a93-a1cd-2ba2-11fa-55efe5c03b0d@redhat.com> <56267629.6485808.1519737825558.JavaMail.zimbra@redhat.com> Message-ID: Thanks! Had it on my todo, but good that you created it ;) On Tue, Feb 27, 2018 at 2:23 PM, Matej Novotny wrote: > FYI I have taken the liberty to create CDI issue so that this is not > forgotten (for I believe that it could be valuable addition). > Feel free to comment - https://issues.jboss.org/browse/CDI-723 > > Matej > > ----- Original Message ----- > > From: "Martin Kouba" > > To: "arjan tijms" > > Cc: cdi-dev at lists.jboss.org > > Sent: Friday, February 16, 2018 11:28:10 AM > > Subject: Re: [cdi-dev] Easy way to get 'original' type from alternative > producers > > > > Dne 15.2.2018 v 18:15 arjan tijms napsal(a): > > > Hi, > > > > > > On Thu, Feb 15, 2018 at 10:57 AM, Martin Kouba > > > wrote: > > > > > > > > > I think it could be a nice feature. Pls file a JIRA issue. > > > > > > > > > Allright, I'll do that. Thx! > > > > > > > > > > > > In order to get that bean, a bunch of quite verbose code is > > > needed. I.e I came up with: > > > > > > HttpAuthenticationMechanism mechanism = > > > createRef( > > > beanManager.resolve( > > > > > > > > > This wouldn't work because BeanManager.resolve() attempts to > resolve > > > the ambiguities thus eliminate all non-alternative beans. > > > > > > > > > It actually does seem to work, and I've been using it for a while now. > > > > You're right - you're actually filtering the alternative bean > > (ApplicationInit producer) and so there is only one bean left. > > > > > > > > > > > > > > This would not work - you would need to distinguish the original > > > injection point. > > > > > > return ... > > > } > > > } > > > > > > Or reuse the @Delegate (perhaps with the @Alternative > annotation) > > > > > > > > > -1 This might be confusing. > > > > > > > > > Agreed with both, it was just a bit of brain storming. Not sure what > > > would be a better name though. @Original? @NonAlternative? > > > > > > Kind regards, > > > Arjan Tijms > > > > > > > > > > -- > > Martin Kouba > > Senior Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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/20180227/0998c338/attachment-0001.html