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 Wed, 23 Jun 2004 04:23:10 GMT
   Date: 2004-06-22T21:23:10
   Editor: 168.226.254.131 <>
   Wiki: Jakarta HiveMind Wiki
   Page: FrequentlyAskedQuestions
   URL: http://wiki.apache.org/jakarta-hivemind/FrequentlyAskedQuestions

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -64,8 +64,12 @@
 
 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.
+DanielFeist: Yes that's a good workable solution the downside it that its not 100% IOC i.e.
the !DataSource is not being injected but rather work has to be done in the services init
method to obtian the datasource.  In !HiveMinds current state that is the best solution I
suppose.  I do believe though that the ability to be able to inject other objects that are
not services or configurations (obtained from a lookup/factory service) is an important functionality
that should certainly be considered as not everything we might want to use and inject can
or should de represented as a service.
 
-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 which would reduce service portability.
+DanielFeist:  I've just been looking at the BeanFactory and translator and it would seem
that you have actually started implementation of something that allows the us to obtain objects
from a factory.  The PiplineFactoryService, for example uses, in its configuration contributions,
beans obtained from the BeanFactory.  This is a good and works well for the needs of the PipelineFactoryService
configuration but it would be far far more flexible to be able to obtain an object from any
factory and not just from a BeanFactory.
 
-DanielFeist:  I've just been looking at the BeanTranslator which obtains an object from a
BeanFactory using a locator.  This would allow the injection of services with beans obtained
from the BeanFactory by the simple addition of a {{{set-bean}}} nested element to the BuilderFactory
schema.  Why can't we extend the BeanTranslator idea, so as to be able to obtain an object
from any factory and not just the BeanFactory, using the same idea of a single argument locator?
 In this way it would be very easy to obtain objects from any factory very simply, anywhere
in !HiveMind, be it in configurations or in a BuilderFactory nested element.  This is no more
complex than what is already implemented in  !HiveMind and gives another level of flexibility
to what you can do with !HiveMind.
+What i would suggest is the following:
+
+1) That we try to work out a simple way of doing the same sort of thing but allowing the
use of arbitary user implemented factories (not neccessarly implementing BeanFactory).  Maybe
it would be possible to extend the !ObjectTranslator so that it optionally returns an object
obtained from a factory or maybe a seperate translator would be best?  I personally would
probably choose to rename and extend the bean translator to accomplish the additional functionality.
 (Only making changes to the translator while leaving the rest of the new BeanFactory code
as it is.)
+
+2) If this can be achieved without over complicating things we could then add to the BuilderFactory
schema the element neccessary to be able to inject these objects.

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