FWIW,
I want to echo what Jens has said. We are using Kura and running
into exactly the issues WRT ConfigurationAdmin and Kura that Jens
describes.
In addition, we are very eager to move to a more recent version of
config admin...that supports DS 1.3 features...e.g. [1]. As well,
there are even further (very nice) changes for config admin in R7
spec being completed now.
We are eager to do this is that these more recent features will
make development for our analytics framework significantly easier.
Scott
[1]
http://njbartlett.name/2015/08/17/osgir6-declarative-services.html
On 1/18/2017 12:22 AM, Jens Reimann wrote:
So that may solve this single one issue, having
duplicate services instances. It does not solve the
other issues. It does not solve the issue that a Karaf
user will configure stuff using the OSGi ConfigAdmin,
which will then still create an inconsistent system. And
it will create even more legacy code. Making the
ConfigurationService even more complex.
But this could be a super-short-term solution in order to
have something ready for one of the milestones.
In the end we have to make Kura more OSGi friendly. And
re-implementing the whole ConfigurationAdmin (as the
ConfigurationService does) because the Equinox
implementation cannot be trusted is not OSGi friendly. And
causes a set of issues.
So I think the correct approach is not to add more complexity
in order to fix issues created by that approach in the first
place. But to get rid of this complexity by sticking to the
core functionality (the OSGi ConfigAdmin).
We can start this improvement during the 3.0 cycle (as the Kura
configuration bundle is already a separate bundle) and work on
this in parallel.
_______________________________________________
kura-dev mailing list
kura-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kura-dev