On Jan 13, 2010, at 4:02 PM, Jakub Podlesak wrote:
> On Wed, Jan 13, 2010 at 12:11:48PM +0100, Paul Sandoz wrote:
>> Hi Mathias,
>>
>> [Moving to a different thread]
>>
>> Thanks for looking at this.
>>
>> Begin forwarded message:
>>
>>> From: Mathias Brökelmann <mbroekelmann_at_googlemail.com>
>>> Date: January 12, 2010 11:29:02 PM CEST
>>> To: users_at_jersey.dev.java.net
>>> Subject: Re: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
>>> Reply-To: users_at_jersey.dev.java.net
>>>
>>>
>>> Hi,
>>>
>>> I've looked at the recently merged osgi branch and run some tests
>>> with it.
>>> Here are the things I think could be improved:
>>>
>>> Personally I think it is better to add the bundle manifest headers
>>> to the
>>> original codebase and not in separate artefacts. The code which is
>>> osgi
>>> related - for instance the modifications to the jersey ServiceFinder
>>> class -
>>> should be inlined into the main artifacts. Otherwise it will be hard
>>> on
>>> future updates since two codebases must be maintained.
>
> IIRC we wanted to avoid OSGi dependencies in the core artifact,
> i would be reluctant to just inline the diffs from the osgi/jersey-
> core
> in the jersey-core for the same reason. I agree the redundant
> ServiceFinder
> class in annoying.
>
It does not have to be hard coded, one can use Java reflection.
>
>>>
>>
>> I agree it would be better to avoid such modifications. It might be
>> possible to have an OsgiServiceFinder that extends from
>> ServiceFinder,
>> and the former is utilized in an OSGi Environment.
>
> That would be an elegant solution. Then we would only need to make
> sure the ServiceFinder
> clients (ServiceProvider class and maybe some others) could obtain
> the right ServiceFactory
> class to call.
>
Right, using reflection. Static methods of ServiceFinder are utilized
to create an instance of ServiceFinder.
We can make the class non-final and so that it can be extended, then
the static method can have logic to decide if the normal ServiceFinder
or the OsgiServiceFinder should be utilized.
>>
>> We would need to double check that the OSGi headers are also
>> compatible with that we currently have for GF support.
>
> These headers are unfortunatelly not 100 % compatible, as in GlassFish
> we need to utilize a special private=GlassFish attribute for certain
> imported packages.
> But i do not understand how this relates to the ServiceFinder
> redundancy thing.
>
It's not. I am just trying thinking of possible issues if we use the
original code base.
>>
>> Given it is getting very close to release of Jersey 1.1.5.1 i think
>> we
>> need to evaluate this quickly to decide if we should go with what we
>> have for 1.1.5.1 or delay it until the next release (which we could
>> do
>> rather quickly just for OSGi support).
>>
>> Jakub, what do you think?
>
> My opinion is to keep the OSGi stuff separated. So to release what
> we have now
> and then keep improving.
>
It does allow use to get something out for wider testing and then for
the next release we can merge things.
Paul.