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