ApacheCon Asia 2021 is calling for Presentations!

[Huxing Zhang]

Hi All,

ApacheCon Asia is coming virtually this August 6 - 8. The CFP will end
on Monday, May 3rd, 2021 8:00 AM (Beijing time - UTC +8).

More details could be found here:

https://apachecon.com/acasia2021/cfp.html

If you have concern with the date and time, please remember that there
is no need to be present at the conference, it is completely virtual,
the talk is pre-recorded.

The presentation could be either in English or in Chinese.

Please free free to submit your ideas related to Web server / Tomcat
or other topics here:

https://acasia2021.jamhosted.net/

-- 
Best Regards！
Huxing

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

RE: Tomcat 9: Application in not starting with TrustStore attributes

[Palod, Manish]

Thanks John,

I will debug this further with pointers you have provided.

Thanks
Manish

-Original Message-
From: john.e.gr...@wellsfargo.com.INVALID  
Sent: Tuesday, April 20, 2021 7:27 PM
To: users@tomcat.apache.org
Subject: RE: Tomcat 9: Application in not starting with TrustStore attributes

CAUTION: External email. Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Manish,

> -Original Message-
> From: Palod, Manish 
> Sent: Tuesday, April 20, 2021 8:37 AM
> To: users@tomcat.apache.org
> Subject: Tomcat 9: Application in not starting with TrustStore 
> attributes
> 
> Hi,
> 
> We are in process of upgrading Tomcat 7 to Tomcat 9 and stuck with 
> Trust store settings for Client certificate, following is the connector 
> setting:
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
>maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true" compression="on"
> compressibleMimeType="text/html,text/xml,text/plain,text/javascript,te
> xt/ css,application/x-javascript,application/javascript"
>address="0.0.0.0"
>maxPostSize="10485760"
>URIEncoding="UTF-8" server=" ">
>  truststorePassword="${tomcat.bind.truststorepass}" truststoreType="jks"
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
> certificateVerification="optional" sslProtocol="TLS"
> protocols="TLSv1.2">
>  certificateKeystorePassword ="${tomcat.bind.keystorepass}"
>  type="RSA" />
> 
> 
> 
> Application is working properly when truststoreFile, 
> truststorePassword and truststoreType attributes are not defined in 
> SSLHostConfig, when these attributes are defined, we are getting following 
> errors at Tomcat start:
> The same configuration parameters are working fine with Tomcat 7. 
> Store has 1 valid certificate and rechecked that with keytool with 
> password and able to list the certificate.
> Parametrized values are replaced with actual value and that part is 
> working fine.
> 
> 
> INFO: Initializing ProtocolHandler ["http-nio-0.0.0.0-80"] Apr 20, 
> 2021 6:59:31 PM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["https-jsse-nio-0.0.0.0-443"] Apr 
> 20, 2021
> 6:59:31 PM org.apache.catalina.util.LifecycleBase 
> handleSubClassException
> SEVERE: Failed to initialize component [Connector[HTTP/1.1-443]]
> org.apache.catalina.LifecycleException: Protocol handler initialization failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1049)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.
> java:5
> 58)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.ja
> va:10
> 45)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)
> at
> Caused by: java.lang.IllegalArgumentException: the trustAnchors 
> parameter must be non-empty
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> act
> JsseEndpoint.java:99)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(Abstract
> JsseEn
> dpoint.java:71)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:246)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEn
> dp
> oint.java:1193)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java
> :1206
> )
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:597)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
> toc
> ol.java:80)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1046)
> ... 14 more
> Caused by: java.security.InvalidAlgorithmParameterException: the 
> trustAnchors parameter must be non-empty
> at
> java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:
> 200
> )
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
> at
> 

Re: Is there a way to know/infer that a JSP got freshly compiled from a taglib library ?

[Christopher Schultz]

Rony,

On 4/20/21 07:06, Rony G. Flatscher (Apache) wrote:

Hi Chris,

On 19.04.2021 17:32, Christopher Schultz wrote:


On 4/18/21 08:06, Rony G. Flatscher (Apache) wrote:

On 11.03.2021 12:23, Rony G. Flatscher (Apache) wrote:

On 11.03.2021 11:53, Mark Thomas wrote:

On 10/03/2021 15:14, Rony G. Flatscher (Apache) wrote:

Is there a way to know/infer that a JSP got freshly compiled from e.g. a taglib 
library?

For caching purposes it would be necessary to learn whether a JSP got 
recompiled as the cache
should
be purged in that case.

Is there a way to find out whether a JSP run is the very first after 
(re-)compilation?

