Re: [OT] Specifying a custom SSLSocketFactory for an LDAP connection

[Michael Osipov]

Am 2020-01-09 um 01:34 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

For anyone who has experience with LDAP in Java, I need a little help.
I have some code connecting to an LDAP server and doing all the
wonderful things I want to do, but I'd like to customize the
SSLSocket(Factory) that gets used by the connection to e.g. limit the
cipher suites, provide client certs, a custom trust store, etc.

I've done some Googling and it looks like I can do this:

 props.put("java.naming.ldap.factory.socket",
"com.example.CustomSSLSocketFactory" );

But that means that my CustomSSLSocketFatory class must have
hard-coded (or statically set) values for the various settings. Yuck.

The Tomcat code (for JNDIRealm) supports customization for STARTTLS,
and that appears to be able to use a custom SSLSocketFactory
*instance*. But it looks like that requires the use of STARTTLS which
I do not need. I'm working with LDAP-over-TLS.

Has anyone worked with Java's LDAP code enough to know if this is
possible and/or how to do it? I know I can fall-back to a hard-coded
or statically-configured SSLSocketFactory class but I'd prefer
something a little more explicitly-configurable.


Chris,

STARTTLS != LDAPS. STARTTLS is an LDAPv3 extension with its OID. The 
cients requests this in-band and the server, if supported, switches to it.


Please clarify why you are mixing a custom socket with STARTTLS?
Do you want to customize the socket or modify the STARTTLS negotiation?

Michael

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

Re: BLOCKING: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API

[Zahid Rahman]

You post has taken my interest and I  am going to experiment  and get a
good  understanding of  how this works. At the end of it I guarantee you I
will know all there is to know  about this.

On Thu, 9 Jan 2020, 05:25 Rathore, Rajendra,  wrote:

> Hi Zahid,
>
> How below link is going to help me out to know the root cause of the
> problem?
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Zahid Rahman 
> Sent: Thursday, January 9, 2020 10:53 AM
> To: Tomcat Users List 
> Subject: Re: BLOCKING: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> External email from: users-return-269283-rarathore=
> ptc@tomcat.apache.org
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.codota.com%2Fcode%2Fjava%2Fmethods%2Forg.apache.tomcat.util.net.NioBlockingSelector%2Fopendata=02%7C01%7Crarathore%40ptc.com%7C02a8c62f96c84b8ea63c08d794c40c25%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637141442053995621sdata=E666bJmF4N1wxBhm%2Fa%2BY29lvLlA32tQ%2B4F3lwBnLM2g%3Dreserved=0
>
>
> On Thu, 9 Jan 2020, 04:49 Rathore, Rajendra,  wrote:
>
> > Hi Team,
> >
> > If someone know how to check whether proper read/write operation done
> > or not or it will caused by network please let me know because it is
> > blocking for me.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rathore, Rajendra
> > Sent: Wednesday, January 8, 2020 11:43 AM
> > To: 'Tomcat Users List' 
> > Subject: RE: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > Can someone please help me to find out the root cause for below issue.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rathore, Rajendra
> > Sent: Tuesday, January 7, 2020 4:16 PM
> > To: Tomcat Users List 
> > Subject: RE: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > Hi Remy,
> >
> > Thanks for the reply,
> >
> > As you mention below points
> >
> > "There's a problem only if things are blocked improperly, for example
> > if the client is correctly reading the data and/or there's no network
> backlog.
> > Also the timeout configured on the connector must be respected by the
> > operation."
> >
> > 1. how can we check the network backlog or data read/write not working
> > properly, if any tool pls let us know 2. how can we set connector
> timeout.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rémy Maucherat 
> > Sent: Tuesday, January 7, 2020 4:11 PM
> > To: Tomcat Users List 
> > Subject: Re: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > External email from: users-return-269207-rarathore=
> > ptc@tomcat.apache.org
> >
> > On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra 
> > wrote:
> >
> > > Hi Rémy/ Christopher,
> > >
> > > It will stuck there for 10-15 minutes, so it will take time to load
> > > simple Web UI, there is no WebSocket call. I am giving you one of
> > > the sample where it will take 90% time in write operation, sometime
> > > it will
> > reach to 100%.
> > >
> > >
> > >  ||
> > >
> > > O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:133
> > > 1)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBa
> > > se
> > > .java:385)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketW
> > > ra
> > > pperBase.java:462)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapper
> > > Ba
> > > se.java:726)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(Ni
> > > oE
> > > ndpoint.java:1316)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.j
> > > av
> > > a:157)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSe
> > > le
> > > ctor.java:114)
> > > count=1667(%92.766)
> > >  ||
> > > |
> > > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWrite
> > > La
> > > tch(NioEndpoint.java:1160)
> > > 

Re: BLOCKING: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API

[Zahid Rahman]

If I was in your position I would use the code to experiment  and debug the
problem.

On Thu, 9 Jan 2020, 05:25 Rathore, Rajendra,  wrote:

> Hi Zahid,
>
> How below link is going to help me out to know the root cause of the
> problem?
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Zahid Rahman 
> Sent: Thursday, January 9, 2020 10:53 AM
> To: Tomcat Users List 
> Subject: Re: BLOCKING: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> External email from: users-return-269283-rarathore=
> ptc@tomcat.apache.org
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.codota.com%2Fcode%2Fjava%2Fmethods%2Forg.apache.tomcat.util.net.NioBlockingSelector%2Fopendata=02%7C01%7Crarathore%40ptc.com%7C02a8c62f96c84b8ea63c08d794c40c25%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637141442053995621sdata=E666bJmF4N1wxBhm%2Fa%2BY29lvLlA32tQ%2B4F3lwBnLM2g%3Dreserved=0
>
>
> On Thu, 9 Jan 2020, 04:49 Rathore, Rajendra,  wrote:
>
> > Hi Team,
> >
> > If someone know how to check whether proper read/write operation done
> > or not or it will caused by network please let me know because it is
> > blocking for me.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rathore, Rajendra
> > Sent: Wednesday, January 8, 2020 11:43 AM
> > To: 'Tomcat Users List' 
> > Subject: RE: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > Can someone please help me to find out the root cause for below issue.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rathore, Rajendra
> > Sent: Tuesday, January 7, 2020 4:16 PM
> > To: Tomcat Users List 
> > Subject: RE: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > Hi Remy,
> >
> > Thanks for the reply,
> >
> > As you mention below points
> >
> > "There's a problem only if things are blocked improperly, for example
> > if the client is correctly reading the data and/or there's no network
> backlog.
> > Also the timeout configured on the connector must be respected by the
> > operation."
> >
> > 1. how can we check the network backlog or data read/write not working
> > properly, if any tool pls let us know 2. how can we set connector
> timeout.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rémy Maucherat 
> > Sent: Tuesday, January 7, 2020 4:11 PM
> > To: Tomcat Users List 
> > Subject: Re: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > External email from: users-return-269207-rarathore=
> > ptc@tomcat.apache.org
> >
> > On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra 
> > wrote:
> >
> > > Hi Rémy/ Christopher,
> > >
> > > It will stuck there for 10-15 minutes, so it will take time to load
> > > simple Web UI, there is no WebSocket call. I am giving you one of
> > > the sample where it will take 90% time in write operation, sometime
> > > it will
> > reach to 100%.
> > >
> > >
> > >  ||
> > >
> > > O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:133
> > > 1)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBa
> > > se
> > > .java:385)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketW
> > > ra
> > > pperBase.java:462)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapper
> > > Ba
> > > se.java:726)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(Ni
> > > oE
> > > ndpoint.java:1316)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.j
> > > av
> > > a:157)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSe
> > > le
> > > ctor.java:114)
> > > count=1667(%92.766)
> > >  ||
> > > |
> > > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWrite
> > > La
> > > tch(NioEndpoint.java:1160)
> > > count=1667(%92.766)
> > >  ||
> > > 

Re: BLOCKING: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API

[Zahid Rahman]

https://youtu.be/VhSu1pRIEqQ
This will you understand . Also explains io blocking performance.


On Thu, 9 Jan 2020, 05:25 Rathore, Rajendra,  wrote:

> Hi Zahid,
>
> How below link is going to help me out to know the root cause of the
> problem?
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Zahid Rahman 
> Sent: Thursday, January 9, 2020 10:53 AM
> To: Tomcat Users List 
> Subject: Re: BLOCKING: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> External email from: users-return-269283-rarathore=
> ptc@tomcat.apache.org
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.codota.com%2Fcode%2Fjava%2Fmethods%2Forg.apache.tomcat.util.net.NioBlockingSelector%2Fopendata=02%7C01%7Crarathore%40ptc.com%7C02a8c62f96c84b8ea63c08d794c40c25%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637141442053995621sdata=E666bJmF4N1wxBhm%2Fa%2BY29lvLlA32tQ%2B4F3lwBnLM2g%3Dreserved=0
>
>
> On Thu, 9 Jan 2020, 04:49 Rathore, Rajendra,  wrote:
>
> > Hi Team,
> >
> > If someone know how to check whether proper read/write operation done
> > or not or it will caused by network please let me know because it is
> > blocking for me.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rathore, Rajendra
> > Sent: Wednesday, January 8, 2020 11:43 AM
> > To: 'Tomcat Users List' 
> > Subject: RE: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > Can someone please help me to find out the root cause for below issue.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rathore, Rajendra
> > Sent: Tuesday, January 7, 2020 4:16 PM
> > To: Tomcat Users List 
> > Subject: RE: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > Hi Remy,
> >
> > Thanks for the reply,
> >
> > As you mention below points
> >
> > "There's a problem only if things are blocked improperly, for example
> > if the client is correctly reading the data and/or there's no network
> backlog.
> > Also the timeout configured on the connector must be respected by the
> > operation."
> >
> > 1. how can we check the network backlog or data read/write not working
> > properly, if any tool pls let us know 2. how can we set connector
> timeout.
> >
> > Thanks and Regards,
> > Rajendra Rathore
> > 9922701491
> >
> > -Original Message-
> > From: Rémy Maucherat 
> > Sent: Tuesday, January 7, 2020 4:11 PM
> > To: Tomcat Users List 
> > Subject: Re: performance issue with Tomcat 8.5.35 in
> > org.apache.tomcat.util.net.NioBlockingSelector.write API
> >
> > External email from: users-return-269207-rarathore=
> > ptc@tomcat.apache.org
> >
> > On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra 
> > wrote:
> >
> > > Hi Rémy/ Christopher,
> > >
> > > It will stuck there for 10-15 minutes, so it will take time to load
> > > simple Web UI, there is no WebSocket call. I am giving you one of
> > > the sample where it will take 90% time in write operation, sometime
> > > it will
> > reach to 100%.
> > >
> > >
> > >  ||
> > >
> > > O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:133
> > > 1)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBa
> > > se
> > > .java:385)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketW
> > > ra
> > > pperBase.java:462)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapper
> > > Ba
> > > se.java:726)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(Ni
> > > oE
> > > ndpoint.java:1316)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.j
> > > av
> > > a:157)
> > > count=1669(%92.877)
> > >  ||
> > >
> > > O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSe
> > > le
> > > ctor.java:114)
> > > count=1667(%92.766)
> > >  ||
> > > |
> > > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWrite
> > > La
> > > tch(NioEndpoint.java:1160)
> > > count=1667(%92.766)
> > >  ||
> > >  

RE: BLOCKING: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API

[Rathore, Rajendra]

Hi Zahid,

How below link is going to help me out to know the root cause of the problem?

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Zahid Rahman  
Sent: Thursday, January 9, 2020 10:53 AM
To: Tomcat Users List 
Subject: Re: BLOCKING: performance issue with Tomcat 8.5.35 in 
org.apache.tomcat.util.net.NioBlockingSelector.write API

External email from: users-return-269283-rarathore=ptc@tomcat.apache.org

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.codota.com%2Fcode%2Fjava%2Fmethods%2Forg.apache.tomcat.util.net.NioBlockingSelector%2Fopendata=02%7C01%7Crarathore%40ptc.com%7C02a8c62f96c84b8ea63c08d794c40c25%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637141442053995621sdata=E666bJmF4N1wxBhm%2Fa%2BY29lvLlA32tQ%2B4F3lwBnLM2g%3Dreserved=0


On Thu, 9 Jan 2020, 04:49 Rathore, Rajendra,  wrote:

> Hi Team,
>
> If someone know how to check whether proper read/write operation done 
> or not or it will caused by network please let me know because it is 
> blocking for me.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rathore, Rajendra
> Sent: Wednesday, January 8, 2020 11:43 AM
> To: 'Tomcat Users List' 
> Subject: RE: performance issue with Tomcat 8.5.35 in 
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> Can someone please help me to find out the root cause for below issue.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rathore, Rajendra
> Sent: Tuesday, January 7, 2020 4:16 PM
> To: Tomcat Users List 
> Subject: RE: performance issue with Tomcat 8.5.35 in 
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> Hi Remy,
>
> Thanks for the reply,
>
> As you mention below points
>
> "There's a problem only if things are blocked improperly, for example 
> if the client is correctly reading the data and/or there's no network backlog.
> Also the timeout configured on the connector must be respected by the 
> operation."
>
> 1. how can we check the network backlog or data read/write not working 
> properly, if any tool pls let us know 2. how can we set connector timeout.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rémy Maucherat 
> Sent: Tuesday, January 7, 2020 4:11 PM
> To: Tomcat Users List 
> Subject: Re: performance issue with Tomcat 8.5.35 in 
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> External email from: users-return-269207-rarathore= 
> ptc@tomcat.apache.org
>
> On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra 
> wrote:
>
> > Hi Rémy/ Christopher,
> >
> > It will stuck there for 10-15 minutes, so it will take time to load 
> > simple Web UI, there is no WebSocket call. I am giving you one of 
> > the sample where it will take 90% time in write operation, sometime 
> > it will
> reach to 100%.
> >
> >
> >  ||
> >
> > O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:133
> > 1)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBa
> > se
> > .java:385)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketW
> > ra
> > pperBase.java:462)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapper
> > Ba
> > se.java:726)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(Ni
> > oE
> > ndpoint.java:1316)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.j
> > av
> > a:157)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSe
> > le
> > ctor.java:114)
> > count=1667(%92.766)
> >  ||
> > |
> > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWrite
> > La
> > tch(NioEndpoint.java:1160)
> > count=1667(%92.766)
> >  ||
> > |O-org.apache.tomcat.util.net
> .NioEndpoint$NioSocketWrapper.awaitLatch(NioEndpoint.java:1157)
> > count=1667(%92.766)
> >  ||
> > |
> > O-java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> > count=1667(%92.766)
> >
> >
> It's a normal blocking write, and the await does not consume CPU (it 

Re: BLOCKING: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API

[Zahid Rahman]

https://www.codota.com/code/java/methods/org.apache.tomcat.util.net.NioBlockingSelector/open


On Thu, 9 Jan 2020, 04:49 Rathore, Rajendra,  wrote:

