Recent changes to bugs

Log4j Configuration included in joost.jar is too aggressive

jasa — Fri, 13 May 2011 11:20:44 -0000

The log4j.properties file defines the root logger for output to the console on the warn level. This causes other application logging to be directed to the console too, which is not that desirable. I have noticed this behaviour on both JBoss and WebLogic application servers.

It would be nicer to have a version of joost that doesn't use the root logger for its logging (configuration).
I have removed the offending line from the included log4j.properties file to fix this issue, but I would feel more comfortable with an official version of the library.

Maybe it is also a good idea to use an alternate naming scheme for the property file to avoid automatic loading of the included property file in context of an application loading chain. This way you can make sure that there is no impact on other libraries or applications who include the joost library.

Much appreciated!

stx:result-document doesn't respect -nodecl

Oliver Becker — Tue, 12 Jan 2010 21:37:31 -0000

When specifying the -nodecl parameter on the command line, only the principal output doesn't have an XML declaration. It is still present in documents created with stx:result-document.

Large number of literal nodes cause stack overflow with TrAX

Doug — Wed, 21 Oct 2009 10:06:36 -0000

I came across this problem when I needed to output a large number of literal elements in a result document. When the stylesheet is executed from the Joost API (e.g. from net.sf.joost.Main) then the stylesheet works as expected. However, if the stylesheet is executed from TrAX then I get a stack overflow of the form:

java.lang.StackOverflowError
at java.util.HashMap$Entry.<init>(HashMap.java:683)
at java.util.HashMap.addEntry(HashMap.java:753)
at java.util.HashMap.put(HashMap.java:385)
at net.sf.joost.instruction.AbstractInstruction.deepCopy(Unknown Source)
at net.sf.joost.instruction.AbstractInstruction.onDeepCopy(Unknown Source)
at net.sf.joost.instruction.NodeBase.onDeepCopy(Unknown Source)
at net.sf.joost.instruction.LitElementFactory$Instance.onDeepCopy(Unknown Source)
at net.sf.joost.instruction.AbstractInstruction.deepCopy(Unknown Source)
at net.sf.joost.instruction.AbstractInstruction.onDeepCopy(Unknown Source)
at net.sf.joost.instruction.NodeBase$End.onDeepCopy(Unknown Source)
at net.sf.joost.instruction.AbstractInstruction.deepCopy(Unknown Source)
at net.sf.joost.instruction.AbstractInstruction.onDeepCopy(Unknown Source)
... etc.

The attached ZIP contains a simple Java program and STX transform which illustrate the issue. For this simple example the stack overflow will occur on 32-bit JVMs on Linux and Windows. 64-bit JVMs on Linux appear to have a higher threshold.

Doug

selecting an attribute in a pattern

Anonymous — Tue, 22 Sep 2009 08:30:29 -0000

It seems that a pattern containing an attribute does not match.
If you apply the enclosed stx file on examples/example1.xml
you will see that the first template matches but not the second.

If you comment out the first, nothing appears.

Guy Lapalme (lapalme@iro.umontreal.ca)

Errors in extension functions are not reported properly

momo — Mon, 24 Aug 2009 13:53:52 -0000

I've been so contrite after I found out an invalid ErrorHandler seems to have caused the problems described in bug [2840856] that I did not even recheck that this actually has been the problem...

Please find attached an Eclipse project showing that an exception thrown by a Java extension function is never signaled to the registered ErrorHandler. The Exception's error message is just printed to std.err.

Cheers,
momo

Errors in extension functions are ignored completely

momo — Thu, 20 Aug 2009 07:24:22 -0000

If an exception is thrown by a Java extension function Joost doesn't report an error nor doesn't emit a warning. If such function is called directly from STX, Joost simply omits the value (assumed one is trying to get a value from the function via <stx:value-of select=...) and continues processing silently. If such function is called from within embedded XSLT code, Joost silently closes all tags opened by the XSLT part and continues processing. No error is logged.

Maybe this has something to do with bug [2840583]?

Cheers,
momo

Provide full exception stacktrace from extension functions

Oliver Becker — Wed, 19 Aug 2009 20:53:11 -0000

If an exception occurs within an extension function, Joost should provide the full stacktrace for detecting the real cause of the exception.

extension functions: can't pass a value to a BigDecimal para

Oliver Becker — Wed, 19 Aug 2009 08:05:52 -0000

Consider the following STXPath code:

x:callBigInteger(y:convertToBigInt(123))

The method convertToBigInt will return a BigInteger, however Joost will convert this value to a number in between, which in turn Joost can't convert back to a BigInteger. The same behavior affects BigDecimal or any other derived Number type.

extension functions: convert "" to null for wrapper types

Oliver Becker — Wed, 19 Aug 2009 07:58:19 -0000

If a Java method parameter has a wrapper type of a primitive type (i.e. java.lang.Long, java.lang.Boolean, etc) then a passed empty string should be converted to null.
Currently the method will be called with a 0 (or false resp.)

Message Emitters on transformers do not seem to be reset

PJ Fanning — Tue, 18 Aug 2009 17:23:24 -0000

Hi,
If you reuse a Joost transformer object and try to reset the message emitter before doing so, the new emitter seems to be ignored.
I'll upload a junit test to demonstrate.