avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <aok...@bellsouth.net>
Subject Re: Re: Embeddable Containers
Date Thu, 01 Jan 1970 00:00:00 GMT
You rock braw! You said exactly what I wanted to hear. 
 
Thanks, 
Alex 
 
>  
> From: Stephen McConnell <mcconnell@apache.org> 
> Date: 2003/08/19 Tue AM 05:26:05 EDT 
> To: Avalon Developers List <dev@avalon.apache.org> 
> Subject: Re: Embeddable Containers 
>  
>  
>  
> Alex Karasulu wrote: 
>  
> >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. 
> > 
>  
> 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. 
> > 
>  
> Yep. 
> 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. 
> > 
>  
> Perfect. 
>  
> > 
> > 
> >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. 
>  
> Stephen. 
>  
> > 
> > 
> >Alex 
> > 
> > 
> > 
> >--------------------------------------------------------------------- 
> >To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org 
> >For additional commands, e-mail: dev-help@avalon.apache.org 
> > 
> > 
> > 
>  
> --  
>  
> Stephen J. McConnell 
> mailto:mcconnell@apache.org 
> http://www.osm.net 
>  
> Sent via James running under Merlin as an NT service. 
> http://avalon.apache.org/sandbox/merlin 
>  
>  
>  
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org 
> For additional commands, e-mail: dev-help@avalon.apache.org 
>  
>  


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


Mime
View raw message