Return-Path: 
 <dev-return-2687-apmail-hivemind-dev-archive=hivemind.apache.org@hivemind.apache.org>
Delivered-To: apmail-hivemind-dev-archive@www.apache.org
Received: (qmail 11891 invoked from network); 7 Nov 2006 05:20:56 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 7 Nov 2006 05:20:56 -0000
Received: (qmail 92172 invoked by uid 500); 7 Nov 2006 05:21:07 -0000
Delivered-To: apmail-hivemind-dev-archive@hivemind.apache.org
Received: (qmail 92158 invoked by uid 500); 7 Nov 2006 05:21:07 -0000
Mailing-List: contact dev-help@hivemind.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hivemind.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hivemind.apache.org>
List-Post: <mailto:dev@hivemind.apache.org>
List-Id: <dev.hivemind.apache.org>
Reply-To: dev@hivemind.apache.org
Delivered-To: mailing list dev@hivemind.apache.org
Received: (qmail 92148 invoked by uid 99); 7 Nov 2006 05:21:07 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Nov 2006 21:21:07 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of knut.wannheden@gmail.com
 designates 64.233.182.184 as permitted sender)
Received: from [64.233.182.184] (HELO nf-out-0910.google.com) (64.233.182.184)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Nov 2006 21:20:53 -0800
Received: by nf-out-0910.google.com with SMTP id c29so66031nfb
        for <dev@hivemind.apache.org>; Mon, 06 Nov 2006 21:20:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=j50oC6fvXYxFvCYyWkKsRaSq9lIsX3abhUqMwQ3eC6+kqRMcmkn5fpdCsTJzIvb9rSYcgm8vX5L+WSpJnHY3WOmeOXJ7dWYtMS+iJl7xrGbqtTp6G/dpen/sH1BDtQ8Ab/B8ElhoaxEAXW+qebxTmuZyLLkEReTaeddi5FzInx8=
Received: by 10.78.158.11 with SMTP id g11mr7771549hue.1162876830622;
        Mon, 06 Nov 2006 21:20:30 -0800 (PST)
Received: by 10.78.184.3 with HTTP; Mon, 6 Nov 2006 21:20:30 -0800 (PST)
Message-ID: <360173eb0611062120v5ea44629le0de90a29d0c18a1@mail.gmail.com>
Date: Tue, 7 Nov 2006 06:20:30 +0100
From: "Knut Wannheden" <knut.wannheden@gmail.com>
To: dev@hivemind.apache.org
Subject: Re: comments / questions on hivemind 2.0 branch
In-Reply-To: <eb4296c40611061126r4a5b9191w7599a6b13fc14a0c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <360173eb0611020118q73b9822bm4fc5b58524788696@mail.gmail.com>
	 <4549EBC2.8030001@gmx.de>
	 <360173eb0611020607m1e2c0088v3abd49960be28926@mail.gmail.com>
	 <454F024C.9060506@gmx.de>
	 <360173eb0611060259rcc42e0are5aa052c9cbd0e5a@mail.gmail.com>
	 <454F68AE.2040707@gmx.de>
	 <360173eb0611061048j693ccb25wb0b31d6e26af44c9@mail.gmail.com>
	 <eb4296c40611061126r4a5b9191w7599a6b13fc14a0c@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

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=FCgen <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 constructo=
r
> > > > 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=FCgen <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 wro=
te
> > > >> > about backwards compatibility in the other thread, but maybe tha=
t
> > > >> > would be OK. I'd like to point out that Howard changed how the e=
ager
> > > >> > 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 th=
e
> > > >> framework
> > > >> already and which is not xml specific. A configuration can have mu=
ltiple
> > > >> registered parsers.
> > > >> A parser is responsible for the contribution of data to a configur=
ation
> > > >> 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, he=
re 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 par=
ser
> > > >> concept
> > > >>   is available in the framework the hivemodule parser can be easil=
y
> > > >>   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 p=
arsed
> > > >> that adhere to a hivemind schema or alternative parsers (e.g. Dige=
ster)
> > > >> are used.
> > > >> + Better integration of legacy data files
> > > >> + Annotated modules can provide parsers easily (see annocon exampl=
es).
> > > >>
> > > >> What do you think?
> > > >>
> > > >> Achim
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> >
>