In my example.security.SelectedItem class, I have the method setMap().
But when I try to access the page, I get following error:
[ERR 0343] The XSLT processor was unable to resolve a reference to the Java method 'setMap'
I am using Websphere 7 and RADAD.
The same worked fine earlier when I used Websphere 6.1 and AST
I'm guessing you are passing a String, not a HashMap, when you use a scriptlet like that. And that therefore the XSL transformer can't find a "setMap(String)" method.
You could test this theory by providing a "setMap(String)" method and seeing if it got called.
Joined: Aug 24, 2009
I added the method. But it still doesnt work. I got the same error.
In Websphere 6.1, xalan.jar is present in the com.ibm.ccl.xtt.xslt4j_2.7.5.v200610160956\lib folder.
I could not find xalan.jar anywhere in the Websphere7.0 installation folder. Has anything changed in Websphere7.0 ? Maybe the version of xalan.jar, or something else ...
>I added the method. But it still doesnt work. I got the same error. If you have that method setup in the class, then you have to either pass the parameter to map in String and that's is important.
_or_ that you've to "convert" it to (xs:)string type in the xsl document, like this:
And then, that would most probably get processed and the setMap() will then receive the argument as expected.
In fact, it would always be less hazardeous, if at all possible, I would say, to pass argument in the xsl document using simple type in the sense of xsd. Complex type, such as passing in some HashMap param would mostly post problem. There is some dynamic casting of param method, but as far as I can experiment with it, it triggers security problem that cannot be resolved without tempering with security manager to grant some privilege or something. If it worked once and that now it doesn't, it is probably related to tightening up of security policy as well - but I am just guessing upon Websphere.
Now, the practical problem is more that of passing a HashMap variable as string and to restore it to the intended HashMap. That cannot be done reliably. So to make the approach more robust, I would say it would be better to  set up Properties object instead of HashMap for topNavMap and serialize it with storeToXML() producing a string;  pass the (xml) string to xsl document to feed it to the helper extension function with the signature of taking a string argument;  in the helper extension function, restore the Properties object with loadFromXML(), but this time it is a reliable process;  convert the Properties object to a HashMap and feed it to the existing setMap(). This would be a more reliable procedure to get it done.
It looks like you suspect that Xalan is not being used as the XSLT processor, which would make Xalan-specific namespaces stop working. To find out which processor is used to do a transform, insert this in the code: