RESOLVER PLUGIN IS INOPERABLE WITH OTHER CLASSLOADING Thomas, can you stop working on the ResolverPlugin, it is just plain wrong. One of the major points of developing the MC based OSGi facade is that OSGi bundles should be able to play nicely with other JBoss deployments. What are doing breaks that requirement. Besides that, the resolver plugin is incomplete compared to all the things that JBoss ClassLoading can do and is broken in other ways e.g. like the way it processes RequireBundle re-exports which can have additional filters on what is exported for non-osgi deployments. What I did for the original work was introduce the OSGi*Requirement/Capability as a way to add the OSGi features without distribuing the jboss-cl code initially. i.e. determine what is required before changing the classloader code. But all those features should and will "bubble up" into jboss-cl project making them redundant in the osgi code. WHAT IS REQUIRED The way to make the resolving work is to do what I said in at least two previous posts and you've ignored. That is to have "on-demand" classloading requirements handled automatically. This could be done in the OSGi code now, but it would be messy, so it needs doing properly in the jboss-cl code. There are additional requirements for osgi, which your resolver doesn't handle either. 1) Introduce a ClassNotFoundException handler This will allow dynamic imports to force a resolution of a bundle that isn't in the resolved state rather than throwing an error 2) Introduce a repository api This will allow both the normal and dynamic imports to load a requirement from a repository. i.e. a bundle/deployment that isn't even installed. Both of the above need to be completed in jboss-cl for the OSGi classloading work that I'm doing. There is some additional work to the ClassLoading/Module api so that the PackageAdmin api can be implemented on top it, and finally fragments and extension bundles need to be supported. The current resolver plugin certainly can't handle some of these and in most cases, we want these features in the core classloading - it shouldn't be OSGi specific. Remember the OSGi framework should just be a facade on JBoss MC features. If the JBossMC feature doesn't exist, it should be added. The only reason to do it in the OSGi project is to determine what is required before it goes in the main codebase. I'm working on doing all this, or at least putting the mechanisms in place so they can be done - so you are just wasting your time, trying to do duplicate stuff that can't possibly be implemented/extended in the way you are doing it. DROOLS PLUGIN On a further topic, the osgi-mc integration project (reactor/framework) is not the place to put things like the drools plugin. As a matter of of general policy, it should live in a seperate project so you don't force an optional plugin (along with all it dependencies - it's a lot for drools) on all users. But, the MC/ClassLoading already has mechanisms such as being able to write your own Requirement/Capability to handle things like this. It doesn't need a "plugin". e.g. something like: | <classloading ...> | <requirements> | <drools-requirement> | rule: | etc. | </drools-requirement> | ... | Even if that is not the level you want to do it at, the extension mechanism belongs in jboss-cl not the osgi facade, so it can be used for everything. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265057#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...