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
