Thanks for the pointer. I'll look into both Peabody and Guice. I forgot to mention that we currently only use OSGi services, the service tracker, configuration admin, and http services. So our framework wrapper certainly won't be wrapping all of what OSGi can do.
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: Todor Boev [mailto:t.b...@prosyst.bg] > Sent: Tuesday, May 19, 2009 02:36 > To: users@felix.apache.org > Subject: Re: ServiceLoader and OSGi? > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
