Knut,
some general remarks:
1. Associations:
I'm missing the associations between related items. For example
between a service point and its implementation(s) or a configuration
and its contributions. I'd distinguish between directly resolvable
extension (inside the same module) and "unresolvable" extensions that
contribute to external modules.
For resolvable extensions I regard it as more intuitive and OO to
offer an api that represents the module as object graph:
ModuleDef module = new ModuleDefImpl("module1");
ServicePointDef sp = new ServicePointDefImpl("Service1", module);
module.addServicePoint(sp);
sp.addImplementation(..));
sp.addInterceptor(...)
vs.
ModuleDef module = new ModuleDefImpl("Module1");
module.addServicePoint(new ServicePointDefImpl("Service1", module));
module.addImplementation(new ImplementationDefImpl("Module1.Service1", ..
));
module.addInterceptor(new InterceptorDefImpl("Module1.Service1", ... ));
By the way, what about the 'add' methods, shouldn't they be included in
the interfaces?
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.
IMO it's very important for java based and annotation based modules, that
we get rid of the 'configuration is always a list or map' limitation.
Hence I defined a ConfigurationConstructor that constructs the container
element (today it's a list):
public interface ConfigurationConstructor extends Locatable
{
public Object constructConfigurationContainer(Module module);
}
and the ContributionsConstructor gets the container handed in and
can add items, set properties or whatever he want's to do with it:
public interface ContributionConstructor
{
public void contribute(ConfigurationPoint configurationPoint, Object
container);
}
- 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
XmlImplementationDef gave me an important inspiration. I now see a way
how to get rid of methods in my constructor classes that were bugging
me. I could even get rid of the 'nature' api I implemented.
Achim
