You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2016/08/01 08:44:44 UTC
Re: Camel SCR
On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
<br...@mediadriver.com> 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
http://camel.apache.org/contributing
> Brad
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel SCR
Posted by Brad Johnson <br...@mediadriver.com>.
One obvious problem with any of this is registry and registry management.
It was easy enough to put in an annotation, proxy the a field/interface to
a ProdcuerTemplate and add the classes to the registry. The problem is
that the AbstractCamelRunner uses two different types of registry and
switches based on contextual information. In the example given it is
suggested that one pass the registry into one's route builders as follows
in order to add beans. The problem is that the SimpleRegistry is used only
when the SCR isn't running in an OSGi container.
public CamelScrExampleRoute(final SimpleRegistry registry) {
this.registry = registry;
}
Here's the actual createCamelContext from the abstract camel runner. If it
finds a bundleContext it sets up an OsgiServiceRegistry with the context
otherwise it sets up a SimpleRegistry. I haven't actually tried throwing
my code into a karaf container to see if it would work but I can't imagine
it would since I'm using the SimpleRegistry as recommended in the
documentation and that shouldn't cast. And the plain Registry interface
only lets me do the look ups and not add beans.
protected void createCamelContext(final BundleContext bundleContext,
final Map<String, String> props) {
if (bundleContext != null) {
registry = new OsgiServiceRegistry(bundleContext);
context = new OsgiDefaultCamelContext(bundleContext, registry);
// Setup the application context classloader with the bundle
classloader
context.setApplicationContextClassLoader(new
BundleDelegatingClassLoader(bundleContext.getBundle()));
// and make sure the TCCL is our classloader
Thread.currentThread().setContextClassLoader(context.getApplicationContextClassLoader());
} else {
registry = new SimpleRegistry();
context = new DefaultCamelContext(registry);
}
setupPropertiesComponent(context, props, log);
}
On Mon, Aug 1, 2016 at 9:38 AM, Brad Johnson <br...@mediadriver.com>
wrote:
> Obviously I didn't mean creating new annotations for everything but for
> some of the items that were originally developed for Spring scanners.
> @Produce, @Consume, @EndpointInject and so on.
> When using Blueprint I ran into problems with using some of the
> annotations. I can't recall which right now.
>
> There are only two concerns I can really think of in terms of reuse of
> existing annotations. The first is if the annotations are in a bundle like
> Spring or other technology which wouldn't be included as a dependency
> otherwise. Obviously pulling in a dependency like that just to get the
> annotations would be silly.
>
> The second concern is behavioral expectations. If one uses the @Produce,
> @Consume, @BeanInject or @EndpointInject annotations there are expectations
> of how those will work based on existing technologies. One example that
> comes to me off the top of my head is if I were to create an injection
> would I do:
>
> @EndpointInject(uri = "direct:inbound")
> Endpoint endpoint;
>
> or
> @Inject
> @Uri("direct:inbound")
> Endpoint endpoint;
>
> I'd guess that the CDI version would be newer and preferable.
>
> Brad
>
>
> On Mon, Aug 1, 2016 at 9:03 AM, Matt Sicker <bo...@gmail.com> wrote:
>
>> It would definitely make sense to reuse the existing annotations. If a
>> user
>> can migrate from Blueprint to DS/SCR relatively easily, that would
>> definitely help in adoption.
>>
>> On 1 August 2016 at 09:01, Claus Ibsen <cl...@gmail.com> wrote:
>>
>> > On Mon, Aug 1, 2016 at 3:56 PM, Brad Johnson
>> > <br...@mediadriver.com> wrote:
>> > > 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());
>> > > scrRegistry.register(MyValidator.class);
>> > > scrRegistry.register(MyFileNameValidator.class);
>> > >
>> > > }
>> > >
>> > > 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))
>> > > {
>> > > declaredField.setAccessible(true);
>> > >
>> >
>> declaredField.set(o,CamelProxyFactory.createProducer(declaredField.getType(),
>> > > 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.
>> > >
>> >
>> > Yes
>> >
>> > > I'm wondering if it would make sense to reuse existing annotations or
>> > > create new ones.
>> > >
>> >
>> > We for sure do NOT want new annotations. Whatever IoC mehanism in osgi
>> > SCR is outside the scope of Apache Camel. Ideally you should use
>> > exisiting such as Blueprint or CDI on OSGi. Not re-invent something
>> > special. Or get in touch with Apache Felix folks and talk about IoC
>> > framework for SCR.
>> >
>> >
>> >
>> > > Brad
>> > >
>> > > On Mon, Aug 1, 2016 at 3:44 AM, Claus Ibsen <cl...@gmail.com>
>> > wrote:
>> > >
>> > >> On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
>> > >> <br...@mediadriver.com> 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
>> > >> http://camel.apache.org/contributing
>> > >>
>> > >>
>> > >> > Brad
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Claus Ibsen
>> > >> -----------------
>> > >> http://davsclaus.com @davsclaus
>> > >> Camel in Action 2: https://www.manning.com/ibsen2
>> > >>
>> >
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -----------------
>> > http://davsclaus.com @davsclaus
>> > Camel in Action 2: https://www.manning.com/ibsen2
>> >
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
Re: Camel SCR
Posted by Brad Johnson <br...@mediadriver.com>.
Obviously I didn't mean creating new annotations for everything but for
some of the items that were originally developed for Spring scanners.
@Produce, @Consume, @EndpointInject and so on.
When using Blueprint I ran into problems with using some of the
annotations. I can't recall which right now.
There are only two concerns I can really think of in terms of reuse of
existing annotations. The first is if the annotations are in a bundle like
Spring or other technology which wouldn't be included as a dependency
otherwise. Obviously pulling in a dependency like that just to get the
annotations would be silly.
The second concern is behavioral expectations. If one uses the @Produce,
@Consume, @BeanInject or @EndpointInject annotations there are expectations
of how those will work based on existing technologies. One example that
comes to me off the top of my head is if I were to create an injection
would I do:
@EndpointInject(uri = "direct:inbound")
Endpoint endpoint;
or
@Inject
@Uri("direct:inbound")
Endpoint endpoint;
I'd guess that the CDI version would be newer and preferable.
Brad
On Mon, Aug 1, 2016 at 9:03 AM, Matt Sicker <bo...@gmail.com> wrote:
> It would definitely make sense to reuse the existing annotations. If a user
> can migrate from Blueprint to DS/SCR relatively easily, that would
> definitely help in adoption.
>
> On 1 August 2016 at 09:01, Claus Ibsen <cl...@gmail.com> wrote:
>
> > On Mon, Aug 1, 2016 at 3:56 PM, Brad Johnson
> > <br...@mediadriver.com> wrote:
> > > 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());
> > > scrRegistry.register(MyValidator.class);
> > > scrRegistry.register(MyFileNameValidator.class);
> > >
> > > }
> > >
> > > 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))
> > > {
> > > declaredField.setAccessible(true);
> > >
> >
> declaredField.set(o,CamelProxyFactory.createProducer(declaredField.getType(),
> > > 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.
> > >
> >
> > Yes
> >
> > > I'm wondering if it would make sense to reuse existing annotations or
> > > create new ones.
> > >
> >
> > We for sure do NOT want new annotations. Whatever IoC mehanism in osgi
> > SCR is outside the scope of Apache Camel. Ideally you should use
> > exisiting such as Blueprint or CDI on OSGi. Not re-invent something
> > special. Or get in touch with Apache Felix folks and talk about IoC
> > framework for SCR.
> >
> >
> >
> > > Brad
> > >
> > > On Mon, Aug 1, 2016 at 3:44 AM, Claus Ibsen <cl...@gmail.com>
> > wrote:
> > >
> > >> On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
> > >> <br...@mediadriver.com> 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
> > >> http://camel.apache.org/contributing
> > >>
> > >>
> > >> > Brad
> > >>
> > >>
> > >>
> > >> --
> > >> Claus Ibsen
> > >> -----------------
> > >> http://davsclaus.com @davsclaus
> > >> Camel in Action 2: https://www.manning.com/ibsen2
> > >>
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Camel SCR
Posted by Matt Sicker <bo...@gmail.com>.
It would definitely make sense to reuse the existing annotations. If a user
can migrate from Blueprint to DS/SCR relatively easily, that would
definitely help in adoption.
On 1 August 2016 at 09:01, Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Aug 1, 2016 at 3:56 PM, Brad Johnson
> <br...@mediadriver.com> wrote:
> > 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());
> > scrRegistry.register(MyValidator.class);
> > scrRegistry.register(MyFileNameValidator.class);
> >
> > }
> >
> > 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))
> > {
> > declaredField.setAccessible(true);
> >
> declaredField.set(o,CamelProxyFactory.createProducer(declaredField.getType(),
> > 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.
> >
>
> Yes
>
> > I'm wondering if it would make sense to reuse existing annotations or
> > create new ones.
> >
>
> We for sure do NOT want new annotations. Whatever IoC mehanism in osgi
> SCR is outside the scope of Apache Camel. Ideally you should use
> exisiting such as Blueprint or CDI on OSGi. Not re-invent something
> special. Or get in touch with Apache Felix folks and talk about IoC
> framework for SCR.
>
>
>
> > Brad
> >
> > On Mon, Aug 1, 2016 at 3:44 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> >> On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
> >> <br...@mediadriver.com> 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
> >> http://camel.apache.org/contributing
> >>
> >>
> >> > Brad
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Matt Sicker <bo...@gmail.com>
Re: Camel SCR
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Aug 1, 2016 at 3:56 PM, Brad Johnson
<br...@mediadriver.com> wrote:
> 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());
> scrRegistry.register(MyValidator.class);
> scrRegistry.register(MyFileNameValidator.class);
>
> }
>
> 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))
> {
> declaredField.setAccessible(true);
> declaredField.set(o,CamelProxyFactory.createProducer(declaredField.getType(),
> 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.
>
Yes
> I'm wondering if it would make sense to reuse existing annotations or
> create new ones.
>
We for sure do NOT want new annotations. Whatever IoC mehanism in osgi
SCR is outside the scope of Apache Camel. Ideally you should use
exisiting such as Blueprint or CDI on OSGi. Not re-invent something
special. Or get in touch with Apache Felix folks and talk about IoC
framework for SCR.
> Brad
>
> On Mon, Aug 1, 2016 at 3:44 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
>> <br...@mediadriver.com> 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
>> http://camel.apache.org/contributing
>>
>>
>> > Brad
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel SCR
Posted by Brad Johnson <br...@mediadriver.com>.
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());
scrRegistry.register(MyValidator.class);
scrRegistry.register(MyFileNameValidator.class);
}
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))
{
declaredField.setAccessible(true);
declaredField.set(o,CamelProxyFactory.createProducer(declaredField.getType(),
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.
Brad
On Mon, Aug 1, 2016 at 3:44 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
> <br...@mediadriver.com> 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
> http://camel.apache.org/contributing
>
>
> > Brad
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>