hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-hivemind Wiki] Trivial Update of "DescriptorApiRevampProposal" by KnutWannheden
Date Thu, 23 Jun 2005 09:28:13 GMT
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


Mime
View raw message