ServiceLoader and OSGi?

[Moloney, Tim M]

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?

Any suggestions on how to get past this?

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
[phone] x208     unreasonable man.    George Bernard Shaw

[Richard S. Hall]

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
> [phone] x208     unreasonable man.    George Bernard Shaw
>
>
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Moloney, Tim M]

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(SecureAction
.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
[phone] x208                    unreasonable man. - George
Bernard Shaw
 

> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@...]
> Sent: Monday, May 18, 2009 10:11
> To: users@...
> 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
> > [phone] x208     unreasonable man.    George Bernard Shaw
> >
> >
> >
> >    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

On 5/18/09 4:04 PM, Moloney, Tim M 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.
>    

Is this the behavior you are expecting?

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

I believe Eclipse boot delegates every package, so your bundles may not
be seeing what you expect them to.

-> richard

> 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(SecureAction
> .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
> [phone] x208                    unreasonable man. - George
> Bernard Shaw
>
>
>    
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@...]
>> Sent: Monday, May 18, 2009 10:11
>> To: users@...
>> 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
>>> [phone] x208     unreasonable man.    George Bernard Shaw
>>>
>>>
>>>
>>>
>>>        
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>      
>> ------------------------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...

[Neil Bartlett]

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.Moloney@...> 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(SecureAction
> .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
> [phone] x208                    unreasonable man. - George
> Bernard Shaw
>
>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@...]
>> Sent: Monday, May 18, 2009 10:11
>> To: users@...
>> 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
>> > [phone] x208     unreasonable man.    George Bernard Shaw
>> >
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Moloney, Tim M]

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
[phone] x208                    unreasonable man. - George Bernard Shaw
 

> -----Original Message-----
> From: Neil Bartlett [mailto:njbartlett@...]
> Sent: Monday, May 18, 2009 16:39
> To: users@...
> 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.Moloney@...> 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
> > [phone] x208                    unreasonable man. - George
> > Bernard Shaw
> >
> >
> >> -----Original Message-----
> >> From: Richard S. Hall [mailto:heavy@...]
> >> Sent: Monday, May 18, 2009 10:11
> >> To: users@...
> >> 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
> >> > [phone] x208     unreasonable man.    George Bernard Shaw
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Todor Boev]

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
> [phone] x208                    unreasonable man. - George Bernard Shaw
>  
>
>> -----Original Message-----
>> From: Neil Bartlett [mailto:njbartlett@...]
>> Sent: Monday, May 18, 2009 16:39
>> To: users@...
>> 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.Moloney@...> 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
>>> [phone] x208                    unreasonable man. - George
>>> Bernard Shaw
>>>
>>>
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@...]
>>>> Sent: Monday, May 18, 2009 10:11
>>>> To: users@...
>>>> 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
>>>>> [phone] x208     unreasonable man.    George Bernard Shaw
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Moloney, Tim M]

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
[phone] x208                    unreasonable man. - George
Bernard Shaw
 

> -----Original Message-----
> From: Todor Boev [mailto:t.boev@...]
> Sent: Tuesday, May 19, 2009 02:36
> To: users@...
> 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
> > [phone] x208                    unreasonable man. -
> George Bernard Shaw
> >  
> >
> >> -----Original Message-----
> >> From: Neil Bartlett [mailto:njbartlett@...]
> >> Sent: Monday, May 18, 2009 16:39
> >> To: users@...
> >> 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.Moloney@...> 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
> >>> [phone] x208                    unreasonable man. - George
> >>> Bernard Shaw
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Richard S. Hall [mailto:heavy@...]
> >>>> Sent: Monday, May 18, 2009 10:11
> >>>> To: users@...
> >>>> 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
> >>>>> [phone] x208     unreasonable man.    George Bernard Shaw
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@...
> >>>> For additional commands, e-mail: users-help@...
> >>>>
> >>>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@...
> >>> For additional commands, e-mail: users-help@...
> >>>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

Did this issue ever get resolved?

As far as I can see, you are trying to find a service provider from the
SPI bundle, but the SPI bundle doesn't have any visibility to the
service provider, so it cannot find it. You cannot use ServiceLoader in
the normal way in OSGi.

