During session replication I optimized my code to decide what order class loader to use based on the class name.
For example, if you load a class that starts with org.apache.catalina. I attempt to load it with the SCL first, it gave the app a huge performance boost. I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts you can make, like make a list of all the classes in common/lib and server/lib and never load those through WebCL unless specified by the user. Most user would love the performance gain of this, and the ability to turn it on/off Filip ----- Original Message ----- From: "Costin Manolache" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 05, 2004 9:54 AM Subject: Re: StandardClassLoader ? Remy Maucherat wrote: > Costin Manolache wrote: > >> Is there any reason we still need StandardClassLoader ? It seems it is >> only used once, in ClassLoaderFactory, and it is used exactly like a >> regular URLClassLoader - the only thing that needs to be moved is the >> convert() method. The code itself is just debug and duplication of >> URLClassLoader - the reverse loading is not used and it's not even >> really implemented in all parts of the code. > > > I'll keep it for now, since I'll try experiments to try to have faster > classloading. If my stuff isn't efficient, then I'll remove it. Can you experiment with WebappClassLoader instead :-) ? SCL is only used in standalone mode and only for loading internal classes. And removing it will improve class loading time by itself - one less layer of if() and indirections. ( I'm experimenting with class loading too, and it's easier to do it in one loader ) What I'm trying to do is allow some modules ( connectors, auth, etc ) to be deployed and loaded/unloaded/upgraded at runtime. Costin > >> >> It would reduce in half the complexity in the loader package :-), and >> it would make 'embeded' and 'standalone' more similar ( embeded doesn't >> usually use Bootstrap and StandardClassLoader but the embedding app >> loader). > > > Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
