hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: comments / questions on hivemind 2.0 branch
Date Tue, 07 Nov 2006 12:52:45 GMT
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 <james@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 <james@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 <achim.huegen@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
> > > <knut.wannheden@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 <james@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 <knut.wannheden@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 <achim.huegen@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 <achim.huegen@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
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> > >
> > >
> >
>

Mime
View raw message