Knut, 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
