[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] virgo with gemini-naming
- From: Dmitry Sklyut <dmitry@xxxxxxxxxxx>
- Date: Fri, 8 Oct 2010 21:37:08 -0400
- Delivered-to: firstname.lastname@example.org
I actually did get a bit further. Had to re-read the spec twice to get some of the mechanics.
What I have done is:
1. Move gemini-naming into user region from kernel.
Naming tries to look up services from service registry when jndi name matches osgi:service and it uses ServiceFactory to get at the client bundle context.
When deployed in kernel it would always get a userregion bundle context and because the service is not in the list of exported services it would never find it.
2. OSGi enterprise jar is deployed in kernel
Config Admin and Event Admin are already deployed there. I just put in the initial list before config/event admins.
3. I created a super dumb way to rewrite java: to osgi:. It is in com.dsklyut.virgo.osgi.javanaming.bridge. I just got it to work. It is basically a hack and POC.
I am publishing an ObjectFactory with property “osgi.jndi.url.scheme=java” and return a proxy Context that later on lookup(String) call gets a new InitialContext from JNDIContextManager and calls lookup(String) on that with rewritten name.
4. Tomcat does get in the way with its insistence of setting initial context factory name.
I could not find a way to declaratively set useNaming to false. Maybe this can be addressed in gemini-web with a property or a fragment? To re-set the System properties I added another bundle that removes them in Activator.start and added that bundle to the list of initialAtifacts right after virgo.web (com.dsklyut.virgo.osgi.javanaming.system.property.cleanup bundle).
I would be happy to put together a more detailed description next week.
On Fri, Oct 8, 2010 at 8:23 AM, Glyn Normington <gnormington@xxxxxxxxxx>
Thanks for the write-up! When you have gotten a bit further, you may want to add this to the Virgo documentation or at least the wiki.
As for KE0003E, perhaps you would raise an enhancement bug so that we at least put the bundle details in the message.
I was playing around with JNDI and Virgo the other week, but didn't get as far as you. Since it was only for a demo, I gave up.
On 7 Oct 2010, at 20:49, Dmitry Sklyut wrote:
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
Make sure to copy those jars to lib/kernel.
2. Modify org.eclipse.virgo.kernel.userregion.properties to add following services to the "serviceImports"
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?
virgo-dev mailing list