Taylor Gautier wrote:
> As a follow up to this, here is what I did in both JVMs (actual Groovy
> script, though you can see it's very similar to Java)
>
> class Foo { }
> cl = new Foo().getClass().getClassLoader()
> cl.__tc_setClassLoaderName("groovy-classloader")
> com.tc.object.bytecode.hook.impl.ClassProcessorHelper.registerGlobalLoader(cl);
>
> Regarding the onload idea, that only gets called for a managed object
> faulted in to the VM, so wouldn't have helped me.
At some point Steve suggested another hood called onInit...
> Seems to me this could be a feature, along the lines of:
>
> <named-classloaders>
> <named-classloader>
> <expression>groovy.lang.GroovyClassLoader$InnerLoader</expression>
> <name>groovy-classloader</name>
> </named-classloader>
> </named-classloaders>
That won't help much because all these classloaders will have the same
name "groovy-classloader", but that is not necessary what you need (i.e.
you may have multiple onrelated groovy classloaders around), so you
would need at least pirce of bsh to get that name at the runtime.
For classloaders that DSO handle it does retrieve context-based name
(i.e. web app name)
There was a discussion while ago about making it easier to deal with
custom classloader and Tim had some ideas how to deal with that...
regards,
Eugene
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
