META-INF/services and OSGi bundles

View: New views
3 Messages — Rating Filter:   Alert me  

META-INF/services and OSGi bundles

by Sahoo :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

META-INF/services [1] is used a lot in non-OSGi environment as an SPI
mechanism. e.g., JAXP, StAX, JPA, etc use this facility. What is the
best way to handle them when we migrate such code to run in OSGi
environment? One solution is to change the library (service provider) to
make the services available as OSGi services in the service registry and
change all clients to use the service registry to look up. But, this
requires changing the library code as well as client code. It's probably
easy to change the library, but changing all the clients is a bit tough
ask. Is there any alternative? Why does the OSGi spec not have any
special treatment for META-INF/services file?

Thanks,
Sahoo

[1] http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider

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


Re: META-INF/services and OSGi bundles

by Richard S. Hall :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Probably the only reason is that OSGi had its own notion of services
since the beginning and it was not really targeting the same area as
META-INF/services. I am not aware of a pattern for dealing with this,
but I agree that it needs to be dealt with.

There has been some discussion about it within the OSGi Alliance, but I
am not up to date on any current status or if there is any progress on
it at all.

Sun is a member, so there is a ripe opportunity... ;-)

-> richard

Sahoo wrote:

> META-INF/services [1] is used a lot in non-OSGi environment as an SPI
> mechanism. e.g., JAXP, StAX, JPA, etc use this facility. What is the
> best way to handle them when we migrate such code to run in OSGi
> environment? One solution is to change the library (service provider)
> to make the services available as OSGi services in the service
> registry and change all clients to use the service registry to look
> up. But, this requires changing the library code as well as client
> code. It's probably easy to change the library, but changing all the
> clients is a bit tough ask. Is there any alternative? Why does the
> OSGi spec not have any special treatment for META-INF/services file?
>
> Thanks,
> Sahoo
>
> [1]
> http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider
>
> ---------------------------------------------------------------------
> 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@...


Re: META-INF/services and OSGi bundles

by Niklas Gustavsson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tue, Jul 1, 2008 at 3:45 AM, Sahoo <Sahoo@...> wrote:

> META-INF/services [1] is used a lot in non-OSGi environment as an SPI
> mechanism. e.g., JAXP, StAX, JPA, etc use this facility. What is the best
> way to handle them when we migrate such code to run in OSGi environment? One
> solution is to change the library (service provider) to make the services
> available as OSGi services in the service registry and change all clients to
> use the service registry to look up. But, this requires changing the library
> code as well as client code. It's probably easy to change the library, but
> changing all the clients is a bit tough ask. Is there any alternative? Why
> does the OSGi spec not have any special treatment for META-INF/services
> file?

Possibly turning the questions around somewhat, here's one approach to
making the spec JARs behave in an OSGi environment:
http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html

/niklas

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

LightInTheBox - Buy quality products at wholesale price!