Re: ServiceLoader and OSGi?

Mon, 18 May 2009 23:36:38 -0700 

Tim,
Maybe your should check out the peaberry project.

http://code.google.com/p/peaberry/
It is service layer agnostic and already comes with implementations for OSGi and Eclipse. All you need to do is implement ServiceRegistry for your "stand alone" use case and maybe you could reuse your ServiceLoader code there.
I must worn here that peaberry is based on Guice and that might be a change too radical for your project. 

Cheers,
Todor

Moloney, Tim M wrote:

I agree that OSGi services solve this problem more cleanly than ServiceLoader.

Let me explain what I'm trying to do.  We have code that needs to work in 
several different frameworks or no framework at all.  I am trying to create an 
abstraction layer so that our code doesn't know the specifics of which 
framework it is using.  There would be the framework interface and several 
implementations.  The OSGi implementation would be a thin wrapper around OSGi.  
Another implementation would wrap a customers' custom framework, and a 
non-framework implementation would provide a crude implementation (mostly for 
testing).

I was hoping that if I had an interface and a factory, that I could simply load 
the appropriate implementation at runtime for the framework in use.  Am I being 
overly ambitious?
Tim Moloney The reasonable man adapts himself to ManTech Real-time Systems Laboratory the world; the unreasonable one persists 
2015 Cattlemen Road                    in trying to adapt the world to himself.
Sarasota, FL  34232                    Therefore all progress depends on the
(941) 377-6775 x208                    unreasonable man. - George Bernard Shaw

-----Original Message-----
From: Neil Bartlett [mailto:njbartl...@gmail.com] Sent: Monday, May 18, 2009 16:39 
To: users@felix.apache.org
Subject: Re: ServiceLoader and OSGi?

Tim,

I see you are using DynamicImport-Package to force visibility of the
implementation class by the FooFactory in the API bundle.

This is very dangerous. Your API bundle is going out and finding
exported classes from ANY bundle which happen to implement the Foo
interface as listed in the META-INF/services contents, but there is no
guarantee that the implementation class will actually implement the
same Foo interface. There may be other versions of the interface
around, for example. Also, ServiceLoader provides no help with dynamic
availability of services, therefore you will have to introduce
start-up ordering amongst all the bundles, which leads to extreme
fragility (and, eventually, un-resolvable circular start-up order
dependencies).

The ServiceLoader mechanism performs scanning of the "classpath" and
can therefore be used for a limited degree of extensibility in a
traditional classpath-based Java application. It is not in my opinion
suitable for use in a modular system. On the other hand you can
certainly use it within bundles, as bundles internally have a
classpath consisting of (potentially) multiple JARs.

I strongly encourage you to look into the OSGi Services model, which
is conceptually as simple as ServiceLoader but is far less fragile and
can be used across multiple bundles.

Regards,
Neil
On Mon, May 18, 2009 at 9:04 PM, Moloney, Tim M <tim.molo...@mantech.com> wrote:
I've attached my example project. To build it just run 
'mvn install'.
To run it from the command line, run 'RunFooFromOsgi'. To 
run it within
Eclipse, import the project, then run fooOsgi. 
RunFooFromMain (command

line) and fooMain (Eclipse) run the example service provider
successfully outside of Felix.

If I run my example code from the command line (RunFooFromOsgi), no
service providers are found.

If I run my example code from within Eclipse, I get the following:

Welcome to Felix.
=================

-> In com.example.foo.osgi.Activator.start():
ERROR: Error starting file:target/com.example.foo.osgi-0.1.0.jar
(org.osgi.framework.BundleException: Activator start error in bundle
com.example.foo.osgi [5].)
java.util.ServiceConfigurationError: 
com.example.foo.spi.Foo: Provider

com.example.foo.impl.FooImpl could not be instantiated:
java.lang.ClassCastException
       at java.util.ServiceLoader.fail(ServiceLoader.java:207)
       at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
       at
java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
       at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
       at com.example.foo.spi.FooFactory.getFoo(FooFactory.java:17)
       at com.example.foo.osgi.Activator.start(Activator.java:17)
       at


org.apache.felix.framework.util.SecureAction.startActivator(Se
cureAction

.java:589)
at 
org.apache.felix.framework.Felix.startBundle(Felix.java:1458)

       at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984)
       at


org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)

       at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassCastException
       at java.lang.Class.cast(Class.java:2990)
       at
java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345)
       ... 8 more
Tim Moloney The reasonable man 
adapts himself

to
ManTech Real-time Systems Laboratory the world; the 
unreasonable one

persists
2015 Cattlemen Road in trying to adapt 
the world to

himself.
Sarasota, FL 34232 Therefore all 
progress depends on

the
(941) 377-6775 x208                    unreasonable man. - George
Bernard Shaw



-----Original Message-----
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: Monday, May 18, 2009 10:11
To: users@felix.apache.org
Subject: Re: ServiceLoader and OSGi?

On 5/18/09 9:31 AM, Moloney, Tim M wrote:

I have a very simple service provider that works outside of OSGi.

I tried using it in Felix but it fails with a ClassCastException.

Is this somehow related to the different class loaders in

the different

bundles?


Probably.


Any suggestions on how to get past this?


Not enough information to say.

-> richard


Thanks.


Tim Moloney             The  reasonable  man adapts  himself  to
MRSL                    the world; the unreasonable one persists
2015 Cattlemen Road     in trying to adapt the world to himself.
Sarasota, FL  34232     Therefore  all progress  depends on  the
(941) 377-6775 x208     unreasonable man.    George Bernard Shaw







---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org






---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to