Bug 27383 - Missing rmi URL context factory
Summary: Missing rmi URL context factory
Status: RESOLVED FIXED
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: 0.90
: P3 normal
Target Milestone: ---
Assignee: Audrius Meškauskas
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-02 11:50 UTC by Audrius Meškauskas
Modified: 2006-08-08 11:36 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Formal fix to make sure that all places are searched (2.35 KB, patch)
2006-05-17 10:47 UTC, Audrius Meškauskas
Details | Diff
Factory implementations (RMI and CORBANAME) (20.97 KB, patch)
2006-08-07 00:58 UTC, Audrius Meškauskas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Audrius Meškauskas 2006-05-02 11:50:43 UTC
Hi,

In Carol project (used by JOnAS project), the RMI context factory is  resolved by a call to the javax.naming.spi.NamingManager class [1].

With JVMs using GNU Classpath, the context returned by calling  NamingManager.getURLContext(,) method is null, while with Sun/Bea/IBM  JDK, it is non-null.

When looking at the GNU classpath class source code:
http://cvs.savannah.gnu.org/viewcvs/classpath/javax/naming/spi/NamingManager.java?rev=1.9&root=classpath&view=log

There are some issues.

For example, there is the following code :

   if (prefixes == null)
     {
   // Specified as the default in the docs.  Unclear if this is
   // right for us.
   prefixes = "com.sun.jndi.url";
     }

By default, (see  http://java.sun.com/j2se/1.3/docs/api/javax/naming/spi/NamingManager.html)  it doesn't mean that it should not be added to the existing prefixes,  and it is strange to add some sun prefixes in GNU classpath.

When using rmi as scheme, with Sun JVM, the expected class is  "com.sun.jndi.url.rmi.rmiURLContextFactory" (as written in the guide  http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-rmi.html ).

With GNU classpath, if we have a prefix (JOnAS case), it will then try  to instantiate a class rmiURLContextFactory with different packages. But  none of them will be found (and it doesn't search in com.sun.jndi.url  package as there is already a package : prefixes != null).

I tried to search a rmiURLContextFactory class in GNU classpath but I  didn't find one (with this name).

So, I think that a rmiURLContextFactory class and iiopURLContextFactory  should be added in a GNU classpath package.
And that the default prefix to use should be the package containing the  2 previous classes. Moreover, this prefix should be added for all cases  (and not only when prefixes is null).

Without these classes, JOnAS couldn't run with RMI/JRMP, RMI/IRMI and  RMI/IIOP (only jeremie should be working as the context factory is in  jeremie package. But jeremie is deprecated and I want to run JOnAS with  IRMI).


[1] example of code reproducing a NULL context by using GNU classpath  (and a non-null context with proprietary jvm like Sun/Bea/IBM)

import java.util.Hashtable;

import javax.naming.Context;
import javax.naming.NamingException;
import javax.naming.spi.InitialContextFactory;
import javax.naming.spi.NamingManager;
public class TestJNDI {

   public static void main(String[] args) throws Exception {

       Hashtable env = new Hashtable();
       env.put(Context.PROVIDER_URL, "rmi://localhost:1099");
       env.put(Context.INITIAL_CONTEXT_FACTORY,  URLInitialContextFactory.class.getName());
       env.put(Context.URL_PKG_PREFIXES, "test.jndi");

       Context ctx = NamingManager.getURLContext("rmi", env);
       System.out.println("Ctx = " + ctx);

   }

   public class URLInitialContextFactory implements InitialContextFactory {

       public Context getInitialContext(Hashtable environment) throws  NamingException {
           return null;
       }
   }
}


Regards,

Florent
Comment 1 Audrius Meškauskas 2006-05-17 10:47:37 UTC
Created attachment 11482 [details]
Formal fix to make sure that all places are searched

The manager now search first in the environment, then (if failed) it always tries the system properties and finally tries the default package which is - in the Free world - is unlikely to be present in the class path. I, however, tried this way - the Sun's class is now found and loaded. I think we need our own implementation of  these factory classes and agree that they package should be default or at least added as the last place to search if the proprietary Sun's classes are not found.

On of your sentence can be understood as that in JOnAS case the required factory classes are present in the patch and specified in the properties, but they are still not found. This is mentioned very briefly. I suspect that it may be the problem of classloader, as it was with our CORBA in the past. I did the same fix as for CORBA. Please let me known if it solves the problem in the case when the factory implementation is present in the linked library. 

We will probably need our own implementation in the future.
Comment 2 Florent BENOIT 2006-06-03 14:25:11 UTC
  Hi,

Well, the problem is that maybe with your patch, the package prefix will be ok, but the Context factory won't be found (for jrmp or iiop). AFAIK, classpath doesn't provide rmiURLContextFactory class and iiopURLContextFactory classes in a com.sun package.

> On of your sentence can be understood as that in JOnAS case the required
> factory classes are present in the patch and specified in the properties, but
> they are still not found. This is mentioned very briefly. I suspect that it may
> be the problem of classloader, as it was with our CORBA in the past. I did the
> same fix as for CORBA. Please let me known if it solves the problem in the case
> when the factory implementation is present in the linked library. 

The required factory are not present. We assume that the JDK provide them.
We provide factories for java: only, not for the RMI protocols.
This is not a classloader problem, if the rmi* or iiop* factories are not present. (missing)

Florent
Comment 3 Audrius Meškauskas 2006-08-06 08:27:44 UTC
Could anybody post here a simple test how the IOR: and CORBALOC: context factories should actually WORK? The factory finding is fixed now. I am now implementing these two factories, it would be great to have some independent testing. Audrius.
Comment 4 Audrius Meškauskas 2006-08-07 00:58:34 UTC
Created attachment 12031 [details]
Factory implementations (RMI and CORBANAME)

This patch adds the URL context factories for RMI and CORBANAME, fixing the 27383. As much as I tested, they work same way as the analogical implementations in sun's package.
Comment 5 Audrius Meškauskas 2006-08-07 00:59:58 UTC
As the implementation exists, I close this bug. The basic functionality is tested. If something still does not work like required, please fill in the new bug report explaining, what is going wrong.
Comment 6 Audrius Meškauskas 2006-08-08 11:36:14 UTC
This bug is also discussed in Carol bug database: http://forge.objectweb.org/tracker/?func=detail&atid=100026&aid=305913&group_id=26