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 <[email protected]>
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 <[email protected]> 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 <[email protected]> wrote:
>>
>> > On Mon, Aug 1, 2016 at 3:56 PM, Brad Johnson
>> > <[email protected]> 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 <[email protected]>
>> > wrote:
>> > >
>> > >> On Sun, Jul 31, 2016 at 6:01 AM, Brad Johnson
>> > >> <[email protected]> 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 <[email protected]>
>>
>
>
