Hi all
I'm building an application on an embedded system which will contain ~20
bundles.
There are many dependencies of services - say for example to provide its
service, module A (several classes) needs services B,C,D.
In order to fully account for the dynamics of OSGi, I have to monitor
B,C,D to stop A when any of these 3 goes away. This unregisters service
A, which in turn will disrupt all clients of A.
If additionally you want to handle part case (A should still provide a
reduced service, if only B and C are available but not D) it gets messy
rapidly.
In the end, I realize that I am mostly writing life cycle code instead
of business logic and I have lots of OSGi dependencies, with the
BundleContect passed around nearly everywhere. This smells like bad design.
Could you share insights or recommend reading on how to structure OSGi
services for cohesion and modularity, to avoid the problems above?
Are there ways to reduce the boiler plate?
Should I be investigating declarative services, iPojo or others (in
general I prefer writing code than XML...). As this is an embedded
system, should I be worried about the performance impact of DS?
Thanks for your insights
Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
