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 <[EMAIL PROTECTED]> 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 <[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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