Or can one rely that if a JSP gets recompiled that a new PageContext gets 
created for it (or if
reused does not contain any custom attributes placed there earlier at the 
PAGE_SCOPE)?

Page scope gets reset at the end of a request so that won't work.

It might not be perfect (containers are allowed to unload unused servlets/JSPs) 
but in you are
using Tomcat and haven't configured maxLoadedJsps or jspIdleTimeout then you 
should be able to use
the jspInit() method. (See JSP spec for details).


It seems that the implicit JSP "page" object can probably be used to determine 
whether a JSP got
recompiled as its hashCode() changes after recompilation.


Something safer might be to keep a cache of datestamps keyed by JSP name (or 
whatever). When the
JSP's init() method is called, you could update the datestamp.

Or do you need to know about the recompliation before the init() is called?


The BodyTag interface [1,2] does not define an init() method, you think 
probably of the Servlet
interface [3,4].


Aha, it wasn't clear to me that you needed to know at the taglib level 
that a JSP had been recompiled.



Ad 'page' implicit object: if the 'page' object gets referenced in the taglib, 
then a re-compiled
version of the same JSP page is guaranteed to have a different hashCode() value


Really? That seems ... awfully convenient and also quite hacky. Do you 
have a reference to the spec that guarantees that modified hashcode?



and as such suffices
to determine whether a page got compiled since the last time this got checked 
in the taglib. The
motivation for learning about a (re-)fresh(ed) page is to remove any cached 
compiled scripts of that
jsp (if it got recompiled then something got changed in the jsp, so also 
scripts might have changed)
and from then on build a new cache.


Yeah, I don't see a great way to do that. You can get the ServletContext 
from the PageContext, but ... you would still need a lot of support in 
there to get what you want.


What about cheating and just putting a Tag at the top-level where you 
have to declare the "version" of the script, and changing the "version" 
causes the cache to be cleared?


-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 ...

[Christopher Schultz]

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: Tomcat 9: Application in not starting with TrustStore attributes

[John.E.Gregg]

Manish,

> -Original Message-
> From: Palod, Manish 
> Sent: Tuesday, April 20, 2021 8:37 AM
> To: users@tomcat.apache.org
> Subject: Tomcat 9: Application in not starting with TrustStore attributes
> 
> Hi,
> 
> We are in process of upgrading Tomcat 7 to Tomcat 9 and stuck with Trust
> store settings for Client certificate, following is the connector setting:
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
>maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true" compression="on"
> compressibleMimeType="text/html,text/xml,text/plain,text/javascript,text/
> css,application/x-javascript,application/javascript"
>address="0.0.0.0"
>maxPostSize="10485760"
>URIEncoding="UTF-8" server=" ">
>  truststorePassword="${tomcat.bind.truststorepass}" truststoreType="jks"
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
> certificateVerification="optional" sslProtocol="TLS"
> protocols="TLSv1.2">
>  certificateKeystorePassword ="${tomcat.bind.keystorepass}"
>  type="RSA" />
> 
> 
> 
> Application is working properly when truststoreFile, truststorePassword and
> truststoreType attributes are not defined in SSLHostConfig, when these
> attributes are defined, we are getting following errors at Tomcat start:
> The same configuration parameters are working fine with Tomcat 7. Store
> has 1 valid certificate and rechecked that with keytool with password and
> able to list the certificate.
> Parametrized values are replaced with actual value and that part is working
> fine.
> 
> 
> INFO: Initializing ProtocolHandler ["http-nio-0.0.0.0-80"] Apr 20, 2021 
> 6:59:31
> PM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["https-jsse-nio-0.0.0.0-443"] Apr 20, 2021
> 6:59:31 PM org.apache.catalina.util.LifecycleBase handleSubClassException
> SEVERE: Failed to initialize component [Connector[HTTP/1.1-443]]
> org.apache.catalina.LifecycleException: Protocol handler initialization failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1049)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:5
> 58)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:10
> 45)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)
> at
> com.intruvert.common.utility.startup.StartupChecks.main(StartupChecks.jav
> a:140)
> Caused by: java.lang.IllegalArgumentException: the trustAnchors parameter
> must be non-empty
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstract
> JsseEndpoint.java:99)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEn
> dpoint.java:71)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:246)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndp
> oint.java:1193)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1206
> )
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:597)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protoc
> ol.java:80)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1046)
> ... 14 more
> Caused by: java.security.InvalidAlgorithmParameterException: the
> trustAnchors parameter must be non-empty
> at
> java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200
> )
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
> at
> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:
> 130)
> at
> org.apache.tomcat.util.net.SSLUtilBase.getParameters(SSLUtilBase.java:501)
> at
> org.apache.tomcat.util.net.SSLUtilBase.getTrustManagers(SSLUtilBase.java:4
> 32)
> at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:2
> 46)
> at
> 

