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
<https://issues.apache.org/jira/browse/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
(http://liquid-reality.de/display/liquid/2013/02/13/Apache+Karaf+Tutorial+Part+8+-+Distributed+OSGi).
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.
Thanks.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com