Thanks Guillaume, Yes, I agree, it would be much better if Camel published services that my services could depend on. I'll bring that up on the camel-dev list as you said.
Do you have any details regarding enhancement plans for Karaf features? /Bengt 2010/4/28 Guillaume Nodet <[email protected]>: > Yes, there are plans to enhance, but I don't think this is the problem here. > This is a service dependency problem and those should either be captured by > camel > or by your bundle itself. Actually, I think camel should be enhanced, > because it waits > for bundles containing components to be started without using services, and > that's wrong. > The way to go would be to have a bundle tracker registering a service for > the component, > even if it's a simple factory and not the real component. That would allow > to have the > spring-dm / blueprint application to add a reference to the component > somehow. > Or have the camel context wait for the component to become available with a > timeout > to cope with such ordering problems. Not sure exactly what the best way > is, but there is > definitely something to improve, as the current behavior is bad. > You should bring that on the camel-dev/user list imho. > > On Wed, Apr 28, 2010 at 11:43, Bengt Rodehav <[email protected]> wrote: > >> Thanks for your reply Guillaume, >> >> I've now added a few bundles in the startup.properties (url handlers) >> and I get this to work. I used the startlevel 40. Is that OK or is >> there a best practice for this? >> >> However, I then move on to my bundles containing camel routes. They >> fail to install becuase the "file:" component is not registered yet. >> It seems like this is cascading. I guess, to get this to work I must >> then stop using the "camel-core" feature in my >> org.apache.felix.karaf.features.cfg and put all (or some) of those >> bundles in the startup.properties as well. I don't like the direction >> I'm heading with this... >> >> Karaf features is a very good way to install/deploy applications based >> on Karaf/Felix. However, there doesn't seem to be a good way to >> achieve an automated, clean, install that way since there will >> (almost) always be certain startup dependency ordering requirements. >> >> Are there any plans to enhance Karaf features? It would be extremely >> useful to be able to specify the startlevel for a specific feature. I >> think that would completely solve the type of problems I'm >> experiencing. >> >> What do you think? >> >> /Bengt >> >> >> >> >> >> >> 2010/4/28 Guillaume Nodet <[email protected]>: >> > Right, using url handlers could lead to such problems if the url handlers >> > are not registered yet. I guess a possible solution would be to change >> the >> > karaf configuration so that url handlers are installed and started very >> > early. >> > This can be done by modifying the etc/startup.properties or modifying the >> > start level of the bundles for your url handlers once they installed. >> > >> > On Wed, Apr 28, 2010 at 09:46, Bengt Rodehav <[email protected]> wrote: >> > >> >> I have a problem with the startup ordering in Karaf. My explicit >> >> problem is that I use iPOJO's Online Manipulator which gives me the >> >> possibility to deploy iPOJO components using the "ipojo:" protocol. >> >> However, it seems impossible to get an automatic installation to work >> >> using Karaf features this way. >> >> >> >> I need to have the iPOJO Online Manipulator started (not just >> >> resolved) before I even try to resolve my iPOJO components since I >> >> refer to them using the "ipojo:" protocol. How can I solve this? I was >> >> hoping that it was possible to specify a startlevel for a specific >> >> feature (in the org.apache.felix.karaf.features.cfg) so that it is >> >> guaranteed to start after other required features. >> >> >> >> I have the same problem when deploying a war. In that case I must be >> >> sure that the "pax-url-war" feature is started first. >> >> >> >> This must be a common problem and I'm hoping there is a standard >> >> recommended way to handle this. >> >> >> >> I'm using Karaf 1.4.0 and iPOJO 1.4.0. >> >> >> >> /Bengt >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > >> > -- >> > Cheers, >> > Guillaume Nodet >> > ------------------------ >> > Blog: http://gnodet.blogspot.com/ >> > ------------------------ >> > Open Source SOA >> > http://fusesource.com >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
