Hi Igor,
The questions are really which component is at fault, and what is the proper way of handling all of this? A few possibilities:
1. The applet is at fault and should save the "context class loader" that was available at initialization time, and then set that as the context class loader whenever the transform method is invoked. But that only works if the applet has sufficient permission to set the context class loader, which might not be the case.
This is not an applet fault. But since we already have such behavior in Java Plugin, applet have to do something. Setting context classloader from an applet might be prohibited, but starting threads from an applet should be allowed (it can be potentially disabled too, but starting threads is very common to applets, so this case is quite unrealistic). Then you could delegate any JavaScript entry points to run code inside this started thread which will always have the same context classloader.
2. The caller of the applet (that is, the java plug-in IE is using) is at fault. Possibly, but then just what is an application permitted to do when it uses context class loaders? Should the authors of components like Xalan and Xerces describe in their documentation that objects created with respect to a particular context class loader have to be used with respect to that same context class loader, because using the object might result in more objects being created through the class loader?
a ) Java Plugin is at fault - if it sets context classloader for one entry-point (init() method) it must set context classloader for all other entry-points of an applet...
b) I agree that Xerces/Xalan classloading should be described somewhere in user documentation...
3. Xalan-J is at fault. Once someone creates a TransformerFactory object with respect to a context class loader, then everything that is ultimately created through the actions of that TransformerFactory should be created with respect to that same class loader, regardless of subsequent changes to the setting of the context class loader on the current thread.
This is good idea... but seems too late to be implemented in Xalan/Xerces... You could talk to xerces-dev too if you interested.
4. The designers of Java are at fault.
If you or anyone else has pointers to accepted practices when using context class loaders (or any description of contracts implied by their use), that would probably help a great deal.
Definitely yes, "designers of Java are at fault" - just because semantic of Class.forName() was changed between 1.1 and 1.2 JVMs :)
I have no inreresting pointers on this topic... Only JavaDoc and other standard Java documentation...
