You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Craig R. McClanahan" <cm...@mytownnet.com> on 2000/01/20 08:04:18 UTC
[Catalina] Discussion - Component Configuration Strategy
One aspect of the proposed architecture is certain to engender further
discussion -- the use of the org.w3c.dom "Node" interface as the means
by which components receive their component configuration information.
This choice was made initially for the following reasons:
* Any deployment of Tomcat is going to need to
parse "web.xml" files anyway, so it is essentially
certain to have the DOM classes, and an appropriate
XML parser, hanging around.
* The approach to this taken sometimes in the current
Tomcat code (convert the DOM to an implementation
of org.apache.tomcat.util.XmlTree) seems like overkill
for something that is used one time.
* The DOM elegantly reflects the hierarchical nature of
component organization within a Tomcat deployment.
As an example of this, see the "server.xml" file in the
top level ("proposals/catalina") directory -- it illustrates
how components in the new proposal nest themselves.
It would be desireable (IMHO) that any configuration
mechanism we actually build be able to parse and
process such a configuration file -- at least until we
have tools that hide the actual server.xml syntax.
* Configuration is only one of the issues involved -- the
start/stop functionality is also important (although you can
modify the configuration mechanism without giving this up).
Counter-arguments and alternative suggestions that have been expressed
so far include:
* It is not particularly elegant to make the core components
of Tomcat dependent upon an external package like the
DOM classes.
* Any XML parsing required can be done external to the
core, and components should be able to be configured
by these external mechanisms in a more typical JavaBeans
fashion.
* Consider using introspection to identify the properties
that can be set from the configuration, in a manner similar
to what Ant does when configuring tasks. (I'm very +1
on doing this).
* Consider using the Configurable interface (and possibly
others like Block as well) from the Avalon framework.
I'd really appreciate some comments from people more
familiar with Avalon on how applicable it might be here.
What do we all think? How should Catalina components be configured?
Craig McClanahan
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by Ludovic Claude <lc...@websitewatchers.com>.
That looks a lot like the Configuration interface defined in Avalon. Why not
just use it, it's there
and Avalon does already a great job on loading configurations.
It's already loading xml configurations, and could in my opinion do much more,
like loading configurations
from LDAP or from the Windows registry.
Ludovic Claude.
John Holman wrote:
> > One aspect of the proposed architecture is certain to engender further
> > discussion -- the use of the org.w3c.dom "Node" interface as the means
> > by which components receive their component configuration information.
>
> As well as the general strategy for configuration there is still this issue
> of the API for accessing the configuration data itself. Rather than using
> the DOM directly (as e.g. in Craig's original proposal) I'd suggest a
> simpler interface that is oriented more towards representing configuration
> data (as opposed to documents) and which should be as well suited to an
> implementation based on say LDAP or properties files as it is to XML. These
> advantages of abstraction and simplification should outweigh any
> disadvantage of introducing an additional layer - especially since
> performance is not really an issue in this context.
>
> For example I've used the following interface to represent configuration
> data
>
> public interface PropertyTree {
> String getName();
> String getValue();
> java.util.Enumeration getAttributeNames();
> String getAttribute(String name);
> java.util.Enumeration getChildren();
> java.util.Enumeration getChildren(String filter);
> PropertyTree getFirstChild();
> PropertyTree getFirstChild(String filter);
> }
>
> In the DOM-based implementation a DOMPropertyTree is an adaptor class
> wrapping a DOM element. The PropertyTree name corresponds to the tag of the
> DOM element, attributes and children map to its attributes and child
> elements, and the value maps to the value of the first child text node of
> the DOM element. The filter simply selects children with the given tag, but
> in an LDAP-based implementation it might perhaps be extended to encompass
> LDAP filters.
>
> I could offer some code for a preliminary DOM-based implementation if it
> would be of any use.
>
> Hoping this is not too far off the point ...
>
> John Holman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
___________________________________
Web Site Watchers Ltd
212 Piccadilly,
London W1V 9LD
United-Kingdom
Telephone: +44 (0)171 917 6255
Fax: +44 (0)171 439 0262
http://www.websitewatchers.co.uk
lc@websitewatchers.com
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by Assaf Arkin <ar...@exoffice.com>.
+1
arkin
"Craig R. McClanahan" wrote:
>
> John Holman wrote:
>
> > > One aspect of the proposed architecture is certain to engender further
> > > discussion -- the use of the org.w3c.dom "Node" interface as the means
> > > by which components receive their component configuration information.
> >
> > As well as the general strategy for configuration there is still this issue
> > of the API for accessing the configuration data itself. Rather than using
> > the DOM directly (as e.g. in Craig's original proposal) I'd suggest a
> > simpler interface that is oriented more towards representing configuration
> > data (as opposed to documents) and which should be as well suited to an
> > implementation based on say LDAP or properties files as it is to XML. These
> > advantages of abstraction and simplification should outweigh any
> > disadvantage of introducing an additional layer - especially since
> > performance is not really an issue in this context.
> >
>
> The current (non-Catalina) version of Tomcat has a very similar data object to
> your PropertyTree already defined-- org.apache.tomcat.util.XMLTree -- that was
> (and might still be?) used for pretty much this purpose.
>
> However, having listened to the interesting discussion on this topic so far,
> I'm actually coming to a different, and somewhat radical (appropriate, I guess,
> for a "revolution" :-) viewpoint -- there should be no such thing as a
> "configuration data API" because the needs of different deployment scenarios
> are quite different from each other. Let me articulate a few principles that I
> think make sense (some already mentioned by others, and some that I'm pulling
> out of what has been said), and lets's see what we all think. For each
> principle, there are some corresponding implications:
>
> (1) Components should be configured from the "outside", not the "inside".
>
> Implication: There should not be a configure(ConfigData data) method
> signature at all. Instead, the component should be configured by
> property setting of publicly accessible properties.
>
> Implication: The outside environment is free to access or represent
> configuration data in any manner that it sees fit. For example, an
> environment parsing an XML configuration via SAX events could
> fire property changes directly at the appropriate times, instead of
> having to build up a complete data object. The same concept applies
> when reading configuration data from a database or directory server.
>
> Implication: You need not go to the work of creating Java classes
> for configuration data (either customized, like the current
> org.apache.tomcat.deployment family, or general purpose)
> unless you need it for some other reason.
>
> (2) Components need to know when the outside environment thinks
> configuration has been completed (so that the component can be
> used), and when the outside environment wants to shut them down.
>
> Implication: Method signatures for these "life cycle" events are useful.
> Catalina uses the start() and stop() methods of the Lifecycle interface
> for this purpose.
>
> (3) Components should support dynamic configuration changes on the
> fly, to the maximum degree feasible.
>
> Implication: In general, no new method signatures are required, because
> reconfiguration is normally done by changing the values of existing
> properties.
>
> Implication: The property setter methods need to be aware when
> they are being called at initialization time, versus at run time. Keeping
> track of the current lifecycle state (see #2 above) makes this easy.
>
> Implication: Components should be able to reject property changes
> that are not feasible to implement dynamically, by throwing
> IllegalStateException.
>
> Implication: From the "outside" viewpoint, dynamic reconfiguration
> changes are done by setXxxx calls on the component itself, since
> no extenral "configuration data" object can be assumed to exist
> (see #1 above).
>
> (4) Persistent storage of configuration information, including the current
> configuration state when dynamic changes are made, is very useful.
>
> Implication: It might be possible for an outside agent to examine the
> current state of all configured components, and synthesize the
> persistent form of the configuration information that would reproduce
> the current state. In such cases, no extra effort inside the components
> is required.
>
> Implication: In some environments, a data object really is maintained
> to represent the current configuration data, and it would be useful for
> changes made dynamically (see #3 above) to be recognized in "real" time.
>
> Fortunately, the JavaBeans property change design pattern makes
> this quite easy to implement -- interested configuration objects can
> register themselves to receive property change events. Components
> should implement appropriate property change event generation into
> their setXxx methods to facilitate this.
>
> I think this approach deals with most of the negative consequences of the
> various approaches we've been discussing. How does it sound?
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
costin@costin.dnt.ro wrote:
> > The current (non-Catalina) version of Tomcat has a very similar data object to
> > your PropertyTree already defined-- org.apache.tomcat.util.XMLTree -- that was
> > (and might still be?) used for pretty much this purpose.
> >
> > However, having listened to the interesting discussion on this topic so far,
> > I'm actually coming to a different, and somewhat radical (appropriate, I guess,
> > for a "revolution" :-) viewpoint -- there should be no such thing as a
>
> Well, we are in total agreement ( with the small observation that it's not
> a radical "revolution", it's the current tomcat :-)
>
> ( XMLTree is just one of the ways to set up tomcat - even if I don't like
> it, it is a valid and accepted solution. Other ways are JNDI,
> SimpleStartup, ant-like XmlHelper, deploy package - all are valid in this
> architecture, and Avalon will also work with the right adapters, if
> someone writes them. ) I think it's the right architecture, and even if it
> is not, it doesn't deny any alternative.
>
> > I think this approach deals with most of the negative consequences of the
> > various approaches we've been discussing. How does it sound?
>
> It's exactly what I want ( but it seems I'm very,very bad at
> explaining it). Thanks, Craig.
>
I figured you'd like it ... don't apologize when you're right :-)
>
> Costin
>
Craig
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by James Todd <jw...@pacbell.net>.
costin@costin.dnt.ro wrote:
>
> ( XMLTree is just one of the ways to set up tomcat - even if I don't like
> it, it is a valid and accepted solution. Other ways are JNDI,
to quantify XMLTree as a solution is a bit grandious.
XMLTree was just a first stab at supporting web.xml while containing
the necessary xml parsing code. top prevent xml ooze so to speak. it
was not intended as an end all solution as to how best to handle xml
parsing. to make such an assertion is akin to stating "i don't need to read
the rest of the book as i know how it ends based on the my perusing of
the preface."
hope this helps,
- james
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by co...@costin.dnt.ro.
> The current (non-Catalina) version of Tomcat has a very similar data object to
> your PropertyTree already defined-- org.apache.tomcat.util.XMLTree -- that was
> (and might still be?) used for pretty much this purpose.
>
> However, having listened to the interesting discussion on this topic so far,
> I'm actually coming to a different, and somewhat radical (appropriate, I guess,
> for a "revolution" :-) viewpoint -- there should be no such thing as a
Well, we are in total agreement ( with the small observation that it's not
a radical "revolution", it's the current tomcat :-)
( XMLTree is just one of the ways to set up tomcat - even if I don't like
it, it is a valid and accepted solution. Other ways are JNDI,
SimpleStartup, ant-like XmlHelper, deploy package - all are valid in this
architecture, and Avalon will also work with the right adapters, if
someone writes them. ) I think it's the right architecture, and even if it
is not, it doesn't deny any alternative.
> I think this approach deals with most of the negative consequences of the
> various approaches we've been discussing. How does it sound?
It's exactly what I want ( but it seems I'm very,very bad at
explaining it). Thanks, Craig.
Costin
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
John Holman wrote:
> > One aspect of the proposed architecture is certain to engender further
> > discussion -- the use of the org.w3c.dom "Node" interface as the means
> > by which components receive their component configuration information.
>
> As well as the general strategy for configuration there is still this issue
> of the API for accessing the configuration data itself. Rather than using
> the DOM directly (as e.g. in Craig's original proposal) I'd suggest a
> simpler interface that is oriented more towards representing configuration
> data (as opposed to documents) and which should be as well suited to an
> implementation based on say LDAP or properties files as it is to XML. These
> advantages of abstraction and simplification should outweigh any
> disadvantage of introducing an additional layer - especially since
> performance is not really an issue in this context.
>
The current (non-Catalina) version of Tomcat has a very similar data object to
your PropertyTree already defined-- org.apache.tomcat.util.XMLTree -- that was
(and might still be?) used for pretty much this purpose.
However, having listened to the interesting discussion on this topic so far,
I'm actually coming to a different, and somewhat radical (appropriate, I guess,
for a "revolution" :-) viewpoint -- there should be no such thing as a
"configuration data API" because the needs of different deployment scenarios
are quite different from each other. Let me articulate a few principles that I
think make sense (some already mentioned by others, and some that I'm pulling
out of what has been said), and lets's see what we all think. For each
principle, there are some corresponding implications:
(1) Components should be configured from the "outside", not the "inside".
Implication: There should not be a configure(ConfigData data) method
signature at all. Instead, the component should be configured by
property setting of publicly accessible properties.
Implication: The outside environment is free to access or represent
configuration data in any manner that it sees fit. For example, an
environment parsing an XML configuration via SAX events could
fire property changes directly at the appropriate times, instead of
having to build up a complete data object. The same concept applies
when reading configuration data from a database or directory server.
Implication: You need not go to the work of creating Java classes
for configuration data (either customized, like the current
org.apache.tomcat.deployment family, or general purpose)
unless you need it for some other reason.
(2) Components need to know when the outside environment thinks
configuration has been completed (so that the component can be
used), and when the outside environment wants to shut them down.
Implication: Method signatures for these "life cycle" events are useful.
Catalina uses the start() and stop() methods of the Lifecycle interface
for this purpose.
(3) Components should support dynamic configuration changes on the
fly, to the maximum degree feasible.
Implication: In general, no new method signatures are required, because
reconfiguration is normally done by changing the values of existing
properties.
Implication: The property setter methods need to be aware when
they are being called at initialization time, versus at run time. Keeping
track of the current lifecycle state (see #2 above) makes this easy.
Implication: Components should be able to reject property changes
that are not feasible to implement dynamically, by throwing
IllegalStateException.
Implication: From the "outside" viewpoint, dynamic reconfiguration
changes are done by setXxxx calls on the component itself, since
no extenral "configuration data" object can be assumed to exist
(see #1 above).
(4) Persistent storage of configuration information, including the current
configuration state when dynamic changes are made, is very useful.
Implication: It might be possible for an outside agent to examine the
current state of all configured components, and synthesize the
persistent form of the configuration information that would reproduce
the current state. In such cases, no extra effort inside the components
is required.
Implication: In some environments, a data object really is maintained
to represent the current configuration data, and it would be useful for
changes made dynamically (see #3 above) to be recognized in "real" time.
Fortunately, the JavaBeans property change design pattern makes
this quite easy to implement -- interested configuration objects can
register themselves to receive property change events. Components
should implement appropriate property change event generation into
their setXxx methods to facilitate this.
I think this approach deals with most of the negative consequences of the
various approaches we've been discussing. How does it sound?
Craig McClanahan
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by James Todd <jw...@pacbell.net>.
John Holman wrote:
> > One aspect of the proposed architecture is certain to engender further
> > discussion -- the use of the org.w3c.dom "Node" interface as the means
> > by which components receive their component configuration information.
>
> As well as the general strategy for configuration there is still this issue
> of the API for accessing the configuration data itself. Rather than using
> the DOM directly (as e.g. in Craig's original proposal) I'd suggest a
> simpler interface that is oriented more towards representing configuration
> data (as opposed to documents) and which should be as well suited to an
> implementation based on say LDAP or properties files as it is to XML. These
> advantages of abstraction and simplification should outweigh any
> disadvantage of introducing an additional layer - especially since
> performance is not really an issue in this context.
>
> For example I've used the following interface to represent configuration
> data
>
> public interface PropertyTree {
> String getName();
> String getValue();
> java.util.Enumeration getAttributeNames();
> String getAttribute(String name);
> java.util.Enumeration getChildren();
> java.util.Enumeration getChildren(String filter);
> PropertyTree getFirstChild();
> PropertyTree getFirstChild(String filter);
> }
>
this is pretty much how XMLTree, possibly badly named as it is,
is designed with the exception of the getFirst() methods. just trying
to point out some alignment potentials here with the hopes of raising
the bar on design/architecture discussions.
hope this helps,
- james
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by John Holman <j....@qmw.ac.uk>.
> One aspect of the proposed architecture is certain to engender further
> discussion -- the use of the org.w3c.dom "Node" interface as the means
> by which components receive their component configuration information.
As well as the general strategy for configuration there is still this issue
of the API for accessing the configuration data itself. Rather than using
the DOM directly (as e.g. in Craig's original proposal) I'd suggest a
simpler interface that is oriented more towards representing configuration
data (as opposed to documents) and which should be as well suited to an
implementation based on say LDAP or properties files as it is to XML. These
advantages of abstraction and simplification should outweigh any
disadvantage of introducing an additional layer - especially since
performance is not really an issue in this context.
For example I've used the following interface to represent configuration
data
public interface PropertyTree {
String getName();
String getValue();
java.util.Enumeration getAttributeNames();
String getAttribute(String name);
java.util.Enumeration getChildren();
java.util.Enumeration getChildren(String filter);
PropertyTree getFirstChild();
PropertyTree getFirstChild(String filter);
}
In the DOM-based implementation a DOMPropertyTree is an adaptor class
wrapping a DOM element. The PropertyTree name corresponds to the tag of the
DOM element, attributes and children map to its attributes and child
elements, and the value maps to the value of the first child text node of
the DOM element. The filter simply selects children with the given tag, but
in an LDAP-based implementation it might perhaps be extended to encompass
LDAP filters.
I could offer some code for a preliminary DOM-based implementation if it
would be of any use.
Hoping this is not too far off the point ...
John Holman
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by co...@costin.dnt.ro.
> I have one bean called Server which I use to load and reload the
> configuration. (More about reloading later). It contains any number of
> Domains, each one with a Limit, Policy elements (for clarity, they are
> actually properties of Domain) and any number of Resource elements.
> Resource elements contain Resource elements, plug Include which
> reference external documents, and so on and one. About 20 objects in the
> graph with one root bean.
And it doesn't have to be a 1-1 mapping between the Object hierarchy and
the Bean structure ( for example, web.xml will be mapped to a simpler
object structure). It's just an implementation detail and a matter of
defining the mapping.
> I have never found this to be a problem. All the discussion about LDAP
> events is pretty moot, they are in the API, but not well supported in
> servers and not guaranteed to be sent. They are also specific for LDAP.
:-)
Yes, you are right about that, LDAP is not the perfect directory service.
I keep giving the JNDI example because directory services are used in real
world to solve configuration problems ( see Windows 2000 , Netware since
4.0, Sun NIS ). I don't want to use an API that is limited to only reading
elements because that's what XML can do today, but an API that
allow us to grow and scale ( even if not all features are implemented ).
Costin
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by Assaf Arkin <ar...@exoffice.com>.
> > 2) the bean pattern. Construction may or may not be empty, but you have
> > a bunch of set/get methods. A bean can be used as the C-"unit"
> > equivalent (a container of data from different types) or as an active
> > component. Ant tasks follow the "active bean" pattern. Note that a bean
> > can be exposed by a single XML empty element with attributes, one for
> > each set method.
> >
> > Problems: this pattern is not well suited for hierarchical
> > configurations unless the bean<->empty-element link is maintained as a
> > rule (like in Assaf's tyrex). Also, it is _very_ verbose in cases where
> > lots of parameters are needed. It is also slower since all parameters
> > (even those ones never used) must be pushed.
No, my comment was not about bean<->empty-element but rather graph of
bean <-> graph of elements.
I have one bean called Server which I use to load and reload the
configuration. (More about reloading later). It contains any number of
Domains, each one with a Limit, Policy elements (for clarity, they are
actually properties of Domain) and any number of Resource elements.
Resource elements contain Resource elements, plug Include which
reference external documents, and so on and one. About 20 objects in the
graph with one root bean.
To extend the graph I simply define set/get methods that take a bean
instead of a simple value.
> > 4) the reconfigurable pattern. Reconfigurable extends Configurable.
> > Another method is provided and it's called by the component manager when
> > the component needs to be reconfigured. When this happens, the component
> > must do something and return true if the operation was completed,
> > otherwise false if this component cannot reconfigure itself. In this
> > case, the component will be properly shutdown and recreated with the new
> > configurations.
> Since you don't mention problems, I'll do it:
I have never found this to be a problem. All the discussion about LDAP
events is pretty moot, they are in the API, but not well supported in
servers and not guaranteed to be sent. They are also specific for LDAP.
Instead of waiting for something to happen, I simply restart the server
with a new configuration file. The server doesn't shutdown and restart
like Windows will (in fact it can't, it's a subordinate or Tomcat), it
simply reconfigures itself, typically dropping existing resource pools
and creating new ones based on the new configuration.
So, XML -> Beans, Beans -> server and then I dispose of the Beans.
Repeat each time and you got a reconfigurable server without any
reconfigurable pattern. No dependency on notification model, you can
update manually, track change to a file, get LDAP events, compare
timestamp on LDAP entries, whatever works for you.
arkin
>
> Problems:
> - can't do "fine" tuning ( "change sessionTimeout" ).
> - the component needs a complex logic to detect the configuration changes
> - no way to query the component ( "what is the session timeout of the
> running context" )
> - the component depends on a particular configuration API - it is ok if
> this is a well-known interface ( standard, used be most other
> components), otherwise you'll have problems mixing components developed
> in different architecture.
>
> > > - notification ( if "/ContextManager" config changes, let me know ( via
> > > Event or callback )
> >
> > Yes, I don't like the reconfigurable pattern myself, but we could not
> > come out with anything better. In fact, Reconfigurable extends Listener,
> > listening for global changed. Also note that server reconfiguration is
> > normally done on a global scale: you change all the configurations and
> > then restart. So doing it in a single place may not be that bad.
>
> :-)
> Well, it's done that way because most servers don't come out with anythin
> better. ( probably windows users will have problems with that, but you
> _don't_ need to restart the computer if you change the IP address :-)
>
> Take a look at JNDI ( notification ), take a look at Novel NDS.
>
> Restarting the component is _bad_ when you just want to change a simple
> property.
>
> > > - Search ( find all contexts where "jsp" is not mapped to Jasper )
> >
> > Can you make an example where this is absolutely required? For the above
> > reasons, I tend to think that if you don't know where the configurations
> > are, there's something wrong.
>
> Sometimes it's not a simple component/configuration situation.
>
> You may have configuration that is shared by components, or one component
> may need to query the config of another component.
>
> Example: a component that will preload all jsp-engines that are registered
> by contexts, or will disable any mapping that is not allowed by the
> company policy.
>
> Or a component that removes all mentions to a certain user from all user
> configs ( == search after "user" attribute ). You may have many
> components that define users ( some unknown when you write the remover).
>
> > > - Write access ( so you can change your config )
> >
> > -1. This is a very bad general practice. A normal component _MUST_ have
> > read-only capabilities. Only special read-write components are created
> > for configuration updating (example: servlet that changes configurations
> > remotely and allows restarting).
>
> What about a smart component that learns at run-time and wants to persist
> the changes, for next time it starts?
> We are talking about a generic framework, not only servlets, some
> components _may_ have read-write access.
>
> ( that adds a new requirement - access control for read/write )
>
> > > - Should work at runtime also ( if a config changes, the component should
> > > be able to reconfigure itself )
> >
> > How? this is _very_ hard to do. In avalon we abandoned the research on
> > reconfigurable because in many cases it's easier to give up and say "I
> > can't do it, kill me" rather than synch-ing all your threads,
> > repositories and such without actually doing a shutdown-restart itself.
> > Automatic component reconfiguration is most of the times a holy grail.
>
> Well, again take a look at existing systems and APIs. LDAP supports
> notification, ( if I remember corectly) NDS supports that, in general it's
> something common for directory services.
> When a context receive a "timeout changed" notification it can do the
> change without restart.
>
> Just take a look at Linux or Solaris kernel - you can change tons of
> configurations by a simple write to a proc file. If you can reconfigure
> something as complex as a kernel, why should't we try for a damn session
> timeout? Yes, Windows needs to be restarted, but that doesn't mean
> reconfiguration without reboot is "holy grail".
>
> > > - Embedeable - you should include and bridge to other config APIs
> >
> > What other config APIs? Properties?
>
> We can't dictate what other application should use, if the application
> that embeds tomcat use properties - we should be able to deal with that.
>
> > > - Add your own :-)
> >
> > I think Costin caught the "flexibility syndrome" about configurations.
> > While I totally understand him because we had the exact same problems in
> > Avalon (and man, it was hard to stop enlarging the picture every day!),
> > but we have to make decisions on what is really required.
>
> No, Costin just described what an existing and mature API can do today.
> ( and did in the last >6 years - see Netware 4, or NIS ).
>
> I worked few years as net admin, and I had the exact same problems, and
> belive me most of that is really required if you have more than 4 servers.
> ( and for web servers it's very common to have a much larger farm of
> computers, in different locations, etc).
>
> > Costin talked about using directory servers as configuration
> > repositories. This is not a bad idea at all, but are we really willing
> > to make Tomcat depend on an LDAP server on our network? let's be
>
> But are we willing to restrict tomcat to file-based configuration, and to
> drop all the features you could get from an LDAP server ?
> There is no requirement for an LDAP server - but if you have a directory
> server that manage all other subsystems, you want to take advantage of it
> ( and it's not only LDAP - NDS, ActiveDirectory, etc).
>
> > reasonable. On the other hand, I see no problems in making the
> > "configurations" implementation pluggable: Costin admitted he saw some
> > LDAP patterns when he saw the Avalon Configuration interfaces. This
> > shows you can pretty easily create a Configuration -> JNDI glue to work
> > with them and your components do not even know this.
>
> Or we can create a JNDI -> Configuration glue, since the reverse will
> lose most of JNDI power. (Right now Configurable is a subset of JNDI.)
> Of course, it will not support all features - so you'll need to restart.
>
> > On the other hand, Configurations do not require that much of server
> > power: most of their access is direct (means you know what you're
> > looking for) and read only. (let's forget about read-write components
> > for now since they are a big minority)
>
> Let's see, how many programs allow you to "save" the settings?
> Even the windows registry allows that.
>
> Yes, a component should work with "simple", not-so-powerfull
> configurations and should be able to deal with that, but again - we are
> talking about servers here, that needs to scale up.
>
> > This is, IMO, the very big power of the configurable pattern we designed
> > in Avalon and that Cocoon has been very happily using since 6 months.
>
> Well, people are happily using windows.
> Do you need to restart Cocoon if a configuration changes?
> What if Cocoon will need to change it's own configuration ?
>
> People are happy because Cocoon does something usefull for them, not
> because it uses Configurable.
>
> > The Servlet API didn't write methods so that your servlet can
> > reconfigure the server. If you do something like this, this is not a
> > servlet anymore.
>
> A configuration system should be useable not only by servlets!
>
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by co...@costin.dnt.ro.
> My comments are brief: I put on the table my knowledge about
> configurations and all the design ideas I could come up with. But, I
> don't have the energy to fight for my arguments also because I admit
> ignorance on many points (I never was a network administrator and I'm a
> windows user, the worst around here).
I'm really sorry about that ( the windows flames ).
Stefano, I hate this fight also, but I'll have to use and work with
whatever comes out of this discussion. The current architecture is
flexible enough to allow this model to be used, and people will start
coding using the "configurable" pattern ( which is easier to code and
understand). And if that becomes "de-facto" standard for tomcat I'll also
have to use it, and I really don't believe in it.
> So, all the irrationality removed, I think I'd better concentrate on my
> work and let you guys do yours since I know you'll do a great job even
> without my comments.
I think most arguments I read are rational, and Arkin's proposal ( to make
it possible to use both ) is reasonable enough. The code itself is
important, and we should not force people to use a certain pattern if we
can't reach agreement on it.
Costin
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by Stefano Mazzocchi <st...@apache.org>.
costin@costin.dnt.ro wrote:
> > The Servlet API didn't write methods so that your servlet can
> > reconfigure the server. If you do something like this, this is not a
> > servlet anymore.
>
> A configuration system should be useable not only by servlets!
There is a pattern I invented to reduce friction and flame wars. It's
more of an algorithm:
1) when you receive a mail that hurts you personally, write a very nasty
and totally unpolite mail back, answering every single point with almost
irrational ideas, removing all possible intelligence from it
2) then, ... delete it and start over again.
It turns out that you dissipated the friction that was created and you
are much more focused on the details and not blinded by personal
irrationality.
This is, of course, the result of point #2 :)
My comments are brief: I put on the table my knowledge about
configurations and all the design ideas I could come up with. But, I
don't have the energy to fight for my arguments also because I admit
ignorance on many points (I never was a network administrator and I'm a
windows user, the worst around here).
So, all the irrationality removed, I think I'd better concentrate on my
work and let you guys do yours since I know you'll do a great job even
without my comments.
With the tiny bit of irrationality remained, I'd suggest others on this
list to implement the anti-flame-war pattern more often :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by co...@costin.dnt.ro.
> better. ( probably windows users will have problems with that, but you
> _don't_ need to restart the computer if you change the IP address :-)
Sorry for the previous mail, please ignore any reference to windows,
I will try to be more careful with those subjects.
Costin
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by co...@costin.dnt.ro.
( 1,3 are just particular cases, I think the discution remains between
pull and push models )
> 2) the bean pattern. Construction may or may not be empty, but you have
> a bunch of set/get methods. A bean can be used as the C-"unit"
> equivalent (a container of data from different types) or as an active
> component. Ant tasks follow the "active bean" pattern. Note that a bean
> can be exposed by a single XML empty element with attributes, one for
> each set method.
>
> Problems: this pattern is not well suited for hierarchical
> configurations unless the bean<->empty-element link is maintained as a
> rule (like in Assaf's tyrex). Also, it is _very_ verbose in cases where
> lots of parameters are needed. It is also slower since all parameters
> (even those ones never used) must be pushed.
True only if you think from XML perspective ( i.e. everything is reduced
somehow to XML documents).
Java Bean model doesn't have this problem, only the (existing) XML-bean
mapping ( and implementation). You'll see few interesting examples and
in the next weeks :-).
The model also allow dynamic (run-time) queries and fine modifications of
the components, which is not possible with 3 or 4.
> 4) the reconfigurable pattern. Reconfigurable extends Configurable.
> Another method is provided and it's called by the component manager when
> the component needs to be reconfigured. When this happens, the component
> must do something and return true if the operation was completed,
> otherwise false if this component cannot reconfigure itself. In this
> case, the component will be properly shutdown and recreated with the new
> configurations.
Since you don't mention problems, I'll do it:
Problems:
- can't do "fine" tuning ( "change sessionTimeout" ).
- the component needs a complex logic to detect the configuration changes
- no way to query the component ( "what is the session timeout of the
running context" )
- the component depends on a particular configuration API - it is ok if
this is a well-known interface ( standard, used be most other
components), otherwise you'll have problems mixing components developed
in different architecture.
> > - notification ( if "/ContextManager" config changes, let me know ( via
> > Event or callback )
>
> Yes, I don't like the reconfigurable pattern myself, but we could not
> come out with anything better. In fact, Reconfigurable extends Listener,
> listening for global changed. Also note that server reconfiguration is
> normally done on a global scale: you change all the configurations and
> then restart. So doing it in a single place may not be that bad.
:-)
Well, it's done that way because most servers don't come out with anythin
better. ( probably windows users will have problems with that, but you
_don't_ need to restart the computer if you change the IP address :-)
Take a look at JNDI ( notification ), take a look at Novel NDS.
Restarting the component is _bad_ when you just want to change a simple
property.
> > - Search ( find all contexts where "jsp" is not mapped to Jasper )
>
> Can you make an example where this is absolutely required? For the above
> reasons, I tend to think that if you don't know where the configurations
> are, there's something wrong.
Sometimes it's not a simple component/configuration situation.
You may have configuration that is shared by components, or one component
may need to query the config of another component.
Example: a component that will preload all jsp-engines that are registered
by contexts, or will disable any mapping that is not allowed by the
company policy.
Or a component that removes all mentions to a certain user from all user
configs ( == search after "user" attribute ). You may have many
components that define users ( some unknown when you write the remover).
> > - Write access ( so you can change your config )
>
> -1. This is a very bad general practice. A normal component _MUST_ have
> read-only capabilities. Only special read-write components are created
> for configuration updating (example: servlet that changes configurations
> remotely and allows restarting).
What about a smart component that learns at run-time and wants to persist
the changes, for next time it starts?
We are talking about a generic framework, not only servlets, some
components _may_ have read-write access.
( that adds a new requirement - access control for read/write )
> > - Should work at runtime also ( if a config changes, the component should
> > be able to reconfigure itself )
>
> How? this is _very_ hard to do. In avalon we abandoned the research on
> reconfigurable because in many cases it's easier to give up and say "I
> can't do it, kill me" rather than synch-ing all your threads,
> repositories and such without actually doing a shutdown-restart itself.
> Automatic component reconfiguration is most of the times a holy grail.
Well, again take a look at existing systems and APIs. LDAP supports
notification, ( if I remember corectly) NDS supports that, in general it's
something common for directory services.
When a context receive a "timeout changed" notification it can do the
change without restart.
Just take a look at Linux or Solaris kernel - you can change tons of
configurations by a simple write to a proc file. If you can reconfigure
something as complex as a kernel, why should't we try for a damn session
timeout? Yes, Windows needs to be restarted, but that doesn't mean
reconfiguration without reboot is "holy grail".
> > - Embedeable - you should include and bridge to other config APIs
>
> What other config APIs? Properties?
We can't dictate what other application should use, if the application
that embeds tomcat use properties - we should be able to deal with that.
> > - Add your own :-)
>
> I think Costin caught the "flexibility syndrome" about configurations.
> While I totally understand him because we had the exact same problems in
> Avalon (and man, it was hard to stop enlarging the picture every day!),
> but we have to make decisions on what is really required.
No, Costin just described what an existing and mature API can do today.
( and did in the last >6 years - see Netware 4, or NIS ).
I worked few years as net admin, and I had the exact same problems, and
belive me most of that is really required if you have more than 4 servers.
( and for web servers it's very common to have a much larger farm of
computers, in different locations, etc).
> Costin talked about using directory servers as configuration
> repositories. This is not a bad idea at all, but are we really willing
> to make Tomcat depend on an LDAP server on our network? let's be
But are we willing to restrict tomcat to file-based configuration, and to
drop all the features you could get from an LDAP server ?
There is no requirement for an LDAP server - but if you have a directory
server that manage all other subsystems, you want to take advantage of it
( and it's not only LDAP - NDS, ActiveDirectory, etc).
> reasonable. On the other hand, I see no problems in making the
> "configurations" implementation pluggable: Costin admitted he saw some
> LDAP patterns when he saw the Avalon Configuration interfaces. This
> shows you can pretty easily create a Configuration -> JNDI glue to work
> with them and your components do not even know this.
Or we can create a JNDI -> Configuration glue, since the reverse will
lose most of JNDI power. (Right now Configurable is a subset of JNDI.)
Of course, it will not support all features - so you'll need to restart.
> On the other hand, Configurations do not require that much of server
> power: most of their access is direct (means you know what you're
> looking for) and read only. (let's forget about read-write components
> for now since they are a big minority)
Let's see, how many programs allow you to "save" the settings?
Even the windows registry allows that.
Yes, a component should work with "simple", not-so-powerfull
configurations and should be able to deal with that, but again - we are
talking about servers here, that needs to scale up.
> This is, IMO, the very big power of the configurable pattern we designed
> in Avalon and that Cocoon has been very happily using since 6 months.
Well, people are happily using windows.
Do you need to restart Cocoon if a configuration changes?
What if Cocoon will need to change it's own configuration ?
People are happy because Cocoon does something usefull for them, not
because it uses Configurable.
> The Servlet API didn't write methods so that your servlet can
> reconfigure the server. If you do something like this, this is not a
> servlet anymore.
A configuration system should be useable not only by servlets!
Costin
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by Stefano Mazzocchi <st...@apache.org>.
I waited to express my comments based on my Avalon experience to see
where things were going.
I jump in hoping to be helpful.
costin@costin.dnt.ro wrote:
>
> > problem. As far as configuration is concerned, it seems to me that the
> > "outside configuration" approach may not be desired for larger
> > architectures. If you look at servlets or in Avalon, the configurable
> > objects are given a chance to explore a configuration context and do as they
> > please with it. This is the "I'll take care of configuring myself"
>
> I have to agree with you, both patterns are usefull.
Let's analyze the way classes can be configured.
1) the construction pattern: you pass a bunch of parameters at the
construction method and the object creates itself. Simple, easy: the
first thing you learn in the Java tutorial.
Problems: this pattern is not well suited for components that need to be
dynamically linked (reflection with parameters is a pain) or for
components that need lots of parameters to start.
2) the bean pattern. Construction may or may not be empty, but you have
a bunch of set/get methods. A bean can be used as the C-"unit"
equivalent (a container of data from different types) or as an active
component. Ant tasks follow the "active bean" pattern. Note that a bean
can be exposed by a single XML empty element with attributes, one for
each set method.
Problems: this pattern is not well suited for hierarchical
configurations unless the bean<->empty-element link is maintained as a
rule (like in Assaf's tyrex). Also, it is _very_ verbose in cases where
lots of parameters are needed. It is also slower since all parameters
(even those ones never used) must be pushed.
3) the configurable pattern. The Constructor must be empy. There is a
method where configurations that are accessible from this component are
"pushed" inside it. The configurations present a structured (tree-based)
architecture, as well as a simple query ability
(get("root/port/default")).
Problems: once configured, the component must be destroyed in order to
be reconfigured.
NOTE: this pattern is silently used by java applications using
Properties and servlets.
4) the reconfigurable pattern. Reconfigurable extends Configurable.
Another method is provided and it's called by the component manager when
the component needs to be reconfigured. When this happens, the component
must do something and return true if the operation was completed,
otherwise false if this component cannot reconfigure itself. In this
case, the component will be properly shutdown and recreated with the new
configurations.
> We should investigate
> the other aproach "I'll take care of myself", but instead of starting with
> a solution ( like DOM or a simple Configurable ) we should clearly define
> the problem and the goals.
> Like:
>
> - hierarchical configuration ( get( "/ContextManager/Contexts/examples")
This is provided by the Configurable pattern. Look that I'm strongly
against the use of powerful query languages to access configurations
such as SQL or XPath or RegExp. The component _MUST_ know where to find
its configurations. If this contract is broken, this data is _NOT_
configuration data but runtime data and should not be required in this
context.
> - notification ( if "/ContextManager" config changes, let me know ( via
> Event or callback )
Yes, I don't like the reconfigurable pattern myself, but we could not
come out with anything better. In fact, Reconfigurable extends Listener,
listening for global changed. Also note that server reconfiguration is
normally done on a global scale: you change all the configurations and
then restart. So doing it in a single place may not be that bad.
> - Search ( find all contexts where "jsp" is not mapped to Jasper )
Can you make an example where this is absolutely required? For the above
reasons, I tend to think that if you don't know where the configurations
are, there's something wrong.
NOTE: this doesn't mean you know all the configurations, careful. If you
want to know where jsp is not mapped to jasper, you request "contexts"
and you do the search by yourself (I don't mean you write the code, we
can create custom code for that, but this should not be included inside
the configuration API)
> - Write access ( so you can change your config )
-1. This is a very bad general practice. A normal component _MUST_ have
read-only capabilities. Only special read-write components are created
for configuration updating (example: servlet that changes configurations
remotely and allows restarting).
> - Should work at runtime also ( if a config changes, the component should
> be able to reconfigure itself )
How? this is _very_ hard to do. In avalon we abandoned the research on
reconfigurable because in many cases it's easier to give up and say "I
can't do it, kill me" rather than synch-ing all your threads,
repositories and such without actually doing a shutdown-restart itself.
Automatic component reconfiguration is most of the times a holy grail.
> - Embedeable - you should include and bridge to other config APIs
What other config APIs? Properties?
> - Add your own :-)
I think Costin caught the "flexibility syndrome" about configurations.
While I totally understand him because we had the exact same problems in
Avalon (and man, it was hard to stop enlarging the picture every day!),
but we have to make decisions on what is really required.
Costin talked about using directory servers as configuration
repositories. This is not a bad idea at all, but are we really willing
to make Tomcat depend on an LDAP server on our network? let's be
reasonable. On the other hand, I see no problems in making the
"configurations" implementation pluggable: Costin admitted he saw some
LDAP patterns when he saw the Avalon Configuration interfaces. This
shows you can pretty easily create a Configuration -> JNDI glue to work
with them and your components do not even know this.
On the other hand, Configurations do not require that much of server
power: most of their access is direct (means you know what you're
looking for) and read only. (let's forget about read-write components
for now since they are a big minority)
Also, note how I did not talk about XML config nor I included SAX nor
DOM. Configuration is a single interface with some 10 methods and
provide you access to a structured configuration hierachy. If this
implemented using DOM, or a custom tree-like memory stucture filled with
SAX, or even an RDMBS system, this is _totally_ transparent.
This is, IMO, the very big power of the configurable pattern we designed
in Avalon and that Cocoon has been very happily using since 6 months.
> I think "notification" is very important if we want to support "run-time"
> configuration changes ( i.e. you want to be able to change sessionTimeout
> of a context without restarting the server. ), and it's a missing features
> in almost all APIs I saw.
some 18 months ago I proposed a new configuration pattern for JServ that
was adopted. this went into ExtendedProperties, the classes that JServ
(and Turbine, ASAIK) is currently using. This patterns allows you to
automatically update your used configurations with a minimum overhead.
The idea is simple:
normally, every configuration pattern provides you with data that you
copy on a local variable. If the configuration gets changed, the
component must be notified in order to update that local copy. To do
this, the component must register for notification and be able to
synchronize its operation on such change. Sometimes this is trivial (as
for sessionTimeout) sometimes is not (as for SocketPort).
ExtendedProperties provide fast methods to retrieve configurations so
that you should always ask them on the main repository rather than copy
them locally (note: for speed issues, many times this practice is not
used in JServ.)
I don't think this it the perfect solution, but it's a pattern worth
considering for an alternative in some cases (DB-based web app use the
same pattern where data is stored in the database rather than locally on
files, but we all know how this pattern is slow and unscalable).
> The Ant "outside configuration" is very good because makes this very easy,
> you can have run-time calls to the setter methods, and you can ask
> running components about their configuration. That will help a lot any
> admin tool.
I think we should not mix admin tools with component configurations.
These are different things. If I am a component write and the API are
harder to read because they contain methods I'll never use, there's
something wrong.
The Servlet API didn't write methods so that your servlet can
reconfigure the server. If you do something like this, this is not a
servlet anymore.
This is the pattern I would like us to follow.
I do consider admin-components, but they are special entities and do
require to have more access than normal read-only components.
> Please keep in mind that if you write an "outside-configurable" component
> you can easily plug in a bridge to an "ask-for-config" API, but the
> reverse is not true ( "I-take-care-of-myself" components can't be changed
> by an external entity unless they follow both patterns ).
> Because of that, all "regular" components should still try to
> follow the "outside-config".
I think this holds true only for flat files where you can map the bean
pattern to the empty element pattern used in Ant.
Unfortunately for all of you bean-pattern lovers, this is a _very_
special case.
While I like Ant limitations on that direction (they reduce flexibility
syndrome), I think it should be wrong to impose such limitation on a
general configuration pattern.
Also, I think that doing what Arkin proposed (map of every element to a
bean-like object) is even worse.
So, since you cannot know how complex the configuration DTD will be, I
pass its root node to the component and give it simple yet powerful API
to come up with that it needs.
This is not an XML binding proposal, it's a real-life API for real-life
needs. And, man, all the cocoon developers are super happy with that.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by co...@costin.dnt.ro.
> problem. As far as configuration is concerned, it seems to me that the
> "outside configuration" approach may not be desired for larger
> architectures. If you look at servlets or in Avalon, the configurable
> objects are given a chance to explore a configuration context and do as they
> please with it. This is the "I'll take care of configuring myself"
I have to agree with you, both patterns are usefull. We should investigate
the other aproach "I'll take care of myself", but instead of starting with
a solution ( like DOM or a simple Configurable ) we should clearly define
the problem and the goals.
Like:
- hierarchical configuration ( get( "/ContextManager/Contexts/examples")
- notification ( if "/ContextManager" config changes, let me know ( via
Event or callback )
- Search ( find all contexts where "jsp" is not mapped to Jasper )
- Write access ( so you can change your config )
- Should work at runtime also ( if a config changes, the component should
be able to reconfigure itself )
- Embedeable - you should include and bridge to other config APIs
- Add your own :-)
I think "notification" is very important if we want to support "run-time"
configuration changes ( i.e. you want to be able to change sessionTimeout
of a context without restarting the server. ), and it's a missing features
in almost all APIs I saw.
The Ant "outside configuration" is very good because makes this very easy,
you can have run-time calls to the setter methods, and you can ask
running components about their configuration. That will help a lot any
admin tool.
Please keep in mind that if you write an "outside-configurable" component
you can easily plug in a bridge to an "ask-for-config" API, but the
reverse is not true ( "I-take-care-of-myself" components can't be changed
by an external entity unless they follow both patterns ).
Because of that, all "regular" components should still try to
follow the "outside-config".
Costin
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by Luis Arias <lu...@elysia.com>.
----- Original Message -----
From: Craig R. McClanahan <cm...@mytownnet.com>
To: <to...@jakarta.apache.org>
Sent: Friday, January 21, 2000 6:18 AM
Subject: Re: [Catalina] Discussion - Component Configuration Strategy
>
> I like the introspection approach Ant uses as well, but (by itself), and I
> can see how that lets you configure an individual component's basic
> properties "from the outside", which is exactly what Ant does. But it
> doesn't help me understand how to configure components that have a
> hierarchical relationship with each other elegantly. Most "configurator"
> patterns I've seen seem to gloss over this issue -- and Ant does not need
> it when you create TaskDefs. Have you got any thoughts on a design
pattern
> for this problem?
>
I had started a big discussion concerning this type of issue in Ant a while
back. (And I learned a great deal :-) Costin's new code sounds neat and
would be a major improvement. My worry was exactly of finding a way to
conserve hierarchical relationships in the ant build file, and generally in
any xml - object mapping. But it's a more general xml represantation
problem. As far as configuration is concerned, it seems to me that the
"outside configuration" approach may not be desired for larger
architectures. If you look at servlets or in Avalon, the configurable
objects are given a chance to explore a configuration context and do as they
please with it. This is the "I'll take care of configuring myself"
approach. Probably what would be best is a synthesis of the two approaches
where it's possible for a configurable object to specify that it want's to
be "auto-configured" yet still have access to the configuration context in
case it wants to explore its configuration neighborhood .
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by Assaf Arkin <ar...@exoffice.com>.
"Craig R. McClanahan" wrote:
>
> Assaf Arkin wrote:
>
> > [snip]
> > For that reason I like tha Ant model better. I just created a new
> > TaskDef without asking myself whether Ant is using DOM or SAX and
> > whether that would change tomorrow. For all I care it might switch to
> > non-XML documents or remote objects.
> >
>
> I like the introspection approach Ant uses as well, but (by itself), and I
> can see how that lets you configure an individual component's basic
> properties "from the outside", which is exactly what Ant does. But it
> doesn't help me understand how to configure components that have a
> hierarchical relationship with each other elegantly. Most "configurator"
> patterns I've seen seem to gloss over this issue -- and Ant does not need
> it when you create TaskDefs. Have you got any thoughts on a design pattern
> for this problem?
Simple solution, if you find that a property is not a simple type, you
construct an object and configure it.
So, if I have a Foo with setValue( String ) and setBar( Bar ), I first
look for an element called 'value' and do setValue() with that. Then,
knowning that Bar is a complex type, I create a new Bar and do a setBar
with it.
Once Bar has been created, the next element is expected to be a <bar>
which is read in order to configure Bar itself, just like its parent Foo
was configured.
Tyrex uses that scheme for the configuration file. I have a set of
objects all over the place in different packages (including arbitrary
JDBC drivers), and the tree is composed in such a manner.
arkin
>
> >
> > arkin
> >
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by co...@costin.dnt.ro.
> I like the introspection approach Ant uses as well, but (by itself), and I
> can see how that lets you configure an individual component's basic
> properties "from the outside", which is exactly what Ant does. But it
> doesn't help me understand how to configure components that have a
> hierarchical relationship with each other elegantly. Most "configurator"
> patterns I've seen seem to gloss over this issue -- and Ant does not need
> it when you create TaskDefs. Have you got any thoughts on a design pattern
> for this problem?
Take a look at tomcat.startup.Tomcat and the 2 helper classes,
IntrospectionHelper and XmlHelper. ( and the new tomcat.xml )
It's code I cut&pasted from Ant, replaced DOM with SAX ( I am more
familiar with SAX ), and added few new patterns to handle
the hierarchy ( subject to change, based on your feedback).
The patterns ( besides ant attribute setting to bean properties):
<foo>
<bar name=1/>
<bar name=2/>
</foo>
will generate:
foo=new Foo();
bar1=new Bar();
bar1.setName(1);
bar1.setFoo( foo ); // set parent - if a setFoo() method is found in bar
foo.addBar( bar1);
bar2=new Bar();
bar2.setName(2);
bar2.setFoo(foo);
foo.addBar( bar2);
With additiona tricks:
- setFoo() will be searched first, then any setXXX where XXX is an
interface implemented by foo.
Same for addBar()
( see ContextManger.addConnector(), and will work for all conntectors )
There are few more tricks ( needed to support loading of server.xml using
the new framework ), and I plan to add more tricks to be able to load
web.xml too ( web.xml also use XmlTree, and reading it is a bit to
complex)
Costin
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Assaf Arkin wrote:
> [snip]
> For that reason I like tha Ant model better. I just created a new
> TaskDef without asking myself whether Ant is using DOM or SAX and
> whether that would change tomorrow. For all I care it might switch to
> non-XML documents or remote objects.
>
I like the introspection approach Ant uses as well, but (by itself), and I
can see how that lets you configure an individual component's basic
properties "from the outside", which is exactly what Ant does. But it
doesn't help me understand how to configure components that have a
hierarchical relationship with each other elegantly. Most "configurator"
patterns I've seen seem to gloss over this issue -- and Ant does not need
it when you create TaskDefs. Have you got any thoughts on a design pattern
for this problem?
>
> arkin
>
Craig McClanahan
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 1/20/00 12:01 PM, Assaf Arkin at arkin@exoffice.com wrote:
> I have one point to make. The fact that Tomcat is using DOM is an
> implementation decision, not a design decision. Tomcat can be upgraded
> tomorrow to use SAX, for example. It doesn't make sense, but it can be
> done.
Well, DOM doesn't make much sense (to me) as a seperate object tree is
actually being created. But whatever, I'm not religous -- however the
implementors of that code choose to do it is ok as it's not on the critical
performance path.
> For that reason I like tha Ant model better. I just created a new
> TaskDef without asking myself whether Ant is using DOM or SAX and
> whether that would change tomorrow. For all I care it might switch to
> non-XML documents or remote objects.
That was the point with the Ant model -- to get away from XML specifics and
just let XML does what it does best (imo) -- be a data format.
.duncan
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: [Catalina] Discussion - Component Configuration Strategy
Posted by Assaf Arkin <ar...@exoffice.com>.
I have one point to make. The fact that Tomcat is using DOM is an
implementation decision, not a design decision. Tomcat can be upgraded
tomorrow to use SAX, for example. It doesn't make sense, but it can be
done.
For that reason I like tha Ant model better. I just created a new
TaskDef without asking myself whether Ant is using DOM or SAX and
whether that would change tomorrow. For all I care it might switch to
non-XML documents or remote objects.
arkin
"Craig R. McClanahan" wrote:
>
> One aspect of the proposed architecture is certain to engender further
> discussion -- the use of the org.w3c.dom "Node" interface as the means
> by which components receive their component configuration information.
> This choice was made initially for the following reasons:
>
> * Any deployment of Tomcat is going to need to
> parse "web.xml" files anyway, so it is essentially
> certain to have the DOM classes, and an appropriate
> XML parser, hanging around.
>
> * The approach to this taken sometimes in the current
> Tomcat code (convert the DOM to an implementation
> of org.apache.tomcat.util.XmlTree) seems like overkill
> for something that is used one time.
>
> * The DOM elegantly reflects the hierarchical nature of
> component organization within a Tomcat deployment.
> As an example of this, see the "server.xml" file in the
> top level ("proposals/catalina") directory -- it illustrates
> how components in the new proposal nest themselves.
> It would be desireable (IMHO) that any configuration
> mechanism we actually build be able to parse and
> process such a configuration file -- at least until we
> have tools that hide the actual server.xml syntax.
>
> * Configuration is only one of the issues involved -- the
> start/stop functionality is also important (although you can
> modify the configuration mechanism without giving this up).
>
> Counter-arguments and alternative suggestions that have been expressed
> so far include:
>
> * It is not particularly elegant to make the core components
> of Tomcat dependent upon an external package like the
> DOM classes.
>
> * Any XML parsing required can be done external to the
> core, and components should be able to be configured
> by these external mechanisms in a more typical JavaBeans
> fashion.
>
> * Consider using introspection to identify the properties
> that can be set from the configuration, in a manner similar
> to what Ant does when configuring tasks. (I'm very +1
> on doing this).
>
> * Consider using the Configurable interface (and possibly
> others like Block as well) from the Avalon framework.
> I'd really appreciate some comments from people more
> familiar with Avalon on how applicable it might be here.
>
> What do we all think? How should Catalina components be configured?
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org