avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Embeddable Containers
Date Tue, 19 Aug 2003 09:26:05 GMT

Alex Karasulu wrote:

>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.

This is totally within scope.  There are two examples of programatically 
embedding of Merlin that already exist in the CVS.

>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.

No problem.

>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.

This confirms that Merlin is the right choice for this scenario. 

>I hope this helps you help us ;-).  

It confirms that you can do everything you want to do with Merlin as it 
is today.  There are some more interesting questions we can get into 
after on concerning service access and release policies/protocols - but 
the first step is to get you up and running.

>Thank you very much for taking the time.

No problem.


>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message