Hi Ivan, I've found trying to understand how jndi is supposed to work quite difficult in the past and this might be another such time :-)
I wonder if jndi is supposed to treat urlContextFactory differently than plan ObjectFactory. The jndi tutorial seems quite clear that a regular ObjectFactory should return null when it can't understand the arguments. However, I wonder if URLContextFactory is supposed to work differently. For URLs of scheme rmi, they are supposed to be easily identifiable in <some-dir>/rmi/rmiURLContextFactory. So jndi will never be calling them for a URL scheme other than "rmi". The example in the jndi tutorial on "how to write URL support" definitely throws an exception given a wrong URL. So I think the problem is either that we are registering URLContextFactories like regular ObjectFactories and we shouldn't be, or that Aries is treating them the same and shouldn't be. I think your proposal should work OK but I would prefer a cleaner solution. If you have time to look into it, great, otherwise lets open a jira issue to remind us to review later. thanks! david jencks On Nov 7, 2010, at 7:19 PM, Ivan wrote: > Hi, > While looking at GERONIMO-5579, just find some interesting things : > a. When looking up remote stub from rmiConnectionFactory shipped with > JRE, it will call the ObjectFactory to decode the returned object. And In > Geronimo 3.0, an OSGiObjectFactoryBuilder from Aries is installed, and it > will iterator all the ObjectFactory published to try to call > getObjectInstance method. So, we got problems, those javaUrlContextFactory > from Geronimo and JRE will throw Exception while they could not handle the > Object. The exception is like : > javax.naming.ConfigurationException: > rmiURLContextFactory.getObjectInstance: argument must be an RMI URL String or > an array of them > at > com.sun.jndi.url.rmi.rmiURLContextFactory.getObjectInstance(rmiURLContextFactory.java:43) > at > org.apache.aries.jndi.ObjectFactoryHelper.getObjectInstanceUsingObjectFactories(ObjectFactoryHelper.java:118) > at > org.apache.aries.jndi.ObjectFactoryHelper.doGetObjectInstance(ObjectFactoryHelper.java:97) > at > org.apache.aries.jndi.ObjectFactoryHelper.access$000(ObjectFactoryHelper.java:41) > at > org.apache.aries.jndi.ObjectFactoryHelper$1.run(ObjectFactoryHelper.java:57) > at java.security.AccessController.doPrivileged(AccessController.java:251) > at org.apache.aries.jndi.Utils.doPrivileged(Utils.java:145) > at > org.apache.aries.jndi.ObjectFactoryHelper.getObjectInstance(ObjectFactoryHelper.java:55) > at > org.apache.aries.jndi.OSGiObjectFactoryBuilder.getObjectInstance(OSGiObjectFactoryBuilder.java:57) > at > javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:334) > at > com.sun.jndi.rmi.registry.RegistryContext.decodeObject(RegistryContext.java:439) > at > com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:103) > at > com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:185) > at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:148) > at javax.naming.InitialContext.lookup(InitialContext.java:455) > at > javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1898) > at > javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1868) > at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:269) > ... 18 more > So currently, I plan to return null if those urlContextFactory found > that they could not handle the objects. For rmiContextFactory, I simply > created a wrapper for it. And now, it works for me. > > b. Enable multiple deploymentManager in the same vm of the server runtime. > In the past, we never try to connect another server with the same vm > of the server runtime, now, since it is allowed to run those deploy commands > in the embedded karaf shell, do think we need to support it. > > I attached a patch to GERONIMO-5579, I hope someone could help to review > the patch, especially the JNDI changes. > Thanks. > > -- > Ivan
