Re: using default cacerts AND custom keystore

[Alex O'Ree]

anything related to SSL, key stores, trust stores, X509 certificates, etc
will do that to you!

On Mon, Feb 19, 2018 at 9:16 AM, Chris Cheshire 
wrote:

> On Fri, Feb 16, 2018 at 2:11 PM, Christopher Schultz
>  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Chris,
> >
> > On 2/14/18 3:34 PM, Chris Cheshire wrote:
> >> On Wed, Feb 14, 2018 at 12:30 PM, Mark Thomas 
> >> wrote:
> >>> On 14/02/18 17:17, Chris Cheshire wrote:
>  I am trying to set up my webapp to connect to an external
>  database via ssl. The database uses a self-signed certificate.
>  I have created a keystore with the self-signed CA and the
>  client key & cert. This keystore is configured via JAVA_OPTS in
>  setenv.sh
> 
>  JAVA_OPTS="-Djavax.net.ssl.keyStore=$CATALINA_BASE/conf/mysql.jks
>  \ -Djavax.net.ssl.keyStorePassword=password \
>  -Djavax.net.ssl.trustStore=$CATALINA_BASE/conf/mysql.jks \
>  -Djavax.net.ssl.trustStorePassword=password"
> 
>  This allows me to connect to the database without a problem.
>  However now I cannot connect to any external web service
>  because their certs will no longer validate.
> 
>  How do I configure tomcat such that the default cacerts is used
>  in addition to my self-signed certificates without importing
>  those into the default keystore (which is a Bad Idea™)?
> >>>
> >>> This is nothing to do with Tomcat. Tomcat plays no role in
> >>> out-going TLS connections.
> >>>
> >>> The short answer is rather than using system properties, you
> >>> should set the keystore and truststore programmatically so they
> >>> apply just to the database connections rather than globally.
> >>>
> >>
> >> So after a bit of digging [1,2] I found that this is achieved by
> >> adding the following parameters to the mysql jdbc url in the
> >> resource definition:
> >>
> >> clientCertificateKeyStoreUrl=file://${catalina.base}/conf/mysql.jks
> >>
> >>
> > clientCertificateKeyStorePassword=password
> >> trustCertificateKeyStoreUrl=file://${catalina.base}/conf/mysql.jks
> >> trustCertificateKeyStorePassword=changeit
> >>
> >> Note that  [2] has a couple of errors. A) it specifies
> >> clientCertificateKeyStore[Url|Password] in lieu of trustStore
> >> system property, that should be
> >> trustCertificateKeyStore[Url|Password] B) it specifies specifies
> >> the urls in the form file:path_to_truststore_file, that is also
> >> incorrect it should be file://path_to_truststore_file (which will
> >> give a triple slash if an absolute path is used)
> >>
> >>
> >> [1]
> >> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-con
> > figuration-properties.html
> >>
> >>
> > [2]
> > https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-using
> > - -ssl.html
> >
> > It might depend upon the version of Connector/J you are using. For
> > example, I have this in my connection URL:
> >
> > '...=file:/etc/mysql/mysql.jks'
> >
> > Only a single leading / for an absolute path in my case, and it works
> > as expected.
> >
> > The use of file:// was a historical mistake web browser users made,
> > thinking that // was necessary between the protocol and anything after
> > it. It was never the case, and any software requiring a URL like
> > file:/// should be considered broken.
> >
> > - -chris
>
> So I went back to retest everything to make sure I wasn't going crazy,
> and it turns out that I actually am. It really is working as expected
> without the double slash (and with). I guess I went crosseyed looking
> at the error logs after so many attempts trying to get this working
> initially.
>
> Chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Possibility of simplifying a UI vs services war setup

