Re: Tomcat throwing 404 error after modifying context.xml

[M. Manna]

Have you read what resource definitions mean from -
https://tomcat.apache.org/tomcat-8.5-doc/config/context.html ?

On 22 February 2018 at 08:32, Howlader, Aakash [GTSUS Non-J] <
ahowl...@its.jnj.com> wrote:

> Hello,
>
> The jdbc url  "url="jdbc:postgresql://itsusralsp06829:5432/spectra"
> points to a postgre db in another host.
> We tried to modify the maxActive parameter. The other parameters were left
> untouched.
>
>
> This is what the property was in the original context.xml
>
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
>  >
>  >   > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xxx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
>
> This is the change we made.
>
> >  > type="javax.sql.DataSource" maxActive="2" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
>  >
>  >   > type="javax.sql.DataSource" maxActive="2" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xxx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
>
> Not sure why the jdbc url should change. Could you shed some light on this?
>
>
> -Original Message-
> From: M. Manna [mailto:manme...@gmail.com]
> Sent: Thursday, February 22, 2018 4:09 AM
> To: Tomcat Users List 
> Cc: DL-MD-R 
> Subject: [EXTERNAL] Re: Tomcat throwing 404 error after modifying
> context.xml
>
> Your jdbc url and context path have changed. Have you updated how and
> where you are requesting it? 404 means Not Found. So your requesting for
> something non-existent.
> Please chill and confirm.
>
> On Wed, 21 Feb 2018 at 22:32, Howlader, Aakash [GTSUS Non-J] <
> ahowl...@its.jnj.com> wrote:
>
> > Hello,
> >
> > We were facing a "pool error timeout waiting for idle object" issue.
> > To replicate that in lower environments and perform tests, we tried to
> > make changes to the contex.xml file located under the conf directory
> > of tomcat.
> > The path is /apps/apache-tomcat-7.0.67/conf/context.xml
> >
> > The properties we were modifying are given below .
> >
> > >  > > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > > maxWait="1" username="saevdcep" password="xx"
> > > driverClassName="org.postgresql.Driver"
> > > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
> > >
> > >  > > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > > maxWait="1" username="saevdcep" password="xxx"
> > > driverClassName="org.postgresql.Driver"
> > > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
> >
> > However, on restarting the tomcat server after making changes to
> > values in these, the application is throwing a 404: Resource not Found
> > error. The tomcat server is up and running but on hitting the
> > application URL, we are getting the 404 error.
> >
> > We even tried restoring the context.xml file to its original values
> > but that did not seem to  make a difference.
> >
> > Can you  please let us know what steps we need to follow in order to
> > be able to make modifications to the file and perform our tests?
> >
> > Best Regards,
> > Aakash
> >
> >
>

RE: Tomcat throwing 404 error after modifying context.xml

[Howlader, Aakash [GTSUS Non-J]]

Hello,

The jdbc url  "url="jdbc:postgresql://itsusralsp06829:5432/spectra" points to a 
postgre db in another host. 
We tried to modify the maxActive parameter. The other parameters were left 
untouched.


This is what the property was in the original context.xml

> type="javax.sql.DataSource" maxActive="50" maxIdle="30"
 > maxWait="1" username="saevdcep" password="xx"
 > driverClassName="org.postgresql.Driver"
 > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
 >
 >  type="javax.sql.DataSource" maxActive="50" maxIdle="30"
 > maxWait="1" username="saevdcep" password="xxx"
 > driverClassName="org.postgresql.Driver"
 > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>


This is the change we made.

> type="javax.sql.DataSource" maxActive="2" maxIdle="30"
 > maxWait="1" username="saevdcep" password="xx"
 > driverClassName="org.postgresql.Driver"
 > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
 >
 >  type="javax.sql.DataSource" maxActive="2" maxIdle="30"
 > maxWait="1" username="saevdcep" password="xxx"
 > driverClassName="org.postgresql.Driver"
 > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>


Not sure why the jdbc url should change. Could you shed some light on this?


-Original Message-
From: M. Manna [mailto:manme...@gmail.com] 
Sent: Thursday, February 22, 2018 4:09 AM
To: Tomcat Users List 
Cc: DL-MD-R 
Subject: [EXTERNAL] Re: Tomcat throwing 404 error after modifying context.xml

Your jdbc url and context path have changed. Have you updated how and where you 
are requesting it? 404 means Not Found. So your requesting for something 
non-existent.
Please chill and confirm.

On Wed, 21 Feb 2018 at 22:32, Howlader, Aakash [GTSUS Non-J] < 
ahowl...@its.jnj.com> wrote:

