Well, there is another thing that is unusual about our environment.
Most OSGi environments run with the OSGi container as the primary
framework, with servlets running inside via the OSGi HttpService. In
our case, OSGi is used as an embedded plugin framework for large,
existing, non-OSGi-based webapps. You can see more about our
architecture in these slides if you're interested: http://www.slideshare.net/mrdon/the-web-on-osgi-heres-how
On Nov 12, 2009, at 11:12 AM, David Boyer wrote:
Tim,
Currently we've done something similar, except that we took the
shindig war-file, and built the equivalent of a webapp, that we
surface to an embedded jetty. We don't do the servlet mapping, we
just take it and expose it through the embedded jetty.
Personally I'm new to using OSGi (3 months), and most of my work to
date hasn't needed a deep thorough understanding of it, but with my
limited knowledge I believe you avoided what we think we want to do:
a. Modify maven so that it can produce OSGi bundles for each of the 4
shindig jars (social-api, server, gadget, and common).
b. These bundles would include package import directives which would
result in the shindig dependencies getting picked up from OSGi.
c. Use internal OSGi extensions to surface the OpenSocial servlets to
our web application.
Why did you avoid using 4 bundles instead of one?
In our case, we're integrating Shindig with several different
applications that share the common OSGi-based plugin framework but are
otherwise very different. We wanted to encapsulate Shindig and provide
a very simplified API/SPI that only exposed a small number of
interface points. The teams responsible for the integration could then
focus on using those, without having to be intimately familiar with
Shindig itself. Other functionality that was common across our
applications is managed by the layer of code that lives in our bundle
(what we call the atlassian-gadgets-opensocial-plugin).
-- Tim
