Re: Tomcat not part of RHEL 8 distro?

[Sean Neeley]

On Thu, Jul 2, 2020 at 3:46 PM calder  wrote:

> On Thu, Jul 2, 2020 at 3:05 PM Sean Neeley 
> wrote:
> > On Thu, Jul 2, 2020 at 2:57 PM calder  wrote:
> > > On Thu, Jul 2, 2020, 14:43 Sean Neeley 
> wrote:
> > >
> > > > I heard that tomcat is no longer available for RHEL 8.  Does anyone
> know
> > > > why this is?  What free alternatives are there for java servlets,
> which
> > > > have rpm packages managed by Red Hat?
> > >
> > > I would fathom a guess that'd be a question for Red Hat?  (as they
> decide
> > > what's available for their distro).
> > > .
> > > In a pinch, one could download plain vanilla Tomcat and install to
> "/opt/"
> > > [1] ... or you could go through the manual pain to install as it would
> be
> > > deployed on RHEL 7.x
> > > .
> > > [1] We do this
> >
> > Thanks.  I know the decision was Red Hat's, but I thought someone here
> > might know the reason.
>
> It's quite possible - I am not a member of the official Tomcat team,
> so they may chime in if they are privy to that info.
>
> > I may do what you did and install as it was on RHEL 7.x.
>
> To be clear, we do not mimic the install layout as is done in RHEL 7.x
> (a splintered install, where various sub-dirs located in different
> sub-dir trees)
>
> We install (most all 3rd party software) to the "/opt/" tree, so we
> have Tomcat based in:
> /opt/tomcat/ ... and TC's native sub-dirs are all encased in that tree, as
> in:
>
> calder@ren:/opt/tomcat > ls -A1
> bin
> conf
> lib
> logs
> temp
> webapps
> work
> calder@ren:/opt/tomcat >
>
> The simplest explanation is
> (1) create the "/opt/tomcat" sub-dir
> (2) unzip the plain-vanilla ZIP there.
> There's much more to it for us[1], but that's it in a nutshell.
>
> > The drawback is no automatic updates.
> Understood [1]  (we do not allow distro vendor updates).
>
> > Did you package your installation into an rpm that could be shared?
> Shared, as in, "with the general public" ? [1]
>
> [1] Because we are a banking institution, we do not allow 3rd party
> software to be "maintained by the distro vendor" (for updates, etc).
> We are responsible to determine how and "where" the 3rd party
> software will be packaged, installed, and updated.
> Any software packages or documents (etc) created internally can *not*
> leave any machine or our network.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Thanks for the tips.  I will give this a try.  I was asking if you created
a package that you can share with me, for my server.  But if you are not
allowed to do so, or your package has proprietary things in it, I
understand.  I was just trying to save myself some time.

Re: Tomcat not part of RHEL 8 distro?

[calder]

On Thu, Jul 2, 2020 at 3:05 PM Sean Neeley  wrote:
> On Thu, Jul 2, 2020 at 2:57 PM calder  wrote:
> > On Thu, Jul 2, 2020, 14:43 Sean Neeley  wrote:
> >
> > > I heard that tomcat is no longer available for RHEL 8.  Does anyone know
> > > why this is?  What free alternatives are there for java servlets, which
> > > have rpm packages managed by Red Hat?
> >
> > I would fathom a guess that'd be a question for Red Hat?  (as they decide
> > what's available for their distro).
> > .
> > In a pinch, one could download plain vanilla Tomcat and install to "/opt/"
> > [1] ... or you could go through the manual pain to install as it would be
> > deployed on RHEL 7.x
> > .
> > [1] We do this
>
> Thanks.  I know the decision was Red Hat's, but I thought someone here
> might know the reason.

It's quite possible - I am not a member of the official Tomcat team,
so they may chime in if they are privy to that info.

> I may do what you did and install as it was on RHEL 7.x.

To be clear, we do not mimic the install layout as is done in RHEL 7.x
(a splintered install, where various sub-dirs located in different
sub-dir trees)

We install (most all 3rd party software) to the "/opt/" tree, so we
have Tomcat based in:
/opt/tomcat/ ... and TC's native sub-dirs are all encased in that tree, as in:

calder@ren:/opt/tomcat > ls -A1
bin
conf
lib
logs
temp
webapps
work
calder@ren:/opt/tomcat >

The simplest explanation is
(1) create the "/opt/tomcat" sub-dir
(2) unzip the plain-vanilla ZIP there.
There's much more to it for us[1], but that's it in a nutshell.

> The drawback is no automatic updates.
Understood [1]  (we do not allow distro vendor updates).

> Did you package your installation into an rpm that could be shared?
Shared, as in, "with the general public" ? [1]

[1] Because we are a banking institution, we do not allow 3rd party
software to be "maintained by the distro vendor" (for updates, etc).
We are responsible to determine how and "where" the 3rd party
software will be packaged, installed, and updated.
Any software packages or documents (etc) created internally can *not*
leave any machine or our network.

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

Re: Tomcat not part of RHEL 8 distro?

[Sean Neeley]

On Thu, Jul 2, 2020 at 2:57 PM calder  wrote:

> On Thu, Jul 2, 2020, 14:43 Sean Neeley  wrote:
>
> > I heard that tomcat is no longer available for RHEL 8.  Does anyone know
> > why this is?  What free alternatives are there for java servlets, which
> > have rpm packages managed by Red Hat?
> >
>
>
> I would fathom a guess that'd be a question for Red Hat?  (as they decide
> what's available for their distro).
> .
> In a pinch, one could download plain vanilla Tomcat and install to "/opt/"
> [1] ... or you could go through the manual pain to install as it would be
> deployed on RHEL 7.x
> .
> [1] We do this
>
> >
>

