This is a work-in-progress, but I thought you'd like to know our
current direction on this.
We're viewing ivy/osgi as basically a smarter WEB-INF/lib. With all
the libraries people include in their projects, it's becoming
difficult to keep versions straight and consistent. And the extra
libraries are puffing up the sizes of .war files to large and
difficult-to-maintain and deploy sizes. (Or if not necessarily
difficult, at least inelegant.)
Our model is for Resin to manage a repository of artifacts (basically
jars) at the top-level (either <cluster> or <resin>), and let
applications pull in the jars as necessary for the application. It's
an ivy cache repository managed by Resin and integrated into Resin's
classloader environments. The repository can populate itself by
loading jars from public repositories, the filesystem, or your own
local repository distribution system. So you might have something like:
(Basically identical to the ivy model).
In your resin-web.xml (or resin.xml), you could use a module/jar by
its symbolic name. The following configuration would add the my-
module jar to the web-app's classpath. The physical location of the
jar would be Resin's top-level repository, so multiple web-apps would
share the same .jar file (which helps the JVM's virtual memory
<module org="com.foo" module="my-module" rev="1.0"/>
B) OSGi (bundle/classloader features)
An OSGi bundle is basically a .jar file with some extra ivy-like
dependency metadata in the manifest to properly hook up the right
versions of a jar's dependencies. There are a few classloader tricks
to encapsulate and hide private implementation classes which is also
nice. By integrating the OSGi versioning with the ivy versioning, we
think we can combine the ivy/OSGi concepts into a single framework.
Currently, the configuration for an OSGi bundle looks like:
<osgi-bundle org="com.foo" module="my-module" rev="1.0"/>
C) OSGi (service features)
Along with its bundling/versioning, OSGi also provides a service
lifecycle and registration system. A good example might be a single-
signon authentication service that's available for all the webapps.
There's a manifest entry and an Activation class which will tell OSGi
to start the service when Resin starts up.
Future (3.2.1?): we're looking at publishing those services
automatically with WebBeans. Your application could use an OSGi
service (like the authentication), by using "@In Authentication _auth;"
Future (3.2.1?): we're also looking at configuring and publishing the
services with WebBeans and Resin's standard <bean> syntax. This is
very similar to what Spring is doing with its OSGi platform. We'll
probably also provide a plugin to publish those services to Spring
Future (3.2.2 ?): interestingly, Spring has proposed an OSGi plugin
for the above two capabilities, using Spring's configuration syntax.
Since it's a proposed standard, and the underlying IoC capabilities
are similar to Resin's, we may implement this as a way of better
integrating Spring applications and OSGi modules with Resin.
resin-interest mailing list