hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Wannheden" <knut.wannhe...@gmail.com>
Subject comments / questions on hivemind 2.0 branch
Date Thu, 02 Nov 2006 09:18:43 GMT
Achim,

Browsing the code in your HiveMind 2.0 experimental branch I jotted
down the following comments / questions:

- The split of the framework and xml sources into separate modules
looks excellent! It makes the framework quite a bit leaner. I found a
few sources which I think maybe ended up in the wrong place (see
following comments).

- The ObjectProvider interface is in the XML source module. I believe
this should be part of the framework. We might for example also want
to use that in the annotation support to inject objects into
parameters of methods creating service implementations.

- On the other hand I wonder if instead the SymbolSource classes along
with the symbol expansion code should be moved into the XML module.
They are used to resolve Ant style ${}-properties in the XML
descriptors. Do we want to support these in other module descriptors
(e.g. annotation based Java classes) also?

- I noticed the ServiceImplementationFactory is in the xml module.
Maybe we could also move the ServiceInterceptorFactory to the xml
module. Although I think some of its implementations (really only the
LoggingInterceptorFactory) should remain in the framework module which
would mean it can't implement the interface anymore. But IMHO that's
OK, because the first thing that's done in the implemented interface
method is to cast the Object parameter to a List. That could be done
by an adapter implementation in the xml module.

- Now some comments on the registry construction API. I believe an
interface based registry construction API would allow for more
flexibility in the implementations. For example you'd have to
possibility of refactoring the existing *Descriptor classes in the XML
module to implement these interfaces instead of define a mapping. As
another example an implementation could chose to have a single object
implement two interfaces (e.g. ServicePointDef and ImplementationDef).
Further we could then also remove OrderedServiceInterceptorDefinition
and simply note that an implementation class can implement the
Orderable interface if ordering is required.

- Also I think the API could be simplified by removing the distinction
between resolved and unresolved extensions. That would make the
registry builder responsible for all resolutions.

- What do you think about removing the natures from the API? Currently
it seems like they're used in the XML implementation to get a
reference to schemas. Maybe the code in the XML module could also just
typecast to the required implementation and get a reference to the
schema that way. IMHO the natures are overcomplicating the API.

Regards,

--knut

Mime
View raw message