> Hello,
>
> We were facing a "pool error timeout waiting for idle object" issue.
> To replicate that in lower environments and perform tests, we tried to 
> make changes to the contex.xml file located under the conf directory 
> of tomcat.
> The path is /apps/apache-tomcat-7.0.67/conf/context.xml
>
> The properties we were modifying are given below .
>
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > maxWait="1" username="saevdcep" password="xx"
> > driverClassName="org.postgresql.Driver"
> > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
> >
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > maxWait="1" username="saevdcep" password="xxx"
> > driverClassName="org.postgresql.Driver"
> > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
> However, on restarting the tomcat server after making changes to 
> values in these, the application is throwing a 404: Resource not Found 
> error. The tomcat server is up and running but on hitting the 
> application URL, we are getting the 404 error.
>
> We even tried restoring the context.xml file to its original values 
> but that did not seem to  make a difference.
>
> Can you  please let us know what steps we need to follow in order to 
> be able to make modifications to the file and perform our tests?
>
> Best Regards,
> Aakash
>
>

tomcat 8.5 gives RC 400 sometimes?

[Lou DeGenaro]

tomcat version = 8.5.5

Requests for same file sometimes get 200 and sometime 400.  How come?

>From log file:

192.168.1.1 - - [22/Feb/2018:05:48:57 -0500] "GET /
whiteplainshistory.org//local/images/icons/Heritage_Trail.jpg HTTP/1.1" 400
-

192.168.1.1 - - [22/Feb/2018:05:49:05 -0500] "GET /
whiteplainshistory.org//local/images/icons/Heritage_Trail.jpg HTTP/1.1" 200
3207

Thanks.

Lou.

Re: Http with client certificate authentication

[Mark Thomas]

On 22/02/18 03:23, Alex O'Ree wrote:
> Howdy folks,
> 
> If I setup a tomcat connector in server.xml with clientAuth="true" and have
> the key store for tomcat and a trust store is the following true?
> 
> - all public key certificates issued by CA's the trust store are allowed in?

Yes.

> - all user public key certificates in the trust store are allowed in
> (assuming their CA's are also in the same trust store)?

Yes. There is no requirement for the issuing cert and associated chain
to a CA to be in the trust store.

> - are the JRE's "cacert" file merged in with this trust store? (this is
> normally the case but i figured i'd ask for clarity)

No.


> Finally regarding certificate validation:
> - i'm assuming basic validation checks are performed, time checks, etc

Any cert in the trust store is fully trusted without ANY validation.

Certificates not in the trust store are validated as are all certs in
the issuing chain until a cert in the trust store is reached. If no
trusted cert is reached, the client cert is rejected.

> - if the requesting user cert has a CRL or OCSP url attached to the cert,
> does tomcat do anything to validate that the cert is still valid?

CRLs should be checked if configured. Note that they are probably only
read once at Tomcat start and then cached.

OCSP requires tomcat-native

> Regarding OCSP, I did see some documentation in the guides related to
> windows native connector but I don't think i'm using that and would prefer
> to remain portable to linux if possible. It's also not clear from the docs
> on how or why it's used.

tomcat-native provides a bridge to OpenSSL. It is generally used because
it is faster than JSSE. It is available for all platforms although
binaries are only provided for Windows.

Mark

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

Re: tomcat 8.5 gives RC 400 sometimes?

[Mark Thomas]

On 22/02/18 11:15, Lou DeGenaro wrote:
> tomcat version = 8.5.5
> 
> Requests for same file sometimes get 200 and sometime 400.  How come?

The request is invalid in some way. Probably an illegal HTTP header value.

Mark


> 
> From log file:
> 
> 192.168.1.1 - - [22/Feb/2018:05:48:57 -0500] "GET /
> whiteplainshistory.org//local/images/icons/Heritage_Trail.jpg HTTP/1.1" 400
> -
> 
> 192.168.1.1 - - [22/Feb/2018:05:49:05 -0500] "GET /
> whiteplainshistory.org//local/images/icons/Heritage_Trail.jpg HTTP/1.1" 200
> 3207
> 
> Thanks.
> 
> Lou.
> 


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

Re: TomcatCon at ApacheCon?

[Mark Thomas]

On 22/02/18 16:21, David Cleary wrote:
> Mark,
> 
> Will there be a TomcatCon within ApacheCon this year?

Yes. Both at the EU roadshow in Berlin (we are aiming for a one track of
content for a day) and at the NA conference in Montreal. How much
content there is at Montreal is TBD but it should be at least a day and
possibly more (we had three days in Miami).

There is also the possibility of running some training in Montreal.

Mark

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

TomcatCon at ApacheCon?

[David Cleary]

Mark,

Will there be a TomcatCon within ApacheCon this year?

Dave

problems with tomcat 8.5.5

[Lou DeGenaro]

>From catalina.out, NPE seems bad.  Other log files have NPEs too.  Need a
never version of tomcat?

Thanks.

Lou.

-

22-Feb-2018 16:37:28.599 SEVERE [http-nio-8080-exec-29]
org.apache.coyote.http11.Http11Processor.endRequest Error finishing response
 java.lang.NullPointerException

22-Feb-2018 16:41:22.340 SEVERE [http-nio-8080-exec-34]
org.apache.coyote.http11.Http11Processor.service Error processing request
 java.lang.NullPointerException

22-Feb-2018 16:41:22.340 SEVERE [http-nio-8080-exec-34]
org.apache.coyote.http11.Http11Processor.endRequest Error finishing response
 java.lang.NullPointerException

22-Feb-2018 16:41:22.341 SEVERE [http-nio-8080-exec-33]
org.apache.coyote.http11.Http11Processor.endRequest Error finishing response
 java.lang.NullPointerException
at
org.apache.coyote.http11.Http11OutputBuffer.commit(Http11OutputBuffer.java:332)
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1288)
at
org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:261)
at
org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java:1457)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:823)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

