I fear your trick does not really work. I think all it does is force your iPojo application to sleep for 1 second before starting, which is enough to make sure the required camel components are registerd. However you still need this delay. What I was proposing would have work (I think) if you were using spring to create the camel context.
If you don't use spring, I suppose you don't use camel-spring-osgi either and you just use camel-core. In such a case the problem is much simpler, as adding a Require-Bundle header on the needed components would make sure the components are available. You just need to use the standard CamelContext and not the OSGi one. On Sat, May 1, 2010 at 23:27, Bengt Rodehav <[email protected]> wrote: > I've now tried your suggested workaround and I think I've got it to > work. Since I create my routes in Java DSL in components instantiated > by iPOJO (not Spring), it wasn't all that straight forward. > > I needed to publish an OSGI service from Spring that my iPOJO services > could depend on (using @Requires). > > This is my spring file: > > ... > > <bean id="fileComponent" > class="org.apache.camel.component.file.FileComponent"/> > > <bean id="camelServiceBean" > class="se.digia.connect.core.service.impl.CamelService"> > <property name="fileComponent" ref="fileComponent" /> > </bean> > > <spring-osgi:service ref="camelServiceBean" > interface="se.digia.connect.core.service.ICamelService"/> > ... > > I instantiate a bean that has a FileComponent injected. I can then > inject other Camel components should I need to require them as well. I > then publish this bean as an OSGI service using Spring. I define a > "tag interface" that my services can depend on. > > This is the CamelService class: > > public class CamelService implements ICamelService { > public CamelService() throws InterruptedException { > Thread.sleep(1000); > } > public void setFileComponent(FileComponent theFileComponent) { > } > } > > I define a setter for the file component but I'm not really interested > in saving its value. Note that I defined a constructor in which I > sleep for a second. If I don't do this, then it won't work. 100 ms is > too short, but 1 s seems to work. This is a bit scary since it means > that not all components are registered at this point but shortly > thereafter. Right now I'll make this delay configurable. Maybe you > can comment on this. > > In my dependent iPOJO services I then put: > > @Requires > private ICamelService mCamelService; > > I guess this could serve as a template workaround for making sure that > Camel is properly initialised before it's being used in an OSGI > environment. The trick (that you suggested) then is to use Spring to > let us know when the camel component is registered. We then publish an > OSGI service that other services can depend on. > > /Bengt > > > 2010/5/1 Bengt Rodehav <[email protected]>: > > Thanks for your reply Guillaume (on a saturday morning!), > > > > I define my routes using Java DSL but I guess I could still add a > > dependency via Spring like you suggest just to get the ordering to > > work. > > > > I'll try and let you know. > > > > As an aside, are you considering the possiblity for adding startlevels > > for the features? I know that ordering should ideally be handled using > > OSGI service dependencies but there will always be a need to make > > software that is not properly OSGI'fied to work as well. You mentioned > > in a previous post that there are some plans to enhance Karaf > > features. Do you have any information regarding what you are > > considering - and in what time frame? > > > > Thanks again, > > > > /Bengt > > > > 2010/5/1 Guillaume Nodet <[email protected]>: > >> I may have a work around. You should try to define the components you > need > >> from inside your xml definition: > >> > >> <bean id="file" class="org.apache.camel.component.file.FileComponent" > /> > >> > >> The resolver will first look up in the spring registry, then the osgi > >> registry, then using the osgi custom discovery mechanism which requires > >> bundles to be started. > >> I'm thinking it should work. > >> > >> On Fri, Apr 30, 2010 at 21:53, Bengt Rodehav <[email protected]> wrote: > >> > >>> Hi again Guillaume, > >>> > >>> Sorry to bother you again Guillaume. Although I agree with you that > >>> Camel should use OSGI services to handle the dependency/ordering > >>> problem, I still need to get this to work. > >>> > >>> Right now I can't seem to figure out how to make sure the required > >>> Camel components are available. Trying to add all the required bundles > >>> to startup.properties seems like a hopeless task since Camel will > >>> bring in almost everything. I need both camel-core and > >>> camel-spring-osgi; which will bring in the following: > >>> > >>> <feature name='camel-core' version='2.2.0'> > >>> <feature version="2.5.6.SEC01">spring</feature> > >>> > >>> > > <bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/1.4.0</bundle> > >>> > >>> > > <bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.1/1.4.0</bundle> > >>> > >>> > > <bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-api-1.0/1.4.0</bundle> > >>> > >>> > > <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.1.12_1</bundle> > >>> <bundle>mvn:org.fusesource.commonman/commons-management/1.0</bundle> > >>> <bundle>mvn:org.apache.camel/camel-core/2.2.0</bundle> > >>> </feature> > >>> <feature name='camel-spring-osgi' version='2.2.0'> > >>> > >>> > <bundle>mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1</bundle> > >>> <feature version='2.5.6.SEC01'>spring</feature> > >>> <feature version='1.2.0'>spring-dm</feature> > >>> <bundle>mvn:org.springframework/spring-tx/2.5.6.SEC01</bundle> > >>> <feature version='2.2.0'>camel-core</feature> > >>> <bundle>mvn:org.apache.camel/camel-spring-osgi/2.2.0</bundle> > >>> </feature> > >>> > >>> I'm hoping there is a workaround (other than moving all my bundles > >>> from the feature file to startup.properties). There must be others who > >>> use the combination of Camel and Karaf and that need a clean way to > >>> install and start the application. Do you have any advice? > >>> > >>> Thanks, > >>> > >>> /Bengt > >>> > >>> > >>> 2010/4/28 Bengt Rodehav <[email protected]>: > >>> > Guillaume, > >>> > > >>> > I've been trying to modify startup.properties to make sure camel-core > >>> > is started by the time the feature containing my route is started. > >>> > Can't get it to work though. There are a lot of dependencies. Seems > >>> > like camel-core is dependent on a number of servicemix bundles as > well > >>> > as the spring feature. I think by the end of this I'll have to remove > >>> > almost everything from my features file and put the individual > bundles > >>> > in startup.properties. > >>> > > >>> > While waiting for support for specifying startup levels for features > >>> > (or something similar), is there another workaround I can use? > >>> > > >>> > /Bengt > >>> > > >>> > 2010/4/28 Bengt Rodehav <[email protected]>: > >>> >> Just sent a mail to [email protected] regarding this. > >>> >> > >>> >> /Bengt > >>> >> > >>> >> 2010/4/28 Bengt Rodehav <[email protected]>: > >>> >>> 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] > >>> > >>> > >> > >> > >> -- > >> 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