[Alex O'Ree]

Hi everyone, yet another email. I'm not too sure who to ask but I figured
the tomcat crew would be a good place to start. Maybe SO is more
appropriate

I have a two web app (war files) system, one containing just the UI and the
other containing a collection of CXF soap services and some rest services
and a web socket endpoint.

The UI basically contains a bunch of JSP files and web service clients
(mostly soap/jaxws) and talks to the services war. This basically means the
UI can reconnected to the same tomcat server and reauthenticate the same
user session.

Design decisions that got me to the setup
- i wanted the ability to run without the user interface
- i wanted to be able to run multiple service wars on multiple servers to
maintain high availability
- i wanted to be able to run the ui on a different server and use
application code to support failover/balancing between multiple instances
of the services war.

I'm open to revising/revisiting of these design decisions but at the time
they made sense. Anyhow, if you've made it this far, I did have a few
questions.

>From the UI war, is there a way I can somehow get a reference to the
service implementation classes in the services war? It would save me the
time and expense of serializing xml and yet another authentication
challenge and tcp socket overhead. As far as I know, this shouldn't be
possible due to class loader isolation but maybe there is some other JNDI
based thing that would work.

I'm not sure how common of a problem this is but if anyone has a similar
setup, i'd be interested to see how you solved it. I also have the added
complexity of supporting both http client cert and username/password
setups, but that can be saved for another conversation.

Http with client certificate authentication

[Alex O'Ree]

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?
- all user public key certificates in the trust store are allowed in
(assuming their CA's are also in the same 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)


Finally regarding certificate validation:
- i'm assuming basic validation checks are performed, time checks, etc
- 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?

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.

Re: Error parsing HTTP request header, HTTP method names must be tokens

[Alex O'Ree]

Thanks. I'll try the logging change to see if i can at least narrow it down
a bit more.

On Wed, Feb 21, 2018 at 7:49 PM, Konstantin Kolinko 
wrote:

> 2018-02-21 22:19 GMT+03:00 Alex O'Ree :
> > That's the error message. The problem is I have no idea which client it
> is
> > and what character it is sending that is causing the issue. Thus I would
> > like to get the offending header logged in some way.
>
> The "http-nio-8080-exec-3" in the message is the thread name. It can
> be written to the Access Log with "%I"
>
> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Logging
>
> Also look for response status in an access log. I think those requests
> are handled with status "400".
>
> You will see an IP address there. You wont't see any headers (such as
> User-Agent) as those have not been parsed yet.
>
> > On Tue, Feb 20, 2018 at 4:25 PM, Coty Sutherland 
> > wrote:
> >
> >> On Tue, Feb 20, 2018 at 4:01 PM, Alex O'Ree 
> wrote:
> >> > I keep running into the an IllegalArgumentException at or near
> startup of
> >> > tomcat 8.5 with a bunch of cxf web services deployed and I have no
> idea
> >> > what's causing it. The error message mentions turning on logging at
> the
> >> > debug level.
> >>
> >> Random shot in the dark given the minimal date provided :) Does it
> >> look like this:
> >>
> >> INFO [http-nio-8080-exec-3]
> >> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
> >> request header
> >>  Note: further occurrences of HTTP request parsing errors will be
> >> logged at DEBUG level.
> >>  java.lang.IllegalArgumentException: Invalid character found in the
> >> request target. The valid characters are defined in RFC 7230 and RFC
> >> 3986
> >> at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(
> >> Http11InputBuffer.java:460)
> >> at org.apache.coyote.http11.Http11Processor.service(
> >> Http11Processor.java:291)
> >> at org.apache.coyote.AbstractProcessorLight.process(
> >> AbstractProcessorLight.java:66)
> >> at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
> >> AbstractProtocol.java:754)
> >> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> >> doRun(NioEndpoint.java:1376)
> >> at org.apache.tomcat.util.net.SocketProcessorBase.run(
> >> SocketProcessorBase.java:49)
> >> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> >> ThreadPoolExecutor.java:1149)
> >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> >> ThreadPoolExecutor.java:624)
> >> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> >> TaskThread.java:61)
> >> at java.lang.Thread.run(Thread.java:748)
> >>
> >> If so, then your client is sending you requests with unencoded special
> >> characters that are now disallowed by Tomcat.
> >>
>
> >> Question: Assuming i need to edit the logging.properties file, which
> setting/line do i have to edit to reveal what the root cause is?
>
> http://tomcat.apache.org/tomcat-8.5-doc/logging.html
> and also official Java documentation on java.util.logging.
>
> From the log message cited by Coty, I think you need to add
> org.apache.coyote.http11.Http11Processor.level = FINE
>
> In short, you need both
> 1) .level = FINE
> 2) .level = FINE
>
> "1)" controls whether a log event is raised,
> "2)" controls writing it out to a specific output (console, file)
>
> "2)" is already set in the logging.properties file provided by Tomcat.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: TomcatCon Training: Tomcat for Administrators

