Hello Guillaume! Interesting point - not sure what I think yet. I create the camel context the following way:
CamelContextFactory camelContextFactory; camelContextFactory = new CamelContextFactory(); camelContextFactory.setBundleContext(theBundleContext); CamelContext camelContext; camelContext = mCamelContextFactory.createContext(); No, I'm not using Spring but I'm pretty sure I use camel's OSGI support. I'm not just creating a DefaultCamelContext. I think that by doing "the trick", I make sure that the bundles are resolved and started before my service is started. However, it may still take a little while before the registration is done and Spring does not seem to wait for that. The delay between starting the camel-core bundle and until all components are registered is what I thought I had to wait for. I know that without "the trick", just sleeping for a second does not work at all. I've tried that. However, I wasn't aware about the Require-Bundle header that you mention. Maybe it achieves the same thing. Does it make sure that the required bundle is started or is it just resolved? Without having checked, I imagine that camel-osgi has an activator that registers a tracker that inspects all loaded bundles for camel components to be registered - including the components in camel-core. This means that there can be a little delay from the time that camel-core is started until camel-osgi has registered these components. I thought I was taking care of that delay. What do you think? /Bengt 2010/5/2 Guillaume Nodet <[email protected]>: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
