users@jersey.java.net

Re: SV: [Jersey] Weld on SE with Jersey and Grizzly

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 28 Apr 2010 10:59:29 +0200

On Apr 27, 2010, at 6:54 PM, Morten wrote:

> Hi Poul,
>
> Thanks a lot! I really value this example and the help!!!!!
>
> To have Jersey now work with the latest java dependency injection
> standard CDI on both JEE and SE is a major achievement! It f.x.
> allows for complex REST apps build using standard Java 6
> javax.inject, that can be run as both lightweight desktop
> applications and full web application in an application server. Way
> cool. I do not think that any other of the competing implementations
> can match this !
>
> Now - pending my own test of your example and the recent bugfix -
> the only possible real potential obstacle for me about Jersey/CDI
> integration will be if the upcoming OSGI version of Jersey will
> continue to work with CDI/weld in both JEE and SE ??? Is this
> something you can check for me Poul in advance (very important as I
> will properly move to OSGI with my application and possible run
> Jersey on top of OSGI Http Service which I think will be a popular
> way to run Jersey) ?
>

It would be most helpful if you could have a play. I know Weld itself
has an OSGI-related distribution.

As Jakub says we are having issues with the maven repo at the moment.
So it you want to verify you will need to check out the trunk and
build yourself.

Note that there is no OSGi specified in Java EE 6. There is some
support in GF for OSGi bundle deployment. But there needs to be some
fixes to that before Jersey can work correctly (and correctly override
the Jersey version distributed with GF).


> I will get back to you about my possible need for a public version
> of JCDIComponentProviderFactory. But maybe other people can say if
> they need it as well ?
>

OK.

I think we may need some sort of public helper or JCDIServletContainer
or something like that for SE. Perhaps as a separate module to ensure
appropriate dependencies get picked up. Then a simple sample. We don't
want developers depending on impl specific classes as these can change
at any time.


> Again - THANKS A LOT!!
>

Np, i was actually rather pleased this worked out. No really big
problems :-)

Paul.