Thanks.  I know the decision was Red Hat's, but I thought someone here
might know the reason.
I may do what you did and install as it was on RHEL 7.x.  The drawback is
no automatic updates.  Did you package your installation into an rpm that
could be shared?

Re: Tomcat not part of RHEL 8 distro?

[calder]

On Thu, Jul 2, 2020, 14:43 Sean Neeley  wrote:

> I heard that tomcat is no longer available for RHEL 8.  Does anyone know
> why this is?  What free alternatives are there for java servlets, which
> have rpm packages managed by Red Hat?
>


I would fathom a guess that'd be a question for Red Hat?  (as they decide
what's available for their distro).
.
In a pinch, one could download plain vanilla Tomcat and install to "/opt/"
[1] ... or you could go through the manual pain to install as it would be
deployed on RHEL 7.x
.
[1] We do this

>

Re: RFC7807 ErrorReportValve

[Mark Thomas]

On 02/07/2020 20:30, Thomas Meyer wrote:
> Hi,
> 
> What are your opinions on providing a RFC7807 based ErrorReportValve as part 
> of Tomcat default distribution?

RFC 7807 looks to be application specific so support for that RFC looks
to be better handled at the application level.

Mark

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

Tomcat not part of RHEL 8 distro?

[Sean Neeley]

I heard that tomcat is no longer available for RHEL 8.  Does anyone know
why this is?  What free alternatives are there for java servlets, which
have rpm packages managed by Red Hat?  Thanks

-- 

Sean Neeley | Senior Developer

t. 630.395.9600 x6234

sean.nee...@producepro.com

Produce Pro Software™

Chicago | Los Angeles | Philadelphia | Austin

Website  | Facebook
 | Twitter
 | Instagram
 | LinkedIn
 | YouTube

Re: Tomcat JDBCRealm using DIGEST authentication not producing the expected HASH using a SALT

[Hugh Roberts]

Mark,

Thanks for your quick response. We will try your suggestion as this may be
the only option we have to get the users authenticated.

Thanks again.



On Thu, Jul 2, 2020 at 2:43 PM Mark Thomas  wrote:

> On 02/07/2020 17:38, Hugh Roberts wrote:
> > Tomcat 9.0.36
> > JDK 1.8.0_251
> >
> > We are trying to use Tomcat JDBCRealm to access user credentials stored
> in
> > Oracle DB. The user password is hashed with a SALT and stored in a table.
> >
> > *ISSUE:* We can authenticate using the BASIC auth-method while passing
> the
> > hashed string of the password but the DIGEST auth-method fails to create
> > the matching hash of the user password after configuring the realm-name
> > with the SALT and using the CredentialHandler
> > MessageDigestCredentialHandler.
> >
> > The user HASH password is created using Oracle DBMS_CRYPTO by taking the
> > SALT combined with the password to create a raw string that is then
> HASHED
> >
> > Using Tomcat DIGEST command, we can successfully create the user's
> matching
> > HASH on the command line as follows: *digest.bat -a SHA-1 -s 0
> >  SALTpassword*
> > *SALTpassword:86a0e40af8c1a0e970f9432bee75bcc886145440* (the other
> formats
> > for using the SALT does not produce a matching HASH -
> > UserName:Realm:Password) BUT we cannot authenticate when using the Tomcat
> > authentication form in the browser. The password hash is not matching. We
> > cannot tell how the form is using the SALT to hash the password to see
> > where the issue is.
> >
> > Can you tell us exactly how Tomcat authentication form uses the SALT
> > configured in the web.xml file to create the password hash. If it hashes
> > the SALT and password as one string or uses another method?
>
> That will never work with HTTP DIGEST authentication. As per the Realm
> HowTo:
>
> 
> CATALINA_HOME/bin/digest.[bat|sh] -a {algorithm} {cleartext-password}
> ...
> If using digested passwords with DIGEST authentication, the cleartext
> used to generate the digest is different and the digest must use one
> iteration of the MD5 algorithm with no salt. In the examples above
> {cleartext-password} must be replaced with
> {username}:{realm}:{cleartext-password}.
> 
>
> More details at
> http://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Digested_Passwords
>
> Note: Using DIGEST authentication is a separate decision to storing
> password hashes in the authentication database although if you do choose
> to do both then DIGEST auth places strict requirements on how you store
> the hashed passwords.
>
> If you want hashed passwords in the database then you'll need to:
> - User BASIC auth
> - Configure the CredentialHandler to match database (assuming this is
>   posisble)
> - Require TLS for authentication
>
> Mark
>
>
> >
> >
> > server.xml
> > ...
> >  > driverName="oracle.jdbc.driver.OracleDriver"
> > connectionURL="jdbc:oracle:thin:@x.x.x.x:1521/test"
> > connectionName="dev"
> > connectionPassword="dev1"
> > userTable="USERS" userNameCol="USERNAME" userCredCol="PASSWORD"
> > userRoleTable="USER_ROLES" roleNameCol="ROLES" >
> >  > className="org.apache.catalina.realm.MessageDigestCredentialHandler"
> > algorithm="SHA-1" saltLength="0" iterations="1" />
> > 
> >
> > web.xml
> >  ...
> >  > DIGEST
> > SALT
> >  > ...
> >
> > Thanks.
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RFC7807 ErrorReportValve

[Thomas Meyer]

Hi,

What are your opinions on providing a RFC7807 based ErrorReportValve as part of 
Tomcat default distribution?

