geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Wrap the rmiConenctionFactory and enable multiple remoteDeploymentFactory in the same vm with the server runtime
Date Mon, 08 Nov 2010 06:54:49 GMT
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

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.

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(
>     at org.apache.aries.jndi.ObjectFactoryHelper.getObjectInstanceUsingObjectFactories(
>     at org.apache.aries.jndi.ObjectFactoryHelper.doGetObjectInstance(
>     at org.apache.aries.jndi.ObjectFactoryHelper.access$000(
>     at org.apache.aries.jndi.ObjectFactoryHelper$
>     at
>     at org.apache.aries.jndi.Utils.doPrivileged(
>     at org.apache.aries.jndi.ObjectFactoryHelper.getObjectInstance(
>     at org.apache.aries.jndi.OSGiObjectFactoryBuilder.getObjectInstance(
>     at javax.naming.spi.NamingManager.getObjectInstance(
>     at com.sun.jndi.rmi.registry.RegistryContext.decodeObject(
>     at com.sun.jndi.rmi.registry.RegistryContext.lookup(
>     at com.sun.jndi.toolkit.url.GenericURLContext.lookup(
>     at org.apache.aries.jndi.DelegateContext.lookup(
>     at javax.naming.InitialContext.lookup(
>     at
>     at
>     at
>     ... 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

View raw message