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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
