Hello, This is the use case I'm implementing... My first "real" OSGi project is a web front end for a lightweight ERP platform that bundles a AJAX/JS GUI framework (the "back office", no OSGi), where the front end (OSGi) runs in a separate process with an embedded Jetty web server. The front end uses a templating engine for rendering ad-hoc user interfaces with the ERP platform used as a data source (with rules, ACL, etc). Templates can be modified in real time... and code too, hence the choice of OSGi. That's the context of what I'm doing.
The application is delivered as an executable JAR with Felix in the classpath and the OSGi bundles are embedded in the JAR (but not in the default classpath). The executable JAR unpacks the embedded bundles onto the filesystem, configures Felix in embedded mode, then installs the bundles (including fragments), starts them (excluding fragments), and sets up a filewatcher so that changes to the directory are detected and bundles started as needed (if the client drops in a new custom bundle, it auto-starts, the client can also drop in hotfix upgrades). These design goals, which seem similar to yours, work well with Felix. The aim is to have everything (code & UI) fully dynamic, i.e.: the application shouldn't ever need to be fully stopped, including patches, minor upgrades, and possibly major ones too, as well as adding/updating/replacing plugins. A bit more detail which may be helpful: all installed bundles are INSTALLED in the framework sense, but then a little extra logic is applied: only the most recent version of a bundle is explicitly STARTED (the others may be started implicity if required, but this can create class space divisions). Also, the filewatcher notifies removal of bundles, triggering stopping of the bundles within the framework. As soon as a bundle is added again, the host application tries to start any "required" bundles that were knocked offline by a previous change (because deleting then replacing a bundle -- as opposed to a one-step upgrade -- can take others offline, and there's no automatic restart logic in this case). The host application requests PackageAdmin->refresh as required to re-wire stuff. For info, about filewatching, I use a little abstraction layer, which (when possible) uses JXFileWatcher, falling back to a polling technique, and capable of delegating to Java 7 filewatching at some point. The filewatching/update logic is in the host application because JXFileWatcher binds to a native library using JNI (so loadLibrary doesn't play nice with bundle restarts if I implement in a bundle) and because we'd get stuck if the "system update watcher" bundle got stopped unintentionally. This works for me. I have a suspicion OSGi start levels could be of some use here too, I haven't looked into that much however. Hope the details (without naming products!) are helpful. Just for the bonus: the container is also useful in unit testing: each bundle gets tested in the framework in isolation, using another mock bundle and a test fragment that attaches to the bundle being tested, in the same package. Getting JUnit to play nice was a bit tricky though, especially creating test instances with access to the bundle context. It's doable though, without hacking JUnit... -- Christopher On 14 July 2011 23:00, <john.dun...@exceter.com> wrote: > > I would like to hide the update mechanism from the end user. As far as the > client is be concerned, the application should be versioned as a whole. For > example, I would like the client to see that an update from version 1.2.3.4 > to 1.2.3.5 is available. Behind the scenes the update would be a collection > of bundles. The bundles would be versioned separately but the > update(collection of bundles) would be tested as a unit in my test > environment before being made available to the client. > > I'd also like to be able to give the client a menu for falling back to a > previous version.