> Hi Team,
>
> If someone know how to check whether proper read/write operation done or
> not or it will caused by network please let me know because it is blocking
> for me.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rathore, Rajendra
> Sent: Wednesday, January 8, 2020 11:43 AM
> To: 'Tomcat Users List' 
> Subject: RE: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> Can someone please help me to find out the root cause for below issue.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rathore, Rajendra
> Sent: Tuesday, January 7, 2020 4:16 PM
> To: Tomcat Users List 
> Subject: RE: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> Hi Remy,
>
> Thanks for the reply,
>
> As you mention below points
>
> "There's a problem only if things are blocked improperly, for example if
> the client is correctly reading the data and/or there's no network backlog.
> Also the timeout configured on the connector must be respected by the
> operation."
>
> 1. how can we check the network backlog or data read/write not working
> properly, if any tool pls let us know 2. how can we set connector timeout.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rémy Maucherat 
> Sent: Tuesday, January 7, 2020 4:11 PM
> To: Tomcat Users List 
> Subject: Re: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> External email from: users-return-269207-rarathore=
> ptc@tomcat.apache.org
>
> On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra 
> wrote:
>
> > Hi Rémy/ Christopher,
> >
> > It will stuck there for 10-15 minutes, so it will take time to load
> > simple Web UI, there is no WebSocket call. I am giving you one of the
> > sample where it will take 90% time in write operation, sometime it will
> reach to 100%.
> >
> >
> >  ||
> >
> > O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:1331)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase
> > .java:385)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketWra
> > pperBase.java:462)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBa
> > se.java:726)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioE
> > ndpoint.java:1316)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.jav
> > a:157)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSele
> > ctor.java:114)
> > count=1667(%92.766)
> >  ||
> > |
> > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWriteLa
> > tch(NioEndpoint.java:1160)
> > count=1667(%92.766)
> >  ||
> > |O-org.apache.tomcat.util.net
> .NioEndpoint$NioSocketWrapper.awaitLatch(NioEndpoint.java:1157)
> > count=1667(%92.766)
> >  ||
> > |
> > O-java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> > count=1667(%92.766)
> >
> >
> It's a normal blocking write, and the await does not consume CPU (it sits
> there however and a profiler will count that but it doesn't matter).
> There's a problem only if things are blocked improperly, for example if
> the client is correctly reading the data and/or there's no network backlog.
> Also the timeout configured on the connector must be respected by the
> operation.
>
> Rémy
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: BLOCKING: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API

[Zahid Rahman]

https://alvinalexander.com/java/jwarehouse/apache-tomcat-6.0.16/java/org/apache/tomcat/util/net/NioBlockingSelector.java.shtml

On Thu, 9 Jan 2020, 04:49 Rathore, Rajendra,  wrote:

> Hi Team,
>
> If someone know how to check whether proper read/write operation done or
> not or it will caused by network please let me know because it is blocking
> for me.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rathore, Rajendra
> Sent: Wednesday, January 8, 2020 11:43 AM
> To: 'Tomcat Users List' 
> Subject: RE: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> Can someone please help me to find out the root cause for below issue.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rathore, Rajendra
> Sent: Tuesday, January 7, 2020 4:16 PM
> To: Tomcat Users List 
> Subject: RE: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> Hi Remy,
>
> Thanks for the reply,
>
> As you mention below points
>
> "There's a problem only if things are blocked improperly, for example if
> the client is correctly reading the data and/or there's no network backlog.
> Also the timeout configured on the connector must be respected by the
> operation."
>
> 1. how can we check the network backlog or data read/write not working
> properly, if any tool pls let us know 2. how can we set connector timeout.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rémy Maucherat 
> Sent: Tuesday, January 7, 2020 4:11 PM
> To: Tomcat Users List 
> Subject: Re: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> External email from: users-return-269207-rarathore=
> ptc@tomcat.apache.org
>
> On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra 
> wrote:
>
> > Hi Rémy/ Christopher,
> >
> > It will stuck there for 10-15 minutes, so it will take time to load
> > simple Web UI, there is no WebSocket call. I am giving you one of the
> > sample where it will take 90% time in write operation, sometime it will
> reach to 100%.
> >
> >
> >  ||
> >
> > O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:1331)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase
> > .java:385)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketWra
> > pperBase.java:462)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBa
> > se.java:726)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioE
> > ndpoint.java:1316)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.jav
> > a:157)
> > count=1669(%92.877)
> >  ||
> >
> > O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSele
> > ctor.java:114)
> > count=1667(%92.766)
> >  ||
> > |
> > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWriteLa
> > tch(NioEndpoint.java:1160)
> > count=1667(%92.766)
> >  ||
> > |O-org.apache.tomcat.util.net
> .NioEndpoint$NioSocketWrapper.awaitLatch(NioEndpoint.java:1157)
> > count=1667(%92.766)
> >  ||
> > |
> > O-java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> > count=1667(%92.766)
> >
> >
> It's a normal blocking write, and the await does not consume CPU (it sits
> there however and a profiler will count that but it doesn't matter).
> There's a problem only if things are blocked improperly, for example if
> the client is correctly reading the data and/or there's no network backlog.
> Also the timeout configured on the connector must be respected by the
> operation.
>
> Rémy
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: JDBC connection pooling maxActive or MaxTotal

[Zahid Rahman]

Hey Dave B. ,

My question  from chris was for your benefit.
default configuration is not the same thing as vendor neutral.

chris wrote: > If you use both, you should be all set for whichever pool
you use at
runtime. DOH !

>If you look in your log file, you will notice that when Tomcat starts
>up it will give you a warning that one of the two configuration
> options failed to apply to whichever pool you are using. It is a
> warning, not an error, so you can ignore it. But it will show up in
> your log file every time.
YES IGNORE WARNINGS  BECAUSE we have not made a word connect
between generic and default and and vendor neutral and vendor specific so,
the developer  who wrote warning should be ignored , because he doesn't
know what he is doing.
but you AND chris do know  by shoving two APIs down the throat our beloved
poor little  tomcat.

>Note that you will have to specifically enable tomcat-pool,
so it's unlikely that the pooling-library in use will be a surprise. HUH!

If your are trying to use both APIs then  you should get chris to help you.
Sometimes terms such as generic and vendor neutral can be confusing.
Especially when chris is saying you will get a warning not an error WHEN
YOU USE BOTH.
I know you think he is being helpful,

but actually he has got his nickers in twist because he doesn't know what
those terms mean that he is himself using either.
If he did he would say to you why are you using vendor specific API and
Vendor neutral API at same time on the same application server.
You see what tomcat is really saying  you are confused by terminology just
like chris.


www.backbutton.co.uk
♡۶¯\_(ツ)_/¯ ♡۶
Marriage of loose and tight coupling
-> healthy applications
  ♡۶
Wot no  -classpath  --class-path  even ! -cp
javac   Garden/Vegetables/VineVegetable.java
java   Garden.Vegetables.VineVegetable


On Fri, 3 Jan 2020 at 23:50, zahid  wrote:

> chris,
>
>
> Is commons-dbcp-2.x   a Database pooling component for any container
> Jetty,Jboss tomcat   etc. ?
>
> is commons-dbcp-2.x a third option, separate option from the two pooling
> options [tomcat-pool and commons-pool] you mentioned ?
>
>
> On 03/01/2020 23:21, Dave Bothwell wrote:
> > Chris,
> >
> > That was very helpful.
> >
> > Thank you
> > Dave
> >
> >
> >
> > On Fri, Jan 3, 2020 at 5:29 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Dave,
> >>
> >> On 1/3/20 13:47, Dave Bothwell wrote:
> >>> I am using Tomcat 8.5.11 with JDBC connection pooling. Based on
> >>> the documentation it is clear that DBCP pooling has changed the
> >>> maxActive attribute to maxTotal. However it is unclear, based on
> >>> this document
> >>> https://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html, if JDBC
> >>> pooling has also changed maxActive to maxTotal.
> >>>
> >>> my question is which attribute should I be using?
> >> Are you asking about the difference between configurations for
> >> tomcat-pool and commons-pool?
> >>
> >> commons-pool (which is the default connection-pool in Tomcat) uses
> >> maxTotal.
> >>
> >> tomcat-pool (which is NOT the default connection-pool in Tomcat) uses
> >> maxActive.
> >>
> >>> Also, I am currently using both attributes maxActive and maxTotal
> >>> in my current server.xml file, which does not appear to be causing
> >>> any issues.
> >> If you use both, you should be all set for whichever pool you use at
> >> runtime. Note that you will have to specifically enable tomcat-pool,
> >> so it's unlikely that the pooling-library in use will be a surprise.
> >>
> >> If you look in your log file, you will notice that when Tomcat starts
> >> up it will give you a warning that one of the two configuration
> >> options failed to apply to whichever pool you are using. It is a
> >> warning, not an error, so you can ignore it. But it will show up in
> >> your log file every time.
> >>
> >> - -chris
> >> -BEGIN PGP SIGNATURE-
> >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >>
> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4PwFkACgkQHPApP6U8
> >> pFiEZRAAloB5RkBB0HrUvYfHd2DJbR5h2xt2WxaKbK6Rql/cdjVEC1dftrGSL9a7
> >> EvFkFl8juTA0oD/9mjGHKtN1MLgV+EFEu5hTppR+3wnkX/8djwp8L27AmtQ/xcT8
> >> /5vasZfn8Web/WqJIJGVF9BiEHoUCr4+M7G+PA8rvsskpIAZKux9NhbliDUYUwzi
> >> R7GsjNelBKixCa8Qy5Q7LqNcHN4RDygXKYsLZVoeoliEBaUOTWHeLoXAo6BQYsVW
> >> Tce5S3xePN6ZG3A5o5lT2bIjWKJp4qDu2CgPHJ0TQyAuey4rpkYmeI7uesmZhr6T
> >> XpwWnk8kYLG7ZCRR99KBF0lx67PQmtxZLoN4kDYQ77x7XUW5c/Qsv2PcOcvXmbzk
> >> iau8YsitqivEAtRh68XG4wrK37vGfkGNzTaSPzpZqgCIiJCotIV6mwQMjo97Ium/
> >> lxSTjLhLEkLNDegHk43wiW02AYfn+2FA0QBTiNX5OoWKu2YD/wrWnmljDwQKO6qL
> >> /ycYDnUCjkcmi0NZJil1kJtB2p8EKwy67W7PPRg2sf2VadFgifJlxO326UW1qK+e
> >> Gv8RjXgEHVOt2ydTa6sTFXT1fjcHaojVx5XgEK19UKNIUcMkyOUh6cZ5N/8d9UMn
> >> +jdZIx4hmxYshdoa4TO2JD6H8I087P8VNCL78RbeWTERUBBvvnc=
> >> =jSNi
> >> -END PGP SIGNATURE-
> >>
> >> 

RE: BLOCKING: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API

[Rathore, Rajendra]

Hi Team,

If someone know how to check whether proper read/write operation done or not or 
it will caused by network please let me know because it is blocking for me.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rathore, Rajendra 
Sent: Wednesday, January 8, 2020 11:43 AM
To: 'Tomcat Users List' 
Subject: RE: performance issue with Tomcat 8.5.35 in 
org.apache.tomcat.util.net.NioBlockingSelector.write API

Can someone please help me to find out the root cause for below issue.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rathore, Rajendra
Sent: Tuesday, January 7, 2020 4:16 PM
To: Tomcat Users List 
Subject: RE: performance issue with Tomcat 8.5.35 in 
org.apache.tomcat.util.net.NioBlockingSelector.write API

Hi Remy,

Thanks for the reply,

As you mention below points

"There's a problem only if things are blocked improperly, for example if the 
client is correctly reading the data and/or there's no network backlog.
Also the timeout configured on the connector must be respected by the 
operation."

1. how can we check the network backlog or data read/write not working 
properly, if any tool pls let us know 2. how can we set connector timeout.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rémy Maucherat 
Sent: Tuesday, January 7, 2020 4:11 PM
To: Tomcat Users List 
Subject: Re: performance issue with Tomcat 8.5.35 in 
org.apache.tomcat.util.net.NioBlockingSelector.write API

External email from: users-return-269207-rarathore=ptc@tomcat.apache.org

On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra  wrote:

> Hi Rémy/ Christopher,
>
> It will stuck there for 10-15 minutes, so it will take time to load 
> simple Web UI, there is no WebSocket call. I am giving you one of the 
> sample where it will take 90% time in write operation, sometime it will reach 
> to 100%.
>
>
>  ||
>
> O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:1331)
> count=1669(%92.877)
>  ||
>   
> O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase
> .java:385)
> count=1669(%92.877)
>  ||
> 
> O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketWra
> pperBase.java:462)
> count=1669(%92.877)
>  ||
>   
> O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBa
> se.java:726)
> count=1669(%92.877)
>  ||
> 
> O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioE
> ndpoint.java:1316)
> count=1669(%92.877)
>  ||
>   
> O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.jav
> a:157)
> count=1669(%92.877)
>  ||
> 
> O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSele
> ctor.java:114)
> count=1667(%92.766)
>  ||
> |
> O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWriteLa
> tch(NioEndpoint.java:1160)
> count=1667(%92.766)
>  ||
> |
> O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitLatch(NioEndpoint.java:1157)
> count=1667(%92.766)
>  ||
> |
> O-java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> count=1667(%92.766)
>
>
It's a normal blocking write, and the await does not consume CPU (it sits there 
however and a profiler will count that but it doesn't matter).
There's a problem only if things are blocked improperly, for example if the 
client is correctly reading the data and/or there's no network backlog.
Also the timeout configured on the connector must be respected by the operation.

Rémy

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

Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?

[Zahid Rahman]

The second technique is to use the  *.nix command.
The result is as below
diff a.out b.out I draw your attention to third line in FILE b.out

5,7c5,7
< SSLEnabled="true" scheme="https" secure="true"
< keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
< clientAuth="false" sslProtocol="TLS" />
---
> SSLEnabled="true" scheme="https" secure="true">
>  certificateVerification="none" sslProtocol="TLS">


*cat a.out*


*cat b.out*




www.backbutton.co.uk
♡۶¯\_(ツ)_/¯ ♡۶
Marriage of loose and tight coupling
-> healthy applications
  ♡۶
java -cp classpath class-path


On Wed, 8 Jan 2020 at 23:59, James H. H. Lampert 
wrote:

> I wrote:
> > Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt"
> > and ".key" files directly, instead of the Java Keystore file?
>
> On 12/30/19 1:41 PM, Peter Kreuser wrote:
> > Correct!
>
> I tried an experiment this afternoon:
>
> I made a copy of the existing server.xml file, and I changed the active
> connector from this (keystore file and alias redacted for privacy,
> ciphers and compressibleMimeTypes clauses redacted because they're quite
> long, and not relevant here):
> >  protocol="org.apache.coyote.http11.Http11NioProtocol"
> >  compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> >  compressableMimeType="[REDACTED]"
> >  maxThreads="1000" socket.appReadBufSize="1024"
> socket.appWriteBufSize="1024" bufferSize="1024"
> >  SSLEnabled="true" scheme="https" secure="true"
> >  keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
> >  clientAuth="false" sslProtocol="TLS" />
>
> to this:
> >  protocol="org.apache.coyote.http11.Http11NioProtocol"
> >  compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> >  compressableMimeType="[REDACTED]"
> >  maxThreads="1000" socket.appReadBufSize="1024"
> socket.appWriteBufSize="1024" bufferSize="1024"
> >  SSLEnabled="true" scheme="https" secure="true">
> >>certificateVerification="none" sslProtocol="TLS">
> >  certificateKeyFile="[REDACTED].key"
> >  certificateChainFile="[REDACTED].ca.crt" />
> >   
> > 
>
> and restarted Tomcat, and it failed to open the port, producing this in
> catalina.out:
> > 08-Jan-2020 23:14:09.026 SEVERE [main]
> org.apache.catalina.core.StandardService.initInternal Failed to initialize
> connector [Connector[HTTP/1.1-8443]]
> >  org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> > at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> > 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:309)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> > Caused by: org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> > at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > ... 12 more
> > Caused by: java.lang.IllegalArgumentException: Cannot store
> non-PrivateKeys
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
> > at org.apache.tomcat.util.net
> .NioEndpoint.bind(NioEndpoint.java:244)
> > at org.apache.tomcat.util.net
> .AbstractEndpoint.init(AbstractEndpoint.java:1105)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
> > at
> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
> > at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
> > at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
> > ... 13 more
> > Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
> > at
> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
> > at
> 

Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?

