On Apr 28, 2010, at 11:20 AM, Morten wrote:
> --- Den ons 28/4/10 skrev Paul Sandoz <Paul.Sandoz_at_Sun.COM>:
>> It would be most helpful if you could have a play. I know
>> Weld itself has an OSGI-related distribution.
>
> Yes, not easy to find but it is there at "http://download.java.net/maven/glassfish/org/jboss/weld/weld-osgi-bundle/1.0.1-Final/
> "
>
>> 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.
>
> Uha, I am not a maven fan but I will try to se if I can build jersey
> for you which I think is maven (so I finally have the need to
> install maven I can see). Alternatively - if I get into trouble - I
> will get back to you and plead for you sending me the jars to
> test :-) ?
Use maven 2.2.1, SE 6 (or SE 5). I use the following maven options:
$ echo $MAVEN_OPTS
-Xmx1048m -XX:PermSize=64M -XX:MaxPermSize=128M
Be prepared for maven to download half the internet when you first use
it :-)
>
>> 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 would really hope that we can get all these things ironed out
> before glassfish 3.01, so that from glassfish 3.01 on everything
> works ?
>
We will target GF v3.1 for such work OSGi integration. Deploying an
OSGi bundle is not AFAIK a currently supported feature and i do not
know if it will be for 3.1 either. So this area is in flux and i
cannot promise anything in this respect.
> As for the OSGI Jersey work I do not know who is doing it, but
> can you ask him/her to verify for Weld/CDI support ?
>
Jakub is doing that.
We are going to change the way we distribute Jersey to GF, as separate
OSGi bundles. That has a higher priority than any Weld/Jersey/OSGi
verification, so that will have to wait, unless you do it before us :-)
>> 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.
>
> Yes, if you write a draft helper. I am willing to test it on a real
> project (my own) + give feedback.
>
Great! Can you log an enhancement to track this?
Paul.