22-Feb-2018 17:45:20.128 SEVERE [http-nio-8080-exec-41]
org.apache.coyote.http11.Http11Processor.service Error processing request
 java.lang.NullPointerException
at
org.apache.coyote.http11.Http11OutputBuffer.commit(Http11OutputBuffer.java:332)
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1288)
at
org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:261)
at org.apache.coyote.Response.action(Response.java:169)
at org.apache.coyote.Response.sendHeaders(Response.java:351)
at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:322)
at
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:281)
at
org.apache.catalina.connector.Response.finishResponse(Response.java:484)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:784)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

22-Feb-2018 17:45:20.130 SEVERE [http-nio-8080-exec-41]
org.apache.coyote.http11.Http11Processor.endRequest Error finishing response
 java.lang.NullPointerException

Re: problems with tomcat 8.5.5

[M. Manna]

Can you please check the changelog for 8.5.x and see if this was fixed?

Regards,

On Thu, 22 Feb 2018 at 23:11, Lou DeGenaro  wrote:

> From catalina.out, NPE seems bad.  Other log files have NPEs too.  Need a
> never version of tomcat?
>
> Thanks.
>
> Lou.
>
> -
>
> 22-Feb-2018 16:37:28.599 SEVERE [http-nio-8080-exec-29]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response
>  java.lang.NullPointerException
>
> 22-Feb-2018 16:41:22.340 SEVERE [http-nio-8080-exec-34]
> org.apache.coyote.http11.Http11Processor.service Error processing request
>  java.lang.NullPointerException
>
> 22-Feb-2018 16:41:22.340 SEVERE [http-nio-8080-exec-34]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response
>  java.lang.NullPointerException
>
> 22-Feb-2018 16:41:22.341 SEVERE [http-nio-8080-exec-33]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response
>  java.lang.NullPointerException
> at
>
> org.apache.coyote.http11.Http11OutputBuffer.commit(Http11OutputBuffer.java:332)
> at
>
> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1288)
> at
> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:261)
> at
>
> org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java:1457)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:823)
> at
>
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
>
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802)
> at
> org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)
> at
> org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> 22-Feb-2018 17:45:20.128 SEVERE [http-nio-8080-exec-41]
> org.apache.coyote.http11.Http11Processor.service Error processing request
>  java.lang.NullPointerException
> at
>
> org.apache.coyote.http11.Http11OutputBuffer.commit(Http11OutputBuffer.java:332)
> at
>
> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1288)
> at
> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:261)
> at org.apache.coyote.Response.action(Response.java:169)
> at org.apache.coyote.Response.sendHeaders(Response.java:351)
> at
> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:322)
> at
> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:281)
> at
> org.apache.catalina.connector.Response.finishResponse(Response.java:484)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:784)
> at
>
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
>
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802)
> at
> org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)
> at
> org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> 22-Feb-2018 17:45:20.130 SEVERE [http-nio-8080-exec-41]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response
>  java.lang.NullPointerException
>

[SECURITY] CVE-2018-1305 Security constraint annotations applied too late

[Mark Thomas]

CVE-2018-1305 Security constraint annotations applied too late

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.4
Apache Tomcat 8.5.0 to 8.5.27
Apache Tomcat 8.0.0.RC1 to 8.0.49
Apache Tomcat 7.0.0 to 7.0.84

