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.) A) Ivy 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: <resin xmlns="http://caucho.com/ns/resin";> <module-repository> <resolver uri="url:"> <init path="http://library.foo.com/ivy"/> </resolver> </module-repository> (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 efficiency): <web-app xmlns="http://caucho.com/ns/resin";> <class-loader> <module org="com.foo" module="my-module" rev="1.0"/> </class-loader> 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: <web-app xmlns="http://caucho.com/ns/resin";> <osgi-bundle org="com.foo" module="my-module" rev="1.0"/> </web-app> 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 inside Resin. 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 resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
