This content has been marked as final.
Show 4 replies
-
1. Re: Problem with javassist + RepositoryClassLoader
jason.greene Nov 15, 2006 10:54 PM (in response to jason.greene)"jason.greene@jboss.com" wrote:
I am not sure if this has been
Unfortunately defineClass() is final so there is no way to detect this condition within the loader. So, currently I call clearBlacklists() directly on the loader. This, however, is not very efficient because the entire list is being cleared instead of just the one class that is being generated.
I left out that I can remove the class, and the resource directly, however, I am tied to implementation details of the loader, which may change.
-Jason -
2. Re: Problem with javassist + RepositoryClassLoader
starksm64 Nov 15, 2006 11:53 PM (in response to jason.greene)This is why there is a dynamic url notion.
/** HashSet<UCL> of class loaders in the repository that have a dynamic * URL associated with them. Such a class loader is added to every package * class loader set in #getPackageClassLoaders(String). */ private HashSet dynamicClassLoaders = new HashSet();
A dynamic URL is one that has a dynamic=true query parameter added to the URL. The aop class generation layer uses this to treat the server/tmp/aopdynclasses dir as containing such classes:URL tmpURL = tempdir.toURL(); URL tmpCP = new URL(tmpURL, "?dynamic=true");
Otherwise, putting the classes in a directory associated with the war class loader would also work since it does not use the ucl by default. -
3. Re: Problem with javassist + RepositoryClassLoader
jason.greene Nov 16, 2006 11:38 AM (in response to jason.greene)Doesn't this just fix visibility of the classloader from other loaders in the repository?
I checked the AOP implementation, and it is currently doing the same process of manually flushing the blacklists.
I ended up having to create a child URLClassLoader to catch the transient classes, since I can't pollute the top level CL that is present at deploy time (else classes referenced by the one I am generating will end up conflicting with the ones loaded by the tomcat CL). So this obviates my specific need.
However it is possible that others would run into it, and if there are plans to redesign any of this for the MC, IMO we should consider a public interface for necessary interactions like this. -
4. Re: Problem with javassist + RepositoryClassLoader
starksm64 Nov 16, 2006 12:38 PM (in response to jason.greene)"jason.greene@jboss.com" wrote:
Doesn't this just fix visibility of the classloader from other loaders in the repository?
From the perspective that a dynamic class loader should be seen as indexed to any package, yes."jason.greene@jboss.com" wrote:
I checked the AOP implementation, and it is currently doing the same process of manually flushing the blacklists.
Ok, this looking under the covers, past the ClassLoader api was supposed to be eliminated by the dynamic class loader notion. The dynamic url notion was not well published or tested so I can't complain. We should have the ability to configure caching behavior for a given deployment, but we should not have to step outside of the class loading api to do this. At least the code doing the class loading should not. This is not to say that we better expose the caching and indexing behavior for injection and integration with lifecycle ops via kernel beans.