Saxon

It would be good to see the actual function call, but from this information it looks as if Saxon knows nothing about the type of the argument supplied in the call. That's not uncommon for code originally written for XSLT 1.0, where typically there will be no "as" clauses on variables and parameters to allow the types of parameters to be inferred.

If the supplied argument is a variable reference then it's often enough to give it an explicit type, for example

in other cases a "treat as" clause can be useful:

select="test:call($x treat as xs:string)"/>

The key thing is that Saxon has to make a static (compile-time) decision which of the methods to call, and therefore the more type information you make available, the better.

The actual function calls, pass a variable containing xml string or the input xml as is. Samples given below.

In most cases the expected method call to match is, public org.w3c.dom.Node x.y.TestClient.call(org.w3c.dom.Node)

There is no type information in the existing xsl however adding - as="element()" or "node()" type did not resolve the method call. How do we cast or explicitly specify type as dom.Node or jdom2.Document in this case?

1. One of the method call argument is a xml generated at runtime <xsl:variable name="request" > <xsl:copy-of select="." /> </xsl:variable> <xsl:variable name="client" select="TestClient:new($processor, xs:string($url))" /> <xsl:variable name="response" select="TestClient:call($client, $request)" />

2. request xml passed as is in some cases <xsl:template match="/request"> <xsl:apply-templates select="body"/> </xsl:template> <xsl:template match="body"> <xsl:variable name="response" select="TestClient:call($client, root)"/> <xsl:copy-of select="$response/root"/> </xsl:template>

or

<xsl:variable name="response" select="TestClient:call($client, .)" />

Sorry, it's difficult to answer because you've only posted some fragments of your code:you haven't shown what TestClient.new() and TestClient.call() actually do.

If your Java method expects a JDOM2 node, then the call is going to fail unless you pass something that is a JDOM2 node. If the input document is a JDOM2 document and you pass a node in the input document, that should be OK; but if you pass a node that the stylesheet has constructed, that won't be a JDOM2 node so it will always fail.

If your Java method expects a DOM node, the situation is slightly more flexible because Saxon is capable of creating a wrapper around its internal nodes to give them a DOM interface (DOM is defined in terms of interfaces, whereas JDOM2 uses concrete classes which makes this approach impossible.)

I think we need a repro: a complete executable stylesheet and a complete Java class, so that we can see exactly what you're doing and where it's going wrong.