I do not use OSGI unfortunately.

The other possibility you describe is more or less exactly what I already
created as a work-around. The main downside to it is that I have to manage
the lifecycle of those properties separately from the Routes themselves
rather than being all bundled together.

On Wed, Apr 4, 2012 at 4:51 PM, Raul Kripalani <r...@fusesource.com> wrote:

> I don't suppose you use OSGi? If you do, you can export each route as
> an OSGi service assigning your own service properties.
>
> Another possibility is to maintain an application-wide singleton
> mimicking a route directory, where you keep a map of route ids and
> route properties. Your route builder would publish all constructed
> routes to this directory, assigning the relevant properties.
>
> Your GC algorithm would then look into this directory to decide which
> ones to prune.
>
> Does that help?
>
> On 4 Apr 2012, at 21:36, Hadrian Zbarcea <hzbar...@gmail.com> wrote:
>
> > Kinda. What about convention over configuration and have the color in
> > the route id (e.g. id="red.something" and if id.startsWith("red.") then
> > garbage collect. Also keep in mind that the RouteBuilder creates just a
> > model, not the route themselves.
> >
> > Hadrian
> >
> > On 04/04/2012 03:53 PM, Jeff Segal wrote:
> >> Sure. I have a system which manages Routes dynamically, which requires
> some
> >> garbage collection to iterate through all Routes in the CamelContext and
> >> remove any which are deemed no longer necessary. For the sake of
> >> discussion, let's say that I wanted to associate a "color" property with
> >> all Routes built by a particular RouteBuilder. Later on, I want the
> garbage
> >> collection algorithm to remove "red" Routes after running for 30 minutes
> >> and leave other Routes alone.
> >>
> >> The easiest way to accomplish that would be to call a method from the
> >> RouteBuilder which adds a "color" property to each Route it creates,
> which
> >> I'd then inspect later on. However, the only method I have available to
> me
> >> is RouteDefinition.setProperty(), which sets properties on the Exchanges
> >> created by the Route, not on the Route itself.
> >>
> >> My current work-around is to maintain my own Route-Properties mapping in
> >> memory.
> >>
> >> Does this make sense?
> >>
> >> On Wed, Apr 4, 2012 at 3:15 PM, Raul Kripalani<r...@fusesource.com>
>  wrote:
> >>
> >>> Hi Jeff,
> >>>
> >>> Could you explain your use case a bit further? It is not clear what you
> >>> ultimately want to achieve.
> >>>
> >>> Regards,
> >>> Raúl.
> >>>
> >>> On 4 April 2012 18:35, Jeff Segal<jeffrey.se...@gmail.com>  wrote:
> >>>
> >>>> Is there any facility to add arbitrary properties to Routes rather
> than
> >>>> just Exchanges from within a RouteBuilder? I noticed that there are a
> few
> >>>> internally managed properties automatically added to each Route (id,
> >>>> parent, group) but I could not find a hook to set additional ones
> from a
> >>>> RouteBuilder.
> >>>>
> >>>> Thanks,
> >>>> Jeff
> >>>>
> >>>
> >>
> >
> > --
> > Hadrian Zbarcea
> > Principal Software Architect
> > Talend, Inc
> > http://coders.talend.com/
> > http://camelbot.blogspot.com/
>

Reply via email to