hlship 2004/12/19 07:44:33
Modified: . .classpath status.xml
src/documentation/content/xdocs index.xml groovy.xml
override.xml
framework build.xml
Log:
Document changes to SpringLookupFactory, the new spring: ObjectProvider, and
the ability to easily override service implementations.
Revision Changes Path
1.44 +1 -0 jakarta-hivemind/.classpath
Index: .classpath
===================================================================
RCS file: /home/cvs/jakarta-hivemind/.classpath,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- .classpath 5 Dec 2004 16:43:19 -0000 1.43
+++ .classpath 19 Dec 2004 15:44:33 -0000 1.44
@@ -1,5 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
+ <classpathentry exported="true" kind="var" path="CLOVER_RUNTIME"/>
<classpathentry output="framework/target/eclipse-test-classes"
kind="src" path="framework/src/conf"/>
<classpathentry output="framework/target/eclipse-classes" kind="src"
path="framework/src/java"/>
<classpathentry output="framework/target/eclipse-test-classes"
kind="src" path="framework/src/test"/>
1.84 +4 -0 jakarta-hivemind/status.xml
Index: status.xml
===================================================================
RCS file: /home/cvs/jakarta-hivemind/status.xml,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- status.xml 5 Dec 2004 16:43:19 -0000 1.83
+++ status.xml 19 Dec 2004 15:44:33 -0000 1.84
@@ -112,6 +112,10 @@
Support the EasyMock Class Extension, if present on the classpath,
to allow classes (not just
interfaces) to be mocked.
</action>
+ <action type="update" dev="HLS">
+ Refactored SpringLookupFactory to identify a Spring BeanFactory
directly, rather than
+ via a SpringBeanFactorySource.
+ </action>
</release>
<release version="1.0" date="Sep 22 2004">
1.23 +2 -0
jakarta-hivemind/src/documentation/content/xdocs/index.xml
Index: index.xml
===================================================================
RCS file:
/home/cvs/jakarta-hivemind/src/documentation/content/xdocs/index.xml,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- index.xml 8 Nov 2004 14:14:24 -0000 1.22
+++ index.xml 19 Dec 2004 15:44:33 -0000 1.23
@@ -105,6 +105,8 @@
removed.</li>
<li>The module parameter has also been removed from the
DefaultImplementationBuilder's
buildDefaultImplementation() method.</li>
+ <li>The <link
href="site:hivemind.lib.SpringLookupFactory">SpringLookupFactory</link> and its
parameters
+ now specify a Spring BeanFactory instance, rather than a
SpringBeanFactorySource.</li>
</ul>
</section>
1.3 +2 -1
jakarta-hivemind/src/documentation/content/xdocs/groovy.xml
Index: groovy.xml
===================================================================
RCS file:
/home/cvs/jakarta-hivemind/src/documentation/content/xdocs/groovy.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- groovy.xml 16 Nov 2004 10:27:12 -0000 1.2
+++ groovy.xml 19 Dec 2004 15:44:33 -0000 1.3
@@ -31,7 +31,8 @@
ways. <link href="http://groovy.codehaus.org/";>Groovy</link>
to the rescue.
</p>
<p>
- In the following we will take a look at how the calculator
example module can be expressed using a
+ In the following we will take a look at how the
+ <link href="bootstrap.html">calculator example module</link> can be
expressed using a
Groovy script. We will also go through the steps required to
get module descriptors defined in
Groovy loaded into the Registry.
</p>
1.6 +52 -90
jakarta-hivemind/src/documentation/content/xdocs/override.xml
Index: override.xml
===================================================================
RCS file:
/home/cvs/jakarta-hivemind/src/documentation/content/xdocs/override.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- override.xml 21 Oct 2004 12:35:56 -0000 1.5
+++ override.xml 19 Dec 2004 15:44:33 -0000 1.6
@@ -37,8 +37,41 @@
<p>HiveMind doesn't have an explicit mechanism for
accomplishing this ...
that's because its reasonable to replace and wrap
existing services just
with the mechanisms already available.</p>
+ <p>
+ In HiveMind 1.0, overriding a service required a "trick", involving
indirection
+ via a HiveMind symbol. This has changed in HiveMind 1.1, which
supports
+ service overrides directly.
+ </p>
+
+ <p>
+ In HiveMind 1.1, the service implementation
+ (the &create-instance; or &invoke-factory;) inside the &service-point;
is considered
+ the <em>default implementation</em>.
+ </p>
+
+ <p>
+ The default implementation may be overriden by contributing an alternate
+ service implementation using the &implementation; element. This may
occur in the same
+ module or in an entirely different module. This new implementation
+ <em>replaces</em> the default implementation.
+ </p>
+
+ <p>
+ It is <em>still</em> an error to provide more than one overriding
implementation.
+ </p>
+
+ <p>
+ If you wish your service to not be overridable, you may simply leave the
+ implementation out of the &service-point; and provide an
&implementation; element
+ of your own. This will prevent any other module from overriding the
service implementation.
+ </p>
+
+ <p>
+ A service must be visible (i.e., not private) to be overriden.
+ </p>
+
<section>
- <title>Step One: A non-overridable service</title>
+ <title>Step One: A service with default
implementation</title>
<p>To describe this technique, we'll start with a
ordinary, every day
service. In fact, for discussion purposes,
there will be two services:
Consumer and Provider. Ultimately, we'll show
how to override Provider.
@@ -47,7 +80,7 @@
<p>To begin, we'll define the two services, and set
Provider as a property
of Consumer:</p>
<source><![CDATA[
-<module id="ex.override" version="1.0.0">
+<module id="ex.default" version="1.0.0">
<service-point id="Provider" interface="ex.override.Provider">
<create-instance class="ex.override.impl.ProviderImpl"/>
</service-point>
@@ -61,97 +94,26 @@
</module>]]> </source>
</section>
<section>
- <title>Step Two: Add some indirection</title>
+ <title>Step Two: Add the override</title>
<p>In this step, we still have just the two services
... Consumer and
Provider, but they are linked together less
explicitly, by using
- substitution symbols.</p>
- <source><![CDATA[
-<module id="ex.override" version="1.0.0">
- <service-point id="Provider" interface="ex.override.Provider">
- <create-instance class="ex.override.impl.ProviderImpl"/>
- </service-point>
-
- <contribution configuration-id="hivemind.FactoryDefaults">
- <default symbol="ex.override.Provider" value="ex.override.Provider"/>
- </contribution>
-
- <service-point id="Consumer" interface="ex.override.Consumer">
- <invoke-factory>
- <construct class="ex.override.impl.Consumer">
- <set-service property="provider"
service-id="${ex.override.Provider}"/>
- </invoke-factory>
- </service-point>
-</module> ]]> </source>
- <p>The indirection is in the form of the symbol
<code>ex.override.Provider</code>,
- which evaluates to the service id
<code>ex.override.Provider</code> and the
- end result is the same as step one. We needed
to use a fully qualified
- service id because, ultimately, we don't know
in which modules the
- symbol will be referenced.</p>
- </section>
- <section>
- <title>Step Three: Override!</title>
- <p>The final step is to define a second service and
slip it into place.
- For kicks, the OverrideProvider service will
get a reference to the
- original Provider service.</p>
- <source><![CDATA[
+ substitution symbols. The other module is not
changed at all, we simply
+ add a new module, containing an &implementation; for the Provider
service:</p>
+ <source><![CDATA[
<module id="ex.override" version="1.0.0">
- <service-point id="Provider" interface="ex.override.Provider">
- <create-instance class="ex.override.impl.ProviderImpl"/>
- </service-point>
-
- <contribution configuration-id="hivemind.FactoryDefaults">
- <default symbol="ex.override.Provider" value="ex.override.Provider"/>
- </contribution>
-
- <service-point id="OverrideProvider" interface="ex.override.Provider">
- <invoke-factory>
- <construct class="ex.override.impl.OverrideProviderImpl">
- <set-service property="defaultProvider" service-id="Provider"/>
- </construct>
- </invoke-factory>
- </service-point>
-
- <!-- ApplicationDefaults overrides FactoryDefaults -->
-
- <contribution id="hivemind.ApplicationDefaults">
- <default symbol="ex.override.Provider"
value="ex.override.OverrideProvider"/>
- </contribution>
-
- <!-- Consumer unchanged from step 2 -->
-
- <service-point id="Consumer" interface="ex.override.Consumer">
- <invoke-factory>
- <construct class="ex.override.impl.Consumer">
- <set-service property="provider"
service-id="${ex.override.Provider}"/>
- </invoke-factory>
- </service-point>
-</module> ]]> </source>
- <p>The new service, OverrideProvider, gets a reference
to the original
- service using its real id. It can't use the
symbol that the Consumer
- service uses, because that would end up
pointing it at itself. Again, in
- this example it's all happening in a single
module, but it could
- absolutely be split up, with OverrideProvider
and the configuration to &hivemind.ApplicationDefaults;
- in an entirely different module.</p>
- <p> &hivemind.ApplicationDefaults; overrides
&hivemind.FactoryDefaults;.
- This means that the Consumer will be connected
to <code>
- ex.override.OverrideProvider</code>.</p>
- <p>Note that the &_service-point; for the Consumer
doesn't change between
- steps two and three.</p>
- </section>
- <section>
- <title>Limitations</title>
- <p>The main limitation to this approach is that you can
only do it once
- for a service; there's no way to add an
EvenMoreOverridenProvider
- service that wraps around OverrideProvider
(that wraps around Provider).
- Making multiple contributions to the
&hivemind.ApplicationDefaults;
- configuration point with the name symbol name
will result in a runtime
- error ... and unpredictable results.</p>
- <p>This could be addressed by adding another source to
the &hivemind.SymbolSources;
- configuration.</p>
- <p>To be honest, if this kind of indirection becomes
extremely frequent,
- then HiveMind should change to accomidate the
pattern, perhaps adding an
- <code><override></code> element, similar
to a &_interceptor;
- element.</p>
+
+ <implementation service-id="ex.default.Provider">
+ <create-instance class="ex.override.impl.OverrideProviderImpl"/>
+ </implementation>
+</module>
+]]> </source>
+
+<p>
+The Consumer service will get the functionality of the Provider service
+from the OverrideProviderImpl (instead of the original ProviderImpl).
ProviderImpl will never
+be instantiated, just OverrideProviderImpl.
+</p>
+
</section>
</body>
</document>
1.17 +4 -0 jakarta-hivemind/framework/build.xml
Index: build.xml
===================================================================
RCS file: /home/cvs/jakarta-hivemind/framework/build.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- build.xml 5 Dec 2004 16:43:19 -0000 1.16
+++ build.xml 19 Dec 2004 15:44:33 -0000 1.17
@@ -46,6 +46,9 @@
<junit-elements>
<!-- Adjust for wrong current directory when
framework/build.xml invoked from the project. -->
<sysproperty key="FRAMEWORK_ROOT"
value="${basedir}/"/>
+
+ <!-- Needed for
org.apache.hivemind.conditional.TestEvaluationContext -->
+ <sysproperty key="property-set-for-evaluation-context"
value="true"/>
</junit-elements>
</default-run-tests>
</target>
@@ -56,6 +59,7 @@
<default-clover>
<clover-junit-elements>
<sysproperty key="FRAMEWORK_ROOT"
value="${basedir}/"/>
+ <sysproperty key="property-set-for-evaluation-context"
value="true"/>
</clover-junit-elements>
</default-clover>
<generate-clover-html/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
