felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Fun with OSGI
Date Tue, 16 Aug 2011 17:06:50 GMT
Hi,

I don't really like to make advertisements :-)
but since you are looking on a nice and easy way of doing Unit Tests
with OSGi did you take a look at Pax Exam [1]?
It's exactly build for this. You can create your unit test even depend
on services and Pax Exam will run it on
any kind of OSGi container if needed :-)

Regards, Achim

[1] - http://team.ops4j.org/wiki/display/paxexam/Pax+Exam

2011/8/16 Teemu Kanstrén <tkanstren@gmail.com>:
> 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..
>
> Teemu
>
> 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
>> 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
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>



-- 
--
*Achim Nierbeck*


Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
blog <http://notizblog.nierbeck.de/>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message