Date: 2004-04-14T15:02:41
Editor: LukeBlanshard <[EMAIL PROTECTED]>
Wiki: Jakarta HiveMind Wiki
Page: ConditionalContributionsProposal
URL: http://wiki.apache.org/jakarta-hivemind/ConditionalContributionsProposal
no comment
Change Log:
------------------------------------------------------------------------------
@@ -2,7 +2,7 @@
This document reflects the state of !HiveMind on April 14 2004, with the code
between 1.0-alpha-3 and 1.0-alpha-4.
-!HiveMind has a powerful and somewhat ingeneous approach to defining services
that, notably, seperates a service's ''interface'' from it's
''implementation''. It's completely possible for one module to define a
<service-point> and for an entirely different module to provide the
implementation using a <implementation>. This decoupling of interface from
implementation is very powerful; it helps make dependencies between modules
more manageable, but more importantly, it allows you to ''plug in'' different
implementations simply by controlling which modules (that is, which JARs) are
on the classpath.
+!HiveMind has a powerful and somewhat ingenious approach to defining services
that, notably, separates a service's ''interface'' from it's
''implementation''. It's completely possible for one module to define a
<service-point> and for an entirely different module to provide the
implementation using a <implementation>. This decoupling of interface from
implementation is very powerful; it helps make dependencies between modules
more manageable, but more importantly, it allows you to ''plug in'' different
implementations simply by controlling which modules (that is, which JARs) are
on the classpath.
The latter opens up some interesting possibilities with regards to testing. By
controlling the classpath during testing, you can have a module provide a
for-testing-purposes implementation of a service. For example, an
implementation of a service that only "pretended" to interact with some kind of
back end system. In this way, you can more easily test the behavior of the
other services that make use of the service.
@@ -21,7 +21,7 @@
= Proposed Solution =
-Change the <implementation> element to add a new {{{if}}} attribute. The
value for the attribute is an expression in a specially concieved expression
language.
+Change the <implementation> element to add a new {{{if}}} attribute. The
value for the attribute is an expression in a specially conceived expression
language.
This expression is evaluated as the registry is constructed (note: to be
determined whether during specification parse or during registry construction).
@@ -33,7 +33,7 @@
== Default Implementation ==
When no expression is provided in an <implementation>, then the
<implementation> is considered the ''default'' implementation; used only when
no more selective
-implementation (that is, an <implemenatation> with an {{{if}}} attribute) has
already filled the slot.
+implementation (that is, an <implementation> with an {{{if}}} attribute) has
already filled the slot.
== Expression Language ==
@@ -70,7 +70,7 @@
=== jdk function ===
-Evaluates its argument as a JDK version number (a dotted sequence number) and
evaulates it against the runtime environment. Returns true if the actual JDK
is the same as, or a subsequent release to, the provided JDK version number.
For example, {{{jdk(1.4)}}} would match against releases 1.4.1, 1.4.1_01,
1.4.2, 1.5, 1.5.1, etc.
+Evaluates its argument as a JDK version number (a dotted sequence number) and
evaluates it against the runtime environment. Returns true if the actual JDK
is the same as, or a subsequent release to, the provided JDK version number.
For example, {{{jdk(1.4)}}} would match against releases 1.4.1, 1.4.1_01,
1.4.2, 1.5, 1.5.1, etc.
=== property function ===
@@ -88,6 +88,6 @@
LukeBlanshard, 14 April 2004:
-- Do you really need the property function? Can''t you just use the ${symbol}
notation?
+ * Do you really need the property function? Can't you just use the ${symbol}
notation?
-- Answering the "when this should be evaluated" issue: it obviously can''t
happen at parse time, because people will need to be able to use the ${symbol}
notation within expressions.
+ * Answering the "when this should be evaluated" issue: it obviously can't
happen at parse time, because people will need to be able to use the ${symbol}
notation within expressions.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
