[Jakarta-hivemind Wiki] Trivial Update of "DescriptorApiRevampProposal" by KnutWannheden

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-hivemind Wiki" for change notification.

The following page has been changed by KnutWannheden:
http://wiki.apache.org/jakarta-hivemind/DescriptorApiRevampProposal

------------------------------------------------------------------------------
  The approach of the proposed solution is to move to a more abstract '''Descriptor API''' and factor the XML specifics into an XML implementation (based on this API).  Apart from the XML shorthand notations reflected in the current API it is primarily the ''schema processing'' which I consider as XML specific.  Factoring that out will in turn also affect parts of the '''Runtime API''' and implementation.
  
  == Descriptor API ==
- Here is an overview of the proposed Descriptor API.
+ Here is an overview of the proposed Descriptor API (package {{{org.apache.hivemind.descriptor}}}).
  
  {{{
  public interface Module
@@ -79, +79 @@

  }
  }}}
  
+ {{{
+ public interface Schema
+ {
+     public String getId();
+     public Visibility getVisibility();
+ }
+ }}}
+ 
  Some important notes:
-  * The described interfaces are all part of a package {{{org.apache.hivemind.descriptor}}}.  Possibly they should all have a ''Descriptor'' suffix to avoid confusion with existing internal interfaces.
+  * Possibly the interfaces should all have a ''Descriptor'' suffix to avoid confusion with existing internal interfaces.
-  * The link between a module and its constituents (i.e. extension points and extensions) is established using a visitor pattern.  For reasons of brevity the {{{public void accept(DescriptorVisitor visitor)}}} method on the various interfaces is not shown.
+  * The link between a module and its constituents (i.e. extension points, extensions, and schemas) is established using a visitor pattern.  For reasons of brevity the {{{public void accept(DescriptorVisitor visitor)}}} method on the various interfaces is not shown.
   * The ''!RegistryBuilder'' part of the Descriptor API has been left out, as it should remain the same.
   * The ordering of interceptors (and eventually configuration contributions) is here not explicitly addressed but could be realized by letting an implementation also implement the !HiveMind {{{Orderable}}} interface.
   * The {{{getConstructor()}}} methods in ''Implementation'', ''Interceptor'', and ''Contribution'' establish the link to the Runtime API.  The returned objects will be used at runtime to lazily instantiate the actual objects.  The referenced interfaces are described in the following.
@@ -116, +124 @@

  }
  }}}
  
+ Some notes:
+  * The interfaces ''!ServiceImplementationConstructor'' and ''!ServiceInterceptorConstructor'' already exist (although with different names). The difference is that the ''context'' is provided as explicit method arguments.
+  * The interface ''!ConfigurationContributionConstructor'' does not have correspondance in the current code.
+ 
  = Discussion =
  

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org