See also Defects & Tasks for known limitations of the current release.
Markus Reith <Markus.Reith@dresdnerKB.com> notes that plug-in error messages can be found in from the menu Help->About Eclipse Platform->Configuration Details (which shows the Eclipse log). This helped him figure out that he needed to add ALL JBoss JARs from the JBoss client folder to his Eclipse Project to get the JNDI tree.
Allow me to re-iterate that: the JBoss JNDI implementation (called JNP) is split across
multiple JAR files, which must be added to your project for the plug-in to function.
At the very least you need jnp-client.jar and log4j.jar,
and maybe some others too.
Wai Yung <waiyung@aicompro.com> reported the following error when using the plug-in to access JBoss 3.0.4.
boundObject LOOKUP FAILURE: javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.yung.interfaces.PartgroupLocalHome (no security manager: RMI classloader disabled)]He solved this problem by adding the parameters
-Djava.security.manager -Djava.security.policy="server.policy"
in the Eclipse startup script and adding the policy file in the Eclipse directory.
Matthew Green <mat@mindhouse.co.uk> reported the following error with JBoss 3.2.1.
Failed to access context: javax.naming.CommunicationException [Root exception is java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.net.MalformedURLException: no protocol: Files/Java/j2re1.4.1_03/lib/jsse.jar]Some component appears to incorrectly parse the space character in "Program Files". He solved this problem by installing the JDK to a path without spaces, and changing the JRE used by Eclipse.
Need to change the JRE that Eclipse is using. So in Window->Preferences under Java > Installed JREs I added a JRE pointing to my sdk jre which has the path: C:\sdk\java\j2sdk1.4.1_03 therefore no spaces, so it works fine now.
Tomcat 4.x includes a JNDI implementation, but it CANNOT be browsed using this plug-in. The Tomcat JNDI is always local and cannot be accessed from a different VM. Rémy Maucherat, author of the Tomcat JNDI implementation, confirmed it is incompatible with this plug-in.
However, Tomcat ships with a JndiServlet that can be used to list the content of a
local JNDI tree. It is found in the "examples" Webapp.
André de Oliveira Fernandes <andre.oliveira@bcb.gov.br> reported an issue running the plug-in with WebSphere 4.
[The plug-in] doesn't seem to work with WebSphere ASE 4. In the eclipse log I get this: !ENTRY com.waldura.eclipse.jndiexplorer 4 0 Out 11, 2002 10:15:17.986 !MESSAGE The initial context could not be created !STACK 0 javax.naming.ServiceUnavailableException: NULL returned when resolving initial reference=NameService at com.ibm.ws.naming.util.WsnInitCtxFactory.getCosRootContext(WsnInitCtxFactory.java:476) at com.ibm.ws.naming.util.WsnInitCtxFactory.getRootJndiContext(WsnInitCtxFactory.java:361) at com.ibm.ws.naming.util.WsnInitCtxFactory.getInitialContextInternal(WsnInitCtxFactory.java:227) at com.ibm.ws.naming.util.WsnInitCtx.getContext(WsnInitCtx.java:98) at com.ibm.ws.naming.util.WsnInitCtx.(WsnInitCtx.java:79) at com.ibm.ws.naming.util.WsnInitCtxFactory.getInitialContext(WsnInitCtxFactory.java:135) at com.ibm.websphere.naming.WsnInitialContextFactory.getInitialContext(WsnInitialContextFactory.java:80) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:665) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246) at javax.naming.InitialContext.init(InitialContext.java:222) at javax.naming.InitialContext. (InitialContext.java:198) at javax.naming.directory.InitialDirContext. (InitialDirContext.java:83) at com.waldura.eclipse.jndiexplorer.InitialContextAdapterFactory.newInitialContext(InitialContextAdapterFactory.java:80) at com.waldura.eclipse.jndiexplorer.InitialContextAdapterFactory.newInitialContextAdapter(InitialContextAdapterFactory.java:43) at com.waldura.eclipse.jndiexplorer.actions.AddRootContextAction.run(AddRootContextAction.java:72) at org.eclipse.jface.action.Action.runWithEvent(Action.java:749) (...) I managed to make it work with WebSphere 4. WAS uses its own JRE (and proprietary JNDI classes, I guess), so you need to start eclipse with the same JRE: eclipse.exe -vm "%WAS4_HOME%\java\jre\bin\java.exe"
About this same issue, Guillaume Compagnon <gcompagnon@hotmail.com> adds:
IBM's JNDI implementation uses IBM Corba ORB and special features of IIOP. (More information can be found here). The best solution is to patch the Sun JVM with the Pluggable Application Client for WebSphere Application Server, available at IBM. You will have everything for making lookup on WAS JNDI and no constraints with the JVM used for Eclipse.
About WebSphere 5, Patrick Elgner reports he got good results by running Eclipse
on the IBM VM as explained above, and using the following libraries:
$WAS_HOME/lib/namingclient.jar
$WAS_HOME/lib/ecutils.jar.
Kington, Max <MKington@cantor.co.uk> reported the following when accessing the JRun JNDI.
I'm getting a nested error which comes down to ajava.net.MalformedURLException: no protocol. I would imagine that I just have to add a property=value pair to the initialcontext that your plugin mentions but I don't know what it should be. Once I had added the Jrun.jar to my classpath for this project that still wasn't enough to get this far. There was a class difference between my copy of the JAR and the production server. A user must ensure that they have a JAR which is the same patch level as the JRun server they want to connect to. Our production boxes are at SP1a and my local developer copy wasn't. The error changed once I had patched my copy.
The root cause of this issue has yet to be resolved.
Chuck Nelson <CNelson@quantumshift.com> reported a problem when JNDI classes from both WebLogic 6.1 and WebLogic 7.0 are present on the classpath.
For the Weblogic issue, I think I'm having classpath problems. My working set contains multiple projects. One uses Weblogic 6.1 classes and another, which is an RMI project, uses some Weblogic 7.0 classes. The Weblogic 6.1 code makes an RMI call to objects that use Weblogic 7.0 classes to make some remote webservice calls. This was done because Weblogic changed some classes between 6.1 and 7.0. Some methods were changed, new ones were added and old ones were remove (not deprecated).Because of that, the webservice client code would not run under 6.1 because of a dependence on the 7.0 class versions. If I replaced the 6.1 classes with their 7.0 equivilents, then the 6.1 server would not start.
My only solution was to run them in different VMs using different classpaths, and using RMI to communicate between the processes. Because of that, my Eclipse working set has different versions of the same classes. When I added weblogic.jar from the 7.0 code to my 6.1 project, I then started getting the error below, which leads me back to the class version collision problem.
This problem can only be solved by telling the plug-in which libraries to use, which as of release 1.1 is not yet possible.
John Freeborg <jfreeborg@softswitch.com> reported a problem with OpenJMS 0.7.2. His conclusion is that the OpenJMS JNDI implementation is deficient and cannot be made to work with the plug-in.
I think I found the root problem with OpenJMS. I crafted a simple command line JNDI namespace dumper and I get a strange exception when I try to list various bindings using Context.listBindings():javax.naming.InvalidNameException: java:/ has more components than JndiContext can handleTracking this back to the OpenJMS source I found this which explains it I think. The javadoc header explains that the OpenJMS implementation of JndiContext cannot handle CompositeName objects with more than one entry. So basically the embedded OpenJMS JNDI service is a bit lacking.
Starting at line 193 of org.exolab.jms.jndi.JndiContext.java:
/**
* Since methods that take instances of Name can either be of type
* CompositeName or CompoundName this JndiContext only deals with
* CompoundNames. This method will convert CompositeNames to CompoundNames
* hence simplifying the process.
* If the specified name is CompositeName then it expects it to only
* support a single entry (i.e does not support federatations) so if
* more than one entry is specified it will throw the InvalidName-
* Exception.
*
* @param name name to evaluate
* @return Name instance of type CompoundName
* @exception InvalidNameException
*/
protected Name toCompoundName(Name name) throws NamingException
{
Name result = name;
if (name instanceof CompositeName) {
if (name.size() > 1) {
throw new InvalidNameException(name.toString() +
" has more components than JndiContext can handle");
}
// use the name parser to convert the string to a compound name
result = nameParser__.parse(name.get(0));
}
return result;
}