[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Class loading debugging

[adrian@jboss.org]

"scott.stark at jboss.org" wrote : 
  | "adrian at jboss.org" wrote : 
  |   | There's no such thing in general. If the policy is a VFSClassLoaderPolicy
  |   | then you can ask what its VFS roots are and you could ask what other policies
  |   | it can see that are VFSClassLoaderPolicys or URLClassLoaders.
  |   | But the new classloading system has been designed to be flexible.
  |   | There's no direct dependency of URLs/VFS etc. Somebody can implement
  |   | a policy how they want.
  | It should not explicitly be URL[], just String[]. In general there needs to be some notion of a classpath. It might be an sql query, who knows, but some generic view should be possible.
  | 

We can ask each ClassLoaderPolicy to implement a getURLs() for management
purposes. For deployment generated classloaders its really just the same as
getClassPath() on the deployment unit. But that doesn't mean that something
should use those URLs as a classpath.

Parts of the filesystem the url represents could be filtered out
e.g. 
1) your excluded packages example
2) the OSGi uses constraint where a deployment may contain jms.jar
but declare it as "uses". i.e. it will actually use our jms classes
3) for importAll, a previously deployed classloader may mask some classes
if they appear in two classloaders (only the first gets used)
etc.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124043#4124043

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124043