[virgo-dev] virgo with gemini-naming

[Dmitry Sklyut <dmitry@xxxxxxxxxxx>]

Hi All,

I started playing with the gemini-naming M1 in virgo.  Everything deploys fine with very few config file changes.

1.  Modify /lib/org.eclipse.virgo.kernel.launch.properties to add

file:lib/kernel/org.osgi.enterprise-4.2.0.jar@start,\

file:lib/kernel/org.eclipse.gemini.naming.impl.bundle-Incubation-1.0-SNAPSHOT.jar@start,\

Make sure to copy those jars to lib/kernel.

2.  Modify org.eclipse.virgo.kernel.userregion.properties to add following services to the "serviceImports"

org.osgi.service.jndi.JNDIContextManager,\

org.osgi.service.jndi.JNDIProviderAdmin

Based on my reading of the spec additional InitalContextFactory, InitialContextFactoryBuilder, ObjectFactory, etc can be published from user region.  In that case all of those entries should be added to the "serviceExports" property in org.eclipse.virgo.kernel.userregion.properties.  I tested that by publishing an InitialContextFactoryBuilder from userregion deployed bundle and saw it getting picked up.

One issues that I ran into:

Adding any of the following to the "serviceImports" list causes kernel to fail start up with very little information outside of a tiny stack trace.  javax.naming.spi.InitialContextFactoryBuilder,  javax.naming.spi.InitialContextFactory, javax.naming.spi.ObjectFactory

Error: startup-tracker <KE0003E> Kernel failed to start. java.lang.RuntimeException: bundle stopped

Another issue is that Tomcat set-up with "useNaming = true", so it will try to set-up "java:/" prefix itself.  It will also set system level properties for 

"java.naming.factory.initial" and "java.naming.factory.url.pkgs".  This behavior basically forces the client of the InitialContext to provide its own environment settings or keep a jndi.properties in the root of the bundle (section 126.3.1 of OSGi Enterprise spec).

Documentation of Tomcat org.apache.catalina.startup.Embedded.initNaming() says (I think) that useNaming should be false if Tomcat is embedded.

"Initialize naming - this should only enable java:env and root naming. If tomcat is embeded in an application that already defines those - it shouldn't do it. XXX The 2 should be separated, you may want to enable java: but not the initial context and the reverse XXX Can we "guess" - i.e. lookup java: and if something is returned assume false ? XXX We have a major problem with the current setting for java: url"

I guess I should also explain why I want to use jndi in OSGi.   We are using number of third party non osgi enabled web applications that provide ability to configure data source, mail session, etc either manually (properties/xml) or through jndi.  This is a maintenance nightmare waiting to happen as we need to modify x number of config files for each deployment.  One will be missed with about 100% probability :)

I wanted to use "osgi:service/" or a wrapper around "java:" namespace to have config in one spot and fetch services from service registry.  The wrapper for "java:/" namespace is useful for us in case one of those components will move out into its own instance of Tomcat/JEE container.

I will post more once I have a working wrapper for "java:/" namespace with delegation to "osgi:service" namespace.

Is anyone interested in virgo with jndi?  Are there any other mines that are waiting to explode?

Regards,

Dmitry