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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
