You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@apache.org on 2002/07/12 19:45:44 UTC
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/conf Config.java package.html
costin 2002/07/12 10:45:44
Added: util/java/org/apache/tomcat/util/conf Config.java
package.html
Log:
Initial version for the proposed 2-layer config tool.
The main focus is to deal with storing the configuration and
supporting the current bean-model of tomcat as well as JMX components.
The Config interface is all that a user ( i.e. management app or
Main/Catalina/Startup component that sets up tomcat ) will use.
Internally it'll use jdk1.4 prefs / JNDI / XML / INI / Properties
to read/store the data, and the current Bean introspection or JMX
to configure the runtime.
Any change to the runtime must be done via Config or JMX ( Config
will use the JMX notifications to intercept the settings on JMX ).
Config will persist the user changes ( and only user changes, as
oposed to calling all getters ).
In addition I would like to support the ${} properties ( as supported
by tomcat3.3 ), and have the storage use ${} expressions.
Please - review and help !
Revision Changes Path
1.1 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/conf/Config.java
Index: Config.java
===================================================================
/*
* ====================================================================
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The end-user documentation included with the redistribution, if
* any, must include the following acknowlegement:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowlegement may appear in the software itself,
* if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
* Foundation" must not be used to endorse or promote products derived
* from this software without prior written permission. For written
* permission, please contact apache@apache.org.
*
* 5. Products derived from this software may not be called "Apache"
* nor may "Apache" appear in their names without prior written
* permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* ====================================================================
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.tomcat.util.conf;
import java.io.*;
import java.util.*;
/**
* This is the interface that the user sees. It can be used to set
* and retrieve config information on components and to deal with the
* storage of this information.
*
* The user of this interface is typically the component
* that deal with configuration of the application, or a management
* application.
*
* The Config interface can store/retrieve attribute on named objects
* or nodes on either layer - both the persistent storage and the
* runtime objects.
*
* The Config will do ${} replacement in string values. Retrieving
* or values from the store will use the un-expanded form. The ${}
* names will be attributes of the base node, or from a different
* node.
*
* @author Costin Manolache
*/
public class Config {
/** Modify both the runtime and the store
*/
public static final int BOTH=0;
/** Modify or read only the stored value
*/
public static final int STORE=1;
/** Modify or read the runtime value
*/
public static final int RUNTIME=2;
/**
*/
public static Config getConfig(String base) {
return null;
}
protected Config() {
}
public void setAttribute(String node, String name, Object value, int type ) {
}
public void setIntAttribute(String node, String name, int value, int type ) {
}
public Object getAttribute(String node, String name, int type ) {
return null;
}
public int getIntAttribute(String node, String name, int type ) {
return 0;
}
public void removeAttribute( String node, String name, int type ) {
}
public void removeNode( String node, int type ) {
}
}
1.1 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/conf/package.html
Index: package.html
===================================================================
<h2>Package org.apache.tomcat.util.prefs</h2>
<p>This package abstract the configuration for tomcat ( or any other
application using a similar 2-layer configuration model ). </p>
<h3>Data storage</h3>
<p>The first layer deals with storing the data. It is modeled after
java.util.prefs, JNDI and other similar config mechanisms - with the
intention of beeing easily adaptable to any of those.
<p>It'll use a discovery mechanism ( similar with jaxp, commons loggig )
and should be able to use JDK1.4 prefs, directory servers, Win32 Registry,
XML config files, INI-style config files, properties files ( with a
naming convention to represent hierarchical information ).
<p>A secondary goal for this package is to allow the config data
to be 'exposed' as a standard JDK1.4 prefs implementation, so
(web)applications using JDK1.4 prefs can use the same data store
( but not the same data ! ).
<p>An important consideration is the security and insolation of different
applications - the current JDK1.4 doesn't provide the fine-grained
security needed for a web environment, and we'll have to provide it
in the implementation.
<h3>Component configuration</h3>
<p>The second layer supports a Java Bean model for the application
components, similar with tomcat and many other applications.
<p>In addition, this will be closely integrated with JMX, allowing
us to support and persist changes made using JMX on all managed
components. The only requirement is that changes are made either
using this API, or that the Notification is supported in the
MBeans ( true for ModelMBeans and any other MBean that chooses to).
<h3>Implementation</h3>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/conf
Config.java package.html
Posted by co...@covalent.net.
On Fri, 12 Jul 2002, Bill Barker wrote:
> I know you hate interfaces :-), but this really does look like it should be
> an interface at the moment.
What about abstract class :-) ?
The major reason I don't like interfaces is backward compatibility issues
( like the ones we see in JDK1.4 Connection ). It'll also have some
convenience methods in it - and it's easier to implement them in the
base and reduce the number of methods in the provider. Plus the static
method for discovery.
I don't think we'll have a lot of multiple-inheritance with this.
Of course, if everyone believe it's better to be an interface, I
can live with that. But at least let's wait until we have an
implementation and see how it works out, then we can make it interface.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/conf Config.java package.html
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: <co...@apache.org>
To: <ja...@apache.org>
Sent: Friday, July 12, 2002 10:45 AM
Subject: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/conf Config.java
package.html
> costin 2002/07/12 10:45:44
>
> Added: util/java/org/apache/tomcat/util/conf Config.java
> package.html
> Log:
> Initial version for the proposed 2-layer config tool.
>
> The main focus is to deal with storing the configuration and
> supporting the current bean-model of tomcat as well as JMX components.
>
> The Config interface is all that a user ( i.e. management app or
> Main/Catalina/Startup component that sets up tomcat ) will use.
>
> Internally it'll use jdk1.4 prefs / JNDI / XML / INI / Properties
> to read/store the data, and the current Bean introspection or JMX
> to configure the runtime.
>
> Any change to the runtime must be done via Config or JMX ( Config
> will use the JMX notifications to intercept the settings on JMX ).
> Config will persist the user changes ( and only user changes, as
> oposed to calling all getters ).
>
> In addition I would like to support the ${} properties ( as supported
> by tomcat3.3 ), and have the storage use ${} expressions.
>
> Please - review and help !
>
I know you hate interfaces :-), but this really does look like it should be
an interface at the moment.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>