With kind regards
Thomas

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

Re: [ANN] New committer: Raymond Augé

[Martin Grigorov]

Welcome Raymond!

On Thu, Jul 2, 2020, 17:40 Mark Thomas  wrote:

> On behalf of the Tomcat committers I am pleased to announce that
> Raymond Augé (rotty3000) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>
> Kind regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat JDBCRealm using DIGEST authentication not producing the expected HASH using a SALT

[Mark Thomas]

On 02/07/2020 17:38, Hugh Roberts wrote:
> Tomcat 9.0.36
> JDK 1.8.0_251
> 
> We are trying to use Tomcat JDBCRealm to access user credentials stored in
> Oracle DB. The user password is hashed with a SALT and stored in a table.
> 
> *ISSUE:* We can authenticate using the BASIC auth-method while passing the
> hashed string of the password but the DIGEST auth-method fails to create
> the matching hash of the user password after configuring the realm-name
> with the SALT and using the CredentialHandler
> MessageDigestCredentialHandler.
> 
> The user HASH password is created using Oracle DBMS_CRYPTO by taking the
> SALT combined with the password to create a raw string that is then HASHED
> 
> Using Tomcat DIGEST command, we can successfully create the user's matching
> HASH on the command line as follows: *digest.bat -a SHA-1 -s 0
>  SALTpassword*
> *SALTpassword:86a0e40af8c1a0e970f9432bee75bcc886145440* (the other formats
> for using the SALT does not produce a matching HASH -
> UserName:Realm:Password) BUT we cannot authenticate when using the Tomcat
> authentication form in the browser. The password hash is not matching. We
> cannot tell how the form is using the SALT to hash the password to see
> where the issue is.
> 
> Can you tell us exactly how Tomcat authentication form uses the SALT
> configured in the web.xml file to create the password hash. If it hashes
> the SALT and password as one string or uses another method?

That will never work with HTTP DIGEST authentication. As per the Realm
HowTo:


CATALINA_HOME/bin/digest.[bat|sh] -a {algorithm} {cleartext-password}
...
If using digested passwords with DIGEST authentication, the cleartext
used to generate the digest is different and the digest must use one
iteration of the MD5 algorithm with no salt. In the examples above
{cleartext-password} must be replaced with
{username}:{realm}:{cleartext-password}.


More details at
http://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Digested_Passwords

Note: Using DIGEST authentication is a separate decision to storing
password hashes in the authentication database although if you do choose
to do both then DIGEST auth places strict requirements on how you store
the hashed passwords.

If you want hashed passwords in the database then you'll need to:
- User BASIC auth
- Configure the CredentialHandler to match database (assuming this is
  posisble)
- Require TLS for authentication

Mark


> 
> 
> server.xml
> ...
>  driverName="oracle.jdbc.driver.OracleDriver"
> connectionURL="jdbc:oracle:thin:@x.x.x.x:1521/test"
> connectionName="dev"
> connectionPassword="dev1"
> userTable="USERS" userNameCol="USERNAME" userCredCol="PASSWORD"
> userRoleTable="USER_ROLES" roleNameCol="ROLES" >
>  className="org.apache.catalina.realm.MessageDigestCredentialHandler"
> algorithm="SHA-1" saltLength="0" iterations="1" />
> 
> 
> web.xml
>  ...
>  DIGEST
> SALT
>  ...
> 
> Thanks.
> 


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

Re: SameSite attribute handling

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Abirami,

On 7/1/20 03:06, S Abirami wrote:
> We can add the samesite attribute in set-cookie header through
> context.xml entry in tomcat. Is there any other way, can we add
> samesite attribute in response of set-cookie header.
Not for Tomcat-generated cookies, and not for cookies added to the
response like this:

  response.addCookie(myCookie);

This is because the Servlet API hasn't yet caught up with
state-of-the-art.

You can, however, craft your own Set-Cookie response header like this:

  response.addHeader("Set-Cookie", "CookieName=value; SameSite=Strict");

Remember that there are rules about the composition of the cookie's
name, value, etc. that Tomcat enforces for you that you will have to
handel yourself.

> I tried with filter by using setHeader but it is sending two
> set-Cookie header.

Correct: you will have to use *either* setCookie() or setHeader().

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7+GyYACgkQHPApP6U8
pFiSqBAAhG9IHJXD4ec6TQD1F2o9CIbRyHSkVYrAl0miT5cz6BkhuqG7uEnpUw66
8m3oe6CCG1syEliyyHM3A7ySXGEYm54otp4A0GRkcK64kd+RwQKKV5JsSp0xFxtG
dqKRtPGKJL7sQ+kaa4Qo2KqAa7ntQFTRVhg44Lofj8usiu/az5Kg6y8gSgQ/3I2Y
n75PCchaMHsilvSIm3sztR6MpoeRXevv7/93LfI1xzyN6Rg1mE0xivKReQfryMeT
sySwz3S1kZgOb3y+xUgSdL0HNSzT+IoKX58UTrMnmnWRS1hnJ30Fu21Nki+ygyZi
iikJCYi8Fv2SjkvQh+klgVMsr/QxYvYIBKof0Tf4n8/gU6ABy9ZVUdiTeezATytT
Kh5r2C6I+nk9/Osl9s9pHauqzQ/evwjPe/d0eJXkHILam09KB6wqnJ4m3Gq9NcYc
S9f5vjTuScncrVn9+GTvr29onrhI8gh7BRTmYehgHaqt7Hl7alLeNV7ccIOjjYOY
qqC+qXDydaHUBBgappAnZnHepNPSKn0kjKhi63gsjoBVXnLmgR7mYUWwmvoPb+/t
E3T5PL73/cjxBNPk/THao0JI+3UoDlQG4rsZL/wxo7q1ZGzbtrbUrr+7Q7pDBY+y
3YhzVFu68xHkH0Tch3UxFn2qvPXToPHNCzSXDi9Dm5IuGf49UKc=
=97wq
-END PGP SIGNATURE-

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

