Achim,
On 8/6/06, Achim Hügen <[EMAIL PROTECTED]> wrote:
Good points, and fortunately they almost coincide with the things
I extracted from the core framework ;-)
For the moment I moved translators and object providers
to the xml module, at least it keeps the core small.
The symbol sources are deeply linked with the core (Registry
extends SymbolSource) so I left them in for now.
I have mixed feelings about Service and interceptor factories.
(which is proven by the fact, that one is in and one outside of the core).
For example LoggingInterceptorFactory is doing a lot of proxy creation
logic
which is independent of xml. But we need another interface to trigger
this proxy creation. The xml module would then provide an
XmlLoggingInterceptorFactory
that implements the legacy ServiceInterceptorFactory interface,
reads a configuration from xml and delegate the work to
LoggingInterceptorFactory.
Maybe LoggingInterceptorFactory should be LoggingInterceptorConstructor and
simply implement the InterceptorConstructor interface?
I was thinking that the InterceptorConstructor interface should be
enough. The implementation of this interface for the XML support would
deal with the schema processing and then pass the converted parameters
on to a common POJO (or HiveMind service) like
LoggingInterceptorFactory. The InterceptorConstructor#construct()
method would be passed an object with which it can lookup HiveMind
services (e.g. the LoggingInterceptorFactory) to fulfill its
responsibility. Same for the service implementation factories.
I had some more ideas for the API:
- The ExtensionDef interface (or its subclasses if we decide not to
include it in the API) could instead of having a extensionPointId :
String attribute declare a extensionPointPattern : String attribute
which is a glob or regex pattern. This would allow us to match up one
extension with multiple extension points. This would probably mostly
be used for interceptors but maybe also for service implementations.
This would effectively render the InterceptorConstructor to the new
ServiceInterceptorFactory.
- I am not sure whether to consider the default / override
implementation mechanism as XMLyness or core feature. To support this
the ImplementationDef interface could declare a method isDefault() :
boolean. An more flexible but not quite as clear alternative would be
to declare something like a getPriority() : int method.
Some status on what I achieved so far in the experimental branch:
I implemented a first version of the registry api and separated all
xml specific code from the core framework.
The unit tests of the framework are working again (99%) but some of
them are still using xml to define the test data. I'm trying to port
them to the plain java api the next days. It's a good exercise to get
a feeling for api deficiencies.
The xml module is fully implemented but must be tested then.
After this I'll go back to the registry construction api and will
try to work in Knuts ideas and do some refactorings.
Excellent! Will the code in your branch be HiveMind 1.1 backwards compatible?
--knut