-> richard

On 5/18/09 22:04, Moloney, Tim M 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(SecureAction
> .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
> [phone] x208                    unreasonable man. - George
> Bernard Shaw
>
>
>    
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@...]
>> Sent: Monday, May 18, 2009 10:11
>> To: users@...
>> 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
>>> [phone] x208     unreasonable man.    George Bernard Shaw
>>>
>>>
>>>
>>>
>>>        
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>      
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeremias Maerki-2]

Just in case anyone is interested: I've written a little bundle to work
around that problem and to get Apache FOP and Batik working in an OSGi
environment. The Apache XML Graphics project makes heavy use of the
META-INF/services mechanism for plug-ins.

My bundle provides code to transparently provide plug-in classes, be
that in an OSGi environment or in a plain Java environment. And it works
for Java >= 1.4 (i.e. doesn't use ServiceLoader). It seems to work quite
nicely for me so far, but I haven't taken the time to clean up
everything and publish it. And I'm using my own Ant-based
Bundle-Manifest creator (i.e. not BND) which is equally unpublished. But
if there's interest, I could do that work and publish it (be that on my
own website, as part of Apache XML Graphics or Apache Felix) in the next
few weeks (when my immediate deadlines are past).

Here's how some client code would look like:

        Services services = Services.getInstance();

        //Dynamic registration of ImagePreloaders
        Iterator iter = services.getServiceProvider(ImagePreloader.class).getServiceFactories();
        while (iter.hasNext()) {
            ServiceFactory factory = (ServiceFactory)iter.next();
            registerPreloader((ImagePreloader)factory.createInstance());
        }

Sorry, no generics, since I have to support Java 1.4 for the time being.

On 01.10.2009 11:48:16 Richard S. Hall wrote:

> Did this issue ever get resolved?
>
> As far as I can see, you are trying to find a service provider from the
> SPI bundle, but the SPI bundle doesn't have any visibility to the
> service provider, so it cannot find it. You cannot use ServiceLoader in
> the normal way in OSGi.
>
> -> richard
>
> On 5/18/09 22:04, Moloney, Tim M 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(SecureAction
> > .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
> > [phone] x208                    unreasonable man. - George
> > Bernard Shaw
> >
> >
> >    
> >> -----Original Message-----
> >> From: Richard S. Hall [mailto:heavy@...]
> >> Sent: Monday, May 18, 2009 10:11
> >> To: users@...
> >> 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
> >>> [phone] x208     unreasonable man.    George Bernard Shaw
> >>>
> >>>

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

Well, definitely make it available somehow so people can take a look at it.

-> richard

On 10/1/09 12:26, Jeremias Maerki wrote:

> Just in case anyone is interested: I've written a little bundle to work
> around that problem and to get Apache FOP and Batik working in an OSGi
> environment. The Apache XML Graphics project makes heavy use of the
> META-INF/services mechanism for plug-ins.
>
> My bundle provides code to transparently provide plug-in classes, be
> that in an OSGi environment or in a plain Java environment. And it works
> for Java>= 1.4 (i.e. doesn't use ServiceLoader). It seems to work quite
> nicely for me so far, but I haven't taken the time to clean up
> everything and publish it. And I'm using my own Ant-based
> Bundle-Manifest creator (i.e. not BND) which is equally unpublished. But
> if there's interest, I could do that work and publish it (be that on my
> own website, as part of Apache XML Graphics or Apache Felix) in the next
> few weeks (when my immediate deadlines are past).
>
> Here's how some client code would look like:
>
>          Services services = Services.getInstance();
>
>          //Dynamic registration of ImagePreloaders
>          Iterator iter = services.getServiceProvider(ImagePreloader.class).getServiceFactories();
>          while (iter.hasNext()) {
>              ServiceFactory factory = (ServiceFactory)iter.next();
>              registerPreloader((ImagePreloader)factory.createInstance());
>          }
>
> Sorry, no generics, since I have to support Java 1.4 for the time being.
>
> On 01.10.2009 11:48:16 Richard S. Hall wrote:
>    
>> Did this issue ever get resolved?
>>
>> As far as I can see, you are trying to find a service provider from the
>> SPI bundle, but the SPI bundle doesn't have any visibility to the
>> service provider, so it cannot find it. You cannot use ServiceLoader in
>> the normal way in OSGi.
>>
>> ->  richard
>>
>> On 5/18/09 22:04, Moloney, Tim M 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(SecureAction
>>> .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
>>> [phone] x208                    unreasonable man. - George
>>> Bernard Shaw
>>>
>>>
>>>
>>>        
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@...]
>>>> Sent: Monday, May 18, 2009 10:11
>>>> To: users@...
>>>> 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
>>>>> [phone] x208     unreasonable man.    George Bernard Shaw
>>>>>
>>>>>
>>>>>            
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeremias Maerki-2]

