Hello Guillaume, What you are describing is what I want to be included in camel, preferably in camel-osgi. In my case I'm making it possible to get the possibility to wait until required bundles are started. This is of course a temporary workaround until the Camel team improves Camel's OSGI support.
I do not need a sleep. I wait until both the camel-core and the camel-osgi bundle is started - then I'm home free. What the camel-osgi bundle does is register a tracker that inspects installed bundles and then registers any components and type converters. On startup it first inspects the already installed bundles. If camel-core is already installed then I only have to wait for the camel-osgi bundle to start. But since camel-core might be installed after camel-osgi, I have to wait for both bundles to be started before I can be sure that my components are registered. Although I agree with you about the preferable solution (it is in fact identical to what I suggested the Camel team should do in my previous post), it's too much work for my workaround. What you are suggesting is a replacement of the camel-osgi bundle so that a service with service properties will be used instead. I second that but that's a bit too much work for me right now. By the way, I also think that the way components should be found in bundles should be through properties in the manifest header - it's closer to the OSGI way. /Bengt 2010/5/4 Guillaume Nodet <[email protected]>: > Sorry to not have been clear enough. What I had in mind was that the > extender would listen for bundle containing camel components. > For each component found into a bundle, the extender would register an OSGI > service with a property identifying the name of the component. The object > itself would not be really important, as we would not really use it, but > only the fact it has been registered. > > Note that the extender must only look into started bundles. > > public void onArrival(Bundle bundle, String extensionValue) throws > InterruptedException { > Enumeration e = > bundle.getEntryPaths("META-INF/services/org/apache/camel/component"); > if (e != null) { > while (e.hasMoreElements()) { > String path = (String)e.nextElement(); > // register a service for the component > } > } > } > > Then, on your iPojo bean that creates the route, i would add a dependency on > those registered services. > > If you still need a sleep, that means there is still a problem somewhere. > > On Tue, May 4, 2010 at 20:55, Bengt Rodehav <[email protected]> wrote: > >> Guillaume, >> >> I've now tried the approach using the extender pattern. I did it using >> iPOJO. Here is the sample code: >> >> @Component(public_factory = false, propagation = true) >> @Extender(extension = "Bundle-SymbolicName", onArrival = "onArrival", >> onDeparture = "onDeparture") >> public class CamelExtenderService { >> private BundleContext mBundleContext; >> private ServiceRegistration mCamelRegistration; >> private Long mCamelCoreBundleId; >> private Long mCamelOsgiBundleId; >> private static final String CAMEL_CORE_NAME = >> "org.apache.camel.camel-core"; >> private static final String CAMEL_OSGI_NAME = >> "org.apache.camel.camel-osgi"; >> >> public CamelExtenderService(BundleContext theBundleContext) { >> mBundleContext = theBundleContext; >> } >> >> public void onArrival(Bundle theBundle, String extensionValue) >> throws InterruptedException { >> if (CAMEL_CORE_NAME.equals(extensionValue)) { >> System.out.println(extensionValue + " arrived"); >> mCamelCoreBundleId = theBundle.getBundleId(); >> } else if (CAMEL_OSGI_NAME.equals(extensionValue)) { >> System.out.println(extensionValue + " arrived"); >> mCamelOsgiBundleId = theBundle.getBundleId(); >> } >> if (mCamelCoreBundleId != null && mCamelOsgiBundleId != null) { >> mCamelRegistration = >> mBundleContext.registerService(ICamelService.class.getName(), new >> ICamelService() { >> }, null); >> } >> } >> >> public void onDeparture(Bundle theBundle) { >> if (theBundle.getBundleId() == mCamelCoreBundleId) { >> System.out.println("camel-core departed"); >> mCamelCoreBundleId = null; >> } else if (theBundle.getBundleId() == mCamelOsgiBundleId) { >> System.out.println("camel-osgi departed"); >> mCamelOsgiBundleId = null; >> } >> if ((mCamelCoreBundleId == null) || (mCamelOsgiBundleId == null)) { >> if (mCamelRegistration != null) { >> mCamelRegistration.unregister(); >> mCamelRegistration = null; >> } >> } >> } >> } >> >> Note that iPOJO requires that one specifies a manifest header that >> will trigger iPOJO's extender support. I used "Bundle-SymbolicName" >> that always exist so that I will detect my specific bundles >> (camel-core and camel-osgi). >> >> Not the best designed code - I know but it seems to work. I started >> off by waiting for the camel-core bundle to be started. It didn't help >> unless a added a 1 s sleep (like in the spring case). Then I looked at >> the camel source code and realised that it's the camel-osgi bundle >> that needs to be started. But, in case camel-osgi is started before >> camel-core I need to know that both of these bundles are started. The >> above works without any sleeps. >> >> The services containing my routes then wait for the ICamelService >> service to become available. >> >> Are we getting close now or have I still misunderstood this? >> >> I suspect that the Spring version (the first tricked you advised me >> of) would work as well if I add a dependency to some class in >> camel-osgi. However, I think the extender is a bit more elegant. >> >> Now what shall we recommend the Camel team do do? >> >> I feel that the best solution is for camel-osgi to publish a service >> that can be depended on. Maybe it's not feasible to publish a separate >> service for each component discovered. I guess service properties >> could be used in some way since it's possible to add requirements to >> service properties when waiting for a service. Perhaps adding a >> service property (dynamically if that is possible) for every component >> discovered is a possibility. >> >> camel-osgi also registers type converters. I guess there are cases >> where it is necessary to wait for them as well. Not sure how to >> publish them though. >> >> I think that a better way for camel-osgi to discover components and >> type converters would be to use a manifest header for this purpose. >> Bundles containing stuff interesting for camel-osgi could add a >> manifest header to indicate this (e g "Camel-Component"). camel-osgi >> would then act as an extender and publish services accordingly (the >> way I have to do right now). >> >> What do you think? >> >> /Bengt >> >> 2010/5/3 Bengt Rodehav <[email protected]>: >> > 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] >> >> > > > -- > 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]
