Getting injection point from Bean#create
by arjan tijms
Hi,
In a producer method it's trivial to get access to an InjectionPoint
instance representing the point where the value produced by the
producer will be injected.
When registering a Bean manually from an extension using
AfterBeanDiscovery#addBean, this is not immediately obvious.
After some fumbling with the CDI APIs I came up with the following
code that seems to work on both Weld and OWB (didn't test CanDI yet).
It uses a small "dummy" class, which is used to grab an InjectionPoint off:
In a Bean:
public Object create(CreationalContext<Object> creationalContext) {
InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
creationalContext
);
With InjectionPointGenerator being the following class:
public class InjectionPointGenerator {
@Inject
private InjectionPoint injectionPoint;
}
And resolve being the following method:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
As mentioned, while this seems to work, I wonder if it's the best approach.
Kind regards,
Arjan
7 years, 8 months
Choosing a date for next CDI Face to Face meeting
by Antoine Sabot-Durand
Hi Guys,
We’re planning to organize a new face to face meeting for CDI EG and community. The place will be in Brno (at Red Hat HQ in Czech Republic) and we’re planning to set it up on a Saturday to avoid loosing more than a day of work for you all.
As we plan to have this meeting for a whole day long you’ll probably have to arrive on Friday evening and leave on Saturday morning.
Please fill the following Doodle to help use choose the best date for this meeting:
http://doodle.com/ecvpshxceup8b278 <http://doodle.com/ecvpshxceup8b278>
Antoine
8 years, 5 months
Best way to specify for spec that CDI contexts should be available?
by arjan tijms
Hi,
In the Security EG many proposals that are currently being discussed depend
on CDI being available in authentication modules.
Low level authentication modules do not necessarily have to be beans
themselves, but they have to be able to programmatically pull beans from
the bean manager, in order to be able to delegate certain authentication
decisions to those.
Now if I'm not mistaken, CDI is most often initialized per request via a
ServletRequestListener (in a vendor specific way), so those obviously have
to be invoked before an authentication module is invoked (which is a
Servlet concern).
On the other hand, the CDI spec defines when the request scope, session
scope and application scope should be active, referencing other spec
artifacts there.
Furthermore, it seems the CDI 2.0 spec is also working on providing APIs
for initializing CDI, but does that also take into account the per request
initialization that CDI implementations currently do? Would this be
powerful enough for code in an authentication module to initialize CDI
itself, such that request- session- and application scoped beans can be
pulled from the bean manager?
And if the above would be possible, what would happen if an authentication
module initialized the per request bits of CDI, and then afterwards (within
the same request) the container would attempt to initialize CDI as it would
normally do for usage in Servlets and Filters?
So, what would be spec-wise and practically speaking the best way to
specify that CDI should be available in authentication modules?
Kind regards,
Arjan Tijms
8 years, 5 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
8 years, 5 months
async activation on observers, why not CompletableFuture
by Romain Manni-Bucau
Hi guys,
on async topic if I followed we are at the point where we are looking for
an activation on the observer side.
Since Java 8 has now CompletableFuture it would be great to use it. Today
the spec doesnt use observer returned values so it is mainly a bad practise
to have one even if not strictly forbidden - BTW never saw it in real
applications - plus spec is not compatible - not specified at all -
with CompletableFuture since it is a new API so we can use it as a marker.
This is quite interesting for few reasons:
1- we have our double activation
2- API is user friendly (observer is async and has an async signature)
3- open door for future async enhancements (hopefully not in CDI) with
composition of these observers
Only point I'm not sure is should these observers support sync events. I
don't see anything blocking to do it but can have missed something.
wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
8 years, 6 months
No meeting today
by Antoine Sabot-Durand
Hi all,
I have to cancel the meeting today for personal reason. Let’s continue the discussion on SE and async on ML.
Antoine
8 years, 6 months
Previously on "Double end async events activation"
by Antoine Sabot-Durand
Hi all,
This mail is quite long, but if you want to catch up on this double end activation for async event and bring your help on this point, you should take the 10 mn to read it and make your feedback. We’ve been talking of this for more thant on month now, so it’s normal that reflection and proposition take a few lines to synthesize
Discussion is going back to solution avoiding this double activation stuff for async event. To avoid explaining again why we should care and the solution we already explore here is a small wrap up of previous episodes :
1) Why is it important to take time on this?
Some of you may find we already spend too many time on this question, but remember. Async events are the 1st requested stuff from the community. It has been asked for a long time (Jira ticket is CDI-4). We didn’t provided a solution for CDI 1.1 so now people are waiting this feature and they probably hope it’ll be nicely designed.
To make short : if we don’t deliver users will be very disappointed, if we propose a lousy solution people will be very critic. I know that it’s better to not deliver than delivering something we are not happy with, but we really should be careful here
2) Why this double activation is needed?
For the producer (fire()) side it’s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there’s no debate on fireAsync()
On the Observer side, the reason is for backward compatibility. CDI events are a great way to cross boundary of our own code and activate unknown code at runtime in another piece of the app (another jar) that we don’t own. This other code can be a framework, a code developed by an other team in a big project or a legacy jar that we don’t want to touch.
Imagine the following use cases (all code running on CDI 2)
a) I’m compiling in CDI 1.x and one of the Jar (framework for instance) already migrated to CDI 2.0 firing async event where it use to fire sync events. Without activation on the observer side, I have all the chance to see my observer break. And if I decide to upgrade to CDI 2.0 I must have a way to activate / deactivate async call on given observers
b) I’m compiling in CDI 2.0 but use jar1 in CDI 1.0 and jar2 in CDI 2.0 coming from other teams. jar2 and jar1 are old related piece of code communicating the event. The guys in jar2 had time to migrate to CDI 2.0 and switch most fire() to fireAsync(). Observer in jar1 will be called asynchronously if the default is to have async activated for all observer.
I agree that these example looks like corner case but the side effect will be that no framework developper will switch to fireAsync() to prevent these issues and we’ll have an adoption problem.
More than that as we are designing a Java EE specification we are committed to backward compatibility and cannot change behavior of old code, like it would do
3) Implementing this observer activation
I’m listing here all the solution to deal with this requirement. For some of them I’ll add the reason we won’t adopt it or my feeling about it
a) Adding or using an @Async annotation :
@Async
public void myObserver(@Observes Object payload) {}
Personally I don’t want to add @Async to or @Asynchronous to CDI, it feels too much like an EJB-ification of the spec. If we go that way we should work to add this to Commons Annotation (simpler for CDI SE) or concurrent utilities (more consistent but not CDI SE friendly since we’ll have to get this dependency in SE). As we’ll already have to wrk on Commons Annotation for @Priority (allowing it on parameter for event ordering), it could make sens to focus our effort here.
This @Async annotation could be used for async operation if we decide to add this support to CDI.
The downside of this annotation is the confusion it can bring to people thinking that it will be sufficient to have an Async observer. The second objection is the confusion if we decide to not add async support operation in CDI (since it’s nearly out of the bow in Java 8). Some people won’t understand why @Async is used only on event
b) Having an @AsyncSupported annotation
@AsyncSupported(true)
public void myObserver(@Observes Object payload) {}
An observer without this annotation will be considered having @AsyncSupported(false) by default
Very similar to previous solution but rather different semantically. It doesn’t give the impression that it’s activating async behavior but it allows it. The boolean value (true by default) could be a solution if we find a nice way to activate async observer by default for our jars (code we own) and provide an opt out solution for the few observer that wouldn’t support it.
Personally I don’t have issue to add this annotation to CDI since it’s more configuration than activation
c) Adding a member to @Observes
public void myObserver(@Observes(asyncSupported=true) Object payload)
The good part of it is that it prevent us to add a new annotation. The major drawback is linking issue with oCDI 1.x code (with old @Observes) running on CDI 2.0. to my knowledge, nobody tested that so far but anyway it’s a risk.
d) Add an @ObserveAsync annotation
public void myObserver(@ObserveAsync Object payload) {}
As we have backward compatibility issue, introducing a brand new type of observer instead of adding annotation on observer or modifying existing @Observes annotation, could be an idea. We could imagine having specific async config in this annotation (scope to propagate if we decide to support this feature).
The main downside of this is the introduction of another annotation to observe event and the confusion for user when using fire() and waiting @ObserveAsync event launch asynchronously
4) What about changing default behavior for the local jar?
Idea launched by some of us. We could extend the chosen scenario by activating AsyncSupport by default on all observer on the current jar (BDA). Since the main backward compatibility issue is linked to have different CDI jar from different owners and version we could give local control to the user for his own code and jars.
That could be done in beans.xml like we did for bean-discovery with an async-event attributes for instance or in code by a config annotation or event in extension (but we probably should expose the BDA concept in SPI if we go that way…)
5)Conclusion:
Now you have the whole picture. If I missed things, tell me. If you like an idea please tell it, if you have a new idea or a different POV, feel free to speak.
Thanks for reading.
Antoine
8 years, 6 months
Some more thoughts on async events
by José Paumard
Hi all,
We had many discussions on this very hot topic. We really need to come with
a good pattern, since a lot of people are expecting async features in CDI
2.0.
So far, we have a fireAsync(...) on the firing side and an opt-in element
on the observer side, to prevent accidental async call of an observer that
needs to be called in the context of a transaction (for instance).
Having to add this opt-in element on all our legacy observers will be very
tedious, so we need to come with a better pattern here.
We could add some information in the beans.xml, that would affect all the
observers of the bean archive. Something that would tell "this bean archive
globally supports asynchronous calls", that would act as a global opt-in.
Then we also need a mean to opt-out observers one by one, because we'll
have to deal with exceptions to this global rule.
Of course it could be done in the other way round: a global opt-out (bean
archive-wise) and individual opt-ins.
If there is no beans.xml, or a beans.xml without this information, the
default behavior would be "asynch is not supported" for backward
compatibility reasons.
This individual opt-in / opt-out then becomes an override to a global rule
set in the beans.xml, or defaulted to "async not supported". It can be
expressed in the beans.xml itself, or with annotations on the observers. To
deal with the potential incompatibility of adding an attribute to the
existing @Observes annotation, we could propose a new annotation, something
like @AsyncSupported(true) for instance.
José
--
8 years, 6 months
Re: [cdi-dev] Shutting down CDI Instances (John D. Ament)
by Werner Keil
All,
Especially if it was only relevant to some "profile" of CDI or environment
like SE, I'd say
+1 for Option 1.
It sounds more modular to me, e.g. this sub-class may only appear in a
certain module of CDI 2 and above (even more vital when you think SE 9+ and
Jigsaw;-)
Cheers,
Werner
On Wed, Mar 25, 2015 at 7:14 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. JavaLand (Thorben Janssen)
> 2. Re: JavaLand (Mark Struberg)
> 3. Today's meeting --> Focus on Java SE (Antoine Sabot-Durand)
> 4. Shutting down CDI Instances (John D. Ament)
> 5. Some more thoughts on async events (Jos? Paumard)
> 6. Re: Some more thoughts on async events (Mark Struberg)
> 7. Re: Some more thoughts on async events (Antoine Sabot-Durand)
>
>
> ----------------------------------------------------------------------
>
> Message: 4
> Date: Tue, 24 Mar 2015 18:00:00 +0000
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: [cdi-dev] Shutting down CDI Instances
> To: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAOqetn_wThUpYSb_2D+VTBaq3MAd4MVn6FqX9aHa444XkvM9Yg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150324/096f96d5/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 52, Issue 82
> ***************************************
>
8 years, 6 months