felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Embedding felix - will this approach work?
Date Sun, 04 Apr 2010 13:05:34 GMT
On 4/4/10 6:34, Mike Haney wrote:
> 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?

Sounds like it.

> A few specific questions:
> 1) What kind of classpath issues would I need to be aware of using this
> approach.

As long as the class loader that loads the framework classes has access 
to the packages you want to provide, then it should work.

> 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?

Neither Import-Package, nor system.packages.extra support wildcards. You 
have to specify them all. The same syntax for Import-Package is used, so 
you can specify versions.

> 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.

Sounds like it.

> 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)?

I don't think that is necessary. You could get some benefits if you had 
a regular bundle and you are using maven-bundle-plugin or BND to 
generate your bundles, since it will include proper versions for your 
bundle imports. Also, if there are some packages you do not want your 
bundles to have access to, then you could exclude them from the exports 
of your libraries, but otherwise it probably doesn't really matter.

> 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.

I am not sure the best way to streamline this. The Felix framework 
supports installing an exploded bundle directory, but you'd still need 
to manually perform an update inside the framework once the contents 
changed. Maybe someone has created something to automate that as part of 
the build process.

I admit to not having a lot of practical experience with bundle 
projects, since I spend most of my time hacking on low-level framework 
issues, so maybe someone else has better advice on all of these issues.

-> richard

> Thanks in advance for any advice.
> Mike

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

View raw message