Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.161.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=oi/MpZLrXxRZAgntxLL580oVtHPNGh6j1frHsW2kIJhhNa1PMSRi6TEEg6XIB36uPZ
         1qNwn9waBFZvqe4FEkidcjqG6P2Y8v9F3YlJrPbm4Mlhq8nrMIPcTKEiJPaCe7U3FHAG
         mg0UDPOabs563EmSSAmFAOwLjcqMs3lam3YoM=
MIME-Version: 1.0
In-Reply-To: <1278342030618-696567.post@n5.nabble.com>
References: <1278342030618-696567.post@n5.nabble.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Mon, 5 Jul 2010 17:31:36 +0200
Message-ID: <AANLkTiny4cmC5Fhbc8dajU_QyfPyWOw_GTSndZya-fbH@mail.gmail.com>
Subject: Re: Using Policy to alter Definitions before building
To: users@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi

Have you looked at org.apache.camel.spi.InterceptStrategy?


On Mon, Jul 5, 2010 at 5:00 PM, Mark Proctor <mproctor@codehaus.org> wrote:
>
> As well as using Policy to wrap the child processors, I'd like to be able=
 to
> change/augment the child definitions before they are built. My current us=
e
> case for this is so I can augment the DataFormats, with additional
> configurations. Additionally this Policy also takes care of setting the
> current context ClassLoader, but that already works fine with the existin=
g
> Policy wrap api.
>
> API comptability is a problem, but as a sketch to what I'm trying to
> achieve, here is a change that while a little clunky (due api compatabili=
ty)
> should achieve the job. This allows the wrap to still call the child
> Process, via the delegate, but to also inspect and change the child
> Definitions prior to building.
>
> public interface DefinitionAwarePolicy extends Policy {
> =A0 =A0Processor wrap(RouteContext routeContext,
> ProcessorDefinition<ProcessorDefinition> processorDefinition, Processor
> processor);
> }
>
> PolicyDefinition.
> =A0 =A0public Processor createProcessor(RouteContext routeContext) throws
> Exception {
> =A0 =A0 =A0 =A0DelegateProcessor childProcessor =3D new DelegateProcessor=
();
>
> =A0 =A0 =A0 =A0Policy policy =3D resolvePolicy(routeContext);
> =A0 =A0 =A0 =A0ObjectHelper.notNull(policy, "policy", this);
> =A0 =A0 =A0 =A0Processor target;
> =A0 =A0 =A0 =A0if ( policy instanceof Policy ) {
> =A0 =A0 =A0 =A0 =A0 =A0target =3D policy.wrap(routeContext, childProcesso=
r);
> =A0 =A0 =A0 =A0} else {
> =A0 =A0 =A0 =A0 =A0 =A0target =3D ((DefinitionAwarePolicy)policy).wrap(ro=
uteContext,
> this, childProcessor);
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0childProcessor.setProcessor( this.createChildProcessor(rou=
teContext,
> true) );
>
> =A0 =A0 =A0 =A0// wrap the target so it becomes a service and we can mana=
ge its
> lifecycle
> =A0 =A0 =A0 =A0WrapProcessor wrap =3D new WrapProcessor(target, childProc=
essor);
> =A0 =A0 =A0 =A0return wrap;
> =A0 =A0}
> --
> View this message in context: http://camel.465427.n5.nabble.com/Using-Pol=
icy-to-alter-Definitions-before-building-tp696567p696567.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>


--=20
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus