Re: blueprint:cm multiple bundle but same config file

[Brad Johnson]

David, (for some reason Google was filtering your email address from yahoo
as a phishing attack)

I agree and think that DS and the SCR are great for exposing and importing
services.  In Blueprint I'd use the normal service/reference mechanics in
XML for that but can easily jettison it.  But most of the work I do isn't
involved with inter-bundle service communication.  And even there the
communications can be via Camel endpoints.  The OSGi services I use are
usually for true cross-cutting concerns that wouldn't be remote.

But Camel SCR simply doesn't have a way to use any internal wiring of beans
and routes.  Even when I do expose services via the OSGi registry it might
be for transforming canonical models into specific forms and back again.
So I need to load up Dozer mapping, get a method call, route to the
transform and send the results back with validators and exception handlers
and logging interceptors all along those internal routes.  To the outside
user they are just calling an interface method of FooInventory
convert(InventoryCanonical model)  and all the dependencies, mappings, etc.
remain encapsulated in the bundle that exports that interface.  But there's
a lot of internal wiring.  And that's a relatively simple example.

But Camel SCR doesn't make that really available.

On Mon, Aug 1, 2016 at 7:22 PM, David Jencks  wrote:

> if the declared DS services are non-exported classes in the bundle then
> even though it gets in the service registry it won’t be accessible outside
> the bundle.
> You can also use a non-feature subsystem to restrict visibility to the
> service, but that starts getting complicated pretty rapidly.
> If you are even more ambitions you can use the Region api that is used in
> back of the subsystem implementation or if you are foolhardy you can use
> framework service hooks for the same purpose.
>
> However…. DS is not really intended to be a universal wiring framework for
> everything.  It’s intended to provide a really good way to set up
> configured OSGI services.  Once you start wanting private components I
> start wondering if the component is actually appropriate to be exposed as a
> service.
>
> I would be interested in seeing something like this in xml form with an
> indication of what kind of wiring variability is needed or useful.  I’d
> like to understand how much independent configuration there is, how it
> would be most logically grouped, and how much the wiring could just as well
> be written in java.  I’m wondering about an approach of having basically
> one DS component that gets the configuration(s) and wires up the other
> components somehow.
>
> thanks
> david jencks
>
> On Aug 1, 2016, at 4:33 PM, Matt Sicker  wrote:
>
> Can you even make a semi-private service in DS/SCR? What could the
> equivalent be to a blueprint bean that isn't exported as a service? Or is
> the philosophy to make all services public in DS?
>
> On 1 August 2016 at 18:12, Brad Johnson 
> wrote:
>
>> Tim,
>>
>> After working with DS and SCR a little I can understand its benefits.
>> One obvious advantage was being able to write basic JUnit tests to test my
>> routes without having to fire up CBTS.  I've always disliked working in XML
>> so it is odd being in the position like I sound like I'm the one
>> championing it.
>>
>> The main problem right now with Camel is that while SCR handles all the
>> external items there isn't a way to do any injection of "local"
>> dependencies.  By that I mean within my own bundle I might have validators,
>> handlers, local data models, etc. that I want to stand up and run in my
>> Camel routes.  Camel SCR doesn't have a mechanism for doing that.
>>
>> When one runs it locally in the IDE it fires up a SimpleRegistry and uses
>> that to register everything and in that case you can manually add your own
>> beans before setting up route definitions.  If the bundle is running where
>> it has a bundle context it instead fires up an OsgiServiceRegistry(don't
>> recall the full name.) In that case you can't add your local beans.
>>
>> I noted that there is a CompositeRegistry in the AbstractCamelRunner and
>> perhaps that should always be the one used.  If one boots up and an OSGi
>> service registry is created both it and the SimpleRegistry are added to the
>> CompositeRegistry but one can access the SimpleRegistry in order to add
>> one's local dependencies for Camel routes.
>>
>> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward 
>> wrote:
>>
>>> Hi Brad,
>>>
>>> I’ve been watching this thread for a while, and you’ve finally managed
>>> to draw me in :)
>>>
>>>
>>> On 12 Jul 2016, at 17:42, Brad Johnson 
>>> wrote:
>>>
>>> Guillaume,
>>>
>>> I'm still using Blueprint and have found Camel/SCR to be a pain to work
>>> with.  It provides no tangible benefit if one is using Blueprint for routes
>>> and dependency injection anyway as it 

