Hi, will the interception mechanism by the security manager still work? I guess that is a key requirement for a rexx class loader to function. Either, there is a rexx API that a class loader can attach to, or it needs the security manager to stop rexx from resolving files normally. (This is only important for rexx files at the moment, but it could also be interesting for packed resources later)
Hope I'll get a chance to adapt the class loader to the new features at some time, but I'm pretty busy at the moment. Still, the new developments look very promising to me. Thanks for the great job! Moritz On Wed, 2 Jul 2008 14:45:36 -0400 "Rick McGuire" <[EMAIL PROTECTED]> wrote: > As part of the recent merge back into the trunk, I introduced the > concept of an "extension path" as an option to the APIs. The intent > of this option was to allow the normal file search path to be extended > by an application. For example, the THE editor could add its macro > search path to the normal lookup order right up front rather than > relying on the function call exit to extend the search order. > > Part of my thinking here was the command launchers (rexx, rexxpaws, > rexxhide, etc.) would then use the new APIs and use the value of a > REXXPATH variable to extend the normal search order. However, the > more I think about it, the more I believe that applications like THE > would probably want the REXXPATH setting to be part of the normal > search order, and the API would be yet one more level on top of that. > It's a fairly trivial matter to add this extra level with the code we > currently have in trunk. > > So, this will make the search order for files to be: > > 1) The directory of the calling file (only for external function > calls), and only if the program was loaded from disk. > 2) The current directory > 3) The extension path > 4) REXXPATH > 5) PATH > > How does this sound to people? Should 1) and 2) be reversed so that > we always look in the current directory first? I can come up with > valid arguments each way, but if you're packaging a collection of > files as an application, you will get more predictable behavior if the > co-located files are picked up before whatever happens to be in the > current directory. > > Rick -- Moritz Hoffmann <[EMAIL PROTECTED]> ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