Description:
Security constraints defined by annotations of Servlets were only
applied once a Servlet had been loaded. Because security constraints
defined in this way apply to the URL pattern and any URLs below that
point, it was possible - depending on the order Servlets were loaded -
for some security constraints not to be applied. This could have exposed
resources to users who were not authorised to access them.

Mitigation:
Users of the affected versions should apply one of the following
mitigations. Upgrade to:
- Apache Tomcat 9.0.5 or later
- Apache Tomcat 8.5.28 or later
- Apache Tomcat 8.0.50 or later
- Apache Tomcat 7.0.85 or later

Credit:
This issue was identified by the Apache Tomcat Security Team.

History:
2018-02-23 Original advisory

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html


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

[SECURITY] CVE-2018-1304 Security constraints mapped to context root are ignored

[Mark Thomas]

CVE-2018-1304 Security constraints mapped to context root are ignored

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.4
Apache Tomcat 8.5.0 to 8.5.27
Apache Tomcat 8.0.0.RC1 to 8.0.49
Apache Tomcat 7.0.0 to 7.0.84

Description:
The URL pattern of "" (the empty string) which exactly maps to the
context root was not correctly handled when used as part of a security
constraint definition. This caused the constraint to be ignored. It was,
therefore, possible for unauthorised users to gain access to web
application resources that should have been protected. Only security
constraints with a URL pattern of the empty string were affected.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Review security constraints and confirm none use a URL patten of ""
  (the empty string)
- Upgrade to Apache Tomcat 9.0.5 or later
- Upgrade to Apache Tomcat 8.5.28 or later
- Upgrade to Apache Tomcat 8.0.50 or later
- Upgrade to Apache Tomcat 7.0.85 or later

Credit:
This issue was reported publicly as bug 62067 and the security
implications identified by the Apache Tomcat Security Team.

History:
2018-02-23 Original advisory

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html


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

RE: Tomcat 8.5.23

[Felix Schumacher]

Am 15. Februar 2018 19:25:24 MEZ schrieb Lawrence Lim 
:
>Red Hat Enterprise Linux Server release 6.9 (Santiago)

How did you install tomcat? 
Are you running tomcat with some kind of security manager enabled (Java or 
system wide)? 
Can the tomcat user (running the process) write to the filesystem?

Regards, 
Felix 

