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="";>
     <resolver uri="url:">
       <init path=""/>

(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  

<web-app xmlns="";>
     <module org="" 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:

<web-app xmlns="";>

   <osgi-bundle org="" 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  
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

Reply via email to