I can now finally follow up on that. I've just published an initial
version of my JAR Service Provider abstraction on my website:
http://www.jeremias-maerki.ch/development/osgi/jar-services.html

However, the client API has changed since I've last talked about it here.
An updated example can be found on the page above. Let me know if
there's interest to adopt the package into Felix. Since it doesn't
require OSGi to run, I guess Apache Commons could also be a suitable
home. At any rate, I'd be happy to donate it to the ASF if the community
finds this useful. I'll continue working on FOP & Batik over the next
few weeks to make them fit to run in an OSGi environment. I've got an
initial version running but not all extension points are transformed to
use the new service abstraction. There's also the question where it will
settle.

I'm grateful for any feedback on this!

On 01.10.2009 12:55:05 Richard S. Hall wrote:

> Well, definitely make it available somehow so people can take a look at it.
>
> -> richard
>
> On 10/1/09 12:26, Jeremias Maerki wrote:
> > Just in case anyone is interested: I've written a little bundle to work
> > around that problem and to get Apache FOP and Batik working in an OSGi
> > environment. The Apache XML Graphics project makes heavy use of the
> > META-INF/services mechanism for plug-ins.
> >
> > My bundle provides code to transparently provide plug-in classes, be
> > that in an OSGi environment or in a plain Java environment. And it works
> > for Java>= 1.4 (i.e. doesn't use ServiceLoader). It seems to work quite
> > nicely for me so far, but I haven't taken the time to clean up
> > everything and publish it. And I'm using my own Ant-based
> > Bundle-Manifest creator (i.e. not BND) which is equally unpublished. But
> > if there's interest, I could do that work and publish it (be that on my
> > own website, as part of Apache XML Graphics or Apache Felix) in the next
> > few weeks (when my immediate deadlines are past).
> >
> > Here's how some client code would look like:
> >
> >          Services services = Services.getInstance();
> >
> >          //Dynamic registration of ImagePreloaders
> >          Iterator iter = services.getServiceProvider(ImagePreloader.class).getServiceFactories();
> >          while (iter.hasNext()) {
> >              ServiceFactory factory = (ServiceFactory)iter.next();
> >              registerPreloader((ImagePreloader)factory.createInstance());
> >          }
> >
> > Sorry, no generics, since I have to support Java 1.4 for the time being.
> >
> > On 01.10.2009 11:48:16 Richard S. Hall wrote:
> >    
> >> Did this issue ever get resolved?
> >>
> >> As far as I can see, you are trying to find a service provider from the
> >> SPI bundle, but the SPI bundle doesn't have any visibility to the
> >> service provider, so it cannot find it. You cannot use ServiceLoader in
> >> the normal way in OSGi.
> >>
> >> ->  richard
> >>
> >> On 5/18/09 22:04, Moloney, Tim M 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(SecureAction
> >>> .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
> >>> [phone] x208                    unreasonable man. - George
> >>> Bernard Shaw
> >>>
> >>>
> >>>
> >>>        
> >>>> -----Original Message-----
> >>>> From: Richard S. Hall [mailto:heavy@...]
> >>>> Sent: Monday, May 18, 2009 10:11
> >>>> To: users@...
> >>>> 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
> >>>>> [phone] x208     unreasonable man.    George Bernard Shaw
> >>>>>
> >>>>>
> >>>>>            
> >
> >

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...