Content-Type: multipart/alternative; boundary="_000_D61618F59D72744F88EC2A89FE644FD808140EMAIL2abc_" --_000_D61618F59D72744F88EC2A89FE644FD808140EMAIL2abc_ Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable Hello, It=92s seems that with this property all works. I have one another answer: Is it possible to compile only XSLT 3.0 version if I set compiler.XsltLangu= ageVersion=3D3.0 If I set compiler.XsltLanguageVersion=3D2.0 for 3.0 to be an error. Or I have to do this checking xslt atribute, that of course works=85 Ar cie=F2u, Aleksandrs Ze=EFikovi=E8s [Description: http://www.abcsoftware.lv/logo/logo_z2.jpg] SIA =84ABC software=94 Programm=E7t=E2js T=E2lr.: +371-67082622 Fakss: +371-67082610 E-pasts: Aleksandrs.Zelikovics@abcsoftware.lv From: Dr O'Neil Delpratt [mailto:oneil@saxonica.com] Sent: Wednesday, March 21, 2012 7:44 PM To: Mailing list for the SAXON XSLT and XQuery processor Cc: Michael Kay; Aleksandrs Ze=EFikovi=E8s Subject: Re: [saxon] .net and xslt compiler Hi Aleksandrs, We have managed to fix the bug you reported, which will be available in the= next maintenance release of Saxon 9.4. We generate byte code (from XQuery or XSLT source) using ASM and load/execu= te it. The problem proved to be a class loader issue within the CompilerSer= vice class, which as Mike suggested is associated with the byte code genera= tion. We have therefore simplified the use of the class loader when generat= ing byte code, which did seem to get 'mixed-up' across .NET through the IKV= M. kind regards, O'Neil On 20/03/2012 10:15, Michael Kay wrote: OK, thanks, we have reproduced the failure. This is associated with byte code generation, so you can work around the pr= oblem by adding the API call processor.SetProperty("http://saxon.sf.net/feature/generateByteCode", "false"); The reason the 3.0 streamable example works is that byte code generation is= automatically switched off for streamable templates. What's happening here, as far as we can tell, is that we are generating byt= e code corresponding to your XSLT stylesheet; we are then translating the b= yte code to IL code using IKVMC. The byte code that we generate is a class = which inherits from the class com.saxonica.bytecode.map.CompiledContextMapp= ingFunction, which is present in saxon9ee.dll. When we run from within the = command line Transform command, which is in the same DLL, this is successfu= lly loaded, but when we run from a different DLL, a failure occurs when att= empting dynamic loading of the superclass. One of the puzzles is how something so simple is failing when all our tests= worked OK - but I suspect that observation won't help us in finding the ca= use and fixing it. As we've reproduced the problem, we should be able to find a fix. My collea= gue O'Neil Delpratt will be working on this. Regards, Michael Kay Saxonica On 19/03/2012 08:24, Aleksandrs Ze=EFikovi=E8s wrote: Thank you for your answer, Before buying saxonica application for our product we test it with simplest= XSLT. We will have catalog with xslt (not only 3.0). Interesting that under Console application all XSLT can be run. Testing your product, this XSLT can=92t be run Under windows project: 1.0 Exception in Compile: com.saxonica.bytecode.map.CompiledContextMapping= Function ---------------------------------------------------------------------------= --- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ saxon-help mailing list archived at http://saxon.markmail.org/ saxon-help@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/saxon-help No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1913 / Virus Database: 2114/4881 - Release Date: 03/19/12 --_000_D61618F59D72744F88EC2A89FE644FD808140EMAIL2abc_ Content-Type: text/html; charset="windows-1257" Content-Transfer-Encoding: quoted-printable

Hello,

 

It=92s seems that with this= property all works.

 

I have one another answer:

Is it possible to compile o= nly XSLT 3.0 version if I set compiler.XsltLanguageVersion=3D3.0=

If I set compiler.XsltLangu= ageVersion=3D2.0 for 3.0 to be an error.

 

Or I have to do this checki= ng xslt atribute, that of course works=85

 

Ar cie=F2u,
Aleksandrs Ze=EFikovi=E8s

 

SIA= =84ABC software=94
Programm=E7t=E2js
T=E2lr.: +371-67082622 Fakss: +371-67082610=
E-pasts: Aleksandrs.Zeli= kovics@abcsoftware.lv

 

From: Dr O'Neil Delpratt [mailto:oneil@saxonica.com]
Sent: Wednesday, March 21, 2012 7:44 PM
To: Mailing list for the SAXON XSLT and XQuery processor
Cc: Michael Kay; Aleksandrs Ze=EFikovi=E8s
Subject: Re: [saxon] .net and xslt compiler

 

Hi Aleksandrs,

We have managed to fix the bug you reported, which will be available in the= next maintenance release of Saxon 9.4.

We generate byte code (from XQuery or XSLT source) using ASM and load/execu= te it. The problem proved to be a class loader issue within the CompilerSer= vice class, which as Mike suggested is associated with the byte code genera= tion. We have therefore simplified the use of the class loader when generating byte code, which did seem to g= et 'mixed-up' across .NET through the IKVM.

kind regards,

O'Neil

On 20/03/2012 10:15, Michael Kay wrote:

OK, thanks, we have reproduced the failure.

This is associated with byte code generation, so you can work around the pr= oblem by adding the API call

processor.SetProperty("http://saxon.sf.net/feature/generateByteCode", "fal= se");

The reason the 3.0 streamable example works is that byte code generation is= automatically switched off for streamable templates.

What's happening here, as far as we can tell, is that we are generating byt= e code corresponding to your XSLT stylesheet; we are then translating the b= yte code to IL code using IKVMC. The byte code that we generate is a class = which inherits from the class com.saxonica.bytecode.map.CompiledContextMapp= ingFunction, which is present in saxon9ee.dll. When we run from within the command line= Transform command, which is in the same DLL, this is successfully loaded, = but when we run from a different DLL, a failure occurs when attempting dyna= mic loading of the superclass.

One of the puzzles is how something so simple is failing when all our tests= worked OK - but I suspect that observation won't help us in finding the ca= use and fixing it.

As we've reproduced the problem, we should be able to find a fix. My collea= gue O'Neil Delpratt will be working on this.

Regards,

Michael Kay
Saxonica

On 19/03/2012 08:24, Aleksandrs Ze=EFikovi=E8s wrote:

Thank you for your answer,

 

Before buying saxonica applicat= ion for our product we test it with simplest XSLT.

We will have catalog with xslt = (not only 3.0).

 

Interesting that under Console = application all XSLT can be run.

 

Testing your product, this XSLT= can=92t be run Under windows project:

 

1.0 Exception in Compile:  = ;com.saxonica.bytecode.map.C= ompiledContextMappingFunction

<xsl:stylesheet version=3D= "1.0" xmlns:xsl=3Dhttp://www.w3.org/1999/XSL/Transform"<= /span> xmlns:xs=3D"htt= p://www.w3.org/2001/XMLSchema" exclude-result-prefixes=3D"xs"= ;>

 &nb= sp;     <xsl:output method=3D&= quot;xml" encoding=3D"UTF-8" indent=3D&= quot;yes"/>

 &nb= sp;     <xsl:template<= span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;mso-fareast-l= anguage:LV"> match=3D&q= uot;/">

 &nb= sp;            <<= /span>c>

 &nb= sp;            =        <xsl:for-eac= h select=3D&= quot;a/b">

 &nb= sp;            =              &l= t;c1>

 &nb= sp;            =             &nb= sp;       <xsl:valu= e-of select=3D&= quot;string(.)"/>

 &nb= sp;            =              &l= t;/c1>

 &nb= sp;            =        </xsl:for-ea= ch>

 &nb= sp;            </= c>

 &nb= sp;     </xsl:template= >

</xsl:stylesheet>=

 

 <= /o:p>




----------------------------------------------------------------------=
--------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2=
d-msazure




_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.s=
ourceforge.net
ht=
tps://lists.sourceforge.net/lists/listinfo/saxon-help 




No virus found in this mes= sage.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2114/4881 - Release Date: 03/19/12

 <= /o:p>

--_000_D61618F59D72744F88EC2A89FE644FD808140EMAIL2abc_--