cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Fwd: DOSGi - service not exported consistently
Date Fri, 22 Mar 2013 14:29:21 GMT
On 22.03.2013 12:39, A. Rothman wrote:
>>> 1. Is DOSGi being updated to work with OSGi 4.3.0/Felix 4.x/Karaf 
>>> 2.3.x etc.? It seems to be slightly outdated. At a glance, it looks 
>>> like making it compile against OSGi 4.3.0 requires just a few 
>>> backward-compatible syntax changes, and hopefully the semantics have 
>>> not changed too much.
>> DOSGi should work with all newer versions of Felix and Karaf. The 
>> OSGI 4.3.0 spec should be compatible to 4.2.0. So this should also work.
> I'll open a separate JIRA issue for fixing the compilation errors with 
> 4.3.0.
Have you tested the OSGI 4.3.1 spec from maven? It fixes some compile 
errors with Java 7. This should only be a compile problem anyway. At 
runtime DOSGi should not have any issues.
>>> 2. The website says on the Karaf feature page: "CXF DOSGi does not 
>>> work with Karaf 2.3.0", however it does not mention whether this 
>>> applies to 2.3.1 as well (is it a DOSGi issue or Karaf issue that 
>>> prevents it from working?), nor does it say anything about what the 
>>> problem is, where it might be relevant, or link to any issue in JIRA 
>>> - could someone in the know please update the text to be a bit more 
>>> informative? Also, is this indeed just an issue with installation 
>>> via the feature, or with compatibility between the projects/versions 
>>> in general regardless of installation method?
>> The website says "The default aegis data format will not work with 
>> Apache Karaf 2.3.0. (See DOSGI-153 
>> <>). Please upgrade to 
>> Apache Karaf 2.3.1".
> True, but I was referring to the "CXF DOSGi in Apache Karaf" feature 
> page which says "CXF DOSGi does not work with Karaf 2.3.0. Please use 
> the latest 2.2.x version for now." So it's even more confusing now - 
> does one need to downgrade to 2.2.x or upgrade to 2.3.1? Is there a 
> separate problem with the feature installation, or is it the same 
> problem referred to on both pages? I think it's safer to leave a 
> notice on both pages (you never know how people reach the links), but 
> they should be clarified and/or updated with the latest issue links 
> and workarounds.
I just tested my DOSGi tutorial with Karaf 2.3.1 
It worked without any problems. I updated the page so it now recommends 
to update to karaf 2.3.1. Of course DOSGi will also work with Karaf 2.2.x.
>>> 3. After all the fixes above, the export success rate is definitely 
>>> better than 50%, but still isn't 100% - every once in a while the 
>>> export still fails. Looking through the logs, I found the message 
>>> "RemoteServiceAdmin Implementation is shutting down now" - during 
>>> Karaf startup! I'm still not sure what exactly is going on, but it 
>>> appears that the RSA is started, services exported properly etc., 
>>> but then it suddenly commits suicide a few moments later with no 
>>> other error or indication of who/what initiated the shutdown or why. 
>>> The initial theory is that the dsw Activator might be getting a 
>>> ConfigurationAdmin updated event with null configuration, which 
>>> would trigger a shutdown - but I haven't yet confirmed that this is 
>>> the case, nor why it would happen or what the proper behavior in 
>>> such a case should be.
>> I have not yet seen this problem. If you can find a way to reproduce 
>> it I would be very interested in your findings.
> I'm not sure how to reproduce it in a test case, though it happens 
> quite often in my project (Karaf 2.3.1 with activemq 5.8.0 and DOSGi 
> 1.4.0 installed from their respective features), with a handful of 
> custom bundles which use a trivial/default DOSGi configuration. The 
> only interesting thing I can think of about them is that some of them 
> register their exported services asynchronously when their dependent 
> services and internal state are all up and running, as opposed to 
> registering in the bundle start method like some simple bundle 
> examples do - but I really don't know if this is related. In any case 
> I'll open a separate JIRA issue for this with the findings and patch 
> from my previous post.



Christian Schneider

Open Source Architect

View raw message