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
8 years, 10 months
Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ?
by Antonio Goncalves
Hi all,
I was playing with @SessionScoped beans... and wondered if @PostActivate,
@PrePassivate and @Remove would make sense in JSR 250 ?
At the moment these annotations belong to the javax.ejb package and are
only used in @Stateful EJBs. With CDI scopes, we end up with a few
"stateful" scopes (@SessionScoped, but also @ConversationScoped,
@ViewScoped...) so why not having the same functionality in CDI ?
@PreDestroy and @PostConstruct are already part of JSR 250. So why not
having @PostActivate and @PrePassivate as well so they could be used in
every bean ?
BTW, while I was playing with @SessionScoped beans, I asked Antoine to show
me how to remove a bean from the session. It's only a few lines of code,
but again, why not having a @Remove annotation that does that (the exact
same one of javax.ejb.Remove) ?
To summarize, why not taking some of those stateful EJB concerns back to
JSR 250 so they could be used anywhere ?
Any thoughts ?
--
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, 11 months
Possible cycle with ProcessBeanAttributes only for enabled beans
by Mark Struberg
The JavaDoc of ProcessBeanAttributes defines that ProcessBeanAttributes must only get fired for ENABLED beans:
"The container fires an event of this type for each enabled bean, interceptor or decorator deployed in a bean archive before registering the Bean object."
The test
org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.specialization.SpecializationTest
has a nice example
@Specializes class Charly extends
-> @Specializes class Bravo extends
-> class Alpha
Which ProcessBeanAttributes events would you except to get fired?
*) Alpha? No, because it's specialized away (5.1.2. Enabled and disabled beans).
*) Bravo? No, because it's specialized away as well, right?
*) Charly? Yes, because that's the only _enabled_ bean!
So far, so clear. But now comes the tricky part!
This test also has an Extension which observes ProcessBeanAttributes and disables Charly.
This means that finally Bravo is enabled, Charly disabled (is there actually a difference btw disabled and vetoed spec wording wise?)
The problem is now that we only know this AFTER the ProcessBeanAttributes for Charly got fired. And this introduces an ordering issue:
If the BeanAttributes for Bravo gets scanned BEFORE the ones of Charly, then we do not know YET that Charly will get disabled. Thus we fire the ProcessBeanAttributes for Bravo as well. But as we know that should not happen!
Otoh if Charly gets scanned first, then Bravo will not get processed.
Can you follow me?
LieGrue,
strub
9 years, 11 months
unproxyable constraint for ejbs
by Romain Manni-Bucau
Hi
org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelMissile
will make the container throw a DeploymentException cause of public
final void finalManeuver() which is final...but it is not in the EJB
API so CDI shouldn't even know it.
Is the test buggy -
org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelInterceptorTest?
IMO this has not to be tested since the EJB container already does it.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
9 years, 11 months
Ordering of AfterTypeDiscovery#getAlternatives() et al
by Mark Struberg
Hi!
If I have a
@Priority(100)
public class MyAlternative implements Foo ..
and
@Priority(101)
public class ABetterAlternative implements Foo ..
Then ABetterAlternative will finally be chosen.
This ordering can be changed via AfterTypeDiscovery#getAlternatives().
But the spec only says "returns the ordered list of enabled alternatives for the application.."
But it does NOT define in which sorting this list is ordered ;)
In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around.
I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec.
LieGrue,
strub
9 years, 11 months
Re: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ?
by Antonio Goncalves
I should have explained my PoV a bit better. I'm trying to take the EJB
services, extract them, see if they could benefit for other components, if
yes, in which spec could they go.
Today, there is less and less difference between :
@Stateful
@SessionScoped
public class MySessionBean {
@PersistenceContext
EntityManager em;
...
}
And :
@Transactional
@SessionScoped
public class MySessionBean {
@PersistenceContext
EntityManager em;
...
}
So I wonder if it would make sense to bother with @PostActivate,
@PrePassivate. I could see the benefit of @Remove though.
Antonio
On Sun, Dec 28, 2014 at 5:21 PM, arjan tijms <arjan.tijms(a)gmail.com> wrote:
> Hi,
>
> On Sun, Dec 28, 2014 at 1:52 PM, John D. Ament <john.d.ament(a)gmail.com>
> wrote:
>
>> EJBs work off of a pool of objects and these life cycle methods are
>> typically used (from the use cases I've dealt with them) to initiate or
>> destroy some end user data for the context in which they are used.
>>
>
> @PrePassivate/@PostActivate are used with @Stateful beans, which being
> unique instances are far less likely to be pooled. Pools are mostly used
> for @Stateless beans (if pools are used at all, the spec doesn't mandate
> those).
>
> Kind regards,
> Arjan Tijms
>
>
>
>>
>> I think you might be thinking of PostConstruct/PreDestroy which match to
>> the CDI/ManagedBean paradigm better. There's no pool of these objects
>> around, they simply get created and destroyed when done. For each of the
>> scopes you mentioned, I would use a PostConstruct/PreDestroy method to do
>> the same thing.
>>
>> John
>>
>> On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves <
>> antonio.goncalves(a)gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I was playing with @SessionScoped beans... and wondered if
>>> @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ?
>>>
>>> At the moment these annotations belong to the javax.ejb package and are
>>> only used in @Stateful EJBs. With CDI scopes, we end up with a few
>>> "stateful" scopes (@SessionScoped, but also @ConversationScoped,
>>> @ViewScoped...) so why not having the same functionality in CDI ?
>>> @PreDestroy and @PostConstruct are already part of JSR 250. So why not
>>> having @PostActivate and @PrePassivate as well so they could be used in
>>> every bean ?
>>>
>>> BTW, while I was playing with @SessionScoped beans, I asked Antoine to
>>> show me how to remove a bean from the session. It's only a few lines of
>>> code, but again, why not having a @Remove annotation that does that (the
>>> exact same one of javax.ejb.Remove) ?
>>>
>>> To summarize, why not taking some of those stateful EJB concerns back to
>>> JSR 250 so they could be used anywhere ?
>>>
>>> Any thoughts ?
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect, Java Champion and Pluralsight author
>>>
>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2 (http://www.apache.org/
>>> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>>> the provider waives all patent and other intellectual property rights
>>> inherent in such information.
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
9 years, 12 months
