synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: Replacing sun.misc.Service
Date Tue, 02 Dec 2008 16:47:14 GMT
Hi Paul
> I agree completely about making the core of Synapse OSGi dependent. I
> think the design I proposed avoids that.
Cool.. I think Ruwan's reply on an OSGi based mediator finder would be 
then outside of the codebase of Synapse?
> My approach is to create a plugpoint which replaces the use of
> sun.misc.Service and creates a standard way of looking up available
> implementations of a given interface. That plugpoint I documented
> above.
> The default Synapse implementation of that plugpoint would use a
> non-JDK, non-OSGI dependent approach like Apache Commons Discovery,
> but could be changed by anyone simply by editing
I guess this means that one could write an implementation over the JDK 
1.6 ServiceLoader or Commons Discovery similarly.. I think we should fix 
the default Synapse implementation to use whatever is supported by the 
JDK (1.5/1.6) and make Synapse work with any JDK for the next release 
1.3.. and for the enhanced ESBs over Synapse, one could easily override 
this with OSGi based finders.. Is this in agreement with your thoughts?

> On Tue, Dec 2, 2008 at 2:36 PM, Asankha C. Perera <> wrote:
>> Hi Ruwan/Paul
>> The Java ServiceProvider API [1] is now in the JDK 1.6 as the
>> java.util.ServiceLoader [3]
>> Other alternatives/workarounds for previous JDK's are the following:
>>     Apache Commons Discovery [2]
>>     The use of javax.imageio.spi.ServiceRegistry [4] - which though [very]
>> ugly was already in the JDK's all along
>> I am not in favor of making the core of Synapse OSGi dependent - but if that
>> could be kept as an option thats triggered, within a larger container like
>> the WSO2 ESB - thats totally fine. Can we first discuss the approach before
>> we commit any changes?
>> thanks
>> asankha
>> [1]
>> [2]
>> [3]
>> [4]
>> +1 for the proposal
>> and the OSGi Services and the Service listeners will make it very easy to
>> pick the mediators using OSGi.
>> So if we can make an OSGi based mediator finder then we can easily declare
>> the MediatorFactory as an OSGi service interface (no code changes required
>> for this), and register the factory implementations as OSGi services. So
>> that this implementation is going to be just a service listener.
>> Thanks,
>> Ruwan
>> On Tue, Dec 2, 2008 at 4:20 PM, Paul Fremantle <> wrote:
>>> There are two problems with sun.misc.Service.
>>> 1) It isn't standard across JDKs
>>> 2) We are likely to run into problems in an OSGi environment.
>>> I personally think that OSGi might provide the long term solution for
>>> this - it can do the same thing, but I'm not clear if we are ready to
>>> take a dependency on OSGi in the core at this point. That would mean
>>> shipping with an OSGi library and therefore choosing which one etc.
>>> So my proposal is that we do the following:
>>> We simply create an interface that matches the current Sun interface
>>> except in our stack:
>>> package org.apache.synapse.configuration;
>>> public interface ClassFinder {
>>>    Iterator findImplementationsOf(Class clazz);
>>> }
>>> I renamed the interface and method names because I think the one's
>>> that Sun uses are frankly confusing.
>>> Then we can have a line in
>>> synapse.config.classfinder=org.apache.synapse.config.ClassFinderImplementation
>>> Initially this implementation could be one of the different plugin
>>> replacements for sun.misc.Service that works on any JDK. We could also
>>> write an OSGi version, and we could write a version that say tries
>>> OSGi first then the old style. Alternatively we could do some other
>>> method.
>>> If there are no objections (or suggestions for improvement!) I will
>>> make these changes over the next day.
>>> Paul
Asankha C. Perera

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message