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) : [EMAIL PROTECTED] e-mail (personal) : [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
