Re: Help Needed

[Rob Sargent]

> 
> On Aug 6, 2021, at 8:31 PM, Mohan T  wrote:
> 
> Dear All,
> 
> Any inputs on this. We are not getting a break in this.

Did upgrading change anything?
You may want to layout your configuration and why you think it should work. 
Which version of Java, etc?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Help Needed

[Mohan T]

Dear All,

Any inputs on this. We are not getting a break in this.

Kindly help us in taking things forward.

Thanks

Mohan

From: Mohan T
Sent: 06 August 2021 09:21
To: Tomcat Users List 
Subject: Help Needed

Dear All,

We are using Tomcat 8.5 on Suse LINUX.

We enabled JAvA security in  tomcat and invoking the Catalina.sh. We are facing 
some permission issues in the environment.

We could see the below error messages.

access: access allowed ("java.util.logging.LoggingPermission" "control")
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1336)
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:419)
at 
java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.util.logging.LogManager.checkPermission(LogManager.java:1586)
at java.util.logging.Logger.checkPermission(Logger.java:422)
at java.util.logging.Logger.removeHandler(Logger.java:1764)
at 
org.apache.juli.ClassLoaderLogManager.resetLoggers(ClassLoaderLogManager.java:393)
at 
org.apache.juli.ClassLoaderLogManager.shutdown(ClassLoaderLogManager.java:377)
at 
org.apache.juli.ClassLoaderLogManager$Cleaner.run(ClassLoaderLogManager.java:81)
policy: getPermissions:
PD CodeSource: 
(file:/home/ilas/tomcat8.5_tech/apache-tomcat-8.5.35/bin/tomcat-juli.jar )
PD ClassLoader: 
sun.misc.Launcher$AppClassLoader@3d4eac69
PD Principals: 
policy: evaluate codesources:
Policy CodeSource: (file:/usr/java/jdk1.8.0_162/jre/lib/- )
Active CodeSource: 
(file:/home/ilas/tomcat8.5_tech/apache-tomcat-8.5.35/bin/tomcat-juli.jar )

Thanks

Mohan
DISCLAIMER: This communication contains information which is confidential and 
the copyright of Ramco Systems Ltd, its subsidiaries or a third party 
("Ramco"). This email may also contain legally privileged information. 
Confidentiality and legal privilege attached to this communication are not 
waived or lost by reason of mistaken delivery to you.This email is intended to 
be read or used by the addressee only. If you are not the intended recipient, 
any use, distribution, disclosure or copying of this email is strictly 
prohibited without the express written approval of Ramco. Please delete and 
destroy all copies and email Ramco at le...@ramco.com immediately. Any views 
expressed in this communication are those of the individual sender, except 
where the sender specifically states them to be the views of Ramco. Except as 
required by law, Ramco does not represent, warrant and/or guarantee that the 
integrity of this communication has been maintained nor that the communication 
is free of errors, virus, interception or interference. If you do not wish to 
receive such communications, please forward this communication to 
market...@ramco.com and express your wish not to receive such communications 
henceforth.

Re: Clarification on behaviour after pool exhaustion happen in tomcat jdbc pool 9.0.16

[Christopher Schultz]

Sampath,

On 8/6/21 08:37, Sampath Rajapakshe wrote:

Hi All,

In my local setup before pool exhaustion exception is thrown, all the
connections seem to be in freezed and when checking processList in mysql,
those connections are in sleep state and doesn't execute any queries. After
waiting for maxWait period the pool exhausted exception gets thrown and
seems to reset the connections and then the queries are getting processed
as normally.

>

So, my question is, with pool exhausted scenarios, doesn't existing
connections execute their queries during that time(maxWait) and try to
resolve the exhausted behaviour by releasing those connections to idle
queue automatically? When checking the JMX matrix during this pool
exhausted time all the connections are in the active queue.


https://blog.christopherschultz.net/2009/03/16/properly-handling-pooled-jdbc-connections/


If not, what i am experiencing is as expected behaviour where the system is
stuck after pool exhaustion for the best case of maxWait?


Most of the time I've seen this kind of behavior it's due to sloppy 
resource-management.


-chris

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

Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

[Pete Helgren]

I don't have an AS/400 any longer but I do I have a 9009 running IBM i.  
If you use iACS and go to the IFS menu option, you can filter by a file 
name.  Are you looking for a class file within a jar or just the jar itself?


Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
AWS Certified Cloud Practitioner
Microsoft Certified: Azure Fundamentals
Twitter - Sys_i_Geek  IBM_i_Geek

