Easy way to get 'original' type from alternative producers
by arjan tijms
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
6 years, 10 months
[JBoss JIRA] (CDI-723) Obtaining 'original' type/instance of alternatives
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-723?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-723:
----------------------------------
Just to ilustrate the proposed solution based on {{WeldInstance}}:
{code:java}
@Alternative
@Priority(10)
FooFace produce(WeldInstance<FooFace> 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....].
> 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)
6 years, 10 months
[JBoss JIRA] (CDI-723) Obtaining 'original' type/instance of alternatives
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-723?page=com.atlassian.jira.plugin.sy... ]
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....].
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....].
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....].
> 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)
6 years, 10 months
[JBoss JIRA] (CDI-723) Obtaining 'original' type/instance of alternatives
by Matej Novotny (JIRA)
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....].
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)
6 years, 10 months
Mail System Error - Returned Mail
by Mail Delivery Subsystem
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.
6 years, 10 months
Mail System Error - Returned Mail
by Mail Administrator
Dear user cdi-dev(a)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.
6 years, 10 months
test
by Automatic Email Delivery Software
6 years, 10 months
[JBoss JIRA] (CDI-722) backward incompatible change for BEFORE_COMPLETION
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-722?page=com.atlassian.jira.plugin.sy... ]
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)
6 years, 10 months
[JBoss JIRA] (CDI-722) backward incompatible change for BEFORE_COMPLETION
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-722?page=com.atlassian.jira.plugin.sy... ]
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)
6 years, 10 months
[JBoss JIRA] (CDI-722) backward incompatible change for BEFORE_COMPLETION
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-722?page=com.atlassian.jira.plugin.sy... ]
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)
6 years, 10 months
