Re: Making non-Java binareis available to Tomcat, how about ...
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
Re: Making non-Java binareis available to Tomcat, how about ...
Rony,
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? 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:
1. Don't
2. Don't use the PATH environment variable; always use full paths
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.
You can even set $PATH in there if you really want to.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Making non-Java binareis available to Tomcat, how about ...
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).
>> 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 excercised
in the Tomcat
supplied scripts, if it exists!
---rony
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Making non-Java binareis available to Tomcat, how about ...
Rony, On 4/20/21 06:46, Rony G. Flatscher (Apache) wrote: CATALINA_OPTS is about passing on Java options and System property definitions, if not mistaken. Correct. 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". 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. -chris On 19.04.2021 17:37, Christopher Schultz wrote: Rony, On 4/19/21 08:54, Rony G. Flatscher (Apache) wrote: Java based web servers are - of course - focused on the Java programming language and the Java runtime environment. Nevertheless, there are situations where non-Java binaries may become resources that may prove helpful in a Java environment. As Java allows interfacing with non-Java binaries via JNI (Java native interface) it may make sense to support native binaries in Tomcat as well. Use case in question would be to make non-Java programming languages with JNI interfaces available without having to install such programming languages globally on the server. There may be other use cases as well (e.g. non-public security libraries). In order to make this as simple as possible and yet allow for the Tomcat setup to be as secure as setting up shared Java libraries, how about allowing for the following: * allow optional "$CATALINA_HOME/natives/bin" and "$CATALINA_HOME/natives/lib" directories into which the (Tomcat shared) binaries can be placed, Is there anything wrong with using CATALINA_OPTS to set java.library.path to some arbitrary value? I always have mine set to CATALINA_BASE/lib * if "$CATALINA_HOME/natives/bin" exists have the PATH environment variable prepended with "$CATALINA_HOME/natives/bin" before Tomcat gets started up, Note that java.library.path (a system property) would be better than changing the PATH environment variable. * if "$CATALINA_HOME/natives/lib" exists do whatever is needed for Linux and MacOS systems for the process to become able to recognize the shared native libraries there, Nothing further is needed after java.library.path is set. * if there are jar files (possibly with JNI interfaces) in "$CATALINA_HOME/natives/lib" then add them to Tomcat (like the jar files in "$CATALINA_HOME/lib"). If you use CATALINA_BASE/lib, then this is already done for you. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Making non-Java binareis available to Tomcat, how about ...
Hi Chris, CATALINA_OPTS is about passing on Java options and System property definitions, if not mistaken. 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. 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). ---rony On 19.04.2021 17:37, Christopher Schultz wrote: > Rony, > > On 4/19/21 08:54, Rony G. Flatscher (Apache) wrote: >> Java based web servers are - of course - focused on the Java programming >> language and the Java >> runtime environment. >> >> Nevertheless, there are situations where non-Java binaries may become >> resources that may prove >> helpful in a Java environment. >> >> As Java allows interfacing with non-Java binaries via JNI (Java native >> interface) it may make sense >> to support native binaries in Tomcat as well. >> >> Use case in question would be to make non-Java programming languages with >> JNI interfaces available >> without having to install such programming languages globally on the server. >> There may be other use >> cases as well (e.g. non-public security libraries). >> >> In order to make this as simple as possible and yet allow for the Tomcat >> setup to be as secure as >> setting up shared Java libraries, how about allowing for the following: >> >> * allow optional "$CATALINA_HOME/natives/bin" and >> "$CATALINA_HOME/natives/lib" directories into >> which the (Tomcat shared) binaries can be placed, > > Is there anything wrong with using CATALINA_OPTS to set java.library.path to > some arbitrary value? > I always have mine set to CATALINA_BASE/lib > >> * if "$CATALINA_HOME/natives/bin" exists have the PATH environment >> variable prepended with >> "$CATALINA_HOME/natives/bin" before Tomcat gets started up, > > Note that java.library.path (a system property) would be better than changing > the PATH environment > variable. > >> * if "$CATALINA_HOME/natives/lib" exists do whatever is needed for Linux >> and MacOS systems for >> the >> process to become able to recognize the shared native libraries there, > > Nothing further is needed after java.library.path is set. > >> * if there are jar files (possibly with JNI interfaces) in >> "$CATALINA_HOME/natives/lib" then add >> them to Tomcat (like the jar files in "$CATALINA_HOME/lib"). > > If you use CATALINA_BASE/lib, then this is already done for you. > > -chris > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Making non-Java binareis available to Tomcat, how about ...
Rony, On 4/19/21 08:54, Rony G. Flatscher (Apache) wrote: Java based web servers are - of course - focused on the Java programming language and the Java runtime environment. Nevertheless, there are situations where non-Java binaries may become resources that may prove helpful in a Java environment. As Java allows interfacing with non-Java binaries via JNI (Java native interface) it may make sense to support native binaries in Tomcat as well. Use case in question would be to make non-Java programming languages with JNI interfaces available without having to install such programming languages globally on the server. There may be other use cases as well (e.g. non-public security libraries). In order to make this as simple as possible and yet allow for the Tomcat setup to be as secure as setting up shared Java libraries, how about allowing for the following: * allow optional "$CATALINA_HOME/natives/bin" and "$CATALINA_HOME/natives/lib" directories into which the (Tomcat shared) binaries can be placed, Is there anything wrong with using CATALINA_OPTS to set java.library.path to some arbitrary value? I always have mine set to CATALINA_BASE/lib * if "$CATALINA_HOME/natives/bin" exists have the PATH environment variable prepended with "$CATALINA_HOME/natives/bin" before Tomcat gets started up, Note that java.library.path (a system property) would be better than changing the PATH environment variable. * if "$CATALINA_HOME/natives/lib" exists do whatever is needed for Linux and MacOS systems for the process to become able to recognize the shared native libraries there, Nothing further is needed after java.library.path is set. * if there are jar files (possibly with JNI interfaces) in "$CATALINA_HOME/natives/lib" then add them to Tomcat (like the jar files in "$CATALINA_HOME/lib"). If you use CATALINA_BASE/lib, then this is already done for you. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Making non-Java binareis available to Tomcat, how about ...
Java based web servers are - of course - focused on the Java programming language and the Java runtime environment. Nevertheless, there are situations where non-Java binaries may become resources that may prove helpful in a Java environment. As Java allows interfacing with non-Java binaries via JNI (Java native interface) it may make sense to support native binaries in Tomcat as well. Use case in question would be to make non-Java programming languages with JNI interfaces available without having to install such programming languages globally on the server. There may be other use cases as well (e.g. non-public security libraries). In order to make this as simple as possible and yet allow for the Tomcat setup to be as secure as setting up shared Java libraries, how about allowing for the following: * allow optional "$CATALINA_HOME/natives/bin" and "$CATALINA_HOME/natives/lib" directories into which the (Tomcat shared) binaries can be placed, * if "$CATALINA_HOME/natives/bin" exists have the PATH environment variable prepended with "$CATALINA_HOME/natives/bin" before Tomcat gets started up, * if "$CATALINA_HOME/natives/lib" exists do whatever is needed for Linux and MacOS systems for the process to become able to recognize the shared native libraries there, * if there are jar files (possibly with JNI interfaces) in "$CATALINA_HOME/natives/lib" then add them to Tomcat (like the jar files in "$CATALINA_HOME/lib"). Would such an idea be seen as acceptable, helpful? ---rony
