Have just completed the implementation of a utility that enables the establishment of a Merlin Kernel via JNDI. Currently this is nothing more that access to the root kernel based on a set of properties containing the system and home path, the root block and internal kernel logging priority.

Using the JNDI context, a servlet can do something like the following:

   Context context = new InitialContext();
   Context env = (Context) context.lookup("java:comp/env");
   Kernel kernel = (Kernel) env.lookup("merlin/ServiceFactory");
   // then use the kernel to get the service that you want

There are a number of areas I would like to improve this. Firstly, the current implementation relies on the fact that the server.xml has the definition of the root block to be loaded. I think that this could/should be changed such that the we application declares the root block(s) to be loaded and the server.xml simply handles the declaration of the Merlin system installation parameters.

A second concern is the return argument. Currently I'm returning the kernel, however it seems to me that it should be possible to return a naming context from which services are access via JNDI lookups. However - being somewhat unfamiliar with JNDI, I was wondering what others thought/preferred. If the initial lookup returns a context then it should be possible to eliminate knowledge of the kernel - and keep things focussed on simply accessing services. This also brings in the potential for including JNDI url resolution of services (i.e. service resolution with arguments) which seems to me a desirable direction.

Any thoughts on this highly appreciated.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to