DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19790>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19790 TransformerFactoryImpl.newTemplates() throws exception in Applet [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2003-06-11 09:30 ------- When using the Transformer (TransformerImpl) class with an applet, there is the exception "org.apache.xml.utils.WrappedRuntimeException: Output method is xml could not load output_xml.properties (check CLASSPATH)", because output_xml.properties is a file and an applet can't read files. If I create an archive containing the files of xalan (right package, containing *.res and *.properties) and I associate it with the applet in the applet tag (archive=xalanfiles.jar), the problem was resolved. At the next step, I use the method transform(Source,Result) but the TransformerImpl class tries to accede the user.dir property (forbidden for an applet). I precised the source systemId, it seemed to be the reason for the TransformerImpl trying to acces user.dir property and so it worked when I did no xsl transformation. But when I tried to do an xsl Transformation (xslSource in the transformer) and then use the transform(Source, Result), it tried to acces user.dir property, probably caused by the fact (line 1050 or something like) "String base = source.getSystemId();" set base == null (only when there is a xsl template loaded for the transformation). I changed the code, just adding "System.out.println(base);", recompiled and it writed that base wasn't null, but the transformation worked also (mysterious correction of the bug). To summarize,with the actual source code, a transformation using an xsl in an applet seems to provoke a bug when trying to get the source's SystemId, adding a System.out.println(source's SystemId) seems to correct the bug.
