some, but I think I'm making good use of its fundamental capability:
hot-swapping components.
My app is a framework for hooking a varying number of command
interpreters to a varying number of communication components, thus
allowing multiple users connecting over different services/platforms
to enter commands to the system and possibly share the results with
other users.
As a result, my primary need is to be able to conveniently add, update
and remove command interpreters and/or communication components at
will. Felix has been excellent for this. Because of this I've been
able to conveniently develop new parsers to provide myself with more
configuration options and debug Camel components.
Yes, there's an issue with non-OSGi-ready libraries, but in many cases
that's just a matter of packaging them with the right manifest. The
biggest problem I've had with that is when jars depend on other jars,
sometimes four or five levels deep. But mostly this encourages me to
keep my code very lean, with minimal external dependencies, and even
with those looking for open-source equivalents to large corporate
jars.
All told, with the required modularity thinking and the encouragement
to loose coupling, I believe working with OSGi has induced me to build
a better app.
Don
2011/8/9 Teemu Kanstrén<[email protected]>:
Hello all,
I have used OSGI in a few projects, most recently in a research
prototype
for a sensor network data collection thingy.
Overall, I think OSGI is not hugely complex and provides some useful
features. However, overall my feelings are a bit mixed. So I would like
to
ask others, what are your experiences in using OSGI vs other platforms.
Some
more specific experiences from my viewpoint:
-Automated updates (or support for them) are commonly mentioned as
something
supported by OSGI. I see there is some basic support for this in
loading/unloading services and bundles in the standard container.
Additionally, there are things like Apache ACE that are commonly
mentioned
to take it further. But I fail to see how this really helps much, the
big
issue for me comes to transferring state from old services to new ones
and
managing all the dependencies between the elements as change is rarely
localized. While I have needed to support updates, I find it is easier
to
just deploy a complete new version and restart the software.
-Service code is separated by OSGI through different classloaders. For
me
this has been really nice in keeping dependencies from spreading and
forcing
me to think about component boundaries in a more focused way. But
running
an OSGI container just for this seems a bit heavyweight for me. The
classloader separation also causes some big issues for me such as
sharing
libraries over services, such as web-services frameworks, where managing
configuration files across services is just extra hard when the
classloaders
are separated, in addition to the usual OSGI classloader issues. When
libraries are better supported, such as the Felix HTTP service with
Jetty,
it seems nice but actually is a wrapper that hides the configuration
options
under layers of abstraction (added complexity) that hide the more
advanced
configuration options from me and makes it hard if possible at all to
use
them.
-Managing the framework and my application becomes more complex as the
user
has to understand the container caches, large number of directories,
libraries, configuration files, etc. Things like configuring my app to
run
as a unix daemon are much more complex to manage and debug as I am not
in
direct control over the platform. Errors in application startup from
remote
deployments are harder since they are shown mainly in Felix and not in
my
application log files.
-Using OSGI for me is a form of a local-level service abstraction (SOA).
I
have basically used Java interfaces to define the "interface" of each
OSGI
service. But this eliminates the navigation support my IDE in terms of
static analysis and adds, what seems to me, unnecessary abstration. This
is
probably my failure in using too many interfaces but it feels to me as a
"common practice" for OSGI apps. I was also looking for some support to
hook
and trace service interactions, which could justify some of this, but
there
is nothing like this.
-Integration testing is difficult due to all the wiring required to get
the
overall system running. In simple cases it works OK with my own
MockBundleContext, and the SOA approach makes the component composition
even
cleaner in this regard. However, in more complex interactions starting
the
whole container becomes a big burden for me.
Overall, the approach of SOA at local level seems great for the overall
architecture. But it seems to me currently there are just too many
issues
for me, and for that reason, I would prefer a more simple approach.
Maybe I am just doing wrong or building wrong types of apps. Any other
experiences?
Thanks for your thoughts,
Teemu
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
