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 <boa...@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 <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>
>