[Alex O'Ree]

@Mark
I just found the videos from the last tomcatcon. I actually
watched/listened to them all. Great to here the inside scoop on stuff, hope
you all make more! I think i must have ran into most of the issues that
were discussed and rewrote most of my application (primarily due to me
using incorrect characters in the query string). Looking forward to the
next set

On Mon, Feb 19, 2018 at 5:12 PM, Coty Sutherland 
wrote:

> On Mon, Feb 19, 2018 at 4:30 PM, Mark Thomas  wrote:
> > On 19/02/18 17:53, Israel Timoteo wrote:
> >> Any plans for having this type of sessions in the US?
> >
> > We are expecting a Tomcat presence ApacheCon NA in September in Canada.
> > I expect we'll have some of this content available there.
> >
> > Beyond that it will be down to there being:
> > - the audience
> > - the content available that the audience want
> > - someone available who can deliver the content
> >
> > The community can help with at least 2 of those 3.
> >
> > There is also the possibility of delivery via a Webinar style approach
> > but I'm really not sure how well that would work for a training course.
>
> Did I suggest (or mention that I was planning on) doing something like
> https://www.katacoda.com/ before? I think an interactive approach to
> training would be awesome. Using containers for Tomcat seems a bit
> redundant to me (mostly because I don't have any real deployments of
> Tomcat), I think that using them for demoing things and having
> reproducible environments would be a good user experience for
> trainees.
>
> >
> > Mark
> >
> >>
> >> 
> >> Israel Timoteo
> >>
> >>> On Feb 19, 2018, at 10:50 AM, Rémy Maucherat  wrote:
> >>>
> >>> On Mon, Feb 19, 2018 at 5:28 PM, Mark Thomas  wrote:
> >>>
>  On 19/02/18 16:23, Coty Sutherland wrote:
> > Do we plan on doing any audio or video to go along with the slides
> for
> > these? We could add them to the youtube channel for those that can't
> > attend the live training.
> 
>  My current thinking is that I'd do a separate recording of the modules
>  for that rather than try and record the sessions. I want to be able to
>  focus on the attendees in the training. The recording would be video
> of
>  the slides and demos with audio of me talking.
> 
> >>>
> >>> As you said in London, that's material that is usually really nice when
> >>> you're there, but really boring when you're by yourself watching on
> >>> youtube. Although I agree we need one (current) copy of the trainings
> on
> >>> youtube for reference ...
> >>>
> >>> Rémy
> >>>
> >>>
> 
>  Mark
> 
> 
> >
> > On Mon, Feb 19, 2018 at 9:50 AM, Mark Thomas 
> wrote:
> >> All,
> >>
> >> The Apache Tomcat PMC is delighted to announce that the
> registration for
> >> the training course "Tomcat for Administrators" is now open.
> >>
> >> This one-day training course will take place in central Manchester,
> UK
> >> on Tuesday April 10, 2018.
> >>
> >> Full details, including the schedule is available on the website:
> >> http://tomcat.apache.org/conference.html
> >>
> >> Registration is via EventBrite:
> >> https://www.eventbrite.com/e/tomcatcon-training-tomcat-for-
>  administrators-tickets-43039556472?aff=lists
> >>
> >> We hope to see you there.
> >>
> >> Mark
> >> on behalf of the Apache Tomcat PMC
> >>
> >> 
> -
> >> 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
> >
> 
> 
>  -
>  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
> >>
> >
> >
> > -
> > 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 parsing HTTP request header, HTTP method names must be tokens

[Konstantin Kolinko]

2018-02-21 22:19 GMT+03:00 Alex O'Ree :
> That's the error message. The problem is I have no idea which client it is
> and what character it is sending that is causing the issue. Thus I would
> like to get the offending header logged in some way.

The "http-nio-8080-exec-3" in the message is the thread name. It can
be written to the Access Log with "%I"

http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Logging

Also look for response status in an access log. I think those requests
are handled with status "400".

You will see an IP address there. You wont't see any headers (such as
User-Agent) as those have not been parsed yet.

