hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hivemind-...@jakarta.apache.org
Subject [Jakarta HiveMind Wiki] Updated: FrequentlyAskedQuestions
Date Tue, 22 Jun 2004 17:43:43 GMT
   Date: 2004-06-22T10:43:43
   Editor: 200.69.248.193 <>
   Wiki: Jakarta HiveMind Wiki
   Page: FrequentlyAskedQuestions
   URL: http://wiki.apache.org/jakarta-hivemind/FrequentlyAskedQuestions

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -63,3 +63,7 @@
 DanielFeist: What then, in terms of !HiveMind 1.0 (assuming no OGNL) is the solution to the
simple problem put forward in the two initial examples?  Implement and define in sdl my own
!CustomBuilderFactory (the implementation of builder factory would be identical but with a
slightly more complex schema)?  There's no simpler solution?  I think considering OGNL or
something similar to make builder paramenters simpler and more flexible for the next version
is a good move.
 
 HowardLewisShip: A completely reasonable and testable solution is to assign the service (i.e.
{{{hivemind.lib.NameLookup}}} to a property of your service, and use the {{{initialize-method}}}
attribute to have your service initialize.  In Java code, you can access the methods of the
collaborating services.
+
+DanielFeist: Yes that's a good workable solution the only downside it has is that its not
100% IOC i.e. the !DataSource itself cannot be injected but rather work has to be done in
the services constructor or init method to obtian the datasource.  In !HiveMinds current state
that is the best solution rather than over complicating the BuilderFactory I suppose.
+
+I do believe though that the ability to be able to inject other entities (that are not services,
configurations or resources) obtained from another lookup/factory service is an important
functionality that should certainly be considered in future versions.  This is because not
everthing can or should de represented as a service (e.g. if it does not implement an interface),
and although !HiveMind ''Resource's'' are good at what they do they are limited to file-based
resources and introduce a dependency on !HiveMind in an up to this point POJO service that
is not dependent on !HiveMind.

---------------------------------------------------------------------
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