See also the Defects & Tasks for known issues in the current release.
For better or for worse, the JNDI framework loads service provider implementations (SPI)
dynamically, using Class.forName(). As always with dynamic classloading,
there is some headache involved in getting this to work right.
Until version 1.2, the JNDI Explorer would look for SPIs in the workspace. More precisely, it would find the open Java projects in the workspace, and get their libraries. This set of libraries would be used to initialize a custom classloader passed to the JNDI framework. In most cases, it would "just work", because you happened to have the SPI libraries in the workspace. In more complicated scenarios, you were out of luck.
Starting with version 1.2, a preference page was created to let you select your own libraries (your own classpath). In that case, the workspace libraries are ignored, and only the libraries you specify are searched for SPIs. This is done with a custom classloader, initialized with the libraries entered in the preference page. Additionally, that classloader's parent is the system classloader. See figure 1 below.
What does this mean to Eclipse users? The default behavior is still to look up the workspace. If your SPIs are referenced by one of your projects, everything should just work. But if you have problems with this default, you can go to the JNDI Explorer preference page, and explicitely select the libraries you want the plug-in to use. In that case, the plug-in will also search the classpath, the extensions directory, etc.
Note that it does not seem possible to prevent the plug-in from searching the JDK libraries
(rt.jar and friends), which bundle Sun's own SPIs for JNDI. I don't think it is
possible to override Sun SPIs with your own.
This plug-in was initially designed as a developer tool, and as such expected to run in the Eclipse Java IDE. However, many users have inquired about the feasibility of using this plug-in outside of the traditional Eclipse Java environment, the JDT.
First off, this plug-in requires the following Eclipse packages. Note that the full list of
dependencies can be found in the plug-in's plugin.xml file.
I have been asked about the possibility of using this plug-in in contexts other than the JDT. Support for doing this is currently in development, and expected to dramatically improve soon. Specifically, extension points will be defined to allow customization of plug-in UI and menus.
In the meanwhile, it is perfectly possible to do so yourself provided that:
An API was created to help with point 2. IJndiExplorerPlugin defines a set of methods to programmatically add/remove initial contexts from the plug-in view. Please refer to the Javadoc for more information.
Debugging output can be obtained by setting com.waldura.eclipse.jndiexplorer/debug
to true in ECLIPSE_HOME/plugins/com.waldura.eclipse.jndiexplorer_x.y.z/.options.
The output goes to the main Eclipse log file,
ECLIPSE_HOME/workspace/.metadata/.log.
The choices presented in the "configure new initial context" dialog are stored
in ECLIPSE_HOME/workspace/.metadata/.plugins/com.waldura.eclipse.jndiexplorer/dialog_settings.xml.
This list is seeded from ECLIPSE_HOME/plugins/com.waldura.eclipse.jndiexplorer_x.y.z/dialog_settings.xml
the first time the plug-in is run. The structure of this XML file is very simple and should be
self-explanatory.
Please refer to the Javadoc (only available in the download).