> On Tue, Feb 20, 2018 at 4:25 PM, Coty Sutherland 
> wrote:
>
>> On Tue, Feb 20, 2018 at 4:01 PM, Alex O'Ree  wrote:
>> > I keep running into the an IllegalArgumentException at or near startup of
>> > tomcat 8.5 with a bunch of cxf web services deployed and I have no idea
>> > what's causing it. The error message mentions turning on logging at the
>> > debug level.
>>
>> Random shot in the dark given the minimal date provided :) Does it
>> look like this:
>>
>> INFO [http-nio-8080-exec-3]
>> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
>> request header
>>  Note: further occurrences of HTTP request parsing errors will be
>> logged at DEBUG level.
>>  java.lang.IllegalArgumentException: Invalid character found in the
>> request target. The valid characters are defined in RFC 7230 and RFC
>> 3986
>> at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(
>> Http11InputBuffer.java:460)
>> at org.apache.coyote.http11.Http11Processor.service(
>> Http11Processor.java:291)
>> at org.apache.coyote.AbstractProcessorLight.process(
>> AbstractProcessorLight.java:66)
>> at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
>> AbstractProtocol.java:754)
>> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
>> doRun(NioEndpoint.java:1376)
>> at org.apache.tomcat.util.net.SocketProcessorBase.run(
>> SocketProcessorBase.java:49)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1149)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:624)
>> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
>> TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:748)
>>
>> If so, then your client is sending you requests with unencoded special
>> characters that are now disallowed by Tomcat.
>>

>> Question: Assuming i need to edit the logging.properties file, which
setting/line do i have to edit to reveal what the root cause is?

http://tomcat.apache.org/tomcat-8.5-doc/logging.html
and also official Java documentation on java.util.logging.

>From the log message cited by Coty, I think you need to add
org.apache.coyote.http11.Http11Processor.level = FINE

In short, you need both
1) .level = FINE
2) .level = FINE

"1)" controls whether a log event is raised,
"2)" controls writing it out to a specific output (console, file)

"2)" is already set in the logging.properties file provided by Tomcat.

Best regards,
Konstantin Kolinko

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

Re: Tomcat throwing 404 error after modifying context.xml

[M. Manna]

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 throwing 404 error after modifying context.xml

[Howlader, Aakash [GTSUS Non-J]]

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: Error parsing HTTP request header, HTTP method names must be tokens

[Mark Thomas]

On 21/02/18 19:19, Alex O'Ree wrote:
> That's the error message. The problem is I have no idea which client it is
> and what character it is sending that is causing the issue. Thus I would
> like to get the offending header logged in some way.

That sounds like an enhancement request for the log message to include
the invalid character and a client IP address.

The patch should be fairly simple if you fancy taking a shot at it.

Mark


