Shared/Global JNDI Environment Variables
Required Files
First the files. You’ll need the following jar. Save it in your application server’s lib directory. On my machine that is C:\sun\appserver\lib.
There are two classes in this jar:
com.ebleenterprises.naming.HashtableFactory com.ebleenterprises.naming.StringFactory
Setting Up Glassfish
Start glassfish and log in to the admin console.
Navigate to Resources -> JNDI ->Custom Resources.
Add a new resource, you can use the type java.util.Hashtable or java.lang.String.
Now specify the factory class that corresponds with the type, either com.ebleenterprises.naming.HashtableFactory or com.ebleenterprises.naming.StringFactory.
Finally Add Properties. If you used the Hashtable it will return to you a hashtable of all the properties you specify. If you used StringFactory you will get back the first property you specify (if you specify more than one subsequent properties will be ignored). If no properties are set, in both cases you will get an Exception when accessing the resource.
Figure 1 below shows a sample setup for the HashtableFactory.
Accessing The Resources
Any application deployed to glassfish can then access the variables through a standard JNDI lookup:
javax.naming.Context ctx = new javax.naming.InitialContext();
Hashtable GlobalVars = (Hashtable) ctx.lookup("GlobalVars");
String name = GlobalVars.get("name");
String url = GlobalVars.get("url);
Or if you are using a Servlet, SessionBean, ContextListener, or other that supports injection you can use:
@Resource(name="GlobalVars") Hashtable GlobalVars;

May 8th, 2010 at 21:14
This is very interesting. We had the need for global server variables on a project a while ago but never figured out how to get it to work. Could you point me to some references that explain the operation of your jar file?
I also found your entry on alternate doc roots valuable – I was just starting a project where I need to do this.
You have a lot of very interesting techniques that are valuable to server developers – please keep them coming!
May 11th, 2010 at 23:51
Custom JNDI Resources just need to implement the interface javax.naming.spi.ObjectFactory. What ever you return from the method getObjectInstance is what you’ll get from the resource.
Glad to hear you found the information valuable.