directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject svn commit: rev 53948 - incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config
Date Thu, 07 Oct 2004 07:29:45 GMT
Author: akarasulu
Date: Thu Oct  7 00:29:44 2004
New Revision: 53948

Added:
   incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/AttributeTypeConfigSet.java
  (contents, props changed)
   incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/ConfigurationSet.java
  (contents, props changed)
   incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/SyntaxConfigSet.java
  (contents, props changed)
Modified:
   incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/AttributeTypeConfig.java
   incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/SyntaxConfig.java
   incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/package.html
Log:
starting to get the picture of how to handle deps and refactoring

Modified: incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/AttributeTypeConfig.java
==============================================================================
--- incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/AttributeTypeConfig.java
(original)
+++ incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/AttributeTypeConfig.java
Thu Oct  7 00:29:44 2004
@@ -23,6 +23,6 @@
  *         Project</a>
  * @version $Rev$
  */
-public class AttributeTypeConfig
+public class AttributeTypeConfig implements AttributeTypeConfigSet
 {
 }

Added: incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/AttributeTypeConfigSet.java
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/AttributeTypeConfigSet.java
Thu Oct  7 00:29:44 2004
@@ -0,0 +1,28 @@
+/*
+ *   Copyright 2004 The Apache Software Foundation
+ *
+ *   Licensed under the Apache License, Version 2.0 (the "License");
+ *   you may not use this file except in compliance with the License.
+ *   You may obtain a copy of the License at
+ *
+ *       http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *   Unless required by applicable law or agreed to in writing, software
+ *   distributed under the License is distributed on an "AS IS" BASIS,
+ *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *   See the License for the specific language governing permissions and
+ *   limitations under the License.
+ *
+ */
+package org.apache.eve.schema.config;
+
+/**
+ * Document me.
+ *
+ * @author <a href="mailto:directory-dev@incubator.apache.org">Apache Directory
+ *         Project</a>
+ * @version $Rev$
+ */
+public interface AttributeTypeConfigSet
+{
+}

Added: incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/ConfigurationSet.java
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/ConfigurationSet.java
Thu Oct  7 00:29:44 2004
@@ -0,0 +1,53 @@
+/*
+ *   Copyright 2004 The Apache Software Foundation
+ *
+ *   Licensed under the Apache License, Version 2.0 (the "License");
+ *   you may not use this file except in compliance with the License.
+ *   You may obtain a copy of the License at
+ *
+ *       http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *   Unless required by applicable law or agreed to in writing, software
+ *   distributed under the License is distributed on an "AS IS" BASIS,
+ *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *   See the License for the specific language governing permissions and
+ *   limitations under the License.
+ *
+ */
+package org.apache.eve.schema.config;
+
+
+/**
+ * A configuration of like Schema objects bundled together and identified as a
+ * set.
+ *
+ * @author <a href="mailto:directory-dev@incubator.apache.org">Apache Directory Project</a>
+ * @version $Rev$
+ */
+public interface ConfigurationSet
+{
+    /**
+     * Gets the name of the owner of the schema objects within this
+     * ConfigurationSet.
+     *
+     * @return the identifier for the owner of this set's objects
+     */
+    String getOwner();
+
+    /**
+     * Gets the name of the logical schema the objects of this ConfigurationSet
+     * belong to: e.g. krb5-kdc may be the logical LDAP schema name.
+     *
+     * @return the name of the logical schema
+     */
+    String getSchemaName();
+
+    /**
+     * Gets the names of other schemas that this objects within this
+     * ConfigurationSet depends upon.  These dependent schemas are those
+     * whose ConfigurationSets will be processed first.
+     *
+     * @return the String names of schema dependencies
+     */
+    String[] getDependentSchemas();
+}

Modified: incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/SyntaxConfig.java
==============================================================================
--- incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/SyntaxConfig.java
(original)
+++ incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/SyntaxConfig.java
Thu Oct  7 00:29:44 2004
@@ -28,7 +28,7 @@
  * @author <a href="mailto:directory-dev@incubator.apache.org">Apache Directory Project</a>
  * @version $Rev$
  */
