Thanks. Well, the variable definition clearly isn't circular, so we have to look for a deeper cause. I suspect some kind of multi-threading issue. Saxon holds a flag that indicates the variable is being evaluated, and the error means that an attempt is being made to evaluate the variable when this flag is already set. The flag is contained in the JAXP Transformer object, so a possible explanation is that the Transformer is being used in more than one thread (which isn't allowed). I notice that net.sf.saxon.Controller (which is Saxon's implementation of the JAXP Transformer) is mentioned in the ClassLoader message, so this might be a hint that things are amiss in this area.
 
Note that because the variable calls the doc() function to load and parse a source document, evaluation of the variable might take some time, so it's quite likely that if there is a threading conflict here, this is where it would be detected. 
 
Does this ring any bells?
 
Michael Kay
http://www.saxonica.com/


From: Anton Mints [mailto:developer.geo@yahoo.com]
Sent: 19 July 2006 21:50
To: 'Michael Kay'; 'Mailing list for SAXON XSLT queries'
Cc: 'Ernst Nolte'; 'Dmitry Krambalev'
Subject: RE: [saxon] Saxon 8.7 Transformer problem - JBOSS - XSLT2.0

I will post a stack trace, the test message and xslt. I have also made an extraction from our jar file – the problematic xslt file is stylesheets/2fix.xslt:

 

>> here we are printing the information about the class loader. So it’s really saxon…

2006-07-18 18:37:25,875 INFO  [STDOUT] 18:37:25.874 SEVERE  [com.marketxs.tradenet.fix.FIXMLMessageSerializer] net.sf.saxon.Controller : org.jboss.mx.loading.UnifiedClassLoader3@1ec265c{ url=file:/usr/local/jboss-4.0.1sp1/server/tradenexus//deploy-hasingleton ,addedOrder=42}

 

>> this is an error indeed (sometimes it complains about msgs variable)

2006-07-18 18:37:25,888 INFO  [STDOUT] Error at xsl:variable  XTDE0640: Circular definition of variable qf

2006-07-18 18:37:25,889 ERROR [com.marketxs.tradenet.actis.ActisConnectorBean] Serialization failed for message (ID:ffffffffb3b8213a:128153002b:10C827FBFC2)

com.marketxs.tradenet.fix.SerializeException: Unable to transform the input with ExecRpt

        at com.marketxs.tradenet.fix.FIXMLMessageSerializer.toMessage(FIXMLMessageSerializer.java:329)

        at com.marketxs.tradenet.fix.FIXMLMessageSerializer.toMessage(FIXMLMessageSerializer.java:238)

        at com.marketxs.tradenet.actis.ActisConnectorBean.FixML2Fix(ActisConnectorBean.java:206)

        at com.marketxs.tradenet.actis.ActisConnectorBean.onMessage(ActisConnectorBean.java:106)

        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:585)

        at org.jboss.invocation.Invocation.performCall(Invocation.java:345)

        at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:475)

        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)

        at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:87)

        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)

        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)

        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:313)

        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:146)

        at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:94)

        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)

        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)

        at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:389)

        at org.jboss.ejb.Container.invoke(Container.java:870)

        at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:967)

        at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1253)

        at com.sonicsw.pso.jboss.v1.SonicMQServerSession.onMessage(Unknown Source)

        at progress.message.jimpl.Session.eU_(Unknown Source)

        at progress.message.jimpl.Session.run(Unknown Source)

        at com.sonicsw.pso.jboss.v1.SonicMQServerSession.run(Unknown Source)

        at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)

        at java.lang.Thread.run(Thread.java:595)

