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
