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: cib...@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/
