Hi again Guillaume,

Sorry to bother you again Guillaume. Although I agree with you that
Camel should use OSGI services to handle the dependency/ordering
problem, I still need to get this to work.

Right now I can't seem to figure out how to make sure the required
Camel components are available. Trying to add all the required bundles
to startup.properties seems like a hopeless task since Camel will
bring in almost everything. I need both camel-core and
camel-spring-osgi; which will bring in the following:

  <feature name='camel-core' version='2.2.0'>
    <feature version="2.5.6.SEC01">spring</feature>
    
<bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/1.4.0</bundle>
    
<bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.1/1.4.0</bundle>
    
<bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-api-1.0/1.4.0</bundle>
    
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.1.12_1</bundle>
    <bundle>mvn:org.fusesource.commonman/commons-management/1.0</bundle>
    <bundle>mvn:org.apache.camel/camel-core/2.2.0</bundle>
  </feature>
  <feature name='camel-spring-osgi' version='2.2.0'>
    <bundle>mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1</bundle>
    <feature version='2.5.6.SEC01'>spring</feature>
    <feature version='1.2.0'>spring-dm</feature>
    <bundle>mvn:org.springframework/spring-tx/2.5.6.SEC01</bundle>
    <feature version='2.2.0'>camel-core</feature>
    <bundle>mvn:org.apache.camel/camel-spring-osgi/2.2.0</bundle>
  </feature>

I'm hoping there is a workaround (other than moving all my bundles
from the feature file to startup.properties). There must be others who
use the combination of Camel and Karaf and that need a clean way to
install and start the application. Do you have any advice?

Thanks,

/Bengt


2010/4/28 Bengt Rodehav <[email protected]>:
> Guillaume,
>
> I've been trying to modify startup.properties to make sure camel-core
> is started by the time the feature containing my route is started.
> Can't get it to work though. There are a lot of dependencies. Seems
> like camel-core is dependent on a number of servicemix bundles as well
> as the spring feature. I think by the end of this I'll have to remove
> almost everything from my features file and put the individual bundles
> in startup.properties.
>
> While waiting for support for specifying startup levels for features
> (or something similar), is there another workaround I can use?
>
> /Bengt
>
> 2010/4/28 Bengt Rodehav <[email protected]>:
>> Just sent a mail to [email protected] regarding this.
>>
>> /Bengt
>>
>> 2010/4/28 Bengt Rodehav <[email protected]>:
>>> Thanks Guillaume,
>>>
>>> Yes, I agree, it would be much better if Camel published services that
>>> my services could depend on. I'll bring that up on the camel-dev list
>>> as you said.
>>>
>>> Do you have any details regarding enhancement plans for Karaf features?
>>>
>>> /Bengt
>>>
>>> 2010/4/28 Guillaume Nodet <[email protected]>:
>>>> Yes, there are plans to enhance, but I don't think this is the problem 
>>>> here.
>>>> This is a service dependency problem and those should either be captured by
>>>> camel
>>>> or by your bundle itself.  Actually, I think camel should be enhanced,
>>>> because it waits
>>>> for bundles containing components to be started without using services, and
>>>> that's wrong.
>>>> The way to go would be to have a bundle tracker registering a service for
>>>> the component,
>>>> even if it's a simple factory and not the real component.  That would allow
>>>> to have the
>>>> spring-dm / blueprint application to add a reference to the component
>>>> somehow.
>>>> Or have the camel context wait for the component to become available with a
>>>> timeout
>>>> to cope with such ordering problems.   Not sure exactly what the best way
>>>> is, but there is
>>>> definitely something to improve, as the current behavior is bad.
>>>> You should bring that on the camel-dev/user list imho.
>>>>
>>>> On Wed, Apr 28, 2010 at 11:43, Bengt Rodehav <[email protected]> wrote:
>>>>
>>>>> Thanks for your reply Guillaume,
>>>>>
>>>>> I've now added a few bundles in the startup.properties (url handlers)
>>>>> and I get this to work. I used the startlevel 40. Is that OK or is
>>>>> there a best practice for this?
>>>>>
>>>>> However, I then move on to my bundles containing camel routes. They
>>>>> fail to install becuase the "file:" component is not registered yet.
>>>>> It seems like this is cascading. I guess, to get this to work I must
>>>>> then stop using the "camel-core" feature in my
>>>>> org.apache.felix.karaf.features.cfg and put all (or some) of those
>>>>> bundles in the startup.properties as well. I don't like the direction
>>>>> I'm heading with this...
>>>>>
>>>>> Karaf features is a very good way to install/deploy applications based
>>>>> on Karaf/Felix. However, there doesn't seem to be a good way to
>>>>> achieve an automated, clean, install that way since there will
>>>>> (almost) always be certain startup dependency ordering requirements.
>>>>>
>>>>> Are there any plans to enhance Karaf features? It would be extremely
>>>>> useful to be able to specify the startlevel for a specific feature. I
>>>>> think that would completely solve the type of problems I'm
>>>>> experiencing.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> /Bengt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2010/4/28 Guillaume Nodet <[email protected]>:
>>>>> > Right, using url handlers could lead to such problems if the url 
>>>>> > handlers
>>>>> > are not registered yet.  I guess a possible solution would be to change
>>>>> the
>>>>> > karaf configuration so that url handlers are installed and started very
>>>>> > early.
>>>>> > This can be done by modifying the etc/startup.properties or modifying 
>>>>> > the
>>>>> > start level of the bundles for your url handlers once they installed.
>>>>> >
>>>>> > On Wed, Apr 28, 2010 at 09:46, Bengt Rodehav <[email protected]> wrote:
>>>>> >
>>>>> >> I have a problem with the startup ordering in Karaf. My explicit
>>>>> >> problem is that I use iPOJO's Online Manipulator which gives me the
>>>>> >> possibility to deploy iPOJO components using the "ipojo:" protocol.
>>>>> >> However, it seems impossible to get an automatic installation to work
>>>>> >> using Karaf features this way.
>>>>> >>
>>>>> >> I need to have the iPOJO Online Manipulator started (not just
>>>>> >> resolved) before I even try to resolve my iPOJO components since I
>>>>> >> refer to them using the "ipojo:" protocol. How can I solve this? I was
>>>>> >> hoping that it was possible to specify a startlevel for a specific
>>>>> >> feature (in the org.apache.felix.karaf.features.cfg) so that it is
>>>>> >> guaranteed to start after other required features.
>>>>> >>
>>>>> >> I have the same problem when deploying a war. In that case I must be
>>>>> >> sure that the "pax-url-war" feature is started first.
>>>>> >>
>>>>> >> This must be a common problem and I'm hoping there is a standard
>>>>> >> recommended way to handle this.
>>>>> >>
>>>>> >> I'm using Karaf 1.4.0 and iPOJO 1.4.0.
>>>>> >>
>>>>> >> /Bengt
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: [email protected]
>>>>> >> For additional commands, e-mail: [email protected]
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Cheers,
>>>>> > Guillaume Nodet
>>>>> > ------------------------
>>>>> > Blog: http://gnodet.blogspot.com/
>>>>> > ------------------------
>>>>> > Open Source SOA
>>>>> > http://fusesource.com
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to