how to re-configure class loader policy?

[emmartins]

I have a bean that doesn't define a custom loader, and its class loader policy is doing black listing, how can I disable this?

Thanks,
Eduardo

[alesj]

What about VFSCLPolicy::setBlackListable(false)?
Or

<classloading xmlns="urn:jboss:classloading:1.0"
 name="test"
 blackList="false">
</classloading>

[emmartins]

"alesj" wrote:
What about VFSCLPolicy::setBlackListable(false)?
Or

<classloading xmlns="urn:jboss:classloading:1.0"
 name="test"
 blackList="false">
</classloading>

The first one I have seen but I don't know how can I reach the policy for the bean's classloader , the second doesn't require a custom classloader in the descriptor that won't acess the libs of the server?

[alesj]

"emmartins" wrote:
but I don't know how can I reach the policy for the bean's classloader

You need to configure that CL at the time of creation.
e.g. proper jboss-classloading.xml in bean's jar

Or push more info, as I don't see what you're trying to do - again. ;-)

[emmartins]

I'm having issues with Javassist, it seems that the parent of deployment unit created classloader, the one of the mobicents beans jar, is blacklisting generated classes, this is generating further errors, specially if I redeploy a deployable unit and classes have to be generated again.

What would be content of the class loading descriptor for the same class loader as it is done by default (with no such descriptor) but with blacklisting off.

Thanks,
Eduardo

PS: By the way, what's the idea of the black listing at all? :-)

[alesj]

"emmartins" wrote:

What would be content of the class loading descriptor for the same class loader as it is done by default (with no such descriptor) but with blacklisting off.

Try this:

<classloading xmlns="urn:jboss:classloading:1.0" name="your-name-here"
export-all="NON_EMPTY" import-all="true" blackList="false">
</classloading>

"emmartins" wrote:

PS: By the way, what's the idea of the black listing at all? :-)

Very simple and common idea. ;-)
Constantly looking up / resolving some classes that already failed is costly.
If you can put an early condition on this check, it speeds up things.

[emmartins]

Worked, thanks, this, and the one in the other thread, are good info that could be on MC wiki.

Regarding the blacklisting feature, it's kind of confusing why it's not off by default, what is an example of an use case, where the lookup of a class that doesn't exist will benefict from this, won't all result in a java.lang.ClassNotFoundException that is usually a failure?

Another thing, lets say I have a domain and 2 class loaders (lets say CL1 and CL2), all with a policy defined as export-all="NON_EMPTY" import-all="true" blackList="false", a loadClass(String) of a class from CL1 in CL2 is failing, is this the expected behavior? Should instead the domain be always used for loading the class?

[emmartins]

"emmartins" wrote:

Another thing, lets say I have a domain and 2 class loaders (lets say CL1 and CL2), all with a policy defined as export-all="NON_EMPTY" import-all="true" blackList="false", a loadClass(String) of a class from CL1 in CL2 is failing, is this the expected behavior? Should instead the domain be always used for loading the class?

The domain is a no go too, the loadClass returns null.

[alesj]

"emmartins" wrote:
Should instead the domain be always used for loading the class?

I don't think you should be using domain, as that is impl specific.
You should be asking yourself why is classloading failing.

We have some info exposed, and there was a request from Scott,
saying the impl should help as much as possible to resolve why the class couldn't be resolved,
but I currently cannot recall what we did about that - apart from JMX exposure.