On 8/6/2021 11:49 AM, James H. H. Lampert wrote:
Searching JAR files for "crimson" would likely be an exercise in 
futility on an AS/400.


--
JHHL

-
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

[ANN] Apache Tomcat 10.0.10 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.10.

This release is targeted at Jakarta EE 9.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

The notable changes compared to 10.0.8 include:

- Correct a regression in the previous release in the HTTP/2 flow
  control window management

- Correct a regression the could cause some TLS connections to hang when
  using NIO

- Use of GraalVM native images no longer automatically disables JMX
  support.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-10.cgi

Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

RE: More information, Re: Tomcat 8.5.68 failing on takeoff!

[John.E.Gregg]

> -Original Message-
> From: James H. H. Lampert 
> Sent: Friday, August 06, 2021 11:49 AM
> To: Tomcat Users List 
> Subject: Re: More information, Re: Tomcat 8.5.68 failing on takeoff!
> 
> Searching JAR files for "crimson" would likely be an exercise in futility on 
> an
> AS/400.
> 
> --
> JHHL
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

I think it's likely to have "crimson" in the file name.

https://search.maven.org/artifact/crimson/crimson/1.1.3/jar

It's ancient, BTW.

Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

[James H. H. Lampert]

Searching JAR files for "crimson" would likely be an exercise in 
futility on an AS/400.


--
JHHL

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

Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

[Rob Sargent]

> On Aug 6, 2021, at 10:17 AM, Konstantin Kolinko  
> wrote:
> 
> пт, 6 авг. 2021 г. в 01:33, James H. H. Lampert
> :
>> org.xml.sax.SAXNotRecognizedException: Feature:
>> http://apache.org/xml/features/allow-java-encodings
>>
>> org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:213)
>>
>> org.apache.crimson.jaxp.SAXParserImpl.setFeatures(SAXParserImpl.java:143)
>>org.apache.crimson.jaxp.SAXParserImpl.(SAXParserImpl.java:126)
>>
>> org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParserImpl(SAXParserFactoryImpl.java:113)
>>
>> org.apache.crimson.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:141)
> 
> Try to find what *.jar file in your system contains the above classes.
> 
> E.g. searching for string "crimson" in *.jar files.
> That string will be visible in the archive file as it is a name of a 
> directory.
> 
> HTH.
> 
I have a bash function which does this moderately well.  Happy to share it, if 
needed.

> -
> 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: More information, Re: Tomcat 8.5.68 failing on takeoff!

[Konstantin Kolinko]

пт, 6 авг. 2021 г. в 01:33, James H. H. Lampert
:
> org.xml.sax.SAXNotRecognizedException: Feature:
> http://apache.org/xml/features/allow-java-encodings
> 
> org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:213)
> 
> org.apache.crimson.jaxp.SAXParserImpl.setFeatures(SAXParserImpl.java:143)
> org.apache.crimson.jaxp.SAXParserImpl.(SAXParserImpl.java:126)
> 
> org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParserImpl(SAXParserFactoryImpl.java:113)
> 
> org.apache.crimson.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:141)

Try to find what *.jar file in your system contains the above classes.

E.g. searching for string "crimson" in *.jar files.
That string will be visible in the archive file as it is a name of a directory.

HTH.

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

Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

[James H. H. Lampert]

On 8/6/21 1:40 AM, Mark Thomas wrote:

Tomcat 7 doesn't have JASPIC support so you'll never see this issue in 
Tomcat 7.


What's a JASPIC?

And as to configuration, Mr. Schultz, my usual procedure is to (after 
commenting out the default 8080 unsecured connector) copy and paste the 
active secured port 443 connector *directly* from the Tomcat 7 
conf/server.xml to the Tomcat 8 conf/server.xml. Ditto for the one user 
definition in tomcat-users.xml.


That particular installation has a note to add this clause

birtUseSvg
false

to the web.xml of *our webapp,* but nothing server-wide.

--
JHHL

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

Re: Http11NioProtocol with TLS seems to be very slow for certain requests >= 9.0.48

[Mark Thomas]

On August 6, 2021 1:35:24 PM UTC, Benjamin Grenacher 
 wrote:
