| Gemini Naming - Service Damping [message #813486] |
Mon, 05 March 2012 05:27  |
Eclipse User |
|
|
|
Hi there,
having used Gemini Naming 1.0.0.M1 together with Gemini JPA I found some issues that I would like to discuss. I'm willing to contribute code in case...
1) The OSGi Enterprise spec allows for arbitrary JNDI Names specified by osgi.jndi.service.name, yet Gemini Naming makes assumptions that a slash may not occur. Example: use "jdbc/MyDS" as JNDI name and Gemini Naming will assume that "osgi:service/jdbc/MyDS" should contain a valid OSGi filter after the second slash. The workaround is to use the longhand notation.
2) The OSGi Enterprise spec does not clearly state what a jndi provider should do in case a service is not (yet) available. I would suggest that a configurable time is waited before returning either a NamingException or the service proxy. In a dynamic environment like OSGi it is almost impossible to make sure all servcices are already there.
In case a service disapears, the spec only mandates that a replacement should be used (if available). Nothing prevents the application to wait on proxy access until either a timeout occurs or a replacement service appears. The whole point of using proxies is to damp the service dynamics.
This behaviour would also be in accordance to what blueprint does (wait until available, damp if service is lost). Apache Aries JNDI also has the feature btw.
Without this feature starting up an enterprise OSGi app with JPA and Naming becomes a real challenge. If you assume for example that DataSources are configured dynamically through ManagedServiceFactoryS, the exact point in time where a DataSource becomes available is not known.
As I said, I would be willing to write and provide a patch that:
- Uses a system property gemini.naming.wait.timeout with a default of 0
- Blocks service querying until a service is found
- Waits on rebind in the proxy implementation.
regards,
Magnus
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05021 seconds
Home