Re: [ANN] New committer: Raymond Augé

[Raymond Auge]

Thank you all.

Sincerely,
- Ray


On Thu, Jul 2, 2020, 11:45 Romain Manni-Bucau, 
wrote:

> Congrats Ray, well deserved!
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le jeu. 2 juil. 2020 à 17:39, Coty Sutherland  a
> écrit :
>
>> Congrats and welcome!
>>
>> On Thu, Jul 2, 2020 at 10:40 AM Mark Thomas  wrote:
>>
>>> On behalf of the Tomcat committers I am pleased to announce that
>>> Raymond Augé (rotty3000) has been voted in as a new Tomcat committer.
>>>
>>> Please join me in welcoming him.
>>>
>>> Kind regards,
>>>
>>> Mark
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>

Tomcat JDBCRealm using DIGEST authentication not producing the expected HASH using a SALT

[Hugh Roberts]

Tomcat 9.0.36
JDK 1.8.0_251

We are trying to use Tomcat JDBCRealm to access user credentials stored in
Oracle DB. The user password is hashed with a SALT and stored in a table.

*ISSUE:* We can authenticate using the BASIC auth-method while passing the
hashed string of the password but the DIGEST auth-method fails to create
the matching hash of the user password after configuring the realm-name
with the SALT and using the CredentialHandler
MessageDigestCredentialHandler.

The user HASH password is created using Oracle DBMS_CRYPTO by taking the
SALT combined with the password to create a raw string that is then HASHED

Using Tomcat DIGEST command, we can successfully create the user's matching
HASH on the command line as follows: *digest.bat -a SHA-1 -s 0
 SALTpassword*
*SALTpassword:86a0e40af8c1a0e970f9432bee75bcc886145440* (the other formats
for using the SALT does not produce a matching HASH -
UserName:Realm:Password) BUT we cannot authenticate when using the Tomcat
authentication form in the browser. The password hash is not matching. We
cannot tell how the form is using the SALT to hash the password to see
where the issue is.

Can you tell us exactly how Tomcat authentication form uses the SALT
configured in the web.xml file to create the password hash. If it hashes
the SALT and password as one string or uses another method?


server.xml
...




web.xml
 ...
DIGEST
SALT

Re: [ANN] New committer: Raymond Augé

[Romain Manni-Bucau]

Congrats Ray, well deserved!

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 2 juil. 2020 à 17:39, Coty Sutherland  a
écrit :

> Congrats and welcome!
>
> On Thu, Jul 2, 2020 at 10:40 AM Mark Thomas  wrote:
>
>> On behalf of the Tomcat committers I am pleased to announce that
>> Raymond Augé (rotty3000) has been voted in as a new Tomcat committer.
>>
>> Please join me in welcoming him.
>>
>> Kind regards,
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

RE: [ANN] New committer: Raymond Augé

[jonmcalexander]

Welcome and Congratulations!


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

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

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

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

-Original Message-
From: Mark Thomas  
Sent: Thursday, July 2, 2020 9:41 AM
To: Tomcat Developers List ; Tomcat Users List 

Subject: [ANN] New committer: Raymond Augé

On behalf of the Tomcat committers I am pleased to announce that Raymond Augé 
(rotty3000) has been voted in as a new Tomcat committer.

Please join me in welcoming him.

Kind regards,

Mark

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

Re: [ANN] New committer: Raymond Augé

[Coty Sutherland]

Congrats and welcome!

On Thu, Jul 2, 2020 at 10:40 AM Mark Thomas  wrote:

> On behalf of the Tomcat committers I am pleased to announce that
> Raymond Augé (rotty3000) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>
> Kind regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

RE: Tomcat Connector issue

[George Stanchev]

To give some closure to the issue, it turned out to be networking related. 
Still not clear how cleanup of the hosts file on the client machines fixed it 
but that's what happened.

Thanks to all that chimed in earlier.

George

-Original Message-
From: George Stanchev  
Sent: Monday, June 29, 2020 9:13 AM
To: Tomcat Users List 
Subject: RE: Tomcat Connector issue

I am sorry, but any ideas how to approach this? I have eliminated the 
possibility that the client is dropping the connection so it must be something 
within IIS/Win. Switching to keep_alive=true and 
HSE_REQ_SEND_RESPONSE_HEADER_EX did not make a difference.

In the logs, occasionally I  see a variation:

start_response::jk_isapi_plugin.c (1082): HSE_REQ_SEND_RESPONSE_HEADER_EX 
failed with error=1229 (0x04cd)

one time there was

iis_write::jk_isapi_plugin.c (1283): Vector write of chunk encoded response 
failed with 1229 (0x04cd)

which means the send response headers succeeded before writing the chunk. The 
responses are generated in relatively good time so timeouts are ruled out...

All things point to connID being dropped/invalid but I can put a finger on 
anything. The only thing I that pops on Google is an old post about having to 
adjust responseBufferLimit=0 in IIS that might cause those errors. I think I 
have ruled out external firewall/intermediary dropping the connection on the 
client side. I know they have FIPS enabled on the Windows side but I cannot 
imagine that would make a difference. Calls to other virtual directories under 
that site do not exhibit this behavior. Interestingly the same is observed 
under othe OSes (Windows Server 2012) procured with their scrips...

