RE: argument type mismatch when using fn:replace
Here are some notes on how to add the saxon transformer in attached screenshot. Whenever you need xslt2.0 support just specify saxon map:transform src=xslt/watermark.xslt type=saxon/ and you're good to go. Robby Pelssers winmail.dat - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: argument type mismatch when using fn:replace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robby, On 8/17/2010 6:29 AM, Robby Pelssers wrote: Here are some notes on how to add the saxon transformer in attached screenshot. No attachment; only one of those stupid MS winmail.dat files :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqpx8ACgkQ9CaO5/Lv0PDTLQCfcfY4z2N9g3QFysXwv0wOZkbD 1n8An3vzZetn9v2DXK+vGuxePOqNjv3H =M+O5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
RE: argument type mismatch when using fn:replace
Ok... I'm a bit lazy today so i just uploaded the attachment to my blog. http://robbypelssers.blogspot.com/2010/08/using-saxon-instead-of-xalan-with.html Cheers, Robby Pelssers winmail.dat - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: argument type mismatch when using fn:replace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 8/6/2010 4:39 PM, florent andré wrote: Good news, you don't have to switch all your cocoon app from xalan to saxon !! Thanks for the tip! It's great to know that Xalan and Saxon can be used in the same Cocoon instance. That will dramatically lessen the burden of testing, since I'll only have to test the one stylesheet that requires XSLT 2.0 and XPath 2.0. Thanks! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxi1rcACgkQ9CaO5/Lv0PCfaQCghJMzReKNjoIVWdwKcJfmd0Zl b10AniN2GqN6kGHrAaCjzlR6N/nA0T7W =W4e7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: argument type mismatch when using fn:replace
Hi Chris, Good news, you don't have to switch all your cocoon app from xalan to saxon !! You can easily have a pretty map:transformer type=xslt2.0 src=path/to/my/xslt2.0.xsl/ For this, you just have to : 1) add this libs in your classpath : http://svn.4sengines.eu/modcontrib/xslt2.0/trunk/java/lib/ 2) patch your cocoon.xconf with this http://svn.4sengines.eu/modcontrib/xslt2.0/trunk/config/cocoon-xconf/component-declaration.xconf ( just copy the component node into the ) 3) declare a transformer in your sitemap : http://svn.4sengines.eu/modcontrib/xslt2.0/trunk/sitemap.xmap ( components/tranformer node) 4) Add... use it ! example also here http://svn.4sengines.eu/modcontrib/xslt2.0/trunk/sitemap.xmap into map:match pattern=* Just use when you need it, no global impact, I use it many times with no problems and enjoy xslt2.0. HTH ++ On 08/05/2010 07:42 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 8/5/2010 1:32 PM, Mark Eggers wrote: I haven't used Cocoon in quite a while, but I remember that you can use Saxon instead of Xalan. A quick google search brings up the following old blog entry from Vadim: http://blog.reverycodes.com/archives/34.html Maybe that's a good start? Thanks for the tip: I'll start there. It does look like switching from Xalan to Saxon is relatively painless, and, if the performance claims in that post are accurate, I may even get a faster product in the end. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxa9+0ACgkQ9CaO5/Lv0PB2pgCff9uHxt73O69IxhacUIEVkcK7 tWUAnRNDAJRJaIj4bzzMOl3iBUErbgTP =8rMS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: argument type mismatch when using fn:replace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas, On 8/4/2010 5:09 PM, Thomas Ernest wrote: I remember having this problem, when I used the same version of Cocoon one year ago. I'm not 100% sure, but I mean fn:replace is a function belonging to XPath 2.0 [1] and Cocoon 2.1.11 integrates a Xalan implementing XPath 1.0 only. That would certainly explain the problem. My Cocoon has Xalan-2.7.1, which only supports XSLT 1.0 and XPath 1.0. It's odd that Xalan 2.7.1 is the latest version available. Is Xalan dead? Does Saxon replace it? You should check which version of Xalan do you use and be sure this version implements XPath 1.0 only. You were right, although I was thrown by the fact that changing the stylesheet version to 2.0 allowed me to use the xsl:analyze-string element, which is apparently not implemented. I guess anything not implemented is ignored. Does that sound right? For the time being, I implemented a manual search-and-replace which does work with Cocoon 2.1.11. I think my best option is to upgrade Cocoon. It's about time, anyway. It's always so nerve-wracking to upgrade something so vital to your product, though :) Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxa7YsACgkQ9CaO5/Lv0PD4KwCgpW4uc1fdeEgH9cLedoxy93WA njQAn3Vb57GRcTtJqNXuFkLG7bOcIPkc =mzJH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: argument type mismatch when using fn:replace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, On 8/5/2010 12:57 PM, Christopher Schultz wrote: On 8/4/2010 5:09 PM, Thomas Ernest wrote: I remember having this problem, when I used the same version of Cocoon one year ago. I'm not 100% sure, but I mean fn:replace is a function belonging to XPath 2.0 [1] and Cocoon 2.1.11 integrates a Xalan implementing XPath 1.0 only. That would certainly explain the problem. My Cocoon has Xalan-2.7.1, which only supports XSLT 1.0 and XPath 1.0. It's odd that Xalan 2.7.1 is the latest version available. Is Xalan dead? Does Saxon replace it? It appears that no current version of Cocoon supports XSLT 2.0. Is that correct? Since neither Xalan nor Cocoon support XSLT/XPath 2.0 directly, is it okay to simply replace Xalan with another XSLT processor like Saxon? I'm unsure of what level of dependency Cocoon has on Xalan... hopefully, everything is done using the JAXP interfaces and not implementation-specific calls, but there may be some Xalan-specific configuration that Cocoon provides in order to grease the wheels a bit. Any suggestions that anyone has could be greatly appreciated. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxa780ACgkQ9CaO5/Lv0PDxJgCfZ3v+BcKYONZbve0WAdDBaD6n lScAoKuPuYz3z6spVlOlRjLml3C+8hb4 =aXy0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: argument type mismatch when using fn:replace
I haven't used Cocoon in quite a while, but I remember that you can use Saxon instead of Xalan. A quick google search brings up the following old blog entry from Vadim: http://blog.reverycodes.com/archives/34.html Maybe that's a good start? /mde/ - Original Message From: Christopher Schultz ch...@christopherschultz.net To: users@cocoon.apache.org Sent: Thu, August 5, 2010 10:07:26 AM Subject: Re: argument type mismatch when using fn:replace -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, On 8/5/2010 12:57 PM, Christopher Schultz wrote: On 8/4/2010 5:09 PM, Thomas Ernest wrote: I remember having this problem, when I used the same version of Cocoon one year ago. I'm not 100% sure, but I mean fn:replace is a function belonging to XPath 2.0 [1] and Cocoon 2.1.11 integrates a Xalan implementing XPath 1.0 only. That would certainly explain the problem. My Cocoon has Xalan-2.7.1, which only supports XSLT 1.0 and XPath 1.0. It's odd that Xalan 2.7.1 is the latest version available. Is Xalan dead? Does Saxon replace it? It appears that no current version of Cocoon supports XSLT 2.0. Is that correct? Since neither Xalan nor Cocoon support XSLT/XPath 2.0 directly, is it okay to simply replace Xalan with another XSLT processor like Saxon? I'm unsure of what level of dependency Cocoon has on Xalan... hopefully, everything is done using the JAXP interfaces and not implementation-specific calls, but there may be some Xalan-specific configuration that Cocoon provides in order to grease the wheels a bit. Any suggestions that anyone has could be greatly appreciated. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxa780ACgkQ9CaO5/Lv0PDxJgCfZ3v+BcKYONZbve0WAdDBaD6n lScAoKuPuYz3z6spVlOlRjLml3C+8hb4 =aXy0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: argument type mismatch when using fn:replace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 8/5/2010 1:32 PM, Mark Eggers wrote: I haven't used Cocoon in quite a while, but I remember that you can use Saxon instead of Xalan. A quick google search brings up the following old blog entry from Vadim: http://blog.reverycodes.com/archives/34.html Maybe that's a good start? Thanks for the tip: I'll start there. It does look like switching from Xalan to Saxon is relatively painless, and, if the performance claims in that post are accurate, I may even get a faster product in the end. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxa9+0ACgkQ9CaO5/Lv0PB2pgCff9uHxt73O69IxhacUIEVkcK7 tWUAnRNDAJRJaIj4bzzMOl3iBUErbgTP =8rMS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
argument type mismatch when using fn:replace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
I've been using Cocoon 2.1.11 successfully for quite some time, and I'm
trying to add new capabilities to our product. I'm tripping-up when
trying to use fn:replace with a regular expression.
I'm on Debian Lenny with Debian's package-managed version of Sun JRE
1.6.0_20. I'm pretty sure I haven't messed with any of the libraries
that ship with Cocoon (such as Xalan, etc.), so it should be a pretty
stock install. I've packaged my own webapp rather than using the one
that Cocoon can build for you. I can give details of that process if
necessary.
I tried to use xsl:analyze-string which gave me a cannot use
xsl:analyze-string here error, so I tried changing my xsl:stylesheet
version=1.0 to xsl:stylesheet version=2.0 which fixed that error,
but didn't give me any output.
At any rate, my current stylesheet header looks like this (with
product-specific xmlns declarations removed for brevity:
?xml version=1.0 ?
xsl:stylesheet version=2.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fn=http://www.w3.org/2005/xpath-functions;
Specifically, my original function call attempt is this (trying to
remove a query parameter form a query string):
xsl:variable name=fixed-base-url
xsl:value-of select=$base-url /
xsl:text?/xsl:text
xsl:value-of select=fn:replace($query-string,
'(amp;)?list_start=[0-9]+', '') /
/xsl:variable
Executing this results in the following error:
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.xalan.extensions.ExtensionHandlerJavaPackage.callFunction(ExtensionHandlerJavaPackage.java:404)
at
org.apache.xalan.extensions.ExtensionHandlerJavaPackage.callFunction(ExtensionHandlerJavaPackage.java:440)
at
org.apache.xalan.extensions.ExtensionsTable.extFunction(ExtensionsTable.java:222)
at
org.apache.xalan.transformer.TransformerImpl.extFunction(TransformerImpl.java:473)
at
org.apache.xpath.functions.FuncExtFunction.execute(FuncExtFunction.java:208)
at
org.apache.xpath.Expression.executeCharsToContentHandler(Expression.java:313)
at org.apache.xalan.templates.ElemValueOf.execute(ElemValueOf.java:274)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2400)
at
org.apache.xalan.transformer.TransformerImpl.transformToRTF(TransformerImpl.java:1988)
...
(let me know if more of the stack trace would be helpful)
I thought I might have some weird kind of data, so I tried something
simpler, just to be sure:
xsl:value-of select=fn:replace('abcabc', 'a', 'b') /
The above gives me the same error. Either commenting-out the entire
xsl:value-of element or changing the select to select='' removes the
error.
As for xsl:analyze-string, the following test resulted in no output:
xsl:analyze-string select='abcabc' regex=a
xsl:matching-substring
A
/xsl:matching-substring
xsl:non-matching-substring
xsl:value-of select=. /
/xsl:non-matching-substring
/xsl:analyze-string
... while I would have expected AbcAbc to be emitted. Perhaps I am
misusing the xsl:analyze-string element.
Can anyone offer any suggestions?
Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxZnmEACgkQ9CaO5/Lv0PCGcQCdGI9nhuNAXvbvtAB7ehA7KEiL
YAcAnA2af9MV5hobIKGf21d8dzBGRxw1
=wxjf
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: argument type mismatch when using fn:replace
Hi Chris,
I remember having this problem, when I used the same version of Cocoon
one year ago.
I'm not 100% sure, but I mean fn:replace is a function belonging to
XPath 2.0 [1] and Cocoon 2.1.11 integrates a Xalan implementing XPath
1.0 only.
You should check which version of Xalan do you use and be sure this
version implements XPath 1.0 only.
I guess there are some ways to use a more up-to-date Xalan (implementing
XPath 2.0), but if I well remember I used another workaround. I'm no
more sure which one, but I guess you should find enough interesting
transformers [2].
It is not the best way, but it is possible to have a heavy two-passes
mechanism. At first xslt transformer adding JX instructions (like 'if
test' or 'set var' and variable instantiations) in the right places and
then a JX transformer evaluating JX instructions (like removing 'if
test' with a false condition or removing/evaluating 'set var' in order
to instance these variables in another places).
I hope it will help. Good luck.
Please give us your feedback about these ideas.
Thomas.
[1] http://www.w3.org/TR/xpath-functions/#func-replace
[2] http://cocoon.apache.org/2.1/userdocs/transformers.html
Le 04/08/2010 19:07, Christopher Schultz a écrit :
All,
I've been using Cocoon 2.1.11 successfully for quite some time, and I'm
trying to add new capabilities to our product. I'm tripping-up when
trying to use fn:replace with a regular expression.
I'm on Debian Lenny with Debian's package-managed version of Sun JRE
1.6.0_20. I'm pretty sure I haven't messed with any of the libraries
that ship with Cocoon (such as Xalan, etc.), so it should be a pretty
stock install. I've packaged my own webapp rather than using the one
that Cocoon can build for you. I can give details of that process if
necessary.
I tried to use xsl:analyze-string which gave me a cannot use
xsl:analyze-string here error, so I tried changing my xsl:stylesheet
version=1.0 to xsl:stylesheet version=2.0 which fixed that error,
but didn't give me any output.
At any rate, my current stylesheet header looks like this (with
product-specific xmlns declarations removed for brevity:
?xml version=1.0 ?
xsl:stylesheet version=2.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fn=http://www.w3.org/2005/xpath-functions;
Specifically, my original function call attempt is this (trying to
remove a query parameter form a query string):
xsl:variable name=fixed-base-url
xsl:value-of select=$base-url /
xsl:text?/xsl:text
xsl:value-of select=fn:replace($query-string,
'(amp;)?list_start=[0-9]+', '') /
/xsl:variable
Executing this results in the following error:
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.xalan.extensions.ExtensionHandlerJavaPackage.callFunction(ExtensionHandlerJavaPackage.java:404)
at
org.apache.xalan.extensions.ExtensionHandlerJavaPackage.callFunction(ExtensionHandlerJavaPackage.java:440)
at
org.apache.xalan.extensions.ExtensionsTable.extFunction(ExtensionsTable.java:222)
at
org.apache.xalan.transformer.TransformerImpl.extFunction(TransformerImpl.java:473)
at
org.apache.xpath.functions.FuncExtFunction.execute(FuncExtFunction.java:208)
at
org.apache.xpath.Expression.executeCharsToContentHandler(Expression.java:313)
at
org.apache.xalan.templates.ElemValueOf.execute(ElemValueOf.java:274)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2400)
at
org.apache.xalan.transformer.TransformerImpl.transformToRTF(TransformerImpl.java:1988)
...
(let me know if more of the stack trace would be helpful)
I thought I might have some weird kind of data, so I tried something
simpler, just to be sure:
xsl:value-of select=fn:replace('abcabc', 'a', 'b') /
The above gives me the same error. Either commenting-out the entire
xsl:value-of element or changing the select to select='' removes the
error.
As for xsl:analyze-string, the following test resulted in no output:
xsl:analyze-string select='abcabc' regex=a
xsl:matching-substring
A
/xsl:matching-substring
xsl:non-matching-substring
xsl:value-of select=. /
/xsl:non-matching-substring
/xsl:analyze-string
... while I would have expected AbcAbc to be emitted. Perhaps I am
misusing the xsl:analyze-string element.
Can anyone offer any suggestions?
Thanks,
-chris
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
