directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <>
Subject Re: [ApacheDS] Embedded http service
Date Wed, 16 May 2007 21:12:22 GMT
OSGi has an http service that we could use, and I think there are also a lot
of new things coming that will make this even better down the road.  I want
to do OSGi as much as anyone, but I really think waiting is the right thing
to do.  Embedding Jetty is a piece of cake anyway, and I like your ideas to
make the dependency optional.


On 5/16/07, Alex Karasulu <> wrote:
> For some time now a few people have been discussing embedding an HTTP
> service into ApacheDS for
> a number of reasons:
> (1) to expose a DSML service
> (2) host a web based configuration and management interface
> (3) for first start configuration
> (4) for other self service interfaces useful for directory users
> Just this morning I responded to an email from Peter Neubauer regarding #4
> to have a simple
> self service application so users can manage various aspects of their
> account.  Such an application
> would be trivial to implement if ApacheDS came with an optional HTTP
> service which could be
> enabled via it's configuration.
> After this email Emmanuel and I had a brief conversation about this.  We
> discussed how
> easy it would be to integrate Jetty with ApacheDS since this was already
> done for Triplesec.
> Furthermore we discussed how just having the service present would allow
> other parties to
> extend ApacheDS functionality for custom use in their environments.
> I have several things on my plate at the moment but I think I should try
> to grok this in the
> next day or two just to the open the door to these other possibilities.
> Adding this new service to ApacheDS will impose some additional
> dependencies since the
> service will be optionally started by the server side JNDI provider using
> the configuration.
> Namely there will be a dependency on Jetty even if this service is not
> turned on.  There are
> several ways to avoid this dependency.
> (1) Leverage OSGi to just provide the service in a decoupled fashion
> (2) Add a "plugin" mechanism into the server-jndi module to load protocol
>      providers dynamically at runtime
> Both approaches have pros and cons.  The first will take time until we get
> to OSGi.  The
> second requires additional work which would be redundant once an OSGi
> container is used.
> For these reasons I think it might be best if we just add this dependency
> for now and refactor
> later depending on what happens in the future.
> Alex

View raw message