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?
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.
Achim
Am Fri, 04 Aug 2006 16:00:03 +0200 schrieb Knut Wannheden
<[EMAIL PROTECTED]>:
James,
I definitely agree with your points on making it simple to implement
other registry definition mechanisms on top of the API and removing
any XMLyness from it.
I am not quite clear on what you mean by building a registry "by
hand". I assume you mean writing simple Java code (i.e. *not* writing
code implementing the API I propose). To support this we would only
have to write some classes in HiveMind implementing the proposed API
interfaces. The following (just an example) could for instance define
a module with an autowired singleton service "foo" (interface Foo and
implementation class FooImpl):
ModuleDef m = new SimpleModule("my");
m.addService(new SimpleService("foo", Foo.class, FooImpl.class));
The Simple* classes would be provided by HiveMind to construct a
registry "by hand". SimpleService would for instance both implement
ServicePointDef *and* ImplementationDef. But there are of course
uncountable other possibilities what exactly these Simple* classes
would look like. Achim has done some work on this in his experimental
branch.
To expand on your list of what is "core", or rather what isn't, here
is a few things which I consider XMLyness and are thus not part of the
proposed API:
- Shorthand notations. This may seem obvious but I'd still like to
point it out. In the current *Descriptor classes used by the XML
parser all the various shorthand notations (e.g. <invoke-factory>
allowed inside <service-point>) are reflected in the API. These
shorthands should IMHO not be in the new API.
- I have the feeling the "package" attribute on <module> is also a
shorthand we don't want in the API. But I haven't given this much
thought yet.
- Schema processing for mapping XML to POJOs. This feature is
currently used to create a configuration's contribution elements, core
service implementation objects, and interceptors. In all these cases
the schema is defined by some extension point. Also note that the
schema processing includes ${} symbol resolution, translator
translation, and thus also object providers.
- Service and interceptor factories. I think even these factories are
really part of the XMLyness. I can for instance not see any use of
this in modules defined using annotations (as e.g. in Tapestry 5 IoC).
This should really be transparent and encapsulated by the *Constructor
objects. Thus factories are represented as normal services (which a
*Constructor object can use).
- Sub modules. I believe sub modules is also XMLyness. They are in
fact already entirely handled by the XmlModuleDescriptorProvider.
On the topic of symbol sources, translators, and object providers it
is IMO only their *usage* in the schema processing which should be
considered XMLyness. They are implemented as normal configurations and
services and I think they might come in handy in other situations
also.
--knut
On 8/4/06, James Carman <[EMAIL PROTECTED]> wrote:
Thank you for all of your hard work on this! I won't really have time
to
review it this weekend as I will be attending NFJS in Cincinnati. I
briefly
perused the API, though. It looks like we're on the right track. We
should
make sure the API makes it very easy to build a registry "by hand."
That
way, we can build any shortcut mechanism (XML, annotations, convention
over
configuration, etc.) on top of it. If we do it right, it should be
*very*
easy for a user to come up with their own custom scheme for building a
registry to suit their needs (like Tapestry 5, for example :-). I would
really like to make HiveMind extensible enough that we don't have folks
thinking that the XML syntax that we've chosen is too restrictive. If
they
want something different, they can easily build their own! :-)
We should probably come up with a list of the features that are "core"
and
not part of the XMLyness (a new word in case you're counting) of the
current
design. Stuff like schemas and the like are really not part of the
"core"
of HiveMind and should be part of the XML builder extension. I would
think
that symbols would fall in the same category.
These comments aren't really aimed at the code you've come up with,
Knut.
They're just my musings while I drink my morning coffee here. Again,
thanks
for working on this. I've been way too busy lately to lay down any code
towards this. You da man!
Okay, I'm going to get out of here to go listen to Stuar Halloway's
"Spring
Fundamentals" talk. Know Thy Enemy!
James
-----Original Message-----
From: Knut Wannheden [mailto:[EMAIL PROTECTED]
Sent: Friday, August 04, 2006 5:43 AM
To: HiveMind Dev List
Subject: registry construction api
Hi all,
I've once again put some effort into working out an API for the
registry construction. I started out with what I've previously
documented under
http://wiki.apache.org/jakarta-hivemind/DescriptorApiRevampProposal.
Here's a diagram for you to look at:
http://wiki.apache.org/jakarta-hivemind/DescriptorApiRevampProposal?action=A
ttachFile&do=view&target=module-def.gif.
Some things worth noting:
- The abstract interfaces ExtensionPointDef, ExtensionDef, and
ExtensionConstructor on the diagram will probably not be part of the
API. I thought they made the ideas on the diagram clearer.
- Note the plural form in ContributionsDef. This signifies that a
ContributionsDef can contribute multiple elements to a configuration
point. I don't know what methods ContributionsConstructor should
declare.
- An InterceptorDef only represents one interceptor. By making
ExtensionDef::extensionPointId a list of IDs we should be able to
model an InterceptorDef applying to multiple services.
- The method ExtensionDef::isApplicable() is a guard around
ExtensionDef::getConstructor() and will be used in the XML
implementation to implement the conditional contribution logic.
- ImplementationDef and InterceptorDef objects don't declare a
reference to a service factory in the API. I considered this a feature
specific to the XML descriptors and must thus be handled in the
implementing classes. For example:
public class XmlImplementationDef implements ImplementationDef
{
private String _factoryServiceId;
private List _parameters;
public ImplementationConstructor getConstructor(DefContext context)
{
ServicePointDef factory =
context.getServicePointDef(_factoryServiceId);
Schema schema = ((XmlServicePointDef) factory).getSchema();
return new XmlFactoryInvocationConstructor(_factoryServiceId,
schema, _parameters);
}
}
- The XML schema processing for the ContributionsDef would work in a
similar fashion.
Let me know what you think.
--knut
