There is more than one method matching...

2009-01-14
2012-10-08
  • Andre John Mas

    Andre John Mas - 2009-01-14

    Hi,

    I am in the process of migrating some code from Xalan to Saxon and have run into a small problem. The following code works without issue in Xalan:

    <xsl:value-of select="i18n:getTextItem($currentLanguage, .)"/>

    In the class referenced by i18n there are two definitions for getTextItem:

    String getTextItem(java.lang.String lang, org.w3c.dom.NodeList list) ;
    String getTextItem(java.lang.String lang, java.lang.String item) ;

    I would have thought that since Xalan can make the distinction Saxon should have been able to.

    Anyhow the data being passed in this case is a node:

    <Error>errors.required<Param>form.fieldA</Param></Error>

    Is there any way to work around the limitation by testing in XSL and then somehow forcefully telling Saxon to treat the node as a node list?

    BTW I am using Saxon 9 with JDK 1.5

    Andre

     
    • Michael Kay

      Michael Kay - 2009-01-15

      There's no intrinsic reason to believe that extension functions in Saxon should work the same way as in Xalan. When they do, it's a bonus. There are several significant differences: (a) Saxon's rules for disambiguating polymorphic Java methods rely much more heavily on static type analysis (Saxon always decides which method to use at compile time, not at run time), (b) in XSLT 2.0, "." is not necessarily a node - it could also be a string (c) Xalan has a much more intimate relationship with the DOM than Saxon has - in Saxon the relationship is very much at arm's length.

      In principle, though, I think this disambiguation should work according to the rules at http://www.saxonica.com/documentation/extensibility/converting-args/converting-atomic.html. How exactly is it failing, and what does the -TJ output from the binding process say?

      It might help to use a variable with an explicitly declared type in the call, rather than using ".". It depends on the context - in most cases Saxon will know statically that "." is a node. And in any case, the rules cited above suggest that a method expecting a NodeList should be preferred anyway.

      If you can put together a repro in a form that I can run, this will help me to investigate this case.

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks