I've now tried your suggested workaround and I think I've got it to
work. Since I create my routes in Java DSL in components instantiated
by iPOJO (not Spring), it wasn't all that straight forward.
I needed to publish an OSGI service from Spring that my iPOJO services
could depend on (using @Requires).
This is my spring file:
...
<bean id="fileComponent"
class="org.apache.camel.component.file.FileComponent"/>
<bean id="camelServiceBean"
class="se.digia.connect.core.service.impl.CamelService">
<property name="fileComponent" ref="fileComponent" />
</bean>
<spring-osgi:service ref="camelServiceBean"
interface="se.digia.connect.core.service.ICamelService"/>
...
I instantiate a bean that has a FileComponent injected. I can then
inject other Camel components should I need to require them as well. I
then publish this bean as an OSGI service using Spring. I define a
"tag interface" that my services can depend on.
This is the CamelService class:
public class CamelService implements ICamelService {
public CamelService() throws InterruptedException {
Thread.sleep(1000);
}
public void setFileComponent(FileComponent theFileComponent) {
}
}
I define a setter for the file component but I'm not really interested
in saving its value. Note that I defined a constructor in which I
sleep for a second. If I don't do this, then it won't work. 100 ms is
too short, but 1 s seems to work. This is a bit scary since it means
that not all components are registered at this point but shortly
thereafter. Right now I'll make this delay configurable. Maybe you
can comment on this.
In my dependent iPOJO services I then put:
@Requires
private ICamelService mCamelService;
I guess this could serve as a template workaround for making sure that
Camel is properly initialised before it's being used in an OSGI
environment. The trick (that you suggested) then is to use Spring to
let us know when the camel component is registered. We then publish an
OSGI service that other services can depend on.
/Bengt
2010/5/1 Bengt Rodehav <[email protected]>:
> Thanks for your reply Guillaume (on a saturday morning!),
>
> I define my routes using Java DSL but I guess I could still add a
> dependency via Spring like you suggest just to get the ordering to
> work.
>
> I'll try and let you know.
>
> As an aside, are you considering the possiblity for adding startlevels
> for the features? I know that ordering should ideally be handled using
> OSGI service dependencies but there will always be a need to make
> software that is not properly OSGI'fied to work as well. You mentioned
> in a previous post that there are some plans to enhance Karaf
> features. Do you have any information regarding what you are
> considering - and in what time frame?
>
> Thanks again,
>
> /Bengt
>
> 2010/5/1 Guillaume Nodet <[email protected]>:
>> I may have a work around. You should try to define the components you need
>> from inside your xml definition:
>>
>> <bean id="file" class="org.apache.camel.component.file.FileComponent" />
>>
>> The resolver will first look up in the spring registry, then the osgi
>> registry, then using the osgi custom discovery mechanism which requires
>> bundles to be started.
>> I'm thinking it should work.
>>
>> On Fri, Apr 30, 2010 at 21:53, Bengt Rodehav <[email protected]> wrote:
>>
>>> Hi again Guillaume,
>>>
>>> Sorry to bother you again Guillaume. Although I agree with you that
>>> Camel should use OSGI services to handle the dependency/ordering
>>> problem, I still need to get this to work.
>>>
>>> Right now I can't seem to figure out how to make sure the required
>>> Camel components are available. Trying to add all the required bundles
>>> to startup.properties seems like a hopeless task since Camel will
>>> bring in almost everything. I need both camel-core and
>>> camel-spring-osgi; which will bring in the following:
>>>
>>> <feature name='camel-core' version='2.2.0'>
>>> <feature version="2.5.6.SEC01">spring</feature>
>>>
>>> <bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/1.4.0</bundle>
>>>
>>> <bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.1/1.4.0</bundle>
>>>
>>> <bundle>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-api-1.0/1.4.0</bundle>
>>>
>>> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.1.12_1</bundle>
>>> <bundle>mvn:org.fusesource.commonman/commons-management/1.0</bundle>
>>> <bundle>mvn:org.apache.camel/camel-core/2.2.0</bundle>
>>> </feature>
>>> <feature name='camel-spring-osgi' version='2.2.0'>
>>>
>>> <bundle>mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1</bundle>
>>> <feature version='2.5.6.SEC01'>spring</feature>
>>> <feature version='1.2.0'>spring-dm</feature>
>>> <bundle>mvn:org.springframework/spring-tx/2.5.6.SEC01</bundle>
>>> <feature version='2.2.0'>camel-core</feature>
>>> <bundle>mvn:org.apache.camel/camel-spring-osgi/2.2.0</bundle>
>>> </feature>
>>>
>>> I'm hoping there is a workaround (other than moving all my bundles
>>> from the feature file to startup.properties). There must be others who
>>> use the combination of Camel and Karaf and that need a clean way to
>>> install and start the application. Do you have any advice?
>>>
>>> Thanks,
>>>
>>> /Bengt
>>>
>>>
>>> 2010/4/28 Bengt Rodehav <[email protected]>:
>>> > Guillaume,
>>> >
>>> > I've been trying to modify startup.properties to make sure camel-core
>>> > is started by the time the feature containing my route is started.
>>> > Can't get it to work though. There are a lot of dependencies. Seems
>>> > like camel-core is dependent on a number of servicemix bundles as well
>>> > as the spring feature. I think by the end of this I'll have to remove
>>> > almost everything from my features file and put the individual bundles
>>> > in startup.properties.
>>> >
>>> > While waiting for support for specifying startup levels for features
>>> > (or something similar), is there another workaround I can use?
>>> >
>>> > /Bengt
>>> >
>>> > 2010/4/28 Bengt Rodehav <[email protected]>:
>>> >> Just sent a mail to [email protected] regarding this.
>>> >>
>>> >> /Bengt
>>> >>
>>> >> 2010/4/28 Bengt Rodehav <[email protected]>:
>>> >>> Thanks Guillaume,
>>> >>>
>>> >>> Yes, I agree, it would be much better if Camel published services that
>>> >>> my services could depend on. I'll bring that up on the camel-dev list
>>> >>> as you said.
>>> >>>
>>> >>> Do you have any details regarding enhancement plans for Karaf features?
>>> >>>
>>> >>> /Bengt
>>> >>>
>>> >>> 2010/4/28 Guillaume Nodet <[email protected]>:
>>> >>>> Yes, there are plans to enhance, but I don't think this is the problem
>>> here.
>>> >>>> This is a service dependency problem and those should either be
>>> captured by
>>> >>>> camel
>>> >>>> or by your bundle itself. Actually, I think camel should be enhanced,
>>> >>>> because it waits
>>> >>>> for bundles containing components to be started without using
>>> services, and
>>> >>>> that's wrong.
>>> >>>> The way to go would be to have a bundle tracker registering a service
>>> for
>>> >>>> the component,
>>> >>>> even if it's a simple factory and not the real component. That would
>>> allow
>>> >>>> to have the
>>> >>>> spring-dm / blueprint application to add a reference to the component
>>> >>>> somehow.
>>> >>>> Or have the camel context wait for the component to become available
>>> with a
>>> >>>> timeout
>>> >>>> to cope with such ordering problems. Not sure exactly what the best
>>> way
>>> >>>> is, but there is
>>> >>>> definitely something to improve, as the current behavior is bad.
>>> >>>> You should bring that on the camel-dev/user list imho.
>>> >>>>
>>> >>>> On Wed, Apr 28, 2010 at 11:43, Bengt Rodehav <[email protected]>
>>> wrote:
>>> >>>>
>>> >>>>> Thanks for your reply Guillaume,
>>> >>>>>
>>> >>>>> I've now added a few bundles in the startup.properties (url handlers)
>>> >>>>> and I get this to work. I used the startlevel 40. Is that OK or is
>>> >>>>> there a best practice for this?
>>> >>>>>
>>> >>>>> However, I then move on to my bundles containing camel routes. They
>>> >>>>> fail to install becuase the "file:" component is not registered yet.
>>> >>>>> It seems like this is cascading. I guess, to get this to work I must
>>> >>>>> then stop using the "camel-core" feature in my
>>> >>>>> org.apache.felix.karaf.features.cfg and put all (or some) of those
>>> >>>>> bundles in the startup.properties as well. I don't like the direction
>>> >>>>> I'm heading with this...
>>> >>>>>
>>> >>>>> Karaf features is a very good way to install/deploy applications
>>> based
>>> >>>>> on Karaf/Felix. However, there doesn't seem to be a good way to
>>> >>>>> achieve an automated, clean, install that way since there will
>>> >>>>> (almost) always be certain startup dependency ordering requirements.
>>> >>>>>
>>> >>>>> Are there any plans to enhance Karaf features? It would be extremely
>>> >>>>> useful to be able to specify the startlevel for a specific feature. I
>>> >>>>> think that would completely solve the type of problems I'm
>>> >>>>> experiencing.
>>> >>>>>
>>> >>>>> What do you think?
>>> >>>>>
>>> >>>>> /Bengt
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> 2010/4/28 Guillaume Nodet <[email protected]>:
>>> >>>>> > Right, using url handlers could lead to such problems if the url
>>> handlers
>>> >>>>> > are not registered yet. I guess a possible solution would be to
>>> change
>>> >>>>> the
>>> >>>>> > karaf configuration so that url handlers are installed and started
>>> very
>>> >>>>> > early.
>>> >>>>> > This can be done by modifying the etc/startup.properties or
>>> modifying the
>>> >>>>> > start level of the bundles for your url handlers once they
>>> installed.
>>> >>>>> >
>>> >>>>> > On Wed, Apr 28, 2010 at 09:46, Bengt Rodehav <[email protected]>
>>> wrote:
>>> >>>>> >
>>> >>>>> >> I have a problem with the startup ordering in Karaf. My explicit
>>> >>>>> >> problem is that I use iPOJO's Online Manipulator which gives me
>>> the
>>> >>>>> >> possibility to deploy iPOJO components using the "ipojo:"
>>> protocol.
>>> >>>>> >> However, it seems impossible to get an automatic installation to
>>> work
>>> >>>>> >> using Karaf features this way.
>>> >>>>> >>
>>> >>>>> >> I need to have the iPOJO Online Manipulator started (not just
>>> >>>>> >> resolved) before I even try to resolve my iPOJO components since I
>>> >>>>> >> refer to them using the "ipojo:" protocol. How can I solve this? I
>>> was
>>> >>>>> >> hoping that it was possible to specify a startlevel for a specific
>>> >>>>> >> feature (in the org.apache.felix.karaf.features.cfg) so that it is
>>> >>>>> >> guaranteed to start after other required features.
>>> >>>>> >>
>>> >>>>> >> I have the same problem when deploying a war. In that case I must
>>> be
>>> >>>>> >> sure that the "pax-url-war" feature is started first.
>>> >>>>> >>
>>> >>>>> >> This must be a common problem and I'm hoping there is a standard
>>> >>>>> >> recommended way to handle this.
>>> >>>>> >>
>>> >>>>> >> I'm using Karaf 1.4.0 and iPOJO 1.4.0.
>>> >>>>> >>
>>> >>>>> >> /Bengt
>>> >>>>> >>
>>> >>>>> >>
>>> ---------------------------------------------------------------------
>>> >>>>> >> To unsubscribe, e-mail: [email protected]
>>> >>>>> >> For additional commands, e-mail: [email protected]
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > --
>>> >>>>> > Cheers,
>>> >>>>> > Guillaume Nodet
>>> >>>>> > ------------------------
>>> >>>>> > Blog: http://gnodet.blogspot.com/
>>> >>>>> > ------------------------
>>> >>>>> > Open Source SOA
>>> >>>>> > http://fusesource.com
>>> >>>>> >
>>> >>>>>
>>> >>>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: [email protected]
>>> >>>>> For additional commands, e-mail: [email protected]
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Cheers,
>>> >>>> Guillaume Nodet
>>> >>>> ------------------------
>>> >>>> Blog: http://gnodet.blogspot.com/
>>> >>>> ------------------------
>>> >>>> Open Source SOA
>>> >>>> http://fusesource.com
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