[Zahid Rahman]

http://tomcat.10.x6.nabble.com/Can-t-Get-SSL-to-Work-in-8-5-td5071245.html

On Thu, 9 Jan 2020, 03:01 Zahid Rahman,  wrote:

>
> https://confluence.atlassian.com/confkb/ssl-connector-fails-to-initialize-during-tomcat-startup-646251490.html
>
> On Thu, 9 Jan 2020, 02:44 Zahid Rahman,  wrote:
>
>>
>> https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
>>
>> I went to college and studied IT before finding a job. My teacher
>> explained to me that you should always look at the first error and ignore
>> the rest.
>>
>>
>> First error.
>> 08-Jan-2020 23:14:09.026 SEVERE [main] 
>> org.apache.catalina.core.StandardService.initInternal
>> Failed to initialize connector [Connector[HTTP/1.1-8443]]
>>
>>
>> Once that has been addressed  then either the remaining  will disappear
>> or address the second error which will then be the first error.
>>
>>
>>
>>
>>
>>
>> On Wed, 8 Jan 2020, 23:59 James H. H. Lampert, 
>> wrote:
>>
>>> I wrote:
>>> > Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt"
>>> > and ".key" files directly, instead of the Java Keystore file?
>>>
>>> On 12/30/19 1:41 PM, Peter Kreuser wrote:
>>> > Correct!
>>>
>>> I tried an experiment this afternoon:
>>>
>>> I made a copy of the existing server.xml file, and I changed the active
>>> connector from this (keystore file and alias redacted for privacy,
>>> ciphers and compressibleMimeTypes clauses redacted because they're quite
>>> long, and not relevant here):
>>> > >> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> >  compression="on" compressionMinSize="2048"
>>> noCompressionUserAgents="gozilla, traviata"
>>> >  compressableMimeType="[REDACTED]"
>>> >  maxThreads="1000" socket.appReadBufSize="1024"
>>> socket.appWriteBufSize="1024" bufferSize="1024"
>>> >  SSLEnabled="true" scheme="https" secure="true"
>>> >  keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
>>> >  clientAuth="false" sslProtocol="TLS" />
>>>
>>> to this:
>>> > >> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> >  compression="on" compressionMinSize="2048"
>>> noCompressionUserAgents="gozilla, traviata"
>>> >  compressableMimeType="[REDACTED]"
>>> >  maxThreads="1000" socket.appReadBufSize="1024"
>>> socket.appWriteBufSize="1024" bufferSize="1024"
>>> >  SSLEnabled="true" scheme="https" secure="true">
>>> >   >> >certificateVerification="none" sslProtocol="TLS">
>>> > >> certificateKeyFile="[REDACTED].key"
>>> >  certificateChainFile="[REDACTED].ca.crt" />
>>> >   
>>> > 
>>>
>>> and restarted Tomcat, and it failed to open the port, producing this in
>>> catalina.out:
>>> > 08-Jan-2020 23:14:09.026 SEVERE [main]
>>> org.apache.catalina.core.StandardService.initInternal Failed to initialize
>>> connector [Connector[HTTP/1.1-8443]]
>>> >  org.apache.catalina.LifecycleException: Failed to initialize
>>> component [Connector[HTTP/1.1-8443]]
>>> > at
>>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
>>> > at
>>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
>>> > at
>>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>> > at
>>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>>> > at
>>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
>>> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
>>> > 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:309)
>>> > at
>>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
>>> > Caused by: org.apache.catalina.LifecycleException: Protocol handler
>>> initialization failed
>>> > at
>>> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
>>> > at
>>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>> > ... 12 more
>>> > Caused by: java.lang.IllegalArgumentException: Cannot store
>>> non-PrivateKeys
>>> > at org.apache.tomcat.util.net
>>> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
>>> > at org.apache.tomcat.util.net
>>> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
>>> > at org.apache.tomcat.util.net
>>> .NioEndpoint.bind(NioEndpoint.java:244)
>>> > at org.apache.tomcat.util.net
>>> .AbstractEndpoint.init(AbstractEndpoint.java:1105)
>>> > at org.apache.tomcat.util.net
>>> 

Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?

[Zahid Rahman]

https://confluence.atlassian.com/confkb/ssl-connector-fails-to-initialize-during-tomcat-startup-646251490.html

On Thu, 9 Jan 2020, 02:44 Zahid Rahman,  wrote:

>
> https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
>
> I went to college and studied IT before finding a job. My teacher
> explained to me that you should always look at the first error and ignore
> the rest.
>
>
> First error.
> 08-Jan-2020 23:14:09.026 SEVERE [main] 
> org.apache.catalina.core.StandardService.initInternal
> Failed to initialize connector [Connector[HTTP/1.1-8443]]
>
>
> Once that has been addressed  then either the remaining  will disappear or
> address the second error which will then be the first error.
>
>
>
>
>
>
> On Wed, 8 Jan 2020, 23:59 James H. H. Lampert, 
> wrote:
>
>> I wrote:
>> > Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt"
>> > and ".key" files directly, instead of the Java Keystore file?
>>
>> On 12/30/19 1:41 PM, Peter Kreuser wrote:
>> > Correct!
>>
>> I tried an experiment this afternoon:
>>
>> I made a copy of the existing server.xml file, and I changed the active
>> connector from this (keystore file and alias redacted for privacy,
>> ciphers and compressibleMimeTypes clauses redacted because they're quite
>> long, and not relevant here):
>> > > protocol="org.apache.coyote.http11.Http11NioProtocol"
>> >  compression="on" compressionMinSize="2048"
>> noCompressionUserAgents="gozilla, traviata"
>> >  compressableMimeType="[REDACTED]"
>> >  maxThreads="1000" socket.appReadBufSize="1024"
>> socket.appWriteBufSize="1024" bufferSize="1024"
>> >  SSLEnabled="true" scheme="https" secure="true"
>> >  keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
>> >  clientAuth="false" sslProtocol="TLS" />
>>
>> to this:
>> > > protocol="org.apache.coyote.http11.Http11NioProtocol"
>> >  compression="on" compressionMinSize="2048"
>> noCompressionUserAgents="gozilla, traviata"
>> >  compressableMimeType="[REDACTED]"
>> >  maxThreads="1000" socket.appReadBufSize="1024"
>> socket.appWriteBufSize="1024" bufferSize="1024"
>> >  SSLEnabled="true" scheme="https" secure="true">
>> >   > >certificateVerification="none" sslProtocol="TLS">
>> > > certificateKeyFile="[REDACTED].key"
>> >  certificateChainFile="[REDACTED].ca.crt" />
>> >   
>> > 
>>
>> and restarted Tomcat, and it failed to open the port, producing this in
>> catalina.out:
>> > 08-Jan-2020 23:14:09.026 SEVERE [main]
>> org.apache.catalina.core.StandardService.initInternal Failed to initialize
>> connector [Connector[HTTP/1.1-8443]]
>> >  org.apache.catalina.LifecycleException: Failed to initialize component
>> [Connector[HTTP/1.1-8443]]
>> > at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
>> > at
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
>> > at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> > at
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>> > at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
>> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
>> > 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:309)
>> > at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
>> > Caused by: org.apache.catalina.LifecycleException: Protocol handler
>> initialization failed
>> > at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
>> > at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> > ... 12 more
>> > Caused by: java.lang.IllegalArgumentException: Cannot store
>> non-PrivateKeys
>> > at org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
>> > at org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
>> > at org.apache.tomcat.util.net
>> .NioEndpoint.bind(NioEndpoint.java:244)
>> > at org.apache.tomcat.util.net
>> .AbstractEndpoint.init(AbstractEndpoint.java:1105)
>> > at org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
>> > at
>> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
>> > at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
>> > at
>> 

Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?

[Zahid Rahman]

https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in

I went to college and studied IT before finding a job. My teacher explained
to me that you should always look at the first error and ignore the rest.


First error.
08-Jan-2020 23:14:09.026 SEVERE [main]
org.apache.catalina.core.StandardService.initInternal
Failed to initialize connector [Connector[HTTP/1.1-8443]]


Once that has been addressed  then either the remaining  will disappear or
address the second error which will then be the first error.






On Wed, 8 Jan 2020, 23:59 James H. H. Lampert, 
wrote:

> I wrote:
> > Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt"
> > and ".key" files directly, instead of the Java Keystore file?
>
> On 12/30/19 1:41 PM, Peter Kreuser wrote:
> > Correct!
>
> I tried an experiment this afternoon:
>
> I made a copy of the existing server.xml file, and I changed the active
> connector from this (keystore file and alias redacted for privacy,
> ciphers and compressibleMimeTypes clauses redacted because they're quite
> long, and not relevant here):
> >  protocol="org.apache.coyote.http11.Http11NioProtocol"
> >  compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> >  compressableMimeType="[REDACTED]"
> >  maxThreads="1000" socket.appReadBufSize="1024"
> socket.appWriteBufSize="1024" bufferSize="1024"
> >  SSLEnabled="true" scheme="https" secure="true"
> >  keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
> >  clientAuth="false" sslProtocol="TLS" />
>
> to this:
> >  protocol="org.apache.coyote.http11.Http11NioProtocol"
> >  compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> >  compressableMimeType="[REDACTED]"
> >  maxThreads="1000" socket.appReadBufSize="1024"
> socket.appWriteBufSize="1024" bufferSize="1024"
> >  SSLEnabled="true" scheme="https" secure="true">
> >>certificateVerification="none" sslProtocol="TLS">
> >  certificateKeyFile="[REDACTED].key"
> >  certificateChainFile="[REDACTED].ca.crt" />
> >   
> > 
>
> and restarted Tomcat, and it failed to open the port, producing this in
> catalina.out:
> > 08-Jan-2020 23:14:09.026 SEVERE [main]
> org.apache.catalina.core.StandardService.initInternal Failed to initialize
> connector [Connector[HTTP/1.1-8443]]
> >  org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> > at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> > 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:309)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> > Caused by: org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> > at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > ... 12 more
> > Caused by: java.lang.IllegalArgumentException: Cannot store
> non-PrivateKeys
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
> > at org.apache.tomcat.util.net
> .NioEndpoint.bind(NioEndpoint.java:244)
> > at org.apache.tomcat.util.net
> .AbstractEndpoint.init(AbstractEndpoint.java:1105)
> > at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
> > at
> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
> > at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
> > at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
> > ... 13 more
> > Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
> > at
> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
> > at
> 

[OT] Specifying a custom SSLSocketFactory for an LDAP connection

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

For anyone who has experience with LDAP in Java, I need a little help.
I have some code connecting to an LDAP server and doing all the
wonderful things I want to do, but I'd like to customize the
SSLSocket(Factory) that gets used by the connection to e.g. limit the
cipher suites, provide client certs, a custom trust store, etc.

I've done some Googling and it looks like I can do this:

props.put("java.naming.ldap.factory.socket",
   "com.example.CustomSSLSocketFactory" );

But that means that my CustomSSLSocketFatory class must have
hard-coded (or statically set) values for the various settings. Yuck.

The Tomcat code (for JNDIRealm) supports customization for STARTTLS,
and that appears to be able to use a custom SSLSocketFactory
*instance*. But it looks like that requires the use of STARTTLS which
I do not need. I'm working with LDAP-over-TLS.

Has anyone worked with Java's LDAP code enough to know if this is
possible and/or how to do it? I know I can fall-back to a hard-coded
or statically-configured SSLSocketFactory class but I'd prefer
something a little more explicitly-configurable.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4WdQoACgkQHPApP6U8
pFge3BAAn/wXpFFpXj8S8ZBnfxE4+zDoJvN673IstXSyaIqw60Bb+VzVMhZVvs2+
JsfwaRCeHmNAqy6J81iGra4ulZipaQD39WZJjXlh6+3+v4vgc+Ow6AwnlkJ5xpBL
mhk7xf8rYHebTUOflCZzpVw5jw7u5rGbVySpobxce0HqIHdAslBWq8ST5z1jHLv7
NUqfJT7klhsHQZT3mUP/t9/ibA+cj06IJsrO86lYqy/00Q3PRPIm3yO3xlYacbl0
UboEaUpnfidwVqc/oLSVLt/fpJ0UqqiNYvk6YFIY4/6jbbxJGFzcCtvZw5XVlnpm
IAHU09B5Oc3rYP3/7fqS5NqkqlY+lp4AalPQTc4olOpGJ7qPOgcSoBBmaJ/VlMMz
Yzjw1Aa+H4rLlf2W/NRGs+1fVio97NUXuNHhvKKszr2lEdqh0mMg5DTS53ao0HRL
1Qo8HZ58XUJrQGI8ty2a5PZni5nek013b/AN5Ze+0KMAHPdKP4M2O5YyOUjkGa3O
++RDbOx6Gb37j0oaI5J4dmmHO/2BnoQHDXE4shhYJi9Bh48bfeyqmUEJ2Q1CfdWu
mqc8j6GOkvTvZqxHV2qVBmNhF2kfm5M0iNR+td08eKdy3Yr3izd6389lJvcKhVHJ
19yYYx0/e+ww6TPUQY6jfaNVbrofrdBpu0GirD/lMMM6dN+1/cg=
=n5Es
-END PGP SIGNATURE-

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

Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?

[James H. H. Lampert]

I wrote:
Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt" 
and ".key" files directly, instead of the Java Keystore file?


On 12/30/19 1:41 PM, Peter Kreuser wrote:

Correct!


I tried an experiment this afternoon:

I made a copy of the existing server.xml file, and I changed the active
connector from this (keystore file and alias redacted for privacy,
ciphers and compressibleMimeTypes clauses redacted because they're quite 
long, and not relevant here):




to this:


  

  



and restarted Tomcat, and it failed to open the port, producing this in 
catalina.out:

08-Jan-2020 23:14:09.026 SEVERE [main] 
org.apache.catalina.core.StandardService.initInternal Failed to initialize 
connector [Connector[HTTP/1.1-8443]]
 org.apache.catalina.LifecycleException: Failed to initialize component 
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
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:309)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
Caused by: org.apache.catalina.LifecycleException: Protocol handler 
initialization failed
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
Caused by: java.lang.IllegalArgumentException: Cannot store non-PrivateKeys
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1105)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
... 13 more
Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
at 
sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
at 
sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
at 
sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
at 
sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
at 
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
at 
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
... 20 more


Can anybody explain what I did wrong? These are fully-qualified paths to 
the certificate, chain, and key files. [REDACTED].ca.crt contains a 
certificate chain; [REDACTED].cer contains a certificate, and 
[REDACTED].key contains a private key, and they all work in Apache 
httpd, on the same box.


