Hello Stefan, On Apr 26, 2008, at 13:28 , Stefan Zoerner wrote:
sorry, if this is slightly off topic. I try to figure out how to design an application which leverages the dynamics and extensibility of OSGi (general design principles).
I don't think it's much off topic.
Eclipse is always the first example people cite as an as a production ready, successful application based on OSGi. This may direct one to think that Eclipse uses OSGi best practices a lot, and copying Eclipse design decisions as patterns leads to a good design automatically.
Eclipse is an example of an existing application that had a different "plugin model" that was migrated to OSGi. In fact, quite a few things in the R4 spec were added because they were used in Eclipse. To be fair to the Eclipse developers, they had to make quite a few trade- offs to remain compatible with earlier versions and not alienate a huge number of plugin writers. That has lead to decisions that might have been made differently if they had started from scratch.
I am quite sure that this does not hold true. For instance Eclipse uses dependencies between bundles a lot, although the preferred way to manage dependencies is via packages (as it is said in the spec and may online resources).
Yes, that is indeed one of these examples. Require bundle dependencies basically define dependencies in terms of "implementations" (if you look at bundles as implementations) instead of "interfaces" (which is what happens most of the time when you use the import/export model of defining dependencies.
Do you know other examples for decisions made in Eclipse, which cannot be used as general design principle. Or the other way around: anything, that *can* be recommended.
One of the other big points of discussion is the Service vs Extension model. In fact on the Felix website you will find an example that implements a simple paint program using both methods. I have a strong preference for the service model because it has a cleaner life cycle and because that was the way OSGi was intended. Eclipse used extensions though because they argue it leads to faster startup. Startup for them matters enormously, since they have a lot of features that can be "loaded on demand". Extensions start faster basically because they don't lead to an "event storm" (associated with the life cycle model of services). On the other hand, I have the feeling that nobody really tried hard to optimize these events for startup time, and that there might be other ways to "not load everything at startup". For example, one could decide not to load a bundle at all until a user triggers some functionality, or to only install (and resolve) it, but not start. Anyway, I'm probably going to get trigger some opposing views with my responses here as this is a topic that's still under discussion.
In general, it's hard to recommend certain solutions, because a lot of decisions depend on actual requirements that often conflict.
An often used pattern is the whiteboard pattern. You can find that one on the OSGi site.
One thing to watch out for is not to go overboard on defining utility classes as bundles that export their classes. Especially if such utility classes are used all over the place. If lots of bundles actually depend on those classes, then updating them often equals almost a full restart of your application. Instead, embed utility classes in your bundles and use tooling that actually allows you to only embed things you actually use (if you care about minimizing code duplication).
I'm sure there are many other things people will add to this list. :) Greetings, Marcel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