-public class SyntaxConfig
+public class SyntaxConfig implements SyntaxConfigSet
 {
     public Syntax[] loadSyntaxes( SyntaxCheckerRegistry registry )
     {

Added: incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/SyntaxConfigSet.java
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/SyntaxConfigSet.java
Thu Oct  7 00:29:44 2004
@@ -0,0 +1,28 @@
+/*
+ *   Copyright 2004 The Apache Software Foundation
+ *
+ *   Licensed under the Apache License, Version 2.0 (the "License");
+ *   you may not use this file except in compliance with the License.
+ *   You may obtain a copy of the License at
+ *
+ *       http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *   Unless required by applicable law or agreed to in writing, software
+ *   distributed under the License is distributed on an "AS IS" BASIS,
+ *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *   See the License for the specific language governing permissions and
+ *   limitations under the License.
+ *
+ */
+package org.apache.eve.schema.config;
+
+/**
+ * Document me.
+ *
+ * @author <a href="mailto:directory-dev@incubator.apache.org">Apache Directory
+ *         Project</a>
+ * @version $Rev$
+ */
+public interface SyntaxConfigSet
+{
+}

Modified: incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/package.html
==============================================================================
--- incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/package.html
(original)
+++ incubator/directory/eve/trunk/backend/core/src/java/org/apache/eve/schema/config/package.html
Thu Oct  7 00:29:44 2004
@@ -1,3 +1,106 @@
 <p>
-Contains interfaces and classes used for baseline schema object configurations.
-</p>
\ No newline at end of file
+Contains interfaces and classes used for bootstrap schema object loading and
+configuration.
+</p>
+
+<p>
+Breifly, before delving into the reasons behind our choices, we would like to
+summarize what is here.  First off each schema entity of significance whether
+defined by the protocol or not is introduced into the system using a bootstrap
+configuration set class.  This is a class that implements a specific interface
+for creating all the needed schema objects to establish a baseline within the
+system.  All such schema objects generated will be owned by the directory
+administrator.  Furthermore these objects are temporary and can be overridden
+in the solid state using altered versions that are authoritative definitions
+within the system backend.
+</p>
+
+<p>
+Just what does all this mean?  Hard coded schema objects in Java classes
+which implement a configuration set interface can be loaded into the system
+and used while bootstrapping it.  If this is the first time bootstrapping,
+meaning these objects are NOT found within the system backend, they will
+be persisted into the system backend at the very end of the bootstrap stage so
+they can be resolved in the solid state.  Changes to these objects via LDAP
+within the system backend by the admin persist across bootstrap sessions.  They
+persist because the bootstrap object is never stored in the system backend
+if a record for that object already exists.
+</p>
+
+<p>
+Why are we storing a configuration directly in Java code?  First off the
+likelihood of altering schema object fields to bootstrap the system is highly
+unlikely.  Secondly most of these objects are published static entities and
+changing them would have serious repercussions.  Hence its highly unlikely
+that these objects will change and there is no need to get complex to try
+to have an external representation for these schema objects.  The
+representation of these objects as entries and attributes within the directory
+is enough of an external representation.  Schema manipulation tools already
+exist for making changes so why have another additional
+mechanism/representation as well.
+</p>
+
+
+<hr>
+
+
+<h3>Notes:</h3>
+
+<ul>
+  <li>
+    Baseline schema configuration sets are loaded first.
+  </li>
+
+  <li>
+    Within a logical schema (e.g. krb5-kdc) the ConfigurationSets of that
+    schema will be loaded in an order consistent with datatype dependencies.
+    For example a ConfigurationSet (CS) for SyntaxCheckers will be loaded
+    before the one for Syntaxes within the same schema.  This is because
+    Syntaxes depend upon SyntaxCheckers and the proper SyntaxChecker must be
+    resolvable via the SyntaxChecker registry.
+  </li>
+
+  <li>
+    A CS shall contain schema objects associated with a specific owner, and a
+    specific logical schema.  The set of CS schema objects may depend on
+    Schema objects within other logic schemas, hence other CS objects.  These
+    dependencies on other logical schemas are exposed by the CS interface.
+  </li>
+
+  <li>
+    Other user defined CS classes can be loaded by the system as well.  The
+    system can search on the classpath for classes implementing the CS
+    interface.  It would then need to analyze dependencies to determine which
+    schema object sets to process/load first.  This is the most rudimentary
+    of mechanisms for users to introduce new schema objects into the system.
+    The other means is during the solid state through LDAP itself.  Changes
+    can be made along with new schema object introductions via schemaSubentry
+    changes in the usual LDAP manager where schema objects are attributes in
+    a massive entry.  Another means is through the alteration of easier to
+    manage entries for schema objects through the system namespace.  Changes
+    to either schemaSubEntry attributes or system namespace schema entries both
+    mirror one another.  A change to one propagates to the other: the same
+    entity is being manipulated through two different views.  One is a heck of
+    a lot more manageable.
+  </li>
+
+  <li>
+    We can add a resolver interface so a resolver can be registered after
+    bootstrapping with a registry.  In the case of a registry miss we ask the
+    resolver for the object.  If it cannot find it then well we're out of luck.
+    Once the resolver is set for solid state operation, registry misses make
+    the resolver go to disk on the system backend for authoritative copies.
+  </li>
+
+  <li>
+    The resolver concept mentioned above can itself be another registry.  It's
+    just a secondary disk registry used when the first misses disk.  So hence
+    other registries should be able to be registerable with others to allow for
+    registry delegation like the way classloaders delegate.  This way there is
+    no need to replace bootstrap registries.  Once they have enough info to
+    enable disk access, they can tap secondary schema information on disk to
+    override the bootstrap objects first of all.  Secondly in the solid state
+    schema objects can be brought into memory from disk.
+  </li>
+</ul>
+

Mime
View raw message