felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Teemu Kanstrén <tkanst...@gmail.com>
Subject Re: Fun with OSGI
Date Fri, 12 Aug 2011 07:36:45 GMT
Hi Donald,

 Thanks for your experiences. I can see it being very useful if you need to
have several users at the same time updating a set of commands. Did you use
the basic OSGI features for this or something else on top of it?

 Besides the standard class-packaging issues and manifesting, another issue
for me has been that I was never able to figure out how to configure shared
bundles (e.g. framework libraries) differently for different bundles using
them inside the same OSGI container. Because the libraries use their own
classloader to load the configuration or something like that. But yes, the
most common issues is the manifest thing and related issues, including the
need to understand the gory details of all the issues.

 I do agree that on the design front using OSGI encourages better design.
That's a big plus.


2011/8/9 Donald Whytock <dwhytock@gmail.com>

> My experience with OSGi/Felix is comparatively limited compared to
> 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 <tkanstren@gmail.com>:
> > 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
> > 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
> For additional commands, e-mail: users-help@felix.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message