Caused by: net.sf.saxon.trans.DynamicError: Circular definition of variable qf

        at net.sf.saxon.instruct.GlobalVariable.evaluateVariable(GlobalVariable.java:200)

        at net.sf.saxon.expr.VariableReference.evaluateVariable(VariableReference.java:244)

        at net.sf.saxon.expr.VariableReference.iterate(VariableReference.java:217)

        at net.sf.saxon.expr.PathExpression.iterate(PathExpression.java:742)

        at net.sf.saxon.expr.PathExpression.iterate(PathExpression.java:742)

        at net.sf.saxon.expr.PathExpression.iterate(PathExpression.java:742)

        at net.sf.saxon.expr.PathExpression.iterate(PathExpression.java:742)

        at net.sf.saxon.instruct.SimpleContentConstructor.evaluateItem(SimpleContentConstructor.java:186)

        at net.sf.saxon.instruct.ValueOf.evaluateItem(ValueOf.java:173)

        at net.sf.saxon.instruct.SimpleNodeConstructor.iterate(SimpleNodeConstructor.java:164)

        at net.sf.saxon.expr.LetExpression.iterate(LetExpression.java:154)

        at net.sf.saxon.expr.Atomizer.iterate(Atomizer.java:99)

        at net.sf.saxon.expr.UntypedAtomicConverter.iterate(UntypedAtomicConverter.java:89)

        at net.sf.saxon.expr.CardinalityChecker.iterate(CardinalityChecker.java:137)

        at net.sf.saxon.expr.ExpressionTool.eagerEvaluate(ExpressionTool.java:279)

        at net.sf.saxon.expr.ExpressionTool.lazyEvaluate(ExpressionTool.java:245)

        at net.sf.saxon.instruct.UserFunction.call(UserFunction.java:163)

        at net.sf.saxon.expr.UserFunctionCall.callFunction(UserFunctionCall.java:255)

        at net.sf.saxon.expr.UserFunctionCall.evaluateItem(UserFunctionCall.java:192)

        at net.sf.saxon.instruct.SimpleContentConstructor.evaluateItem(SimpleContentConstructor.java:177)

        at net.sf.saxon.instruct.ValueOf.processLeavingTail(ValueOf.java:163)

        at net.sf.saxon.instruct.Block.processLeavingTail(Block.java:332)

        at net.sf.saxon.instruct.Template.expand(Template.java:98)

        at net.sf.saxon.instruct.Template.processLeavingTail(Template.java:82)

        at net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:297)

        at net.sf.saxon.instruct.ApplyTemplates.defaultAction(ApplyTemplates.java:329)

        at net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:291)

        at net.sf.saxon.Controller.transformDocument(Controller.java:1513)

        at net.sf.saxon.Controller.transform(Controller.java:1346)

        at com.marketxs.tradenet.fix.FIXMLMessageSerializer.toMessage(FIXMLMessageSerializer.java:292)

        ... 28 more

 

>> One of the test messages…

 

<Message xmlns:fn="http://www.w3.org/2005/02/xpath-functions"

         xmlns:xs="http://www.w3.org/2001/XMLSchema"

         xmlns:fixutil="http://www.marketxs.com/fixutil"

         xmlns:xdt="http://www.w3.org/2005/02/xpath-datatypes"

         xmlns:fix="http://www.fixprotocol.org/FIXML-4-4"

         name="ExecRpt">

   <Field Tag="37" Name="OrdID">

      <Value>1153240639828</Value>

   </Field>

   <Field Tag="11" Name="ID">

      <Value>tnx/test5_39</Value>

   </Field>

   <Field Tag="17" Name="ExecID">

      <Value>1153240639829</Value>

   </Field>

   <Field Tag="150" Name="ExecTyp">

      <Value>0</Value>

   </Field>

   <Field Tag="39" Name="Stat">

      <Value>0</Value>

   </Field>

   <Field Tag="1" Name="Acct">

      <Value>223630160TC3</Value>

   </Field>

   <Field Tag="54" Name="Side">

      <Value>1</Value>

   </Field>

   <Field Tag="40" Name="Typ">

      <Value>2</Value>

   </Field>

   <Field Tag="44" Name="Px">

      <Value>8.06</Value>

   </Field>

   <Field Tag="151" Name="LeavesQty">

      <Value>200</Value>

   </Field>

   <Field Tag="14" Name="CumQty">

      <Value>0</Value>

   </Field>

   <Field Tag="6" Name="AvgPx">

      <Value>0</Value>

   </Field>

   <Field Tag="60" Name="TxnTm">

      <Value>20060718-16:37:19</Value>

   </Field>

   <Field Tag="58" Name="Txt">

      <Value>This order has been accepted by an exchange simulator. When placing a new order: 1. If the quantity ends with a "0" (multiple of 10), it sends a

 complete fill. 2. If the quantity ends with a [1-8], the order is filled in [1-8] parts. 3. When maxFloor is specified (showQty in MXSPro), the above is ove

rridden and the order will be filled in chunks of maxFloor size each. This gives more control over the number of partial fills 4. If the quantity ends with a

 "9", the order is rejected.</Value>

   </Field>

   <Block name="fix:Hdr">

      <Field Tag="49" Name="SID">

         <Value>tradenet</Value>

      </Field>

      <Field Tag="56" Name="TID">

         <Value>tnx</Value>

      </Field>

      <Field Tag="50" Name="SSub">

         <Value>simulator</Value>

      </Field>

      <Field Tag="57" Name="TSub">

         <Value>test5</Value>

      </Field>

      <Field Tag="52" Name="Snt">

         <Value>20060718-16:37:19</Value>

      </Field>

   </Block>

   <Block name="fix:Instrmt">

      <Field Tag="55" Name="Sym">

         <Value>GTN</Value>

      </Field>

      <Field Tag="48" Name="ID">

         <Value>NL0000355915@XAMS/EUR</Value>

      </Field>

      <Field Tag="22" Name="Src">

         <Value>100</Value>

      </Field>

   </Block>

   <Block name="fix:OrdQty">

      <Field Tag="38" Name="Qty">

         <Value>200</Value>

      </Field>

   </Block>

   <Block name="fix:Comm"/>

