Brief history - we initially wrote this app last year as pure OSGi running on Spring DM Server. For a variety of reasons, that didn't work for us, and we ended up refactoring into a monolithic web app in a single WAR file. We kept the modularity mostly intact, knowing we needed to go back to a plug-in based model in the near future - basically we are using our spring application context as a surrogate for the service registry.
Now it's time to add the plugin capabilities back in, and our goal is to keep 70% of the functionality in the main web app itself, and just use OSGi to manage plugins for customizing and extending this app. I've been reading the page on embedding and playing with a sample project, and so far so good. Now the tricky part is how to deal with 3rd party libraries used both within the webapp and within the OSGi environment. Here's where I need to verify my approach before I dive into the abyss. As a simple, concrete example, we want to be able to contribute Wicket components as plugins (this is just one of many plugin areas depending on 3rd party libraries - Drools and Hibernate are 2 other biggies). Since the wicket jars already exist on the web application classpath, it looks like I should be able to just pass all the wicket packages (along with any transitive dependencies) to Felix using the org.osgi.framework.system.packages.extra property. My understanding is this will make all those packages available as part of the system bundle, which conceptually seems like the same thing many frameworks like DM Server do for things like the servlet api, spring, etc. Am I on the right track here? A few specific questions: 1) What kind of classpath issues would I need to be aware of using this approach. 2) Will the system.packages.extra property take wildcards in the value, similar to a manifest import-package statement? IOW, can I just list "org.apache.wicket.*", or do I have to list out every single package in wicket? Also, can I specify versions on these packages like in a manifest? 3) I've already separated out our application-specific interfaces into a separate bundle, which is included in both the main web app and the bundle dependencies. I assume this is the correct approach, based on my reading. 4) What about build-time dependencies on 3rd party jars like wicket within the bundles themselves? It seems like it should be sufficient to just include the wicket, etc. dependencies in the pom so it can compile against those classes, but at runtime they will actually be resolved through the system bundle. Any problems with that, or should I create another bundle used just for building that exports all of the 3rd party interfaces (i.e. with a proper OSGi manifest)? 5) The other big hiccup I can see is debugging in Eclipse. Debugging the main webapp on Tomcat is a no brainer, but I'm trying to figure out the best method to drop the plugins into our debugged instance of Tomcat, short of having to do a Maven build each time, then copy the plugins to an autodeploy directory. Any suggestions for streamlining this process? I think Pax had a project that let you deploy bundles from an exploded directory instead of a jar, but I think it relied on the PaxRunner stuff to work. Anything else similar to this? If I could just point our embedded Felix instance at our source directory, that would save a lot of time. Thanks in advance for any advice. Mike
