Dear Stefano
While I understand your arguments historically, I think this decision
should be questioned today.
Regarding configuration through System Properties. Even when running
ZB4O without an OSGi framework, providing the configuration in a
ConfigAdmin compatible way is as simple as passing a Dictionary to
update(). I very small helper class which reads System Properties and
encapsulates them in a Dictionary would do the trick and allow those
using OSGi (a majority I guess) to fully profit of ConfigAdmin advantages.
Regarding backwards compatibility: Java 5 which introduced generics is
now 10 years old. Do you know of users which still rely on a 1.4 JVM?
Currently all kinds of platforms have a valid modern JVM - in particular
Oracle is strongly going into this by providing full Java SE 8 VMs for
ARM systems. I guess it is not a large break to pass on to the next step.
Regarding OSGi 3 vs. 4: I'm not sure, but would guess that an external
dependency management system (eg. Felix DM) which is not part of the
OSGi spec can also run on OSGi 3. All the basic service functionalities
haven't changed. If you are interested, I could investigate this.
Regards Philipp
On 13.01.2015 11:50, Stefano Lenzi wrote:
Dear Philipp,
please se my comment inline...
Il 13/01/2015 09:32, Philipp Buluschek ha scritto:
Dear all
I see that diverse ideas point at refactoring parts of ZB4O. I
suggest that we refactor ZB4O to use a dependency manager, which
would result in cleaner and more robust code:
Currently all Service and Config dependencies are handled explicitly
by hand. This makes it very hard to get right, as any service might
appear or disappear at any time and dependent services must then
adapt. Also, the current code uses a mix of ConfigAdmin values,
System Properties, and BundleContext properties to configure the run
time.
The original idea was to enable no-OSGi user to use part of ZB4O as
library that's why some part of the code are based on System
properties for configuration, I think that the idea is still valuable
but we may have to provide a better separation.
This could easily be refactored to uniformly use ConfigAdmin with a
dependency manager. OSGi offers diverse possibilities to handle these
dependencies automatically and cleanly using a dependency managers,
of which the mains are: Declarative services, Blueprint, iPOJO and
Felix DM.
In my code, I use Felix DM very successfully.
Using a dependency manager would result in cleaner code because all
the OSGi "plumbing" (which service needs what other service and what
config to work) is being done in one single place, outside the code
(or with annotations). This also results in the objects having less
dependencies on the org.osgi packages.
The rationale for not using any dependency manager is that our goal
was to target OSGi v3 running on JVM 1.4 at most, thus there was no
chance to use any Dependency Manager. So, unless some architecural
change is needed, I would avoid to introduce any spec of OSGi v4,
which will increase the footprint for executing ZB4O.
What do you think about this?
Regards
Philipp
_______________________________________________
Dev mailing list
[email protected]
http://zb4osgi.aaloa.org/mailman/listinfo/dev
--
________________________________________
Philipp Buluschek, Dr.-Ing.
Adhoco AG
Althardstr. 70
CH-8105 Regensdorf
Phone: +41 52 264 5081
Mobile: +41 79 800 8218
________________________________________
_______________________________________________
Dev mailing list
[email protected]
http://zb4osgi.aaloa.org/mailman/listinfo/dev
