Saxon

SourceForge user: mhkay

Logged In: YES

user_id=251681

I can't reproduce this. This stylesheet:

<xsl:stylesheet version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" version="1.0" encoding="UTF-8"

      indent="yes"/>

<xsl:param name="keyname" select="'html.center'"/>

<xsl:param name="listenerOutput" select="'abracadabra'"/>

<xsl:template name="main"

 xmlns:map="java:java.util.TreeMap" >

<xsl:variable name="mymap" select="map:new()" />

<xsl:value-of

select="map:put($mymap,$keyname,concat($listenerOutput,''))"/>

<xsl:value-of select="map:keySet($mymap)" />

<xsl:value-of

select="map:get($mymap,'html.center')"/>

<xsl:value-of

select="map:containsKey($mymap,'html.center')" />

</xsl:template>

</xsl:stylesheet>

produces this output:

<keySet

xmlns:map="java:java.util.TreeMap">[html.center]

<keyValue

xmlns:map="java:java.util.TreeMap">abracadabra

true

Please submit a complete self-contained test case that

demonstrates the problem, and say which version you are running.

SourceForge user: mhkay

Logged In: YES

user_id=251681

Another observation: the value actually stored in your Map

is a Java object of class net.sf.saxon.value.StringValue.

Because the signature of the put() and get() methods

requires only Object, it's important that the values you

supply in your calls to these methods are actually of the

same XPath type. StringValue has an equals() method which

relies on String.equals(). It should also cause a string to

match an UntypedAtomicValue. But if you supplied a node in

the call on get() it wouldn't work: as the Java method

accepts Object, the node would not be atomized.

I don't think the behaviour of FastStringBuffer comes into it.

SourceForge user: rohanr2

Logged In: YES

user_id=570959

I am not sure if it will help, but here is the file - it's part of a larger

system though...

the map key get set at line 140 and retrived at 174. The template

"thoth:include" runs another java extention that does another transform

and returns the result as a java String, looks something like:

<xsl:variable name="results"

		select="xslexe:transform(

			xslexe:new(),

			concat($request_string,''),

			concat($page_string,''),

			thoth:variableToList($params,'`'),

			concat('/',$file)

		)"

	/>

	
	<xsl:value-of select="$results" />

where that method returns a proper java String.

And it was an eariler version of saxon 8 that it worked (the name of the

working jar is saxon8.jar, and the date on the file is May 30th)

SourceForge user: mhkay

Logged In: YES

user_id=251681

Sorry, I can't really help you debug this unless you provide

me with something I can run.

My guess would be that you're falling foul of some

optimization. Calling methods with side-effects (such as

map.put()) can behave in very unpredictable ways, given the

non-sequential execution model of XSLT. It's really not a

recommended way of using the language.

I'd suggest you write your own Map class as a wrapper around

the Hashmap class, and trace the calls on put and get, with

particular attention to the types of the objects that are

being put/got.

Michael Kay

SourceForge user: mhkay

Logged In: YES

user_id=251681

By the way, I should have reminded you of the notice on the

"Submit" bug" form that this section of the site is for

comfirmed bugs only. Please use "support requests" or the

saxon-help list/forum in future. To make life easier for

people searching for real bugs, I'm marking this one as

"closed/invalid".

Michael Kay

SourceForge user: rohanr2

Logged In: YES

user_id=570959

I fully understand - I was assuming it was a bug in saxon since it worked

with an earily version and not with the lastest. I'll write a standlone test

case as you suggested later today.