It's apparent that I need to enhance my knowledge of OSGI. I will take a look at the extender pattern and see if it is a possible solution. When reading about the Require-Bundle header I can't really see how it would solve my problem. It does not guaranteee anything regarding the start/stop status of bundle - it's only about resolving. I guess you mean that if I use the DefaultCamelContext then I don't have to wait for the bundle to be activated. Doesn't seem right in an OSGI environment but I'm not really sure what the concrete disadvantages are. Why is it better to use the OSGI enabled camel context then the default context? (I guess I should post that question om Came's mailing list).
I'll take a look at extenders and see if I can make any sens out of them. Thanks, /Bengt 2010/5/3 Guillaume Nodet <[email protected]>: > THe problem is that the OSGi enabled camel context and the standard one have > a different component discovery. > The first one will only discover components from the current spring > application (if any) and from started bundles. > The second one will discover those in the classpath. > Given the first one does not uses OSGi services, you can't express the fact > that the bundle need to be started (there's really no way to do that in OSGi > other than using services). > > So, as a work around, I think there are two possibilities: > * use the osgi resolver, but ensure the bundles are started. THis can be > done by writing an extender that would publish services when the bundles > containing components are started. Then your bundles containing the routes > could wait on those services to be registered. > * use the standard one and include the components in your bundles > classloader. This can be done by adding the Require-Bundle header on each > of the camel components. > > The first way actually sounds better as this could be a first step toward a > refactored version of the camel osgi support. The second one is easier to > try for your as it would not require any coding at all... > > On Sun, May 2, 2010 at 21:13, Bengt Rodehav <[email protected]> wrote: > >> 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] >> >> > > > -- > 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]
