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

Reply via email to