Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of cschneider111@gmail.com
 designates 74.125.82.51 as permitted sender)
Sender: Christian Schneider <cschneider111@gmail.com>
Message-ID: <546261A0.7020304@die-schneider.net>
Date: Tue, 11 Nov 2014 20:21:04 +0100
From: Christian Schneider <chris@die-schneider.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15
References: 
 <CAGB5yNns8XwwMWpUzhFuXZw1ws=AQCvmoAudeEXkiwnRLozDWA@mail.gmail.com>
 <546082A7.3020704@die-schneider.net>
 <CAGB5yN=dGqACF2pgoeEvnvPv-mAmRC4JV4vF=0z=CR+vx2GQFw@mail.gmail.com>
In-Reply-To: 
 <CAGB5yN=dGqACF2pgoeEvnvPv-mAmRC4JV4vF=0z=CR+vx2GQFw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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
> <chris@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