>
>Yes. I did check the logs. It does not log anything when I deploy. But,
>it logs something when I undeploy. 
>
>Lawrence Lim  
>Software Developer
>-
>
>ENBRIDGE
>TEL: 780-969-6208
>10175 101 St NW,  Edmonton, Alberta T5J 0H3
>
>enbridge.com
>Integrity. Safety. Respect.
>
>-Original Message-
>From: Satish Chhatpar 02 [mailto:chhatp...@cpwplc.com] 
>Sent: Thursday, February 15, 2018 10:58 AM
>To: users@tomcat.apache.org
>Subject: [External] Re: Tomcat 8.5.23
>
>Which operating system?
>Did you check the logs?
>
>Sent using OWA for iPhone
>
>From: Lawrence Lim 
>Sent: Thursday, February 15, 2018 11:09:54 PM
>To: users@tomcat.apache.org
>Subject: Tomcat 8.5.23
>
>Hi,
>
>
>
>I just installed tomcat 8.5.23. I am having problems deploying web apps
>via manager. To reproduce:
>
>
>
>1.   Login to tomcat manager
>
>
>
>2.   Go to " WAR file to deploy"
>
>
>
>3.   Pick a war file
>
>
>
>
>
>Error message: FAIL - File upload failed, no file
>
>
>
>
>
>Workaround: Copy war file to the tomcat webapps directory
>
>
>
>
>
>I also tried using localhost:8080, same result. So, it's not some weird
>networking constraint.
>
>
>Lawrence Lim
>Software Developer
>-
>
>ENBRIDGE
>TEL: 780-969-6208
>10175 101 St NW,  Edmonton, Alberta T5J 0H3
>
>enbridge.com
>Integrity. Safety. Respect.
>
>::DISCLAIMER::
>
>Confidentiality Notice from Dixons Carphone plc (registered in England
>& Wales No.07105905) of 1 Portal Way, London, W3 6RS ("Dixons
>Carphone"). The information contained in this e-mail and any
>attachments may be legally privileged, proprietary and/or confidential.
>If you received this e-mail in error, please notify the sender by
>return, permanently delete the e-mail and destroy all hard copies
>immediately. No warranty is made as to the completeness or accuracy of
>the information contained in this e-mail. Opinions, conclusions and
>statements of intent in this e-mail are those of the sender and will
>not bind any Dixons Carphone group company (Dixons Carphone Group)
>unless confirmed by an authorised representative independently of this
>e-mail. We do not accept responsibility for viruses; you must scan for
>these. E-mails sent to and from Dixons Carphone Group are routinely
>monitored for record keeping, quality control, training purposes, to
>ensure regulatory compliance and to prevent viruses and unauthorised
>use of our computer systems. The Carphone Warehouse Limited (registered
>in England & Wales No.02142673) is a member of the Dixons Carphone
>Group and is authorised and regulated by the Financial Conduct
>Authority.
>
>
>-
>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: error creating connection pool

[Felix Schumacher]

Am 13. Februar 2018 15:20:00 MEZ schrieb "Bruce L. Riddle" 
:
>We are running a CDC Application PHIN MS that uses Tomcat 8.5.11.
>
>As the application starts, we are getting a message that says
>
>'error creating connection pool for dbid.'
>
>
>Our assumption is that the message is coming from TomCat.  Please,
>
>what does the message mean and how to we research a possible
>
>resolution?

Have you looked in other log files for error messages? I can only guess some 
possible misinformed from the given one (which I believe is a message generated 
by the app and not tomcat) 

Check that
 * you have configured a database resource
 * the DB resource has the correct name (equal to the one configured in your 
app) 
 * you have placed the db driver jar in a directory the app or rather tomcat 
expects it

Regards, 
Felix 
>
>
>Thanks.
>
>
>A segment from the LOG:
>
>
>ocalhost-startStop-1|02/13|08:28:35|Processing folderMap:
>C:\PHINMS3.0/config/sender/foldermap.xml|
>localhost-startStop-1|02/13|08:28:35|Loading decryption keystore|
>localhost-startStop-1|02/13|08:28:35|=== Spawning queue 0 |
>Thread-6|02/13|08:28:35|Initializing requeue cachepath from
>C:\PHINMS3.0/\shared\requeueCache|
>Thread-6|02/13|08:28:35|Spawning multi database poller 1...|
>Thread-7|02/13|08:28:35|Connection established|
>Thread-7|02/13|08:28:35|Waiting for records ...|
>localhost-startStop-1|02/13|08:28:35|Error creating connection pool for
>dbid: NHSCR_DB|
>localhost-startStop-1|02/13|08:28:35||
>
>Bruce
>
>
>
>Bruce Riddle
>NHSCR / Dartmouth College
>Phone: 603-653-6620
>PO Box 186, Hanover NH 03755
>
>STATEMENT OF CONFIDENTIALITY: This email may contain
>privileged and confidential information and is intended for use only by
>the
>individual(s) to whom it is addressed.  You are hereby notified
>that any unauthorized distribution or copying of this
>transmission is prohibited. If you have received this message
>in error, please contact the sender immediately and
>delete this electronic message
>and any attachments from your system.

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

Re: Jmxproxy causes datasources exceptions.

[Oliva]

Problem was initialSize="0".
Solution initialSize="1".



-- Forwarded message -
From: Oliva 
Date: mié., 21 feb. 2018 a las 12:47
Subject: Jmxproxy causes datasources exceptions.
To: 


When I try "http://myserver:myport/manager/jmxproxy; y get in catalina.out
the same error for getting attributes like Schema, AutoCommit, Catalog,
TransactionIsolation, Holdability and ReadOnly.

Tomcat 8.5.28 with DBCP 2 factory datasources.

Example from catalina.out for one attribute of them (Schema):

21-Feb-2018 12:20:33.714 GRAVE [http-nio-9010-exec-6]
org.apache.catalina.mbeans.MBeanDumper.dumpBeans Error getting attribute
Catalina:type=DataSource,class=javax.sql.DataSource,name="jdbc/MyDatasource",connectionpool=connections,connection=1
Schema
 javax.management.MBeanException: java.sql.SQLException: Connection
oracle.jdbc.driver.T4CConnection@4bdab731 is closed.
at
com.sun.jmx.mbeanserver.MBeanIntrospector.unwrapInvocationTargetException(MBeanIntrospector.java:313)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:239)
at
com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
at
com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at
org.apache.catalina.mbeans.MBeanDumper.dumpBeans(MBeanDumper.java:84)
at
org.apache.catalina.manager.JMXProxyServlet.listBeans(JMXProxyServlet.java:185)
at
org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:613)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.sql.SQLException: Connection
oracle.jdbc.driver.T4CConnection@4bdab731 is closed.
at
org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.checkOpen(DelegatingConnection.java:615)
at
org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.getSchema(DelegatingConnection.java:997)
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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at