Re: Ad Apple''s setup for the (Java) scripting framework

[Rony G. Flatscher (Apache)]

While also testing on LO (and getting the ooRexx macro support there up and 
running again with the
help of - kudos! - Stephan Bergmann) the problem should be restated (issues
, 
):

  * if launching AOO from a Terminal (the command
"/Application/OpenOffice.org/Contents/MacOS/soffice") the environment got 
already set by the
login script, such that soffice works in that environment and therefore has 
access to all
programs in the directory "/usr/local/bin" (which has become of paramount 
inmportance on MacOSX
because Apple since a few releases forces third parties to install their 
binaries and commands 
there),

  * when launching AOO (and LO for that matter) from the Finder ("Application") 
no user login
scripts get executed and the environment therefore is - unfortunately - not 
set up the same as
in a Terminal! This is the reason why the environment variable PATH is not 
set correctly (the
Apple launch service does not honor "/etc/paths", it seems, but rather has 
the PATH hardcoded)
and other environment variables may not be defined for the application that 
gets launched by it).

On MacOS there is a file named "/etc/paths" which lists the system paths 
line by line and
includes the directory "/usr/local/bin", however the Finder launched 
application (AOO, LO) does
not include that mandatory directory in the PATH environment variable! 
Although there is a key
LSEnvironment which would allow to set the environment and therefore would 
allow to define PATH
to contain also the directory "/usr/local/bin" (e.g. by honoring 
"/etc/paths" on MacOS), I have
not been able to define it in the Info.plist that it gets honored for 
swriter, scalc, etc.!

(In my case, allowing the scripting language ooRexx to be used and deployed 
as an AOO/LO macro,
I could eventually solve the problem with a - stable, nevertheless - MacOS 
hack by analyzing
PATH prior to invoke the Rexx interpreter and if "/usr/local/bin" is 
missing it gets prepended
to the environment, which is possible via the JNI bridge to BSF4ooRexx. To 
make a long story
short: this allows ooRexx to search "/usr/local/bin" for ooRexx packages 
like BSF.CLS, UNO.CLS
and the like. It would be *much* better, of course, if AOO would be able to 
add the
"/usr/local/bin" directory to the PATH environment variable if it is 
missing from there, as then
other third party programs on MacOS could be invoked, used via AOO/LO 
components and/or macros.)

The issue with Java programs on MacOS that interact with the GUI that all of a 
sudden cause crashes
on MacOS () is still present 
on AOO (LO does not
have that problem).

What may be interesting to locate the cause is the information, that AOO/LO 
macros including ooRexx
get dispatched via Java and they work. (MacOS seems to have a quite "special" 
setup for processing
GUI events compared to other platforms, causing this crash.)

Will add these remarks/findings to the respective issues.

---rony


On 31.12.2018 14:25, Rony G. Flatscher wrote:
> On 26.12.2018 15:37, Jim Jagielski wrote:
>> I am looking into the 1st 2 and cannot find, at present, where these vars 
>> are being set... will continue to look.
>>
>>> On Dec 20, 2018, at 10:17 AM, Rony G. Flatscher  
>>> wrote:
>>>
>>> Peter,
>>>
>>> as these are different problems to issue 117961 I opened three separate new 
>>> issues for them to allow
>>> to evaluate and trace them individually:
>>>
>>>  * MacOS: PATH wrongly set for scripts: 
>>> 
>>>  * MacOS: Current directory wrongly set to root directory "/" for scripts:
>>>
>>>  * MacOS: Running via Java causes exception on MacOSX Mojave:
>>>
>>>
>>> Once the critical PATH issue (127965 above) gets resolved, I will become 
>>> able to test issue 117961
>>> again and in case it still is a problem then, I would re-open it.
>>>
>>> ---rony
> ... cut ...
>
> On further testing both, PATH (issue 127965) and current home directory 
> (issue 127966), may have the
> same cause.
>
> When starting AOO from the Apple terminal (command line), the environment is 
> untouched and therefore
> everything can work.
>
> However, if starting the AOO instance from the Apple menu (Application folder 
> and clicking on
> OpenOffice.org to start it), then the environment gets crippled 
> unfortunately, causing
> incomplete/wrong/wiped out environment values.
>
> So speculating that the installation setups scripts that cripple the 
> environment AOO gets started in.
>
> Will update the above two issues to point to each other and supply a 
> Beanshell macro that reads the
> environment settings and writes them into its swriter document. Supplying 