Any help/ideas is much appreciated

George

-Original Message-
From: George Stanchev 
Sent: Tuesday, June 23, 2020 10:31 AM
To: Tomcat Users List 
Subject: RE: Tomcat Connector issue

Thanks all for the responses. It is on AWS VM machine that I don't have access 
to. I've googed the crap of x57 but besides some Bugzilla report from Adobe 
that seemed unrelated nothing good comes out of Google. x57 as Mark said is bad 
parameter and it is a generic error meaning either the p->lpEcb->ConnID is 
invalid or something is wrong with the headers or their sizes. Also chunking is 
off so keep-alive is JK_FALSE. I can try to enable the chunking to see if I can 
fork the execution into the HSE_REQ_SEND_RESPONSE_HEADER_EX call on 
jk_isapi_plugin.c#1066 and if it would make a difference. The headers from TC 
on the 302 response are pretty vanilla and I cannot imagine headers+sizes are 
wrong which leaves p->lpEcb->ConnID. I have omitted the actual binary dump of 
the AJP message because it is from a customer and didn't want to disclose their 
hostname but I can obfuscate it and post it if we think it is related to the 
issue.

For now forking into the _EX call is the only idea I have to explore...

Asked to procur another VM image in case something is wrong with IIS but it is 
a problem for them...

Any ideas on how to even approach this are much appreciated...

George

-Original Message-
From: Mark Thomas 
Sent: Tuesday, June 23, 2020 9:42 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat Connector issue

On 23/06/2020 16:35, Christopher Schultz wrote:
> 
> 
> On 6/23/20 11:32, Mark Thomas wrote:
>> On 23/06/2020 16:20, Christopher Schultz wrote:
>>> George,
>>>
>>> On 6/22/20 17:13, George Stanchev wrote:
 We are getting HSE_REQ_SEND_RESPONSE_HEADER failed with
 error=87 (0x0057) on a 302 redirect proxied by TC connector 
 1.2.46.
>>> Windows error 0x0057 is ... "Cannot connect to printer"???
> 
>> Not sure where you found that. 0x57 is "Invalid Parameter"
> 
> Yeah, it sounded weird. Searching Google for "windows 0x0057" (at 
> least here in the US) gives a million pages about errors connecting to 
> printers, like this one which is the top-hit for me with expanded
> explanation:
> 
> https://appuals.com/fix-printer-error-0x0057/
> 
> "
> Error 0x0057 is a printer related error on Windows which does not 
> allow the user to add the printer. This error is usually due to 
> corrupt drivers previously installed and the permission issues. ...
> The 1st one would delete the driver and the second method would be to 
> copy the driver from a working computer.
> "
> 
> I don't have a "perror" program for Windows handy right now, so I just 
> tried Google :/

For the archives:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

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

[ANN] New committer: Raymond Augé

[Mark Thomas]

On behalf of the Tomcat committers I am pleased to announce that
Raymond Augé (rotty3000) has been voted in as a new Tomcat committer.

Please join me in welcoming him.

Kind regards,

Mark

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

Re: Problem with JarScanFilter, maybe a bug?

[Mark Thomas]

On 02/07/2020 14:14, Vitor Medina Cruz wrote:
> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas  wrote:



>> @WebFiler, @WebListener and @WebServlet are deployment annotations so
>> scanning for these is controlled by the JarScanner.
>>
>> If an SCI has an @HandlesTypes annotation then all JARs that are
>> potential SCI sources will be scanned for matches. To put it another
>> way, the JarScanner configuration does NOT control the search for
>> @HandlesTypes matches. Any JAR eligible to provide an SCI will be
>> scanned for @HandlesTypes. Those JARs are controlled by 
>>
> 
> Ok, and if a jar doesn't provide a web-fragment name? In this old post(
> http://tomcat.10.x6.nabble.com/Why-does-absolute-ordering-in-web-xml-without-others-kill-classpath-scanning-td5029985.html)
> it is said :
> 
> "Tomcat will give these a name equal to the name of the JAR file so you can
> use it in ordering. That is a Tomcat specific feature."
> 
> This is/holds true? I tried with no success

It should do. So for foobar-0.3.jar the name should be "foobar-0.3.jar"

Mark

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

Re: Tomcat Large Payload Truncated

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bhavesh,

On 6/29/20 22:12, Bhavesh Mistry wrote:
> Hi Mark,
>
> Thank you for responding.  I have one more question.  This is
> spring-boot 2 application REST API server and it does not accept
> Cookie or session (timeout is set to zero).Auth happens through
> Authorized header. We have set 10mb for maxPostSize.  Does
> maxSavePostSize takes precedence over maxPostSize ?  I will set
> maxSavePostSize to -1 to disable it.

Sounds like what you really want to use is:

Expect: 100-continue

And then only send the 10MiB payload if you get a "100 Continue" respons
e.

> Also, I have another question.  When Payload is as large as 10mb
> (json post),  does payload body in JVM MEMORY or offloaded to
> FileInputStream ?

