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=AttachFile&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