</Message>

 

 


From: Michael Kay [mailto:mike@saxonica.com]
Sent: Wednesday, July 19, 2006 7:22 PM
To: 'Anton Mints'; 'Mailing list for SAXON XSLT queries'
Cc: 'Ernst Nolte'; 'Dmitry Krambalev'
Subject: RE: [saxon] Saxon 8.7 Transformer problem - JBOSS - XSLT2.0

 

I think that when you used

 

TransformerFactory factory = new net.sf.saxon.TransformerFactoryImpl();

 

it did solve your initial problem, which was that you weren't loading Saxon. It then exposed another problem, the circular reference error. We now need to tackle this second problem. The fact that it didn't happen when running from the standalone application might suggest that different stylesheet modules are being loaded in the two cases, for example because the base URI is different. Could you please provide details that help us to understand the circular reference error? - specifically, the actual error message and the stylesheet modules referred to in the message?

 

Michael Kay

http://www.saxonica.com/

 

 

 


From: Anton Mints [mailto:developer.geo@yahoo.com]
Sent: 19 July 2006 18:07
To: 'Michael Kay'; 'Mailing list for SAXON XSLT queries'
Cc: 'Ernst Nolte'; 'Dmitry Krambalev'
Subject: RE: [saxon] Saxon 8.7 Transformer problem - JBOSS - XSLT2.0

We are already instantiating it exactly like this, however it didn’t solve the problem. It only brought circular reference error into picture. There is no problem with the stylesheet either, because it was tested on the stand alone application with exactly same package for the same test message.

 

Anton

 


From: Michael Kay [mailto:mike@saxonica.com]
Sent: Wednesday, July 19, 2006 5:23 PM
To: 'Mailing list for SAXON XSLT queries'
Cc: 'Anton Mints'
Subject: RE: [saxon] Saxon 8.7 Transformer problem - JBOSS - XSLT2.0

 

The simplest way to ensure that you load Saxon and not Xalan is to instantiate it directly: instead of using

 

TransformerFactory factory = TransformerFactory.newInstance();

 

use

 

TransformerFactory factory = new net.sf.saxon.TransformerFactoryImpl();

 

It means your code is committed to Saxon, but that seems to be what you want here.

 

(I think you mean Xalan when you say Xerces. Xerces is an XML parser, Xalan an XSLT transformer. It's quite normal to use Xerces as the XML parser with Saxon as the XSLT transformer).

 

If you still have problems with circular variable references, that suggests a problem in your stylesheet.

 

Michael Kay

http://www.saxonica.com/

 


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Anton Mints
Sent: 18 July 2006 21:45
To: Saxon-help@lists.sourceforge.net
Subject: [saxon] Saxon 8.7 Transformer problem - JBOSS - XSLT2.0

Hi All,

 

We are making ear component that shall run in JBOSS. In this component we are reading messages from the Sonic queue and writing them to the database. In between there is an XSLT transformation.

 

We are using XSLT 2.0 style sheet in combination with Saxon 8.7B.

 

It was failing immediately, because it was trying to use XERCES transformer by default.

 

1. First of all we have thoughts that it failing because it’s using xerces parser installed on the apache at the initial stage. So we have placed saxon8..jar files to the CLASSPATH (they are obviously deployed locally in the ear package). It didn’t help.

 

2. Then, we have added the saxon namespace in front of all parsers and transformer classes. It did help, but now it failing with the ‘Circular variable definition …’ exception.

 

It’s obviously working as stand alone application with java 1.5. It’s also working on the test JBOSS server with no XERCES installed. Also there is no problem with the XSLT.

 

It probably a class loading problem, but we could not figure out, what is the problem, because the Saxons are the first one to be loaded.

 

So we might assume, that even we are really calling saxon transformer (and we can see, that it’s loaded with the saxon loader) it still somehow internally using the xerces that is only 1.0 comparable.

 

Can somebody advice, what shall we do to force saxon transformer and parser use only 2.0 own implementation.

 

Much appreciated for any help.

 

Anton Mints