Dear Philipp, On Wed, Jan 14, 2015 at 9:51 AM, Philipp Buluschek < [email protected]> wrote:
> 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. > I agree on this, it will be simple to split OSGi-ware from Plain Java part. > > 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. > I know that some telco provider that want to use cheap HW cannot afford Java 5 running on their chip because there is no support. > > 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. > I would appreciate if you some time to spend on this topic :) > > Regards Philipp > Ciao, Stefano > > > > 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 > [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 > >
_______________________________________________ Dev mailing list [email protected] http://zb4osgi.aaloa.org/mailman/listinfo/dev
