Re: Making non-Java binareis available to Tomcat, how about ...

2021-04-23 Thread Rony G. Flatscher (Apache)
Hi Chris,

On 23.04.2021 05:12, Christopher Schultz wrote:
> On 4/21/21 08:53, Rony G. Flatscher (Apache) wrote:
>> Hi Chris,
>>
>> On 20.04.2021 16:47, Christopher Schultz wrote:
>> ... cut ...
>> When bringing non-Java binaries into the picture then they work in the 
>> process environment where
 e.g. PATH defines which directories are looked up for finding executables 
 (which might be
 important
 for some natives) and on Windows DLLs, and in Linux and MacOS shared 
 libraries need to be found by
 the non-Java native code. Hence the desire to allow setting up the process 
 environment before
 starting up Tomcat in a simple, but effective way.
>>>
>>> You may want to do a Google search for "java.library.path".
>>
>> have been aware of (and using) "java.library.path" for quite some time, it 
>> does not do for natives
>> what it does for the JVM. E.g. adding a path via something like
>>
>>     -Djava.library.path="%PATH%;x:\some\path" | 
>> -Djava.library.path="${PATH}:/some/path"
>>
>> does not change the process environment variable PATH accordingly (adding 
>> "x:\some\path" |
>> "/some/path" to the PATH environment variable) such that a native library 
>> can issue a command that
>> will be looked for in addition in "x:\some\path" | "/some/path" (just tested 
>> it again on Windows
>> with Java 8).
>
> Do you mean when you call exec() or similar (yuck!) or do you mean loading 
> dependencies for your
> native library? 
There are scenarios where the former is done in the context of the native 
binaries (not from Java).

> If you have native dependencies for your shared library, you should also put 
> them into the
> java.library.path.
>
> If you are calling exec() or system() or anything like that from your Java 
> code:

No, not from the Java code, but may be a valid scenario from/via the native 
binaries.

> 1. Don't
> 2. Don't use the PATH environment variable; always use full paths

There are scenarios where PATH becomes relevant (again for native binaries, not 
Java).

 However, with CATALINA_OPTS you brought the startup/stop|shutdown/catalina 
 scripts into the
 picture,
 which might be a possible solution (though being very wary 
 altering/tampering such fundamental
 scripts).
>>>
>>> I didn't suggest that you modify those scripts. I only suggested that you 
>>> use an environment
>>> variable that those scripts are aware of.
>>>
>>> Typically, admins will create a bin/setenv.sh script which sets all 
>>> environment variables
>>> necessary for local operation. You could even change the PATH variable -- 
>>> if you really want to do
>>> that -- there.
>>
>> Thank you very much for this pointer, seeing "setenv.{sh|bat}" being 
>> exercised in the Tomcat
>> supplied scripts, if it exists!
>
> That's why it's there.

:)

How about services/daemons?

> You can even set $PATH in there if you really want to.

Yes, indeed, which got me a little bit excited. :)

---rony



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



Servlet filter execution ordering

2021-04-23 Thread Christopher Schultz

All,

When building a filter chain to execute for a request, the spec says 
that the ordering is "as declared in the deployment descriptor". These 
is an example in the spec language but I wanted to be absolutely sure I 
understand this.


The ordering of the  elements in web.xml is not relevant. Only 
the order of the  elements (which match the request's 
) is relevant.


Do I have that correct?

-chris

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