Re: Ad Apple''s setup for the (Java) scripting framework

[Rony G. Flatscher]

On 26.12.2018 15:37, Jim Jagielski wrote:
> I am looking into the 1st 2 and cannot find, at present, where these vars are 
> being set... will continue to look.
>
>> On Dec 20, 2018, at 10:17 AM, Rony G. Flatscher  
>> wrote:
>>
>> Peter,
>>
>> as these are different problems to issue 117961 I opened three separate new 
>> issues for them to allow
>> to evaluate and trace them individually:
>>
>>  * MacOS: PATH wrongly set for scripts: 
>> 
>>  * MacOS: Current directory wrongly set to root directory "/" for scripts:
>>
>>  * MacOS: Running via Java causes exception on MacOSX Mojave:
>>
>>
>> Once the critical PATH issue (127965 above) gets resolved, I will become 
>> able to test issue 117961
>> again and in case it still is a problem then, I would re-open it.
>>
>> ---rony

... cut ...

On further testing both, PATH (issue 127965) and current home directory (issue 
127966), may have the
same cause.

When starting AOO from the Apple terminal (command line), the environment is 
untouched and therefore
everything can work.

However, if starting the AOO instance from the Apple menu (Application folder 
and clicking on
OpenOffice.org to start it), then the environment gets crippled unfortunately, 
causing
incomplete/wrong/wiped out environment values.

So speculating that the installation setups scripts that cripple the 
environment AOO gets started in.

Will update the above two issues to point to each other and supply a Beanshell 
macro that reads the
environment settings and writes them into its swriter document. Supplying also 
the two AOO swriter
documents, one being off the "command line AOO", one being off the "menu AOO".

---rony

P.S.: On Windows (this is still with AOO 4.1.5) the environment remains intact 
when starting AOO
from the Windows menu. This should be also the case for the Unix based AOO 
installations.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Ad Apple''s setup for the (Java) scripting framework

[Jim Jagielski]

I am looking into the 1st 2 and cannot find, at present, where these vars are 
being set... will continue to look.