>Recently updated from 9.0.43 to 9.0.50 and are having similar symptoms
>as already reported ("Possible Http11NioProtocol regression since
>9.0.48?").
>
>Integration test runs have shown this issue seems to occur for browser
>tests only. Since we have larger JS files and requests take about 1 min
>(default connectionTimeout/keepAliveTimeout) this seems to be the same
>issue.
>
>Downgrading to 9.0.48 shows that the issue persists.
>
>Related active configuration is only "compression=off" the rest is
>default. Trying to change configuration (useSendfile, selectorTimeout,
>useBomIfPresent) didn't help.
>
>Seems to be resolved when using HTTP (no TLS).
>
>
>Running on docker swarm through reverse proxy and without explicit
>reverse proxy (swarm internally routes traffic, so kind of "proxy" in
>place).
>
>When running through reverse proxy there occur "I/O Errors" reported by
>the proxy (not restricted to JS file requests - e.g. includes favicon
>and svg requests).
>
>Related error logs (browser):
>
>https://XXX...b85a.js - Failed to load resource:
>net::ERR_CONTENT_LENGTH_MISMATCH
>
>https://XXX..f.min.js 14:1649 Uncaught SyntaxError: Unexpected end of
>input
>
>
>Running with local docker containers (without proxy): Can't reproduce
>issue.
>
>
>Let me know if you need anything else.

Most likely this:

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

Fix is in 9.0.51 onwards. Should be available in a few days if the vote is 
successful.

Switch to NIO2 if you need an immediate work around.

Mark

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

Re: Question for verification

[Mark Thomas]

On August 6, 2021 2:24:13 PM UTC, jonmcalexan...@wellsfargo.com.INVALID wrote:
>Verifying an assumption.
>
>All modern versions of Tomcat (8.5 and above) are compatible with Java
>11.

Yes.

We regularly test Tomcat with the early access versions of each Java release. 
We also have CI systems that test 8, 11 and latest.

Mark

>
>Thanks in advance
>
>Dream * Excel * Explore * Inspire
>Jon McAlexander
>Infrastructure Engineer
>Asst Vice President
>
>Middleware Product Engineering
>Enterprise CIO | Platform Services | Middleware | Infrastructure
>Solutions
>
>8080 Cobblestone Rd | Urbandale, IA 50322
>MAC: F4469-010
>Tel 515-988-2508 | Cell 515-988-2508
>
>jonmcalexan...@wellsfargo.com
>
>Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020,
>11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020,
>12/29/2020, 12/30/2020, 12/31/2020
>This message may contain confidential and/or privileged information. If
>you are not the addressee or authorized to receive this for the
>addressee, you must not use, copy, disclose, or take any action based
>on this message or any information herein. If you have received this
>message in error, please advise the sender immediately by reply e-mail
>and delete this message. Thank you for your cooperation.


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

RE: Question for verification

[jonmcalexander]

Doh

Thanks!

Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com

Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
12/30/2020, 12/31/2020
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: calder 
> Sent: Friday, August 6, 2021 9:45 AM
> To: Tomcat Users List 
> Subject: Re: Question for verification
> 
> On Fri, Aug 6, 2021, 09:31  wrote:
> 
> > Verifying an assumption.
> >
> > All modern versions of Tomcat (8.5 and above) are compatible with Java 11.
> >
> 
> GIYF
> 
> https://urldefense.com/v3/__https://tomcat.apache.org/whichversion.html
> __;!!F9svGWnIaVPGSwU!5OACMZ6S7VZsWNYMAuLJ-
> v0iUP2_CFdYOeHUf01bhLejkLIIgrlwgUt2wyjXaqPnsNkjYP8$

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

Re: Question for verification

[calder]

On Fri, Aug 6, 2021, 09:31  wrote:

> Verifying an assumption.
>
> All modern versions of Tomcat (8.5 and above) are compatible with Java 11.
>

GIYF

https://tomcat.apache.org/whichversion.html

Question for verification

[jonmcalexander]

Verifying an assumption.

All modern versions of Tomcat (8.5 and above) are compatible with Java 11.

Thanks in advance

Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com

Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
12/30/2020, 12/31/2020
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Http11NioProtocol with TLS seems to be very slow for certain requests >= 9.0.48

[Benjamin Grenacher]

Recently updated from 9.0.43 to 9.0.50 and are having similar symptoms as 
already reported ("Possible Http11NioProtocol regression since 9.0.48?").

Integration test runs have shown this issue seems to occur for browser tests 
only. Since we have larger JS files and requests take about 1 min (default 
connectionTimeout/keepAliveTimeout) this seems to be the same issue.

Downgrading to 9.0.48 shows that the issue persists.

Related active configuration is only "compression=off" the rest is default. 
Trying to change configuration (useSendfile, selectorTimeout, useBomIfPresent) 
didn't help.

Seems to be resolved when using HTTP (no TLS).


Running on docker swarm through reverse proxy and without explicit reverse 
proxy (swarm internally routes traffic, so kind of "proxy" in place).

When running through reverse proxy there occur "I/O Errors" reported by the 
proxy (not restricted to JS file requests - e.g. includes favicon and svg 
requests).

Related error logs (browser):

https://XXX...b85a.js - Failed to load resource: 
net::ERR_CONTENT_LENGTH_MISMATCH

https://XXX..f.min.js 14:1649 Uncaught SyntaxError: Unexpected end of input


Running with local docker containers (without proxy): Can't reproduce issue.


Let me know if you need anything else.


Ben

Clarification on behaviour after pool exhaustion happen in tomcat jdbc pool 9.0.16

[Sampath Rajapakshe]

Hi All,

In my local setup before pool exhaustion exception is thrown, all the
connections seem to be in freezed and when checking processList in mysql,
those connections are in sleep state and doesn't execute any queries. After
waiting for maxWait period the pool exhausted exception gets thrown and
seems to reset the connections and then the queries are getting processed
as normally.

So, my question is, with pool exhausted scenarios, doesn't existing
connections execute their queries during that time(maxWait) and try to
resolve the exhausted behaviour by releasing those connections to idle
queue automatically? When checking the JMX matrix during this pool
exhausted time all the connections are in the active queue.

If not, what i am experiencing is as expected behaviour where the system is
stuck after pool exhaustion for the best case of maxWait?

Thanks and regards,
Sampath
-- 

*Sampath Rajapakse* | Senior Software Engineer | WSO2 Inc.

+94717313761 | samp...@wso2.com

Re: Wrong logic for NONE as certificateKeystoreFile?

[Mark Thomas]

Thanks for the report. Fixed for the September release round.

Mark


On 05/08/2021 14:09, Mikael Sterner wrote:

It seems like the logic implemented for NONE as certificateKeystoreFile
deviates from the documentation. Currently NONE is always interpreted as
a file path, even for PKCS11. Looks like the comparison with NONE should
be inside the parentheses for the negation? A workaround is to use ""
instead of NONE.

https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/SSLUtilBase.java#L196

Yours,
Mikael

-
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: More information, Re: Tomcat 8.5.68 failing on takeoff!

[Mark Thomas]

On 06/08/2021 06:15, Christopher Schultz wrote:

On 8/5/21 18:33, James H. H. Lampert wrote:




java.lang.SecurityException: org.xml.sax.SAXNotRecognizedException: 
Feature: http://apache.org/xml/features/allow-java-encodings
 org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.loadProviders(PersistentProviderRegistrations.java:65) 

 org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.loadPersistentRegistrations(AuthConfigFactoryImpl.java:345) 

 org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.(AuthConfigFactoryImpl.java:68) 

 sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83) 

 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) 


 java.lang.reflect.Constructor.newInstance(Constructor.java:437)
 javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:76) 

 javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:67) 

 java.security.AccessController.doPrivileged(AccessController.java:696) 

 javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:66) 






