You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2008/12/02 11:50:36 UTC
Replacing sun.misc.Service
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.properties:
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
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Replacing sun.misc.Service
Posted by Andreas Veithen <an...@gmail.com>.
Paul,
The code that implements the JDK-style provider lookup is already part
of Synpase; see ExtensionDeployer#getProviders. You can recycle this
code. The only change that will be required is to replace the call to
findResource by findResources or getResources (depending on whether it
is used by the extension deployer or by
(MediatorFactory|MediatorSerializer|Startup)Finder). Actually removing
the dependency on sun.misc.Service has been on my todo list for quite
some time as part of SYNAPSE-377. Please have a look at this JIRA
issue so that we can make sure we are going in the same direction.
Andreas
On Tue, Dec 2, 2008 at 15:59, Paul Fremantle <pz...@gmail.com> wrote:
> Asankha
>
> Thanks for the feedback.
>
> I agree completely about making the core of Synapse OSGi dependent. I
> think the design I proposed avoids that.
>
> 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 synapse.properties.
>
> Paul
>
> On Tue, Dec 2, 2008 at 2:36 PM, Asankha C. Perera <as...@apache.org> 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]
>> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
>> [2]
>> http://commons.apache.org/discovery/apidocs/org/apache/commons/discovery/tools/Service.html
>> [3] http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
>> [4]
>> http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/spi/ServiceRegistry.html
>>
>> +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 <pz...@gmail.com> 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.properties:
>>>
>>>
>>> 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
>> http://adroitlogic.org
>>
>> http://esbmagic.blogspot.com
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Replacing sun.misc.Service
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Asankha C. Perera wrote:
>> Well, it is possible to keep this out of synapse of course, if synapse
>> doesn't want it.
> As Sanjiva suggested, it could be a separate maven module or outside of
> Synapse. I would slightly prefer the latter because I think it would not
> be useful for a general Synapse install, and also to limit the number of
> maven modules
I wasn't suggesting keeping it out of Synapse - just a separate maven
module. I don't see why limiting the number of maven modules would be a
requirement at all. Also, OSGi is getting tremendous traction across the
board- having the capability to use its functionality to do things
easier/better is not a bad thing for Synapse.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Replacing sun.misc.Service
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Ruwan
>
> 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?
>
>
> Well, it is possible to keep this out of synapse of course, if synapse
> doesn't want it.
As Sanjiva suggested, it could be a separate maven module or outside of
Synapse. I would slightly prefer the latter because I think it would not
be useful for a general Synapse install, and also to limit the number of
maven modules
thanks
asankha
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Replacing sun.misc.Service
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Asankha,
On Tue, Dec 2, 2008 at 10:17 PM, Asankha C. Perera <as...@apache.org>wrote:
> 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?
Well, it is possible to keep this out of synapse of course, if synapse
doesn't want it.
>
> 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 synapse.properties.
>>
>>
> 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?
+1
Thanks,
Ruwan
>
>
> thanks
> asankha
>
> On Tue, Dec 2, 2008 at 2:36 PM, Asankha C. Perera <as...@apache.org>
>> 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]
>>> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
>>> [2]
>>>
>>> http://commons.apache.org/discovery/apidocs/org/apache/commons/discovery/tools/Service.html
>>> [3] http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
>>> [4]
>>>
>>> http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/spi/ServiceRegistry.html
>>>
>>> +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 <pz...@gmail.com> 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.properties:
>>>>
>>>>
>>>>
>>>> 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
> http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Replacing sun.misc.Service
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Asankha C. Perera wrote:
> 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?
I don't see any issue with that being a separate maven module. Is that
acceptable? The core of Synapse does not depend on OSGi yet, but there
would be an extension (one that uses a well-defined plug point) to suck in
OSGi-aware stuff.
> 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?
+1 from me.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Replacing sun.misc.Service
Posted by "Asankha C. Perera" <as...@apache.org>.
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 synapse.properties.
>
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?
thanks
asankha
> On Tue, Dec 2, 2008 at 2:36 PM, Asankha C. Perera <as...@apache.org> 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]
>> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
>> [2]
>> http://commons.apache.org/discovery/apidocs/org/apache/commons/discovery/tools/Service.html
>> [3] http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
>> [4]
>> http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/spi/ServiceRegistry.html
>>
>> +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 <pz...@gmail.com> 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.properties:
>>>
>>>
>>> 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
http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Replacing sun.misc.Service
Posted by Paul Fremantle <pz...@gmail.com>.
Asankha
Thanks for the feedback.
I agree completely about making the core of Synapse OSGi dependent. I
think the design I proposed avoids that.
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 synapse.properties.
Paul
On Tue, Dec 2, 2008 at 2:36 PM, Asankha C. Perera <as...@apache.org> 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]
> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
> [2]
> http://commons.apache.org/discovery/apidocs/org/apache/commons/discovery/tools/Service.html
> [3] http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
> [4]
> http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/spi/ServiceRegistry.html
>
> +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 <pz...@gmail.com> 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.properties:
>>
>>
>> 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
> http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Replacing sun.misc.Service
Posted by "Asankha C. Perera" <as...@apache.org>.
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]
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
[2]
http://commons.apache.org/discovery/apidocs/org/apache/commons/discovery/tools/Service.html
[3] http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
[4]
http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/spi/ServiceRegistry.html
> +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 <pzfreo@gmail.com
> <ma...@gmail.com>> 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.properties:
>
> 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
http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Replacing sun.misc.Service
Posted by Ruwan Linton <ru...@gmail.com>.
+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 <pz...@gmail.com> 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.properties:
>
>
> 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
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/