camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Johnson <>
Subject Re: Camel SCR
Date Mon, 01 Aug 2016 13:56:18 GMT
I figured that was probably the case so started work on something this week
end.  Contributing that sort of thing is possible.  I'm not sure if the way
that Spring did it is exactly the way I'd do it if writing it from
scratch.  The first shot at it in a couple of hours time created a
constrained version.

>From the SCR component which extends AbstractCamelRunner I added a method
called initBeans.

private void initBeans() {

SimpleRegistry sRegistry = (SimpleRegistry) registry;
SCRRegistry scrRegistry = new SCRRegistry(sRegistry, getContext());


The SCRRegistry just instantiates the classes passed in and then looks for
an @To annotation.  I didn't want to reuse the existing annotations because
I was not sure if that would be a good idea or not.  The registry looks at
the fields on the classes and does this:

for(To to: declaredField.getAnnotationsByType(To.class))
camelContext, to.uri()));

The @To annotation has a uri field so it's very similar to what the
@Produce does.

However, after I finished it and sat back to see what to do next I started
thinking that maybe this isn't the way I'd do it if I were doing it from
scratch.  What I mean is that maybe it makes more sense to put the @To
annotations on the interface methods themselves.  Then instead of having
the class that uses that interface specify the @To and URI it would specify
@Bean or @EventSource or something else.  The SCRRegistry would then look
to see if that interface had already been created and proxied.  If so it
just sets it on the field.  If not it creates a new one, sets up producers
for each of the @To methods and puts them in a map in the invocation
handler, and then puts the proxied interface into the registry.

Perhaps I should address this on the dev email.

I'm wondering if it would make sense to reuse existing annotations or
create new ones.


On Mon, Aug 1, 2016 at 3:44 AM, Claus Ibsen <> wrote:

> On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
> <> wrote:
> > I've started experimenting with SCR some. One item I'm curious about is
> if
> > there are any annotations or mechanics available for using the Camel
> proxy
> > or other mechanics like @EndpointInject, @Produce, @Consume.
> >
> > The use of the @Produce annotation with uri is quite convenient for
> making
> > external connections.  As an example, I have validator that I use in a
> > filter for go/no go in processing.  In that validator when it fails I
> use a
> > producer template to send a message to a route the fires off an email.
> > With the @Produce that is even simpler because the interface is very
> > explicit about what it is and what it is for yet remains nicely
> decoupled.
> >
> > I'm sure I can make my own factory to create such producers.  But I'm
> > wondering if (a) does it exist currently and (b) are there any plans to
> add
> > it?  Obviously I'm not using Blueprint, Spring or Guice so those
> libraries
> > aren't available in this context.
> >
> Does not exists, and there is no plan.
> Community users would need to dive into this themselves and look what
> is possible.
> We love contributions
> > Brad
> --
> Claus Ibsen
> -----------------
> @davsclaus
> Camel in Action 2:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message