Re: blueprint:cm multiple bundle but same config file

[Timothy Ward]

This sounds like a good place to use the whiteboard pattern and marker 
properties. Using annotations requires a number of extra steps from the 
Camel/OSGi runtime, where a service property would just require a simple filter 
on the service registry lookup.

Regards,

Tim

On 2 Aug 2016, at 02:44, Matt Sicker 
> wrote:

Can you include scanning services or certain types of annotated services to 
inject camel things into? That way you can use DS components more easily.

On 1 August 2016 at 20:03, Brad Johnson 
> wrote:
The CamelContext disambiguation obviously is a next step...

On Mon, Aug 1, 2016 at 8:01 PM, Brad Johnson 
> wrote:
I'd thought that it was possible since the examples have a SimpleRegistry and 
mention using it to register beans.  But when I looked at the 
AbstractCamelRunner it became obvious that that would not work.

I'm trying something by creating a new SCRRegistry type just  for the sake of 
experimentation.  Internally it has a CompositeRegistry and the 
AbstractCamelRunner which I'm modifying uses the new SCRRegistry which has a 
setter or on it for both a SimpleRegistry and an OsgiRegistry.  If it finds the 
bundle context it creates the OSGi service registry and adds it and in either 
case adds a SimpleRegistry after it.


protected void createCamelContext(final BundleContext bundleContext, final 
Map props) {
if (bundleContext != null) {
OsgiServiceRegistry osgiRegistry = new 
OsgiServiceRegistry(bundleContext);
context = new OsgiDefaultCamelContext(bundleContext, osgiRegistry);
// 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());
this.registry.setOsgiRegistry(osgiRegistry);
}
registry.setSimpleRegistry(new SimpleRegistry());
context = new DefaultCamelContext(registry);



Inside the SCRRegistry it delegates all its Registry interface calls to the 
CompositeRegistry but it keeps a handle on the SimpleRegistry.  So to register 
a class one can do the following:

registry.register(POValidator.class);

In this case it's very simple instantiation of the no-arg constructor and then 
looking for EndpointInject annotations and setting it to the ProducerTemplate 
and the URI it finds.  This is such a quick and naive cut that I'm not even 
checking to see if there's an endpoint by that name in the registry already 
which I could just use instead.  Obviously if I do anything more with this I'll 
look at reusing the existing libraries for annotation processing instead of 
writing this stuff by hand.  I still haven't tested this by throwing it in 
karaf with Felix or any other OSGi implementation.

public void register(Class clazz){
try {
Object o=clazz.newInstance();
for(Field declaredField:clazz.getDeclaredFields())
{
for(EndpointInject endpoint: 
declaredField.getAnnotationsByType(EndpointInject.class))
{
declaredField.setAccessible(true);
ProducerTemplate template = camelContext.createProducerTemplate();
template.setDefaultEndpointUri(endpoint.uri());
declaredField.set(o,template);
}
}
this.simpleRegistry.put(clazz.getSimpleName(), o);
} catch (InstantiationException | IllegalAccessException e) {
//TODO log..
}
}

On Mon, Aug 1, 2016 at 6:33 PM, Matt Sicker 
> wrote:
Can you even make a semi-private service in DS/SCR? What could the equivalent 
be to a blueprint bean that isn't exported as a service? Or is the philosophy 
to make all services public in DS?

On 1 August 2016 at 18:12, Brad Johnson 
> wrote:
Tim,

After working with DS and SCR a little I can understand its benefits.  One 
obvious advantage was being able to write basic JUnit tests to test my routes 
without having to fire up CBTS.  I've always disliked working in XML so it is 
odd being in the position like I sound like I'm the one championing it.

The main problem right now with Camel is that while SCR handles all the 
external items there isn't a way to do any injection of "local" dependencies.  
By that I mean within my own bundle I might have validators, handlers, local 
data models, etc. that I want to stand up and run in my Camel routes.  Camel 
SCR doesn't have a mechanism for doing that.

When one runs it locally in the IDE it fires up a SimpleRegistry and uses that 
to register everything and in that case you can manually add your own beans 
before setting up route definitions.  If the bundle is running where it has a 
bundle context it instead fires up