Hi there,
sorry, was off for a week witohut access to e-mail, hence my late answer
(keeping the quotings so only this e-mail is needed).
Stephan Bergmann wrote:
> Rony G. Flatscher wrote:
>> Hi Stephan,
>>
>>>> , in the case of the ooRexx scripting engine:
>>>>
>>>> * there is a platform dependent DLL/so which needs to be
>>>> accessible
>>>> (at the moment I copy it into "OOoHome/program"), so the library
>>>> is *not* an UNO-component, just a native library,
>>>> * there are three text files (actually ooRexx programs) named
>>>> BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be
>>>> accessible by ooRexx scripts (and for that reason I have to copy
>>>> them into "OOoHome/program".
>>> Which code accesses those files (the shared lib and the Rexx programs)
>>> how, and why does it help to move them to the program directory? (If
>>> it is clear how those files are accessed, there might be a way to
>>> access them directly within the extension.)
>> Code which is invoked via the OOo scripting framework, here's what
>> happens:
>>
>> * An ooRexx macro is invoked via Tools->Macro
>> * the Java support part for the scripting language uses BSF (Apache
>> Java archive) to load the Rexx interpreter (via the DLL/so
>> residing in OOHome/program) and supplies the script and makes the
>> arguments available to it;
>
> I still do not understand how "the DLL/so residing in OOHome/program"
> (lets call it X) is loaded. Is it supplying UNO services/singletons
> and is thus loaded via the UNO framework?
Yes, the ooRexx script provider package for OOo adheres to UNO
("ScriptProviderForooRexx.jar") which invokes bsf.jar (an Apache.org jar
which invokes the DLL/so via JNI, which then invokes the ooRexx
interpreter).
> Is it loaded from some Java code Y via System.loadLibrary? Is it
> loaded from some native code Z via dlopen?
If an ooRexx script is run by OOo, then the ooRexx script provider
package (ScriptProviderForooRexx.jar) is used to dispatch the macro
using bsf.jar which uses JNI to load the [lib]BSF4Rexx.{dll|so}which
then will load the ooRexx interpreter and supply the macro for
execution. Such ooRexx macros need access to UNO.CLS (which itself needs
access to BSF.CLS and UNO_XINTERFACES.REX) to make it really easy to
interface with OOo. Placing the DLL/so and the ooRexx files (plain
textfiles) into "$OOO_HOME/program" makes the ooRexx script provider run
successfully, i.e., these files will be found.
Therefore I have been under the impression, that OOo sets that directory
($OOO_HOME) to the PATH (and maybe LD_LIBRARY_PATH on Linux systems?)
environment variable, as otherwise these files could hardly be found.
>> * the Rexx interpreter executes the script which itself calls
>> UNO.CLS (specific UNO/OOO support, which itself uses
>> UNO_XINTERFACES.REX), which calls BSF.CLS (bridge to Java); all
>> these scripts are plain text files and are found in their location
>> (OOHome/program).
>
> *Why* are they found in the program directory?
Good question (but I am *very* happy that they are found!) !
:)
> Does the Rexx interpreter (is that the library X above?) look next to
> itself for them? (That is, if the Rexx interpreter were instead
> located in your extension, would those text files automatically be
> found in your extension, too?)
The Rexx interpreter is not placed in the script provider package, but
accessible globally (on Windows it is installed for all users, on Linux
it is installed in /opt and the executable is linked to /usr/bin the
librexx.so to /usr/lib). So the interpreter lives independently of OOo,
but every process can access it given the above environment setup.
HTH,
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
