This is exactly the way I was thinking:
- Define a new interface representing a Camel component ( e g
CamelComponentService)
- Use a service property to identify the specific componente (e g
"camel.component")
This enables me to wait for a service with that specific service
property to be available. E g in my case I'm using iPOJO to
instantiate OSGI service and can use an annotation similar to the
following:
@Requires(filter={camel.component=file})
private CamelComponentService fileComponent;
I didn't check that I used the right syntax above. However, the result
is that my service will not be started until a CamelComponentService
with the service property "camel.component" with the value "file" has
been started. I think this would be very useful. It gives Camel a way
to publish the availability of components to the outside world - and
also a way to do it the OSGI way.
/Bengt
2010/4/29 Guillaume Nodet <gno...@gmail.com>:
> We don't have to add anything to the component jars I think. It should be
> possible to extend camel-osgi bundle in the following way:
> * when a bundle containing a component is started, register a service in
> the osgi registry for the component. I think it should be a new interface
> which will allow the creation of components (a component factory)
> registered with an asssociated property to identify the type of component
> (file, jms, etc...)
> * modify the osgi component resolver or camel context go to the registry
> and wait for some time until all the components are available
> The last part might be a bit more tricky, as we need to find a good strategy
> for that. It could also be configurable on the osgi component context to
> some degree.
>
> On Thu, Apr 29, 2010 at 04:30, Willem Jiang <willem.ji...@gmail.com> wrote:
>
>> Bengt Rodehav wrote:
>>
>>> Thanks for your reply Willem,
>>>
>>> I will try to the bundle dependency of camel-core to my route bundle
>>> as you suggested - sounds like good advice.
>>>
>>> I wasn't sure what you mean by your last paragraph:
>>>
>>> If you need to dependent on some specify component interface will
>>>> introduce
>>>> the OSGi related dependency to the camel components.
>>>> We need to find another way to do it.
>>>>
>>>
>>> I assume that there was a problem with my suggestion but I didn't
>>> quite understand what.
>>>
>>
>> Oh, that is if you want to publish the camel components into a OSGi
>> service, you can do it in the BundleActivator, or write some XML
>> configuration to leverage Spring DM or Blue Print to do it.
>>
>> If you are using BundleActivator, you will introduce some kind of compile
>> time dependency of OSGi jar. As we also want camel components work well as a
>> stand alone Java application, we should avoid introduce this kind of
>> dependency.
>>
>> Maybe the xml configuration is a choice for us.
>>
>> This solution need to your start the Spring-DM or BluePrint container
>> before your camel route bundle to let the container lookup the bundle
>> context for the xml configuration. It seems we are back to your original
>> question. And if you start the camel components bundles before you start up
>> your camel route bundle, you will not hit this kind of issue.
>>
>> Willem
>>
>>
>>
>>> /Bengt
>>>
>>>
>>>
>>> 2010/4/28 Willem Jiang <willem.ji...@gmail.com>:
>>>
>>>> Hi
>>>>
>>>> Please see my comments in the mail.
>>>>
>>>> Bengt Rodehav wrote:
>>>>
>>>>> I'm using Karaf to deploy my Camel routes. However, I run into
>>>>> problems during startup due to dependency ordering. Some of these
>>>>> ordering problems are OSGI/Karaf specific and have nothing to do with
>>>>> Camel. I've discussed them on the Felix user mailing list and I have
>>>>> workarounds for that. The Camel problems remain though.
>>>>>
>>>>> When trying to deploy both my routes and the camel bundles in Karaf,
>>>>> my routes fail to iniitialize because the referenced camel component
>>>>> ("file:" in this case) is not registered in Camel yet. I've tried to
>>>>> solve this with workarounds in Karaf. It is possible but not very
>>>>> elegant at all.
>>>>>
>>>> Can you add the bundle dependency of camel-core to your route bundle?
>>>>
>>>>> Guillaume Nodet (via us...@felix.apache.org) suggested to me that this
>>>>> is more of a Camel problem than a Karaf problem. In his opinion (and
>>>>> mine), it would be much better if Camel published components using
>>>>> OSGI services. That way my services could have a service dependency on
>>>>> the Camel services so that my service would start when the Camel
>>>>> service was available. As I understand it, today Camel just scans
>>>>> bundles as they are started and updates its component registry. This
>>>>> makes it impossible for dependent bundles (like my routes) to know
>>>>> whether all the required prerequisites are in place before starting
>>>>> the route.
>>>>>
>>>> That could be a solution of your issue.
>>>>
>>>>> If components were published using a component specific interface, I
>>>>> could add a service dependency to that service and wait until it
>>>>> becomes available before trying to start my routes.
>>>>>
>>>>> If you need to dependent on some specify component interface will
>>>> introduce
>>>> the OSGi related dependency to the camel components.
>>>> We need to find another way to do it.
>>>>
>>>> Has anyone else had similar issues?What is the recommended workaround?
>>>>> Are there any plans for improvement?
>>>>>
>>>>> /Bengt
>>>>>
>>>>>
>>>> Willem
>>>>
>>>>
>>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
