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/11/02 10:18:43 UTC
comments / questions on hivemind 2.0 branch
Achim,
Browsing the code in your HiveMind 2.0 experimental branch I jotted
down the following comments / questions:
- The split of the framework and xml sources into separate modules
looks excellent! It makes the framework quite a bit leaner. I found a
few sources which I think maybe ended up in the wrong place (see
following comments).
- The ObjectProvider interface is in the XML source module. I believe
this should be part of the framework. We might for example also want
to use that in the annotation support to inject objects into
parameters of methods creating service implementations.
- On the other hand I wonder if instead the SymbolSource classes along
with the symbol expansion code should be moved into the XML module.
They are used to resolve Ant style ${}-properties in the XML
descriptors. Do we want to support these in other module descriptors
(e.g. annotation based Java classes) also?
- I noticed the ServiceImplementationFactory is in the xml module.
Maybe we could also move the ServiceInterceptorFactory to the xml
module. Although I think some of its implementations (really only the
LoggingInterceptorFactory) should remain in the framework module which
would mean it can't implement the interface anymore. But IMHO that's
OK, because the first thing that's done in the implemented interface
method is to cast the Object parameter to a List. That could be done
by an adapter implementation in the xml module.
- Now some comments on the registry construction API. I believe an
interface based registry construction API would allow for more
flexibility in the implementations. For example you'd have to
possibility of refactoring the existing *Descriptor classes in the XML
module to implement these interfaces instead of define a mapping. As
another example an implementation could chose to have a single object
implement two interfaces (e.g. ServicePointDef and ImplementationDef).
Further we could then also remove OrderedServiceInterceptorDefinition
and simply note that an implementation class can implement the
Orderable interface if ordering is required.
- Also I think the API could be simplified by removing the distinction
between resolved and unresolved extensions. That would make the
registry builder responsible for all resolutions.
- What do you think about removing the natures from the API? Currently
it seems like they're used in the XML implementation to get a
reference to schemas. Maybe the code in the XML module could also just
typecast to the required implementation and get a reference to the
schema that way. IMHO the natures are overcomplicating the API.
Regards,
--knut
Re: comments / questions on hivemind 2.0 branch
Posted by James Carman <ja...@carmanconsulting.com>.
I'm going to have to think about that a bit. I only glanced at the
new stuff for about a half hour this morning so far. I plan to do a
deeper dive, though. Here's an interesting question though. How
about allowing service points to have more than one service interface?
On 11/7/06, Achim Hügen <ac...@gmx.de> wrote:
> James Carman schrieb:
> > I started looking through the new API today and so far it looks pretty
> > cool. One thing I don't like, though, is having the ClassResolver
> > stuff inside the definition classes. Is that absolutely necessary? I
> > was kind of hoping that we could use something like commons proxy to
> > do all of the proxying logic and get ourselves out of the Javassist
> > business if we can.
> The ModuleImpl needs a class provider for the resolveType method.
> It is provided by the ModuleDefinition.
> I think this has the same justification as the ClassResolver mechanism
> itself.
> Do you see another way?
>
> Achim
>
>
Re: comments / questions on hivemind 2.0 branch
Posted by James Carman <ja...@carmanconsulting.com>.
As long as its kind of hidden behind the scenes, I guess it's not that
bad. But, too much "magic" can tend to freak some folks out.
However, whenever I present HM to folks and I'm able to make the light
bulb come on, they are usually very impressed with all of the magic
that goes on behind the scenes.
On 11/7/06, Knut Wannheden <kn...@gmail.com> wrote:
> There is one alternative I can think of. The SchemaRegistry service
> could provided a hardcoded (using Java code) Schema for the "Schemas"
> extension point. Then any <contribution> to the "Schemas"
> configuration could be handled the same way as any other
> <contribution>. But of course the contribution would then have to go
> through the SchemaProcessor to create the Schema...
>
> I think all the magic in the XML implementation of the API actually
> warrants some complexity in its implementation. And I think we should
> try hard to keep as much of this complexity out of the framework. Thus
> I don't think either of these approaches would be that bad.
>
> --knut
>
> On 11/7/06, Achim Hügen <ac...@gmx.de> wrote:
> > It think it can be done this way.
> > But now that you pointed out the consequences I'm no
> > longer sure that this doesn't get too complex.
> >
> > Achim
> >
> >
> > Am Tue, 07 Nov 2006 06:20:30 +0100 schrieb Knut Wannheden
> > <kn...@gmail.com>:
> >
> > > James,
> > >
> > > Good point. I hadn't thought too hard about that but I think it should
> > > be possible to bootstrap that. What we'd have to do is to:
> > >
> > > - Define the SchemaRegistry service using the Java or Java annotations
> > > implementation of the API (as opposed to the XML implementation).
> > > - Modify the existing XML DescriptorParser to handle <contribution>
> > > elements to the "Schema" configuration the same way it handles
> > > <schema> elements, which is to create the corresponding SchemaImpl
> > > object and create a ContributionDef object for it. This
> > > ContributionDef object would although use a ContributionConstructor
> > > from the Java implementation of the API.
> > >
> > > This way the "Schema" configuration would not have a schema itself and
> > > contributions to it would thus not require the "SchemaRegistry"
> > > service in the ContributionConstructor. Also the "SchemaRegistry"
> > > service can be setup without any schema processing if it's defined
> > > using a Java or Java annotations module.
> > >
> > > Does this make sense?
> > >
> > > --knut
> > >
> > > On 11/6/06, James Carman <ja...@carmanconsulting.com> wrote:
> > >> Aren't you getting into a chicken/egg scenario here? You need to
> > >> parse the XML to set up the services, but you need the services to
> > >> parse the XML. Sorry if I'm just jumping in the middle here with no
> > >> context (I haven't been able to check out the new API yet,
> > >> unfortunately), but this just sounded weird.
> > >>
> > >> On 11/6/06, Knut Wannheden <kn...@gmail.com> wrote:
> > >> > Achim,
> > >> >
> > >> > I think I see what you're getting at. We could solve the whole problem
> > >> > by defining the whole schema and parsing functionality in terms of
> > >> > HiveMind services and configurations.
> > >> >
> > >> > The XML module could thus define a hivemind.xml.Schemas configuration
> > >> > to which configuration and service points can contribute schemas.
> > >> > Either implicitly by a <schema> element or explicitly with a normal
> > >> > <contribution> element. I suppose a second configuration (e.g.
> > >> > hivemind.xml.ExtensionSchemas) would be needed to define the linking
> > >> > of a schema to specific configuration or service points. Again, the
> > >> > contributions to this would be explicit or implicit.
> > >> >
> > >> > Now a contribution constructor could access a
> > >> > hivemind.xml.SchemaManager service (having the aforementioned
> > >> > configurations injected) to retrieve the schema and / or parser (or
> > >> > also a "pairing") for its configuration point.
> > >> >
> > >> > Does this correspond to what you were thinking?
> > >> >
> > >> > --knut
> > >> >
> > >> > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > >> > > Knut,
> > >> > >
> > >> > > you are right, SchemaProcessor should be a service
> > >> > > and I would even make Schemas available via a SchemaManager
> > >> > > service too.
> > >> > > To make the parser based contribution possible as defined
> > >> > > in the contributeToFactoryConfig method in the example
> > >> > > (http://annocon.sourceforge.net/manual/configurations.html)
> > >> > > we need a connection between configuration point, parser
> > >> > > and schema. Otherwise the contributor would always
> > >> > > have to specify which parser to use and I want to have a default.
> > >> > >
> > >> > > Achim
> > >> > >
> > >> > >
> > >> > > Knut Wannheden schrieb:
> > >> > > > Achim,
> > >> > > >
> > >> > > > Instead of adding a new construct I think it would be cleaner to
> > >> > > > expose the parsers as normal services. The contribution
> > >> constructor
> > >> > > > would then be given access to the appropriate parser (or any other
> > >> > > > visible service) using the contextual construction parameter. I
> > >> > > > believe this would already work in your branch.
> > >> > > >
> > >> > > > So in the XML HiveMind module we'd expose the SchemaProcessor as a
> > >> > > > service which could be used by contribution constructors.
> > >> > > >
> > >> > > > This also turns out to be how it's solved in Tapestry 5. See 3rd
> > >> > > > example here:
> > >> > > > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
> > >> > > >
> > >> > > > What do you say?
> > >> > > >
> > >> > > > --knut
> > >> > > >
> > >> > > > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > >> > > >> Knut Wannheden schrieb:
> > >> > > >> >
> > >> > > >> > Maybe we could also drop the support for contributing to these
> > >> > > >> > configurations using XML. OK, I know this contradicts what I
> > >> wrote
> > >> > > >> > about backwards compatibility in the other thread, but maybe
> > >> that
> > >> > > >> > would be OK. I'd like to point out that Howard changed how the
> > >> eager
> > >> > > >> > loading works in Tapestry 5 IOC. The ServicePointDef simply
> > >> has a
> > >> > > >> > boolean getEagerLoad() method. How about that?
> > >> > > >> >
> > >> > > >> I think I've found a better solution (borrowed from
> > >> > > >> http://annocon.sourceforge.net/manual/configurations.html)
> > >> > > >> I will introduce a generic parser interface which is defined in
> > >> the
> > >> > > >> framework
> > >> > > >> already and which is not xml specific. A configuration can have
> > >> multiple
> > >> > > >> registered parsers.
> > >> > > >> A parser is responsible for the contribution of data to a
> > >> configuration
> > >> > > >> which is defined in a textual format (especially file based
> > >> data).
> > >> > > >> The SchemaProcessor then is one special parser which can process
> > >> > > >> inline data from a hivemodule.xml.
> > >> > > >>
> > >> > > >> The idea is that the creator of a configuration point says 'ok,
> > >> here is
> > >> > > >> a parser
> > >> > > >> which can read contributions from files' and the provider of a
> > >> > > >> contribution
> > >> > > >> just says 'ok, then parse that file please'.
> > >> > > >>
> > >> > > >> Pros:
> > >> > > >> + It solves our 'interface or no interface' dilemma. Since the
> > >> parser
> > >> > > >> concept
> > >> > > >> is available in the framework the hivemodule parser can be
> > >> easily
> > >> > > >> attached by the xml module afterwards.
> > >> > > >> + Configuration data can be defined in external files (xml,
> > >> > > >> properties etc.)
> > >> > > >> Either the hivemind parsing is extended so that xml files can be
> > >> parsed
> > >> > > >> that adhere to a hivemind schema or alternative parsers (e.g.
> > >> Digester)
> > >> > > >> are used.
> > >> > > >> + Better integration of legacy data files
> > >> > > >> + Annotated modules can provide parsers easily (see annocon
> > >> examples).
> > >> > > >>
> > >> > > >> What do you think?
> > >> > > >>
> > >> > > >> Achim
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> >
> >
> >
>
Re: comments / questions on hivemind 2.0 branch
Posted by James Carman <ja...@carmanconsulting.com>.
We should also try to introduce the concept of a thread-local
"invocation context", so that we don't have to have that whole
interceptor stack stuff anymore. The invocation context would give
you stuff like the outer proxy of the current invocation, the service
id, etc. so that interceptors could refer to that when doing their
work (like LoggingInterceptor). The outer proxy would have to be
responsible for setting up the context. Also, the context would have
to be a stack, now wouldn't it?
On 11/7/06, James Carman <ja...@carmanconsulting.com> wrote:
> I started looking through the new API today and so far it looks pretty
> cool. One thing I don't like, though, is having the ClassResolver
> stuff inside the definition classes. Is that absolutely necessary? I
> was kind of hoping that we could use something like commons proxy to
> do all of the proxying logic and get ourselves out of the Javassist
> business if we can.
>
> On 11/7/06, James Carman <ja...@carmanconsulting.com> wrote:
> > Well, whatever we do, I think we should try to keep the architecture
> > pretty simple, at least make it somewhat understandable. One of the
> > hardest things about HiveMind is getting your mind around it. It's
> > somewhat of a steep learning curve. That's one of the easiest things
> > about Spring (except for 2.0 where they basically allow you to define
> > your own DSL) is that it's pretty easy to understand. Wrapping stuff
> > into <bean> tags in Spring is very intuitive. I learned Spring way
> > easier than I learned HiveMind, but I think HiveMind has it right in a
> > lot more ways than Spring. I would argue that one of the reasons that
> > people complain about Tapestry's learning curve so much is that HM has
> > been thrown into the mix in 4.x. There are a *lot* of HM questions on
> > that mailing list!
> >
> >
> > On 11/7/06, Achim Hügen <ac...@gmx.de> wrote:
> > > It think it can be done this way.
> > > But now that you pointed out the consequences I'm no
> > > longer sure that this doesn't get too complex.
> > >
> > > Achim
> > >
> > >
> > > Am Tue, 07 Nov 2006 06:20:30 +0100 schrieb Knut Wannheden
> > > <kn...@gmail.com>:
> > >
> > > > James,
> > > >
> > > > Good point. I hadn't thought too hard about that but I think it should
> > > > be possible to bootstrap that. What we'd have to do is to:
> > > >
> > > > - Define the SchemaRegistry service using the Java or Java annotations
> > > > implementation of the API (as opposed to the XML implementation).
> > > > - Modify the existing XML DescriptorParser to handle <contribution>
> > > > elements to the "Schema" configuration the same way it handles
> > > > <schema> elements, which is to create the corresponding SchemaImpl
> > > > object and create a ContributionDef object for it. This
> > > > ContributionDef object would although use a ContributionConstructor
> > > > from the Java implementation of the API.
> > > >
> > > > This way the "Schema" configuration would not have a schema itself and
> > > > contributions to it would thus not require the "SchemaRegistry"
> > > > service in the ContributionConstructor. Also the "SchemaRegistry"
> > > > service can be setup without any schema processing if it's defined
> > > > using a Java or Java annotations module.
> > > >
> > > > Does this make sense?
> > > >
> > > > --knut
> > > >
> > > > On 11/6/06, James Carman <ja...@carmanconsulting.com> wrote:
> > > >> Aren't you getting into a chicken/egg scenario here? You need to
> > > >> parse the XML to set up the services, but you need the services to
> > > >> parse the XML. Sorry if I'm just jumping in the middle here with no
> > > >> context (I haven't been able to check out the new API yet,
> > > >> unfortunately), but this just sounded weird.
> > > >>
> > > >> On 11/6/06, Knut Wannheden <kn...@gmail.com> wrote:
> > > >> > Achim,
> > > >> >
> > > >> > I think I see what you're getting at. We could solve the whole problem
> > > >> > by defining the whole schema and parsing functionality in terms of
> > > >> > HiveMind services and configurations.
> > > >> >
> > > >> > The XML module could thus define a hivemind.xml.Schemas configuration
> > > >> > to which configuration and service points can contribute schemas.
> > > >> > Either implicitly by a <schema> element or explicitly with a normal
> > > >> > <contribution> element. I suppose a second configuration (e.g.
> > > >> > hivemind.xml.ExtensionSchemas) would be needed to define the linking
> > > >> > of a schema to specific configuration or service points. Again, the
> > > >> > contributions to this would be explicit or implicit.
> > > >> >
> > > >> > Now a contribution constructor could access a
> > > >> > hivemind.xml.SchemaManager service (having the aforementioned
> > > >> > configurations injected) to retrieve the schema and / or parser (or
> > > >> > also a "pairing") for its configuration point.
> > > >> >
> > > >> > Does this correspond to what you were thinking?
> > > >> >
> > > >> > --knut
> > > >> >
> > > >> > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > > >> > > Knut,
> > > >> > >
> > > >> > > you are right, SchemaProcessor should be a service
> > > >> > > and I would even make Schemas available via a SchemaManager
> > > >> > > service too.
> > > >> > > To make the parser based contribution possible as defined
> > > >> > > in the contributeToFactoryConfig method in the example
> > > >> > > (http://annocon.sourceforge.net/manual/configurations.html)
> > > >> > > we need a connection between configuration point, parser
> > > >> > > and schema. Otherwise the contributor would always
> > > >> > > have to specify which parser to use and I want to have a default.
> > > >> > >
> > > >> > > Achim
> > > >> > >
> > > >> > >
> > > >> > > Knut Wannheden schrieb:
> > > >> > > > Achim,
> > > >> > > >
> > > >> > > > Instead of adding a new construct I think it would be cleaner to
> > > >> > > > expose the parsers as normal services. The contribution
> > > >> constructor
> > > >> > > > would then be given access to the appropriate parser (or any other
> > > >> > > > visible service) using the contextual construction parameter. I
> > > >> > > > believe this would already work in your branch.
> > > >> > > >
> > > >> > > > So in the XML HiveMind module we'd expose the SchemaProcessor as a
> > > >> > > > service which could be used by contribution constructors.
> > > >> > > >
> > > >> > > > This also turns out to be how it's solved in Tapestry 5. See 3rd
> > > >> > > > example here:
> > > >> > > > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
> > > >> > > >
> > > >> > > > What do you say?
> > > >> > > >
> > > >> > > > --knut
> > > >> > > >
> > > >> > > > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > > >> > > >> Knut Wannheden schrieb:
> > > >> > > >> >
> > > >> > > >> > Maybe we could also drop the support for contributing to these
> > > >> > > >> > configurations using XML. OK, I know this contradicts what I
> > > >> wrote
> > > >> > > >> > about backwards compatibility in the other thread, but maybe
> > > >> that
> > > >> > > >> > would be OK. I'd like to point out that Howard changed how the
> > > >> eager
> > > >> > > >> > loading works in Tapestry 5 IOC. The ServicePointDef simply
> > > >> has a
> > > >> > > >> > boolean getEagerLoad() method. How about that?
> > > >> > > >> >
> > > >> > > >> I think I've found a better solution (borrowed from
> > > >> > > >> http://annocon.sourceforge.net/manual/configurations.html)
> > > >> > > >> I will introduce a generic parser interface which is defined in
> > > >> the
> > > >> > > >> framework
> > > >> > > >> already and which is not xml specific. A configuration can have
> > > >> multiple
> > > >> > > >> registered parsers.
> > > >> > > >> A parser is responsible for the contribution of data to a
> > > >> configuration
> > > >> > > >> which is defined in a textual format (especially file based
> > > >> data).
> > > >> > > >> The SchemaProcessor then is one special parser which can process
> > > >> > > >> inline data from a hivemodule.xml.
> > > >> > > >>
> > > >> > > >> The idea is that the creator of a configuration point says 'ok,
> > > >> here is
> > > >> > > >> a parser
> > > >> > > >> which can read contributions from files' and the provider of a
> > > >> > > >> contribution
> > > >> > > >> just says 'ok, then parse that file please'.
> > > >> > > >>
> > > >> > > >> Pros:
> > > >> > > >> + It solves our 'interface or no interface' dilemma. Since the
> > > >> parser
> > > >> > > >> concept
> > > >> > > >> is available in the framework the hivemodule parser can be
> > > >> easily
> > > >> > > >> attached by the xml module afterwards.
> > > >> > > >> + Configuration data can be defined in external files (xml,
> > > >> > > >> properties etc.)
> > > >> > > >> Either the hivemind parsing is extended so that xml files can be
> > > >> parsed
> > > >> > > >> that adhere to a hivemind schema or alternative parsers (e.g.
> > > >> Digester)
> > > >> > > >> are used.
> > > >> > > >> + Better integration of legacy data files
> > > >> > > >> + Annotated modules can provide parsers easily (see annocon
> > > >> examples).
> > > >> > > >>
> > > >> > > >> What do you think?
> > > >> > > >>
> > > >> > > >> Achim
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> > >
> > >
> >
>
Re: comments / questions on hivemind 2.0 branch
Posted by Achim Hügen <ac...@gmx.de>.
James Carman schrieb:
> I started looking through the new API today and so far it looks pretty
> cool. One thing I don't like, though, is having the ClassResolver
> stuff inside the definition classes. Is that absolutely necessary? I
> was kind of hoping that we could use something like commons proxy to
> do all of the proxying logic and get ourselves out of the Javassist
> business if we can.
The ModuleImpl needs a class provider for the resolveType method.
It is provided by the ModuleDefinition.
I think this has the same justification as the ClassResolver mechanism
itself.
Do you see another way?
Achim
Re: comments / questions on hivemind 2.0 branch
Posted by James Carman <ja...@carmanconsulting.com>.
I started looking through the new API today and so far it looks pretty
cool. One thing I don't like, though, is having the ClassResolver
stuff inside the definition classes. Is that absolutely necessary? I
was kind of hoping that we could use something like commons proxy to
do all of the proxying logic and get ourselves out of the Javassist
business if we can.
On 11/7/06, James Carman <ja...@carmanconsulting.com> wrote:
> Well, whatever we do, I think we should try to keep the architecture
> pretty simple, at least make it somewhat understandable. One of the
> hardest things about HiveMind is getting your mind around it. It's
> somewhat of a steep learning curve. That's one of the easiest things
> about Spring (except for 2.0 where they basically allow you to define
> your own DSL) is that it's pretty easy to understand. Wrapping stuff
> into <bean> tags in Spring is very intuitive. I learned Spring way
> easier than I learned HiveMind, but I think HiveMind has it right in a
> lot more ways than Spring. I would argue that one of the reasons that
> people complain about Tapestry's learning curve so much is that HM has
> been thrown into the mix in 4.x. There are a *lot* of HM questions on
> that mailing list!
>
>
> On 11/7/06, Achim Hügen <ac...@gmx.de> wrote:
> > It think it can be done this way.
> > But now that you pointed out the consequences I'm no
> > longer sure that this doesn't get too complex.
> >
> > Achim
> >
> >
> > Am Tue, 07 Nov 2006 06:20:30 +0100 schrieb Knut Wannheden
> > <kn...@gmail.com>:
> >
> > > James,
> > >
> > > Good point. I hadn't thought too hard about that but I think it should
> > > be possible to bootstrap that. What we'd have to do is to:
> > >
> > > - Define the SchemaRegistry service using the Java or Java annotations
> > > implementation of the API (as opposed to the XML implementation).
> > > - Modify the existing XML DescriptorParser to handle <contribution>
> > > elements to the "Schema" configuration the same way it handles
> > > <schema> elements, which is to create the corresponding SchemaImpl
> > > object and create a ContributionDef object for it. This
> > > ContributionDef object would although use a ContributionConstructor
> > > from the Java implementation of the API.
> > >
> > > This way the "Schema" configuration would not have a schema itself and
> > > contributions to it would thus not require the "SchemaRegistry"
> > > service in the ContributionConstructor. Also the "SchemaRegistry"
> > > service can be setup without any schema processing if it's defined
> > > using a Java or Java annotations module.
> > >
> > > Does this make sense?
> > >
> > > --knut
> > >
> > > On 11/6/06, James Carman <ja...@carmanconsulting.com> wrote:
> > >> Aren't you getting into a chicken/egg scenario here? You need to
> > >> parse the XML to set up the services, but you need the services to
> > >> parse the XML. Sorry if I'm just jumping in the middle here with no
> > >> context (I haven't been able to check out the new API yet,
> > >> unfortunately), but this just sounded weird.
> > >>
> > >> On 11/6/06, Knut Wannheden <kn...@gmail.com> wrote:
> > >> > Achim,
> > >> >
> > >> > I think I see what you're getting at. We could solve the whole problem
> > >> > by defining the whole schema and parsing functionality in terms of
> > >> > HiveMind services and configurations.
> > >> >
> > >> > The XML module could thus define a hivemind.xml.Schemas configuration
> > >> > to which configuration and service points can contribute schemas.
> > >> > Either implicitly by a <schema> element or explicitly with a normal
> > >> > <contribution> element. I suppose a second configuration (e.g.
> > >> > hivemind.xml.ExtensionSchemas) would be needed to define the linking
> > >> > of a schema to specific configuration or service points. Again, the
> > >> > contributions to this would be explicit or implicit.
> > >> >
> > >> > Now a contribution constructor could access a
> > >> > hivemind.xml.SchemaManager service (having the aforementioned
> > >> > configurations injected) to retrieve the schema and / or parser (or
> > >> > also a "pairing") for its configuration point.
> > >> >
> > >> > Does this correspond to what you were thinking?
> > >> >
> > >> > --knut
> > >> >
> > >> > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > >> > > Knut,
> > >> > >
> > >> > > you are right, SchemaProcessor should be a service
> > >> > > and I would even make Schemas available via a SchemaManager
> > >> > > service too.
> > >> > > To make the parser based contribution possible as defined
> > >> > > in the contributeToFactoryConfig method in the example
> > >> > > (http://annocon.sourceforge.net/manual/configurations.html)
> > >> > > we need a connection between configuration point, parser
> > >> > > and schema. Otherwise the contributor would always
> > >> > > have to specify which parser to use and I want to have a default.
> > >> > >
> > >> > > Achim
> > >> > >
> > >> > >
> > >> > > Knut Wannheden schrieb:
> > >> > > > Achim,
> > >> > > >
> > >> > > > Instead of adding a new construct I think it would be cleaner to
> > >> > > > expose the parsers as normal services. The contribution
> > >> constructor
> > >> > > > would then be given access to the appropriate parser (or any other
> > >> > > > visible service) using the contextual construction parameter. I
> > >> > > > believe this would already work in your branch.
> > >> > > >
> > >> > > > So in the XML HiveMind module we'd expose the SchemaProcessor as a
> > >> > > > service which could be used by contribution constructors.
> > >> > > >
> > >> > > > This also turns out to be how it's solved in Tapestry 5. See 3rd
> > >> > > > example here:
> > >> > > > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
> > >> > > >
> > >> > > > What do you say?
> > >> > > >
> > >> > > > --knut
> > >> > > >
> > >> > > > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > >> > > >> Knut Wannheden schrieb:
> > >> > > >> >
> > >> > > >> > Maybe we could also drop the support for contributing to these
> > >> > > >> > configurations using XML. OK, I know this contradicts what I
> > >> wrote
> > >> > > >> > about backwards compatibility in the other thread, but maybe
> > >> that
> > >> > > >> > would be OK. I'd like to point out that Howard changed how the
> > >> eager
> > >> > > >> > loading works in Tapestry 5 IOC. The ServicePointDef simply
> > >> has a
> > >> > > >> > boolean getEagerLoad() method. How about that?
> > >> > > >> >
> > >> > > >> I think I've found a better solution (borrowed from
> > >> > > >> http://annocon.sourceforge.net/manual/configurations.html)
> > >> > > >> I will introduce a generic parser interface which is defined in
> > >> the
> > >> > > >> framework
> > >> > > >> already and which is not xml specific. A configuration can have
> > >> multiple
> > >> > > >> registered parsers.
> > >> > > >> A parser is responsible for the contribution of data to a
> > >> configuration
> > >> > > >> which is defined in a textual format (especially file based
> > >> data).
> > >> > > >> The SchemaProcessor then is one special parser which can process
> > >> > > >> inline data from a hivemodule.xml.
> > >> > > >>
> > >> > > >> The idea is that the creator of a configuration point says 'ok,
> > >> here is
> > >> > > >> a parser
> > >> > > >> which can read contributions from files' and the provider of a
> > >> > > >> contribution
> > >> > > >> just says 'ok, then parse that file please'.
> > >> > > >>
> > >> > > >> Pros:
> > >> > > >> + It solves our 'interface or no interface' dilemma. Since the
> > >> parser
> > >> > > >> concept
> > >> > > >> is available in the framework the hivemodule parser can be
> > >> easily
> > >> > > >> attached by the xml module afterwards.
> > >> > > >> + Configuration data can be defined in external files (xml,
> > >> > > >> properties etc.)
> > >> > > >> Either the hivemind parsing is extended so that xml files can be
> > >> parsed
> > >> > > >> that adhere to a hivemind schema or alternative parsers (e.g.
> > >> Digester)
> > >> > > >> are used.
> > >> > > >> + Better integration of legacy data files
> > >> > > >> + Annotated modules can provide parsers easily (see annocon
> > >> examples).
> > >> > > >>
> > >> > > >> What do you think?
> > >> > > >>
> > >> > > >> Achim
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> >
> >
> >
>
Re: comments / questions on hivemind 2.0 branch
Posted by James Carman <ja...@carmanconsulting.com>.
Well, whatever we do, I think we should try to keep the architecture
pretty simple, at least make it somewhat understandable. One of the
hardest things about HiveMind is getting your mind around it. It's
somewhat of a steep learning curve. That's one of the easiest things
about Spring (except for 2.0 where they basically allow you to define
your own DSL) is that it's pretty easy to understand. Wrapping stuff
into <bean> tags in Spring is very intuitive. I learned Spring way
easier than I learned HiveMind, but I think HiveMind has it right in a
lot more ways than Spring. I would argue that one of the reasons that
people complain about Tapestry's learning curve so much is that HM has
been thrown into the mix in 4.x. There are a *lot* of HM questions on
that mailing list!
On 11/7/06, Achim Hügen <ac...@gmx.de> wrote:
> It think it can be done this way.
> But now that you pointed out the consequences I'm no
> longer sure that this doesn't get too complex.
>
> Achim
>
>
> Am Tue, 07 Nov 2006 06:20:30 +0100 schrieb Knut Wannheden
> <kn...@gmail.com>:
>
> > James,
> >
> > Good point. I hadn't thought too hard about that but I think it should
> > be possible to bootstrap that. What we'd have to do is to:
> >
> > - Define the SchemaRegistry service using the Java or Java annotations
> > implementation of the API (as opposed to the XML implementation).
> > - Modify the existing XML DescriptorParser to handle <contribution>
> > elements to the "Schema" configuration the same way it handles
> > <schema> elements, which is to create the corresponding SchemaImpl
> > object and create a ContributionDef object for it. This
> > ContributionDef object would although use a ContributionConstructor
> > from the Java implementation of the API.
> >
> > This way the "Schema" configuration would not have a schema itself and
> > contributions to it would thus not require the "SchemaRegistry"
> > service in the ContributionConstructor. Also the "SchemaRegistry"
> > service can be setup without any schema processing if it's defined
> > using a Java or Java annotations module.
> >
> > Does this make sense?
> >
> > --knut
> >
> > On 11/6/06, James Carman <ja...@carmanconsulting.com> wrote:
> >> Aren't you getting into a chicken/egg scenario here? You need to
> >> parse the XML to set up the services, but you need the services to
> >> parse the XML. Sorry if I'm just jumping in the middle here with no
> >> context (I haven't been able to check out the new API yet,
> >> unfortunately), but this just sounded weird.
> >>
> >> On 11/6/06, Knut Wannheden <kn...@gmail.com> wrote:
> >> > Achim,
> >> >
> >> > I think I see what you're getting at. We could solve the whole problem
> >> > by defining the whole schema and parsing functionality in terms of
> >> > HiveMind services and configurations.
> >> >
> >> > The XML module could thus define a hivemind.xml.Schemas configuration
> >> > to which configuration and service points can contribute schemas.
> >> > Either implicitly by a <schema> element or explicitly with a normal
> >> > <contribution> element. I suppose a second configuration (e.g.
> >> > hivemind.xml.ExtensionSchemas) would be needed to define the linking
> >> > of a schema to specific configuration or service points. Again, the
> >> > contributions to this would be explicit or implicit.
> >> >
> >> > Now a contribution constructor could access a
> >> > hivemind.xml.SchemaManager service (having the aforementioned
> >> > configurations injected) to retrieve the schema and / or parser (or
> >> > also a "pairing") for its configuration point.
> >> >
> >> > Does this correspond to what you were thinking?
> >> >
> >> > --knut
> >> >
> >> > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> >> > > Knut,
> >> > >
> >> > > you are right, SchemaProcessor should be a service
> >> > > and I would even make Schemas available via a SchemaManager
> >> > > service too.
> >> > > To make the parser based contribution possible as defined
> >> > > in the contributeToFactoryConfig method in the example
> >> > > (http://annocon.sourceforge.net/manual/configurations.html)
> >> > > we need a connection between configuration point, parser
> >> > > and schema. Otherwise the contributor would always
> >> > > have to specify which parser to use and I want to have a default.
> >> > >
> >> > > Achim
> >> > >
> >> > >
> >> > > Knut Wannheden schrieb:
> >> > > > Achim,
> >> > > >
> >> > > > Instead of adding a new construct I think it would be cleaner to
> >> > > > expose the parsers as normal services. The contribution
> >> constructor
> >> > > > would then be given access to the appropriate parser (or any other
> >> > > > visible service) using the contextual construction parameter. I
> >> > > > believe this would already work in your branch.
> >> > > >
> >> > > > So in the XML HiveMind module we'd expose the SchemaProcessor as a
> >> > > > service which could be used by contribution constructors.
> >> > > >
> >> > > > This also turns out to be how it's solved in Tapestry 5. See 3rd
> >> > > > example here:
> >> > > > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
> >> > > >
> >> > > > What do you say?
> >> > > >
> >> > > > --knut
> >> > > >
> >> > > > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> >> > > >> Knut Wannheden schrieb:
> >> > > >> >
> >> > > >> > Maybe we could also drop the support for contributing to these
> >> > > >> > configurations using XML. OK, I know this contradicts what I
> >> wrote
> >> > > >> > about backwards compatibility in the other thread, but maybe
> >> that
> >> > > >> > would be OK. I'd like to point out that Howard changed how the
> >> eager
> >> > > >> > loading works in Tapestry 5 IOC. The ServicePointDef simply
> >> has a
> >> > > >> > boolean getEagerLoad() method. How about that?
> >> > > >> >
> >> > > >> I think I've found a better solution (borrowed from
> >> > > >> http://annocon.sourceforge.net/manual/configurations.html)
> >> > > >> I will introduce a generic parser interface which is defined in
> >> the
> >> > > >> framework
> >> > > >> already and which is not xml specific. A configuration can have
> >> multiple
> >> > > >> registered parsers.
> >> > > >> A parser is responsible for the contribution of data to a
> >> configuration
> >> > > >> which is defined in a textual format (especially file based
> >> data).
> >> > > >> The SchemaProcessor then is one special parser which can process
> >> > > >> inline data from a hivemodule.xml.
> >> > > >>
> >> > > >> The idea is that the creator of a configuration point says 'ok,
> >> here is
> >> > > >> a parser
> >> > > >> which can read contributions from files' and the provider of a
> >> > > >> contribution
> >> > > >> just says 'ok, then parse that file please'.
> >> > > >>
> >> > > >> Pros:
> >> > > >> + It solves our 'interface or no interface' dilemma. Since the
> >> parser
> >> > > >> concept
> >> > > >> is available in the framework the hivemodule parser can be
> >> easily
> >> > > >> attached by the xml module afterwards.
> >> > > >> + Configuration data can be defined in external files (xml,
> >> > > >> properties etc.)
> >> > > >> Either the hivemind parsing is extended so that xml files can be
> >> parsed
> >> > > >> that adhere to a hivemind schema or alternative parsers (e.g.
> >> Digester)
> >> > > >> are used.
> >> > > >> + Better integration of legacy data files
> >> > > >> + Annotated modules can provide parsers easily (see annocon
> >> examples).
> >> > > >>
> >> > > >> What do you think?
> >> > > >>
> >> > > >> Achim
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >
>
>
>
Re: comments / questions on hivemind 2.0 branch
Posted by Knut Wannheden <kn...@gmail.com>.
There is one alternative I can think of. The SchemaRegistry service
could provided a hardcoded (using Java code) Schema for the "Schemas"
extension point. Then any <contribution> to the "Schemas"
configuration could be handled the same way as any other
<contribution>. But of course the contribution would then have to go
through the SchemaProcessor to create the Schema...
I think all the magic in the XML implementation of the API actually
warrants some complexity in its implementation. And I think we should
try hard to keep as much of this complexity out of the framework. Thus
I don't think either of these approaches would be that bad.
--knut
On 11/7/06, Achim Hügen <ac...@gmx.de> wrote:
> It think it can be done this way.
> But now that you pointed out the consequences I'm no
> longer sure that this doesn't get too complex.
>
> Achim
>
>
> Am Tue, 07 Nov 2006 06:20:30 +0100 schrieb Knut Wannheden
> <kn...@gmail.com>:
>
> > James,
> >
> > Good point. I hadn't thought too hard about that but I think it should
> > be possible to bootstrap that. What we'd have to do is to:
> >
> > - Define the SchemaRegistry service using the Java or Java annotations
> > implementation of the API (as opposed to the XML implementation).
> > - Modify the existing XML DescriptorParser to handle <contribution>
> > elements to the "Schema" configuration the same way it handles
> > <schema> elements, which is to create the corresponding SchemaImpl
> > object and create a ContributionDef object for it. This
> > ContributionDef object would although use a ContributionConstructor
> > from the Java implementation of the API.
> >
> > This way the "Schema" configuration would not have a schema itself and
> > contributions to it would thus not require the "SchemaRegistry"
> > service in the ContributionConstructor. Also the "SchemaRegistry"
> > service can be setup without any schema processing if it's defined
> > using a Java or Java annotations module.
> >
> > Does this make sense?
> >
> > --knut
> >
> > On 11/6/06, James Carman <ja...@carmanconsulting.com> wrote:
> >> Aren't you getting into a chicken/egg scenario here? You need to
> >> parse the XML to set up the services, but you need the services to
> >> parse the XML. Sorry if I'm just jumping in the middle here with no
> >> context (I haven't been able to check out the new API yet,
> >> unfortunately), but this just sounded weird.
> >>
> >> On 11/6/06, Knut Wannheden <kn...@gmail.com> wrote:
> >> > Achim,
> >> >
> >> > I think I see what you're getting at. We could solve the whole problem
> >> > by defining the whole schema and parsing functionality in terms of
> >> > HiveMind services and configurations.
> >> >
> >> > The XML module could thus define a hivemind.xml.Schemas configuration
> >> > to which configuration and service points can contribute schemas.
> >> > Either implicitly by a <schema> element or explicitly with a normal
> >> > <contribution> element. I suppose a second configuration (e.g.
> >> > hivemind.xml.ExtensionSchemas) would be needed to define the linking
> >> > of a schema to specific configuration or service points. Again, the
> >> > contributions to this would be explicit or implicit.
> >> >
> >> > Now a contribution constructor could access a
> >> > hivemind.xml.SchemaManager service (having the aforementioned
> >> > configurations injected) to retrieve the schema and / or parser (or
> >> > also a "pairing") for its configuration point.
> >> >
> >> > Does this correspond to what you were thinking?
> >> >
> >> > --knut
> >> >
> >> > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> >> > > Knut,
> >> > >
> >> > > you are right, SchemaProcessor should be a service
> >> > > and I would even make Schemas available via a SchemaManager
> >> > > service too.
> >> > > To make the parser based contribution possible as defined
> >> > > in the contributeToFactoryConfig method in the example
> >> > > (http://annocon.sourceforge.net/manual/configurations.html)
> >> > > we need a connection between configuration point, parser
> >> > > and schema. Otherwise the contributor would always
> >> > > have to specify which parser to use and I want to have a default.
> >> > >
> >> > > Achim
> >> > >
> >> > >
> >> > > Knut Wannheden schrieb:
> >> > > > Achim,
> >> > > >
> >> > > > Instead of adding a new construct I think it would be cleaner to
> >> > > > expose the parsers as normal services. The contribution
> >> constructor
> >> > > > would then be given access to the appropriate parser (or any other
> >> > > > visible service) using the contextual construction parameter. I
> >> > > > believe this would already work in your branch.
> >> > > >
> >> > > > So in the XML HiveMind module we'd expose the SchemaProcessor as a
> >> > > > service which could be used by contribution constructors.
> >> > > >
> >> > > > This also turns out to be how it's solved in Tapestry 5. See 3rd
> >> > > > example here:
> >> > > > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
> >> > > >
> >> > > > What do you say?
> >> > > >
> >> > > > --knut
> >> > > >
> >> > > > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> >> > > >> Knut Wannheden schrieb:
> >> > > >> >
> >> > > >> > Maybe we could also drop the support for contributing to these
> >> > > >> > configurations using XML. OK, I know this contradicts what I
> >> wrote
> >> > > >> > about backwards compatibility in the other thread, but maybe
> >> that
> >> > > >> > would be OK. I'd like to point out that Howard changed how the
> >> eager
> >> > > >> > loading works in Tapestry 5 IOC. The ServicePointDef simply
> >> has a
> >> > > >> > boolean getEagerLoad() method. How about that?
> >> > > >> >
> >> > > >> I think I've found a better solution (borrowed from
> >> > > >> http://annocon.sourceforge.net/manual/configurations.html)
> >> > > >> I will introduce a generic parser interface which is defined in
> >> the
> >> > > >> framework
> >> > > >> already and which is not xml specific. A configuration can have
> >> multiple
> >> > > >> registered parsers.
> >> > > >> A parser is responsible for the contribution of data to a
> >> configuration
> >> > > >> which is defined in a textual format (especially file based
> >> data).
> >> > > >> The SchemaProcessor then is one special parser which can process
> >> > > >> inline data from a hivemodule.xml.
> >> > > >>
> >> > > >> The idea is that the creator of a configuration point says 'ok,
> >> here is
> >> > > >> a parser
> >> > > >> which can read contributions from files' and the provider of a
> >> > > >> contribution
> >> > > >> just says 'ok, then parse that file please'.
> >> > > >>
> >> > > >> Pros:
> >> > > >> + It solves our 'interface or no interface' dilemma. Since the
> >> parser
> >> > > >> concept
> >> > > >> is available in the framework the hivemodule parser can be
> >> easily
> >> > > >> attached by the xml module afterwards.
> >> > > >> + Configuration data can be defined in external files (xml,
> >> > > >> properties etc.)
> >> > > >> Either the hivemind parsing is extended so that xml files can be
> >> parsed
> >> > > >> that adhere to a hivemind schema or alternative parsers (e.g.
> >> Digester)
> >> > > >> are used.
> >> > > >> + Better integration of legacy data files
> >> > > >> + Annotated modules can provide parsers easily (see annocon
> >> examples).
> >> > > >>
> >> > > >> What do you think?
> >> > > >>
> >> > > >> Achim
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >
>
>
>
Re: comments / questions on hivemind 2.0 branch
Posted by Achim Hügen <ac...@gmx.de>.
It think it can be done this way.
But now that you pointed out the consequences I'm no
longer sure that this doesn't get too complex.
Achim
Am Tue, 07 Nov 2006 06:20:30 +0100 schrieb Knut Wannheden
<kn...@gmail.com>:
> James,
>
> Good point. I hadn't thought too hard about that but I think it should
> be possible to bootstrap that. What we'd have to do is to:
>
> - Define the SchemaRegistry service using the Java or Java annotations
> implementation of the API (as opposed to the XML implementation).
> - Modify the existing XML DescriptorParser to handle <contribution>
> elements to the "Schema" configuration the same way it handles
> <schema> elements, which is to create the corresponding SchemaImpl
> object and create a ContributionDef object for it. This
> ContributionDef object would although use a ContributionConstructor
> from the Java implementation of the API.
>
> This way the "Schema" configuration would not have a schema itself and
> contributions to it would thus not require the "SchemaRegistry"
> service in the ContributionConstructor. Also the "SchemaRegistry"
> service can be setup without any schema processing if it's defined
> using a Java or Java annotations module.
>
> Does this make sense?
>
> --knut
>
> On 11/6/06, James Carman <ja...@carmanconsulting.com> wrote:
>> Aren't you getting into a chicken/egg scenario here? You need to
>> parse the XML to set up the services, but you need the services to
>> parse the XML. Sorry if I'm just jumping in the middle here with no
>> context (I haven't been able to check out the new API yet,
>> unfortunately), but this just sounded weird.
>>
>> On 11/6/06, Knut Wannheden <kn...@gmail.com> wrote:
>> > Achim,
>> >
>> > I think I see what you're getting at. We could solve the whole problem
>> > by defining the whole schema and parsing functionality in terms of
>> > HiveMind services and configurations.
>> >
>> > The XML module could thus define a hivemind.xml.Schemas configuration
>> > to which configuration and service points can contribute schemas.
>> > Either implicitly by a <schema> element or explicitly with a normal
>> > <contribution> element. I suppose a second configuration (e.g.
>> > hivemind.xml.ExtensionSchemas) would be needed to define the linking
>> > of a schema to specific configuration or service points. Again, the
>> > contributions to this would be explicit or implicit.
>> >
>> > Now a contribution constructor could access a
>> > hivemind.xml.SchemaManager service (having the aforementioned
>> > configurations injected) to retrieve the schema and / or parser (or
>> > also a "pairing") for its configuration point.
>> >
>> > Does this correspond to what you were thinking?
>> >
>> > --knut
>> >
>> > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
>> > > Knut,
>> > >
>> > > you are right, SchemaProcessor should be a service
>> > > and I would even make Schemas available via a SchemaManager
>> > > service too.
>> > > To make the parser based contribution possible as defined
>> > > in the contributeToFactoryConfig method in the example
>> > > (http://annocon.sourceforge.net/manual/configurations.html)
>> > > we need a connection between configuration point, parser
>> > > and schema. Otherwise the contributor would always
>> > > have to specify which parser to use and I want to have a default.
>> > >
>> > > Achim
>> > >
>> > >
>> > > Knut Wannheden schrieb:
>> > > > Achim,
>> > > >
>> > > > Instead of adding a new construct I think it would be cleaner to
>> > > > expose the parsers as normal services. The contribution
>> constructor
>> > > > would then be given access to the appropriate parser (or any other
>> > > > visible service) using the contextual construction parameter. I
>> > > > believe this would already work in your branch.
>> > > >
>> > > > So in the XML HiveMind module we'd expose the SchemaProcessor as a
>> > > > service which could be used by contribution constructors.
>> > > >
>> > > > This also turns out to be how it's solved in Tapestry 5. See 3rd
>> > > > example here:
>> > > > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
>> > > >
>> > > > What do you say?
>> > > >
>> > > > --knut
>> > > >
>> > > > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
>> > > >> Knut Wannheden schrieb:
>> > > >> >
>> > > >> > Maybe we could also drop the support for contributing to these
>> > > >> > configurations using XML. OK, I know this contradicts what I
>> wrote
>> > > >> > about backwards compatibility in the other thread, but maybe
>> that
>> > > >> > would be OK. I'd like to point out that Howard changed how the
>> eager
>> > > >> > loading works in Tapestry 5 IOC. The ServicePointDef simply
>> has a
>> > > >> > boolean getEagerLoad() method. How about that?
>> > > >> >
>> > > >> I think I've found a better solution (borrowed from
>> > > >> http://annocon.sourceforge.net/manual/configurations.html)
>> > > >> I will introduce a generic parser interface which is defined in
>> the
>> > > >> framework
>> > > >> already and which is not xml specific. A configuration can have
>> multiple
>> > > >> registered parsers.
>> > > >> A parser is responsible for the contribution of data to a
>> configuration
>> > > >> which is defined in a textual format (especially file based
>> data).
>> > > >> The SchemaProcessor then is one special parser which can process
>> > > >> inline data from a hivemodule.xml.
>> > > >>
>> > > >> The idea is that the creator of a configuration point says 'ok,
>> here is
>> > > >> a parser
>> > > >> which can read contributions from files' and the provider of a
>> > > >> contribution
>> > > >> just says 'ok, then parse that file please'.
>> > > >>
>> > > >> Pros:
>> > > >> + It solves our 'interface or no interface' dilemma. Since the
>> parser
>> > > >> concept
>> > > >> is available in the framework the hivemodule parser can be
>> easily
>> > > >> attached by the xml module afterwards.
>> > > >> + Configuration data can be defined in external files (xml,
>> > > >> properties etc.)
>> > > >> Either the hivemind parsing is extended so that xml files can be
>> parsed
>> > > >> that adhere to a hivemind schema or alternative parsers (e.g.
>> Digester)
>> > > >> are used.
>> > > >> + Better integration of legacy data files
>> > > >> + Annotated modules can provide parsers easily (see annocon
>> examples).
>> > > >>
>> > > >> What do you think?
>> > > >>
>> > > >> Achim
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >
>> > > >
>> > >
>> > >
>> >
>>
>
Re: comments / questions on hivemind 2.0 branch
Posted by Knut Wannheden <kn...@gmail.com>.
James,
Good point. I hadn't thought too hard about that but I think it should
be possible to bootstrap that. What we'd have to do is to:
- Define the SchemaRegistry service using the Java or Java annotations
implementation of the API (as opposed to the XML implementation).
- Modify the existing XML DescriptorParser to handle <contribution>
elements to the "Schema" configuration the same way it handles
<schema> elements, which is to create the corresponding SchemaImpl
object and create a ContributionDef object for it. This
ContributionDef object would although use a ContributionConstructor
from the Java implementation of the API.
This way the "Schema" configuration would not have a schema itself and
contributions to it would thus not require the "SchemaRegistry"
service in the ContributionConstructor. Also the "SchemaRegistry"
service can be setup without any schema processing if it's defined
using a Java or Java annotations module.
Does this make sense?
--knut
On 11/6/06, James Carman <ja...@carmanconsulting.com> wrote:
> Aren't you getting into a chicken/egg scenario here? You need to
> parse the XML to set up the services, but you need the services to
> parse the XML. Sorry if I'm just jumping in the middle here with no
> context (I haven't been able to check out the new API yet,
> unfortunately), but this just sounded weird.
>
> On 11/6/06, Knut Wannheden <kn...@gmail.com> wrote:
> > Achim,
> >
> > I think I see what you're getting at. We could solve the whole problem
> > by defining the whole schema and parsing functionality in terms of
> > HiveMind services and configurations.
> >
> > The XML module could thus define a hivemind.xml.Schemas configuration
> > to which configuration and service points can contribute schemas.
> > Either implicitly by a <schema> element or explicitly with a normal
> > <contribution> element. I suppose a second configuration (e.g.
> > hivemind.xml.ExtensionSchemas) would be needed to define the linking
> > of a schema to specific configuration or service points. Again, the
> > contributions to this would be explicit or implicit.
> >
> > Now a contribution constructor could access a
> > hivemind.xml.SchemaManager service (having the aforementioned
> > configurations injected) to retrieve the schema and / or parser (or
> > also a "pairing") for its configuration point.
> >
> > Does this correspond to what you were thinking?
> >
> > --knut
> >
> > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > > Knut,
> > >
> > > you are right, SchemaProcessor should be a service
> > > and I would even make Schemas available via a SchemaManager
> > > service too.
> > > To make the parser based contribution possible as defined
> > > in the contributeToFactoryConfig method in the example
> > > (http://annocon.sourceforge.net/manual/configurations.html)
> > > we need a connection between configuration point, parser
> > > and schema. Otherwise the contributor would always
> > > have to specify which parser to use and I want to have a default.
> > >
> > > Achim
> > >
> > >
> > > Knut Wannheden schrieb:
> > > > Achim,
> > > >
> > > > Instead of adding a new construct I think it would be cleaner to
> > > > expose the parsers as normal services. The contribution constructor
> > > > would then be given access to the appropriate parser (or any other
> > > > visible service) using the contextual construction parameter. I
> > > > believe this would already work in your branch.
> > > >
> > > > So in the XML HiveMind module we'd expose the SchemaProcessor as a
> > > > service which could be used by contribution constructors.
> > > >
> > > > This also turns out to be how it's solved in Tapestry 5. See 3rd
> > > > example here:
> > > > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
> > > >
> > > > What do you say?
> > > >
> > > > --knut
> > > >
> > > > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > > >> Knut Wannheden schrieb:
> > > >> >
> > > >> > Maybe we could also drop the support for contributing to these
> > > >> > configurations using XML. OK, I know this contradicts what I wrote
> > > >> > about backwards compatibility in the other thread, but maybe that
> > > >> > would be OK. I'd like to point out that Howard changed how the eager
> > > >> > loading works in Tapestry 5 IOC. The ServicePointDef simply has a
> > > >> > boolean getEagerLoad() method. How about that?
> > > >> >
> > > >> I think I've found a better solution (borrowed from
> > > >> http://annocon.sourceforge.net/manual/configurations.html)
> > > >> I will introduce a generic parser interface which is defined in the
> > > >> framework
> > > >> already and which is not xml specific. A configuration can have multiple
> > > >> registered parsers.
> > > >> A parser is responsible for the contribution of data to a configuration
> > > >> which is defined in a textual format (especially file based data).
> > > >> The SchemaProcessor then is one special parser which can process
> > > >> inline data from a hivemodule.xml.
> > > >>
> > > >> The idea is that the creator of a configuration point says 'ok, here is
> > > >> a parser
> > > >> which can read contributions from files' and the provider of a
> > > >> contribution
> > > >> just says 'ok, then parse that file please'.
> > > >>
> > > >> Pros:
> > > >> + It solves our 'interface or no interface' dilemma. Since the parser
> > > >> concept
> > > >> is available in the framework the hivemodule parser can be easily
> > > >> attached by the xml module afterwards.
> > > >> + Configuration data can be defined in external files (xml,
> > > >> properties etc.)
> > > >> Either the hivemind parsing is extended so that xml files can be parsed
> > > >> that adhere to a hivemind schema or alternative parsers (e.g. Digester)
> > > >> are used.
> > > >> + Better integration of legacy data files
> > > >> + Annotated modules can provide parsers easily (see annocon examples).
> > > >>
> > > >> What do you think?
> > > >>
> > > >> Achim
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> >
>
Re: comments / questions on hivemind 2.0 branch
Posted by James Carman <ja...@carmanconsulting.com>.
Aren't you getting into a chicken/egg scenario here? You need to
parse the XML to set up the services, but you need the services to
parse the XML. Sorry if I'm just jumping in the middle here with no
context (I haven't been able to check out the new API yet,
unfortunately), but this just sounded weird.
On 11/6/06, Knut Wannheden <kn...@gmail.com> wrote:
> Achim,
>
> I think I see what you're getting at. We could solve the whole problem
> by defining the whole schema and parsing functionality in terms of
> HiveMind services and configurations.
>
> The XML module could thus define a hivemind.xml.Schemas configuration
> to which configuration and service points can contribute schemas.
> Either implicitly by a <schema> element or explicitly with a normal
> <contribution> element. I suppose a second configuration (e.g.
> hivemind.xml.ExtensionSchemas) would be needed to define the linking
> of a schema to specific configuration or service points. Again, the
> contributions to this would be explicit or implicit.
>
> Now a contribution constructor could access a
> hivemind.xml.SchemaManager service (having the aforementioned
> configurations injected) to retrieve the schema and / or parser (or
> also a "pairing") for its configuration point.
>
> Does this correspond to what you were thinking?
>
> --knut
>
> On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > Knut,
> >
> > you are right, SchemaProcessor should be a service
> > and I would even make Schemas available via a SchemaManager
> > service too.
> > To make the parser based contribution possible as defined
> > in the contributeToFactoryConfig method in the example
> > (http://annocon.sourceforge.net/manual/configurations.html)
> > we need a connection between configuration point, parser
> > and schema. Otherwise the contributor would always
> > have to specify which parser to use and I want to have a default.
> >
> > Achim
> >
> >
> > Knut Wannheden schrieb:
> > > Achim,
> > >
> > > Instead of adding a new construct I think it would be cleaner to
> > > expose the parsers as normal services. The contribution constructor
> > > would then be given access to the appropriate parser (or any other
> > > visible service) using the contextual construction parameter. I
> > > believe this would already work in your branch.
> > >
> > > So in the XML HiveMind module we'd expose the SchemaProcessor as a
> > > service which could be used by contribution constructors.
> > >
> > > This also turns out to be how it's solved in Tapestry 5. See 3rd
> > > example here:
> > > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
> > >
> > > What do you say?
> > >
> > > --knut
> > >
> > > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> > >> Knut Wannheden schrieb:
> > >> >
> > >> > Maybe we could also drop the support for contributing to these
> > >> > configurations using XML. OK, I know this contradicts what I wrote
> > >> > about backwards compatibility in the other thread, but maybe that
> > >> > would be OK. I'd like to point out that Howard changed how the eager
> > >> > loading works in Tapestry 5 IOC. The ServicePointDef simply has a
> > >> > boolean getEagerLoad() method. How about that?
> > >> >
> > >> I think I've found a better solution (borrowed from
> > >> http://annocon.sourceforge.net/manual/configurations.html)
> > >> I will introduce a generic parser interface which is defined in the
> > >> framework
> > >> already and which is not xml specific. A configuration can have multiple
> > >> registered parsers.
> > >> A parser is responsible for the contribution of data to a configuration
> > >> which is defined in a textual format (especially file based data).
> > >> The SchemaProcessor then is one special parser which can process
> > >> inline data from a hivemodule.xml.
> > >>
> > >> The idea is that the creator of a configuration point says 'ok, here is
> > >> a parser
> > >> which can read contributions from files' and the provider of a
> > >> contribution
> > >> just says 'ok, then parse that file please'.
> > >>
> > >> Pros:
> > >> + It solves our 'interface or no interface' dilemma. Since the parser
> > >> concept
> > >> is available in the framework the hivemodule parser can be easily
> > >> attached by the xml module afterwards.
> > >> + Configuration data can be defined in external files (xml,
> > >> properties etc.)
> > >> Either the hivemind parsing is extended so that xml files can be parsed
> > >> that adhere to a hivemind schema or alternative parsers (e.g. Digester)
> > >> are used.
> > >> + Better integration of legacy data files
> > >> + Annotated modules can provide parsers easily (see annocon examples).
> > >>
> > >> What do you think?
> > >>
> > >> Achim
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
>
Re: comments / questions on hivemind 2.0 branch
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
I think I see what you're getting at. We could solve the whole problem
by defining the whole schema and parsing functionality in terms of
HiveMind services and configurations.
The XML module could thus define a hivemind.xml.Schemas configuration
to which configuration and service points can contribute schemas.
Either implicitly by a <schema> element or explicitly with a normal
<contribution> element. I suppose a second configuration (e.g.
hivemind.xml.ExtensionSchemas) would be needed to define the linking
of a schema to specific configuration or service points. Again, the
contributions to this would be explicit or implicit.
Now a contribution constructor could access a
hivemind.xml.SchemaManager service (having the aforementioned
configurations injected) to retrieve the schema and / or parser (or
also a "pairing") for its configuration point.
Does this correspond to what you were thinking?
--knut
On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> Knut,
>
> you are right, SchemaProcessor should be a service
> and I would even make Schemas available via a SchemaManager
> service too.
> To make the parser based contribution possible as defined
> in the contributeToFactoryConfig method in the example
> (http://annocon.sourceforge.net/manual/configurations.html)
> we need a connection between configuration point, parser
> and schema. Otherwise the contributor would always
> have to specify which parser to use and I want to have a default.
>
> Achim
>
>
> Knut Wannheden schrieb:
> > Achim,
> >
> > Instead of adding a new construct I think it would be cleaner to
> > expose the parsers as normal services. The contribution constructor
> > would then be given access to the appropriate parser (or any other
> > visible service) using the contextual construction parameter. I
> > believe this would already work in your branch.
> >
> > So in the XML HiveMind module we'd expose the SchemaProcessor as a
> > service which could be used by contribution constructors.
> >
> > This also turns out to be how it's solved in Tapestry 5. See 3rd
> > example here:
> > http://tapestry.apache.org/tapestry5/ioc/configuration.html.
> >
> > What do you say?
> >
> > --knut
> >
> > On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> >> Knut Wannheden schrieb:
> >> >
> >> > Maybe we could also drop the support for contributing to these
> >> > configurations using XML. OK, I know this contradicts what I wrote
> >> > about backwards compatibility in the other thread, but maybe that
> >> > would be OK. I'd like to point out that Howard changed how the eager
> >> > loading works in Tapestry 5 IOC. The ServicePointDef simply has a
> >> > boolean getEagerLoad() method. How about that?
> >> >
> >> I think I've found a better solution (borrowed from
> >> http://annocon.sourceforge.net/manual/configurations.html)
> >> I will introduce a generic parser interface which is defined in the
> >> framework
> >> already and which is not xml specific. A configuration can have multiple
> >> registered parsers.
> >> A parser is responsible for the contribution of data to a configuration
> >> which is defined in a textual format (especially file based data).
> >> The SchemaProcessor then is one special parser which can process
> >> inline data from a hivemodule.xml.
> >>
> >> The idea is that the creator of a configuration point says 'ok, here is
> >> a parser
> >> which can read contributions from files' and the provider of a
> >> contribution
> >> just says 'ok, then parse that file please'.
> >>
> >> Pros:
> >> + It solves our 'interface or no interface' dilemma. Since the parser
> >> concept
> >> is available in the framework the hivemodule parser can be easily
> >> attached by the xml module afterwards.
> >> + Configuration data can be defined in external files (xml,
> >> properties etc.)
> >> Either the hivemind parsing is extended so that xml files can be parsed
> >> that adhere to a hivemind schema or alternative parsers (e.g. Digester)
> >> are used.
> >> + Better integration of legacy data files
> >> + Annotated modules can provide parsers easily (see annocon examples).
> >>
> >> What do you think?
> >>
> >> Achim
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>
Re: comments / questions on hivemind 2.0 branch
Posted by Achim Hügen <ac...@gmx.de>.
Knut,
you are right, SchemaProcessor should be a service
and I would even make Schemas available via a SchemaManager
service too.
To make the parser based contribution possible as defined
in the contributeToFactoryConfig method in the example
(http://annocon.sourceforge.net/manual/configurations.html)
we need a connection between configuration point, parser
and schema. Otherwise the contributor would always
have to specify which parser to use and I want to have a default.
Achim
Knut Wannheden schrieb:
> Achim,
>
> Instead of adding a new construct I think it would be cleaner to
> expose the parsers as normal services. The contribution constructor
> would then be given access to the appropriate parser (or any other
> visible service) using the contextual construction parameter. I
> believe this would already work in your branch.
>
> So in the XML HiveMind module we'd expose the SchemaProcessor as a
> service which could be used by contribution constructors.
>
> This also turns out to be how it's solved in Tapestry 5. See 3rd
> example here:
> http://tapestry.apache.org/tapestry5/ioc/configuration.html.
>
> What do you say?
>
> --knut
>
> On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
>> Knut Wannheden schrieb:
>> >
>> > Maybe we could also drop the support for contributing to these
>> > configurations using XML. OK, I know this contradicts what I wrote
>> > about backwards compatibility in the other thread, but maybe that
>> > would be OK. I'd like to point out that Howard changed how the eager
>> > loading works in Tapestry 5 IOC. The ServicePointDef simply has a
>> > boolean getEagerLoad() method. How about that?
>> >
>> I think I've found a better solution (borrowed from
>> http://annocon.sourceforge.net/manual/configurations.html)
>> I will introduce a generic parser interface which is defined in the
>> framework
>> already and which is not xml specific. A configuration can have multiple
>> registered parsers.
>> A parser is responsible for the contribution of data to a configuration
>> which is defined in a textual format (especially file based data).
>> The SchemaProcessor then is one special parser which can process
>> inline data from a hivemodule.xml.
>>
>> The idea is that the creator of a configuration point says 'ok, here is
>> a parser
>> which can read contributions from files' and the provider of a
>> contribution
>> just says 'ok, then parse that file please'.
>>
>> Pros:
>> + It solves our 'interface or no interface' dilemma. Since the parser
>> concept
>> is available in the framework the hivemodule parser can be easily
>> attached by the xml module afterwards.
>> + Configuration data can be defined in external files (xml,
>> properties etc.)
>> Either the hivemind parsing is extended so that xml files can be parsed
>> that adhere to a hivemind schema or alternative parsers (e.g. Digester)
>> are used.
>> + Better integration of legacy data files
>> + Annotated modules can provide parsers easily (see annocon examples).
>>
>> What do you think?
>>
>> Achim
>>
>>
>>
>>
>>
>>
>>
>
>
Re: Re: comments / questions on hivemind 2.0 branch
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
Instead of adding a new construct I think it would be cleaner to
expose the parsers as normal services. The contribution constructor
would then be given access to the appropriate parser (or any other
visible service) using the contextual construction parameter. I
believe this would already work in your branch.
So in the XML HiveMind module we'd expose the SchemaProcessor as a
service which could be used by contribution constructors.
This also turns out to be how it's solved in Tapestry 5. See 3rd
example here: http://tapestry.apache.org/tapestry5/ioc/configuration.html.
What do you say?
--knut
On 11/6/06, Achim Hügen <ac...@gmx.de> wrote:
> Knut Wannheden schrieb:
> >
> > Maybe we could also drop the support for contributing to these
> > configurations using XML. OK, I know this contradicts what I wrote
> > about backwards compatibility in the other thread, but maybe that
> > would be OK. I'd like to point out that Howard changed how the eager
> > loading works in Tapestry 5 IOC. The ServicePointDef simply has a
> > boolean getEagerLoad() method. How about that?
> >
> I think I've found a better solution (borrowed from
> http://annocon.sourceforge.net/manual/configurations.html)
> I will introduce a generic parser interface which is defined in the
> framework
> already and which is not xml specific. A configuration can have multiple
> registered parsers.
> A parser is responsible for the contribution of data to a configuration
> which is defined in a textual format (especially file based data).
> The SchemaProcessor then is one special parser which can process
> inline data from a hivemodule.xml.
>
> The idea is that the creator of a configuration point says 'ok, here is
> a parser
> which can read contributions from files' and the provider of a contribution
> just says 'ok, then parse that file please'.
>
> Pros:
> + It solves our 'interface or no interface' dilemma. Since the parser
> concept
> is available in the framework the hivemodule parser can be easily
> attached by the xml module afterwards.
> + Configuration data can be defined in external files (xml, properties etc.)
> Either the hivemind parsing is extended so that xml files can be parsed
> that adhere to a hivemind schema or alternative parsers (e.g. Digester)
> are used.
> + Better integration of legacy data files
> + Annotated modules can provide parsers easily (see annocon examples).
>
> What do you think?
>
> Achim
>
>
>
>
>
>
>
Re: comments / questions on hivemind 2.0 branch
Posted by Achim Hügen <ac...@gmx.de>.
Knut Wannheden schrieb:
> Achim,
>>
>> to be represented by a xml specific implementation of
>> ConfigurationPointDefinition
>> which is not available in the framework when they get constructed.
>> Natures (or better decorators) solve this problem.
>>
>
> Maybe we could also drop the support for contributing to these
> configurations using XML. OK, I know this contradicts what I wrote
> about backwards compatibility in the other thread, but maybe that
> would be OK. I'd like to point out that Howard changed how the eager
> loading works in Tapestry 5 IOC. The ServicePointDef simply has a
> boolean getEagerLoad() method. How about that?
>
I think I've found a better solution (borrowed from
http://annocon.sourceforge.net/manual/configurations.html)
I will introduce a generic parser interface which is defined in the
framework
already and which is not xml specific. A configuration can have multiple
registered parsers.
A parser is responsible for the contribution of data to a configuration
which is defined in a textual format (especially file based data).
The SchemaProcessor then is one special parser which can process
inline data from a hivemodule.xml.
The idea is that the creator of a configuration point says 'ok, here is
a parser
which can read contributions from files' and the provider of a contribution
just says 'ok, then parse that file please'.
Pros:
+ It solves our 'interface or no interface' dilemma. Since the parser
concept
is available in the framework the hivemodule parser can be easily
attached by the xml module afterwards.
+ Configuration data can be defined in external files (xml, properties etc.)
Either the hivemind parsing is extended so that xml files can be parsed
that adhere to a hivemind schema or alternative parsers (e.g. Digester)
are used.
+ Better integration of legacy data files
+ Annotated modules can provide parsers easily (see annocon examples).
What do you think?
Achim
Re: comments / questions on hivemind 2.0 branch
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
On 11/2/06, Achim Hügen <ac...@gmx.de> wrote:
> Knut Wannheden schrieb:
> >
> > - The ObjectProvider interface is in the XML source module. I believe
> > this should be part of the framework. We might for example also want
> > to use that in the annotation support to inject objects into
> > parameters of methods creating service implementations.
> Yes and no. There might be a use case that justifies putting the
> ObjectProviders
> in the framework but I don't regard annotations as one.
> I wouldn't do anything textual in annotations which could be implemented
> in pure java without any extra work. Let's have a look at the
> current object providers:
> ClassObjectProvider: -> trivial in java code
> ConfigurationObjectProvider -> just call getConfiguration() in an
> annotated module
> ObjectInstanceProvider -> trivial in java code
> ServiceObjectProvider -> just call getService() in an annotated module
> ServicePropertyProvider -> just call getService() and then any getter method
> BeanFactoryProvider -> create the bean manually or call a factory method
>
> For the moment it could stay in the xml module and if needed we could
> move it without breaking compatibility?
>
I must say I still haven't looked at an example of how your annotation
support is used. And maybe I've studied the Tapestry 5 IOC framework
(http://tapestry.apache.org/tapestry5/ioc/index.html) too hard. But
IMHO it looks very good.
You say that you would simply call getService(). Is that method called
on parameter that's always passed or is it an inherited method? This
is solved very cleanly in Tapestry 5 IOC where a module class neither
has to inherit from another class nor are there any special
parameters. Take a look at these pages to see how object providers are
used: http://tapestry.apache.org/tapestry5/ioc/module.html and
http://tapestry.apache.org/tapestry5/ioc/service.html.
Also I've noticed that quite a few of the features users can't find as
out-of-the-box features in HiveMind (just like the one I answered
earlier today on the user list) can often be solved by a custom object
provider. Thus I think these would be really useful to have in the
framework or another module other than xml. Maybe the library.
> > - On the other hand I wonder if instead the SymbolSource classes along
> > with the symbol expansion code should be moved into the XML module.
> > They are used to resolve Ant style ${}-properties in the XML
> > descriptors. Do we want to support these in other module descriptors
> > (e.g. annotation based Java classes) also?
> I regard it as another simple configuration mechanism for an application.
> But there may be better (and even typed) ways to read system properties etc.
> My first attempt to break the deep integration with the registry failed
> but if we decide to move it to xml I could make another try.
>
There are really two separate features we should consider. The symbol
sources on the one hand and the symbol expansion on the other. IMHO we
should at least try to move the symbol expansion into the schema
processing of the xml module.
> > - I noticed the ServiceImplementationFactory is in the xml module.
> > Maybe we could also move the ServiceInterceptorFactory to the xml
> > module. Although I think some of its implementations (really only the
> > LoggingInterceptorFactory) should remain in the framework module which
> > would mean it can't implement the interface anymore. But IMHO that's
> > OK, because the first thing that's done in the implemented interface
> > method is to cast the Object parameter to a List. That could be done
> > by an adapter implementation in the xml module.
> That's exactly how it should be done. I hope we can do it during
> the redesign of the interceptor construction, when createInterceptor
> will return an interceptor object.
OK, glad we find something we can agree on ;-)
> > - Now some comments on the registry construction API. I believe an
> > interface based registry construction API would allow for more
> > flexibility in the implementations. For example you'd have to
> > possibility of refactoring the existing *Descriptor classes in the XML
> > module to implement these interfaces instead of define a mapping. As
> > another example an implementation could chose to have a single object
> > implement two interfaces (e.g. ServicePointDef and ImplementationDef).
> > Further we could then also remove OrderedServiceInterceptorDefinition
> > and simply note that an implementation class can implement the
> > Orderable interface if ordering is required.
> One problem prevented me from conversion to interfaces at all.
> Configurations like ServiceModels, EagerLoad, Startup etc. are defined
> in the core framework. Afterwards they get schemas assigned
> from the xml module. They are a little ambivalent.
> To hold the schema information they would have
> to be represented by a xml specific implementation of
> ConfigurationPointDefinition
> which is not available in the framework when they get constructed.
> Natures (or better decorators) solve this problem.
>
Maybe we could also drop the support for contributing to these
configurations using XML. OK, I know this contradicts what I wrote
about backwards compatibility in the other thread, but maybe that
would be OK. I'd like to point out that Howard changed how the eager
loading works in Tapestry 5 IOC. The ServicePointDef simply has a
boolean getEagerLoad() method. How about that?
> Like you mentioned below only the xml module uses natures in the moment.
> This means on the other hand that all the overhead of the separation
> between interfaces and implementations would be done for that
> single case. Whereas natures doesn't hurt since you are not forced
> to use them.
>
> The definition classes doesn't contain any logic besides consistency
> checking.
> In the meantime I regard it as perfectly valid to use plain beans for them.
> The java/xml/annotation-specific parts are done in the constructors which
> are realized as interfaces.
>
I still quite strongly believe that defining the API as a set of
interfaces would be worth the effort. And as far as natures are
concerned I can see that they can be used for many different things
although they do add some complexity. But as we've already previously
discussed I really think that we should call them adapters instead of
natures. Maybe we should even let all *Def types allow to have
adapters.
> > - Also I think the API could be simplified by removing the distinction
> > between resolved and unresolved extensions. That would make the
> > registry builder responsible for all resolutions.
> During the construction of the registry a complete object graph of
> definition
> items is build up where all unresolved extensions get resolved and placed
> into the referenced extension points. It is quite convenient to use the same
> data structure here that were used for the definition.
> The RegistrySerializer (though far from being usable) uses the graph too.
> Moreover it is convenient and IMHO more intuitive to attach an
> implementation
> defnition directly to an service definition instead of putting it
> unresolved into
> the module.
>
If it always were the case that an extension gets attached to its
definition then I agree that your design is more intuitive. But since
that's not always the case, especially in the case of configuration
contributions, then I think that consistency and simplicity should
outweigh.
Further I don't think we need to provide for much convenience in the
API. For users who'd like to define modules using pure (non annotated)
Java code to define registry constituents we could provide a Java
implementation of the API with all of this convenience built in.
I hope we'll be able to find some common ground and not end up
disagreeing on everything.
Regards,
--knut
Re: comments / questions on hivemind 2.0 branch
Posted by Achim Hügen <ac...@gmx.de>.
Knut Wannheden schrieb:
> Achim,
>
> Browsing the code in your HiveMind 2.0 experimental branch I jotted
> down the following comments / questions:
>
> - The split of the framework and xml sources into separate modules
> looks excellent! It makes the framework quite a bit leaner. I found a
> few sources which I think maybe ended up in the wrong place (see
> following comments).
>
> - The ObjectProvider interface is in the XML source module. I believe
> this should be part of the framework. We might for example also want
> to use that in the annotation support to inject objects into
> parameters of methods creating service implementations.
Yes and no. There might be a use case that justifies putting the
ObjectProviders
in the framework but I don't regard annotations as one.
I wouldn't do anything textual in annotations which could be implemented
in pure java without any extra work. Let's have a look at the
current object providers:
ClassObjectProvider: -> trivial in java code
ConfigurationObjectProvider -> just call getConfiguration() in an
annotated module
ObjectInstanceProvider -> trivial in java code
ServiceObjectProvider -> just call getService() in an annotated module
ServicePropertyProvider -> just call getService() and then any getter method
BeanFactoryProvider -> create the bean manually or call a factory method
For the moment it could stay in the xml module and if needed we could
move it without breaking compatibility?
>
> - On the other hand I wonder if instead the SymbolSource classes along
> with the symbol expansion code should be moved into the XML module.
> They are used to resolve Ant style ${}-properties in the XML
> descriptors. Do we want to support these in other module descriptors
> (e.g. annotation based Java classes) also?
I regard it as another simple configuration mechanism for an application.
But there may be better (and even typed) ways to read system properties etc.
My first attempt to break the deep integration with the registry failed
but if we decide to move it to xml I could make another try.
>
> - I noticed the ServiceImplementationFactory is in the xml module.
> Maybe we could also move the ServiceInterceptorFactory to the xml
> module. Although I think some of its implementations (really only the
> LoggingInterceptorFactory) should remain in the framework module which
> would mean it can't implement the interface anymore. But IMHO that's
> OK, because the first thing that's done in the implemented interface
> method is to cast the Object parameter to a List. That could be done
> by an adapter implementation in the xml module.
That's exactly how it should be done. I hope we can do it during
the redesign of the interceptor construction, when createInterceptor
will return an interceptor object.
>
> - Now some comments on the registry construction API. I believe an
> interface based registry construction API would allow for more
> flexibility in the implementations. For example you'd have to
> possibility of refactoring the existing *Descriptor classes in the XML
> module to implement these interfaces instead of define a mapping. As
> another example an implementation could chose to have a single object
> implement two interfaces (e.g. ServicePointDef and ImplementationDef).
> Further we could then also remove OrderedServiceInterceptorDefinition
> and simply note that an implementation class can implement the
> Orderable interface if ordering is required.
One problem prevented me from conversion to interfaces at all.
Configurations like ServiceModels, EagerLoad, Startup etc. are defined
in the core framework. Afterwards they get schemas assigned
from the xml module. They are a little ambivalent.
To hold the schema information they would have
to be represented by a xml specific implementation of
ConfigurationPointDefinition
which is not available in the framework when they get constructed.
Natures (or better decorators) solve this problem.
Like you mentioned below only the xml module uses natures in the moment.
This means on the other hand that all the overhead of the separation
between interfaces and implementations would be done for that
single case. Whereas natures doesn't hurt since you are not forced
to use them.
The definition classes doesn't contain any logic besides consistency
checking.
In the meantime I regard it as perfectly valid to use plain beans for them.
The java/xml/annotation-specific parts are done in the constructors which
are realized as interfaces.
>
> - Also I think the API could be simplified by removing the distinction
> between resolved and unresolved extensions. That would make the
> registry builder responsible for all resolutions.
During the construction of the registry a complete object graph of
definition
items is build up where all unresolved extensions get resolved and placed
into the referenced extension points. It is quite convenient to use the same
data structure here that were used for the definition.
The RegistrySerializer (though far from being usable) uses the graph too.
Moreover it is convenient and IMHO more intuitive to attach an
implementation
defnition directly to an service definition instead of putting it
unresolved into
the module.
>
> - What do you think about removing the natures from the API? Currently
> it seems like they're used in the XML implementation to get a
> reference to schemas. Maybe the code in the XML module could also just
> typecast to the required implementation and get a reference to the
> schema that way. IMHO the natures are overcomplicating the API.
>
> Regards,
>
> --knut
>
>
Relating to your last posting I'm adding some information to the wiki
currently.
Bye
Achim