[HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15

[Claus Ibsen <cl...@gmail.com>]

Hi

There is a great contribution for a new camel-scr module that allows
end users to use OSGi declarative services instead of spring-dm /
blueprint.

The code has just been pushed to master branch, but there is still
some work to finish and polish the code.

But I wanted to bring this to attention, so we can have more eyes on
this - especially for the OSGi folks.

The JIRA ticket is, with some bullets to look at:
https://issues.apache.org/jira/browse/CAMEL-7997

And the code is in the camel-scr module. And there is a camel-scr
feature to install the module.





-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/

Re: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15

[Christian Schneider <ch...@die-schneider.net>]

The OSGi way to specify the need for a component would be a requirement 
and the component would offer a capability.
See http://wiki.osgi.org/wiki/Provide-Capability

On the component side it should be easy to add this.

On the client side the question is if people want to do this by hand ... 
probably not. Maybe we could simply create a maven plugin that scans the 
classpath for components and creates the require statements in the Manifest.
This might be even better than special annotations.

The nice thing with capabilities and requirements is that OSGi is aware 
of them. So the framework will make sure the bundle only resolves once 
the capability is present. It also works with OSGi repositories that 
then can automatically select matching bundles for a requirement.

Still we would probably need to wait for the service for a short time. 
As far as I know the installation of the component bundle does not 
directly create the service.

In any case I think it makes sense to solve this once and independent 
from blueprint. So future adapters like camel-scr will become easier to 
do. I will dig into this. Btw. if you are at apachecon next week we 
maybe can talk about this in person.

Christian

On 11.11.2014 07:54, Claus Ibsen wrote:
> Hi
>
> Christian sounds good if you have the time and willingness to dive
> into improving the camel-scr code.
>
> In camel-blueprint / camel-core-osgi is some code that gathers all the
> component names, data formats, and languages that are define in the
> Camel routes. And then use that to reference as the needed osgi
> services. And hence why camel-blueprint apps can go into grace period
> waiting for bundles to be installed with the needed Camel components.
>
> Not sure how easy that work would be to do with routes define in Java
> code. Though they build up the same model, so its likely doable.
>
> Though at first we could instead just fail fast. And therefore require
> all the needed bundles to be installed first. Then we can look into
> this "grace period" work later.
>
> Though we could also as you say introduce a set of annotations where
> people specify the needed components. Or maybe there is a OSGi way to
> define that in the MANIFEST.MF file? Though annotations is maybe
> easier for end users?
>
> Though at first I think cleanup of the code is needed and making the
> sample code simpler etc as you also say.
>
>
>
> On Mon, Nov 10, 2014 at 10:17 AM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> I just looked into the camel-scr component.
>>
>> If found some design issues:
>>
>> - Why do we need to @Reference to ComponentResolver. I think we should do
>> this under the covers so the user does not have to configure it himself.
>> The easiest way would probably be to do this using plain OSGi APIs.
>>
>> - It seems the context start is delayed when additional components are
>> found. This seems to be a bit fragile as the delay means we can miss
>> components.
>> In the case of camel blueprint we go into GracePeriod and specify which
>> component we are missing. For SCR I think the correct way would be to only
>> start after all required components are present. Not sure if this is easy to
>> do though. In any case I think the problem of depending on components and
>> only starting once they are there is a general problem that should be solved
>> outside camel blueprint or camel scr.
>>
>> - If component auto detection does not work we could create a custom camel
>> annotation @RequiresComponent("<component name>") and @RequiresCompoents. So
>> people could annotate their concrete context class with all components they
>> need.
>>
>> - I think the direct injection of properties into RouteBuilders should not
>> be done. Or at least not by default. Instead I would by default let the user
>> do the injection in getRouteBuilders. At least we could use the @Inject
>> annotation to mark properties that are meant for injection perhaps even with
>> @Named so the user can specify the name.
>>
>> I can help with implementing some of my proposals. I will wait for more
>> comments and discussions though.
>>
>> Christian
>>
>>
>> On 09.11.2014 09:42, Claus Ibsen wrote:
>>> Hi
>>>
>>> There is a great contribution for a new camel-scr module that allows
>>> end users to use OSGi declarative services instead of spring-dm /
>>> blueprint.
>>>
>>> The code has just been pushed to master branch, but there is still
>>> some work to finish and polish the code.
>>>
>>> But I wanted to bring this to attention, so we can have more eyes on
>>> this - especially for the OSGi folks.
>>>
>>> The JIRA ticket is, with some bullets to look at:
>>> https://issues.apache.org/jira/browse/CAMEL-7997
>>>
>>> And the code is in the camel-scr module. And there is a camel-scr
>>> feature to install the module.
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15

[Claus Ibsen <cl...@gmail.com>]

Hi

Christian sounds good if you have the time and willingness to dive
into improving the camel-scr code.

In camel-blueprint / camel-core-osgi is some code that gathers all the
component names, data formats, and languages that are define in the
Camel routes. And then use that to reference as the needed osgi
services. And hence why camel-blueprint apps can go into grace period
waiting for bundles to be installed with the needed Camel components.

Not sure how easy that work would be to do with routes define in Java
code. Though they build up the same model, so its likely doable.

Though at first we could instead just fail fast. And therefore require
all the needed bundles to be installed first. Then we can look into
this "grace period" work later.

Though we could also as you say introduce a set of annotations where
people specify the needed components. Or maybe there is a OSGi way to
define that in the MANIFEST.MF file? Though annotations is maybe
easier for end users?

Though at first I think cleanup of the code is needed and making the
sample code simpler etc as you also say.



On Mon, Nov 10, 2014 at 10:17 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I just looked into the camel-scr component.
>
> If found some design issues:
>
> - Why do we need to @Reference to ComponentResolver. I think we should do
> this under the covers so the user does not have to configure it himself.
> The easiest way would probably be to do this using plain OSGi APIs.
>
> - It seems the context start is delayed when additional components are
> found. This seems to be a bit fragile as the delay means we can miss
> components.
> In the case of camel blueprint we go into GracePeriod and specify which
> component we are missing. For SCR I think the correct way would be to only
> start after all required components are present. Not sure if this is easy to
> do though. In any case I think the problem of depending on components and
> only starting once they are there is a general problem that should be solved
> outside camel blueprint or camel scr.
>
> - If component auto detection does not work we could create a custom camel
> annotation @RequiresComponent("<component name>") and @RequiresCompoents. So
> people could annotate their concrete context class with all components they
> need.
>
> - I think the direct injection of properties into RouteBuilders should not
> be done. Or at least not by default. Instead I would by default let the user
> do the injection in getRouteBuilders. At least we could use the @Inject
> annotation to mark properties that are meant for injection perhaps even with
> @Named so the user can specify the name.
>
> I can help with implementing some of my proposals. I will wait for more
> comments and discussions though.
>
> Christian
>
>
> On 09.11.2014 09:42, Claus Ibsen wrote:
>>
>> Hi
>>
>> There is a great contribution for a new camel-scr module that allows
>> end users to use OSGi declarative services instead of spring-dm /
>> blueprint.
>>
>> The code has just been pushed to master branch, but there is still
>> some work to finish and polish the code.
>>
>> But I wanted to bring this to attention, so we can have more eyes on
>> this - especially for the OSGi folks.
>>
>> The JIRA ticket is, with some bullets to look at:
>> https://issues.apache.org/jira/browse/CAMEL-7997
>>
>> And the code is in the camel-scr module. And there is a camel-scr
>> feature to install the module.
>>
>>
>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/

Re: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15

[Christian Schneider <ch...@die-schneider.net>]

I just looked into the camel-scr component.

If found some design issues:

- Why do we need to @Reference to ComponentResolver. I think we should 
do this under the covers so the user does not have to configure it himself.
The easiest way would probably be to do this using plain OSGi APIs.

- It seems the context start is delayed when additional components are 
found. This seems to be a bit fragile as the delay means we can miss 
components.
In the case of camel blueprint we go into GracePeriod and specify which 
component we are missing. For SCR I think the correct way would be to 
only start after all required components are present. Not sure if this 
is easy to do though. In any case I think the problem of depending on 
components and only starting once they are there is a general problem 
that should be solved outside camel blueprint or camel scr.

- If component auto detection does not work we could create a custom 
camel annotation @RequiresComponent("<component name>") and 
@RequiresCompoents. So people could annotate their concrete context 
class with all components they need.

- I think the direct injection of properties into RouteBuilders should 
not be done. Or at least not by default. Instead I would by default let 
the user do the injection in getRouteBuilders. At least we could use the 
@Inject annotation to mark properties that are meant for injection 
perhaps even with @Named so the user can specify the name.

I can help with implementing some of my proposals. I will wait for more 
comments and discussions though.

Christian


On 09.11.2014 09:42, Claus Ibsen wrote:
> Hi
>
> There is a great contribution for a new camel-scr module that allows
> end users to use OSGi declarative services instead of spring-dm /
> blueprint.
>
> The code has just been pushed to master branch, but there is still
> some work to finish and polish the code.
>
> But I wanted to bring this to attention, so we can have more eyes on
> this - especially for the OSGi folks.
>
> The JIRA ticket is, with some bullets to look at:
> https://issues.apache.org/jira/browse/CAMEL-7997
>
> And the code is in the camel-scr module. And there is a camel-scr
> feature to install the module.
>
>
>
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15

[Claus Ibsen <cl...@gmail.com>]

Hi

Just a note that Jyrki did some more code contributions, so I have
just pushed his latest changes to the master branch.

Its this PR which has a summary of changes
https://github.com/apache/camel/pull/329

On Sun, Nov 9, 2014 at 9:42 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> There is a great contribution for a new camel-scr module that allows
> end users to use OSGi declarative services instead of spring-dm /
> blueprint.
>
> The code has just been pushed to master branch, but there is still
> some work to finish and polish the code.
>
> But I wanted to bring this to attention, so we can have more eyes on
> this - especially for the OSGi folks.
>
> The JIRA ticket is, with some bullets to look at:
> https://issues.apache.org/jira/browse/CAMEL-7997
>
> And the code is in the camel-scr module. And there is a camel-scr
> feature to install the module.
>
>
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/