Tomcat 9: Application in not starting with TrustStore attributes

[Palod, Manish]

Hi,

We are in process of upgrading Tomcat 7 to Tomcat 9 and stuck with Trust store 
settings for Client certificate, following is the connector setting:







Application is working properly when truststoreFile, truststorePassword and 
truststoreType attributes are not defined in SSLHostConfig, when these 
attributes are defined, we are getting following errors at Tomcat start:
The same configuration parameters are working fine with Tomcat 7. Store has 1 
valid certificate and rechecked that with keytool with password and able to 
list the certificate.
Parametrized values are replaced with actual value and that part is working 
fine.


INFO: Initializing ProtocolHandler ["http-nio-0.0.0.0-80"]
Apr 20, 2021 6:59:31 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["https-jsse-nio-0.0.0.0-443"]
Apr 20, 2021 6:59:31 PM org.apache.catalina.util.LifecycleBase 
handleSubClassException
SEVERE: Failed to initialize component [Connector[HTTP/1.1-443]]
org.apache.catalina.LifecycleException: Protocol handler initialization failed
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:1049)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:558)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1045)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)
at 
com.intruvert.common.utility.startup.StartupChecks.main(StartupChecks.java:140)
Caused by: java.lang.IllegalArgumentException: the trustAnchors parameter must 
be non-empty
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:99)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:246)
at 
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1193)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1206)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:597)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:1046)
... 14 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors 
parameter must be non-empty
at 
java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
at 
java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
at 
org.apache.tomcat.util.net.SSLUtilBase.getParameters(SSLUtilBase.java:501)
at 
org.apache.tomcat.util.net.SSLUtilBase.getTrustManagers(SSLUtilBase.java:432)
at 
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:246)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:97)
... 21 more

Apr 20, 2021 6:59:31 PM org.apache.catalina.startup.Catalina load
INFO: Server initialization in [2010] milliseconds


What is the error I am making with configuration in the connector part?

Thanks
Manish

Re: Is there a way to know/infer that a JSP got freshly compiled from a taglib library ?

[Rony G. Flatscher (Apache)]

Hi Chris,

On 19.04.2021 17:32, Christopher Schultz wrote:
>
> On 4/18/21 08:06, Rony G. Flatscher (Apache) wrote:
>> On 11.03.2021 12:23, Rony G. Flatscher (Apache) wrote:
>>> On 11.03.2021 11:53, Mark Thomas wrote:
 On 10/03/2021 15:14, Rony G. Flatscher (Apache) wrote:
> Is there a way to know/infer that a JSP got freshly compiled from e.g. a 
> taglib library?
>
> For caching purposes it would be necessary to learn whether a JSP got 
> recompiled as the cache
> should
> be purged in that case.
>
> Is there a way to find out whether a JSP run is the very first after 
> (re-)compilation?
>
> Or can one rely that if a JSP gets recompiled that a new PageContext gets 
> created for it (or if
> reused does not contain any custom attributes placed there earlier at the 
> PAGE_SCOPE)?
 Page scope gets reset at the end of a request so that won't work.

 It might not be perfect (containers are allowed to unload unused 
 servlets/JSPs) but in you are
 using Tomcat and haven't configured maxLoadedJsps or jspIdleTimeout then 
 you should be able to use
 the jspInit() method. (See JSP spec for details).
>>
>> It seems that the implicit JSP "page" object can probably be used to 
>> determine whether a JSP got
>> recompiled as its hashCode() changes after recompilation.
>
> Something safer might be to keep a cache of datestamps keyed by JSP name (or 
> whatever). When the
> JSP's init() method is called, you could update the datestamp.
>
> Or do you need to know about the recompliation before the init() is called?

The BodyTag interface [1,2] does not define an init() method, you think 
probably of the Servlet
interface [3,4].

Ad 'page' implicit object: if the 'page' object gets referenced in the taglib, 
then a re-compiled
version of the same JSP page is guaranteed to have a different hashCode() value 
and as such suffices
to determine whether a page got compiled since the last time this got checked 
in the taglib. The
motivation for learning about a (re-)fresh(ed) page is to remove any cached 
compiled scripts of that
jsp (if it got recompiled then something got changed in the jsp, so also 
scripts might have changed)
and from then on build a new cache.

---rony

[1] javax-BodyTag with lifecycle description:

[2] jakarta-BodyTag:

[3] jakarta-Servlet:

[4] Wikipedia "Jakarta Servlet": 



-
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 G. Flatscher (Apache)]

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