Guillaume Nodet wrote:
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.
CamelContext will try to get the component which the schema ID, and we can override this behavior in camel-osgi to check if the component service is available.

My question is current we are leverage Spring DM to manage the Camel route context life cycle. If I block the thread which call the starting the camel context from the Spring DM, does it will have some side effect on the Spring DM thread ? And Do I need to manage the camel context life cycle by myself in camel ?

Willem


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





Reply via email to