Mailing-List: contact commits-help@hivemind.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hivemind.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: hivemind-cvs@jakarta.apache.org
Date: Tue, 07 Nov 2006 14:11:44 -0000
Message-ID: <20061107141144.6853.97677@ajax.apache.org>
Subject: [Jakarta-hivemind Wiki] Update of
 "NewAndNoteworthyFeaturesInAnnotationBranch" by AchimHuegen

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 AchimHuegen:
http://wiki.apache.org/jakarta-hivemind/NewAndNoteworthyFeaturesInAnnotationBranch

------------------------------------------------------------------------------
  
  == Arbitrary Configuration Types ==
  
+ Configurations are no longer restricted to lists. A configuration can be of any type whereas
+ collections will be the most common case. Like service points that separate between the 
+ service interface and the service implementation a configuration has a type and an implementation
+ (called container) which is responsible for the aggregation of the configuration data. 
+ To be backward compatible any configuration
+ defined in a xml module is by default of type java.util.List and uses an ArrayList as container
+ (there are some exceptions to this rule when dealing with unique attributes and mapped configurations).
+ 
+ The container object is passed around to the different contributions which can add new
+ data to it.
+ 
+ Example for a map based configuration:
+ {{{
+   @Configuration(id = "FactoryConfig")
+   public Map getFactoryConfig()
+   {
+     return new HashMap();
+   }
+ 
+   @Contribution(configurationId = "FactoryConfig")
+   public void contributeToFactory(Map container)
+   {
+     container.put("map", "java.util.HashMap");
+     container.put("collection", "java.util.ArrayList");
+     container.put("inputStream", "java.io.ByteArrayInputStream");
+   }
+ }}}
+ 
+ The configuration type of an xml configuration point is optionally defined 
+ by the container-class attribute (uuuh .. need some cleanup here).
+ The container implementation is defined by the root-element-class attribute
+ of a schema. An instance of the specified class is created and moved on the
+ top of the Element-Stack when a contribution is parsed.  
+ 
+ {{{
+   <configuration-point id="ObjectProviders" container-class="java.util.Map">
+      
+     <schema root-element-class="java.util.HashMap">
+       <element name="provider" >
+         ... 
+         <rules>
+          <push-attribute attribute="prefix"/>
+          <push-attribute attribute="service-id"/>
+          <invoke-parent method="put" parameter-count="2"/>
+         </rules>
+       </element>
+     </schema>
+   </configuration-point>
+ }}}
+ 
  == Subsequent Schema Assignment ==
  
+ The new element <schema-assignment> in module descriptors allows to assign schemas to
+ configuration points which have been defined in a non xml module. 
+ {{{
+   <schema-assignment configuration-id="hivemind.SymbolSources" schema-id="SymbolSources" />
+   <schema id="SymbolSources">
+      ...
+   </schem>
+ }}}
+ 
+ It's mainly used to retain backward compatibility. Certain configurations are defined
+ in the core framework now which knows nothing about schemas.
+ 
+ 
+