>From xalan's users' point of view, if there is only one task that is to use
XSLTC in applets. In this scenario, there is one solution that I can think
of.
In the applet init() method, store the right context class loader in a
public variable. When transform() method is called, set the context class
loader back to current thread. Now, the applet is trying to run outside
sandbox, the applet provider has to deploy the applet as a signed applet
and hope that the end users will trust the applet.
I tried it with Sun JRE 1.3.1_07 and IE5.5. It works fine. However, if I am
trying to use Sun JRE 1.4.* plugin. I encountered the same old problem. I
put the newer version xalan.jar in the %JAVA_JRE%/lib/endorsed/ directory.
When I try to access the signed applet, if I click "Yes" to give all
permission to this applet, somehow the JVM is looking for the
javax.xml.transform.TransformFactory text file from the xalan.jar in the
endorsed directory, instead of the jar specified in the archive attribute.
Is there better solution?
Christine Li
XSLT Development
IBM Toronto Lab
Tel: (905)413-2601
Email: [EMAIL PROTECTED]
"Henry Zongaro"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
om> cc:
Subject: Re: Question about how Xalan
generalized ClassLoading Mechanism can
03/18/2003 07:56 solve ClassNotFoundException in Applet
AM
Please respond to
xalan-dev
Hi Igor,
I thought I'd follow up by responding to one of your comments and also
by expanding upon Christine's original note.
Christine wrote:
[[
> superclass
org.apache.xml.dtm.ref.DTMDefaultBaseIterators$NamespaceIterator
> Cause of an old version of Xalan is bundled with Sun JDK 1.4.*. Using the
> "Endorsed Standards Override Mechanism", I copied a newer version of
> Xalan.jar in the /lib/endorsed directory. The story starts from here,
]]
You responded:
[[
This should solve java.lang.IllegalAccessError problem... Isn't it?
]]
Yes, that did eliminate the IllegalAccessError - the more important issue
was what followed in Christine's note.
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.
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?
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.
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.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab Tie Line 969-6044; Phone (905) 413-6044
mailto:[EMAIL PROTECTED]
|---------+---------------------------->
| | Igor Malinin |
| | <[EMAIL PROTECTED]|
| | e> |
| | |
| | 03/14/2003 03:13 |
| | PM |
| | Please respond to|
| | xalan-dev |
| | |
|---------+---------------------------->
>
------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Question about how Xalan generalized ClassLoading
Mechanism can solve ClassNotFoundException |
| in Applet
|
|
|
|
|
>
------------------------------------------------------------------------------------------------------------------|
Christine Li wrote:
> Plugin runtime environment. When I tested CompiledApplet sample, I got
> java.lang.IllegalAccessError: class
> org.apache.xalan.xsltc.dom.SAXImpl$TypedNamespaceIterator cannot access
its
^^^^^
XSLTC has not covered by Generalized ClassLoading patch because it has
own tricks with classloading which I doesn't yet understand enough...
But in your case it seems that you just have incompatible classes, i.e.
new xsltc classes (which is not in JVM's rt.jar) with old Xalan classes
(which is in rt.jar).
> superclass
org.apache.xml.dtm.ref.DTMDefaultBaseIterators$NamespaceIterator
> Cause of an old version of Xalan is bundled with Sun JDK 1.4.*. Using the
> "Endorsed Standards Override Mechanism", I copied a newer version of
> Xalan.jar in the /lib/endorsed directory. The story starts from here,
This should solve java.lang.IllegalAccessError problem... Isn't it?
> Referring back to previous discussions about Xalan generalized
> ClassLoading Mechanism.
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16675
> I modified the code and use the ObjectFactory class to load the translet
> class in org.apache.xalan.xsltc.trax.TransformerFactoryImpl .
>
> The very first time, I access my applet from IE. According to the Applet
> lifecycle, its init() and start() methods are invoked by the JVM. The
> getContextClassLoader() returns sun.plugin.security.PluginClassLoader and
> the getSystemClassLoader() returns sun.misc.Launcher$AppClassLoader. The
> ObjectFactory.findClassLoader() method will return
> sun.plugin.security.PluginClassLoader as the class loader to load the
> translet class. The translet class is in a jar file which specified in
the
> applet archive attribute. I get the right result.
As expected!
> Subsequently, I click "Run" in the menu.html which uses Javascript to
call
> the transform() method of my applet. It is where I get
> javax.xml.transform.TransformerConfigurationException: Cannot find class
> ****
>
> This time, the getContextClassLoader() returns null, cause the applet
> lifecycle methods (init, start, stop, destroy) and the transform() method
> are running in different threads. The contextclassloader for transform()
> method has no knowledge about the classes were loaded from the codebase
or
> archive. In this case, ObjectFactory.class.getClassLoader() in
> ObjectFactory.findClassLoader() returns null too, cause of the xalan.jar
in
> the endorsed directory is loaded by the bootstrap class loader. So the
> systemClassLoader ( sun.misc.Launcher$AppClassLoader) is returned. Of
> cause, it has no information about my translet class. Then the
> ObjectFactory.findProviderClass() method uses the fallback and tries to
> load translet class by using Class.forName(classname) . It tries to load
> the translet class from the current loader which is null.
As expected too!!! In any point of time you have access only to three
classloaders: current, context and system. If no one points to your
classes then you can't load it at all!
> Now, you can tell why I got Cannot find class error. My questions are:
> 1. Did I use the right way to replace the bundled xalan ?
yes
> 2. Is there any way that I can get the right ContextClassLoader from
> Applets. (without using setContextClassLoader)
in short - no
You can only ask SUN to fix their Java Plugin so it would set correct
context classloader when applet is called from javascript...
I could recommend you to cache context classloader init init() call and
then set it when applet is called from javascript. Or run another
utility thread from init() (context classloader inherited by children
threads) and use technique used in SwingUtil.invokeLater() and
SwingUtil.invokeAndWait()...
> 3. Is ObjectFactory sophisticated enough?
It tries to do its best from information it could get from JVM...
If you know the way it could do its job even better please tell us!
