users@jersey.java.net

Re: [Jersey] How to make CDI/Weld work with jersey outside webapp with glassfish?

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 16 Apr 2010 11:52:35 +0200

On Apr 16, 2010, at 3:24 AM, Greg Beams wrote:

> Hi.
>
> Just a quick note to say that in Tomcat the BeanManager is in JNDI
> at java:comp/env/BeanManager. By changing the JNDI lookup in the
> JCDIComponentProviderFactory class (and by annotating your resource
> classes with javax.annotation.ManagedBean) injection should work.
>

One can avoid modifying the JCDIComponentProviderFactoryInitializer by
doing the following in an extension Application/ResourceConfig or by
extending ServletContainer:

   Object beanManager = ic.lookup("java:comp/env/BeanManager");
   rc.getSingletons().add(new
JCDIComponentProviderFactory(beanManager));

Note that JCDIComponentProviderFactory is in the impl package so could
change or go away. Let me know if you think this should be moved to
the public API.

Paul.

> (You also have to put the weld-tomcat-support jar in tomcat outside
> of your webapp)
>
> Greg.
>
> ----- Original message -----
>> Hi Morten,
>>
>> Currently CDI integration is only supported as specified for Java
>> EE 6.
>>
>> CDI integration outside of Java EE 6 is not specified and is specific
>> to a CDI implementation.
>>
>> So i am guessing the bootstrapping for Weld in an SE environment is
>> different to that specified for Java EE 6.
>>
>> I do not have time to investigate how to get Weld and Jersey to work
>> together in SE but i can help you if you are willing to do more of
>> the
>> investigation work.
>>
>> You are on the right track to look at JCDIComponentProviderFactory.
>> This requires initialization with the
>> JCDIComponentProviderFactoryInitializer. For Java EE 6 environments
>> it
>> looks up the CDI BeanManager using the JNDI name "java:comp/
>> BeanManager".
>>
>> In addition Jersey registers a CDI extension, JCDIComponentExtension,
>> that caches ProcessInjectionTarget instances. This class is declared
>> in META-INF/services/javax.enterprise.inject.spi.Extension. When the
>> JCDIComponentProviderFactory is created it obtains the cached
>> ProcessInjectionTarget instances and then adapts the InjectionTarget
>> such that Jersey can perform injection.
>>
>> Paul.
>>
>>
>> On Apr 4, 2010, at 6:48 PM, Morten wrote:
>>
>>> I have been able to make Jersey work fine with CDI (Weld) when
>>> deployed as part of a webproject (war file) in glassfish 3.0. To do
>>> this I just had to annotate my jersey controllers with CDI
>>> annotations as noted on this newsgroup.
>>>
>>> However, I have problems when I try the same outside a
>>> webapplication (and outside glassfish container). In particular, I
>>> have problems having CDI resources injected into jersey controllers
>>> under a simple Weld SE command line application that has an embedded
>>> Grizzly in it (i.e. Java SE app - not Java EE app).
>>>
>>> I did find a class JCDIComponentProviderFactory that I tried to
>>> provide to GrizzlyServerFactory.create but it does not work as it
>>> gives a lot of errors about ambiguous CDI injections.
>>>
>>> Any advice?
>>>
>>> P.S: A little official information about how to get jersey to
>>> interoperable with CDI would be nice. Could not find anything except
>>> from 1-2 newsgroup postings that was a bit difficult to understand.
>>>
>>> __________________________________________________
>>> Bruger du Yahoo!?
>>> Er du tręt af spam? Yahoo!Mail har den bedste spambeskyttelse, der
>>> findes
>>> http://dk.mail.yahoo.com
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>