Now THAT looks like a bug. Here is the code around that setFeature() call:

     Digester digester = new Digester();

     try {

digester.setFeature("http://apache.org/xml/features/allow-java-encodings;, 
true);

     digester.setValidating(true);
     digester.setNamespaceAware(true);
     } catch (Exception e) {
     throw new SecurityException(e);
     }

That digester.setFeature() call should be in its own try/catch block 
which issues a warning if a SAXException is thrown.


+1

And to reiterate, the very same JVM has no difficulty at all running 
Tomcat 7.0.93.


Something seems odd about that. There must be soe configuration 
difference between your 7.0.x environment and the 8.5.x environment you 
are testing.


Tomcat 7 doesn't have JASPIC support so you'll never see this issue in 
Tomcat 7.


Mark

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

Re: Minor doc bug, DSS should be DSA for certificate type?

[Mark Thomas]

Hi Mikael,

Thanks for spotting and reporting this. I've just fixed this typo in all 
the supported branches. The fix will be included in the September 
release round.


Kind regards,

Mark


On 04/08/2021 19:13, Mikael Sterner wrote:

In tomcat/webapps/docs/config/http.xml, it seems like the valid values for
the type attribute of the Certificate element should include DSA instead
of DSS, to match the enum used in the code?

https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java#L276

Yours,
Mikael

-
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