users@jersey.java.net

Re: [Jersey] Classloader problem with Felix/Jetty

From: Jakub Podlesak <Jakub.Podlesak_at_Sun.COM>
Date: Wed, 26 May 2010 08:56:51 +0200

Morten wrote:
> --- Den tirs 25/5/10 skrev Jakub Podlesak <Jakub.Podlesak_at_Sun.COM>:
>
>>> Great, so does that mean that you are doing automated tests on >>multiple OSGI environments as Pax Exam supports (I am particularly >>interested in Felix AND Equinox) ?
>>>
>
>
>> We tried it, but the Equinox based tests seemed a bit unstable. I have
>> disabled them in the recent builds.
>>
>
>
>> It would be great, if you can have a look at the tests and maybe
>> suggest some improvements?
>>
>
> I will have a look at your examples and tests as soon as possible (properly next week). I am also relatively new to OSGI but I will help where possible (at jersey is not the only project I am helping in this regard - I am f.x. already helping the Weld SE project to support OSGI).
>

O.K. Next week sounds great.
>
>> To be able to test reliably, some events are generated when the war is
>> deployed/jersey servlet gets registered.
>>
>
> Can you supply details about the events you rely on ?
>

The logic is similar to what is required by the spec (see in my previous
post bellow).
The event says: "resources are ready, you can access them). See the
sample source.
>
>> This technique is even required by the OSGi spec v4.2, but
>> unfortunately neither jetty nor grizzly (the containers used for
>> testing)
>>
>
>
>> follow that requirement. Then we have to generate the events of our
>> own. Are you aware of any container
>>
>
> No sorry.
>

Never mind.
>
>> The event infrastructure API is defined as part of OSGi compendium
>> spec. For Equinox, the only available implementation ....
>> The version above looks pretty obsolete. Are you aware of any more
>> recent stable version?
>>
>
> No, but I really think you should ask this on the Equinox mailing list !
>
I suggest you do it as part of the help offered above.

>
>> I know i can re-use the impl from Felix (which works fine for me with
>> Equinox),
>>
>
> Yea, that should not be a problem
>
>
>> but if Equinox does not provide something of it's own, i would rather
>> keep the tests disabled...
>>
>
> I also need automated tests for this so I hope we can find a solution. I can help you a bit with some things but the Equinox problems you have should really be addressed to the Equinox teams as they should know what to do (and I do not).
>
I believe our test infrastructure is fine. Feel free to re-use it.
Regarding the issues with instability of Equinox implementation
of OSGi compendium parts, if you manage to work this out with
Equinox guys then great, i could re-enable related tests.

> It is really important for me that Equinox works well with jersey as Equinox is way better/faster/productive to use in development mode then felix because of the eclipse IDE support. Also, if you only test on one OSGI implementation that you can not be sure you in fact is OSGI complient. I have had some experiences with

It is a pity, there is no reference OSGi implementation we could use.
Otherwise Felix is our main target as it is used also by GlassFish.
Other OSGi frameworks could be covered based on user requirements (you
did that part) and if things do not go smoothly with
some help from the community (i am glad you offered to participate).

Looking forward to see some good news from you on the matter.

Cheers,

~Jakub
> bugs in my code that would only shown up either Equinox or Felix. Having both working is a big thing! (just as important as f.x. testing multithreaded code on a multi-processor machine).
>
> /Morten
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>