On Mar 14, 2007, at 10:40 AM, Jarek Gawor wrote:
> Another idea I've had was to create a new context classloader (when
> set() is called) instead of the thread local solution. That new
> context classloader would first load a specific jar file for the
SAAJ
> implementation (the jar file would just contain SAAJ configuration
> files) and delegate everything else to the existing context
> classloader. That way, since the right configuration files would
> appear first in the classloader, it would force the right SAAJ
> implementation to be used (the SAAJ factory classes first check the
> context classloader for the configuration files).
I don't see how this could work as the resource data would likely be
cached by Java code, so when you attempt switch to another SAAJ
implementation the Java code won't notice the CL switch.
Hmm... you mean that information would be cached somewhere else
besides the classloader?
Sure. Resource files are just byte arrays, and some code will read
them in and interpret them. Normally, this type of code caches the
results since disks are so slow. Maybe we are talking about
different things.
-dain