> On Dec 20, 2018, at 10:17 AM, Rony G. Flatscher  
> wrote:
> 
> Peter,
> 
> as these are different problems to issue 117961 I opened three separate new 
> issues for them to allow
> to evaluate and trace them individually:
> 
>  * MacOS: PATH wrongly set for scripts: 
> 
>  * MacOS: Current directory wrongly set to root directory "/" for scripts:
>
>  * MacOS: Running via Java causes exception on MacOSX Mojave:
>
> 
> Once the critical PATH issue (127965 above) gets resolved, I will become able 
> to test issue 117961
> again and in case it still is a problem then, I would re-open it.
> 
> ---rony
> 
> 
> On 19.12.2018 18:22, Peter Kovacs wrote:
>> Since it has been closed because of lack of response, just reopen it and
>> continue.
>> 
>> 
>> On 19.12.18 18:06, Rony G. Flatscher (Apache) wrote:
>>> While re-assessing the (Java based) scripting framework on Apple (checking 
>>> on
>>> ) for AOO 4.1.6 the 
>>> following problems could be
>>> isolated:
>>> 
>>>  * the PATH environment variable on MacOS gets tampered with, such that 
>>> executables in
>>>"/usr/local/bin" cannot be resolved, breaking the long standing 
>>> scripting support for ooRexx
>>>  o AOO 4.1.6 on Darwin sets the PATH environment variable to
>>>.:/usr/bin:/bin:/usr/sbin:/sbin
>>>rather, it should just leave the PATH environment variable intact as 
>>> is the case on AOO
>>>4.1.6 for Linux
>>> 
>>>As Apple has forced third party software to install to "/usr/local" a 
>>> few years ago, at least
>>>"/usr/local/bin" needs to be available at all times as well! (Better 
>>> would be the user's PATH
>>>value like on Linux.)
>>> 
>>>  * the current directory is set to the root directory "/" rather than to 
>>> the user's home directory
>>>like on Linux
>>> 
>>> ---
>>> 
>>> Another observation that pertains to Apple only: interacting with AOO using 
>>> the Java archives
>>> (juh.jar, unoil.jar, ridl.jar, jurt.jar) from Java now causes a runtime 
>>> exception on Apple with Java
>>> 9. Not sure whether this is the Apple AOO or the Java responsibility (it 
>>> used to work in the past
>>> years).
>>> 
>>> Here the trace of the exception (RexxDispatcher.java is the Java program 
>>> that will invoke the ooRexx
>>> scripting engine which itself uses a Java bridge that interacts with AOO 
>>> via Java):
>>> 
>>>wu114215:test rony$ rexxj.sh OpenOfficeTest.rex 
>>>*CE> 2018-12-18 16:06:25.356 soffice[6648:119551] WARNING: NSWindow drag 
>>> regions should only be
>>>invalidated on the Main Thread! This will throw an exception in the 
>>> future. Called from (***CE>  0   AppKit  
>>> 0x7fff381bdccc -[NSWindow(NSWindow_Theme) 
>>> _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
>>>CE>  1   AppKit  0x7fff381bb07c 
>>> -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
>>>CE>  2   AppKit  0x7fff381baaa6 
>>> -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
>>>CE>  3   libvcl.dylib0x0001118d5286 
>>> -[SalFrameWindow initWithSalFrame:] + 262
>>>CE>  4   libvcl.dylib0x00011160e273 
>>> _ZN12AquaSalFrame17initWindowAndViewEv + 643
>>>CE>  5   libvcl.dylib0x00011160deb7 
>>> _ZN12AquaSalFrameC2EP8SalFramem + 519
>>>CE>  6   libvcl.dylib0x0001115e93f0 
>>> _ZN15AquaSalInstance11CreateFrameEP8SalFramem + 48
>>>CE>  7   libvcl.dylib0x00011189f567 
>>> _ZN6Window8ImplInitEPS_lP16SystemParentData + 1159
>>>CE>  8   libvcl.dylib0x000111823184 
>>> _ZN16ImplBorderWindow8ImplInitEP6WindowltP16SystemParentData + 404
>>>CE>  9   libvcl.dylib0x0001118234c5 
>>> _ZN16ImplBorderWindowC1EP6WindowP16SystemParentDatalt + 69
>>>CE>  10  libvcl.dylib0x0001118bef78 
>>> _ZN10WorkWindow8ImplInitEP6WindowlP16SystemParentData + 88
>>>CE>  11  libvcl.dylib0x0001118bf320 
>>> _ZN10WorkWindowC1EP6Windowl + 80
>>>CE>  12  libootk.dylib   0x0001109420c0 
>>> _ZN11VCLXToolkit16ImplCreateWindowEPP10VCLXWindowRKN3com3sun4star3awt16WindowDescriptorEP6Windowl
>>>  + 5712
>>>CE>  13  libootk.dylib   0x000110940454 
>>> _ZN11VCLXToolkit16ImplCreateWindowERKN3com3sun4star3awt16WindowDescriptorEl 
>>> + 452
>>>CE>  14  libootk.dylib   

Re: Ad Apple''s setup for the (Java) scripting framework

[Rony G. Flatscher]

Peter,

as these are different problems to issue 117961 I opened three separate new 
issues for them to allow
to evaluate and trace them individually:

  * MacOS: PATH wrongly set for scripts: 

  * MacOS: Current directory wrongly set to root directory "/" for scripts:

  * MacOS: Running via Java causes exception on MacOSX Mojave:


Once the critical PATH issue (127965 above) gets resolved, I will become able 
to test issue 117961
again and in case it still is a problem then, I would re-open it.

---rony


On 19.12.2018 18:22, Peter Kovacs wrote:
> Since it has been closed because of lack of response, just reopen it and
> continue.
>
>
> On 19.12.18 18:06, Rony G. Flatscher (Apache) wrote:
>> While re-assessing the (Java based) scripting framework on Apple (checking on
>> ) for AOO 4.1.6 the 
>> following problems could be
>> isolated:
>>
>>   * the PATH environment variable on MacOS gets tampered with, such that 
>> executables in
>> "/usr/local/bin" cannot be resolved, breaking the long standing 
>> scripting support for ooRexx
>>   o AOO 4.1.6 on Darwin sets the PATH environment variable to
>> .:/usr/bin:/bin:/usr/sbin:/sbin
>> rather, it should just leave the PATH environment variable intact as 
>> is the case on AOO
>> 4.1.6 for Linux
>>
>> As Apple has forced third party software to install to "/usr/local" a 
>> few years ago, at least
>> "/usr/local/bin" needs to be available at all times as well! (Better 
>> would be the user's PATH
>> value like on Linux.)
>>
>>   * the current directory is set to the root directory "/" rather than to 
>> the user's home directory
>> like on Linux
>>
>> ---
>>
>> Another observation that pertains to Apple only: interacting with AOO using 
>> the Java archives
>> (juh.jar, unoil.jar, ridl.jar, jurt.jar) from Java now causes a runtime 
>> exception on Apple with Java
>> 9. Not sure whether this is the Apple AOO or the Java responsibility (it 
>> used to work in the past
>> years).
>>
>> Here the trace of the exception (RexxDispatcher.java is the Java program 
>> that will invoke the ooRexx
>> scripting engine which itself uses a Java bridge that interacts with AOO via 
>> Java):
>>
>> wu114215:test rony$ rexxj.sh OpenOfficeTest.rex 
>> *CE> 2018-12-18 16:06:25.356 soffice[6648:119551] WARNING: NSWindow drag 
>> regions should only be
>> invalidated on the Main Thread! This will throw an exception in the 
>> future. Called from (***CE>  0   AppKit  
>> 0x7fff381bdccc -[NSWindow(NSWindow_Theme) 
>> _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
>> CE>  1   AppKit  0x7fff381bb07c 
>> -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
>> CE>  2   AppKit  0x7fff381baaa6 
>> -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
>> CE>  3   libvcl.dylib0x0001118d5286 
>> -[SalFrameWindow initWithSalFrame:] + 262
>> CE>  4   libvcl.dylib0x00011160e273 
>> _ZN12AquaSalFrame17initWindowAndViewEv + 643
>> CE>  5   libvcl.dylib0x00011160deb7 
>> _ZN12AquaSalFrameC2EP8SalFramem + 519
>> CE>  6   libvcl.dylib0x0001115e93f0 
>> _ZN15AquaSalInstance11CreateFrameEP8SalFramem + 48
>> CE>  7   libvcl.dylib0x00011189f567 
>> _ZN6Window8ImplInitEPS_lP16SystemParentData + 1159
>> CE>  8   libvcl.dylib0x000111823184 
>> _ZN16ImplBorderWindow8ImplInitEP6WindowltP16SystemParentData + 404
>> CE>  9   libvcl.dylib0x0001118234c5 
>> _ZN16ImplBorderWindowC1EP6WindowP16SystemParentDatalt + 69
>> CE>  10  libvcl.dylib0x0001118bef78 
>> _ZN10WorkWindow8ImplInitEP6WindowlP16SystemParentData + 88
>> CE>  11  libvcl.dylib0x0001118bf320 
>> _ZN10WorkWindowC1EP6Windowl + 80
>> CE>  12  libootk.dylib   0x0001109420c0 
>> _ZN11VCLXToolkit16ImplCreateWindowEPP10VCLXWindowRKN3com3sun4star3awt16WindowDescriptorEP6Windowl
>>  + 5712
>> CE>  13  libootk.dylib   0x000110940454 
>> _ZN11VCLXToolkit16ImplCreateWindowERKN3com3sun4star3awt16WindowDescriptorEl 
>> + 452
>> CE>  14  libootk.dylib   0x0001109407b4 
>> _ZThn80_N11VCLXToolkit12createWindowERKN3com3sun4star3awt16WindowDescriptorE 
>> + 20
>> CE>  15  libfwk.dylib0x000113f2d84e 
>> 

Re: Ad Apple''s setup for the (Java) scripting framework

[Peter Kovacs]

Since it has been closed because of lack of response, just reopen it and
continue.


On 19.12.18 18:06, Rony G. Flatscher (Apache) wrote:
> While re-assessing the (Java based) scripting framework on Apple (checking on
> ) for AOO 4.1.6 the 
> following problems could be
> isolated:
>
>   * the PATH environment variable on MacOS gets tampered with, such that 
> executables in
> "/usr/local/bin" cannot be resolved, breaking the long standing scripting 
> support for ooRexx
>   o AOO 4.1.6 on Darwin sets the PATH environment variable to
> .:/usr/bin:/bin:/usr/sbin:/sbin
> rather, it should just leave the PATH environment variable intact as 
> is the case on AOO
> 4.1.6 for Linux
>
> As Apple has forced third party software to install to "/usr/local" a few 
> years ago, at least
> "/usr/local/bin" needs to be available at all times as well! (Better 
> would be the user's PATH
> value like on Linux.)
>
>   * the current directory is set to the root directory "/" rather than to the 
> user's home directory
> like on Linux
>
> ---
>
> Another observation that pertains to Apple only: interacting with AOO using 
> the Java archives
> (juh.jar, unoil.jar, ridl.jar, jurt.jar) from Java now causes a runtime 
> exception on Apple with Java
> 9. Not sure whether this is the Apple AOO or the Java responsibility (it used 
> to work in the past
> years).
>
> Here the trace of the exception (RexxDispatcher.java is the Java program that 
> will invoke the ooRexx
> scripting engine which itself uses a Java bridge that interacts with AOO via 
> Java):
>
> wu114215:test rony$ rexxj.sh OpenOfficeTest.rex 
> *CE> 2018-12-18 16:06:25.356 soffice[6648:119551] WARNING: NSWindow drag 
> regions should only be
> invalidated on the Main Thread! This will throw an exception in the 
> future. Called from (***CE>   0   AppKit  
> 0x7fff381bdccc -[NSWindow(NSWindow_Theme) 
> _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
> CE>   1   AppKit  0x7fff381bb07c 
> -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
> CE>   2   AppKit  0x7fff381baaa6 
> -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
> CE>   3   libvcl.dylib0x0001118d5286 
> -[SalFrameWindow initWithSalFrame:] + 262
> CE>   4   libvcl.dylib0x00011160e273 
> _ZN12AquaSalFrame17initWindowAndViewEv + 643
> CE>   5   libvcl.dylib0x00011160deb7 
> _ZN12AquaSalFrameC2EP8SalFramem + 519
> CE>   6   libvcl.dylib0x0001115e93f0 
> _ZN15AquaSalInstance11CreateFrameEP8SalFramem + 48
> CE>   7   libvcl.dylib0x00011189f567 
> _ZN6Window8ImplInitEPS_lP16SystemParentData + 1159
> CE>   8   libvcl.dylib0x000111823184 
> _ZN16ImplBorderWindow8ImplInitEP6WindowltP16SystemParentData + 404
> CE>   9   libvcl.dylib0x0001118234c5 
> _ZN16ImplBorderWindowC1EP6WindowP16SystemParentDatalt + 69
> CE>   10  libvcl.dylib0x0001118bef78 
> _ZN10WorkWindow8ImplInitEP6WindowlP16SystemParentData + 88
> CE>   11  libvcl.dylib0x0001118bf320 
> _ZN10WorkWindowC1EP6Windowl + 80
> CE>   12  libootk.dylib   0x0001109420c0 
> _ZN11VCLXToolkit16ImplCreateWindowEPP10VCLXWindowRKN3com3sun4star3awt16WindowDescriptorEP6Windowl
>  + 5712
> CE>   13  libootk.dylib   0x000110940454 
> _ZN11VCLXToolkit16ImplCreateWindowERKN3com3sun4star3awt16WindowDescriptorEl + 
> 452
> CE>   14  libootk.dylib   0x0001109407b4 
> _ZThn80_N11VCLXToolkit12createWindowERKN3com3sun4star3awt16WindowDescriptorE 
> + 20
> CE>   15  libfwk.dylib0x000113f2d84e 
> _ZN9framework18TaskCreatorService28implts_createContainerWindowERKN3com3sun4star3uno9ReferenceINS3_3awt7XWindowEEERKNS6_9RectangleEh
>  + 1022
> CE>   16  libfwk.dylib0x000113f2cecc 
> _ZN9framework18TaskCreatorService27createInstanceWithArgumentsERKN3com3sun4star3uno8SequenceINS4_3AnyEEE
>  + 924
> CE>   17  libfwk.dylib0x000113f2ecd2 
> _ZThn16_N9framework18TaskCreatorService27createInstanceWithArgumentsERKN3com3sun4star3uno8SequenceINS4_3AnyEEE
>  + 18
> CE>   18  libfwk.dylib0x000113e34591 
> _ZN9framework11TaskCreator10createTaskERKN3rtl8OUStringEh + 3089
> CE>   19  libfwk.dylib0x000113efbd9a 
> _ZN9framework7Desktop9findFrameERKN3rtl8OUStringEi + 778
> CE>   20  libfwk.dylib0x000113efc3b2 
>