You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by James Todd <ja...@eng.sun.com> on 1999/07/19 10:41:42 UTC
request for review: server/config discussion
hi -
attached is a first cut at collecting the various
thoughts surrounding a "pure java http server
configuration" project.
this is not meant to be a holy relic or artifact
or even the truth but is more a collection of thoughts
and decission points, which are not final, expressed
to date presented in a format which should allow for
peer review and editing (althought this later part will
be a bit sticky till we have a bit more infrastructure
to help out).
anyways, i welcome any/all feedback and anticipate
subsequent drill-downs on some of the topics which
are barely touched upon.
the area i'd really like to see some active drill
down on is:
2. Configuration Data Consumer Model
or "entity data model"
i'm a big fan of tufte and uml ... so, in order to
convey some of these design thoughts i'm likely to
start stitching together some graphics ... although
this'll be a bit rough to archive and reference till
these docs have a web home.
note: i was fortunate enough to attend a
day long seminar presented by
edward tufte (http://www.cs.yale.edu/people/faculty/tufte.html) ...
he's
the man in my book when it comes
to "conveying thought." attending
one of his seminars is almost a
religious experience.
also, i happen to really like
martin fowler's "uml distilled"
as a guide map. it is a great
light-weight read. i'm also
impressed with "use case driven
object modeling with uml" by
rosenberg and scott. very practical.
wow, i guess i should've inlined
some amazon associate links in
here to see if i could retire on
these references :)
house-keeping details:
i put forth the motion to continue the design
details of this specifi discussion under the
tomcat-dev@jakarta.apache.org list
when providing feedback, it is recommended to inline
the comments/corrections/questions amongst a complete
and existing document
i will rev the document in order to maintain content
integrity (this item should go away when we have a
bit more infrastructure) as modifications are published
any/all comments are welcome including:
format/fields
scope
credits
this doc isn't done by a long shot so do feel free
to contribute
hope this helps,
- james
Re: request for review: server/config discussion
Posted by James Davidson <du...@x180.com>.
Greg Wilkins wrote:
> Just an after-send-button-thought...
> Should this discussion be moved to jakarta-general?
I don't think so.. I think that this is an issue affecting just the
Tomcat portions of the project and not the JSP portions.
The general list should be for items that are of concern to all (or more
than 1 when we get more subgroup).
.duncan
--
James Davidson
duncan@eng.sun.com http://java.sun.com/products/servlet
duncan@x180.com http://jakarta.apache.org
!try; do() PGP:0x7D776205
Re: request for review: server/config discussion
Posted by Greg Wilkins <gr...@mortbay.com>.
Just an after-send-button-thought...
Should this discussion be moved to jakarta-general?
--
Greg Wilkins<gr...@mortbay.com> GB Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK. Mbl Phone: +44-(0)7775534369
http://www.mortbay.com AU Phone: +61-(0)299772395
Re: request for review: server/config discussion
Posted by James Todd <ja...@eng.sun.com>.
i completely agree. the "100% pure java" perspective was
taken, possibly prematurely, whilst a bit of "you can't
rewrite how apache does it's config" discussion was going
on ... which was not my intention at all.
i believe to preclude servers written in less then 100% pure
java from this service is technically not mandatory and i'll
try to reflect this accordingly.
regarding drill down content ... there is no way that i
solely can author all this stuff. i have ideas and i think
i have a 50k foot view of a "best fit scenario and a first
milestone definition" in mind but i welcome/encourage/beg
multi-author contributions on this thread ... as long as we
can continually progress in refining the scope (all be it
possibly big) and subsequent design decisions pertaining to
this initiative. i really don't want to hack in some
implementation early on that causes us to go through unnecessary
contortions later on which we could've seen early had we
pulled together some sort of "agreeable roadmap."
once we get a bit more shared document management (eg
cvs managed web content) this should be trivial. till then,
we'll have to make do. i can aggregate this stuff till
then (as editor, hence the Editor's Note nomenclature)
and i plan on continuing to add content as one author.
regarding the alias, it was recommended to me back when
to move this discussion to tomcat-dev@jakarta.apache.org
which is a move i feel very comfortable with.
that said, i'll roll in your comments and we'll proceed
accordingly ... k?
hope this helps,
-james
Greg Wilkins wrote:
>
> James Todd wrote:
> > attached is a first cut at collecting the various
> > thoughts surrounding a "pure java http server
> > configuration" project.
>
> James,
>
> A good start to formalizing these discussions, but a number
> of suggestions
>
> The language/terminology of the document is firmly directed at
> configuration of a 100% java HTTP server. It may be
> better to adjust the language to be a little more
> deployment nuetral and in line with the project definitions
> we have seen to date. For example, it is probably worthwhile
> to structure the "Data Consumer Model" section along the lines of
>
> Jakarta module configuration
> |
> + Jakarta Communciations connector configuration
> | + Adaptor configuration
> | | + Apache
> | | + Netscape
> | | + ...
> | + HTTP Server config
> |
> + Servlet Container configuration
> | |
> | + Servlet Configuration
> | | + JSP Servlet Configuration
> | | + CGI Servlet Configuration
> | + ???
> |
> + New and wonderful module configuration
>
> Configuration of a HTTP server is only one aspect of configuring
> "Jakarta"
>
> Note that I think all configuration should be module based and
> all jakarta modules should share a common set of params. As much
> of jakarta will be dynamic and hopefully restartable, things like
> module name, CLASSPATHs and class loaders for each module
> should be common.
>
> While I think you document does make the distinction between the
> configuration model, it's flat file format and the service that
> provides configuration - It think the distinctions need to be
> made clearer:
>
> + As Craig has suggested, we need to talk about the services
> that provide configuration and their dynamic behaviour.
> I see a mechanism similar to a window redraw API. The service
> can tell us exactly what has changed in the config file (the region),
> and config clients have the option of just refreshing that part of
> the config, or giving up and refreshing the whole module.
>
> + As somebody else pointed out - the call to go XML has not
> yet been made - so it is important to clearly separate
> the data model from potential file formats. Again this
> will require work on the API so that it is decoupled from
> any XML package.
>
> You doc does cover these points - but I think a lengthy configuration
> architecture and philosophy statement is needed up front (including
> the protocol and management architecture etc.). I'm happy either
> to contribute to this if James continues as primary author - or
> write a first draft if my ramblings here a along the lines of
> what others are thinking...
>
> regards
>
> --
> Greg Wilkins<gr...@mortbay.com> GB Phone: +44-(0)171-4394045
> Mort Bay Consulting Australia and UK. Mbl Phone: +44-(0)7775534369
> http://www.mortbay.com AU Phone: +61-(0)299772395
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: request for review: server/config discussion
Posted by Greg Wilkins <gr...@mortbay.com>.
James Todd wrote:
> attached is a first cut at collecting the various
> thoughts surrounding a "pure java http server
> configuration" project.
James,
A good start to formalizing these discussions, but a number
of suggestions
The language/terminology of the document is firmly directed at
configuration of a 100% java HTTP server. It may be
better to adjust the language to be a little more
deployment nuetral and in line with the project definitions
we have seen to date. For example, it is probably worthwhile
to structure the "Data Consumer Model" section along the lines of
Jakarta module configuration
|
+ Jakarta Communciations connector configuration
| + Adaptor configuration
| | + Apache
| | + Netscape
| | + ...
| + HTTP Server config
|
+ Servlet Container configuration
| |
| + Servlet Configuration
| | + JSP Servlet Configuration
| | + CGI Servlet Configuration
| + ???
|
+ New and wonderful module configuration
Configuration of a HTTP server is only one aspect of configuring
"Jakarta"
Note that I think all configuration should be module based and
all jakarta modules should share a common set of params. As much
of jakarta will be dynamic and hopefully restartable, things like
module name, CLASSPATHs and class loaders for each module
should be common.
While I think you document does make the distinction between the
configuration model, it's flat file format and the service that
provides configuration - It think the distinctions need to be
made clearer:
+ As Craig has suggested, we need to talk about the services
that provide configuration and their dynamic behaviour.
I see a mechanism similar to a window redraw API. The service
can tell us exactly what has changed in the config file (the region),
and config clients have the option of just refreshing that part of
the config, or giving up and refreshing the whole module.
+ As somebody else pointed out - the call to go XML has not
yet been made - so it is important to clearly separate
the data model from potential file formats. Again this
will require work on the API so that it is decoupled from
any XML package.
You doc does cover these points - but I think a lengthy configuration
architecture and philosophy statement is needed up front (including
the protocol and management architecture etc.). I'm happy either
to contribute to this if James continues as primary author - or
write a first draft if my ramblings here a along the lines of
what others are thinking...
regards
--
Greg Wilkins<gr...@mortbay.com> GB Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK. Mbl Phone: +44-(0)7775534369
http://www.mortbay.com AU Phone: +61-(0)299772395
Re: request for review: server/config discussion
Posted by James Todd <ja...@eng.sun.com>.
Ben Laurie wrote:
>
> As was mentioned in another thread, Apache _may_ use XML for
> configuration in future versions. I would strongly suggest that a
> solution which can also be used for Apache (and other projects with
> similar configuration goals, particularly ones operating under the ASF
> umbrella) would be highly desirable. This tends to rule out complex
> solutions involving things like UML, simply because there's already a
> big overhead to learning how to extend Apache, and forcing people to
> also learn UML, XMI and the like is liable to meet huge resistance. Even
> requiring DTDs is causing some angst.
>
> Don't get me wrong, I'm not suggesting that things should be dumbed down
> to satisfy lazy developers, but I am suggesting that extra complexity
> needs to be accompanied by a corresponding large win of some kind. I
> think it is unlikely that going beyond XML/DTD is likely to lead to that
> kind of win. I'm happy to be wrong, though.
>
> It is particularly significant (IMO) that many think XML/DTD are going
> to be pretty much a fact of life. Things like UML are not going to be
> nearly so pervasive, in current estimation.
agreed. i choose the "this can be done with a 100% pure java
http server" as a) that is what tomcat does and b) to defuse
any "this isn't the way apache does it today and things are
just fine by me" threads so that we could more directly get
to the proactive part of the discussion. my hope is that we
can start with something small, clean, pure (eg models reality
as we perceive it today) and open/portable afterwhich we should
be able to start fleshing out some loose milestones. if this
core framework can be extended and used by other server's then
that is good. if, on the other hand, we decide more info should
be pushed to the core config and we feel this won't disrupt
other consumer's of the config data that too is good. i have
a feeling we'll end up with something in the middle coupled
with some good design discussions.
re uml ...
i am by no means mandating uml. i find it very intuitive but
i a) realize that that is just my opinion and 2) i only utilize
the aspects of uml (probably less then 5%) that help me to
understand and convey some design decisions. no one should get
browny points for being more uml complete ... no way. i did
feel that i would like to offer a bit of my life experiences
in some of the tricks in my bag. i'd like to hear other folks
perspectives. uml to me is similiar to hieroglyphs in that i
find meaning (not all meaning) can often (not always) be
conveyed to folks with a varied background (technically or
not) and language of choice (doesn't have to be english only).
i also find it is easier to rev glyphs vs rev docs (which
tend to bury and stagnate the best of ideas). my humble
perspective anyways.
i agree with your xml/dtd assertion ... hence my motivation to
promote it as a baseline format. everything else is icing on
the cake ... and i'd like for us to have options which should
fall out if the general design premise is understood.
i'll roll your comments into the config discussion thread and
adjust accordingly.
i also agree with your sig :)
hope this helps,
- james
Re: request for review: server/config discussion
Posted by Ben Laurie <be...@algroup.co.uk>.
James Todd wrote:
>
> hi -
>
> attached is a first cut at collecting the various
> thoughts surrounding a "pure java http server
> configuration" project.
>
> this is not meant to be a holy relic or artifact
> or even the truth but is more a collection of thoughts
> and decission points, which are not final, expressed
> to date presented in a format which should allow for
> peer review and editing (althought this later part will
> be a bit sticky till we have a bit more infrastructure
> to help out).
>
> anyways, i welcome any/all feedback and anticipate
> subsequent drill-downs on some of the topics which
> are barely touched upon.
As was mentioned in another thread, Apache _may_ use XML for
configuration in future versions. I would strongly suggest that a
solution which can also be used for Apache (and other projects with
similar configuration goals, particularly ones operating under the ASF
umbrella) would be highly desirable. This tends to rule out complex
solutions involving things like UML, simply because there's already a
big overhead to learning how to extend Apache, and forcing people to
also learn UML, XMI and the like is liable to meet huge resistance. Even
requiring DTDs is causing some angst.
Don't get me wrong, I'm not suggesting that things should be dumbed down
to satisfy lazy developers, but I am suggesting that extra complexity
needs to be accompanied by a corresponding large win of some kind. I
think it is unlikely that going beyond XML/DTD is likely to lead to that
kind of win. I'm happy to be wrong, though.
It is particularly significant (IMO) that many think XML/DTD are going
to be pretty much a fact of life. Things like UML are not going to be
nearly so pervasive, in current estimation.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: request for review: server/config discussion
Posted by James Todd <ja...@eng.sun.com>.
"Craig R. McClanahan" wrote:
> global restart being required. This doesn't seem to be a high priority for most server
> developers (and I'm talking to myself here as well -- Apache JServ 1.1-DEV still requires restarts
> on config changes), but it sure does matter in environments where a server restart can be very
> disruptive to lots of users.
agreed. for the apps i've built this was mandatory. it make dev
nice but in a production system i can be a pretty big deal to
?quiesce? and revive the system in full. this is not to say that
*all* config data will fit this criteria (updateable w/o require
server restart) but i do believe there is a large set of such
attributes that fits the bill nicely.
hope this helps,
- james
Re: request for review: server/config discussion
Posted by James Todd <ja...@eng.sun.com>.
i hope the "server/config" discussion/subProject can kickstart
without too much overhead from existing projects ... hence my
artificially constraining this to a "100% pure java server config
initiative." also, the tomcat implementation is so simple and
most likely provides a complete subset of features needed by
other servers (this is not to say it is feature complete) this
to is an attractive starting point in my book.
i do hope this "config service" can be used by more engines and
can even possible manage a wider set of configuration data ...
big picture and this will be stated in the "objectives" section.
down to earth a bit, we've got to starting picking the low
hanging fruit to kick this off. as i see it, these are:
tomcat (small, 100% java server, xml config driven,
and is actively tracking the servlet and jsp
specifications)
xml config format as a baseline today ... possibly
openining this up to other formats as
consensus feels appropriate
multi-protocol friendly "configuration service" which
will shield the consumers of configuration
data (server with read access, tools with
read/write access) from the data format (xml)
and file i/o details
from the feedback that has been posted, i think the boundaries
of this discussion are well based and there are two to three
key subTopics of interest:
xml format
entitity roles (eg config service, server, etc)
api (as i see it this will be a fallout of getting
the afore mentioned roles on the table)
hope this helps,
- james
hope this helps,
- james
hope this helps,
- james
Ben Laurie wrote:
>
> "Craig R. McClanahan" wrote:
> >
> > Ben Laurie wrote:
> >
> > > "Craig R. McClanahan" wrote:
> > > > My single biggest gripe about Apache (or Netscape Enterprise Server, and I'm sure lots of others),
> > > > no matter now good it is at what it does, is the fact that you have to restart the server for the
> > > > most trivial configuration file changes. To me, that's not the way things should work -- it should
> > > > be possible to make incremental changes to existing configurations, at least to some level, without
> > > > global restart being required. This doesn't seem to be a high priority for most server
> > > > developers (and I'm talking to myself here as well -- Apache JServ 1.1-DEV still requires restarts
> > > > on config changes), but it sure does matter in environments where a server restart can be very
> > > > disruptive to lots of users.
> > >
> > > a) Apache supports "graceful" restarts for this reason.
> >
> > The Apache source code is pretty dense, but it looks like a graceful restart still kills all the child
> > httpd processes and recreates them. Among other things, that seems to mean all the modules go through
> > their initialization lifecycle again.
>
> Yes, but not if they are currently processing a request. This means it
> doesn't disrupt users.
>
> > > b) Supporting incremental changes could get pretty complicated, because
> > > of cached derived information. I suppose simply blowing away all the
> > > caches is feasible, though.
> > >
> >
> > Speaking as an author of server-side stuff as well (Apache JServ 1.1-DEV) I am familiar with the "pretty
> > complicated" parts of it. Basically, you can no longer count on certain things being static for the
> > life of your server, and this has lots of ramifications. But exit/restart is still the lazy way out of
> > dealing with the issue.
>
> And is there something wrong with laziness? :-)
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: request for review: server/config discussion
Posted by Ben Laurie <be...@algroup.co.uk>.
"Craig R. McClanahan" wrote:
>
> Ben Laurie wrote:
>
> > "Craig R. McClanahan" wrote:
> > > My single biggest gripe about Apache (or Netscape Enterprise Server, and I'm sure lots of others),
> > > no matter now good it is at what it does, is the fact that you have to restart the server for the
> > > most trivial configuration file changes. To me, that's not the way things should work -- it should
> > > be possible to make incremental changes to existing configurations, at least to some level, without
> > > global restart being required. This doesn't seem to be a high priority for most server
> > > developers (and I'm talking to myself here as well -- Apache JServ 1.1-DEV still requires restarts
> > > on config changes), but it sure does matter in environments where a server restart can be very
> > > disruptive to lots of users.
> >
> > a) Apache supports "graceful" restarts for this reason.
>
> The Apache source code is pretty dense, but it looks like a graceful restart still kills all the child
> httpd processes and recreates them. Among other things, that seems to mean all the modules go through
> their initialization lifecycle again.
Yes, but not if they are currently processing a request. This means it
doesn't disrupt users.
> > b) Supporting incremental changes could get pretty complicated, because
> > of cached derived information. I suppose simply blowing away all the
> > caches is feasible, though.
> >
>
> Speaking as an author of server-side stuff as well (Apache JServ 1.1-DEV) I am familiar with the "pretty
> complicated" parts of it. Basically, you can no longer count on certain things being static for the
> life of your server, and this has lots of ramifications. But exit/restart is still the lazy way out of
> dealing with the issue.
And is there something wrong with laziness? :-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: request for review: server/config discussion
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Ben Laurie wrote:
> "Craig R. McClanahan" wrote:
> > My single biggest gripe about Apache (or Netscape Enterprise Server, and I'm sure lots of others),
> > no matter now good it is at what it does, is the fact that you have to restart the server for the
> > most trivial configuration file changes. To me, that's not the way things should work -- it should
> > be possible to make incremental changes to existing configurations, at least to some level, without
> > global restart being required. This doesn't seem to be a high priority for most server
> > developers (and I'm talking to myself here as well -- Apache JServ 1.1-DEV still requires restarts
> > on config changes), but it sure does matter in environments where a server restart can be very
> > disruptive to lots of users.
>
> a) Apache supports "graceful" restarts for this reason.
The Apache source code is pretty dense, but it looks like a graceful restart still kills all the child
httpd processes and recreates them. Among other things, that seems to mean all the modules go through
their initialization lifecycle again.
>
> b) Supporting incremental changes could get pretty complicated, because
> of cached derived information. I suppose simply blowing away all the
> caches is feasible, though.
>
Speaking as an author of server-side stuff as well (Apache JServ 1.1-DEV) I am familiar with the "pretty
complicated" parts of it. Basically, you can no longer count on certain things being static for the
life of your server, and this has lots of ramifications. But exit/restart is still the lazy way out of
dealing with the issue.
>
> Cheers,
>
> Ben.
>
Craig
>
> --
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: request for review: server/config discussion
Posted by Ben Laurie <be...@algroup.co.uk>.
"Craig R. McClanahan" wrote:
>
> James Todd wrote:
>
> > these are my thoughts as well and an area i'd like for us to
> > drill down on rsn. i think we're comfortable knowing what we
> > know about the entities which are likely to produce and use
> > the data ... what differentiates this, in my mind and i believe
> > yours as well, is that the "configuration service" should make
> > available in a protocol friendly means the configuration data
> > (or derived objects) and will singal to clients (most likely
> > passively) when a "data refresh" is required as the config
> > data has changed.
> >
>
> I would make a stronger statement than that ... I do not want "data refresh" notifications -- I
> want each individual change event. In Java, the JavaBeans event broadcast model seems to be the
> best way to deal with it in the configuration API.
>
> My single biggest gripe about Apache (or Netscape Enterprise Server, and I'm sure lots of others),
> no matter now good it is at what it does, is the fact that you have to restart the server for the
> most trivial configuration file changes. To me, that's not the way things should work -- it should
> be possible to make incremental changes to existing configurations, at least to some level, without
> global restart being required. This doesn't seem to be a high priority for most server
> developers (and I'm talking to myself here as well -- Apache JServ 1.1-DEV still requires restarts
> on config changes), but it sure does matter in environments where a server restart can be very
> disruptive to lots of users.
a) Apache supports "graceful" restarts for this reason.
b) Supporting incremental changes could get pretty complicated, because
of cached derived information. I suppose simply blowing away all the
caches is feasible, though.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: request for review: server/config discussion
Posted by James Davidson <du...@x180.com>.
> My single biggest gripe about Apache (or Netscape Enterprise Server, and I'm sure lots of others),
> no matter now good it is at what it does, is the fact that you have to restart the server for the
> most trivial configuration file changes.
+1
Restarting servers for config changes is silly, especially as the data
structures inside are usually already runtime changeable.
--
James Davidson
duncan@eng.sun.com http://java.sun.com/products/servlet
duncan@x180.com http://jakarta.apache.org
!try; do() PGP:0x7D776205
RE: request for review: server/config discussion
Posted by Liam Magee <li...@interneticons.com.au>.
I agree wholeheartedly with this. As a casual observer on the Jakarta
project, and a servlet developer/administrator, the ability to reload
servlets (and dependencies), JSP's and configuration properties is key, IMO.
Using servlets to then remotely configure these properties, upload new
servlets, etc., would also be easier.
Liam Magee.
> -----Original Message-----
> From: Craig McClanahan [mailto:cmcclanahan@mytownnet.com]
> Sent: Tuesday, July 20, 1999 11:24 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: request for review: server/config discussion
>
>
> James Todd wrote:
>
> > these are my thoughts as well and an area i'd like for us to
> > drill down on rsn. i think we're comfortable knowing what we
> > know about the entities which are likely to produce and use
> > the data ... what differentiates this, in my mind and i believe
> > yours as well, is that the "configuration service" should make
> > available in a protocol friendly means the configuration data
> > (or derived objects) and will singal to clients (most likely
> > passively) when a "data refresh" is required as the config
> > data has changed.
> >
>
> I would make a stronger statement than that ... I do not want
> "data refresh" notifications -- I
> want each individual change event. In Java, the JavaBeans event
> broadcast model seems to be the
> best way to deal with it in the configuration API.
>
> My single biggest gripe about Apache (or Netscape Enterprise
> Server, and I'm sure lots of others),
> no matter now good it is at what it does, is the fact that you
> have to restart the server for the
> most trivial configuration file changes. To me, that's not the
> way things should work -- it should
> be possible to make incremental changes to existing
> configurations, at least to some level, without
> global restart being required. This doesn't seem to be a high
> priority for most server
> developers (and I'm talking to myself here as well -- Apache
> JServ 1.1-DEV still requires restarts
> on config changes), but it sure does matter in environments where
> a server restart can be very
> disruptive to lots of users.
>
> After all, we can't laugh at Microsoft Windows for forcing a
> reboot just to change DNS servers if
> we do the same sort of thing in our application services ....
>
> >
> > - james
> >
>
> Craig McClanahan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: request for review: server/config discussion
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
James Todd wrote:
> these are my thoughts as well and an area i'd like for us to
> drill down on rsn. i think we're comfortable knowing what we
> know about the entities which are likely to produce and use
> the data ... what differentiates this, in my mind and i believe
> yours as well, is that the "configuration service" should make
> available in a protocol friendly means the configuration data
> (or derived objects) and will singal to clients (most likely
> passively) when a "data refresh" is required as the config
> data has changed.
>
I would make a stronger statement than that ... I do not want "data refresh" notifications -- I
want each individual change event. In Java, the JavaBeans event broadcast model seems to be the
best way to deal with it in the configuration API.
My single biggest gripe about Apache (or Netscape Enterprise Server, and I'm sure lots of others),
no matter now good it is at what it does, is the fact that you have to restart the server for the
most trivial configuration file changes. To me, that's not the way things should work -- it should
be possible to make incremental changes to existing configurations, at least to some level, without
global restart being required. This doesn't seem to be a high priority for most server
developers (and I'm talking to myself here as well -- Apache JServ 1.1-DEV still requires restarts
on config changes), but it sure does matter in environments where a server restart can be very
disruptive to lots of users.
After all, we can't laugh at Microsoft Windows for forcing a reboot just to change DNS servers if
we do the same sort of thing in our application services ....
>
> - james
>
Craig McClanahan
Re: request for review: server/config discussion
Posted by James Todd <ja...@eng.sun.com>.
<:)>
some tomcatDev discussions ... !fresh!
</:)>
these are my thoughts as well and an area i'd like for us to
drill down on rsn. i think we're comfortable knowing what we
know about the entities which are likely to produce and use
the data ... what differentiates this, in my mind and i believe
yours as well, is that the "configuration service" should make
available in a protocol friendly means the configuration data
(or derived objects) and will singal to clients (most likely
passively) when a "data refresh" is required as the config
data has changed.
- james
"Craig R. McClanahan" wrote:
>
> James Todd wrote:
>
> > hi -
> >
> > attached is a first cut at collecting the various
> > thoughts surrounding a "pure java http server
> > configuration" project.
> >
>
> I did not see this issue addressed so far (maybe it's more an issue for the server
> implementation itself), but I would like to see a mechanism where incremental changes to the
> configuration information, such as adding a new Directory Path or changing an existing
> Maintainer (in the terminology of the Appendix example) are "absorbed" in to the running
> server without requiring a complete restart. This may require architectural support within
> the configuration data management module itself (as well as the API), to broadcast events when
> changes occur.
>
> It should also go without saying that the results of this should be useful in configuring all
> Tomcat components, not just the HTTP server :-).
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: request for review: server/config discussion
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
James Todd wrote:
> hi -
>
> attached is a first cut at collecting the various
> thoughts surrounding a "pure java http server
> configuration" project.
>
I did not see this issue addressed so far (maybe it's more an issue for the server
implementation itself), but I would like to see a mechanism where incremental changes to the
configuration information, such as adding a new Directory Path or changing an existing
Maintainer (in the terminology of the Appendix example) are "absorbed" in to the running
server without requiring a complete restart. This may require architectural support within
the configuration data management module itself (as well as the API), to broadcast events when
changes occur.
It should also go without saying that the results of this should be useful in configuring all
Tomcat components, not just the HTTP server :-).
Craig McClanahan
Re: request for review: server/config discussion
Posted by Ben Laurie <be...@algroup.co.uk>.
James Todd wrote:
>
> hi -
>
> attached is a first cut at collecting the various
> thoughts surrounding a "pure java http server
> configuration" project.
>
> this is not meant to be a holy relic or artifact
> or even the truth but is more a collection of thoughts
> and decission points, which are not final, expressed
> to date presented in a format which should allow for
> peer review and editing (althought this later part will
> be a bit sticky till we have a bit more infrastructure
> to help out).
>
> anyways, i welcome any/all feedback and anticipate
> subsequent drill-downs on some of the topics which
> are barely touched upon.
As was mentioned in another thread, Apache _may_ use XML for
configuration in future versions. I would strongly suggest that a
solution which can also be used for Apache (and other projects with
similar configuration goals, particularly ones operating under the ASF
umbrella) would be highly desirable. This tends to rule out complex
solutions involving things like UML, simply because there's already a
big overhead to learning how to extend Apache, and forcing people to
also learn UML, XMI and the like is liable to meet huge resistance. Even
requiring DTDs is causing some angst.
Don't get me wrong, I'm not suggesting that things should be dumbed down
to satisfy lazy developers, but I am suggesting that extra complexity
needs to be accompanied by a corresponding large win of some kind. I
think it is unlikely that going beyond XML/DTD is likely to lead to that
kind of win. I'm happy to be wrong, though.
It is particularly significant (IMO) that many think XML/DTD are going
to be pretty much a fact of life. Things like UML are not going to be
nearly so pervasive, in current estimation.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi