Hi Mark,
Well, anything is 100% better than nothing. Is this "127.0.0.1 - -
[31/Jul/2019:16:45:16 +0100] "-" 400 -" going to be followed by any reason or
error-code that can point to the reason of failure? Anything that distinguishes
it from a 'regular' 400 error originating after the
Chris,
We have done several product releases on Azul, also running our SaaS instances
without any issues. Granted, we're Windows-only product but I know other
products within my company that switched to it from Oracle's Java that have not
had any issues. When Oracle changed its license
On August 2, 2019 5:23:58 PM UTC, Mark Boon wrote:
>Hi Mark,
>
>Well, anything is 100% better than nothing. Is this "127.0.0.1 - -
>[31/Jul/2019:16:45:16 +0100] "-" 400 -" going to be followed by any
>reason or error-code that can point to the reason of failure?
No. I'm working with what I can
On 02/08/2019 10:12, Polina Georgieva wrote:
> Hi all,
>
> Would you please clarify the compatibility restrictions (if any) between
> the Apache Tomcat Native Lib and its dependencies on one hand and between
> Apache Tomcat server and the native lib. My questions are based on the
> information
Hi.
Not a full response but an additional source.
On 02.08.2019 11:12, Polina Georgieva wrote:
Hi all,
Would you please clarify the compatibility restrictions (if any) between
the Apache Tomcat Native Lib and its dependencies on one hand and between
Apache Tomcat server and the native lib.
Hi all,
Would you please clarify the compatibility restrictions (if any) between
the Apache Tomcat Native Lib and its dependencies on one hand and between
Apache Tomcat server and the native lib. My questions are based on the
information available here: http://tomcat.apache.org/native-doc/
