You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Alex Amies <AA...@access360.com> on 2001/05/16 23:30:48 UTC
List of options and their usage
Is there a list of all the options and their usage somewhere?
-----Original Message-----
From: Scott_Boag@lotus.com [mailto:Scott_Boag@lotus.com]
Sent: Wednesday, May 16, 2001 12:36 PM
To: xalan-dev@xml.apache.org
Subject: RE: Xalan2 with Weblogic 6
> I think Scott said this stuff would work differently with the new DTM
code
> where Xalan (if used with Xerces) won't use 2 threads for the
transform.
But
> I may quite easily have misunderstood.
You didn't misunderstand.
We'll provide a option
"http://xml.apache.org/xalan/features/incremental"
that will be true by default.
1) If you use a TransformerHandler, and
"http://xml.apache.org/xalan/features/incremental" is true, the extra
thread will be used. If
"http://xml.apache.org/xalan/features/incremental"
is false, the transform won't occur until the endDocument event is
reached.
2) If you pass in a URL, file, or stream to a Transformer, and
"http://xml.apache.org/xalan/features/incremental" is true, and we
javax.xml.parsers.SAXParserFactory creates a non-Xerces parser, the
extra
thread will be used.
3) If you use a SAXSource, pass in a reader, and
"http://xml.apache.org/xalan/features/incremental" is true, and the
reader
is a non-Xerces parser, the extra thread will be used.
4) If the parser being used is a Xerces parser, and
"http://xml.apache.org/xalan/features/incremental" is true, it will use
the
parseNext method to implement incrementally. If
"http://xml.apache.org/xalan/features/incremental" is false, it will
built
the DTM more directly, and then do the transform.
5) In all other cases, the extra thread will not be created.
Also, Costin has provided some stuff to hook in a threading pool from
the
servlet, which should help things also.
-scott
"Glencross,
Christian" To:
"'xalan-dev@xml.apache.org'" <xa...@xml.apache.org>
<Christian.Glencro cc: (bcc: Scott
Boag/CAM/Lotus)
ss@gs.com> Subject: RE: Xalan2
with Weblogic 6
05/16/01 12:34 PM
Please respond to
xalan-dev
This looks like a known issue which makes it very hard to use Xalan 2
with
Weblogic 6. It was discussed a few weeks ago.
I think Scott said this stuff would work differently with the new DTM
code
where Xalan (if used with Xerces) won't use 2 threads for the transform.
But
I may quite easily have misunderstood.
I suggest clicking "Vote for this bug" to ensure it doesn't drop off any
radars.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1119
-----Original Message-----
From: Alex Amies [mailto:AAmies@access360.com]
Sent: 15 May 2001 23:05
To: 'xalan-dev@xml.apache.org'
Subject: RE: Xalan2 with Weblogic 6
We created a Weblogic XML Registry before posting the first
message.
-----Original Message-----
From: Erik Onnen [mailto:EOnnen@c-bridge.com]
Sent: Tuesday, May 15, 2001 10:58 AM
To: 'xalan-dev@xml.apache.org'
Subject: RE: Xalan2 with Weblogic 6
Did you try to create a new XML Registry first? That should help reduce
the
chance of threading problems as the parsing threads and anything they
spawn
are now managed by the app server. The BEA documentation for the parser
config/registry is at
http://edocs.bea.com/wls/docs60/xml/xml_admin.html
I haven't tried Xalan in a WL6 container yet but I imagine it has to be
similar to the way the parsers are done.
-----Original Message-----
From: Alex Amies [mailto:AAmies@access360.com]
Sent: Tuesday, May 15, 2001 11:46 AM
To: 'xalan-dev@xml.apache.org'
Cc: Mark Braksator; Weibo (Weber) Yuan
Subject: Xalan2 with Weblogic 6
Is anybody successfully using Xalan2 with Weblogic 6?
We were using it with Weblogic 5.1 sucessfully but
on upgrading to Weblogic 6 we got an exception with
the stack trace listed below. Is anybody using Xalan2
successfully with Weblogic 6?
I am using Servlets to transform xml into html. To
do the transformation I pass the PrintWriter from
the HttpServletResponse to the Xalan processor:
Writer out = res.getWriter();
StreamResult streamResult = new StreamResult(out);
transformer.transform(xmlSource, streamResult);
Following that we get a ClassCastException from the
Servlet engine. It doesn't look like it is related
to the old version of Xalan that Weblogic is now
packaging but seems like something separate.
We believe that it is a Weblogic problem but the interesting
thing is that it looks like Xalan is starting a new
thread at some point. Weblogic seems to be making
a class cast to one of their own threads to find out
the date and setting this into a http header. It
appears that Xalan is the creator of this thread instead
of the Weblogic server leading to a ClassCastException.
Is it correct that Xalan initiates a new thread in such
a situation? If so, is there a way to configure Xalan
to not do so?
<May 14, 2001 11:33:13 AM PDT> <Error> <T3Services>
<javax.xml.transform.TransformerException: java.lang.Thread
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerIm
pl.java:1242)
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:29
42)
at java.lang.Thread.run(Thread.java:484)
---------
java.lang.ClassCastException: java.lang.Thread
at
weblogic.servlet.internal.ResponseHeaders.setDateHeader(ResponseHeaders.
java:273)
at
weblogic.servlet.internal.ServletResponseImpl.setDateHeader(ServletRespo
nseImpl.java:476)
at
weblogic.servlet.internal.ServletResponseImpl.writeHeaders(ServletRespon
seImpl.java:664)
at
weblogic.servlet.internal.ServletOutputStreamImpl.flush(ServletOutputStr
eamImpl.java:126)
at
weblogic.servlet.internal.WLOutputStreamWriter.flush(WLOutputStreamWrite
r.java:124)
at java.io.PrintWriter.flush(PrintWriter.java:120)
at
org.apache.xalan.serialize.SerializerToXML.flushWriter(SerializerToXML.j
ava:1471)
at
org.apache.xalan.serialize.SerializerToXML.endDocument(SerializerToXML.j
ava:662)
at
org.apache.xalan.transformer.ResultTreeHandler.endDocument(ResultTreeHan
dler.java:193)
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerIm
pl.java:1224)
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:29
42)
at java.lang.Thread.run(Thread.java:484)