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
