7:52 a.m.
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...