You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/05/21 17:58:19 UTC
[ApacheDS] Embedded http service part2
I've been looking into how to embed the http service into ApacheDS so
applications
can be built for doing DSML, and exposing various other web applications
like for
configuration and self service.
There are some options here that I thought I should discuss on list
especially with the
efforts under way to change the installation layout of the ApacheDS packages
on Linux.
First let me clarify what I plan to do. I will add the http service using
an embedded Jetty
instance for now. The Jetty instance will start up after the directory
server's core has
started. It's startup and configuration will occur in the
ServerContextFactory which also
starts the other protocol services. Obviously the port used will be a
configurable parameter
with a smart default which can be overriden with a port number property in a
HttpServiceConfiguration bean along with other configuration parameters.
Starting the Jetty server is not all we need to do. Jetty must be
configured to serve out
various web applications most of which will not be provided out of the box
with the server.
Some may be but we have none right now. These webapps need to be configured
with Jetty
so it can expose the proper web contexts to be serviced by the web
applications. These
applications can exist on disk somewhere like in a webapps directory. I
will make this
directory a configuration parameter. What I am wondering is whether this
parameter should
be a relative directory relative to the installation base. Since we're
changing the way the
layout will be this may be an issue. I guess I can make it so this path can
be relative or
absolute.
The server can auto configure any webapps that have been unjarred into this
directory so
if a new web application is installed it can be picked up on the next
startup to enable the
webapplication. Any ideas on what to do here or any thoughts?
Another problem I have here is that some XSDs are needed off the web
when web applications are installed and wind up breaking the startup if
there is no inet
connection. I can work around this I guess but I have to figure out how.
So here are the properties that I foresee with their smart defaults in the
HttpServiceConfiguration
bean for now:
port (default 8383)
webapps (default ${installHome}/webapps})
** if a relative path is provided to the webapps property then it is
presumed to be
relative to the installation home.
Also there may be an additional parameter in the StartupConfiguration that
enables or disables
this http service.
Alex
Re: [ApacheDS Webapp or not Webapp] was [ApacheDS] Embedded http
service part2
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel Lecharny wrote:
SNIP
>>
>>
>> Hmmm - So I assume then that
>> that even though the webapp
>> and ADS are running on the same
>> host the webapp that runs with
>> ADS embedded will run faster than the
>> one connecting to ApacheDS via JDNI?
>>
>> I also assume that we're talking a significant
>> improvement like 5 to 10 % faster.
>
> I would say 5 to 10 times faster.
WHoahhhh!!! Smoookinnn!!
OK - Lights are starting to
turn on now :-)
SNIP
> Yes, this is the perfect scenario. Also consider people who don't want
> to bother with an external LDAP server installation.
Good point as well.
>
>>> Do you have something else in mind ?
>> The only thing I had in mind was to separate
>> the application layer from the data store,
>> through an integration layer so as to maintain
>> modularity and make each piece appeal to as many
>> people as possible.
>
> Usually, when you have a webapp and you need to address a LDAP server,
> it is a separated LDAP server, ADS is bringing this new possibility to
> embed it. I don't know about another LDAP server which allow you to do
> so (except OpenDS, AFAIK). So the scenario you are thinking of is the
> scenario everybody use.
>
>>
>> For low volume applications like administration, etc.
>> this makes sense because more people can use the webapp,
>> thus more people will be interested in improving it,
>> and performance is a fairly minor consideration.
>>
>> On the other hand if the webapp is a phone directory
>> and gazillions of connections are made per second then
>> maybe embedding is a good thing. This is why I asked about
>> the percentage gain in performance via embedding vs.
>> JNDI on the same host.
>
> It is huge. I dind't measured it yet, ut from the profiling session I
> have done, the ASN.1 codeing/decoding + network layer is really costing
> a lot.
Wow - OK - It all makes a lot more sense now :-)
> The good thing with ADS is that embedding cost almost nothing, as you
> communicate with ADS using exactly the same API as the one you will use
> to communicate with a remote LDAP server : JNDI. In fact, this is
> totally transparent, except the initialization.
Cool - so it sounds like it's easy to give all developers the best of
both worlds. Maybe even have thin layer with a a little toggle
for turning embedded ADS on and off, making the webapp appeal
to all developers.
I'm getting a lot more excited. :-)
Thanks for all the clarification Emmmanuel.
I'm definitely a lot more excited about
the the embedding scenario
now. Let me crunch this DAS out, and then once that's done I'll try
to do a thin embedding layer with the first DAS sample application.
Cheers,
- Ole
[ApacheDS Webapp or not Webapp] was [ApacheDS] Embedded http service
part2
Posted by Emmanuel Lecharny <el...@apache.org>.
Ole Ersoy a écrit :
> OK - Now I'm getting all mixed up
> about whether I should change the heading or not.
>
> I'm going to trust Emmanuel's judgement, and just leave it.
Sorry, I didn't read Alex comment, and he is right. So I changed the
subject :)
>
> Emmanuel Lecharny wrote:
>
>> Ole Ersoy a écrit :
>
>
> SNIPPING the SNIP
>
>> I see at least one obvious use-case : embedding ADS allow you to
>> avoid network costs because ADS will be adressed directly. This will
>> allow the app to use the full power of ADS, at full speed, which is
>> really a good use case. But there are many more...
>
>
> Hmmm - So I assume then that
> that even though the webapp
> and ADS are running on the same
> host the webapp that runs with
> ADS embedded will run faster than the
> one connecting to ApacheDS via JDNI?
>
> I also assume that we're talking a significant
> improvement like 5 to 10 % faster.
I would say 5 to 10 times faster.
>
>>
>> But this is the common case ! I don't really see exactly what you are
>> thinking of. What I see is that you have only two cases :
>> - ADS embedded
>> - ADS beside the server, but then it is seen as a standard LDAP
>> server, running in its own JVM. Nothing new under the sun (tm), so
>> far...
>
>
> I'm thinking ADS beside the server running the webapp.
> So the webapp connects to ADS via JNDI.
> But if there is performance to be gained from
> embedding ADS within the webapp then that of coarse is very valid.
Yes, this is the perfect scenario. Also consider people who don't want
to bother with an external LDAP server installation.
>> Do you have something else in mind ?
>
>
>
> The only thing I had in mind was to separate
> the application layer from the data store,
> through an integration layer so as to maintain
> modularity and make each piece appeal to as many
> people as possible.
Usually, when you have a webapp and you need to address a LDAP server,
it is a separated LDAP server, ADS is bringing this new possibility to
embed it. I don't know about another LDAP server which allow you to do
so (except OpenDS, AFAIK). So the scenario you are thinking of is the
scenario everybody use.
>
> For low volume applications like administration, etc.
> this makes sense because more people can use the webapp,
> thus more people will be interested in improving it,
> and performance is a fairly minor consideration.
>
> On the other hand if the webapp is a phone directory
> and gazillions of connections are made per second then
> maybe embedding is a good thing. This is why I asked about
> the percentage gain in performance via embedding vs.
> JNDI on the same host.
It is huge. I dind't measured it yet, ut from the profiling session I
have done, the ASN.1 codeing/decoding + network layer is really costing
a lot.
>
> The main thing I was trying to high light was that there
> could be a developer interest cost to embedding,
> so choosing the right set of use cases is important.
The good thing with ADS is that embedding cost almost nothing, as you
communicate with ADS using exactly the same API as the one you will use
to communicate with a remote LDAP server : JNDI. In fact, this is
totally transparent, except the initialization.
Emmanuel
Re: [ApacheDS] Embedded http service part2
Posted by Ole Ersoy <ol...@gmail.com>.
OK - Now I'm getting all mixed up
about whether I should change the heading or not.
I'm going to trust Emmanuel's judgement, and just leave it.
Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
SNIPPING the SNIP
> I see at least one obvious use-case : embedding ADS allow you to avoid
> network costs because ADS will be adressed directly. This will allow the
> app to use the full power of ADS, at full speed, which is really a good
> use case. But there are many more...
Hmmm - So I assume then that
that even though the webapp
and ADS are running on the same
host the webapp that runs with
ADS embedded will run faster than the
one connecting to ApacheDS via JDNI?
I also assume that we're talking a significant
improvement like 5 to 10 % faster.
>
>> If the webapp can be made independent of apacheds,
>
> All the webapps adressing a Ldap server through JNDI or any other LDAP
> api are independant of ADS, even if you use ADS beside the J2EE
> container. This was the general case until ADS brought an embedded LDAP
> server to users.
Sure.
>
>> this can
>> turn on other contributors that are not
>> currently ApacheDS core contributors, but really like the functionality
>> in the webapp and want to help make it better.
>
> But this is the common case ! I don't really see exactly what you are
> thinking of. What I see is that you have only two cases :
> - ADS embedded
> - ADS beside the server, but then it is seen as a standard LDAP server,
> running in its own JVM. Nothing new under the sun (tm), so far...
I'm thinking ADS beside the server running the webapp.
So the webapp connects to ADS via JNDI.
But if there is performance to be gained from
embedding ADS within the webapp then that of coarse is very valid.
>
> Do you have something else in mind ?
The only thing I had in mind was to separate
the application layer from the data store,
through an integration layer so as to maintain
modularity and make each piece appeal to as many
people as possible.
For low volume applications like administration, etc.
this makes sense because more people can use the webapp,
thus more people will be interested in improving it,
and performance is a fairly minor consideration.
On the other hand if the webapp is a phone directory
and gazillions of connections are made per second then
maybe embedding is a good thing. This is why I asked about
the percentage gain in performance via embedding vs.
JNDI on the same host.
The main thing I was trying to high light was that there
could be a developer interest cost to embedding,
so choosing the right set of use cases is important.
Cheers,
- Ole
Re: [ApacheDS] Embedded http service part2
Posted by Emmanuel Lecharny <el...@apache.org>.
Ole Ersoy a écrit :
> SNIP
>
>> If the webapps are as modular and independent from ApacheDS as
>> possible,
>> it would maximize developer interest and momentum.
>>
>>
>> If you are talking about having a webapp which does not embed ADS,
>> then this is not the good ML to talk about it : try Geronimo ML or
>> tomcat ML ;)
>> If you are thinking about communication between a webapp and a
>> LdapServer outside the container, then JNDI is the key.
>
>
> What I'm really talking about are use cases and how they can be
> satisfied.
>
> We know we can embed ApacheDS in a webapp.
> The question is what use case does this satisfy?
I see at least one obvious use-case : embedding ADS allow you to avoid
network costs because ADS will be adressed directly. This will allow the
app to use the full power of ADS, at full speed, which is really a good
use case. But there are many more...
> If the webapp can be made independent of apacheds,
All the webapps adressing a Ldap server through JNDI or any other LDAP
api are independant of ADS, even if you use ADS beside the J2EE
container. This was the general case until ADS brought an embedded LDAP
server to users.
> this can
> turn on other contributors that are not
> currently ApacheDS core contributors, but really like the functionality
> in the webapp and want to help make it better.
But this is the common case ! I don't really see exactly what you are
thinking of. What I see is that you have only two cases :
- ADS embedded
- ADS beside the server, but then it is seen as a standard LDAP server,
running in its own JVM. Nothing new under the sun (tm), so far...
Do you have something else in mind ?
Emmanuel
Re: [ApacheDS Webapps] Use Cases
Posted by Alex Karasulu <ak...@apache.org>.
Well I think they do what Oracle does with OID and Oracle RDBMS. They use
many read-only
tables and stage updates to the directory.
Alex
On 5/21/07, Andrew C. Oliver <ac...@buni.org> wrote:
>
>
> > I have seen DB2+TivoliDS used in a big company with more than 70 000 000
> > entries. Stable, reliable. I wish ADS is half as good as TivoliDS + DB2
> ;)
> >
> > Emmanuel
>
> They must have turned it to allow dirty reads.
>
> -Andy
> --
> Buni Meldware Communication Suite
> http://buni.org
> Multi-platform and extensible Email,
> Calendaring (including freebusy),
> Rich Webmail, Web-calendaring, ease
> of installation/administration.
>
Re: [ApacheDS Webapps] Use Cases
Posted by "Andrew C. Oliver" <ac...@buni.org>.
> I have seen DB2+TivoliDS used in a big company with more than 70 000 000
> entries. Stable, reliable. I wish ADS is half as good as TivoliDS + DB2 ;)
>
> Emmanuel
They must have turned it to allow dirty reads.
-Andy
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: [ApacheDS Webapps] Use Cases
Posted by Emmanuel Lecharny <el...@apache.org>.
Andrew C. Oliver a écrit :
> Stefan Zoerner wrote:
>
>> Ole Ersoy wrote:
>>
>>>
>>> Yeah - Would be great if they would just drop the whole thing
>>> and go with something superior like ADS :-). They did it with
>>> Geronimo, now it's ADS's turn.
>>>
>> I just talked about the WebApp. I do not think that ApacheDS is
>> superior to TivoliDS yet. TivoliDS has a very solid persistence (DB2)
>> and has some really large installations in production for ages.
>>
>> Greetings,
>> Stefan
>
>
> DB2's locking scheme isn't very good for assuring consistency on read
> mostly systems.
>
I have seen DB2+TivoliDS used in a big company with more than 70 000 000
entries. Stable, reliable. I wish ADS is half as good as TivoliDS + DB2 ;)
Emmanuel
Re: [ApacheDS Webapps] Use Cases
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Stefan Zoerner wrote:
> Ole Ersoy wrote:
>>
>> Yeah - Would be great if they would just drop the whole thing
>> and go with something superior like ADS :-). They did it with
>> Geronimo, now it's ADS's turn.
>>
> I just talked about the WebApp. I do not think that ApacheDS is superior
> to TivoliDS yet. TivoliDS has a very solid persistence (DB2) and has
> some really large installations in production for ages.
>
> Greetings,
> Stefan
DB2's locking scheme isn't very good for assuring consistency on read
mostly systems.
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: [ApacheDS Webapps] Use Cases
Posted by Ole Ersoy <ol...@gmail.com>.
Stefan Zoerner wrote:
> Ole Ersoy wrote:
>>
>> Yeah - Would be great if they would just drop the whole thing
>> and go with something superior like ADS :-). They did it with
>> Geronimo, now it's ADS's turn.
>>
> I just talked about the WebApp. I do not think that ApacheDS is superior
> to TivoliDS yet. TivoliDS has a very solid persistence (DB2) and has
> some really large installations in production for ages.
Yes - but we all know ApacheDS will smoke it soon :-)
Cheers,
- Ole
Re: [ApacheDS Webapps] Use Cases
Posted by Stefan Zoerner <st...@labeo.de>.
Ole Ersoy wrote:
>
> Yeah - Would be great if they would just drop the whole thing
> and go with something superior like ADS :-). They did it with
> Geronimo, now it's ADS's turn.
>
I just talked about the WebApp. I do not think that ApacheDS is superior
to TivoliDS yet. TivoliDS has a very solid persistence (DB2) and has
some really large installations in production for ages.
Greetings,
Stefan
Re: [ApacheDS Webapps] Use Cases
Posted by Ole Ersoy <ol...@gmail.com>.
Stefan Zoerner wrote:
> Ole Ersoy wrote:
>>
>> We know we can embed ApacheDS in a webapp.
>> The question is what use case does this satisfy?
>
> None in production, I am afraid. The example in the docs is about how to
> embed ApacheDS as a web application, just for the sake of demonstration.
>
> Although I know developers, who run a Tomcat test environment within
> Eclipse, and now run ApacheDS within Tomcat within Eclipse as a test
> environment.
That's cool. Wish I had more time to play with cool stuff like that.
>
>> Then if embedding ApacheDS is the only way to go
>> by all means do it.
>>
>> If the webapp can be made independent of apacheds, this can
>> turn on other contributors that are not
>> currently ApacheDS core contributors, but really like the functionality
>> in the webapp and want to help make it better.
>
> This would in fact be an interesting option, although web applications
> to administer LDAP directory content in general already exist (in PHP,
> for instance). IBM Tivoli Directory Server only ships with such a WebApp
> as graphical frontend. By the way, it is Tivoli specific and closed
> source ;-).
Yeah - Would be great if they would just drop the whole thing
and go with something superior like ADS :-). They did it with
Geronimo, now it's ADS's turn.
>
> Another nice subproject would be a portlet, especially for integration
> into Geronimo admin application. There are synergies with the WebApp,
> obviously. So many ideas ... :-)
Indeed. Yes - I was thinking more along these lines as well.
I imagine these types of webapps would be really popular with
the Geronimo duds and would help bring more attention and visibility
to ApacheDS.
Cheers,
- Ole
SNIP
Re: [ApacheDS] Embedded http service part2
Posted by Stefan Zoerner <st...@labeo.de>.
Ole Ersoy wrote:
>
> We know we can embed ApacheDS in a webapp.
> The question is what use case does this satisfy?
None in production, I am afraid. The example in the docs is about how to
embed ApacheDS as a web application, just for the sake of demonstration.
Although I know developers, who run a Tomcat test environment within
Eclipse, and now run ApacheDS within Tomcat within Eclipse as a test
environment.
> Then if embedding ApacheDS is the only way to go
> by all means do it.
>
> If the webapp can be made independent of apacheds, this can
> turn on other contributors that are not
> currently ApacheDS core contributors, but really like the functionality
> in the webapp and want to help make it better.
This would in fact be an interesting option, although web applications
to administer LDAP directory content in general already exist (in PHP,
for instance). IBM Tivoli Directory Server only ships with such a WebApp
as graphical frontend. By the way, it is Tivoli specific and closed
source ;-).
Another nice subproject would be a portlet, especially for integration
into Geronimo admin application. There are synergies with the WebApp,
obviously. So many ideas ... :-)
Greetings,
Stefan
Re: [ApacheDS] Embedded http service part2
Posted by Ole Ersoy <ol...@gmail.com>.
SNIP
> If the webapps are as modular and independent from ApacheDS as possible,
> it would maximize developer interest and momentum.
>
>
> If you are talking about having a webapp which does not embed ADS, then
> this is not the good ML to talk about it : try Geronimo ML or tomcat ML ;)
> If you are thinking about communication between a webapp and a
> LdapServer outside the container, then JNDI is the key.
What I'm really talking about are use cases and how they can be satisfied.
We know we can embed ApacheDS in a webapp.
The question is what use case does this satisfy?
Then if embedding ApacheDS is the only way to go
by all means do it.
If the webapp can be made independent of apacheds, this can
turn on other contributors that are not
currently ApacheDS core contributors, but really like the functionality
in the webapp and want to help make it better.
So it just depends on what the use cases for the webapp are.
See what I mean?
Cheers,
- Ole
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
Re: [ApacheDS] Embedded http service part2
Posted by Emmanuel Lecharny <el...@gmail.com>.
>
> > So far, the JVM use the memory as a whole, even if you have many
> > containers. If tomcat or jetty sucks all the memory, then you are dead.
>
> I guess if a shop has Tomcat and wants to run Tomcat
> only, as long as the webapps are independent of the container,
> they can just drop them in.
A webapp is, by essence, totally independent if the the container. This is
what the J2EE spec is all about.
Hence they would not incur any extra memory cost from running Jetty
> as well.
As it has been stated before, you can disable Jetty from the beginning.
For instance if a shop running Germonimo wanted to run the webapps,
> all the instructions would need to say is "Drop in the webapps", start
> ApacheDS with Jetty turned off, and you're set.
This is exactly what you can done right now, and the link pushed by Stefan
explains how to do it.
If the webapps are as modular and independent from ApacheDS as possible,
> it would maximize developer interest and momentum.
If you are talking about having a webapp which does not embed ADS, then this
is not the good ML to talk about it : try Geronimo ML or tomcat ML ;)
If you are thinking about communication between a webapp and a LdapServer
outside the container, then JNDI is the key.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Embedded http service part2
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel Lecharny wrote:
>
>
> On 5/21/07, *Ole Ersoy* <ole.ersoy@gmail.com
> <ma...@gmail.com>> wrote:
>
> If someone wants to disable
> the HTTP service completely by turning
> it off, saving memory, etc. will this be possible?
>
>
> Obviously, yes.
Rock On!
SNIP
> So far, the JVM use the memory as a whole, even if you have many
> containers. If tomcat or jetty sucks all the memory, then you are dead.
I guess if a shop has Tomcat and wants to run Tomcat
only, as long as the webapps are independent of the container,
they can just drop them in.
Hence they would not incur any extra memory cost from running Jetty
as well.
For instance if a shop running Germonimo wanted to run the webapps,
all the instructions would need to say is "Drop in the webapps", start
ApacheDS with Jetty turned off, and you're set.
If the webapps are as modular and independent from ApacheDS as possible,
it would maximize developer interest and momentum.
>
>
> Also - Some shops already run Tomcat or other web containers,
> and they may prefer dropping in the ApacheDS webapps, rather
> that having ADS start yet another container.
>
>
> This is a totally different concern. Nothing forbid you to create a
> webapp including an embedded ADS. This has already been done (I had two
> student this year who provided such a webapp). We wanted to embed a
> container so that we don't depend on any other container if we want to
> offer DSML through HTTP, standalone. Having to setup N product when you
> want to play with ADS and DSML is not very convenient.
Absolutely. I see how this makes it really simple for
peeps who want to play with ApacheDS and webapps, without
reading 500 pages of Apache Tomcat Bible :-)
>
> However, the idea of building a standalone webapp with ADS embedded is
> not stupid, and woth to spend some time on it. Wanna do it ?
As soon as I'm done with the DAS (At least reading and writing graphs)
I need to start on a webapp that demos DAS capabilities
for ApacheDS. That might fit well with the type of effort being
considered. The DAS's connection manager connects to ADS and uses
it just like an RDB DAS would use a RDB. So the WebApp
would be focused on a simple static or dynamic (Since SDO supports
dynamic real time modeling and open types) model and be completely
decoupled from ApacheDS via the DAS.
Cheers,
- Ole
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
Re: [ApacheDS] Embedded http service part2
Posted by Ole Ersoy <ol...@gmail.com>.
Stefan Zoerner wrote:
> Ole Ersoy wrote:
>
>> Wow - I'm really impressed with the documentation.
>> Well Done!
>
> Thanks Ole. I turn scarlet and would really love to provide more such
> stuff especially for people new to ApacheDS. It makes so much fun!
> Unfortunately, I have to edit the 3rd edition of my book first :-(
Well I'm certain everyone appreciates it a lot.
It's been of massive help to me getting started with the server,
and LDAP in general. Good luck with the 3rd Edition!! If you need any
sections reviewed I'll be happy to assist.
Cheers,
- Ole
Re: [ApacheDS] Embedded http service part2
Posted by Stefan Zoerner <st...@labeo.de>.
Ole Ersoy wrote:
> Wow - I'm really impressed with the documentation.
> Well Done!
Thanks Ole. I turn scarlet and would really love to provide more such
stuff especially for people new to ApacheDS. It makes so much fun!
Unfortunately, I have to edit the 3rd edition of my book first :-(
Greetings from Hamburg,
Stefan
Re: [ApacheDS] Embedded http service part2
Posted by Ole Ersoy <ol...@gmail.com>.
Wow - I'm really impressed with the documentation.
Well Done!
Stefan Zoerner wrote:
> Emmanuel Lecharny wrote:
>> This is a totally different concern. Nothing forbid you to create a
>> webapp including an embedded ADS. This has already been done (I had
>> two student this year who provided such a webapp). We wanted to embed
>> a container so that we don't depend on any other container if we want
>> to offer DSML through HTTP, standalone. Having to setup N product when
>> you want to play with ADS and DSML is not very convenient.
>>
>> However, the idea of building a standalone webapp with ADS embedded is
>> not stupid, and woth to spend some time on it. Wanna do it ?
>
> We already have this as a simple embedding example in our documentation,
> by the way:
> http://directory.apache.org/apacheds/1.0/embedding-apacheds-as-a-web-application.html
>
>
> Greetings,
> Stefan
>
>
Re: [ApacheDS] Embedded http service part2
Posted by Emmanuel Lecharny <el...@gmail.com>.
very true !!!
Thanks Stefan :)
On 5/21/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Emmanuel Lecharny wrote:
> > This is a totally different concern. Nothing forbid you to create a
> > webapp including an embedded ADS. This has already been done (I had two
> > student this year who provided such a webapp). We wanted to embed a
> > container so that we don't depend on any other container if we want to
> > offer DSML through HTTP, standalone. Having to setup N product when you
> > want to play with ADS and DSML is not very convenient.
> >
> > However, the idea of building a standalone webapp with ADS embedded is
> > not stupid, and woth to spend some time on it. Wanna do it ?
>
> We already have this as a simple embedding example in our documentation,
> by the way:
>
> http://directory.apache.org/apacheds/1.0/embedding-apacheds-as-a-web-application.html
>
> Greetings,
> Stefan
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Embedded http service part2
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
> This is a totally different concern. Nothing forbid you to create a
> webapp including an embedded ADS. This has already been done (I had two
> student this year who provided such a webapp). We wanted to embed a
> container so that we don't depend on any other container if we want to
> offer DSML through HTTP, standalone. Having to setup N product when you
> want to play with ADS and DSML is not very convenient.
>
> However, the idea of building a standalone webapp with ADS embedded is
> not stupid, and woth to spend some time on it. Wanna do it ?
We already have this as a simple embedding example in our documentation,
by the way:
http://directory.apache.org/apacheds/1.0/embedding-apacheds-as-a-web-application.html
Greetings,
Stefan
Re: [ApacheDS] Embedded http service part2
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 5/21/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> If someone wants to disable
> the HTTP service completely by turning
> it off, saving memory, etc. will this be possible?
Obviously, yes.
OT - Just something that popped in as I was thinking about this
> ===============================================================
> Suppose the only thing a user wishes
> to run is the LDAP protocol. Can the server
> be configured to run such that it minimizes the memory footprint?
Of course. Just have a loook at server.xml
>
> If the webapps are created and run
> separately in a servlet container
> then the memory footprint concern goes away,
So far, the JVM use the memory as a whole, even if you have many containers.
If tomcat or jetty sucks all the memory, then you are dead.
>
> Also - Some shops already run Tomcat or other web containers,
> and they may prefer dropping in the ApacheDS webapps, rather
> that having ADS start yet another container.
This is a totally different concern. Nothing forbid you to create a webapp
including an embedded ADS. This has already been done (I had two student
this year who provided such a webapp). We wanted to embed a container so
that we don't depend on any other container if we want to offer DSML through
HTTP, standalone. Having to setup N product when you want to play with ADS
and DSML is not very convenient.
However, the idea of building a standalone webapp with ADS embedded is not
stupid, and woth to spend some time on it. Wanna do it ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Embedded http service part2
Posted by Ole Ersoy <ol...@gmail.com>.
Oh Cool - That rocks then!
Alex Karasulu wrote:
>
>
> On 5/21/07, *Ole Ersoy* <ole.ersoy@gmail.com
> <ma...@gmail.com>> wrote:
>
> If someone wants to disable
> the HTTP service completely by turning
> it off, saving memory, etc. will this be possible?
>
>
> Yeah by default this service is off.
>
> OT - Just something that popped in as I was thinking about this
> ===============================================================
> Suppose the only thing a user wishes
> to run is the LDAP protocol. Can the server
> be configured to run such that it minimizes the memory footprint?
> Maybe it already does...I just thought I'd mention it.
> We should start a new thread if anyone wishes to discuss this.
> I'm just injecting it in this context for awareness.
> ==============================================================
>
>
> This is the default configuration. All other services need to be turned on.
>
> SNIP ...
>
> Alex
>
Re: [ApacheDS] Embedded http service part2
Posted by Alex Karasulu <ak...@apache.org>.
On 5/21/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> If someone wants to disable
> the HTTP service completely by turning
> it off, saving memory, etc. will this be possible?
Yeah by default this service is off.
OT - Just something that popped in as I was thinking about this
> ===============================================================
> Suppose the only thing a user wishes
> to run is the LDAP protocol. Can the server
> be configured to run such that it minimizes the memory footprint?
> Maybe it already does...I just thought I'd mention it.
> We should start a new thread if anyone wishes to discuss this.
> I'm just injecting it in this context for awareness.
> ==============================================================
This is the default configuration. All other services need to be turned on.
SNIP ...
Alex
Re: [ApacheDS] Embedded http service part2
Posted by Ole Ersoy <ol...@gmail.com>.
If someone wants to disable
the HTTP service completely by turning
it off, saving memory, etc. will this be possible?
OT - Just something that popped in as I was thinking about this
===============================================================
Suppose the only thing a user wishes
to run is the LDAP protocol. Can the server
be configured to run such that it minimizes the memory footprint?
Maybe it already does...I just thought I'd mention it.
We should start a new thread if anyone wishes to discuss this.
I'm just injecting it in this context for awareness.
==============================================================
If the webapps are created and run
separately in a servlet container
then the memory footprint concern goes away,
at least for the Servlet container.
Also the servlet container could be started
separately as required, taking care of the
XML Schema concern.
Also - Some shops already run Tomcat or other web containers,
and they may prefer dropping in the ApacheDS webapps, rather
that having ADS start yet another container.
The directory that JPackage uses
(So I assume it's FHS) for webapps is
/var/lib/webapps
Cheers,
- Ole
Alex Karasulu wrote:
> I've been looking into how to embed the http service into ApacheDS so
> applications
> can be built for doing DSML, and exposing various other web applications
> like for
> configuration and self service.
>
> There are some options here that I thought I should discuss on list
> especially with the
> efforts under way to change the installation layout of the ApacheDS
> packages on Linux.
>
> First let me clarify what I plan to do. I will add the http service
> using an embedded Jetty
> instance for now. The Jetty instance will start up after the directory
> server's core has
> started. It's startup and configuration will occur in the
> ServerContextFactory which also
> starts the other protocol services. Obviously the port used will be a
> configurable parameter
> with a smart default which can be overriden with a port number property
> in a
> HttpServiceConfiguration bean along with other configuration parameters.
>
> Starting the Jetty server is not all we need to do. Jetty must be
> configured to serve out
> various web applications most of which will not be provided out of the
> box with the server.
> Some may be but we have none right now. These webapps need to be
> configured with Jetty
> so it can expose the proper web contexts to be serviced by the web
> applications. These
> applications can exist on disk somewhere like in a webapps directory. I
> will make this
> directory a configuration parameter. What I am wondering is whether
> this parameter should
> be a relative directory relative to the installation base. Since we're
> changing the way the
> layout will be this may be an issue. I guess I can make it so this path
> can be relative or
> absolute.
>
> The server can auto configure any webapps that have been unjarred into
> this directory so
> if a new web application is installed it can be picked up on the next
> startup to enable the
> webapplication. Any ideas on what to do here or any thoughts?
>
> Another problem I have here is that some XSDs are needed off the web
> when web applications are installed and wind up breaking the startup if
> there is no inet
> connection. I can work around this I guess but I have to figure out how.
>
> So here are the properties that I foresee with their smart defaults in
> the HttpServiceConfiguration
> bean for now:
>
> port (default 8383)
> webapps (default ${installHome}/webapps})
>
> ** if a relative path is provided to the webapps property then it is
> presumed to be
> relative to the installation home.
>
> Also there may be an additional parameter in the StartupConfiguration
> that enables or disables
> this http service.
>
> Alex
>
>
Re: [ApacheDS] Embedded http service part2
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Jetty performance/scale is an interesting thing:
http://www.webperformanceinc.com/library/reports/ServletReport/index.html?wmi=6,1
-Andy
Alex Karasulu wrote:
> I've been looking into how to embed the http service into ApacheDS so
> applications
> can be built for doing DSML, and exposing various other web applications
> like for
> configuration and self service.
>
> There are some options here that I thought I should discuss on list
> especially with the
> efforts under way to change the installation layout of the ApacheDS
> packages
> on Linux.
>
> First let me clarify what I plan to do. I will add the http service using
> an embedded Jetty
> instance for now. The Jetty instance will start up after the directory
> server's core has
> started. It's startup and configuration will occur in the
> ServerContextFactory which also
> starts the other protocol services. Obviously the port used will be a
> configurable parameter
> with a smart default which can be overriden with a port number property
> in a
>
> HttpServiceConfiguration bean along with other configuration parameters.
>
> Starting the Jetty server is not all we need to do. Jetty must be
> configured to serve out
> various web applications most of which will not be provided out of the box
> with the server.
> Some may be but we have none right now. These webapps need to be
> configured
> with Jetty
> so it can expose the proper web contexts to be serviced by the web
> applications. These
> applications can exist on disk somewhere like in a webapps directory. I
> will make this
> directory a configuration parameter. What I am wondering is whether this
> parameter should
> be a relative directory relative to the installation base. Since we're
> changing the way the
> layout will be this may be an issue. I guess I can make it so this path
> can
> be relative or
> absolute.
>
> The server can auto configure any webapps that have been unjarred into this
> directory so
> if a new web application is installed it can be picked up on the next
> startup to enable the
> webapplication. Any ideas on what to do here or any thoughts?
>
> Another problem I have here is that some XSDs are needed off the web
> when web applications are installed and wind up breaking the startup if
> there is no inet
> connection. I can work around this I guess but I have to figure out how.
>
> So here are the properties that I foresee with their smart defaults in the
> HttpServiceConfiguration
> bean for now:
>
> port (default 8383)
> webapps (default ${installHome}/webapps})
>
> ** if a relative path is provided to the webapps property then it is
> presumed to be
> relative to the installation home.
>
> Also there may be an additional parameter in the StartupConfiguration that
> enables or disables
> this http service.
>
> Alex
>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.