bug Xalan 1.2

[Loïc Trégan <lt...@hotmail.com>]

Hello,


XSLTJavaClassEngine.java line 417 : only reflection exceptions (I don't know
how it can be decided) should be caught .  Currently, if there is an
exception thrown by the user extension, a next try is done but irrelvant.

thanks for your attention.

loic

PS : please CC me personally any potential answer, I've not susbribed to the
mailing list (maybe newsgroup or real time update of history for XMas ? ;) )

Re: bug Xalan 1.2

[Gary L Peskin <ga...@firstech.com>]

Loïc Trégan wrote:
> what means "invocation  fails" ? do you mean the method is called but an
> excpetion occurs in it, or do you mean that java.lang.reflect.invok() can't
> call the underlying function ?

Actually it means any failure.  The most likely failure in this section
of code is that the underlying function can be called but that it throws
an Exception.

> 
> >Thus, for example, if your extension function has
> >several methods with the same name but different types of arguments
> 
> How is it possible ? I thought all element functions should be :
> XXX elem( XSLProcessorContext context,    ElemExtensionCall extElem)
> 
> In this case, it is always the same method which should be called and there
> is no problem of wrong cache ?
> 

This signature is for extension elements but not for extension
functions.  The extension function can really have just about any
signature.  The distinction between extension elements and extension
functions was very confusing to me at first, too.  If an extension
function is called with a variable, that variable can have a string
value on one execution and a boolean value, for example, on the next
execution.  This could result in the need to call different functions.

> >At run time, this means that the cache may
> >not hold the correct extension Method object.
> maybe (depending of your answer to previous question). But you rely on an
> exception thrown by the user extension to test the validity of the cache.
> What if the wrong function is called but in such context that the user
> extension does not thrown an exception ? 

This is definitely a risk with the current implementation.  In that
case, you'd get incorrect output but no indication of an error. 
However, this hasn't been reported as a problem in the real life so
we're trying to sneak by with our current implementation for now.

> And if, at the opposite of what I
> have understood, you do not rely on a exception thrown by the user ext, why
> not test direclty the reflection exception (maybe there is a NoSuchMethod,
> or WrongParameter, exception that you can test to be sure the problem comes
> from the cache and not the user ext)?

We're not talking about reflection exceptions but exceptions from the
underlying method, as I said above.

> 
> Well if you are sure it works don't worry with my questions, I trust you !

This is probably not a good approach.  You should always question and
never assume that the author or maintainer knew what he was doing, at
least when I am the author or maintainer.  The whole point of open
source is that subjecting code to numerous eyeballs will result in more
reliable and understandable code.

Thanks for your questions,
Gary

Re: bug Xalan 1.2

[Loïc Trégan <lt...@hotmail.com>]

>If that method invocation fails, we look up the method
>again and, if a more appropriate method is found this time around,
what means "invocation  fails" ? do you mean the method is called but an
excpetion occurs in it, or do you mean that java.lang.reflect.invok() can't
call the underlying function ?


>Thus, for example, if your extension function has
>several methods with the same name but different types of arguments

How is it possible ? I thought all element functions should be :
XXX elem( XSLProcessorContext context,    ElemExtensionCall extElem)

In this case, it is always the same method which should be called and there
is no problem of wrong cache ?


>At run time, this means that the cache may
>not hold the correct extension Method object.
maybe (depending of your answer to previous question). But you rely on an
exception thrown by the user extension to test the validity of the cache.
What if the wrong function is called but in such context that the user
extension does not thrown an exception ? And if, at the opposite of what I
have understood, you do not rely on a exception thrown by the user ext, why
not test direclty the reflection exception (maybe there is a NoSuchMethod,
or WrongParameter, exception that you can test to be sure the problem comes
from the cache and not the user ext)?

Well if you are sure it works don't worry with my questions, I trust you !


loic

----- Message d'origine -----
De : Gary L Peskin <ga...@firstech.com>
À : <xa...@xml.apache.org>
Cc : <lt...@hotmail.com>
Envoyé : mardi 19 décembre 2000 17:50
Objet : Re: bug Xalan 1.2


Loïc Trégan wrote:
>
> Hello,
>
> XSLTJavaClassEngine.java line 417 : only reflection exceptions (I don't
know
> how it can be decided) should be caught .  Currently, if there is an
> exception thrown by the user extension, a next try is done but irrelvant.

Loic --

The next try can be relevant in some situations.  Currently, extension
function Method objects are cached in a Hashtable according to a
simplistic key.  Thus, for example, if your extension function has
several methods with the same name but different types of arguments, the
function is cached only once according to the name of the function and
position in the stylesheet.  At run time, this means that the cache may
not hold the correct extension Method object.

Usually, people don't do this.  They have only one method with the same
name and the extension code itself deals with the different types of
objects, if that is possible.  So this scheme works most of the time.
However, this part code also handles situations where the wrong method
is in the cache.  If that method invocation fails, we look up the method
again and, if a more appropriate method is found this time around, we
invoke it and replace the contents of the cache.

Gary

Re: bug Xalan 1.2

[Gary L Peskin <ga...@firstech.com>]

Loïc Trégan wrote:
> 
> Hello,
> 
> XSLTJavaClassEngine.java line 417 : only reflection exceptions (I don't know
> how it can be decided) should be caught .  Currently, if there is an
> exception thrown by the user extension, a next try is done but irrelvant.

Loic --

The next try can be relevant in some situations.  Currently, extension
function Method objects are cached in a Hashtable according to a
simplistic key.  Thus, for example, if your extension function has
several methods with the same name but different types of arguments, the
function is cached only once according to the name of the function and
position in the stylesheet.  At run time, this means that the cache may
not hold the correct extension Method object.

Usually, people don't do this.  They have only one method with the same
name and the extension code itself deals with the different types of
objects, if that is possible.  So this scheme works most of the time. 
However, this part code also handles situations where the wrong method
is in the cache.  If that method invocation fails, we look up the method
again and, if a more appropriate method is found this time around, we
invoke it and replace the contents of the cache.

Gary