That depends upon how you are doing authentication. When you say
authentication is done "through an authorized header", are you saying
that Tomcat is performing the authentication or not? Is Tomcat saving
the request and asking the client to authenticate) as it does with
e.g. FORM login? Or does your application reject the request with a
response header and the client has to re-try with the authenticated
header AND the large JSON request again?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl796fcACgkQHPApP6U8
pFjjJw/6AwoXu4eTXa86JvHn8qP1m9fls+AMjQBM3VePfEKxa0LibjiPGxwjsy7/
SstRvv+8rJ5Tan6IdGgSFr+BsHXDgWa/4Q+PirpjIjcO7xOMlvsHC0xaA8sNSKhD
DbK0sCrrKuvixX3AwUCXz0wuTHrZBFmznvVkM0rh+/XXJxq5n5yd18J36KqIaR7d
a1eef8cbPkPo+ds9ci3VYsy50TtEmI6tGdjQMMko1QxnXcUHzz/pTjDN5qttE4g1
+K9CI4zG8qYVuMEvoW+679knq9UUWLeeBO71T7TQea2WJkoyMw9UY2ksH7SIstlY
+GhXs8/fWQ+YdZ+eYxnkuNXOOes8L/UvC0+Ea13Y8u1eiD7INXsGhc1gTrZ+ct16
i4jGM1GYhHMxFDsXcs5uhL1/7ew+EgTR3dBuNsrYKASN/5DTpIlcIa+xpqb2uoyL
Irf9jGkRbNYneI52Woopf1SGAT+hCqGt7yiN7grVdyo3pUA82xqcuM/SwLilyEru
LkkS6nQz1l2YUQi2U1OYwYdt3NxlD94FmGmhzEBPaw2hYvXwrPMBYTY3iuEueOqZ
2L3DE/K/f8CX+0ogJZKMU+KbZ2itW7DL1183AwiZx9Y19i1nr6pjyb7ius+f0zkr
ML9x7mYrRLyL12kkwbLdOgx/xmsflOC1WQCElJ/sib7dS6V/skg=
=ty2B
-END PGP SIGNATURE-

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

Re: Having trouble with tomcat 7 installation on RHEL 7.8 power pc

[Sean Neeley]

On Thu, Jul 2, 2020 at 7:21 AM Coty Sutherland  wrote:

> The RHEL 7 Tomcat package uses systemd and the journal to capture stdout
> instead of catalina.out. Did you check the journal to see if the thread
> dumps are logged there from your invocations of kill -3? You can use
> `journalctl -u tomcat` to check it.
>
> On Wed, Jul 1, 2020 at 6:58 PM Sean Neeley 
> wrote:
>
> > On Wed, Jul 1, 2020 at 5:24 PM calder  wrote:
> >
> > > On Wed, Jul 1, 2020, 15:32 Sean Neeley 
> > wrote:
> > >
> > > > I tried switching from Java 1.8 to Java 11 to see if that makes a
> > > > difference.  Now the VM Thread is using a lot less CPU:
> > > >
> > > >   PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+
> > > COMMAND
> > > >  2320 tomcat20   0 4659072  47872  19904 R 99.9  0.6  22:15.16
> java
> > > >  2326 tomcat20   0 4659072  47872  19904 R  4.6  0.6   0:56.43 VM
> > > > Thread
> > > >
> > > > I tried running jstack on the processes, but I get this:
> > > >
> > > > 2320: Unable to open socket file: target process not responding or
> > > HotSpot
> > > > VM not loaded
> > > >
> > >
> > > Did you attempt to run the command as the "Tomcat user"?
> > >
> > > BTW,  Oracle recommends the use of "jcmd" over "jstack". Personally,
> I'd
> > > give Mission Control/Flight Recorder a go.
> > >
> >
> > I'm definitely running it as the tomcat user.  I just tried jcmd with no
> > arguments and the command completely hangs.  The only way to terminate it
> > is a kill -9.  This seems almost like an OS level issue.  We are opening
> a
> > ticket with Red Hat support to see what they say.
> >
>

Thanks for the tip Coty.  The logs show a normal start.  The kill -3 output
does not appear in the logs.  I then did a kill -9 and that showed up.
Logs:

-- Logs begin at Wed 2020-07-01 12:37:09 PDT, end at Thu 2020-07-02
06:36:59 PDT.
 --
Jul 02 06:36:31 ecom-main.spokaneproduce.com systemd[1]: Started Apache
Tomcat We
b Application Container.
-- Subject: Unit tomcat.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tomcat.service has finished starting up.
--
-- The start-up result is done.
Jul 02 06:36:32 ecom-main.spokaneproduce.com server[26466]: Java virtual
machine used: /usr/lib/jvm/jre/bin/java
Jul 02 06:36:32 ecom-main.spokaneproduce.com server[26466]: classpath used:
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
Jul 02 06:36:32 ecom-main.spokaneproduce.com server[26466]: main class
used: org.apache.catalina.startup.Bootstrap
Jul 02 06:36:32 ecom-main.spokaneproduce.com server[26466]: flags used:
Jul 02 06:36:32 ecom-main.spokaneproduce.com server[26466]: options used:
-Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
-Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
Jul 02 06:36:32 ecom-main.spokaneproduce.com server[26466]: arguments used:
start
Jul 02 06:36:59 ecom-main.spokaneproduce.com systemd[1]: tomcat.service:
main process exited, code=killed, status=9/KILL
Jul 02 06:36:59 ecom-main.spokaneproduce.com systemd[1]: Unit
tomcat.service entered failed state.
Jul 02 06:36:59 ecom-main.spokaneproduce.com systemd[1]: tomcat.service
failed.

Re: Problem with JarScanFilter, maybe a bug?

[Vitor Medina Cruz]

On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas  wrote:

