Steve, First let me elaborate on what we're doing. LDAPd is an Avalon based LDAP server that currently uses Phoenix for its microkernel. This is fine for a standalone configuration however we would like existing applications like JBoss, Tomcat, and Geronimo to be able to embed LDAPd. Looking at some of the utility APIs Avalon has and PUnit's implementation it occurred to us that we could roll our own "glue" so to speak to bring up LDAPd's blocks hence the server. Rather than do that we would first like to see if an embeddable container exists already which can be programmatically setup and started on demand.
In terms of LDAPd integration into an embedding server, we intend to leverage JNDI. LDAPd has a server-side JNDI LDAP provider which basically behaves like the SUN provider but bypasses the protocol to directly access the server's database. In theory one should be able to merely change the Context.INITIAL_CONTEXT_FACTORY property within a property file and run code that already works using the SUN LDAP provider without a recompile. The source and executable would be compatible between drivers. Now the key here is to enable the server to come up when a host application tries to access LDAPd on the first InitialContext creation attempt. So when the ContextFactory referred to by the Context.INITIAL_CONTEXT_FACTORY property is instantiated using a default constructor, that code can check if the server is up. Checking for the server would merely involve a lookup for a singleton instance within the system. If the singleton is null then the server is down and it needs to be brought up before the InitialContext request can be satisfied. Hence the ContextFactory implementation, before attempting to access the requested context, must fire up the embedded server which takes LDAPd's blocks through the Avalon life-cycle stages in accordance with inter-component dependencies. So now let me try to answer your questions below: 1. What is the containment context you thinking of? In particular, are you considering embedding within a foreign container (e.g. web-app) or embedding in an application (i.e. something your in control of). Yes the container would be foreign and we would not have control over its source. In fact the embedding application should not be aware of the existence of the embedded container. 2. What are the sort of components you thinking of managing? In particular are you more focussed on light-weight pooled components, or are you looking more towards managed business components, business processes, etc? The components would be parts of the LDAPd server. These components are not really light weight. Some of these components are LDAP backends or databases so the words "light weight" are unfortunately not very fitting here. Other components are "lighter" but in general these are not things that get garbage collected or have life-cycles where they can be put into a dormant/hibernating state like EJBs - they are turned on and stay on. I hope this helps you help us ;-). Thank you very much for taking the time. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
