RE: Xalan's usage of BSF language engines, please help clarify ...

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

Rony -

Did you ever get an answer to this.  I have some time to look into it at
the moment.

Gary

> -----Original Message-----
> From: Rony G. Flatscher [mailto:Rony.Flatscher@wu-wien.ac.at] 
> Sent: Tuesday, September 17, 2002 4:27 AM
> To: scott_boag@us.ibm.com; Shane_Curcuru@us.ibm.com; 
> Paul_Dick@us.ibm.com; keshlam@us.ibm.com; 
> donald_leslie@us.ibm.com; David_Marston@us.ibm.com; 
> myriam_midy@us.ibm.com; cmanolache@yahoo.com; 
> garyp@firstech.com; mkwan@ca.ibm.com; ilene@ca.ibm.com; 
> zongaro@ca.ibm.com
> Subject: Xalan's usage of BSF language engines, please help 
> clarify ...
> 
> 
> Hi there,
> 
> in the context of experimenting with XSL-extensions, 
> implementing them with a non-Java-language, i.e. a 
> self-developed RexxEngine (supporting IBM's Object Rexx on 
> Linux, OS/2, Windows, and the opensource Rexx interpreter 
> "Regina" on Linux and Windows), I had a student experiment 
> with extensions.
> 
> The problem: what works with JavaScript does not work with 
> Rexx (the JavaScript extension example is enclosed, the 
> JavaScript part should get replaced with a Rexx program as a 
> proof of concept). The RexxEngine extends BSFEngineImpl, is 
> loaded and call() is invoked. Unfortunately, the method 
> call() does not receive the source-code (i.e. the Rexx code) 
> but only the name of the function and the arguments.
> 
> The question:  how would one be able to get a hold of the 
> source code at runtime? (Where is the program source of the 
> script located?)
> 
> Any hint would be highly appreciated!
> 
> ---
> 
> [With eval(), exec() and apply() all the arguments are more 
> clearly defined compared to call(). Actually, I would have 
> expected that apply() would be invoked instead of call(). 
> call() is obviously meant for invoking a given method on a 
> known object in the target scripting environment, hence my 
> surprise that call() is used within the Xalan extension 
> mechanism and not apply().]
> 
> Also, please do not be offended, if I address all of you, who 
> are known to be Xalan-implementors. It's just a sign of the 
> high level of despair (due to strong time-restrictions and 
> work-overload) and the hope that maybe one of you may be able 
> to anwer this quickly and without too much effort.
> 
> (The student, a non-Informatic student,  has been trying for 
> three months to solve the problem, I started two weeks ago to 
> look into it and started out studying the e-mail archives of 
> cocoon and posted questions there to no avail, now 
> concentrating on Xalan, but have not found any information on 
> this. The BSF-discussion list was not used yet, because its 
> posting intensity is very low and I would not expect any help 
> from there.)
> 
> Thank you very much for *any* hint/help in advance !
> 
> Regards,
> 
> Rony G. Flatscher
> 
> 

RE: Xalan's usage of BSF language engines, please help clarify ...

[Joseph Kesselman <ke...@us.ibm.com>]

Looked at this question in a bit more detail...

Xalan's handling of all "inline scripts" invoked via BSF should be 
identical -- extract the script body as a string, and pass it, the name of 
the script language binding to be applied, and the arguments to BSF; then 
take the value returned by BSF and massage it into a form that Xalan can 
do something useful with.

The code which does this is in the 
org.apache.xalan.extensions.ExtensionHandlerGeneral class.


In specific: The constructor for this class  issues a BSF exec call to the 
engine to "compile" the script. This is when the text of the extension 
script is considered; it's the  m_scriptSrc parameter. The resulting 
compiled script is stored into m_engine. The callFunction() method then 
issues a BSF "call" to actually execute the compiled script.

Note that this means there is no promise that the script can access its 
own source. In some scripting languages that may be possible. In others it 
won't be. If you need to do so, that's something to discuss with the BSF 
folks.

______________________________________
Joe Kesselman  / IBM Research