> On 01/07/2020 20:28, Vitor Medina Cruz wrote:
> > On Wed, Jul 1, 2020 at 3:19 PM Mark Thomas  wrote:
> >
> >> On 01/07/2020 18:09, Vitor Medina Cruz wrote:
> >>> On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas  wrote:
> >>>
>  On 30/06/2020 14:19, Vitor Medina Cruz wrote:
> >  Hello,
> >
> > I am trying to configure Tomcat in a way that it makes SCI scan only
> in
> > jars I explicitly specify to. I followed instructions from
> > https://tomcat.apache.org/tomcat-8.5-doc/config/jar-scan-filter.htm,
> >> in
> > both Tomcat 8 and 9, but with no success. I posted a question on
> > stackoverflow that explains more in detail what I did:
> >
> 
> >>
> https://stackoverflow.com/questions/62602550/how-to-specify-which-classes-and-jars-gets-scanned-for-servlet-annotations-in-to
> >
> > And I also found other unanswered questions pointing to the same
> >> problem,
> > here is one example:
> >
> 
> >>
> https://stackoverflow.com/questions/52876216/tomcat-too-slow-scanning-for-annotations
> > .
> >
> > The thing is that it is looking like an error to me because logs
> tells
>  that
> > scanning is done as configured — if I add a jar for scanning in
> > JarScanFilter, the log show it is scanned, if I remove it, the log
> stop
> > reporting it's scanning — but after that, no matter what
> configuration
> >> I
> > made with JarScanFilter, the WebappServiceLoader loads servlet
> >> annotated
> > classes, such as @WebListener.
> 
>  The JarScanner machinery handles annotation and TLD scanning.
> 
>  WebappServiceLoader handles SCIs which are handled under the standard
>  service loader mechanism. SCIs can load classes.
> 
> > Any leads? Ideas? Anyone can confirm if that is an error or if I am
> >> using
> > the functionality wrongly or if I understand it wrongly.
> 
>  It looks like you aren't preventing the SCIs from being loaded.
> 
>  The specification isn't as clear as it could be here and there are
> still
>  a few gaps. That is being worked on at Eclipse. A useful summary of
> the
>  current position can be found at:
> 
> 
> 
> >>
> https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/catalina/startup/ContextConfig.java#L1092
> 
>  The simplest way to block the Servlet 3 pluggability features is:
> 
>  1. Add metadata-complete="true" to the web-app element in web.xml
> (disables annotation scanning for deploy time annotations -
>  Servlet 3.1, 8.1)
> 
>  2. Add  to web.xml
> (disables any SCIs - Servlet 3.1, 8.2.2.d)
> 
>  Mark
> 
> 
> >>> Thanks. I, however, don't want to block all Servlet 3 pluggability as
> >> there
> >>> are frameworks already being made with no way of configuring it other
> >> than
> >>> that
> >>
> >> You can always explicitly define configuration in web.xml.
> >>
> >>> I would like to selectively choose which jars to be scanned in
> >>> order to avoid performance issues and rogue classes to be loaded. As is
> >>> seems, nor Servlet specification nor Tomcat in specific provides a way
> of
> >>> doing that, is that correct?
> >>
> >> No.
> >>
> >> Scanning != SCI loading.
> >>
> >> Scanning for deployment annotations can be controlled by the JarScanner.
> >>
> >> SCI loading can be controlled by an  element that
> >> includes the JARs from which you do want to load SCIs.
> >>
> >>
> > But how can SCI loading takes place without scanning? That was what I
> > thought when I tried to control SCI loads, if I didn't scan any class at
> > all then no SCI should be loaded since no annotations will be found, but
> > that is not the case, so SCI loading must be doing an independent
> scanning
> > on it's own.
>
> No.
>
> SCIs are discovered via the service loader mechanism.
>
> Deployment annotations are discovered via JAR scanning.
>
> These are completely separate mechanisms.
>
> Note that an SCI may load and configure Servlets, Filters, Listeners etc.
>
>
Humm, ok, thanks, I understand now.



> > In any way, leaving behind internal machinery, is it possible to define
> in
> > Tomcat which jars should be considered for annotation processing and SCI
> > loading, and which not?
>
> Yes.
>
> JarScanner for deployment annotations.
>
>  for SCIs and @HandlesTypes matches.
>
> > I wanna tell Tomcat to only look and load for
> > @WebFiler, @WebListener, @WebServlet, @HandlesTypes and etc on specific
> > jars. Is that possible?
>
> @WebFiler, @WebListener and @WebServlet are deployment annotations so
> scanning for these is controlled by the JarScanner.
>
> If an SCI has an @HandlesTypes annotation then all JARs that are
> potential SCI sources will be scanned for matches. To put it another
> way, the JarScanner configuration does NOT control the search for
> @HandlesTypes matches. Any JAR eligible to provide an SCI will be
> 

Re: Having trouble with tomcat 7 installation on RHEL 7.8 power pc

[Coty Sutherland]

The RHEL 7 Tomcat package uses systemd and the journal to capture stdout
instead of catalina.out. Did you check the journal to see if the thread
dumps are logged there from your invocations of kill -3? You can use
`journalctl -u tomcat` to check it.

On Wed, Jul 1, 2020 at 6:58 PM Sean Neeley 
wrote:

