Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of bardweller@gmail.com
 designates 74.125.78.147 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=lwmKDHqphLHrBtlrWA4OBnMroL7Ej54hXoCISnEXu+X/7VEjirHVx14i9U2JIfRIzR
         V3n9YWn8zzZrNFt4nF315WtoAcpSusZ+dYjhdotf7qxD/qrJDvyoH4e/ivLLvyYAMBFt
         xtOxLHu9K8Ee4zWwNxqme+LMWt7kkiy3klahs=
MIME-Version: 1.0
In-Reply-To: <b23ecedc0911030127p3afbb67cg66627df53452fced@mail.gmail.com>
References: <b23ecedc0911030127p3afbb67cg66627df53452fced@mail.gmail.com>
Date: Tue, 3 Nov 2009 20:30:44 +0000
Message-ID: <ec2fe6dd0911031230j6f2abf67ve986dafcdd403906@mail.gmail.com>
Subject: Re: [blueprint] Custom namespace handlers and registration of
	metadata
From: The Dweller <bardweller@gmail.com>
To: aries-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e6d975e15909fa04777d5e11

--0016e6d975e15909fa04777d5e11
Content-Type: text/plain; charset=ISO-8859-1

Hmm.. not too sure how you'd get to the ComponentDefintionRegistry during a
BeanProcessor before/after init call... the before/after calls do get passed
a reference to the current bean metadata though..

I'd figure that metadata passed to before/after init should be treated as
readonly.. since the metadata is accompanied by an instance of the bean
created from it, it would be strange to allow changes to it there. Although
we don't prevent that today either !

I'd guess the most likely way to do what you're describing would be to have
the NamespaceHandler save a reference to the CompDefReg into something it
registers as a BeanProcessor.. all feels a bit messy, and overall I think
I'd agree we probably dont want to be allowing modification of the registry
once we declare the parse phase complete. The comp def processor appears to
have to jump through some entertaining hoops to allow it's modifications to
take effect, and this would feel similar.

Regards,
Ozzy

On Tue, Nov 3, 2009 at 9:27 AM, Guillaume Nodet <gnodet@gmail.com> wrote:

> I'm working on blueprint support for Apache Camel these days and came
> across the following use case.
> I have a custom namespace handler for camel which is able to create
> camel routes.  Those camel routes depends on camel components.  What
> I'm trying to do is use the OSGi registry to host those components and
> leverage blueprint support for OSGi services, especially the grace
> period.  This means that the namespace handler would have to add a few
> dependencies on the main bean, each of those dependencies being a
> reference to a camel component from the OSGi registry.
> So far so good.
> Now the problem is that, given the way camel works, the required
> components can only be found when the routes are created.  I'd like to
> keep this creation done when the camel context bean is created by the
> blueprint container instead of having the custom namespace handler do
> the instanciation and introspect the routes for components.  This
> should be doable using the BeanProcessor#afterInit() method.  The
> problem is, what should happen if we add additional metadata at this
> stage ?
> Currently, nothing is done, which means it may leave the blueprint
> container in an inconsistent state.  So we need to choose one way:
> either registration of metadata using
> ComponentDefinitionRegistry#registerComponentDefinition() can only be
> done at parsing time or we want to allow it later at runtime.  The
> later is obvisouly much more complicated.
> For this very use case, I could do without that by instanciating the
> camel context at parsing time, introspect it, and add the needed
> service references, so that's not a big deal, but i still think we
> need to agree on this issue and enhance the code to either fully
> support or reject that.
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>

--0016e6d975e15909fa04777d5e11--