Hi Igor, Henry and all,
>> 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.
Whenever ideas about ignoring changes in the external environment of a
process (like changes in values of system properties or context
classloaders) come up, I have to admit I get a bit nervous. What if an
application has a good reason to change the outside environment: then
what's the workaround if its changes aren't picked up by underlying code?
For instance, perhaps it's possible to imagine an application that has a
pool of TransformerFactories. Then it hands these out to threads as
necessary. It's quite possible that each thread has its own classloader
with unique properties; somehow it doesn't seem quite proper to ignore
these classloaders.
Another idea would be to stack up all the context classloaders that have
ever been set on the factory, and consult them in the reverse order that we
saw them. But I wonder whether this might not produce unexpected results
sometimes, since potentially we'd be consulting stale objects...
Just my $0.02.
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Igor Malinin |
| | <[EMAIL PROTECTED]|
| | e> |
| | |
| | 03/19/2003 06:47 |
| | AM |
| | Please respond to|
| | xalan-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Question about how Xalan generalized ClassLoading Mechanism
can solve ClassNotFoundException in Applet |
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Henry Zongaro wrote:
> 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...