> On Wed, Jul 1, 2020 at 5:24 PM calder  wrote:
>
> > On Wed, Jul 1, 2020, 15:32 Sean Neeley 
> wrote:
> >
> > > I tried switching from Java 1.8 to Java 11 to see if that makes a
> > > difference.  Now the VM Thread is using a lot less CPU:
> > >
> > >   PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+
> > COMMAND
> > >  2320 tomcat20   0 4659072  47872  19904 R 99.9  0.6  22:15.16 java
> > >  2326 tomcat20   0 4659072  47872  19904 R  4.6  0.6   0:56.43 VM
> > > Thread
> > >
> > > I tried running jstack on the processes, but I get this:
> > >
> > > 2320: Unable to open socket file: target process not responding or
> > HotSpot
> > > VM not loaded
> > >
> >
> > Did you attempt to run the command as the "Tomcat user"?
> >
> > BTW,  Oracle recommends the use of "jcmd" over "jstack". Personally, I'd
> > give Mission Control/Flight Recorder a go.
> >
>
> I'm definitely running it as the tomcat user.  I just tried jcmd with no
> arguments and the command completely hangs.  The only way to terminate it
> is a kill -9.  This seems almost like an OS level issue.  We are opening a
> ticket with Red Hat support to see what they say.
>

Re: Tomcat 9.0.36 - JDK 13/14

[tomcat/perl]

On 02.07.2020 10:23, Utkarsh Bhargav wrote:

Please i have resolved my issue Kindly stop sending mails



Hi. You receive these emails because you subscribed to the email list 
"users@tomcat.apache.org".
To not receive these emails anymore, you should unsubscribe from the list, be sending an 
email (from the same email address which you used to subscribe), *as indicated at the end 
of every email that you receive from the list*.

(including this one)

[...]


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

Re: Tomcat 9.0.36 - JDK 13/14

[Utkarsh Bhargav]

Please i have resolved my issue Kindly stop sending mails

On Tue, 30 Jun, 2020, 5:53 AM Kiran Badi,  wrote:

> Hi Mark,  It does not log any errors. Just reverted back to the JDK1.8
> version and tried to recreate the issue. I can recreate it. I had a doubt
> that the logging configuration might have messed up, so had to create a
> sample war file to check this.
>
> Anyone can try this and see if it works for them. Just build a simple
> spring boot app with jdk 13/14 and deploy it on the latest tomcat running
> on jdk 1.8. Maybe something is messed up in my environment.
>
> Here is console catalina.out log along with same use case classes from
> spring site.
>
> 29-Jun-2020 20:19:24.852 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server version name:
>  Apache Tomcat/9.0.36
> 29-Jun-2020 20:19:24.854 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server built:
>   Jun 3 2020 17:07:09 UTC
> 29-Jun-2020 20:19:24.854 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server version
> number: 9.0.36.0
> 29-Jun-2020 20:19:24.854 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log OS Name:
>  Windows 10
> 29-Jun-2020 20:19:24.855 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log OS Version:
>   10.0
> 29-Jun-2020 20:19:24.855 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Architecture:
>   amd64
> 29-Jun-2020 20:19:24.855 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Java Home:
>  C:\Program Files\Java\jdk1.8.0_221\jre
> 29-Jun-2020 20:19:24.855 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log JVM Version:
>  1.8.0_221-b11
> 29-Jun-2020 20:19:24.855 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
>   Oracle Corporation
> 29-Jun-2020 20:19:24.855 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:
>  C:\Program Files\Apache Software Foundation\apache-tomcat-9.0.36
> 29-Jun-2020 20:19:24.855 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:
>  C:\Program Files\Apache Software Foundation\apache-tomcat-9.0.36
> 29-Jun-2020 20:19:24.856 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.util.logging.config.file=C:\Program Files\Apache Software
> Foundation\apache-tomcat-9.0.36\conf\logging.properties
> 29-Jun-2020 20:19:24.856 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> 29-Jun-2020 20:19:24.857 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djdk.tls.ephemeralDHKeySize=2048
> 29-Jun-2020 20:19:24.857 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> 29-Jun-2020 20:19:24.857 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dignore.endorsed.dirs=
> 29-Jun-2020 20:19:24.857 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dcatalina.base=C:\Program Files\Apache Software
> Foundation\apache-tomcat-9.0.36
> 29-Jun-2020 20:19:24.857 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dcatalina.home=C:\Program Files\Apache Software
> Foundation\apache-tomcat-9.0.36
> 29-Jun-2020 20:19:24.858 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.io.tmpdir=C:\Program Files\Apache Software
> Foundation\apache-tomcat-9.0.36\temp
> 29-Jun-2020 20:19:24.860 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache
> Tomcat Native library which allows using OpenSSL was not found on the
> java.library.path: [C:\Program
>
> Files\Java\jdk1.8.0_221\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Python38\Scripts\;C:\Python38\;C:\app\oracle\product\12.2.0\dbhome_1\bin;C:\Python27\;C:\Python27\Scripts;C:\Program
> Files (x86)\Common
>
> Files\Oracle\Java\javapath;C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program
> Files\Apache Software Foundation\apache-maven-3.3.9\bin;C:\Program
> Files\Java\jdk1.8.0_121;C:\Program Files\PuTTY\;C:\Program
> Files\Git\cmd;C:\Program Files
>
> (x86)\Calibre2\;C:\WINDOWS\System32\OpenSSH\;C:\ProgramData\chocolatey\bin;C:\Program
> Files\AdoptOpenJDK\jdk8u192-b12\bin;C:\Program
>
> Files\Java\jdk1.8.0_221\bin;C:\Android\android-sdk\tools;C:\Android\android-sdk\platform-tools;C:\Android\android-sdk\tools\bin;C:\Program
>
> Files\dotnet\;C:\Users\KIRAN\AppData\Local\Microsoft\WindowsApps;C:\Users\KIRAN\AppData\Local\Programs\Fiddler;C:\Users\KIRAN\AppData\Local\Microsoft\WindowsApps;C:\Program
> Files\JetBrains\IntelliJ IDEA
>