You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Edward L. Knoll" <ed...@cosd.fedex.com> on 2004/10/21 02:00:45 UTC
Problem with Transformer.setParameter() in SAX chain.
I have chain of Sax handlers which is effectively a XMLReader chained to
SAXTransformer chained to a custom ContentHandler chained to a
Serializer. I am actually parsing multiple XML input streams to
generate a single output XML stream. The custom Content Handler
suppresses all but the first startDocument() event and the last
endDocument() event to keep the Serializer which is generating the
single XML output from getting upset.
This is the net chain; my actually chain contains some custom "tee"
ContentHandlers and additional flows of SAX events, but I don't believe
those to be germane to my problem.
I need to change a parameter with the SAXTransformer for each file
processed. This parameter is used to generate an output element for
each file processed. I can do a setParameter() followed by a
getParameter() and see that the parameter is changed in the Transformer.
This is done for each file before doing a XMLReader.parse().
My problem is that the elements in the output XML which represent this
changing parameter only have the last value this parameter was set to.
I've tried doing a Transformer.clearParameters() between
XMLReader.parse() actions, but that appears to have no affect.
I would think that each XMLReader.parse() execution and so each XSL
Transformation would be independent of each other. I don't see how
anything other than the value of this changing parameter can be
propagating through the custom ContentHandler given the signatures of
the ContentHandler methods.
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Problem with Transformer.setParameter() in SAX chain.
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Edward.
"Edward L. Knoll" <ed...@cosd.fedex.com> wrote on 10/20/2004 08:00:45
PM:
> I have chain of Sax handlers which is effectively a XMLReader chained to
> SAXTransformer chained to a custom ContentHandler chained to a
> Serializer. I am actually parsing multiple XML input streams to
> generate a single output XML stream. The custom Content Handler
...
>
> I need to change a parameter with the SAXTransformer for each file
> processed. This parameter is used to generate an output element for
...
> My problem is that the elements in the output XML which represent this
> changing parameter only have the last value this parameter was set to.
> I've tried doing a Transformer.clearParameters() between
> XMLReader.parse() actions, but that appears to have no affect.
When you say that you're using a SAXTransformer, I assume you mean
you're using a TransformerHandler. Is that correct?
There's a long-standing issue in Xalan-J Interpretive over the fact
that TransformerHandler objects cannot be reused.[1] I don't believe that
that restriction's ever been clearly stated in the JAXP specification.
However, I think it is a reasonable restriction, given the following
statement in the Javadoc for ContentHandler.endDocument() [2]:
The SAX parser will invoke this method only once, and it will
be the last method invoked during the parse.
Currently, Xalan-Java Interpretive produces a NullPointerException if
you attempt to reuse a TransformerHandler, so I'm not sure whether you're
using Xalan-J Interpretive or XSLTC. In any event, I think the right
thing to do is create a Templates object, and prior to each parse, use
SAXTransformerFactory.newTransformerHandler(Templates) to create a new
TransformerHandler from the Templates object. Then set the parameter
value and connect the XMLReader to the new TransformerHandler and the
TransformerHandler to the custom ContentHandler.
I hope that helps.
Thanks,
Henry
[1] http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=XALANJ-101
[2]
http://xml.apache.org/xalan-j/apidocs/org/xml/sax/ContentHandler.html#endDocument()
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XSL template priority problem in SAX processing stream.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
Please disregard this. A misedited file appeared to resolve the
problem; taking the mode attribute off did not fix the problem.
Edward L. Knoll wrote:
> I have isolated the problem further: the templates where priorities
> are not working also have mode attributes. If I take the mode
> attributes off, the templates work correctly.
>
> Unfortunately, company policy regarding software/confidential material
> will not allow me to post the input/source I'm using. However, if I
> can reproduce the problem in a smaller context, I will open the JIRA bug.
>
> Morris Kwan wrote:
>
>> I believe template priority should work in all modes of transformation,
>> without any code change from the user side. Please open a bug in the
>> JIRA
>> database (http://nagoya.apache.org/jira/secure/Dashboard.jspa) and
>> attach
>> the input xml, stylesheet and the Java code to reproduce the problem.
>>
>> Morris Kwan
>> XSLT Development
>> IBM Toronto Lab
>> Tel: (905)413-3729
>> Email: mkwan@ca.ibm.com
>>
>>
>>
>>
>>
>>
>> We have a XSL stylesheet which has prioritized templates. It was
>> working as expected when we were using org.apache.xalan.xslt.Process to
>> process it. We've since changed our processing to be handled by a
>> chain of SAX content handlers with the core XSL processing being handled
>> by a TransformerHandler created from a Templates handler created from a
>> SAXTransformerFactory.
>>
>> Now it appears that template priority is not being recognized at all.
>>
>> We're using Xalan-Java 2.6 on Solaris platform. We are overriding the
>> default version of Xalan used by the Solaris java command by overriding
>> the bootclasspath.
>>
>> Is this a (known) Xalan-Java bug, is there something we have to
>> change/do to enable template prioritization, do we have to change how
>> prioritization values are expressed with the SAX components?
>>
>>
>>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XSL template priority problem in SAX processing stream.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
I have isolated the problem further: the templates where priorities are
not working also have mode attributes. If I take the mode attributes
off, the templates work correctly.
Unfortunately, company policy regarding software/confidential material
will not allow me to post the input/source I'm using. However, if I can
reproduce the problem in a smaller context, I will open the JIRA bug.
Morris Kwan wrote:
>I believe template priority should work in all modes of transformation,
>without any code change from the user side. Please open a bug in the JIRA
>database (http://nagoya.apache.org/jira/secure/Dashboard.jspa) and attach
>the input xml, stylesheet and the Java code to reproduce the problem.
>
>Morris Kwan
>XSLT Development
>IBM Toronto Lab
>Tel: (905)413-3729
>Email: mkwan@ca.ibm.com
>
>
>
>
>
>
>We have a XSL stylesheet which has prioritized templates. It was
>working as expected when we were using org.apache.xalan.xslt.Process to
>process it. We've since changed our processing to be handled by a
>chain of SAX content handlers with the core XSL processing being handled
>by a TransformerHandler created from a Templates handler created from a
>SAXTransformerFactory.
>
>Now it appears that template priority is not being recognized at all.
>
>We're using Xalan-Java 2.6 on Solaris platform. We are overriding the
>default version of Xalan used by the Solaris java command by overriding
>the bootclasspath.
>
>Is this a (known) Xalan-Java bug, is there something we have to
>change/do to enable template prioritization, do we have to change how
>prioritization values are expressed with the SAX components?
>
>
>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XSL template priority problem in SAX processing stream.
Posted by da...@us.ibm.com.
Edward Knoll writes:
>The templates at issues are actually distributed across multiple files.
>A master XSL file references these templates using <xsl:import>. If I
>change the <xsl:import> to an <xsl:include>, the prioritization works.
>...should I expect this behavior?
Yes, import precedence outweighs template priority. We have a conformance
test for this (conflictres09), so we would enforce the required behavior.
.................David Marston
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XSL template priority problem in SAX processing stream.
Posted by Joseph Kesselman <ke...@us.ibm.com>.
Yes, you should expect that behavior.
Include treats the other file as part of the same stylesheet source
document. Import brings it in at reduced priority -- "lower Importance", if
you need a mnemonic. See the XSLT spec for details.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XSL template priority problem in SAX processing stream.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
The templates at issues are actually distributed across multiple files.
A master XSL file references these templates using <xsl:import>. If
I change the <xsl:import> to an <xsl:include>, the prioritization works.
I've never been entirely sure of the difference between xsl:import and
xsl:include, should I expect this behavior?
Morris Kwan wrote:
>I believe template priority should work in all modes of transformation,
>without any code change from the user side. Please open a bug in the JIRA
>database (http://nagoya.apache.org/jira/secure/Dashboard.jspa) and attach
>the input xml, stylesheet and the Java code to reproduce the problem.
>
>Morris Kwan
>XSLT Development
>IBM Toronto Lab
>Tel: (905)413-3729
>Email: mkwan@ca.ibm.com
>
>
>
>
>
>
>We have a XSL stylesheet which has prioritized templates. It was
>working as expected when we were using org.apache.xalan.xslt.Process to
>process it. We've since changed our processing to be handled by a
>chain of SAX content handlers with the core XSL processing being handled
>by a TransformerHandler created from a Templates handler created from a
>SAXTransformerFactory.
>
>Now it appears that template priority is not being recognized at all.
>
>We're using Xalan-Java 2.6 on Solaris platform. We are overriding the
>default version of Xalan used by the Solaris java command by overriding
>the bootclasspath.
>
>Is this a (known) Xalan-Java bug, is there something we have to
>change/do to enable template prioritization, do we have to change how
>prioritization values are expressed with the SAX components?
>
>
>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XSL template priority problem in SAX processing stream.
Posted by Morris Kwan <mk...@ca.ibm.com>.
I believe template priority should work in all modes of transformation,
without any code change from the user side. Please open a bug in the JIRA
database (http://nagoya.apache.org/jira/secure/Dashboard.jspa) and attach
the input xml, stylesheet and the Java code to reproduce the problem.
Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: mkwan@ca.ibm.com
"Edward L. Knoll"
<ed.knoll@cosd.fe
dex.com> To
xalan-dev@xml.apache.org
11/04/2004 12:37 cc
PM
Subject
XSL template priority problem in
Please respond to SAX processing stream.
xalan-dev
We have a XSL stylesheet which has prioritized templates. It was
working as expected when we were using org.apache.xalan.xslt.Process to
process it. We've since changed our processing to be handled by a
chain of SAX content handlers with the core XSL processing being handled
by a TransformerHandler created from a Templates handler created from a
SAXTransformerFactory.
Now it appears that template priority is not being recognized at all.
We're using Xalan-Java 2.6 on Solaris platform. We are overriding the
default version of Xalan used by the Solaris java command by overriding
the bootclasspath.
Is this a (known) Xalan-Java bug, is there something we have to
change/do to enable template prioritization, do we have to change how
prioritization values are expressed with the SAX components?
Thanks,
Ed Knoll
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
XSL template priority problem in SAX processing stream.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
We have a XSL stylesheet which has prioritized templates. It was
working as expected when we were using org.apache.xalan.xslt.Process to
process it. We've since changed our processing to be handled by a
chain of SAX content handlers with the core XSL processing being handled
by a TransformerHandler created from a Templates handler created from a
SAXTransformerFactory.
Now it appears that template priority is not being recognized at all.
We're using Xalan-Java 2.6 on Solaris platform. We are overriding the
default version of Xalan used by the Solaris java command by overriding
the bootclasspath.
Is this a (known) Xalan-Java bug, is there something we have to
change/do to enable template prioritization, do we have to change how
prioritization values are expressed with the SAX components?
Thanks,
Ed Knoll
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Losing xsl:comment between SAX Transformer and Serializer.
Posted by Brian Minchau <mi...@ca.ibm.com>.
Ed,
I'm guessing that you are using Xalan 2.6.0
This is looking like bug 1966
(http://nagoya.apache.org/jira/browse/XALANJ-1966). Please build Xalan
with that patch an try again.
----------
Brian Minchau
XSLT Development, IBM Toronto
e-mail: minchau@ca.ibm.com
"Edward L. Knoll"
<ed.knoll@cosd.fe
dex.com> To
xalan-dev@xml.apache.org
10/25/2004 07:45 cc
PM
Subject
Losing xsl:comment between SAX
Please respond to Transformer and Serializer.
xalan-dev
We have a XSL stylesheet which generates xsl:comments. We're losing
those comments between the TransformerHandler and the Serializer. The
TransformerHandler we're getting from a
SAXTransformerFactory.newTransformerHandler() using a Templates object.
The Serializer we're getting from SerializerFactory.getSerializer().
The Serializer we get appears to be a LexicalHandler and I've explicitly
called SAXResult.setLexicalHandler() with that same Serializer prior to
assigning the SAXResult wrapping the Serializer to the TransformerHandler.
I'm guessing there's something I missing; can someone help me with this?
Thanks,
Ed Knoll
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Losing xsl:comment between SAX Transformer and Serializer.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
We have a XSL stylesheet which generates xsl:comments. We're losing
those comments between the TransformerHandler and the Serializer. The
TransformerHandler we're getting from a
SAXTransformerFactory.newTransformerHandler() using a Templates object.
The Serializer we're getting from SerializerFactory.getSerializer().
The Serializer we get appears to be a LexicalHandler and I've explicitly
called SAXResult.setLexicalHandler() with that same Serializer prior to
assigning the SAXResult wrapping the Serializer to the TransformerHandler.
I'm guessing there's something I missing; can someone help me with this?
Thanks,
Ed Knoll
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Concurrency issue .... resulved.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
Resolved (probably). Each ContentHandler instance when created was
getting a reference to the root document node of the XML file
representing the static/common filter. Now I return:
(Element) Document.getDocumentElement().cloneNode(true);
This actually didn't eliminate all my exceptions at first, but once I
synchronized the above operation , it appeared to fix my exception
problems. I haven't seen the exception yet and have rerun the test many
times, so that problem is probably fixed (or it might be that the
synchronize changed the timing enough to make it harder to get to).
I still haven't heard; should Node/NodeList be safe to access currently
for read only kind of operations?
Edward L. Knoll wrote:
> We have a custom ContentHandler in a SAX processing chain which we use
> to filter for nodes we wish to pass on. The filter is defined via a
> XML file which we read into a NodeList. Since the filter definition
> is static and we are only reading the NodeList, we set the filter up
> to be shared between instances of the associated ContentHandler.
>
> We are (intermittently) getting exceptions within the
> NodeList.getLength() method. I don't know if our expectations are
> inappropriate or if there is some problem buried within this NodeList
> method/class.
>
> If it is a problem, I can't supply source/data (company proprietary
> policies), so I hope that's enough to go on.
>
> I will be working on an alternate implementation, so am not looking
> for resolution (although suggestions are welcome, if timely :).
>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Concurrency problem with static Java calls.
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Edward.
"Edward L. Knoll" <ed...@cosd.fedex.com> wrote on 2004-12-20 11:55:43
AM:
> If I'd stopped to think about it, I would not have expected to be able
> to change a result-tree-fragement into a number/integer, but the logic
> appears to work (outside the threading issues). I've included some XSL
> fragments to illustrate:
Just FYI - according to Section 11.1 of XSLT 1.0:[1]
the operations permitted on a result tree fragment are a subset
of those permitted on a node-set. An operation is permitted on
a result tree fragment only if that operation would be permitted
on a string (the operation on the string may involve first
converting the string to a number or boolean)
Thanks,
Henry
[1] http://www.w3.org/TR/xslt#section-Result-Tree-Fragments
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Concurrency problem with static Java calls.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
Empirical evidence now seems to be pointing at another possible
explanation. The Java function we are calling takes several parameters
which are either integers or strings. Template scope XSL variables
were being used to establish the values of these parameters and then
these local variables were passed to the Java function. I happened to
notice that while all of the Java function parameters where simple types
(e.g. integers/strings), some of the local variables were technically
result-tree-fragments. I eliminated some of these local variables we
were defining and that seemed to reduce the problem incidence rate,
although I can't actually prove a cause and effect relationship.
If I'd stopped to think about it, I would not have expected to be able
to change a result-tree-fragement into a number/integer, but the logic
appears to work (outside the threading issues). I've included some XSL
fragments to illustrate:
<xsl:variable name='Offset'> <!-- [+-]HHMM portion -->
<xsl:variable name='afterZ' select="substring-after($Input,'Z')" />
<xsl:choose>
<xsl:when test="string-length($afterZ)=5">
<xsl:value-of select="$afterZ" />
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="'+0000'" />
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:variable name="Offset_mSec"
select="(number(substring($Offset,2,2)) * 3600000) +
(number(substring($Offset,4,2)) * 60000)" />
<xsl:choose>
<xsl:when test="substring($Offset,1,1) = '-'">
<xsl:value-of select="FastDateFormat:formatDate(
$DateFormatter, $DateFormat,
substring($DateTime,5,2), substring($DateTime,7,2),
substring($DateTime,1,4), substring($DateTime,9,2),
substring($DateTime,11,2), '0', -($Offset_mSec))" />
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="FastDateFormat:formatDate(
$DateFormatter, $DateFormat,
substring($DateTime,5,2), substring($DateTime,7,2),
substring($DateTime,1,4), substring($DateTime,9,2),
substring($DateTime,11,2), '0', $Offset_mSec)" />
</xsl:otherwise>
</xsl:choose>
Edward L. Knoll wrote:
> Spoke to soon. The incident rate dropped a lot, but the problem still
> persistes.
>
> Edward L. Knoll wrote:
>
>> Context: Xalan-J, 2.6.0; SAX transformation chain.
>>
>> We were having a concurrency operation associated with a call to a
>> static Java method we were making from an XSL stylesheet. We
>> restructured the Java class, so that the operation could be performed
>> as a method call on an instance; the static method was changed to
>> create an instance of the class and make the instance method call.
>>
>> When we create an object instance and make the instance method call,
>> we do not have a concurrency problem. If we call the static method,
>> we have a concurrency problem. I reverified that the problem is
>> still there with the static method call after restructuring the class.
>>
>> What ever this problem is, it's tied up with how static Java method
>> calls are handled from the stylesheet versus instance method calls.
>> The static method call is reentrant; there should not have been a
>> problem. The problem appears to be tied up with how the parameters
>> are handled; in some instances it appears as though parameters from
>> one invocation are mixed up with another (presumably from another
>> thread). If I were to hazard a guess, on static Java method calls
>> the parameters are being maintained in a static structure.
>>
>> I won't be researching this farther, since will be using the instance
>> method call. As I've said before, company proprietary policies won't
>> allow me to provide source. Our test driver is running 10 threads on
>> a 8 CPU platform.
>>
>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Concurrency problems reproduced - what now.
Posted by Brian Minchau <mi...@ca.ibm.com>.
Ed,
please open separate JIRA issues, it is easy to mark one as a duplicate of
the other should that turn out to be the case.
This way each issue can have its own status, rather than tangling them
together. A single zip file, or separate attachements is fine, what ever
is best for you.
----------
Brian Minchau
XSLT Development, IBM Toronto
e-mail: minchau@ca.ibm.com
"Edward L. Knoll"
<ed.knoll@cosd.fe
dex.com> To
xalan-dev@xml.apache.org
01/12/2005 02:58 cc
PM
Subject
Concurrency problems reproduced -
Please respond to what now.
xalan-dev
I've reproduced the three major types of concurrency problems we
encountered with Xalan-Java 2.6.0 with fairly small elements for which I
can supply the source. One problem is an HTML serialization problem
which has likely been resolved, but I will supply anyway, so someone can
verify. The other two problems may turn out to be different aspects of
the same problem, since they both appear to revolve around management of
local variables within templates.
Do you want these packaged as a single defect?
How do you want the source: multiple text file attachments or a single
tar file? The components include a Java class/program, XSL stylesheets,
XML file(s), and the scripts I use to run the tests and cross compare
results to identify the errors.
I still have some cleanup and (re)packaging to do before I submit these,
but these activities should be completed soon.
Thanks,
Ed Knoll
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Concurrency problems reproduced - what now.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
I've reproduced the three major types of concurrency problems we
encountered with Xalan-Java 2.6.0 with fairly small elements for which I
can supply the source. One problem is an HTML serialization problem
which has likely been resolved, but I will supply anyway, so someone can
verify. The other two problems may turn out to be different aspects of
the same problem, since they both appear to revolve around management of
local variables within templates.
Do you want these packaged as a single defect?
How do you want the source: multiple text file attachments or a single
tar file? The components include a Java class/program, XSL stylesheets,
XML file(s), and the scripts I use to run the tests and cross compare
results to identify the errors.
I still have some cleanup and (re)packaging to do before I submit these,
but these activities should be completed soon.
Thanks,
Ed Knoll
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Concurrency problems with variable management?
Posted by Christine Li <jy...@ca.ibm.com>.
Hi, Edward
Thanks for trying to identify the problem. Once you can reproduce the
problem, please one a bug report and attach a test case to demonstrate the
problem http://nagoya.apache.org/jira/
Thanks,
Christine Li
XSLT Development
IBM Toronto Lab
Tel: (905)413-2601
Email: jycli@ca.ibm.com
"Edward L. Knoll" <ed...@cosd.fedex.com>
12/23/2004 02:49 PM
Please respond to
xalan-dev
To
xalan-dev@xml.apache.org
cc
Subject
Concurrency problems with variable management?
We seem to have isolated a couple of concurrency problems to the
handling of (template scope) variables in two different contexts. I
will include code fragments to illustrate the problems. Corporate
proprietary policies will not allow me to send the entire source or the
data. Within the next couple of weeks it is my intent to attempt to
reproduce both of these problems with simple/benign examples which (if
successful) I will submit with a bug report.
Our thread test driver is running 20 threads on a 8 processor box. Each
thread is performing the same set of 16 different transformations (in a
couple of different orders). Each transformation is performed by a SAX
processing chain. The XSL transforms are loaded into templates. The
classes used in the SAX processing chain are recreated for each
transformation.
In the first example, a local variable is passed to two separate
templates. The value of the IntermediateValue variable changes between
the two xsl:call-template invocations. The incorrect value can be found
in the input XML. We believe the incorrect value is being picked up
from another thread. This error will generally occur once or twice
every 10 runs (of the 20 threads).
<xsl:template match="sep-gmt-post-timestamp" priority="20.0">
<xsl:variable name="IntermediateValue"
select="concat(normalize-space(.),
substring-after(../event-creation-timestamp,'Z'))" />
<xsl:call-template name='TransformField'>
<xsl:with-param name="IntermediateValue"
select="$IntermediateValue" />
<xsl:with-param name="OtherElements">
<xsl:call-template name="FormatDateTime">
<xsl:with-param name="Input">
<xsl:value-of select="$IntermediateValue" />
</xsl:with-param>
</xsl:call-template>
</xsl:with-param>
</xsl:call-template>
</xsl:template>
The other error occurred on almost every test run. A local variable
inside of a recursive template call appeared to be changing. The
"count" was sometimes '1' when it should have been '0'. We totally
eliminated the local variables and the problem when away. I've included
old and new code fragments:
<!--Original/Broken Code-->
<xsl:template name="OutputFieldAndValue">
<xsl:param name="count" />
....
<xsl:variable name="paddingSpaces">
<xsl:value-of select="$num * 4" />
</xsl:variable>
....
<xsl:variable name="calculatedPadding">
<xsl:value-of
select="substring($TranslatedSpaces,1,$paddingSpaces)" />
</xsl:variable>
....
<xsl:for-each select="*">
<xsl:call-template name="OutputFieldAndValue">
<xsl:with-param name="count" select="$count+1" />
</xsl:call-template>
</xsl:for-each>
....
</xsl:template>
<!--New/Working Code-->
<xsl:template name="OutputFieldAndValue">
<xsl:param name="count" select="0" />
<xsl:param name="indent" select="''" />
....
<xsl:for-each select="*">
<xsl:call-template name="OutputFieldAndValue">
<xsl:with-param name="count" select="$count+1" />
<xsl:with-param name="indent"
select="substring($TranslatedSpaces,1,$count*4)" />
</xsl:call-template>
</xsl:for-each>
....
</xsl:template>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Concurrency problems with variable management?
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
We seem to have isolated a couple of concurrency problems to the
handling of (template scope) variables in two different contexts. I
will include code fragments to illustrate the problems. Corporate
proprietary policies will not allow me to send the entire source or the
data. Within the next couple of weeks it is my intent to attempt to
reproduce both of these problems with simple/benign examples which (if
successful) I will submit with a bug report.
Our thread test driver is running 20 threads on a 8 processor box. Each
thread is performing the same set of 16 different transformations (in a
couple of different orders). Each transformation is performed by a SAX
processing chain. The XSL transforms are loaded into templates. The
classes used in the SAX processing chain are recreated for each
transformation.
In the first example, a local variable is passed to two separate
templates. The value of the IntermediateValue variable changes between
the two xsl:call-template invocations. The incorrect value can be found
in the input XML. We believe the incorrect value is being picked up
from another thread. This error will generally occur once or twice
every 10 runs (of the 20 threads).
<xsl:template match="sep-gmt-post-timestamp" priority="20.0">
<xsl:variable name="IntermediateValue"
select="concat(normalize-space(.),
substring-after(../event-creation-timestamp,'Z'))" />
<xsl:call-template name='TransformField'>
<xsl:with-param name="IntermediateValue"
select="$IntermediateValue" />
<xsl:with-param name="OtherElements">
<xsl:call-template name="FormatDateTime">
<xsl:with-param name="Input">
<xsl:value-of select="$IntermediateValue" />
</xsl:with-param>
</xsl:call-template>
</xsl:with-param>
</xsl:call-template>
</xsl:template>
The other error occurred on almost every test run. A local variable
inside of a recursive template call appeared to be changing. The
"count" was sometimes '1' when it should have been '0'. We totally
eliminated the local variables and the problem when away. I've included
old and new code fragments:
<!--Original/Broken Code-->
<xsl:template name="OutputFieldAndValue">
<xsl:param name="count" />
....
<xsl:variable name="paddingSpaces">
<xsl:value-of select="$num * 4" />
</xsl:variable>
....
<xsl:variable name="calculatedPadding">
<xsl:value-of
select="substring($TranslatedSpaces,1,$paddingSpaces)" />
</xsl:variable>
....
<xsl:for-each select="*">
<xsl:call-template name="OutputFieldAndValue">
<xsl:with-param name="count" select="$count+1" />
</xsl:call-template>
</xsl:for-each>
....
</xsl:template>
<!--New/Working Code-->
<xsl:template name="OutputFieldAndValue">
<xsl:param name="count" select="0" />
<xsl:param name="indent" select="''" />
....
<xsl:for-each select="*">
<xsl:call-template name="OutputFieldAndValue">
<xsl:with-param name="count" select="$count+1" />
<xsl:with-param name="indent"
select="substring($TranslatedSpaces,1,$count*4)" />
</xsl:call-template>
</xsl:for-each>
....
</xsl:template>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Concurrency problem with static Java calls.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
Spoke to soon. The incident rate dropped a lot, but the problem still
persistes.
Edward L. Knoll wrote:
> Context: Xalan-J, 2.6.0; SAX transformation chain.
>
> We were having a concurrency operation associated with a call to a
> static Java method we were making from an XSL stylesheet. We
> restructured the Java class, so that the operation could be performed
> as a method call on an instance; the static method was changed to
> create an instance of the class and make the instance method call.
>
> When we create an object instance and make the instance method call,
> we do not have a concurrency problem. If we call the static method,
> we have a concurrency problem. I reverified that the problem is still
> there with the static method call after restructuring the class.
>
> What ever this problem is, it's tied up with how static Java method
> calls are handled from the stylesheet versus instance method calls.
> The static method call is reentrant; there should not have been a
> problem. The problem appears to be tied up with how the parameters are
> handled; in some instances it appears as though parameters from one
> invocation are mixed up with another (presumably from another
> thread). If I were to hazard a guess, on static Java method calls the
> parameters are being maintained in a static structure.
>
> I won't be researching this farther, since will be using the instance
> method call. As I've said before, company proprietary policies won't
> allow me to provide source. Our test driver is running 10 threads on
> a 8 CPU platform.
>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
More concurrency problems ....
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
Another concurrency issue has been isolated to a recursive XSL
template. This template has a (local) variable established using a
count passed to the template. The variable is an indent string; the
parameter is a number used to determine the amount of indent. Very
infrequently the indent string (variable) doesn't match the count
(parameter).
We've also encountered an output discrepancy in serialized XML output;
we've seen this once over a very large number of runs. The was a known
problem associated with HTML serialization and most of those issues
disappeared when we replaced the HTML Serializer with our own. We'll
try that with the XML Serializer.
I'm beginning to feel like I'm herding cats. I'm not sharing any XML
parsers, ContentHandlers, TransformHandlers, or Serializes between
threads. Is there anything else I should be doing to improve concurrent
behavior?
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Concurrency problem with static Java calls.
Posted by Morris Kwan <mk...@ca.ibm.com>.
Hi, Edward
You can open a bug in the JIRA database
(http://nagoya.apache.org/jira/secure/Dashboard.jspa).
Please attach the description here in the bug report. It might be difficult
to diagnose the problem without a testcase. If possible, please also
describe the types of the parameters, in case the problem is related to the
parameter types.
Thanks.
Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: mkwan@ca.ibm.com
"Edward L. Knoll"
<ed.knoll@cosd.fe
dex.com> To
xalan-dev@xml.apache.org
12/17/2004 10:41 cc
AM
Subject
Concurrency problem with static
Please respond to Java calls.
xalan-dev
Context: Xalan-J, 2.6.0; SAX transformation chain.
We were having a concurrency operation associated with a call to a
static Java method we were making from an XSL stylesheet. We
restructured the Java class, so that the operation could be performed as
a method call on an instance; the static method was changed to create an
instance of the class and make the instance method call.
When we create an object instance and make the instance method call, we
do not have a concurrency problem. If we call the static method, we
have a concurrency problem. I reverified that the problem is still
there with the static method call after restructuring the class.
What ever this problem is, it's tied up with how static Java method
calls are handled from the stylesheet versus instance method calls. The
static method call is reentrant; there should not have been a problem.
The problem appears to be tied up with how the parameters are handled;
in some instances it appears as though parameters from one invocation
are mixed up with another (presumably from another thread). If I were
to hazard a guess, on static Java method calls the parameters are being
maintained in a static structure.
I won't be researching this farther, since will be using the instance
method call. As I've said before, company proprietary policies won't
allow me to provide source. Our test driver is running 10 threads on a
8 CPU platform.
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Concurrency problem with static Java calls.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
Context: Xalan-J, 2.6.0; SAX transformation chain.
We were having a concurrency operation associated with a call to a
static Java method we were making from an XSL stylesheet. We
restructured the Java class, so that the operation could be performed as
a method call on an instance; the static method was changed to create an
instance of the class and make the instance method call.
When we create an object instance and make the instance method call, we
do not have a concurrency problem. If we call the static method, we
have a concurrency problem. I reverified that the problem is still
there with the static method call after restructuring the class.
What ever this problem is, it's tied up with how static Java method
calls are handled from the stylesheet versus instance method calls. The
static method call is reentrant; there should not have been a problem.
The problem appears to be tied up with how the parameters are handled;
in some instances it appears as though parameters from one invocation
are mixed up with another (presumably from another thread). If I were
to hazard a guess, on static Java method calls the parameters are being
maintained in a static structure.
I won't be researching this farther, since will be using the instance
method call. As I've said before, company proprietary policies won't
allow me to provide source. Our test driver is running 10 threads on a
8 CPU platform.
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Other concurrency issues ....
Posted by Brian Minchau <mi...@ca.ibm.com>.
Edward,
with SAX output one of three classes can get involved:
ToXMLSAXHandler
ToHTMLSAXHandler
ToTextSAXHandler
If Xalan "knows" from the <xsl:output> method attribute what the output
type is, we take advantage of that.
For example the ToTextSAXHandler will pretty much ignore
startElement/endElement calls, and this is an optimization earlier on in
output chain.
I can't remember exactly what, but ToXMLSAXHandler and ToHTMLSAXHandler
also differ. If you are providing your own ContentHandler implementation
then there is a conversion from SAX-like to SAX method calls going on here
with one of the 3 classes mentioned above. Without more information on what
your anomalous behavior is, and what your set-up is, I can't say more.
----------
Brian Minchau
XSLT Development, IBM Toronto
e-mail: minchau@ca.ibm.com
"Edward L. Knoll"
<ed.knoll@cosd.fe
dex.com> To
xalan-dev@xml.apache.org
12/16/2004 10:47 cc
AM
Subject
Other concurrency issues ....
Please respond to
xalan-dev
While we appear to have resolved our two biggest concurrency issues, I
still have a couple of lingering problems I'm trying to
characterize/isolate.
Does anyone know of any concurrency problems related to the XSL
extension mechanism for accessing/calling Java classes/methods? We're
accessing a class we've demonstrated to be thread safe in another
context. We're accessing that class through a wrapper, so the problem
could be there although I currently can't see it.
Even using our own HTML serializer, we're getting some anomalous output
in the final HTML. Does anyone know whether a <xsl:output ...>
statement in the stylesheet is going to have any affect on the XSL
processing (using a SAX TransformHandler) if we don't have a standard
(HTML) Serialize in our SAX processing chain?
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Other concurrency issues ....
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
While we appear to have resolved our two biggest concurrency issues, I
still have a couple of lingering problems I'm trying to
characterize/isolate.
Does anyone know of any concurrency problems related to the XSL
extension mechanism for accessing/calling Java classes/methods? We're
accessing a class we've demonstrated to be thread safe in another
context. We're accessing that class through a wrapper, so the problem
could be there although I currently can't see it.
Even using our own HTML serializer, we're getting some anomalous output
in the final HTML. Does anyone know whether a <xsl:output ...>
statement in the stylesheet is going to have any affect on the XSL
processing (using a SAX TransformHandler) if we don't have a standard
(HTML) Serialize in our SAX processing chain?
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Concurrency issue ....
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
We have a custom ContentHandler in a SAX processing chain which we use
to filter for nodes we wish to pass on. The filter is defined via a XML
file which we read into a NodeList. Since the filter definition is
static and we are only reading the NodeList, we set the filter up to be
shared between instances of the associated ContentHandler.
We are (intermittently) getting exceptions within the
NodeList.getLength() method. I don't know if our expectations are
inappropriate or if there is some problem buried within this NodeList
method/class.
If it is a problem, I can't supply source/data (company proprietary
policies), so I hope that's enough to go on.
I will be working on an alternate implementation, so am not looking for
resolution (although suggestions are welcome, if timely :).
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: question .... Resolved
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
Figured out. I was expecting to see the " " sequence from the
source coming through since that's what the HRML Serializer was
outputting. As it turned out, a '\u00A0' value was coming through.
Edward L. Knoll wrote:
> We have a SAX transformation chain that terminates with HTML output.
> Because we work in a multi-threaded context and because there is a
> concurrency issue with the Xalan-J 2.6.0 HTML serialization, we are
> (attempting) to introduce our own (simple) HTML serializer as a SAX
> ContentHandler.
>
> We've run into a problem with non-breaking spaces. Some of our XSL
> stylesheets need to output ' ' sequences, so those XSL
> stylesheets containing the following statement, so they can include
> ' ' inline:
>
> <!DOCTYPE xsl:stylesheet [ <!ENTITY nbsp " "> ]>
>
> None of the ' ' sequences are making it through our
> ContentHandler/serializer; they do make it through a Serializer
> configured for HTML output.
>
> I'd appreciate any information regarding how to resolve this problem.
>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
question ....
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
We have a SAX transformation chain that terminates with HTML output.
Because we work in a multi-threaded context and because there is a
concurrency issue with the Xalan-J 2.6.0 HTML serialization, we are
(attempting) to introduce our own (simple) HTML serializer as a SAX
ContentHandler.
We've run into a problem with non-breaking spaces. Some of our XSL
stylesheets need to output ' ' sequences, so those XSL stylesheets
containing the following statement, so they can include ' ' inline:
<!DOCTYPE xsl:stylesheet [ <!ENTITY nbsp " "> ]>
None of the ' ' sequences are making it through our
ContentHandler/serializer; they do make it through a Serializer
configured for HTML output.
I'd appreciate any information regarding how to resolve this problem.
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Threading / concurrency problem.
Posted by Brian Minchau <mi...@ca.ibm.com>.
Hi, Ed:
This also reminds me of XALANJ-1861.
http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=XALANJ-1861
This fix would be in the current CVS but not in 2.6.0
----------
Brian Minchau
XSLT Development, IBM Toronto
e-mail: minchau@ca.ibm.com
Henry
Zongaro/Toronto/I
BM@IBMCA To
xalan-dev@xml.apache.org
12/07/2004 11:32 cc
AM
Subject
Re: Threading / concurrency
Please respond to problem.
xalan-dev
Hi, Ed.
"Edward L. Knoll" <ed...@cosd.fedex.com> wrote on 2004-12-06 01:19:14
PM:
> We have a class that puts together a SAX processing chain. We have put
> together a threaded test driver to exercise instances of this class
> concurrently and we're seeing some anomalous behavior involving
> whitespace. We're seeing extra line breaks and non breaking spaces
> introduced into the final output stream.
>
> Each instance of this class has it's own instances of the core
> processing components:
>
> - Serializer (up to three instances per transformation thread)
> - XMLReader (never more than one per thread)
> - TransformerHandlers (up to two per transformation thread)
> - custom classes implementing the ContentHandler interface
>
> The only (static) class instances (knowingly) shared across these
> threads are:
>
> - Templates for different transformations we may perform.
> - Property generated from OutputPropertiesFactory configured for XML
output.
> - Property generated from OutputPropertiesFactory configured for HTML
> output..
From your description, it sounds like you're putting together the
pieces in a way that ought to be thread-safe.
I took a quick look at the classes that implement serialization, and I
notice that the Serializer.setOutputFormat(Properties) maintains a
reference to the argument Properties object that is passed in, as opposed
to making a copy of it. Is it possible that your code makes changes to the
Properties object that's produced by OutputPropertiesFactory before passing
it to Serializer.setOutputFormat at the same time that some other
Serializer is using that same Properties object?
I'm not saying that it's right or wrong for
Serializer.setOutputFormat(Properties) to use a reference to the Properties
object - just making an observation.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Threading / concurrency problem.
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Ed.
"Edward L. Knoll" <ed...@cosd.fedex.com> wrote on 2004-12-06 01:19:14
PM:
> We have a class that puts together a SAX processing chain. We have put
> together a threaded test driver to exercise instances of this class
> concurrently and we're seeing some anomalous behavior involving
> whitespace. We're seeing extra line breaks and non breaking spaces
> introduced into the final output stream.
>
> Each instance of this class has it's own instances of the core
> processing components:
>
> - Serializer (up to three instances per transformation thread)
> - XMLReader (never more than one per thread)
> - TransformerHandlers (up to two per transformation thread)
> - custom classes implementing the ContentHandler interface
>
> The only (static) class instances (knowingly) shared across these
> threads are:
>
> - Templates for different transformations we may perform.
> - Property generated from OutputPropertiesFactory configured for XML
output.
> - Property generated from OutputPropertiesFactory configured for HTML
> output..
From your description, it sounds like you're putting together the
pieces in a way that ought to be thread-safe.
I took a quick look at the classes that implement serialization, and
I notice that the Serializer.setOutputFormat(Properties) maintains a
reference to the argument Properties object that is passed in, as opposed
to making a copy of it. Is it possible that your code makes changes to
the Properties object that's produced by OutputPropertiesFactory before
passing it to Serializer.setOutputFormat at the same time that some other
Serializer is using that same Properties object?
I'm not saying that it's right or wrong for
Serializer.setOutputFormat(Properties) to use a reference to the
Properties object - just making an observation.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Threading / concurrency problem.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
We have a class that puts together a SAX processing chain. We have put
together a threaded test driver to exercise instances of this class
concurrently and we're seeing some anomalous behavior involving
whitespace. We're seeing extra line breaks and non breaking spaces
introduced into the final output stream.
Each instance of this class has it's own instances of the core
processing components:
- Serializer (up to three instances per transformation thread)
- XMLReader (never more than one per thread)
- TransformerHandlers (up to two per transformation thread)
- custom classes implementing the ContentHandler interface
The only (static) class instances (knowingly) shared across these
threads are:
- Templates for different transformations we may perform.
- Property generated from OutputPropertiesFactory configured for XML output.
- Property generated from OutputPropertiesFactory configured for HTML
output..
None for our final output is mangled or missing; we just seem to have
extra whitespace. A transformation sequence might capture the raw XML
input to a file, capture a generated intermediate XML form to a file,
and/or capture a final HTML display output to a file. All of the
discrepancies so far have been in the final HTML output.
We have never seen any differences in the output from run to run doing
these transformations in a single thread. Running in three threads has
generated discrepancies, but not consistently. Running with six threads
seems to consistently generate discrepancies. The discrepancies are not
predictable or consistent from run to run.
My understanding is that Templates should be thread safe and I would not
expect the Property objects returned from OutputPropertiesFactory to be
a problem.
I'd appreciate any light anyone might be able to shed on this problem.
Thanks,
Ed Knoll
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Problem with Transformer.setParameter() in SAX chain.
Posted by "Edward L. Knoll" <ed...@cosd.fedex.com>.
Thanks for all the feedback I received. It helped me understand why I
had a problem and led me to a solution. The XSL Transformation could
not be incremental; it would have to collect the entire tree before
processing and then it would use what ever value the parameter had at
the time. I would hazard this processing is triggered by the
ContentHandler.endDocument() event.
The solution I went with was to create a custom ContentHandler to use
when each of the raw XML streams was being processed. This
ContentHandler looked for a specific element and then introduced a new
element with the value I was trying to set by parameter.
>I have chain of Sax handlers which is effectively a XMLReader chained to
>SAXTransformer chained to a custom ContentHandler chained to a
>Serializer. I am actually parsing multiple XML input streams to
>generate a single output XML stream. The custom Content Handler
>suppresses all but the first startDocument() event and the last
>endDocument() event to keep the Serializer which is generating the
>single XML output from getting upset.
>
>This is the net chain; my actually chain contains some custom "tee"
>ContentHandlers and additional flows of SAX events, but I don't believe
>those to be germane to my problem.
>
>I need to change a parameter with the SAXTransformer for each file
>processed. This parameter is used to generate an output element for
>each file processed. I can do a setParameter() followed by a
>getParameter() and see that the parameter is changed in the Transformer.
> This is done for each file before doing a XMLReader.parse().
>
>My problem is that the elements in the output XML which represent this
>changing parameter only have the last value this parameter was set to.
>I've tried doing a Transformer.clearParameters() between
>XMLReader.parse() actions, but that appears to have no affect.
>
>I would think that each XMLReader.parse() execution and so each XSL
>Transformation would be independent of each other. I don't see how
>anything other than the value of this changing parameter can be
>propagating through the custom ContentHandler given the signatures of
>the ContentHandler methods.
>
>
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Problem with Transformer.setParameter() in SAX chain.
Posted by Brian Minchau <mi...@ca.ibm.com>.
Ed,
Your setParameter() need to be made before "the" transformation starts,
effectively sets a global xsl:param in your stylesheet. However once the
transformation has started you can't change the value of global stylesheet
variables in the middle of a transformation. You are going to need multiple
transformations and do the setParameter() on each one before the
transformation starts. But you should be able to concatenate your output by
reusing the output Writer or OutputStream from one transformation to the
next.
How about this. You have created the java.io.Writer or a
java.io.OutputStream. You can use the org.apache.xml.serializer.Serializer
interface to set either your Writer or your OutputStream. Run each of your
documents through your stream with a startDocument and endDocument. For the
first document let it write out the XML header. For subsequent documents
you can call the reset() method on the serializer, or get a new Serializer,
but you should be able to reuse that serializer (you might have to
setWriter() with the same writer ...). Also for subsequent transformations
you need to set the property on the serializer to omit the xml header:
java.util.Properties p = new Properties();
p.setProperty("omit-xml-header", "yes");
Serializer.setOutputFormat(p);
For each transformation leading into this serializer you should be able to
setParameter().
----------
Brian Minchau
XSLT Development, IBM Toronto
e-mail: minchau@ca.ibm.com
"Edward L. Knoll"
<ed.knoll@cosd.fe
dex.com> To
xalan-dev@xml.apache.org
10/20/2004 08:00 cc
PM
Subject
Problem with
Please respond to Transformer.setParameter() in SAX
xalan-dev chain.
I have chain of Sax handlers which is effectively a XMLReader chained to
SAXTransformer chained to a custom ContentHandler chained to a
Serializer. I am actually parsing multiple XML input streams to
generate a single output XML stream. The custom Content Handler
suppresses all but the first startDocument() event and the last
endDocument() event to keep the Serializer which is generating the
single XML output from getting upset.
This is the net chain; my actually chain contains some custom "tee"
ContentHandlers and additional flows of SAX events, but I don't believe
those to be germane to my problem.
I need to change a parameter with the SAXTransformer for each file
processed. This parameter is used to generate an output element for
each file processed. I can do a setParameter() followed by a
getParameter() and see that the parameter is changed in the Transformer.
This is done for each file before doing a XMLReader.parse().
My problem is that the elements in the output XML which represent this
changing parameter only have the last value this parameter was set to.
I've tried doing a Transformer.clearParameters() between
XMLReader.parse() actions, but that appears to have no affect.
I would think that each XMLReader.parse() execution and so each XSL
Transformation would be independent of each other. I don't see how
anything other than the value of this changing parameter can be
propagating through the custom ContentHandler given the signatures of
the ContentHandler methods.
--
Edward L. Knoll Phone (FedEx) : (719)484-2717
e-mail (FedEx) : edward.knoll@fedex.com
e-mail (personal) : edward@elknoll.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org