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 Tue, 16 Aug 2011 16:36:41 GMT
Hello Peter,

 I think you are quite correct in your analysis. My problem is perhaps that
I was experimenting with "too much" modularity in OSGI terms. In taking my
application, splitting this into modules providing services with clear
responsibilities, and composing it from these. In this case there is no real
intent for me to ever replace one service with another. I just like the way
it helps me avoid spaghetti et al. I shall have to look at the projects you
link and try if they fit me better. I think perhaps without classloaders it
is not possible to achieve some of the bigger benefits in OSGI, so maybe it
is more of a platform (JVM) issue as well.

 I do not really have a problem with the container startup time. Just the
fact that I cannot control it. If I start write a unit/integration test I
prefer to keep it simple and run relatively fast. With OSGI (Felix) I could
not figure how to do that simple and easy without starting a different JVM
for the container. Well, I managed some hacks but it wasn't so easy.

 For the configuration, I would not call most classloader use hacks really,
since this is mostly for me the best way to access resources bundled with
the application jar file. Perhaps it is more a problem with the way
frameworks and libraries are built to not provide alternative means. That
could be hard to change, so I do not know if alternatives could be found to
make it easier to adapt existing ones. Probably would exist if it was. I had
a look at the bndtools site but as you say I am a control freak so probably
not my thing.. :)

Thanks for you input..


2011/8/15 Peter Kriens <peter.kriens@aqute.biz>

> I think you run in the problem that you want to have your cake and eat it
> too. OSGi is implementing a modular system and enforces this modularity. As
> you acknowledge, this gives a lot of advantages. Many of the problems you
> find are then related to the problems this modularity causes (class
> loaders!) and not having access to the implementation details.
> The problem is that if you do not enforce modularity, it will not be
> modular. Unfortunately, in the Java world there are many popular hacks that
> are just not modular. Trying to merge these worlds can be painful. If you
> have proper modularity, you should not be able to navigate in your IDE
> because an implementation could be substituted. Hiding the implementation
> maybe makes it harder to use the special options but it eases migration and
> makes your code more robust because it has less special dependencies.
> Integration testing is less valuable but unit testing is crucial.
> Your pain seems to be that you have to give up control in certain areas. I
> believe that this is an aspect of modularity/component programming and not
> inherently OSGi. It is up to you to decide if the benefits of modularity are
> worth the pain ... I think they are.
> That said, we're currently working on a specification that will allow the
> OSGi service API to be used without the class loader model. See
> http://code.google.com/p/pojosr/ or
> http://www.osgi.org/blog/2011/04/osgi-lite.html for more. This will give
> you the service model but it will not force you to be modular, class loader
> hacks still work.
> Kind regards,
>        Peter Kriens
> P.S. Somehow it feels like you see the "container" as too big. It takes
> +/-100ms to start a framework. So if you're testing you do not need to
> create a MockBundleContext. Anyway, MOST of your code should not see a
> BundleContext ever. Did you look at bndtools?
> On 9 aug 2011, at 20:01, Teemu Kanstrén wrote:
> > 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