--
JHHL

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

Re: Dates on Linux vs. Windows - Resolved

[Jerry Malcolm]

On 1/8/2020 4:47 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Johan,

On 1/8/20 3:28 AM, Johan Compagner wrote:

So you moved once the database to a different timezone (that had
say that 6 hour difference) then the behavior is correct...

Its very weird but that is default behavior of the normal datetime
columns that are created if you move stuff around the database
somehow remembers at what timezone the datetime was inserted and
will convert the millis accordingly..

The database doesn't store timezone information. It just has a
DATETIME which is zoneless. If you INSERT .. VALUES ('2020-01-08
17:45:00') then that's what gets written. It doesn't do any
translation. That's why it's important for the client to understand
the context of all datetime values and adjust accordingly.


Its the same as if you have different clients connecting to the
same database over different timezones they will al see the same
date as a string (so the formatted date) instead of really having
the same millis after 1970 utc.

Correct.


I always find this very very weird. But i guess this is the
difference between database types "timestamp with timezone" and
"timestamp"

So moving the database or moving the client (app server) with
existing data is very tricky.

If the client always adjusts both ways, there shouldn't be any
problems. Ignorant clients will always cause confusion.

- -chris


On Wed, 8 Jan 2020 at 06:05, Jerry Malcolm 
wrote:


First of all, a big thank you to everyone who responded to this
one.  I doubt I'd have figured it out for days without your
guidance and help.

And the winner is the JVM timezone.  But the problem was NOT
that the JVM wasn't set to US Central time.  The problem was that
it WAS set to US Central, apparently inherited from the Linux OS
TZ.  There was no parameter on the tomcat java command that set
the timezone.  So I added one and set it to America/Chicago.  No
change.  But since it appeared we were already double-dipping and
converting from GMT to central twice (i.e. subtracting an
additional 6 hours), I figured ok tell the JVM to stay in GMT
and not do any conversions.  So now, the database returns Central
time dates and times, but JVM no longer thinks it needs to
convert again to 'more central'.

This is about as convoluted and ugly as it gets.  And I don't
make any claims of thinking I can give a rational explanation for
why it works this way.  But it's on to fight a battle on another
hill now.

Just to summarize for anybody who comes along with a similar
problem I original set the timezone of mySQL RDS instance to
Central time when I created it months back (unchangable after
it's set).  I set my Linux timezone to Central as well in order
to make my log files have entries with the correct timestamps.
But as I described earlier, changing the OS timezone made the JVM
also go to Central as well.  But the JVM apparently assumed the
database was in GMT so it subtracted 6 more hours off the
already-central time from the db.  I guess the real error was not
initially leaving the MySQL RDS in GMT.  But since that's not
changeable without recreating a whole new RDS instance, the next
option is what I did with the jvm.   Makes total sense, right???
:-)

Thanks again.

Jerry

Chris, I really want to get this right.  I understand that enough wrongs 
in even numbers may result in a 'right'.  But I'd really like to 
understand this.  So bear with me on this.  It makes sense that the 
database doesn't store timezone info in data fields unless the tz is 
part of the data itself.  But then what is the significance of the RDS 
timezone and/or setting mySQL timezone values if the database is zoneless.


But whether or not tz info is present, there is an assumed timezone for 
all date/datetime/etc fields written to the database.  In my code, for 
years, when I write a date, datetime, etc field, it's always been the 
date/datetime of central timezone.  Until now I haven't had a need to 
have clients in other timezones.  So it has never been a problem.  So I 
guess I could say my database is 'central time' since years worth of 
date and datetime fields were written as the date/datetime values of 
central tz.  There is no reasonable  way to alter that massive amount of 
data now.  But just to educate me, it appears that to be really 
timezone-enabled, I should convert any date/datetime I write to the 
database into GMT, and then declare the database to be a GMT database.  
Once that is done, I can now tell the jvm to use central time, and it 
will re-convert the stored GMT back to central (or whatever tz the 
server is declared to be).   Am I on the right track?


And the final question/assumption... it appears that the jvm on Windows 
does not inherit the OS timezone as it does in Linux.  My code on 
Windows does not convert db values to central time even though windows 
is set to central.

Re: [OT] Re: Maven Warning. Ubuntu Users

[Mark Thomas]

This is off-topic.

As per my previous email in this thread, please stop this behaviour and
keep your posts on-topic.

Mark


On 08/01/2020 19:51, Zahid Rahman wrote:
> Another example of using  maven 2015 version and the impact of unknown
> warning  by MAVEN can have on application development across the Globe.
> Let'sEncrypt guy (Shultz) dismissed as unimportant.
> 
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.3.9/
> 
> 
> Mary Zheng
> Posted by: Mary Zheng
>  in Core Java
>  December 27th, 2019
>  0
> 
>  433 Views
> 
> She works as a senior Software Engineer in the telecommunications sector
> where she acts as a leader and works with others to design, implement, and
> monitor the software solution.
> 
> https://examples.javacodegeeks.com/multiple-inheritance-java-example/
> 
> 2. Technologies Used
> 
> The example code in this article was built and run using:
> 
>- Java 11
>- Maven 3.3.9
>- Eclipse Oxygen
>- Junit 4.12
> 
> 
> On Wed, 8 Jan 2020, 12:36 zahid,  wrote:
> 
>> ok
>>
>> Thank you.
>>
>> www.backbutton.co.uk
>> ♡۶¯\_(ツ)_/¯ ♡۶
>> Marriage of loose and tight coupling
>> -> healthy applications
>>♡۶
>> javac Garden/Vegetables/VineVegetable.java
>> java   Garden.Vegetables.VineVegetable
>> What No!  -classpath -class-path even -cp!
>>
>> On 08/01/2020 09:48, Mark Thomas wrote:
>>> On 08/01/2020 08:41, Peter Kreuser wrote:
 Zahid,

 you‘re talking to one of the most respected members of the community
>>> like this?
>>>
>>> All participants in Apache communities are expected to follow the code
>>> of conduct:
>>>
>>> http://www.apache.org/foundation/policies/conduct.html
>>>
>>> This is irrespective of whether you are replying to a message from one
>>> of the founders of the ASF or a first time contributor.
>>>
 STFU or leave.
>>> While I understand the frustration, statements like the above are only
>>> going to add heat to an already heated situation. Please try and refrain
>>> from such responses.
>>>
 This calls for an ban!
>>> As one of the list moderators, that thought crossed my mind as soon as I
>>> saw the off-topic Linux vs Windows post. I hoped that it was a one-off.
>>> When it became clear that it wasn't, I posted my request to keep threads
>>> on topic. I hoped that would be sufficient. Clearly it wasn't.
>>>
>>> I would urge everyone not to reply to off-topic posts.
>>>
>>> If you want to bring a post you find problematic to the attention of the
>>> moderators then please feel free to mail the list moderators at:
>>> users-ow...@tomcat.apache.org
>>>
> Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
>
> 
>> A version of what?
> MAVEN
> MAVEN
> MAVEN
>
> In light of this video https://youtu.be/idViw4anA6E
> Of http.
>
> You and your let's encrypt must be the longest troll on this line.
>>> No.
>>>
>>> How to configure Apache Tomcat with keys and certificates provided by
>>> Let's Encrypt is entirely on-topic for the Apache Tomcat users' mailing
>>> list.
>>>
> Take your wares and peddle them somewhere else carpet beggar.
>>> Zahid,
>>>
>>> Please stop this now.
>>>
>>> Please keep your posts to this list on topic.
>>>
>>> Please ensure that any posts are consistent with the Apache Code of
>> Conduct.
>>>
>>> If you continue to disrupt this community with off-topic posts and/or
>>> behaviour that is inconsistent with the Apache Code of Conduct then the
>>> list moderators will either require all your posts to be moderated or
>>> simply block you from posting at all.
>>>
>>> Mark
>>> wearing his list moderator hat
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>> --
>> www.backbutton.co.uk
>> ♡۶¯\_(ツ)_/¯ ♡۶
>> Marriage of loose and tight coupling
>> -> healthy applications
>>♡۶
>> java -cp classpath class-path
>>
>>
> 


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

Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 1/8/20 12:35 PM, James H. H. Lampert wrote:
> On 1/8/20 5:18 AM, Christopher Schultz wrote: . . .
>> Now the URL line becomes (for me, using a management port):
>> 
>> http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtoco
lHa
>>
>> 
ndler,port%3D8215=reloadSslHostConfigs
> . . .
>> Have you configured any  elements, or are you
>> using the old-style configuration like:
>> 
>> 
> 
> I just have a connector definition in server.xml, almost exactly
> the same as I've been using in Tomcat 7 installations. I don't
> think prior to this discussion, I'd even *heard* of
> "SSLHostConfig."
> 
>> You may need to change your connector configuration to use
>> nested  elements if it's not that way already.
>> 
>> Try invoking the "findSslHostConfigs" operation to see if it 
>> completes. That will at least tell you if you have your
>> objectname correct.
>> 
>> Like this:
>> 
>> $ curl -k -u "test:test" 
>> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto
col
>>
>> 
Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs"
> 
> This gave me a stacktrace:
>> curl -k -u "test:test" 
>> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto
colHandler,port%3D8443,ad
>>
>>
>> 
dress%3D127.0.0.1=findSslHostConfigs"
> 
> But omitting the address parameter, as in your own test, gave me
> this:
>> curl -k -u test:test 
>> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto
colHandler,port%3D8443&
>>
>>
>> 
op=findSslHostConfigs"
>> OK - Operation findSslHostConfigs returned: 
>> org.apache.tomcat.util.net.SSLHostConfig@1a9b80c2
> 
>> curl -k -u test:test 
>> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto
colHandler,port%3D8443&
>>
>>
>> 
op=reloadSslHostConfigs"
>> OK - Operation reloadSslHostConfigs without return value
> 
> And I just now confirmed that the latter did indeed reload the
> keystore when I swapped between the regular keystore and a
> self-signed one, even though I just have the old-style connector
> definition.
> 
> So apparently, it was the "address" parameter that was killing me. 
> Interesting.
> 
> The idea was to put the Tomcat server on the same certificate and 
> private key files as the httpd server on the same EC2 box. Do I
> need this newfangled "SSLHostConfig" for that?
> 
> At any rate, I think we have another breakthrough here, but at the
> same time, I think I also need to disable the "test" user, and get
> back to another project I have going, at least for now.

Glad you got it working.

The next releases of Tomcat will give you a better error message from
JMXProxyServlet in cases like these. No more NPEs.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4WXLQACgkQHPApP6U8
pFgVRw/+O3zCPWww0FgzSp46NIkqh50j6bGwu95N9mM9r43DNHZ4XOBNoZ/04khc
0otFGF0xnCvXX/3s3RPvYHeV+ZggMhtb8Sd/IZjHAWArVPC1+iXOlydIniaqXeJ5
jEvF4fu67FVLIFRz625gHVGrERwIfUM4om7qo3KYaOOA8+KQY/pCEZGPqMV90FRy
Dx2n2ifLEwSFV9lq1yDaqelhW2YgvqaAaoocRoRBaEBnWtgMl+vAtTpWTCFk5bwM
iH2mgdc9DIUawjLpIjuCsXb7AlAI4GrB4ATSpMIcvHNkyWSubxvm9PpdYSbwR4vQ
N5QJGOdYbpNdY9kylyKi5AteS0IpCBD+iXwTn5QJIxwarIlluIj9pGhZbibumg9M
JhwzLpyK90OF6lFlNNWLuc5frC8R2rJFEWCPwGPwml7V8RCzNi8YzTi13UyyaMJi
1wa6uyICKGJIWexyz5sLG/Juo9wDqZzojN4Bxl2AxMWHDpN6M/fXMeesB3B5ScKg
kBoHf+1SZTjD5j61QarkyUgfskgG7oH+PaZkQNudggZ/QghuuSmSHjGcIECbRaiC
oSWdlv2acRs5eExXu5PedLrQO66HoecMlOA1Sl/B5gajlZCerhTEBqLq6ebwIefF
U4sQsBwmwfwo6U1wd0377nTGj/+zWV31BqXfAP3cZ/duyo9g9kA=
=oXVx
-END PGP SIGNATURE-

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

Re: Dates on Linux vs. Windows - Resolved

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Johan,

On 1/8/20 3:28 AM, Johan Compagner wrote:
> So you moved once the database to a different timezone (that had
> say that 6 hour difference) then the behavior is correct...
> 
> Its very weird but that is default behavior of the normal datetime
> columns that are created if you move stuff around the database
> somehow remembers at what timezone the datetime was inserted and
> will convert the millis accordingly..

The database doesn't store timezone information. It just has a
DATETIME which is zoneless. If you INSERT .. VALUES ('2020-01-08
17:45:00') then that's what gets written. It doesn't do any
translation. That's why it's important for the client to understand
the context of all datetime values and adjust accordingly.

> Its the same as if you have different clients connecting to the
> same database over different timezones they will al see the same
> date as a string (so the formatted date) instead of really having
> the same millis after 1970 utc.

Correct.

> I always find this very very weird. But i guess this is the
> difference between database types "timestamp with timezone" and
> "timestamp"
> 
> So moving the database or moving the client (app server) with
> existing data is very tricky.

If the client always adjusts both ways, there shouldn't be any
problems. Ignorant clients will always cause confusion.

- -chris

> On Wed, 8 Jan 2020 at 06:05, Jerry Malcolm 
> wrote:
> 
>> First of all, a big thank you to everyone who responded to this
>> one.  I doubt I'd have figured it out for days without your
>> guidance and help.
>> 
>> And the winner is the JVM timezone.  But the problem was NOT
>> that the JVM wasn't set to US Central time.  The problem was that
>> it WAS set to US Central, apparently inherited from the Linux OS
>> TZ.  There was no parameter on the tomcat java command that set
>> the timezone.  So I added one and set it to America/Chicago.  No
>> change.  But since it appeared we were already double-dipping and
>> converting from GMT to central twice (i.e. subtracting an
>> additional 6 hours), I figured ok tell the JVM to stay in GMT
>> and not do any conversions.  So now, the database returns Central
>> time dates and times, but JVM no longer thinks it needs to 
>> convert again to 'more central'.
>> 
>> This is about as convoluted and ugly as it gets.  And I don't
>> make any claims of thinking I can give a rational explanation for
>> why it works this way.  But it's on to fight a battle on another
>> hill now.
>> 
>> Just to summarize for anybody who comes along with a similar
>> problem I original set the timezone of mySQL RDS instance to
>> Central time when I created it months back (unchangable after
>> it's set).  I set my Linux timezone to Central as well in order
>> to make my log files have entries with the correct timestamps.
>> But as I described earlier, changing the OS timezone made the JVM
>> also go to Central as well.  But the JVM apparently assumed the
>> database was in GMT so it subtracted 6 more hours off the
>> already-central time from the db.  I guess the real error was not
>> initially leaving the MySQL RDS in GMT.  But since that's not 
>> changeable without recreating a whole new RDS instance, the next
>> option is what I did with the jvm.   Makes total sense, right???
>> :-)
>> 
>> Thanks again.
>> 
>> Jerry
>> 
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4WW/wACgkQHPApP6U8
pFgyOw//e1s40WZp2BXR93OmY/B+1ujrJGqPBzTZ6xYwRREqYfc14D1XhdDV9QuY
NH9p99rZLC2fpjxcWsoLDl82sDr/31aM5mkR4XRvOu93EAWO8jwMdmaFwxI05Kmn
S4ALFYjlFvgVS6usjKHjxeUcOihNJncEimdexRLfzzxCcj3qWaetr6j11azIqWn6
zWxGqWIq5dyfr43zwA/lTaoEOzVAOzzhGGzTrK2kQLNz7KKVnSID39BFxKo2AeYr
A22r/RfPsxuChnO22U32tWD2ulwO7kzOm0hfgzND9efJkRrN50gO746HdL5qrqyv
rfUrPpWsJurWj393WQzMwN04WsLOIAemQ8WF+djJmnrYX0k9khwiMRPxKG0QPBz3
8ukX2Y5jSDQTlcmw21FSWtnWZ6Q8CtGNXwxQPcHLC3yp1UIwMzndPqCq9Qs0JQ+U
RHNng/Vq2COzIAMWMdZWPVFPb+gffQGoBEk7dDXfNRuiyG5JE7bzmb5+0EYOpJA3
piexrJoR1J91rrLhQ62wOGpO26c9GlO3v+VP4/WcOk1amjdN4gzaXTRx2ncq6GsD
Te7ZfucErcmwO4YROPG8ZHp8yoGInhZ98mj2yyteo618U0a/v9F/A4GhiWjjyD76
5ImOvoIGLXTSfDyZUI4UhPWVhQVqvAdm6zmG4w63cJAAaonMpzc=
=U0UR
-END PGP SIGNATURE-

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

Re: Dates on Linux vs. Windows - Resolved

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jerry,

On 1/8/20 12:05 AM, Jerry Malcolm wrote:
> First of all, a big thank you to everyone who responded to this
> one.  I doubt I'd have figured it out for days without your
> guidance and help.

Glad you are all set, though I'm not sure I agree with your
solution... and possibly your conclusions as to why/how it's "fixed".

> And the winner is the JVM timezone.

!!

> But as I described earlier, changing the OS timezone made the JVM
> also go to Central as well.

It's slightly more complicated than this. The system has a time zone.
Each user has their own time zone which defaults to the system time
zone. The user launching the JVM chooses the time zone for the JVM. So
the default progression looks like this:

1. Explicitly set at JVM launch using -Duser.timezone
2. Explicitly set by user using TZ environment variable
3. Inherit from system time zone

> But the JVM apparently assumed the database was in GMT so it
> subtracted 6 more hours off the already-central time from the db.

The JVM doesn't do this. The JDBC driver is responsible. And I still
think that Connector/J is doing the right thing. When you connect via
Connector/J, the driver grabs the time zone from the server and
figures how (and if) to convert time values between the two.

> I guess the real error was not initially leaving the MySQL RDS in
> GMT.  But since that's not changeable without recreating a whole
> new RDS instance, the next option is what I did with the jvm.
> Makes total sense, right???  :-)

If you can login to a shell on the RDS instance, you can change the
system time zone. You can also change the db time zone in the db
config if you want it different from the system (which you do not want
IMHO).

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4WW1EACgkQHPApP6U8
pFgvcRAAiPPdACvG+kUv0paR9XGIZ4NsIl8y6ujxx+vvCqzjyzJ7QmsWifDLDeWq
DALbvpK1JR6tlXcaQPGRV18yI8SkfDUBi/2gCpy7pjgYqXCO/h772QQ+qWqpiC8o
S402a5GctvdXqD2Kd2xX2wK3oiHGqlQrzCvabt/Fgt4AQOIQJjX46evYu46X1mjZ
BZ7utdZBeApK+iKDv0N/1yFS1NAEIqms06hnsYHcEqYAHkxTr1yyQkdFAUmVI3nV
uPRagXEN/+IAOsOqULK69axK6ioesMZErGOWRbMFi/3WOkHaaI0eaor2OUQhoSK/
X7L8hy24mMWrXOV+LBmtw5tRj0K7eAeW30+dZFcYcWR4Hb50whvDlfnyqIT1/SSk
Z3HtrqYT4QIsorU5/uifN2yDjVfuIqu8YDS5/BW8BWsa0hGaDbqR2JdszeR0t4Nf
judacTtPVZThbqfoWsmvRNu0+chQITaZUpEtlSllNzlxmBcwYhsdPO8F7AWzh5i/
gxlbI6KMTO9BCm/0x4QprrROBNr9Zjnas6vXGVuijQDL3wcjQuVdfJKJlQ9OT3pw
abi0Z/f5y66mCpN1qenvY328c9XbkQk+0NK1EkdyNLVCmKT1qFvYPU9XRjNmpXRB
OvDnakziRvyDU/BMLLX7bGhr/YO3WGu1YvObRyFIFLy8gWjnHVs=
=N+gY
-END PGP SIGNATURE-

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

Re: ECDSA Private Keys

[logo]

Hi Mark,

> Am 08.01.2020 um 19:04 schrieb Mark Thomas :
> 
> On 26/12/2019 23:55, logo wrote:
> 
> 
> 
>> as an EC certificate will start with EC PRIVATE KEY.
>> 
>> Is this something that is expected? ECDSA unsupported? Or just an incomplete 
>> implementation, edge case or a bug?
> 
> Hi,
> 
> Sorry for not getting to this sooner.
> 
> I'm not 100% sure that Java directly supports the format that includes:
> -BEGIN EC PRIVATE KEY-
> 
> 
> Initial research suggests you need to "update" the format of the key file:
> 
> openssl pkcs8 -topk8 -inform pem -in file.key -outform pem -nocrypt -out
> file.pem
> 
> I have confirmed that this updated key then works cleanly with both the
> OpenSSL and JSSE TLS implementations.
> 

Felix already suggested that. I've tried it and at first it looks good. 
Connector starts and serves the ECDSA cert.

Please see the last two emails with the findings of the testssl.sh scans. I 
don’t know but tomcat now also serves strange ciphers… (at least some that 
openssl doesn’t even support and the scanner gets some strange results!)

https://markmail.org/message/nj7lvuplld4c5nqx


> In theory, Tomcat should be able to do this conversion for you. The
> issue will be how much of the crypto API we need to do that is part of
> the public API and, where it isn't, how easy it is to craft our own.
> 
> I'm currently investigating…
> 

Thanks for your support. I got the people at smallstep to create an option to 
also create RSA certs. So there is currently a workaround to use their acme 
process with tomcat.

Peter


> Mark
> 
> -
> 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: [OT] Re: Maven Warning. Ubuntu Users

[Zahid Rahman]

I am responding to statement made by lersencrypt guy with evidence.
Statement  he made on this list. It is known as right to respond.

On Wed, 8 Jan 2020, 21:20 calder,  wrote:

> What does this have to do with Tomcat?
>
> Moderators???
>
>
>
> On Wed, Jan 8, 2020, 13:52 Zahid Rahman  wrote:
>
> > Another example of using  maven 2015 version and the impact of unknown
> > warning  by MAVEN can have on application development across the Globe.
> > Let'sEncrypt guy (Shultz) dismissed as unimportant.
> >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.3.9/
> >
> >
> > Mary Zheng
> > Posted by: Mary Zheng
> >  in Core Java
> >  December 27th,
> > 2019
> >  0
> > <
> >
> https://examples.javacodegeeks.com/multiple-inheritance-java-example/#respond
> > >
> >  433 Views
> >
> > She works as a senior Software Engineer in the telecommunications sector
> > where she acts as a leader and works with others to design, implement,
> and
> > monitor the software solution.
> >
> > https://examples.javacodegeeks.com/multiple-inheritance-java-example/
> >
> > 2. Technologies Used
> >
> > The example code in this article was built and run using:
> >
> >- Java 11
> >- Maven 3.3.9
> >- Eclipse Oxygen
> >- Junit 4.12
> >
> >
> > On Wed, 8 Jan 2020, 12:36 zahid,  wrote:
> >
> > > ok
> > >
> > > Thank you.
> > >
> > > www.backbutton.co.uk
> > > ♡۶¯\_(ツ)_/¯ ♡۶
> > > Marriage of loose and tight coupling
> > > -> healthy applications
> > >♡۶
> > > javac Garden/Vegetables/VineVegetable.java
> > > java   Garden.Vegetables.VineVegetable
> > > What No!  -classpath -class-path even -cp!
> > >
> > > On 08/01/2020 09:48, Mark Thomas wrote:
> > > > On 08/01/2020 08:41, Peter Kreuser wrote:
> > > >> Zahid,
> > > >>
> > > >> you‘re talking to one of the most respected members of the community
> > > > like this?
> > > >
> > > > All participants in Apache communities are expected to follow the
> code
> > > > of conduct:
> > > >
> > > > http://www.apache.org/foundation/policies/conduct.html
> > > >
> > > > This is irrespective of whether you are replying to a message from
> one
> > > > of the founders of the ASF or a first time contributor.
> > > >
> > > >> STFU or leave.
> > > > While I understand the frustration, statements like the above are
> only
> > > > going to add heat to an already heated situation. Please try and
> > refrain
> > > > from such responses.
> > > >
> > > >> This calls for an ban!
> > > > As one of the list moderators, that thought crossed my mind as soon
> as
> > I
> > > > saw the off-topic Linux vs Windows post. I hoped that it was a
> one-off.
> > > > When it became clear that it wasn't, I posted my request to keep
> > threads
> > > > on topic. I hoped that would be sufficient. Clearly it wasn't.
> > > >
> > > > I would urge everyone not to reply to off-topic posts.
> > > >
> > > > If you want to bring a post you find problematic to the attention of
> > the
> > > > moderators then please feel free to mail the list moderators at:
> > > > users-ow...@tomcat.apache.org
> > > >
> > > >>> Am 08.01.2020 um 06:06 schrieb Zahid Rahman  >:
> > > >>>
> > > >>> 
> > >  A version of what?
> > > >>> MAVEN
> > > >>> MAVEN
> > > >>> MAVEN
> > > >>>
> > > >>> In light of this video https://youtu.be/idViw4anA6E
> > > >>> Of http.
> > > >>>
> > > >>> You and your let's encrypt must be the longest troll on this line.
> > > > No.
> > > >
> > > > How to configure Apache Tomcat with keys and certificates provided by
> > > > Let's Encrypt is entirely on-topic for the Apache Tomcat users'
> mailing
> > > > list.
> > > >
> > > >>> Take your wares and peddle them somewhere else carpet beggar.
> > > > Zahid,
> > > >
> > > > Please stop this now.
> > > >
> > > > Please keep your posts to this list on topic.
> > > >
> > > > Please ensure that any posts are consistent with the Apache Code of
> > > Conduct.
> > > >
> > > > If you continue to disrupt this community with off-topic posts and/or
> > > > behaviour that is inconsistent with the Apache Code of Conduct then
> the
> > > > list moderators will either require all your posts to be moderated or
> > > > simply block you from posting at all.
> > > >
> > > > Mark
> > > > wearing his list moderator hat
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > >
> > > --
> > > www.backbutton.co.uk
> > > ♡۶¯\_(ツ)_/¯ ♡۶
> > > Marriage of loose and tight coupling
> > > -> healthy applications
> > >♡۶
> > > java -cp classpath class-path
> > >
> > >
> >
>

Re: [OT] Re: Maven Warning. Ubuntu Users

[Zahid Rahman]

I am going to put all your emails attacking me on my website.

On Wed, 8 Jan 2020, 21:20 calder,  wrote:

> What does this have to do with Tomcat?
>
> Moderators???
>
>
>
> On Wed, Jan 8, 2020, 13:52 Zahid Rahman  wrote:
>
> > Another example of using  maven 2015 version and the impact of unknown
> > warning  by MAVEN can have on application development across the Globe.
> > Let'sEncrypt guy (Shultz) dismissed as unimportant.
> >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.3.9/
> >
> >
> > Mary Zheng
> > Posted by: Mary Zheng
> >  in Core Java
> >  December 27th,
> > 2019
> >  0
> > <
> >
> https://examples.javacodegeeks.com/multiple-inheritance-java-example/#respond
> > >
> >  433 Views
> >
> > She works as a senior Software Engineer in the telecommunications sector
> > where she acts as a leader and works with others to design, implement,
> and
> > monitor the software solution.
> >
> > https://examples.javacodegeeks.com/multiple-inheritance-java-example/
> >
> > 2. Technologies Used
> >
> > The example code in this article was built and run using:
> >
> >- Java 11
> >- Maven 3.3.9
> >- Eclipse Oxygen
> >- Junit 4.12
> >
> >
> > On Wed, 8 Jan 2020, 12:36 zahid,  wrote:
> >
> > > ok
> > >
> > > Thank you.
> > >
> > > www.backbutton.co.uk
> > > ♡۶¯\_(ツ)_/¯ ♡۶
> > > Marriage of loose and tight coupling
> > > -> healthy applications
> > >♡۶
> > > javac Garden/Vegetables/VineVegetable.java
> > > java   Garden.Vegetables.VineVegetable
> > > What No!  -classpath -class-path even -cp!
> > >
> > > On 08/01/2020 09:48, Mark Thomas wrote:
> > > > On 08/01/2020 08:41, Peter Kreuser wrote:
> > > >> Zahid,
> > > >>
> > > >> you‘re talking to one of the most respected members of the community
> > > > like this?
> > > >
> > > > All participants in Apache communities are expected to follow the
> code
> > > > of conduct:
> > > >
> > > > http://www.apache.org/foundation/policies/conduct.html
> > > >
> > > > This is irrespective of whether you are replying to a message from
> one
> > > > of the founders of the ASF or a first time contributor.
> > > >
> > > >> STFU or leave.
> > > > While I understand the frustration, statements like the above are
> only
> > > > going to add heat to an already heated situation. Please try and
> > refrain
> > > > from such responses.
> > > >
> > > >> This calls for an ban!
> > > > As one of the list moderators, that thought crossed my mind as soon
> as
> > I
> > > > saw the off-topic Linux vs Windows post. I hoped that it was a
> one-off.
> > > > When it became clear that it wasn't, I posted my request to keep
> > threads
> > > > on topic. I hoped that would be sufficient. Clearly it wasn't.
> > > >
> > > > I would urge everyone not to reply to off-topic posts.
> > > >
> > > > If you want to bring a post you find problematic to the attention of
> > the
> > > > moderators then please feel free to mail the list moderators at:
> > > > users-ow...@tomcat.apache.org
> > > >
> > > >>> Am 08.01.2020 um 06:06 schrieb Zahid Rahman  >:
> > > >>>
> > > >>> 
> > >  A version of what?
> > > >>> MAVEN
> > > >>> MAVEN
> > > >>> MAVEN
> > > >>>
> > > >>> In light of this video https://youtu.be/idViw4anA6E
> > > >>> Of http.
> > > >>>
> > > >>> You and your let's encrypt must be the longest troll on this line.
> > > > No.
> > > >
> > > > How to configure Apache Tomcat with keys and certificates provided by
> > > > Let's Encrypt is entirely on-topic for the Apache Tomcat users'
> mailing
> > > > list.
> > > >
> > > >>> Take your wares and peddle them somewhere else carpet beggar.
> > > > Zahid,
> > > >
> > > > Please stop this now.
> > > >
> > > > Please keep your posts to this list on topic.
> > > >
> > > > Please ensure that any posts are consistent with the Apache Code of
> > > Conduct.
> > > >
> > > > If you continue to disrupt this community with off-topic posts and/or
> > > > behaviour that is inconsistent with the Apache Code of Conduct then
> the
> > > > list moderators will either require all your posts to be moderated or
> > > > simply block you from posting at all.
> > > >
> > > > Mark
> > > > wearing his list moderator hat
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > >
> > > --
> > > www.backbutton.co.uk
> > > ♡۶¯\_(ツ)_/¯ ♡۶
> > > Marriage of loose and tight coupling
> > > -> healthy applications
> > >♡۶
> > > java -cp classpath class-path
> > >
> > >
> >
>

Re: [OT] Re: Maven Warning. Ubuntu Users

[calder]

What does this have to do with Tomcat?

Moderators???



On Wed, Jan 8, 2020, 13:52 Zahid Rahman  wrote:

> Another example of using  maven 2015 version and the impact of unknown
> warning  by MAVEN can have on application development across the Globe.
> Let'sEncrypt guy (Shultz) dismissed as unimportant.
>
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.3.9/
>
>
> Mary Zheng
> Posted by: Mary Zheng
>  in Core Java
>  December 27th,
> 2019
>  0
> <
> https://examples.javacodegeeks.com/multiple-inheritance-java-example/#respond
> >
>  433 Views
>
> She works as a senior Software Engineer in the telecommunications sector
> where she acts as a leader and works with others to design, implement, and
> monitor the software solution.
>
> https://examples.javacodegeeks.com/multiple-inheritance-java-example/
>
> 2. Technologies Used
>
> The example code in this article was built and run using:
>
>- Java 11
>- Maven 3.3.9
>- Eclipse Oxygen
>- Junit 4.12
>
>
> On Wed, 8 Jan 2020, 12:36 zahid,  wrote:
>
> > ok
> >
> > Thank you.
> >
> > www.backbutton.co.uk
> > ♡۶¯\_(ツ)_/¯ ♡۶
> > Marriage of loose and tight coupling
> > -> healthy applications
> >♡۶
> > javac Garden/Vegetables/VineVegetable.java
> > java   Garden.Vegetables.VineVegetable
> > What No!  -classpath -class-path even -cp!
> >
> > On 08/01/2020 09:48, Mark Thomas wrote:
> > > On 08/01/2020 08:41, Peter Kreuser wrote:
> > >> Zahid,
> > >>
> > >> you‘re talking to one of the most respected members of the community
> > > like this?
> > >
> > > All participants in Apache communities are expected to follow the code
> > > of conduct:
> > >
> > > http://www.apache.org/foundation/policies/conduct.html
> > >
> > > This is irrespective of whether you are replying to a message from one
> > > of the founders of the ASF or a first time contributor.
> > >
> > >> STFU or leave.
> > > While I understand the frustration, statements like the above are only
> > > going to add heat to an already heated situation. Please try and
> refrain
> > > from such responses.
> > >
> > >> This calls for an ban!
> > > As one of the list moderators, that thought crossed my mind as soon as
> I
> > > saw the off-topic Linux vs Windows post. I hoped that it was a one-off.
> > > When it became clear that it wasn't, I posted my request to keep
> threads
> > > on topic. I hoped that would be sufficient. Clearly it wasn't.
> > >
> > > I would urge everyone not to reply to off-topic posts.
> > >
> > > If you want to bring a post you find problematic to the attention of
> the
> > > moderators then please feel free to mail the list moderators at:
> > > users-ow...@tomcat.apache.org
> > >
> > >>> Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
> > >>>
> > >>> 
> >  A version of what?
> > >>> MAVEN
> > >>> MAVEN
> > >>> MAVEN
> > >>>
> > >>> In light of this video https://youtu.be/idViw4anA6E
> > >>> Of http.
> > >>>
> > >>> You and your let's encrypt must be the longest troll on this line.
> > > No.
> > >
> > > How to configure Apache Tomcat with keys and certificates provided by
> > > Let's Encrypt is entirely on-topic for the Apache Tomcat users' mailing
> > > list.
> > >
> > >>> Take your wares and peddle them somewhere else carpet beggar.
> > > Zahid,
> > >
> > > Please stop this now.
> > >
> > > Please keep your posts to this list on topic.
> > >
> > > Please ensure that any posts are consistent with the Apache Code of
> > Conduct.
> > >
> > > If you continue to disrupt this community with off-topic posts and/or
> > > behaviour that is inconsistent with the Apache Code of Conduct then the
> > > list moderators will either require all your posts to be moderated or
> > > simply block you from posting at all.
> > >
> > > Mark
> > > wearing his list moderator hat
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > --
> > www.backbutton.co.uk
> > ♡۶¯\_(ツ)_/¯ ♡۶
> > Marriage of loose and tight coupling
> > -> healthy applications
> >♡۶
> > java -cp classpath class-path
> >
> >
>

Re: [OT] Re: Maven Warning. Ubuntu Users

[Zahid Rahman]

Another example of using  maven 2015 version and the impact of unknown
warning  by MAVEN can have on application development across the Globe.
Let'sEncrypt guy (Shultz) dismissed as unimportant.

https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.3.9/


Mary Zheng
Posted by: Mary Zheng
 in Core Java
 December 27th, 2019
 0

 433 Views

She works as a senior Software Engineer in the telecommunications sector
where she acts as a leader and works with others to design, implement, and
monitor the software solution.

https://examples.javacodegeeks.com/multiple-inheritance-java-example/

2. Technologies Used

The example code in this article was built and run using:

   - Java 11
   - Maven 3.3.9
   - Eclipse Oxygen
   - Junit 4.12


On Wed, 8 Jan 2020, 12:36 zahid,  wrote:

> ok
>
> Thank you.
>
> www.backbutton.co.uk
> ♡۶¯\_(ツ)_/¯ ♡۶
> Marriage of loose and tight coupling
> -> healthy applications
>♡۶
> javac Garden/Vegetables/VineVegetable.java
> java   Garden.Vegetables.VineVegetable
> What No!  -classpath -class-path even -cp!
>
> On 08/01/2020 09:48, Mark Thomas wrote:
> > On 08/01/2020 08:41, Peter Kreuser wrote:
> >> Zahid,
> >>
> >> you‘re talking to one of the most respected members of the community
> > like this?
> >
> > All participants in Apache communities are expected to follow the code
> > of conduct:
> >
> > http://www.apache.org/foundation/policies/conduct.html
> >
> > This is irrespective of whether you are replying to a message from one
> > of the founders of the ASF or a first time contributor.
> >
> >> STFU or leave.
> > While I understand the frustration, statements like the above are only
> > going to add heat to an already heated situation. Please try and refrain
> > from such responses.
> >
> >> This calls for an ban!
> > As one of the list moderators, that thought crossed my mind as soon as I
> > saw the off-topic Linux vs Windows post. I hoped that it was a one-off.
> > When it became clear that it wasn't, I posted my request to keep threads
> > on topic. I hoped that would be sufficient. Clearly it wasn't.
> >
> > I would urge everyone not to reply to off-topic posts.
> >
> > If you want to bring a post you find problematic to the attention of the
> > moderators then please feel free to mail the list moderators at:
> > users-ow...@tomcat.apache.org
> >
> >>> Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
> >>>
> >>> 
>  A version of what?
> >>> MAVEN
> >>> MAVEN
> >>> MAVEN
> >>>
> >>> In light of this video https://youtu.be/idViw4anA6E
> >>> Of http.
> >>>
> >>> You and your let's encrypt must be the longest troll on this line.
> > No.
> >
> > How to configure Apache Tomcat with keys and certificates provided by
> > Let's Encrypt is entirely on-topic for the Apache Tomcat users' mailing
> > list.
> >
> >>> Take your wares and peddle them somewhere else carpet beggar.
> > Zahid,
> >
> > Please stop this now.
> >
> > Please keep your posts to this list on topic.
> >
> > Please ensure that any posts are consistent with the Apache Code of
> Conduct.
> >
> > If you continue to disrupt this community with off-topic posts and/or
> > behaviour that is inconsistent with the Apache Code of Conduct then the
> > list moderators will either require all your posts to be moderated or
> > simply block you from posting at all.
> >
> > Mark
> > wearing his list moderator hat
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> --
> www.backbutton.co.uk
> ♡۶¯\_(ツ)_/¯ ♡۶
> Marriage of loose and tight coupling
> -> healthy applications
>♡۶
> java -cp classpath class-path
>
>

Re: ECDSA Private Keys

[Mark Thomas]

On 26/12/2019 23:55, logo wrote:



> as an EC certificate will start with EC PRIVATE KEY.
> 
> Is this something that is expected? ECDSA unsupported? Or just an incomplete 
> implementation, edge case or a bug?

Hi,

Sorry for not getting to this sooner.

I'm not 100% sure that Java directly supports the format that includes:
-BEGIN EC PRIVATE KEY-


Initial research suggests you need to "update" the format of the key file:

openssl pkcs8 -topk8 -inform pem -in file.key -outform pem -nocrypt -out
file.pem

I have confirmed that this updated key then works cleanly with both the
OpenSSL and JSSE TLS implementations.

In theory, Tomcat should be able to do this conversion for you. The
issue will be how much of the crypto API we need to do that is part of
the public API and, where it isn't, how easy it is to craft our own.

I'm currently investigating...

Mark

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

Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?

[James H. H. Lampert]

On 1/8/20 5:18 AM, Christopher Schultz wrote:
. . .

Now the URL line becomes (for me, using a management port):

http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa
ndler,port%3D8215=reloadSslHostConfigs

. . .

Have you configured any  elements, or are you using the
old-style configuration like:




I just have a connector definition in server.xml, almost exactly the 
same as I've been using in Tomcat 7 installations. I don't think prior 
to this discussion, I'd even *heard* of "SSLHostConfig."



You may need to change your connector configuration to use nested
 elements if it's not that way already.

Try invoking the "findSslHostConfigs" operation to see if it
completes. That will at least tell you if you have your objectname
correct.

Like this:

$ curl -k -u "test:test"
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocol
Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs"


This gave me a stacktrace:

curl -k -u "test:test"
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443,ad
dress%3D127.0.0.1=findSslHostConfigs"


But omitting the address parameter, as in your own test, gave me this:

curl -k -u test:test
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443;
op=findSslHostConfigs"
OK - Operation findSslHostConfigs returned:
  org.apache.tomcat.util.net.SSLHostConfig@1a9b80c2



curl -k -u test:test
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443;
op=reloadSslHostConfigs"
OK - Operation reloadSslHostConfigs without return value


And I just now confirmed that the latter did indeed reload the keystore 
when I swapped between the regular keystore and a self-signed one, even 
though I just have the old-style connector definition.


So apparently, it was the "address" parameter that was killing me. 
Interesting.


The idea was to put the Tomcat server on the same certificate and 
private key files as the httpd server on the same EC2 box. Do I need 
this newfangled "SSLHostConfig" for that?


At any rate, I think we have another breakthrough here, but at the same 
time, I think I also need to disable the "test" user, and get back to 
another project I have going, at least for now.


--
JHHL

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

Re: Dates on Linux vs. Windows

[Terence M. Bandoian]

On 1/7/2020 6:53 PM, Jerry Malcolm wrote:
>> If your systems always use the same time zone to read and write the 
data, it isn't a problem.


Terrance, thanks for the info.  In my case I do only have one timezone 
(or at least I want to...).  Using the string for dates is a good 
idea.  But this is a massive application that's been in production for 
years with tons of date and timestamp fields spread everywhere across 
the code and the db.  So converting to strings is not a possibility now.


It still comes down to the fact that the mysql command line on my 
linux box gets the date right, but it's converted incorrectly by JDBC 
and only on the linux box (and works on WIndows)


When I first set up the box an installed Tomcat, the default Linux 
time was gmt.  I didn't change the Linux time to central until later.  
Any chance that tomcat stored the timezone in effect when it was 
installed and still is using that even though I changed the linux 
timezone?  (Just grasping at straws here).





Hi, Jerry-

I realize you've found an apparent work-around for the issue but, to be 
clear, I did not use character columns.  The column types were 
DATETIME.  However, when I inserted or updated, I provided string values 
(e.g. update MyTable set myDateTime = '2020-01-08 06:57:00').  And, when 
I read the data, I extracted date/time values from the result set using 
getString (e.g. parseSqlDateTime( resultSet.getString( "myDateTime" ) ).


Best regards.

-Terence Bandoian

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

Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 1/7/20 8:24 PM, James H. H. Lampert wrote:
> On 1/7/20 4:19 PM, Christopher Schultz wrote:
> 
>> You probably "spelled" something incorrectly. It might be a 
>> quoting/escaping issue. It might be a literal misspelling/typo.
>> 
>> The JMXProxyServlet shouldn't NPE like that, though.
>> 
>> I'll take a look and see if we can give you a better error 
>> message than that when it happens.
> 
> Well given that (1) there's no production data at stake, (2) you 
> don't know where this server is, (3) the test user will be removed 
> permanently and replaced with something else once this problem is 
> resolved, and (4) the test user will never be active if I'm not 
> running actual tests, there's no reason to censor the curl call.
> 
> curl -k -u test:test 
> https://localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProto
colHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostCon
figs
>
>
> 
> 
> I tried it with or without quote marks around the URL; I tried it 
> both with the user in a "-u" clause, as above, or with the user 
> prefixing the domain. In all four cases, I get what appears to be 
> the exact same stacktrace as before.

You will absolutely have to quote the whole URL, otherwise the
embedded "&" character will cause the shell to do weird things.

In a local VisualVM, I grabbed the path to a random protocol handler.
The JMX bean object name was:

Catalina:type=ProtocolHandler,port=8215

I'm only missing the address portion, because I haven't set any
address in the configuration.

I don't believe any of those characters need to be escaped except for
the "=" because the object name needs to be a parameter value.

That would give me:

Catalina:type%3DProtocolHandler,port%3D8215

Now the URL line becomes (for me, using a management port):

http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa
ndler,port%3D8215=reloadSslHostConfigs

This gives me the same stack trace as you; same line numbers, etc.

In my case, I have no SSL configured, so maybe I can't reload those
configs for some reason. If I call an arbitrary other method, it works:

http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa
ndler,port%3D8215=findSslHostConfigs

OK - Operation findSslHostConfigs returned:

There is no other output. So there aren't any SSLHostConfigs.

Have you configured any  elements, or are you using the
old-style configuration like:



?

You may need to change your connector configuration to use nested
 elements if it's not that way already.

Try invoking the "findSslHostConfigs" operation to see if it
completes. That will at least tell you if you have your objectname
correct.

Like this:

$ curl -k -u "test:test"
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocol
Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs"

> I can't tell any difference, other than the user, and specifying a 
> port, between that and the "hard-coded" curl call on slide 35 of 
> the presentation. And if I leave out the port number, I get 
> "connection refused."
> 
> FYI, the relevant lines in tomcat-users.xml (with the actual admin 
> user definition redacted) are:
> 
>>   
>> [line redacted] > roles="manager-gui,manager-jmx"/>

Your role is fine, now. You would have gotten a 401 response if you
didn't have the right credentials.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4V1okACgkQHPApP6U8
pFgdjw//SJZPMvvfo322JDngUr6Sdv5MAmV0rfJZ0CQYmQ54LnhAIVX4I3TsgXae
OwDtoQqi9tBk/1qhv9a9GZneXfox28FFb8PiTcwmUSAMcJfzoNFAESqC1HPZGqtD
ET+cNXAde7N4bfaV/+HJGkTUEl5Ze2SBnONBxaBwMQgSUiYCwfr9iv/K2LIpGnjt
PdCts7/XuvGmbWLsZFUpR6tWOwVYUGjXlT042mBegJPQoHkabAFv0xknrgk8oKaD
bUKk2MSB/KZvR6Pzeq+pltSsjoE4C5zMx04gmMndcD7costp+1l2gXk7yOuC2qlI
IRY3LxfI2qIstxcbX9DeuPuQcR0NBsUCcC4CNfBldJy2MEexiwlYp61JPwWr51f3
2gR9MKO11uAlVI1+xXXUsd5wTaXWOvAniphhO35ef88iLsNKQCEo24XhC0x9fYX9
MvbOMFO6w5jlslnrfTxSJyqMm1MT/uBnhoZx1lGHwTswF2/Zp9VDSgOiFCzNLkc9
UfRd+KY/Bk3pDkkkQ3BvEjLg/Lirudtaa9xTjfHDjpEIOUXFsYmALY9cqBvocrtF
BVJIMUrvv4LlzzOtFXEqhnr5nh9HZJR9+3AggY0yy3gqa3fdiSli/I3JZNfYBSWx
c0XR/sex2+vMeIAL+F89Bwp5AV5Q3ncs5Dp8xYIHnCx8yRd2eDo=
=Yj+m
-END PGP SIGNATURE-

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

Re: [OT] Re: Maven Warning. Ubuntu Users

[zahid]

ok

Thank you.

www.backbutton.co.uk
♡۶¯\_(ツ)_/¯ ♡۶
Marriage of loose and tight coupling
-> healthy applications
  ♡۶
javac Garden/Vegetables/VineVegetable.java
java   Garden.Vegetables.VineVegetable
What No!  -classpath -class-path even -cp!

On 08/01/2020 09:48, Mark Thomas wrote:

On 08/01/2020 08:41, Peter Kreuser wrote:

Zahid,

you‘re talking to one of the most respected members of the community

like this?

All participants in Apache communities are expected to follow the code
of conduct:

http://www.apache.org/foundation/policies/conduct.html

This is irrespective of whether you are replying to a message from one
of the founders of the ASF or a first time contributor.


STFU or leave.

While I understand the frustration, statements like the above are only
going to add heat to an already heated situation. Please try and refrain
from such responses.


This calls for an ban!

As one of the list moderators, that thought crossed my mind as soon as I
saw the off-topic Linux vs Windows post. I hoped that it was a one-off.
When it became clear that it wasn't, I posted my request to keep threads
on topic. I hoped that would be sufficient. Clearly it wasn't.

I would urge everyone not to reply to off-topic posts.

If you want to bring a post you find problematic to the attention of the
moderators then please feel free to mail the list moderators at:
users-ow...@tomcat.apache.org


Am 08.01.2020 um 06:06 schrieb Zahid Rahman :



A version of what?

MAVEN
MAVEN
MAVEN

In light of this video https://youtu.be/idViw4anA6E
Of http.

You and your let's encrypt must be the longest troll on this line.

No.

How to configure Apache Tomcat with keys and certificates provided by
Let's Encrypt is entirely on-topic for the Apache Tomcat users' mailing
list.


Take your wares and peddle them somewhere else carpet beggar.

Zahid,

Please stop this now.

Please keep your posts to this list on topic.

Please ensure that any posts are consistent with the Apache Code of Conduct.

If you continue to disrupt this community with off-topic posts and/or
behaviour that is inconsistent with the Apache Code of Conduct then the
list moderators will either require all your posts to be moderated or
simply block you from posting at all.

Mark
wearing his list moderator hat

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


--
www.backbutton.co.uk
♡۶¯\_(ツ)_/¯ ♡۶
Marriage of loose and tight coupling
-> healthy applications
  ♡۶
java -cp classpath class-path


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

Re: [OT] Re: Maven Warning. Ubuntu Users

[Mark Thomas]

On 08/01/2020 08:41, Peter Kreuser wrote:
> Zahid,
>
> you‘re talking to one of the most respected members of the community
like this?

All participants in Apache communities are expected to follow the code
of conduct:

http://www.apache.org/foundation/policies/conduct.html

This is irrespective of whether you are replying to a message from one
of the founders of the ASF or a first time contributor.

> STFU or leave.

While I understand the frustration, statements like the above are only
going to add heat to an already heated situation. Please try and refrain
from such responses.

> This calls for an ban!

As one of the list moderators, that thought crossed my mind as soon as I
saw the off-topic Linux vs Windows post. I hoped that it was a one-off.
When it became clear that it wasn't, I posted my request to keep threads
on topic. I hoped that would be sufficient. Clearly it wasn't.

I would urge everyone not to reply to off-topic posts.

If you want to bring a post you find problematic to the attention of the
moderators then please feel free to mail the list moderators at:
users-ow...@tomcat.apache.org

>> Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
>>
>> 
>>>
>>> A version of what?
>> MAVEN
>> MAVEN
>> MAVEN
>>
>> In light of this video https://youtu.be/idViw4anA6E
>> Of http.
>>
>> You and your let's encrypt must be the longest troll on this line.

No.

How to configure Apache Tomcat with keys and certificates provided by
Let's Encrypt is entirely on-topic for the Apache Tomcat users' mailing
list.

>> Take your wares and peddle them somewhere else carpet beggar.

Zahid,

Please stop this now.

Please keep your posts to this list on topic.

Please ensure that any posts are consistent with the Apache Code of Conduct.

If you continue to disrupt this community with off-topic posts and/or
behaviour that is inconsistent with the Apache Code of Conduct then the
list moderators will either require all your posts to be moderated or
simply block you from posting at all.

Mark
wearing his list moderator hat

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

Re: Dates on Linux vs. Windows - Resolved

[Olaf Kock]

On 08.01.20 06:05, Jerry Malcolm wrote:
> Just to summarize for anybody who comes along with a similar
> problem I original set the timezone of mySQL RDS instance to
> Central time when I created it months back (unchangable after it's
> set).  I set my Linux timezone to Central as well in order to make my
> log files have entries with the correct timestamps.  But as I
> described earlier, changing the OS timezone made the JVM also go to
> Central as well.  But the JVM apparently assumed the database was in
> GMT so it subtracted 6 more hours off the already-central time from
> the db.  I guess the real error was not initially leaving the MySQL
> RDS in GMT.  But since that's not changeable without recreating a
> whole new RDS instance, the next option is what I did with the jvm.  
> Makes total sense, right???  :-)


That's why my personal general recommendation is to run all server code
and OS, and especially all stored data, in UTC only. Optionally, for
selected output (e.g. website display) have the application explicitly
convert to a timezone, dependent on the current user (see Christopher's
excellent answer). It's work, but it's what needs to be done. There is
no "it just works" when handling time without being explicit -
especially in the web / server world, where people access from different
timezones. Desktop applications can be more relaxed (but shouldn't).

Granted, it's easier for me with UTC being one or two hours off during
the year, but the advantage is: UTC is "forward only" - there's no
daylight saving back and forth, no need to interpret anything, just the
plain timestamp. On the technical side (logs) that's what I want, even
if it requires a bit of mental math.

I'm not always remembering to set all of this right away, but it's the
first thing I retroactively do once I run into those problems.

Olaf


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

Re: Dates on Linux vs. Windows - Resolved

[Greg Huber]

>From my past experience with dates and timestamps, it helps to pass the
time zone as a  jvm parameter when starting tomcat

-Duser.timezone=Europe/London



On Wed, 8 Jan 2020 at 05:05, Jerry Malcolm  wrote:

> First of all, a big thank you to everyone who responded to this one.  I
> doubt I'd have figured it out for days without your guidance and help.
>
> And the winner is the JVM timezone.  But the problem was NOT that
> the JVM wasn't set to US Central time.  The problem was that it WAS set
> to US Central, apparently inherited from the Linux OS TZ.  There was no
> parameter on the tomcat java command that set the timezone.  So I added
> one and set it to America/Chicago.  No change.  But since it appeared we
> were already double-dipping and converting from GMT to central twice
> (i.e. subtracting an additional 6 hours), I figured ok tell the JVM
> to stay in GMT and not do any conversions.  So now, the database returns
> Central time dates and times, but JVM no longer thinks it needs to
> convert again to 'more central'.
>
> This is about as convoluted and ugly as it gets.  And I don't make any
> claims of thinking I can give a rational explanation for why it works
> this way.  But it's on to fight a battle on another hill now.
>
> Just to summarize for anybody who comes along with a similar problem
> I original set the timezone of mySQL RDS instance to Central time when I
> created it months back (unchangable after it's set).  I set my Linux
> timezone to Central as well in order to make my log files have entries
> with the correct timestamps.  But as I described earlier, changing the
> OS timezone made the JVM also go to Central as well.  But the JVM
> apparently assumed the database was in GMT so it subtracted 6 more hours
> off the already-central time from the db.  I guess the real error was
> not initially leaving the MySQL RDS in GMT.  But since that's not
> changeable without recreating a whole new RDS instance, the next option
> is what I did with the jvm.   Makes total sense, right???  :-)
>
> Thanks again.
>
> Jerry
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] Re: Maven Warning. Ubuntu Users Ban him for abusive behaviour.

[Zahid Rahman]

Ban him for abusive behaviour.

On Wed, 8 Jan 2020, 08:42 Peter Kreuser,  wrote:

> Zahid,
>
> you‘re talking to one of the most respected members of the community like
> this?
>
> STFU or leave.
>
> This calls for an ban!
>
> Peter
>
> > Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
> >
> > 
> >>
> >> A version of what?
> > MAVEN
> > MAVEN
> > MAVEN
> >
> > In light of this video https://youtu.be/idViw4anA6E
> > Of http.
> >
> > You and your let's encrypt must be the longest troll on this line.
> >
> > Take your wares and peddle them somewhere else carpet beggar.
> >
> >
> >
> >
> >> On Wed, 8 Jan 2020, 01:12 Christopher Schultz, <
> ch...@christopherschultz.net>
> >> wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Zahid,
> >>
> >>> On 1/6/20 3:13 PM, Zahid Rahman wrote:
> >>> That must be the reason why Apache Netbeans is using a version from
> >>> 2015
> >>
> >> A version of what?
> >>
> >>> and Apache Struts is recommending to use jdk 8.
> >> Apache Struts 2.5.x supports Java 7 and later. I see no official
> >> documentation recommending a specific Java version over any others.
> >>
> >>> Because there is somebody like you keeps telling people it is off
> >>> topic and Giant IT companies are not releasing jdk further than JDK
> >>> 8.
> >>
> >> Maybe just not for free.
> >>
> >>
> https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads
> >> - -5672538.html
> >> https://www.azul.com/category/java13/
> >>
> >> Admittedly, Oracle's JDK/JRE is based upon
> >> https://openjdk.java.net/projects/jdk/13/ so maybe that doesn't count
> >> as a separate release.
> >>
> >> But no, IBM doesn't appear to have a new version beyond Java 11.
> >>
> >>> The issue is a miserable and disgraceful failure in coordination by
> >>> Apache Foundation.
> >>
> >> So you found a problem with a package provided by Ubuntu/Debian, and
> >> your solution was to install the official Maven package from the
> >> Apache Software Foundation. And your conclusion is that the ASF is the
> >> miserable and disgraceful party, here?
> >>
> >> I'm so confused.
> >>
> >> It's worth pointing-out that there is no enforced coordination between
> >> ASF projects. Some of them work together in almost lock-step, like APR
> >> and httpd. Others are completely de-coupled. Some ignore each other
> >> (e.g. Apache Maven and Apache Tomcat). It's up to the individual
> >> projects to determine if/how they will work together.
> >>
> >> You may wish to read a little more about the ASF before you make
> >> blanket statements about it.
> >> https://community.apache.org/projectIndependence.html
> >>
> >> If you are dissatisfied with the ASF communities (or maybe just a few
> >> in particular), may I suggest that you take one of these two courses
> >> of action:
> >>
> >> 1. Volunteer to improve the situation. Usually in the form of
> >> patches/PRs to that project.
> >>
> >> 2. Take your complaints elsewhere.
> >>
> >> - -chris
> >>
>  On Mon, 6 Jan 2020, 19:45 Mark Thomas,  wrote:
> >>>
>  On 06/01/2020 18:37, Zahid Rahman wrote:
> > To all ubuntu Maven  users.
> 
>  This is off-topic for this mailing list.
> 
>  Please keep posts on this list on topic.
> 
>  Thanks,
> 
>  Mark
> 
> 
> >
> > Do NOT  install maven using sudo apt install maven
> >
> > Install by  direct download  only  from
> > https://maven.apache.org/download.cgi
> >
> > BECAUSE:
> >
> > "I seem to remember they [ubuntu] have their own build of Maven
> > which differs from the Apache source.
> >
> > ( https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1754602
> > suggests it's a known bug in their packaging/build? )
> >
> > If you download Maven from http://maven.apache.org/download.cgi
> > and
>  follow
> > the instructions in http://maven.apache.org/install.html then
> > you
>  shouldn't
> > see those warnings. " ‐---
> >
> > The Java 11 warning mentions that
> > "/usr/share/maven/lib/guice.jar" has a class named
> > "com.google.inject.internal.cglib.core.$ReflectUtils$1"
> >
> > This looks suspect because the official Maven distribution uses
> > the "no-AOP" version of Guice which doesn't contain any CGLIB
> > classes. It suggests that whoever provided that copy of Maven
> > has replaced the
>  "no-AOP"
> > version with the "AOP" version, and this will cause warnings on
> > Java 11. (The "AOP" version uses CGLIB which currently relies
> > on certain
>  reflective
> > access that Java 11 warns about - whereas the "no-AOP" version
> > doesn't.)
> >
> 
> 
>  -
> 
> 
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 
> >>>
> >> -BEGIN 

Re: [OT] Re: Maven Warning. Ubuntu Users

[Zahid Rahman]

15 years ago I pointed in detail what I expect from a professional  tool

That tool has been sent to.

You are a classpath class-path people
.
I am  -cp kind of person.

He makes you feel comfortable because you are lost and confused. He is too.




On Wed, 8 Jan 2020, 08:42 Peter Kreuser,  wrote:

> Zahid,
>
> you‘re talking to one of the most respected members of the community like
> this?
>
> STFU or leave.
>
> This calls for an ban!
>
> Peter
>
> > Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
> >
> > 
> >>
> >> A version of what?
> > MAVEN
> > MAVEN
> > MAVEN
> >
> > In light of this video https://youtu.be/idViw4anA6E
> > Of http.
> >
> > You and your let's encrypt must be the longest troll on this line.
> >
> > Take your wares and peddle them somewhere else carpet beggar.
> >
> >
> >
> >
> >> On Wed, 8 Jan 2020, 01:12 Christopher Schultz, <
> ch...@christopherschultz.net>
> >> wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Zahid,
> >>
> >>> On 1/6/20 3:13 PM, Zahid Rahman wrote:
> >>> That must be the reason why Apache Netbeans is using a version from
> >>> 2015
> >>
> >> A version of what?
> >>
> >>> and Apache Struts is recommending to use jdk 8.
> >> Apache Struts 2.5.x supports Java 7 and later. I see no official
> >> documentation recommending a specific Java version over any others.
> >>
> >>> Because there is somebody like you keeps telling people it is off
> >>> topic and Giant IT companies are not releasing jdk further than JDK
> >>> 8.
> >>
> >> Maybe just not for free.
> >>
> >>
> https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads
> >> - -5672538.html
> >> https://www.azul.com/category/java13/
> >>
> >> Admittedly, Oracle's JDK/JRE is based upon
> >> https://openjdk.java.net/projects/jdk/13/ so maybe that doesn't count
> >> as a separate release.
> >>
> >> But no, IBM doesn't appear to have a new version beyond Java 11.
> >>
> >>> The issue is a miserable and disgraceful failure in coordination by
> >>> Apache Foundation.
> >>
> >> So you found a problem with a package provided by Ubuntu/Debian, and
> >> your solution was to install the official Maven package from the
> >> Apache Software Foundation. And your conclusion is that the ASF is the
> >> miserable and disgraceful party, here?
> >>
> >> I'm so confused.
> >>
> >> It's worth pointing-out that there is no enforced coordination between
> >> ASF projects. Some of them work together in almost lock-step, like APR
> >> and httpd. Others are completely de-coupled. Some ignore each other
> >> (e.g. Apache Maven and Apache Tomcat). It's up to the individual
> >> projects to determine if/how they will work together.
> >>
> >> You may wish to read a little more about the ASF before you make
> >> blanket statements about it.
> >> https://community.apache.org/projectIndependence.html
> >>
> >> If you are dissatisfied with the ASF communities (or maybe just a few
> >> in particular), may I suggest that you take one of these two courses
> >> of action:
> >>
> >> 1. Volunteer to improve the situation. Usually in the form of
> >> patches/PRs to that project.
> >>
> >> 2. Take your complaints elsewhere.
> >>
> >> - -chris
> >>
>  On Mon, 6 Jan 2020, 19:45 Mark Thomas,  wrote:
> >>>
>  On 06/01/2020 18:37, Zahid Rahman wrote:
> > To all ubuntu Maven  users.
> 
>  This is off-topic for this mailing list.
> 
>  Please keep posts on this list on topic.
> 
>  Thanks,
> 
>  Mark
> 
> 
> >
> > Do NOT  install maven using sudo apt install maven
> >
> > Install by  direct download  only  from
> > https://maven.apache.org/download.cgi
> >
> > BECAUSE:
> >
> > "I seem to remember they [ubuntu] have their own build of Maven
> > which differs from the Apache source.
> >
> > ( https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1754602
> > suggests it's a known bug in their packaging/build? )
> >
> > If you download Maven from http://maven.apache.org/download.cgi
> > and
>  follow
> > the instructions in http://maven.apache.org/install.html then
> > you
>  shouldn't
> > see those warnings. " ‐---
> >
> > The Java 11 warning mentions that
> > "/usr/share/maven/lib/guice.jar" has a class named
> > "com.google.inject.internal.cglib.core.$ReflectUtils$1"
> >
> > This looks suspect because the official Maven distribution uses
> > the "no-AOP" version of Guice which doesn't contain any CGLIB
> > classes. It suggests that whoever provided that copy of Maven
> > has replaced the
>  "no-AOP"
> > version with the "AOP" version, and this will cause warnings on
> > Java 11. (The "AOP" version uses CGLIB which currently relies
> > on certain
>  reflective
> > access that Java 11 warns about - whereas the "no-AOP" version
> > doesn't.)
> >
> 
> 
>  

Re: [OT] Re: Maven Warning. Ubuntu Users

[Zahid Rahman]

You can STFU.

He doesn't even know about an what in API is  ?



On Wed, 8 Jan 2020, 08:42 Peter Kreuser,  wrote:

> Zahid,
>
> you‘re talking to one of the most respected members of the community like
> this?
>
> STFU or leave.
>
> This calls for an ban!
>
> Peter
>
> > Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
> >
> > 
> >>
> >> A version of what?
> > MAVEN
> > MAVEN
> > MAVEN
> >
> > In light of this video https://youtu.be/idViw4anA6E
> > Of http.
> >
> > You and your let's encrypt must be the longest troll on this line.
> >
> > Take your wares and peddle them somewhere else carpet beggar.
> >
> >
> >
> >
> >> On Wed, 8 Jan 2020, 01:12 Christopher Schultz, <
> ch...@christopherschultz.net>
> >> wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Zahid,
> >>
> >>> On 1/6/20 3:13 PM, Zahid Rahman wrote:
> >>> That must be the reason why Apache Netbeans is using a version from
> >>> 2015
> >>
> >> A version of what?
> >>
> >>> and Apache Struts is recommending to use jdk 8.
> >> Apache Struts 2.5.x supports Java 7 and later. I see no official
> >> documentation recommending a specific Java version over any others.
> >>
> >>> Because there is somebody like you keeps telling people it is off
> >>> topic and Giant IT companies are not releasing jdk further than JDK
> >>> 8.
> >>
> >> Maybe just not for free.
> >>
> >>
> https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads
> >> - -5672538.html
> >> https://www.azul.com/category/java13/
> >>
> >> Admittedly, Oracle's JDK/JRE is based upon
> >> https://openjdk.java.net/projects/jdk/13/ so maybe that doesn't count
> >> as a separate release.
> >>
> >> But no, IBM doesn't appear to have a new version beyond Java 11.
> >>
> >>> The issue is a miserable and disgraceful failure in coordination by
> >>> Apache Foundation.
> >>
> >> So you found a problem with a package provided by Ubuntu/Debian, and
> >> your solution was to install the official Maven package from the
> >> Apache Software Foundation. And your conclusion is that the ASF is the
> >> miserable and disgraceful party, here?
> >>
> >> I'm so confused.
> >>
> >> It's worth pointing-out that there is no enforced coordination between
> >> ASF projects. Some of them work together in almost lock-step, like APR
> >> and httpd. Others are completely de-coupled. Some ignore each other
> >> (e.g. Apache Maven and Apache Tomcat). It's up to the individual
> >> projects to determine if/how they will work together.
> >>
> >> You may wish to read a little more about the ASF before you make
> >> blanket statements about it.
> >> https://community.apache.org/projectIndependence.html
> >>
> >> If you are dissatisfied with the ASF communities (or maybe just a few
> >> in particular), may I suggest that you take one of these two courses
> >> of action:
> >>
> >> 1. Volunteer to improve the situation. Usually in the form of
> >> patches/PRs to that project.
> >>
> >> 2. Take your complaints elsewhere.
> >>
> >> - -chris
> >>
>  On Mon, 6 Jan 2020, 19:45 Mark Thomas,  wrote:
> >>>
>  On 06/01/2020 18:37, Zahid Rahman wrote:
> > To all ubuntu Maven  users.
> 
>  This is off-topic for this mailing list.
> 
>  Please keep posts on this list on topic.
> 
>  Thanks,
> 
>  Mark
> 
> 
> >
> > Do NOT  install maven using sudo apt install maven
> >
> > Install by  direct download  only  from
> > https://maven.apache.org/download.cgi
> >
> > BECAUSE:
> >
> > "I seem to remember they [ubuntu] have their own build of Maven
> > which differs from the Apache source.
> >
> > ( https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1754602
> > suggests it's a known bug in their packaging/build? )
> >
> > If you download Maven from http://maven.apache.org/download.cgi
> > and
>  follow
> > the instructions in http://maven.apache.org/install.html then
> > you
>  shouldn't
> > see those warnings. " ‐---
> >
> > The Java 11 warning mentions that
> > "/usr/share/maven/lib/guice.jar" has a class named
> > "com.google.inject.internal.cglib.core.$ReflectUtils$1"
> >
> > This looks suspect because the official Maven distribution uses
> > the "no-AOP" version of Guice which doesn't contain any CGLIB
> > classes. It suggests that whoever provided that copy of Maven
> > has replaced the
>  "no-AOP"
> > version with the "AOP" version, and this will cause warnings on
> > Java 11. (The "AOP" version uses CGLIB which currently relies
> > on certain
>  reflective
> > access that Java 11 warns about - whereas the "no-AOP" version
> > doesn't.)
> >
> 
> 
>  -
> 
> 
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 

Re: [OT] Re: Maven Warning. Ubuntu Users

[Peter Kreuser]

Zahid,

you‘re talking to one of the most respected members of the community like this?

STFU or leave.

This calls for an ban!

Peter

> Am 08.01.2020 um 06:06 schrieb Zahid Rahman :
> 
> 
>> 
>> A version of what?
> MAVEN
> MAVEN
> MAVEN
> 
> In light of this video https://youtu.be/idViw4anA6E
> Of http.
> 
> You and your let's encrypt must be the longest troll on this line.
> 
> Take your wares and peddle them somewhere else carpet beggar.
> 
> 
> 
> 
>> On Wed, 8 Jan 2020, 01:12 Christopher Schultz, 
>> wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Zahid,
>> 
>>> On 1/6/20 3:13 PM, Zahid Rahman wrote:
>>> That must be the reason why Apache Netbeans is using a version from
>>> 2015
>> 
>> A version of what?
>> 
>>> and Apache Struts is recommending to use jdk 8.
>> Apache Struts 2.5.x supports Java 7 and later. I see no official
>> documentation recommending a specific Java version over any others.
>> 
>>> Because there is somebody like you keeps telling people it is off
>>> topic and Giant IT companies are not releasing jdk further than JDK
>>> 8.
>> 
>> Maybe just not for free.
>> 
>> https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads
>> - -5672538.html
>> https://www.azul.com/category/java13/
>> 
>> Admittedly, Oracle's JDK/JRE is based upon
>> https://openjdk.java.net/projects/jdk/13/ so maybe that doesn't count
>> as a separate release.
>> 
>> But no, IBM doesn't appear to have a new version beyond Java 11.
>> 
>>> The issue is a miserable and disgraceful failure in coordination by
>>> Apache Foundation.
>> 
>> So you found a problem with a package provided by Ubuntu/Debian, and
>> your solution was to install the official Maven package from the
>> Apache Software Foundation. And your conclusion is that the ASF is the
>> miserable and disgraceful party, here?
>> 
>> I'm so confused.
>> 
>> It's worth pointing-out that there is no enforced coordination between
>> ASF projects. Some of them work together in almost lock-step, like APR
>> and httpd. Others are completely de-coupled. Some ignore each other
>> (e.g. Apache Maven and Apache Tomcat). It's up to the individual
>> projects to determine if/how they will work together.
>> 
>> You may wish to read a little more about the ASF before you make
>> blanket statements about it.
>> https://community.apache.org/projectIndependence.html
>> 
>> If you are dissatisfied with the ASF communities (or maybe just a few
>> in particular), may I suggest that you take one of these two courses
>> of action:
>> 
>> 1. Volunteer to improve the situation. Usually in the form of
>> patches/PRs to that project.
>> 
>> 2. Take your complaints elsewhere.
>> 
>> - -chris
>> 
 On Mon, 6 Jan 2020, 19:45 Mark Thomas,  wrote:
>>> 
 On 06/01/2020 18:37, Zahid Rahman wrote:
> To all ubuntu Maven  users.
 
 This is off-topic for this mailing list.
 
 Please keep posts on this list on topic.
 
 Thanks,
 
 Mark
 
 
> 
> Do NOT  install maven using sudo apt install maven
> 
> Install by  direct download  only  from
> https://maven.apache.org/download.cgi
> 
> BECAUSE:
> 
> "I seem to remember they [ubuntu] have their own build of Maven
> which differs from the Apache source.
> 
> ( https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1754602
> suggests it's a known bug in their packaging/build? )
> 
> If you download Maven from http://maven.apache.org/download.cgi
> and
 follow
> the instructions in http://maven.apache.org/install.html then
> you
 shouldn't
> see those warnings. " ‐---
> 
> The Java 11 warning mentions that
> "/usr/share/maven/lib/guice.jar" has a class named
> "com.google.inject.internal.cglib.core.$ReflectUtils$1"
> 
> This looks suspect because the official Maven distribution uses
> the "no-AOP" version of Guice which doesn't contain any CGLIB
> classes. It suggests that whoever provided that copy of Maven
> has replaced the
 "no-AOP"
> version with the "AOP" version, and this will cause warnings on
> Java 11. (The "AOP" version uses CGLIB which currently relies
> on certain
 reflective
> access that Java 11 warns about - whereas the "no-AOP" version
> doesn't.)
> 
 
 
 -
 
 
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
>>> 
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>> 
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VLGgACgkQHPApP6U8
>> pFjmuw//cXWmOfcRCt/2FqHwWZwuB23fIXrzEdOJ3RPdJEfwDUxtVcz/rXGI9TB6
>> ae64Vr1+8Znh8xX+wGvoScITo3L/qUPWDkWf5W3rAhhQNWCqsvJvCM4Sw7YE4ytE
>> pv9gT9seDOx+wiGq+FQ5gdy1T7adgTwgYAVLCeuG/bvk4niz9vtYxXBXdfeTIb5e
>> 

Re: Dates on Linux vs. Windows - Resolved

[Johan Compagner]

So you moved once the database to a different timezone (that had say that 6
hour difference)
then the behavior is correct...

Its very weird but that is default behavior of the normal datetime columns
that are created if you move stuff around the database somehow remembers at
what timezone the datetime was inserted and will convert the millis
accordingly..

Its the same as if you have different clients connecting to the same
database over different timezones they will al see the same date as a
string (so the formatted date) instead of really having the same millis
after 1970 utc.
I always find this very very weird.
But i guess this is the difference between database types "timestamp with
timezone" and "timestamp"

So moving the database or moving the client (app server) with existing data
is very tricky.


On Wed, 8 Jan 2020 at 06:05, Jerry Malcolm  wrote:

> First of all, a big thank you to everyone who responded to this one.  I
> doubt I'd have figured it out for days without your guidance and help.
>
> And the winner is the JVM timezone.  But the problem was NOT that
> the JVM wasn't set to US Central time.  The problem was that it WAS set
> to US Central, apparently inherited from the Linux OS TZ.  There was no
> parameter on the tomcat java command that set the timezone.  So I added
> one and set it to America/Chicago.  No change.  But since it appeared we
> were already double-dipping and converting from GMT to central twice
> (i.e. subtracting an additional 6 hours), I figured ok tell the JVM
> to stay in GMT and not do any conversions.  So now, the database returns
> Central time dates and times, but JVM no longer thinks it needs to
> convert again to 'more central'.
>
> This is about as convoluted and ugly as it gets.  And I don't make any
> claims of thinking I can give a rational explanation for why it works
> this way.  But it's on to fight a battle on another hill now.
>
> Just to summarize for anybody who comes along with a similar problem
> I original set the timezone of mySQL RDS instance to Central time when I
> created it months back (unchangable after it's set).  I set my Linux
> timezone to Central as well in order to make my log files have entries
> with the correct timestamps.  But as I described earlier, changing the
> OS timezone made the JVM also go to Central as well.  But the JVM
> apparently assumed the database was in GMT so it subtracted 6 more hours
> off the already-central time from the db.  I guess the real error was
> not initially leaving the MySQL RDS in GMT.  But since that's not
> changeable without recreating a whole new RDS instance, the next option
> is what I did with the jvm.   Makes total sense, right???  :-)
>
> Thanks again.
>
> Jerry
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Johan Compagner
Servoy