Adding a ClassLoader import exclusion filter

[jason.greene]

We seem to have some cases where we need an isolated deployment to ignore specific packages from a parent. A common example would be a WAR shipping its own implementation of JSF.

Anther similar case is a deployment wanting to exclude particular resources. As an example, a child deployment of an isolated ear may call getResources("META-INF/common-name.xml") and end up pulling in stuff from the server that it does not actually want (in particular non isolated deployments).

To solve the former, I was thinking about adding an enhancement to classloading that would allow a policy to exclude a package list from all parent and/or module imports.

Does this sound reasonable? Or am I missing something?

[dmlloyd]

If you generalized it to a filename pattern you could exclude the META-INF stuff too, no?

[alesj]

You can already do all of these things,
most of if just requires proper ClassLoadingMetaData / jboss-classloading.xml configuration.

Or you have to override some of the Module, ParentPolicy and ClassLoaderPolicy behavior,
providing your own impl via new CL deployer.

[jason.greene]

"alesj" wrote:
You can already do all of these things,
most of if just requires proper ClassLoadingMetaData / jboss-classloading.xml configuration.

AFAICS a deployment can only exclude classes that it contains (excludes) or that it exports (excludeExport). A deployment could achieve this by defining all the package requirements for every EE and JBoss API it uses, however this could end up being overly verbose compared to a simple exclusion. What I am talking about would be something like a new excludeImport value which would take precedence over any import (either importAll or via module imports). However, I don't want to add it if this would violate the intentions of the design, or if you guys think it would be a bad practice.

[alesj]

What I am talking about would be something like a new excludeImport value which would take precedence over any import (either importAll or via module imports).

Where and how would this excludeImport fit in?

[adrian.brock]

"alesj" wrote:
You can already do all of these things,
most of if just requires proper ClassLoadingMetaData / jboss-classloading.xml configuration.

AFAICS a deployment can only exclude classes that it contains (excludes) or that it exports (excludeExport). A deployment could achieve this by defining all the package requirements for every EE and JBoss API it uses, however this could end up being overly verbose compared to a simple exclusion. What I am talking about would be something like a new excludeImport value which would take precedence over any import (either importAll or via module imports). However, I don't want to add it if this would violate the intentions of the design, or if you guys think it would be a bad practice.

I don't see a problem with it in principle.

If you add an "exclude import filter" to the ClassLoadingMetaData which gets copied
into the ClassLoaderPolicy then it would just be a simple piece of code
that goes directly to loadClassLocally() instead of loadClassFromDomain()
when it matches the filter - and the same for resources/packages.

The only thing it would complicate/break would be the consistency checking of the
ClassLoaderSpace. If one of your imports also has something but you always want
to use your local version then there is a potential for ClassCastException, etc.
in cross classloader calls.

However, if you are using this feature then you've already said you don't want
to share, so presumably you've done the analysis?
Such an analysis can get quite complicated.
e.g. the common problem is people putting a different version of the jaxp classes
in WEB-INF/lib which then has knock on effects if for example you want you're
jaxb stuff to use it rather than the version in the JDK and not get ClassCastExceptions.

[hostalp]

Yeah, I also vote for import filter option in order to prevent some packages/classes to be accessible from within the app. Something like Filtering Classloader on WebLogic for example: http://download.oracle.com/docs/cd/E12840_01/wls/docs103/programming/classloading.html#wp1097187 would do the trick.

In particular I'm packaging some stuff in the app (like hibernate, jaxb etc) which exists in JBoss as well and I don't want to use those from JBoss in my app.

AFAIK this isn't currently possible to achieve on JBoss in the easy way. Or am I wrong?

Also the documentation for this classloding configuration is in very bad shape. There are pieces here and there, one must read sources sometimes etc. That really ****. A good, comprehensive documentation with simple and explained examples - all at one place - would be great.

[alesj]

AFAIK this isn't currently possible to achieve on JBoss in the easy way. Or am I wrong?

* http://community.jboss.org/thread/156441?start=0&tstart=0

[hostalp]

Alright, thanks, that finally looks promising. I'll followup there as I've got some questions regarding configuring.