Re: eclipse launch xsl transformation with extension functions

Hi Mukul, and thanks for the fast reply :)

Few comments inline.
Adrian.

P.S. Anyone tried to use the Xalan processor distributed with Sun's JRE?


On 09/05/2010 18:38, Mukul Gandhi wrote:
> Though this questions is more appropriate for an Eclipse forum. But
> here are some hints, which might help,
>
> Try having your extension classes in the Eclipse run-time classpath (I
> remember, there's something like a "classpath" tab in Eclipse 'run
> configuration', where you could do this).

Seems that there is something wrong with Xalan distributed with Sun's JRE.
I tried to use the ExpressionContext interface in my extension functions 
and it is not available.

>
> btw, I'm curious that, you refer a java class as, com.foo@%#$%@#^#%#$.

What I tried to emphasize is that the class name is completely ignored.
The XSL processor always tries to activate methods in the 
java.lang.String class!

> I guess, this could not be a real class name. Perhaps, this is a
> mailer feature, or you might have manually written a non-significant
> class-name string for confidentiality. These are all my guesses :)
>
> On Sun, May 9, 2010 at 6:49 PM, Adrian Herscu<[email protected]>  wrote:
>> I am trying to test an XSL extension function by launching the XSL from
>> Eclipse -- so far, with no success :(
>>
>> The configuration is as follows:
>> 1. Eclipse Galileo with the XSL feature
>> 2. Defined an XSL run configuration with the Xalan 2.7.1 processor
>>
>> I am able to launch the XSL transformation, however the reference to my
>> custom Java extension class is ignored.
>>
>> This is my XSL header:
>>
>> <xsl:stylesheet version="1.0"
>>   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>> xmlns:tl="http://foo.com//lang/1.0"
>>   xmlns:tc="http://qcore.com/pump/testing/commands/1.0"
>> xmlns:xalan="http://xml.apache.org/xalan"
>>   xmlns:utils="com.foo@%#$%@#^#%#$"
>>   extension-element-prefixes="utils">
>>
>>
>> I discovered that no matter what the contents of xmlns:util are, the XSL
>> process treats them as "java.lang"; that is, all java.lang classes are
>> available and called successfully!
>>
>> Any suggestion(s)?
>> What should I check further?
>>
>> Thanks in advance,
>> Adrian.
>
>
>