> 
> On Tue, Feb 20, 2018 at 4:25 PM, Coty Sutherland 
> wrote:
> 
>> On Tue, Feb 20, 2018 at 4:01 PM, Alex O'Ree  wrote:
>>> I keep running into the an IllegalArgumentException at or near startup of
>>> tomcat 8.5 with a bunch of cxf web services deployed and I have no idea
>>> what's causing it. The error message mentions turning on logging at the
>>> debug level.
>>
>> Random shot in the dark given the minimal date provided :) Does it
>> look like this:
>>
>> INFO [http-nio-8080-exec-3]
>> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
>> request header
>>  Note: further occurrences of HTTP request parsing errors will be
>> logged at DEBUG level.
>>  java.lang.IllegalArgumentException: Invalid character found in the
>> request target. The valid characters are defined in RFC 7230 and RFC
>> 3986
>> at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(
>> Http11InputBuffer.java:460)
>> at org.apache.coyote.http11.Http11Processor.service(
>> Http11Processor.java:291)
>> at org.apache.coyote.AbstractProcessorLight.process(
>> AbstractProcessorLight.java:66)
>> at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
>> AbstractProtocol.java:754)
>> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
>> doRun(NioEndpoint.java:1376)
>> at org.apache.tomcat.util.net.SocketProcessorBase.run(
>> SocketProcessorBase.java:49)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1149)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:624)
>> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
>> TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:748)
>>
>> If so, then your client is sending you requests with unencoded special
>> characters that are now disallowed by Tomcat.
>>
>>> Question: Assuming i need to edit the logging.properties file, which
>>> setting/line do i have to edit to reveal what the root cause is?
>>
>> I can't answer that without more information. What is throwing the
>> exception? A stack trace would be helpful.
>>
>> -
>> 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 parsing HTTP request header, HTTP method names must be tokens

[Alex O'Ree]

That's the error message. The problem is I have no idea which client it is
and what character it is sending that is causing the issue. Thus I would
like to get the offending header logged in some way.

On Tue, Feb 20, 2018 at 4:25 PM, Coty Sutherland 
wrote:

> On Tue, Feb 20, 2018 at 4:01 PM, Alex O'Ree  wrote:
> > I keep running into the an IllegalArgumentException at or near startup of
> > tomcat 8.5 with a bunch of cxf web services deployed and I have no idea
> > what's causing it. The error message mentions turning on logging at the
> > debug level.
>
> Random shot in the dark given the minimal date provided :) Does it
> look like this:
>
> INFO [http-nio-8080-exec-3]
> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
> request header
>  Note: further occurrences of HTTP request parsing errors will be
> logged at DEBUG level.
>  java.lang.IllegalArgumentException: Invalid character found in the
> request target. The valid characters are defined in RFC 7230 and RFC
> 3986
> at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(
> Http11InputBuffer.java:460)
> at org.apache.coyote.http11.Http11Processor.service(
> Http11Processor.java:291)
> at org.apache.coyote.AbstractProcessorLight.process(
> AbstractProcessorLight.java:66)
> at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
> AbstractProtocol.java:754)
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> doRun(NioEndpoint.java:1376)
> at org.apache.tomcat.util.net.SocketProcessorBase.run(
> SocketProcessorBase.java:49)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:624)
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
>
> If so, then your client is sending you requests with unencoded special
> characters that are now disallowed by Tomcat.
>
> > Question: Assuming i need to edit the logging.properties file, which
> > setting/line do i have to edit to reveal what the root cause is?
>
> I can't answer that without more information. What is throwing the
> exception? A stack trace would be helpful.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

FINAL REMINDER: CFP for Apache EU Roadshow Closes 25th February

[Sharan F]

Hello Apache Supporters and Enthusiasts

This is your FINAL reminder that the Call for Papers (CFP) for the 
Apache EU Roadshow is closing soon. Our Apache EU Roadshow will focus on 
Cloud, IoT, Apache Tomcat, Apache Http and will run from 13-14 June 2018 
in Berlin.
Note that the CFP deadline has been extended to *25*^*th* *February *and 
it will be your final opportunity to submit a talk for thisevent.


Please make your submissions at http://apachecon.com/euroadshow18/

Also note that early bird ticket registrations to attend FOSS Backstage 
including the Apache EU Roadshow, have also been extended and will be 
available until 23^rd February. Please register at 
https://foss-backstage.de/tickets


We look forward to seeing you in Berlin!

Thanks
Sharan Foga, VP Apache Community Development

PLEASE NOTE: You are receiving this message because you are subscribed 
to a user@ or dev@ list of one or more Apache Software Foundation projects.

Jmxproxy causes datasources exceptions.

[Oliva]

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 sun.reflect.GeneratedMethodAccessor196.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)