You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/05/01 07:47:31 UTC
Re: Problems with startup order in Karaf
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 <be...@rodehav.com> 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 <be...@rodehav.com>:
> > 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 <be...@rodehav.com>:
> >> Just sent a mail to users@camel.apache.org regarding this.
> >>
> >> /Bengt
> >>
> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
> >>> 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 <gn...@gmail.com>:
> >>>> 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 <be...@rodehav.com>
> 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 <gn...@gmail.com>:
> >>>>> > 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 <be...@rodehav.com>
> 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: users-unsubscribe@felix.apache.org
> >>>>> >> For additional commands, e-mail: users-help@felix.apache.org
> >>>>> >>
> >>>>> >>
> >>>>> >
> >>>>> >
> >>>>> > --
> >>>>> > Cheers,
> >>>>> > Guillaume Nodet
> >>>>> > ------------------------
> >>>>> > Blog: http://gnodet.blogspot.com/
> >>>>> > ------------------------
> >>>>> > Open Source SOA
> >>>>> > http://fusesource.com
> >>>>> >
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>> Guillaume Nodet
> >>>> ------------------------
> >>>> Blog: http://gnodet.blogspot.com/
> >>>> ------------------------
> >>>> Open Source SOA
> >>>> http://fusesource.com
> >>>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Problems with startup order in Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>:
> 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
>> > 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 <gn...@gmail.com>:
>> >> 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 <be...@rodehav.com> 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 <gn...@gmail.com>:
>> >>> > 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 <be...@rodehav.com>
>> 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 <be...@rodehav.com>:
>> >>> >> > 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 <gn...@gmail.com>:
>> >>> >> >> 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 <be...@rodehav.com>
>> >>> 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 <be...@rodehav.com>:
>> >>> >> >>> > 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 <be...@rodehav.com>:
>> >>> >> >>> >> Just sent a mail to users@camel.apache.org regarding this.
>> >>> >> >>> >>
>> >>> >> >>> >> /Bengt
>> >>> >> >>> >>
>> >>> >> >>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
>> >>> >> >>> >>> 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 <gn...@gmail.com>:
>> >>> >> >>> >>>> 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 <
>> >>> bengt@rodehav.com>
>> >>> >> >>> 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 <gn...@gmail.com>:
>> >>> >> >>> >>>>> > 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 <
>> >>> >> bengt@rodehav.com>
>> >>> >> >>> 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:
>> users-unsubscribe@felix.apache.org
>> >>> >> >>> >>>>> >> For additional commands, e-mail:
>> >>> users-help@felix.apache.org
>> >>> >> >>> >>>>> >>
>> >>> >> >>> >>>>> >>
>> >>> >> >>> >>>>> >
>> >>> >> >>> >>>>> >
>> >>> >> >>> >>>>> > --
>> >>> >> >>> >>>>> > Cheers,
>> >>> >> >>> >>>>> > Guillaume Nodet
>> >>> >> >>> >>>>> > ------------------------
>> >>> >> >>> >>>>> > Blog: http://gnodet.blogspot.com/
>> >>> >> >>> >>>>> > ------------------------
>> >>> >> >>> >>>>> > Open Source SOA
>> >>> >> >>> >>>>> > http://fusesource.com
>> >>> >> >>> >>>>> >
>> >>> >> >>> >>>>>
>> >>> >> >>> >>>>>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> >>> >>>>> To unsubscribe, e-mail:
>> users-unsubscribe@felix.apache.org
>> >>> >> >>> >>>>> For additional commands, e-mail:
>> users-help@felix.apache.org
>> >>> >> >>> >>>>>
>> >>> >> >>> >>>>>
>> >>> >> >>> >>>>
>> >>> >> >>> >>>>
>> >>> >> >>> >>>> --
>> >>> >> >>> >>>> Cheers,
>> >>> >> >>> >>>> Guillaume Nodet
>> >>> >> >>> >>>> ------------------------
>> >>> >> >>> >>>> Blog: http://gnodet.blogspot.com/
>> >>> >> >>> >>>> ------------------------
>> >>> >> >>> >>>> Open Source SOA
>> >>> >> >>> >>>> http://fusesource.com
>> >>> >> >>> >>>>
>> >>> >> >>> >>>
>> >>> >> >>> >>
>> >>> >> >>> >
>> >>> >> >>>
>> >>> >> >>>
>> >>> ---------------------------------------------------------------------
>> >>> >> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>> >> >>> For additional commands, e-mail: users-help@felix.apache.org
>> >>> >> >>>
>> >>> >> >>>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> --
>> >>> >> >> Cheers,
>> >>> >> >> Guillaume Nodet
>> >>> >> >> ------------------------
>> >>> >> >> Blog: http://gnodet.blogspot.com/
>> >>> >> >> ------------------------
>> >>> >> >> Open Source SOA
>> >>> >> >> http://fusesource.com
>> >>> >> >>
>> >>> >> >
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Cheers,
>> >>> > Guillaume Nodet
>> >>> > ------------------------
>> >>> > Blog: http://gnodet.blogspot.com/
>> >>> > ------------------------
>> >>> > Open Source SOA
>> >>> > http://fusesource.com
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Guillaume Nodet
>> >> ------------------------
>> >> Blog: http://gnodet.blogspot.com/
>> >> ------------------------
>> >> Open Source SOA
>> >> http://fusesource.com
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problems with startup order in Karaf
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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 <be...@rodehav.com>:
> > 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 <gn...@gmail.com>:
> >> 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 <be...@rodehav.com> 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 <gn...@gmail.com>:
> >>> > 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 <be...@rodehav.com>
> 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 <be...@rodehav.com>:
> >>> >> > 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 <gn...@gmail.com>:
> >>> >> >> 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 <be...@rodehav.com>
> >>> 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 <be...@rodehav.com>:
> >>> >> >>> > 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 <be...@rodehav.com>:
> >>> >> >>> >> Just sent a mail to users@camel.apache.org regarding this.
> >>> >> >>> >>
> >>> >> >>> >> /Bengt
> >>> >> >>> >>
> >>> >> >>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
> >>> >> >>> >>> 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 <gn...@gmail.com>:
> >>> >> >>> >>>> 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 <
> >>> bengt@rodehav.com>
> >>> >> >>> 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 <gn...@gmail.com>:
> >>> >> >>> >>>>> > 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 <
> >>> >> bengt@rodehav.com>
> >>> >> >>> 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:
> users-unsubscribe@felix.apache.org
> >>> >> >>> >>>>> >> For additional commands, e-mail:
> >>> users-help@felix.apache.org
> >>> >> >>> >>>>> >>
> >>> >> >>> >>>>> >>
> >>> >> >>> >>>>> >
> >>> >> >>> >>>>> >
> >>> >> >>> >>>>> > --
> >>> >> >>> >>>>> > Cheers,
> >>> >> >>> >>>>> > Guillaume Nodet
> >>> >> >>> >>>>> > ------------------------
> >>> >> >>> >>>>> > Blog: http://gnodet.blogspot.com/
> >>> >> >>> >>>>> > ------------------------
> >>> >> >>> >>>>> > Open Source SOA
> >>> >> >>> >>>>> > http://fusesource.com
> >>> >> >>> >>>>> >
> >>> >> >>> >>>>>
> >>> >> >>> >>>>>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> >>> >>>>> To unsubscribe, e-mail:
> users-unsubscribe@felix.apache.org
> >>> >> >>> >>>>> For additional commands, e-mail:
> users-help@felix.apache.org
> >>> >> >>> >>>>>
> >>> >> >>> >>>>>
> >>> >> >>> >>>>
> >>> >> >>> >>>>
> >>> >> >>> >>>> --
> >>> >> >>> >>>> Cheers,
> >>> >> >>> >>>> Guillaume Nodet
> >>> >> >>> >>>> ------------------------
> >>> >> >>> >>>> Blog: http://gnodet.blogspot.com/
> >>> >> >>> >>>> ------------------------
> >>> >> >>> >>>> Open Source SOA
> >>> >> >>> >>>> http://fusesource.com
> >>> >> >>> >>>>
> >>> >> >>> >>>
> >>> >> >>> >>
> >>> >> >>> >
> >>> >> >>>
> >>> >> >>>
> >>> ---------------------------------------------------------------------
> >>> >> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> >> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>> >> >>>
> >>> >> >>>
> >>> >> >>
> >>> >> >>
> >>> >> >> --
> >>> >> >> Cheers,
> >>> >> >> Guillaume Nodet
> >>> >> >> ------------------------
> >>> >> >> Blog: http://gnodet.blogspot.com/
> >>> >> >> ------------------------
> >>> >> >> Open Source SOA
> >>> >> >> http://fusesource.com
> >>> >> >>
> >>> >> >
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> >> For additional commands, e-mail: users-help@felix.apache.org
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > Cheers,
> >>> > Guillaume Nodet
> >>> > ------------------------
> >>> > Blog: http://gnodet.blogspot.com/
> >>> > ------------------------
> >>> > Open Source SOA
> >>> > http://fusesource.com
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Problems with startup order in Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@rodehav.com>:
> 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 <gn...@gmail.com>:
>> 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 <be...@rodehav.com> 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 <gn...@gmail.com>:
>>> > 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
>>> >> > 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 <gn...@gmail.com>:
>>> >> >> 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 <be...@rodehav.com>
>>> 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 <be...@rodehav.com>:
>>> >> >>> > 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 <be...@rodehav.com>:
>>> >> >>> >> Just sent a mail to users@camel.apache.org regarding this.
>>> >> >>> >>
>>> >> >>> >> /Bengt
>>> >> >>> >>
>>> >> >>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
>>> >> >>> >>> 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 <gn...@gmail.com>:
>>> >> >>> >>>> 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 <
>>> bengt@rodehav.com>
>>> >> >>> 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 <gn...@gmail.com>:
>>> >> >>> >>>>> > 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 <
>>> >> bengt@rodehav.com>
>>> >> >>> 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: users-unsubscribe@felix.apache.org
>>> >> >>> >>>>> >> For additional commands, e-mail:
>>> users-help@felix.apache.org
>>> >> >>> >>>>> >>
>>> >> >>> >>>>> >>
>>> >> >>> >>>>> >
>>> >> >>> >>>>> >
>>> >> >>> >>>>> > --
>>> >> >>> >>>>> > Cheers,
>>> >> >>> >>>>> > Guillaume Nodet
>>> >> >>> >>>>> > ------------------------
>>> >> >>> >>>>> > Blog: http://gnodet.blogspot.com/
>>> >> >>> >>>>> > ------------------------
>>> >> >>> >>>>> > Open Source SOA
>>> >> >>> >>>>> > http://fusesource.com
>>> >> >>> >>>>> >
>>> >> >>> >>>>>
>>> >> >>> >>>>>
>>> >> ---------------------------------------------------------------------
>>> >> >>> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> >> >>> >>>>> For additional commands, e-mail: users-help@felix.apache.org
>>> >> >>> >>>>>
>>> >> >>> >>>>>
>>> >> >>> >>>>
>>> >> >>> >>>>
>>> >> >>> >>>> --
>>> >> >>> >>>> Cheers,
>>> >> >>> >>>> Guillaume Nodet
>>> >> >>> >>>> ------------------------
>>> >> >>> >>>> Blog: http://gnodet.blogspot.com/
>>> >> >>> >>>> ------------------------
>>> >> >>> >>>> Open Source SOA
>>> >> >>> >>>> http://fusesource.com
>>> >> >>> >>>>
>>> >> >>> >>>
>>> >> >>> >>
>>> >> >>> >
>>> >> >>>
>>> >> >>>
>>> ---------------------------------------------------------------------
>>> >> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> >> >>> For additional commands, e-mail: users-help@felix.apache.org
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Cheers,
>>> >> >> Guillaume Nodet
>>> >> >> ------------------------
>>> >> >> Blog: http://gnodet.blogspot.com/
>>> >> >> ------------------------
>>> >> >> Open Source SOA
>>> >> >> http://fusesource.com
>>> >> >>
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> >> For additional commands, e-mail: users-help@felix.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Cheers,
>>> > Guillaume Nodet
>>> > ------------------------
>>> > Blog: http://gnodet.blogspot.com/
>>> > ------------------------
>>> > Open Source SOA
>>> > http://fusesource.com
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problems with startup order in Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>:
> 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 <be...@rodehav.com> 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 <gn...@gmail.com>:
>> > 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
>> >> > 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 <gn...@gmail.com>:
>> >> >> 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 <be...@rodehav.com>
>> 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 <be...@rodehav.com>:
>> >> >>> > 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 <be...@rodehav.com>:
>> >> >>> >> Just sent a mail to users@camel.apache.org regarding this.
>> >> >>> >>
>> >> >>> >> /Bengt
>> >> >>> >>
>> >> >>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
>> >> >>> >>> 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 <gn...@gmail.com>:
>> >> >>> >>>> 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 <
>> bengt@rodehav.com>
>> >> >>> 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 <gn...@gmail.com>:
>> >> >>> >>>>> > 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 <
>> >> bengt@rodehav.com>
>> >> >>> 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: users-unsubscribe@felix.apache.org
>> >> >>> >>>>> >> For additional commands, e-mail:
>> users-help@felix.apache.org
>> >> >>> >>>>> >>
>> >> >>> >>>>> >>
>> >> >>> >>>>> >
>> >> >>> >>>>> >
>> >> >>> >>>>> > --
>> >> >>> >>>>> > Cheers,
>> >> >>> >>>>> > Guillaume Nodet
>> >> >>> >>>>> > ------------------------
>> >> >>> >>>>> > Blog: http://gnodet.blogspot.com/
>> >> >>> >>>>> > ------------------------
>> >> >>> >>>>> > Open Source SOA
>> >> >>> >>>>> > http://fusesource.com
>> >> >>> >>>>> >
>> >> >>> >>>>>
>> >> >>> >>>>>
>> >> ---------------------------------------------------------------------
>> >> >>> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> >>> >>>>> For additional commands, e-mail: users-help@felix.apache.org
>> >> >>> >>>>>
>> >> >>> >>>>>
>> >> >>> >>>>
>> >> >>> >>>>
>> >> >>> >>>> --
>> >> >>> >>>> Cheers,
>> >> >>> >>>> Guillaume Nodet
>> >> >>> >>>> ------------------------
>> >> >>> >>>> Blog: http://gnodet.blogspot.com/
>> >> >>> >>>> ------------------------
>> >> >>> >>>> Open Source SOA
>> >> >>> >>>> http://fusesource.com
>> >> >>> >>>>
>> >> >>> >>>
>> >> >>> >>
>> >> >>> >
>> >> >>>
>> >> >>>
>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> >>> For additional commands, e-mail: users-help@felix.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Cheers,
>> >> >> Guillaume Nodet
>> >> >> ------------------------
>> >> >> Blog: http://gnodet.blogspot.com/
>> >> >> ------------------------
>> >> >> Open Source SOA
>> >> >> http://fusesource.com
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problems with startup order in Karaf
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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 <gn...@gmail.com>:
> > 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
> >> > 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 <gn...@gmail.com>:
> >> >> 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 <be...@rodehav.com>
> 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 <be...@rodehav.com>:
> >> >>> > 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 <be...@rodehav.com>:
> >> >>> >> Just sent a mail to users@camel.apache.org regarding this.
> >> >>> >>
> >> >>> >> /Bengt
> >> >>> >>
> >> >>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
> >> >>> >>> 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 <gn...@gmail.com>:
> >> >>> >>>> 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 <
> bengt@rodehav.com>
> >> >>> 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 <gn...@gmail.com>:
> >> >>> >>>>> > 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 <
> >> bengt@rodehav.com>
> >> >>> 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: users-unsubscribe@felix.apache.org
> >> >>> >>>>> >> For additional commands, e-mail:
> users-help@felix.apache.org
> >> >>> >>>>> >>
> >> >>> >>>>> >>
> >> >>> >>>>> >
> >> >>> >>>>> >
> >> >>> >>>>> > --
> >> >>> >>>>> > Cheers,
> >> >>> >>>>> > Guillaume Nodet
> >> >>> >>>>> > ------------------------
> >> >>> >>>>> > Blog: http://gnodet.blogspot.com/
> >> >>> >>>>> > ------------------------
> >> >>> >>>>> > Open Source SOA
> >> >>> >>>>> > http://fusesource.com
> >> >>> >>>>> >
> >> >>> >>>>>
> >> >>> >>>>>
> >> ---------------------------------------------------------------------
> >> >>> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> >>> >>>>> For additional commands, e-mail: users-help@felix.apache.org
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>> --
> >> >>> >>>> Cheers,
> >> >>> >>>> Guillaume Nodet
> >> >>> >>>> ------------------------
> >> >>> >>>> Blog: http://gnodet.blogspot.com/
> >> >>> >>>> ------------------------
> >> >>> >>>> Open Source SOA
> >> >>> >>>> http://fusesource.com
> >> >>> >>>>
> >> >>> >>>
> >> >>> >>
> >> >>> >
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> >>> For additional commands, e-mail: users-help@felix.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Cheers,
> >> >> Guillaume Nodet
> >> >> ------------------------
> >> >> Blog: http://gnodet.blogspot.com/
> >> >> ------------------------
> >> >> Open Source SOA
> >> >> http://fusesource.com
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Problems with startup order in Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>:
> 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
>> > 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 <gn...@gmail.com>:
>> >> 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
>> >>> > 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 <be...@rodehav.com>:
>> >>> >> Just sent a mail to users@camel.apache.org regarding this.
>> >>> >>
>> >>> >> /Bengt
>> >>> >>
>> >>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
>> >>> >>> 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 <gn...@gmail.com>:
>> >>> >>>> 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 <be...@rodehav.com>
>> >>> 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 <gn...@gmail.com>:
>> >>> >>>>> > 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 <
>> bengt@rodehav.com>
>> >>> 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: users-unsubscribe@felix.apache.org
>> >>> >>>>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >
>> >>> >>>>> >
>> >>> >>>>> > --
>> >>> >>>>> > Cheers,
>> >>> >>>>> > Guillaume Nodet
>> >>> >>>>> > ------------------------
>> >>> >>>>> > Blog: http://gnodet.blogspot.com/
>> >>> >>>>> > ------------------------
>> >>> >>>>> > Open Source SOA
>> >>> >>>>> > http://fusesource.com
>> >>> >>>>> >
>> >>> >>>>>
>> >>> >>>>>
>> ---------------------------------------------------------------------
>> >>> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>> >>>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> --
>> >>> >>>> Cheers,
>> >>> >>>> Guillaume Nodet
>> >>> >>>> ------------------------
>> >>> >>>> Blog: http://gnodet.blogspot.com/
>> >>> >>>> ------------------------
>> >>> >>>> Open Source SOA
>> >>> >>>> http://fusesource.com
>> >>> >>>>
>> >>> >>>
>> >>> >>
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Guillaume Nodet
>> >> ------------------------
>> >> Blog: http://gnodet.blogspot.com/
>> >> ------------------------
>> >> Open Source SOA
>> >> http://fusesource.com
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problems with startup order in Karaf
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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 <be...@rodehav.com>:
> > 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 <gn...@gmail.com>:
> >> 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
> >>> > 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 <be...@rodehav.com>:
> >>> >> Just sent a mail to users@camel.apache.org regarding this.
> >>> >>
> >>> >> /Bengt
> >>> >>
> >>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
> >>> >>> 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 <gn...@gmail.com>:
> >>> >>>> 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 <be...@rodehav.com>
> >>> 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 <gn...@gmail.com>:
> >>> >>>>> > 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 <
> bengt@rodehav.com>
> >>> 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: users-unsubscribe@felix.apache.org
> >>> >>>>> >> For additional commands, e-mail: users-help@felix.apache.org
> >>> >>>>> >>
> >>> >>>>> >>
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> > --
> >>> >>>>> > Cheers,
> >>> >>>>> > Guillaume Nodet
> >>> >>>>> > ------------------------
> >>> >>>>> > Blog: http://gnodet.blogspot.com/
> >>> >>>>> > ------------------------
> >>> >>>>> > Open Source SOA
> >>> >>>>> > http://fusesource.com
> >>> >>>>> >
> >>> >>>>>
> >>> >>>>>
> ---------------------------------------------------------------------
> >>> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> >>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>> >>>>>
> >>> >>>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> --
> >>> >>>> Cheers,
> >>> >>>> Guillaume Nodet
> >>> >>>> ------------------------
> >>> >>>> Blog: http://gnodet.blogspot.com/
> >>> >>>> ------------------------
> >>> >>>> Open Source SOA
> >>> >>>> http://fusesource.com
> >>> >>>>
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Problems with startup order in Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@rodehav.com>:
> 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 <gn...@gmail.com>:
>> 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
>>> > 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 <be...@rodehav.com>:
>>> >> Just sent a mail to users@camel.apache.org regarding this.
>>> >>
>>> >> /Bengt
>>> >>
>>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
>>> >>> 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 <gn...@gmail.com>:
>>> >>>> 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 <be...@rodehav.com>
>>> 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 <gn...@gmail.com>:
>>> >>>>> > 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 <be...@rodehav.com>
>>> 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: users-unsubscribe@felix.apache.org
>>> >>>>> >> For additional commands, e-mail: users-help@felix.apache.org
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > --
>>> >>>>> > Cheers,
>>> >>>>> > Guillaume Nodet
>>> >>>>> > ------------------------
>>> >>>>> > Blog: http://gnodet.blogspot.com/
>>> >>>>> > ------------------------
>>> >>>>> > Open Source SOA
>>> >>>>> > http://fusesource.com
>>> >>>>> >
>>> >>>>>
>>> >>>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> >>>>> For additional commands, e-mail: users-help@felix.apache.org
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Cheers,
>>> >>>> Guillaume Nodet
>>> >>>> ------------------------
>>> >>>> Blog: http://gnodet.blogspot.com/
>>> >>>> ------------------------
>>> >>>> Open Source SOA
>>> >>>> http://fusesource.com
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problems with startup order in Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>:
> 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 <be...@rodehav.com> 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 <be...@rodehav.com>:
>> > 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 <be...@rodehav.com>:
>> >> Just sent a mail to users@camel.apache.org regarding this.
>> >>
>> >> /Bengt
>> >>
>> >> 2010/4/28 Bengt Rodehav <be...@rodehav.com>:
>> >>> 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 <gn...@gmail.com>:
>> >>>> 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 <be...@rodehav.com>
>> 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 <gn...@gmail.com>:
>> >>>>> > 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 <be...@rodehav.com>
>> 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: users-unsubscribe@felix.apache.org
>> >>>>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>> >>
>> >>>>> >>
>> >>>>> >
>> >>>>> >
>> >>>>> > --
>> >>>>> > Cheers,
>> >>>>> > Guillaume Nodet
>> >>>>> > ------------------------
>> >>>>> > Blog: http://gnodet.blogspot.com/
>> >>>>> > ------------------------
>> >>>>> > Open Source SOA
>> >>>>> > http://fusesource.com
>> >>>>> >
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Cheers,
>> >>>> Guillaume Nodet
>> >>>> ------------------------
>> >>>> Blog: http://gnodet.blogspot.com/
>> >>>> ------------------------
>> >>>> Open Source SOA
>> >>>> http://fusesource.com
>> >>>>
>> >>>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org