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. Regards, ---rony 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
