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 <claus.ib...@gmail.com> wrote:
> On Mon, Aug 1, 2016 at 3:56 PM, Brad Johnson
> <brad.john...@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 <claus.ib...@gmail.com>
> wrote:
> >
> >> On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
> >> <brad.john...@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 <boa...@gmail.com>
