Hi there,

when running multiple BSF4Rexx programs from Java, then the very first
Rexx program will work, but any subsequent Rexx program that gets
dispatched via Java in the same process will cause a runtime error. The
reason is, that in the second run the ".local" directory does not have
the BSF4Rexx needed entries. Hence references to e.g.
".java.lang.System" will not retrieve the Java proxy object for the Java
system class (rather its string value ".JAVA.LANG.SYSTEM" gets returned
which does not understand messages like "getProperty" and the like).

It seems that the second invocation of a BSF4Rexx program via Java
(using RexxStart and hence running each Rexx program in a separate
interpreter instance) is somehow not fully isolated from the previous
Rexx interpreter instance. At least it seems that the current
implementation would not load the requited BSF.CLS and/or run its
initialization code (the code before the first directive), which among
other things sets the Rexx engine's behaviour at the Java-side (to use a
certain encoding) and saves important Java proxy objects and BSF-related
information into .local. Hence this initializatin code is vital for
setting up the environment under which BSF4Rexx programs execute.

The effect can be seen in the OpenOffice.org (OOo) support which is
realized via UNO.CLS which will initialize its environment and save
runtime information in .local, but depends on entries in .local that
stem from the required BSF.CLS which initializes the BSF4Rexx bridge and
puts needed runtime information into .local. Running Rexx macros under
OOo works the very first time, but bombs on the next invocation of a
Rexx macro. The OOo-support for ooRexx (the part implemented in Java)
will dispatch any Rexx macro using RexxStart (the executed ooRexx
macro/program must always contain the "::requires OOo.CLS", which itself
requires BSF.CLS and relies on the .local entries of BSF.CLS). In the
OOo macro environment it may be very well the case that multiple ooRexx
macros are executing concurrently/overlapping in the same process. So if
the interpreter instances are not isolated from each other, then
unpredictable/non-deterministic behaviours would occur.

The same ooRexx OOo macros work flawlessly under ooRexx 3.2.0.



P.S.: Other than this particular RexxStart runtime problem in rev. 4323,
everything seems to work fine with BSF4Rexx under ooRexx 4.0.0! This is
very remarkable and great (I ran successfully all my BSF4Rexx tests
against 4.0.0)!

Oorexx-devel mailing list

Reply via email to