"scott.stark(a)jboss.org" wrote : Being able to support osgi deployments is the only real plan. What I started was an osgi bundle implementation on top of the vfs as a replacement for the unified class loader. | "bill.burke(a)jboss.com" wrote : This means we will have to refactor our UCL layer to support their classloader notions. "scott.stark(a)jboss.org" wrote : The class versioning in osgi comes from the bundle | class loader, and its really a package level versioning. We will have an | osgi compatible class loader in the mc/jboss5." Ok, so there was not a clear understanding. But it doesn't hurt to have both options (current impl with delegation to existing OSGi framework and new UCL layer) ;-). So basically we want to have a whole new CL layer with versioning on packages available, e.g.: | Export-Package: org.osgi.util.tracker;version=1.3 | Import-Package: com.acme.foo;version="[1.23, 2)" | And this is what was already started by Scott. Why the need of using OSGi interfaces - Bundle, Activator, ... ? How do we start this UCL refactoring? Once we have this, I think service lookup / registry via Class instance (or ClassName + version) is trivial, since MC at state machine level ([Abstract]Controller) is (String) name unaware - name is plain Object (eq. via hash). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021090#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...