You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Knut Wannheden <kn...@gmail.com> on 2006/08/04 11:43:00 UTC
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=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
Re: registry construction api
Posted by Knut Wannheden <kn...@gmail.com>.
Hi Achim,
Thanks for the feedback. Some comments:
On 8/6/06, Achim Hügen <ac...@gmx.de> wrote:
>
> 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?
>
Yes and no. I feel that the API, i.e. the *Def interfaces, should only
represent the requirements from HiveMind's point of view and not
contain methods that the implementation (e.g. Java or Java annotations
based support) will need. This should however not prevent the
implementation from defining such methods. I.e. your example for what
the Java based support implementation could look like should still be
simple to implement in terms of the proposed API.
> > - 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);
> }
>
That looks interesting. That would of course mean that a configuration
is always just available as one type of "container". But that seems
like a reasonable restriction and a backward incompatibility we could
justify.
I just wonder if this has any implications for the proxying and
autowiring. Should the ConfigurationPointDef maybe, just like the
ServicePointDef with getServiceInterfaceName(), expose the container
type with a getContainerInterfaceName() method. This would probably be
required for HiveMind to be able to create a proxy for the
configuration. We can also take a peek at Tapestry IoC's approach
(currently limited to unordered, ordered, and mapped configurations)
for ideas: http://svn.apache.org/viewvc/tapestry/tapestry5/tapestry-core/trunk/src/main/java/org/apache/tapestry/ioc/def/ContributionDef.java?view=markup.
--knut
Re: registry construction api
Posted by Achim Hügen <ac...@gmx.de>.
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
Re: registry construction api
Posted by Knut Wannheden <kn...@gmail.com>.
In the list of XMLynesses I forgot to mention conditional
contributions. But I believe an isApplicable() (or isEnabled()) method
in the ExtensionDef subclasses is an adequate hook allowing to
implement this feature in the XML implementation of the API.
Cheers,
--knut
On 8/4/06, Knut Wannheden <kn...@gmail.com> wrote:
> 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 <ja...@carmanconsulting.com> 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:knut.wannheden@gmail.com]
> > 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
> >
> >
> >
>
Re: registry construction api
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
On 8/6/06, Achim Hügen <ac...@gmx.de> wrote:
> 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?
>
I was thinking that the InterceptorConstructor interface should be
enough. The implementation of this interface for the XML support would
deal with the schema processing and then pass the converted parameters
on to a common POJO (or HiveMind service) like
LoggingInterceptorFactory. The InterceptorConstructor#construct()
method would be passed an object with which it can lookup HiveMind
services (e.g. the LoggingInterceptorFactory) to fulfill its
responsibility. Same for the service implementation factories.
I had some more ideas for the API:
- The ExtensionDef interface (or its subclasses if we decide not to
include it in the API) could instead of having a extensionPointId :
String attribute declare a extensionPointPattern : String attribute
which is a glob or regex pattern. This would allow us to match up one
extension with multiple extension points. This would probably mostly
be used for interceptors but maybe also for service implementations.
This would effectively render the InterceptorConstructor to the new
ServiceInterceptorFactory.
- I am not sure whether to consider the default / override
implementation mechanism as XMLyness or core feature. To support this
the ImplementationDef interface could declare a method isDefault() :
boolean. An more flexible but not quite as clear alternative would be
to declare something like a getPriority() : int method.
>
> 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.
>
Excellent! Will the code in your branch be HiveMind 1.1 backwards compatible?
--knut
Re: registry construction api
Posted by Achim Hügen <ac...@gmx.de>.
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
<kn...@gmail.com>:
> 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 <ja...@carmanconsulting.com> 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:knut.wannheden@gmail.com]
>> 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
>>
>>
>>
>
Re: registry construction api
Posted by Knut Wannheden <kn...@gmail.com>.
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 <ja...@carmanconsulting.com> 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:knut.wannheden@gmail.com]
> 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
>
>
>
RE: registry construction api
Posted by James Carman <ja...@carmanconsulting.com>.
Whoah! I just had another idea. If we make this API extensible enough, we
might be able to write an adapter that makes a Spring ApplicationContext
look like a HiveMind module that can be added to the registry! That would
be pretty cool! Just a thought.
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Friday, August 04, 2006 8:24 AM
To: dev@hivemind.apache.org
Subject: RE: registry construction api
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:knut.wannheden@gmail.com]
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
RE: registry construction api
Posted by James Carman <ja...@carmanconsulting.com>.
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:knut.wannheden@gmail.com]
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