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 <[email protected]>: > 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 <[email protected]> > >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > -- -- *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: [email protected] For additional commands, e-mail: [email protected]
