hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Jakarta HiveMind Wiki] Updated: ConditionalContributionsProposal
Date Fri, 30 Apr 2004 22:03:00 GMT
   Date: 2004-04-30T15:03:00
   Editor: <>
   Wiki: Jakarta HiveMind Wiki
   Page: ConditionalContributionsProposal

   no comment

Change Log:

@@ -100,3 +100,8 @@
 I was thinking more like '"${interface.module.!ServiceName}" == "implementation.module.!ImplementationName"'.
 Then you just arrange your symbol sources to look in standard places for these definitions,
and you have maximum configurability.
+I think the solution is insufficient and cluttered: To a module a service defined by the
module is either a service with module provided implementation(s) or a service demanded by
the module (implementation is provided by another module). This combined with overriding/default-impl
gives four (abstract) types of services: A provided service implementations(s) may either
be overwriten (Type I) or final (Type II), a demanded service may either have a default implemantation(s)
(Type III) or none (Type IV). Type I and Type III are actually the same, both provide different
default implementations which can be overwritten. Current Hivemind (without this proposal)
supports only Type II and IV with one implementation. The current proposal also supports a
Type I and Type III but with the restriction to have only one default implementation. Ie it
would be impossible to provide your own regex-impl if the regex-module already defines for
JDK1.4 and JDK1.3 and you use JDK1.4. 
+A little change could solve that: The implementation tag should be used for overriding only
and should be unconditional. The service however should be allowed to provide differend conditional
implementations which are only taken if there is no implementation. (So implementation are
allowed even when the service-definiton provides an implementation). If TYPE II (final) is
seen as important - I don't think so - also an extra attribute should be added to the service
tag. (An alternative - of course my favorite - would be to replace the invoke-factory with
a script :-))       

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message