from:"Michael\-O"


Hi,

several authentication mechanisms require a session (*not* HTTP session) 
or connection being initiated when authentication is performed and 
principal cached for subsquent requests [1], [2].


Now, I want to patch our SPNEGO authenticator in Tomcat 6 to behave 
stateful. I once contributed that code to Apache in bug 48465 [3] which 
does not behave like that. I like to align both authenticators.
This issue initially popped up while fixing an issue in libserf [4] for 
the upcoming Apache Subversion version 1.8.0.


How do I access that information in an authenticator? I do not intend to 
create a HTTP session for that for two reasons:


1. Creation of sessions should be upto the webapp.
2. There is no guarantee that the client will present the session cookie 
on a subsequent request.


Thanks,

Michael

[1] http://www.chromium.org/spdy/spdy-authentication
[2] 
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html

[3] https://issues.apache.org/bugzilla/show_bug.cgi?id=48685
[4] http://code.google.com/p/serf/issues/detail?id=89#c11

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

Re: Detect in an authenticator whether a connection is persistent or not


Am 2012-10-27 16:57, schrieb Mark Thomas:

On 27/10/2012 14:50, Michael-O wrote:

Hi,

several authentication mechanisms require a session (*not* HTTP session)
or connection being initiated when authentication is performed and
principal cached for subsquent requests [1], [2].

Now, I want to patch our SPNEGO authenticator in Tomcat 6 to behave
stateful. I once contributed that code to Apache in bug 48465 [3] which
does not behave like that. I like to align both authenticators.
This issue initially popped up while fixing an issue in libserf [4] for
the upcoming Apache Subversion version 1.8.0.

How do I access that information in an authenticator? I do not intend to
create a HTTP session for that for two reasons:

1. Creation of sessions should be upto the webapp.
2. There is no guarantee that the client will present the session cookie
on a subsequent request.


The only mechanism to maintain state between HTTP requests is the HTTP
session. You might be able to hack something together (in a non-portable
way) on a per connection basis but that is likely to require some rather
major internal surgery for Tomcat (and may be rejected by the committers).


Is there no way to tell that subsequent n requests come from the very 
same socket connection? HTTP is just on top of TCP/IP. Something like 
this should be transparent to HTTP though?
I am curious, since I know server implementations which indeed DO 
maintain state without HTTP sessions but I do not know how they do that.


At least the chromium link says how this can be done. Apache HTTP Cient 
does that too. Why not Tomcat?



It isn't unreasonable for use of an authentication to require an HTTP
session. FORM auth does that so I don't immediately see why SPNEGO can't.


FORM auth works very different compared to header-based auth. Form is 
meant for human interaction with a browser which will always pass cookies.
I cannot expect that from a machine client nor can the client actively 
say destroy that session unless a specific URL is called. Connection: 
close can do that.


Mike

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

Re: Detect in an authenticator whether a connection is persistent or not


Am 2012-10-27 18:38, schrieb Mark Thomas:

On 27/10/2012 16:28, Michael-O wrote:

Am 2012-10-27 16:57, schrieb Mark Thomas:



The only mechanism to maintain state between HTTP requests is the HTTP
session. You might be able to hack something together (in a non-portable
way) on a per connection basis but that is likely to require some rather
major internal surgery for Tomcat (and may be rejected by the
committers).


Is there no way to tell that subsequent n requests come from the very
same socket connection? HTTP is just on top of TCP/IP. Something like
this should be transparent to HTTP though?
I am curious, since I know server implementations which indeed DO
maintain state without HTTP sessions but I do not know how they do that.


It is easy if the same request object is reused for each request
processed for a given connection. Tomcat doesn't do this.

When a connection has data to process, first a processor is taken from
the processor pool to process the data. The processor has a request
object that is re-used. Each time an HTTP request is processed, a
different processor and request object may be used. (This does vary
slightly between the different connections but lets not complicate things).

Undoing this is the major internal surgery I was referring to. You might
be able to add an API to store/retrieve data to/from the connection
(similar to notes on the session, but at the connection level) and
access this from the authenticator (that is a lot further up the stack).
That could still end up being pretty invasive.


OK that's a statement. Tomcat does fully support persistent connections 
but there is no state information maintained, right?
The answer would be: There is clearly no way to store any information 
for a given connection context and retrieve throughout the Tomcat code.


Is this something worth being filed in Bugzilla as a longterm goal for 
Tomcat 8?


Thanks for the quick response,

Michael

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

Re: Detect in an authenticator whether a connection is persistent or not


Am 2012-10-27 19:25, schrieb Mark Thomas:

Is this something worth being filed in Bugzilla as a longterm goal for
Tomcat 8?


Sure, but without a proposed patch I suspect it will sit there for a few
years and then closed as WONTFIX. With a patch, it still might not get
fixed but at least you'll know for sure and if the patch isn't too
invasive (for the benefit it provides) it is likely to be applied.


That seems to be very tough. I hacked Tomcat code several times but 
wouldn't claim that I am firm enough to implement such a tremendous 
improvement. Interesting though that no one else yet requested such an 
improvement.


I have no usecase for this at the moment :-(, I only provide patches for 
stuff I suffer from at work.


As this [1] draft lays out Negotiate and Kerberos may apply to 
connection or request level auth. We are just lucky that the first 
gss_accept_sec_context makes the context complete in the SPNEGO 
authenticator.


Some clients maintain the state and rely on the server to maintain the 
connection state too. Tomcat does not do that which means that the 
current SPNEGO authenticator has to issue a Connection: close after 
successful auth. Otherwise the client will reuse the connection and keep 
sending requests w/o reauthenticating eventhough Tomcat requires to do 
so. In this case I have a Wireshark capture where this exactly happens 
and the clients traps in an endless loop and issues thousands of 
requests performs a DoS.


Thanks,

Mike

[1] 
http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth-01#section-1


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

Re: Detect in an authenticator whether a connection is persistent or not


Am 2012-10-27 20:22, schrieb Mark Thomas:

On 27/10/2012 18:57, Michael-O wrote:

Am 2012-10-27 19:25, schrieb Mark Thomas:

Is this something worth being filed in Bugzilla as a longterm goal for
Tomcat 8?


Sure, but without a proposed patch I suspect it will sit there for a few
years and then closed as WONTFIX. With a patch, it still might not get
fixed but at least you'll know for sure and if the patch isn't too
invasive (for the benefit it provides) it is likely to be applied.


That seems to be very tough. I hacked Tomcat code several times but
wouldn't claim that I am firm enough to implement such a tremendous
improvement. Interesting though that no one else yet requested such an
improvement.


Yes, we are fairly tough on adding new features. We really don't want to
add what, for most users, is bloat. We are usually happy to add hooks if
folks need them to implement their particular itch.

I wouldn't worry about the quality of the patch. The first one I wrote
for Tomcat was (rightly) ripped to pieces by the committers at the time
but the feature was implemented and is still there today. If a committer
can see a cleaner way of doing the same thing then they'll either give
you some pointers or just fix it and apply it. The main point is that if
there is a change you want to see, then you need do be the driving force.

Adding connection level notes shouldn't be too hard. The trickier part
is exposing them to the high-level components that need them. Passing
through the request is probably the way to go.


As long as there is general interest in such a feature I will keep that 
in mind and might take a look at it over Christmas.



I have no usecase for this at the moment :-(, I only provide patches for
stuff I suffer from at work.


The below looks like a use case to me.


As this [1] draft lays out Negotiate and Kerberos may apply to
connection or request level auth. We are just lucky that the first
gss_accept_sec_context makes the context complete in the SPNEGO
authenticator.

Some clients maintain the state and rely on the server to maintain the
connection state too. Tomcat does not do that which means that the
current SPNEGO authenticator has to issue a Connection: close after
successful auth. Otherwise the client will reuse the connection and keep
sending requests w/o reauthenticating eventhough Tomcat requires to do
so. In this case I have a Wireshark capture where this exactly happens
and the clients traps in an endless loop and issues thousands of
requests performs a DoS.


Well, as long as there is support for connection storage should I file a 
bug about that? The connector has to close the connection in my opinion.


Mike

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

HttpServletReponse#sendError(int) behavior in ErrorReportValve

Hi,

I've been struggling recently with this builtin valve and some
Spring-based REST services. I some cases I do return states like 404 or
400. SendError seems to be the right thing to do but Tomcat alters the
response with the HTML page. Which is highly unwanted for a REST API.

I have checked Oracle's original JavaDocs for #sendError(int) + Servlet
Spec 2.5 and 3.0 all three of them, do not explicitly mention that an
error HTML response is returned with this method. The JavaDoc [1] says:
...If an error-page declaration has been made for the web application
corresponding to the status code passed in, it will be served back the
error page...

I did not define a custom error page.

Where as the #sendError(int,String) says:
... The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message,
setting the content type to text/html.

This one is crystal clear.
sendError(int) simply calls sendError(int,String) with a null string arg.

Am I misunderstanding the the definition? Should I avoid sendError
alltogher and resort to setStatus? What would be the implications?

I do know that sendError commits and closes the response immediately.

A clarification is highly appreciated.

Thanks,

Michael

[1]
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendError%28int%29

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

Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve


Am 2012-11-23 22:16, schrieb Mark Thomas:

On 23/11/2012 21:09, Michael-O wrote:

Hi,

I've been struggling recently with this builtin valve and some
Spring-based REST services. I some cases I do return states like 404 or
400. SendError seems to be the right thing to do but Tomcat alters the
response with the HTML page. Which is highly unwanted for a REST API.

I have checked Oracle's original JavaDocs for #sendError(int) + Servlet
Spec 2.5 and 3.0 all three of them, do not explicitly mention that an
error HTML response is returned with this method. The JavaDoc [1] says:
...If an error-page declaration has been made for the web application
corresponding to the status code passed in, it will be served back the
error page...

I did not define a custom error page.

Where as the #sendError(int,String) says:
... The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message,
setting the content type to text/html.

This one is crystal clear.
sendError(int) simply calls sendError(int,String) with a null string arg.

Am I misunderstanding the the definition? Should I avoid sendError
alltogher and resort to setStatus? What would be the implications?
I do know that sendError commits and closes the response immediately.

A clarification is highly appreciated.


Use Tomcat 7 and define a custom, default error page. You'll then remain
in complete control of the error response.


Well, I am still on Tomcat 6 but I would do the following:

1. Define a @Controller
2. Define @RequestMapping on a method
3. Map that controller in the web.xml

Now here's the problem, that method would return ModelAndView or simply 
a view's string name. But I would like to use ResponseEntity as it would 
be necessary for REST.


Did you had this in mind? Otherwise would produces with distinct 
methods work for such an error page?


Thank you Mark,

Michael

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

Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve


Am 2012-11-23 22:28, schrieb Mark Thomas:

On 23/11/2012 21:23, Michael-O wrote:

Am 2012-11-23 22:16, schrieb Mark Thomas:

On 23/11/2012 21:09, Michael-O wrote:

Hi,

I've been struggling recently with this builtin valve and some
Spring-based REST services. I some cases I do return states like 404 or
400. SendError seems to be the right thing to do but Tomcat alters the
response with the HTML page. Which is highly unwanted for a REST API.

I have checked Oracle's original JavaDocs for #sendError(int) + Servlet
Spec 2.5 and 3.0 all three of them, do not explicitly mention that an
error HTML response is returned with this method. The JavaDoc [1] says:
...If an error-page declaration has been made for the web application
corresponding to the status code passed in, it will be served back the
error page...

I did not define a custom error page.

Where as the #sendError(int,String) says:
... The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message,
setting the content type to text/html.

This one is crystal clear.
sendError(int) simply calls sendError(int,String) with a null string
arg.

Am I misunderstanding the the definition? Should I avoid sendError
alltogher and resort to setStatus? What would be the implications?
I do know that sendError commits and closes the response immediately.

A clarification is highly appreciated.


Use Tomcat 7 and define a custom, default error page. You'll then remain
in complete control of the error response.


Well, I am still on Tomcat 6 but I would do the following:

1. Define a @Controller
2. Define @RequestMapping on a method
3. Map that controller in the web.xml

Now here's the problem, that method would return ModelAndView or simply
a view's string name. But I would like to use ResponseEntity as it would
be necessary for REST.

Did you had this in mind? Otherwise would produces with distinct
methods work for such an error page?


Sorry, I know next to nothing about Spring (and yes, I do work for
SpringSource).

For Tomcat 6 I'd define my own error valve but that is not portable. You
could also define error pages for each error code you use and for
java.lang.Exception


The problem is that our Tomcat is serving a variety of apps. I do not 
want to code a custom valve to one app which would impact other ones.
Neither I do want to subclass StandardHost class and disable the valve 
and add one on a per-webapp base.



My reading of the specification text quoted above is that the server is
expected to create HTML error pages unless the user defines a custom
error page in web.xml. I don't see any room for an alternative
interpretation.


Well, that applies for the JavaDoc of sendError(int, String). 
sendError(int) does not say that the server has to auto-generate a HTML 
error page unless one is defined by the developer.

Am I correct?

Thanks,

Mike

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

Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve


Am 2012-11-23 22:50, schrieb Mark Thomas:

On 23/11/2012 21:44, Michael-O wrote:

Am 2012-11-23 22:28, schrieb Mark Thomas:

On 23/11/2012 21:23, Michael-O wrote:

Am 2012-11-23 22:16, schrieb Mark Thomas:

On 23/11/2012 21:09, Michael-O wrote:

Hi,

I've been struggling recently with this builtin valve and some
Spring-based REST services. I some cases I do return states like
404 or
400. SendError seems to be the right thing to do but Tomcat alters the
response with the HTML page. Which is highly unwanted for a REST API.

I have checked Oracle's original JavaDocs for #sendError(int) +
Servlet
Spec 2.5 and 3.0 all three of them, do not explicitly mention that an
error HTML response is returned with this method. The JavaDoc [1]
says:
...If an error-page declaration has been made for the web application
corresponding to the status code passed in, it will be served back the
error page...

I did not define a custom error page.

Where as the #sendError(int,String) says:
... The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message,
setting the content type to text/html.

This one is crystal clear.
sendError(int) simply calls sendError(int,String) with a null string
arg.

Am I misunderstanding the the definition? Should I avoid sendError
alltogher and resort to setStatus? What would be the implications?
I do know that sendError commits and closes the response immediately.

A clarification is highly appreciated.


Use Tomcat 7 and define a custom, default error page. You'll then
remain
in complete control of the error response.


Well, I am still on Tomcat 6 but I would do the following:

1. Define a @Controller
2. Define @RequestMapping on a method
3. Map that controller in the web.xml

Now here's the problem, that method would return ModelAndView or simply
a view's string name. But I would like to use ResponseEntity as it would
be necessary for REST.

Did you had this in mind? Otherwise would produces with distinct
methods work for such an error page?


Sorry, I know next to nothing about Spring (and yes, I do work for
SpringSource).

For Tomcat 6 I'd define my own error valve but that is not portable. You
could also define error pages for each error code you use and for
java.lang.Exception


The problem is that our Tomcat is serving a variety of apps. I do not
want to code a custom valve to one app which would impact other ones.
Neither I do want to subclass StandardHost class and disable the valve
and add one on a per-webapp base.


My reading of the specification text quoted above is that the server is
expected to create HTML error pages unless the user defines a custom
error page in web.xml. I don't see any room for an alternative
interpretation.


Well, that applies for the JavaDoc of sendError(int, String).
sendError(int) does not say that the server has to auto-generate a HTML
error page unless one is defined by the developer.
Am I correct?


No.

sendError(int) == sendError(int, null)

sendError(int, null) requires an HTML response, even if the message is null.


I am aware of that implementation detail. I was solely referring to the 
definition in the JavaDocs. They seem to be misleading. At least to me.


Mike

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

Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve

Am 2012-11-23 23:02, schrieb Mark Thomas:

On 23/11/2012 22:00, Michael-O wrote:

Am 2012-11-23 22:50, schrieb Mark Thomas:

On 23/11/2012 21:44, Michael-O wrote:

Am 2012-11-23 22:28, schrieb Mark Thomas:

On 23/11/2012 21:23, Michael-O wrote:

Am 2012-11-23 22:16, schrieb Mark Thomas:

On 23/11/2012 21:09, Michael-O wrote:

Hi,

I've been struggling recently with this builtin valve and some
Spring-based REST services. I some cases I do return states like
404 or
400. SendError seems to be the right thing to do but Tomcat
alters the
response with the HTML page. Which is highly unwanted for a REST
API.

I have checked Oracle's original JavaDocs for #sendError(int) +
Servlet
Spec 2.5 and 3.0 all three of them, do not explicitly mention
that an
error HTML response is returned with this method. The JavaDoc [1]
says:
...If an error-page declaration has been made for the web
application
corresponding to the status code passed in, it will be served
back the
error page...

I did not define a custom error page.

This one is crystal clear.
sendError(int) simply calls sendError(int,String) with a null string
arg.

Am I misunderstanding the the definition? Should I avoid sendError
alltogher and resort to setStatus? What would be the implications?
I do know that sendError commits and closes the response
immediately.

A clarification is highly appreciated.

Use Tomcat 7 and define a custom, default error page. You'll then
remain
in complete control of the error response.

Well, I am still on Tomcat 6 but I would do the following:

1. Define a @Controller
2. Define @RequestMapping on a method
3. Map that controller in the web.xml

Now here's the problem, that method would return ModelAndView or
simply
a view's string name. But I would like to use ResponseEntity as it
would
be necessary for REST.

Did you had this in mind? Otherwise would produces with distinct
methods work for such an error page?

Sorry, I know next to nothing about Spring (and yes, I do work for
SpringSource).

For Tomcat 6 I'd define my own error valve but that is not portable.
You
could also define error pages for each error code you use and for
java.lang.Exception

The problem is that our Tomcat is serving a variety of apps. I do not
want to code a custom valve to one app which would impact other ones.
Neither I do want to subclass StandardHost class and disable the valve
and add one on a per-webapp base.

My reading of the specification text quoted above is that the server is
expected to create HTML error pages unless the user defines a custom
error page in web.xml. I don't see any room for an alternative
interpretation.

Well, that applies for the JavaDoc of sendError(int, String).
sendError(int) does not say that the server has to auto-generate a HTML
error page unless one is defined by the developer.
Am I correct?

No.

sendError(int) == sendError(int, null)

sendError(int, null) requires an HTML response, even if the message is
null.

I am aware of that implementation detail. I was solely referring to the
definition in the JavaDocs. They seem to be misleading. At least to me.

I was referring only to the Javadoc you quoted.

Yes, for the second one. Why do the Tomcat Servlet JavaDocs for
sendError(int) not mention that [1]? SendError(int, String) is fine
though. Care to update the docs to make this crystal clear?

Thanks,

Mike

[1]
http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/HttpServletResponse.html#sendError(int)

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

Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve


Am 2012-11-23 23:10, schrieb Mark Thomas:

On 23/11/2012 22:07, Michael-O wrote:

Am 2012-11-23 23:02, schrieb Mark Thomas:

On 23/11/2012 22:00, Michael-O wrote:


snip/


I am aware of that implementation detail. I was solely referring to the
definition in the JavaDocs. They seem to be misleading. At least to me.


I was referring only to the Javadoc you quoted.


Yes, for the second one. Why do the Tomcat Servlet JavaDocs for
sendError(int) not mention that [1]? SendError(int, String) is fine
though. Care to update the docs to make this crystal clear?


You started off quoting the Oracle Javadocs and that is what I responded
to. You are now moving the goal posts. If you think there is room for
improvement in the Tomcat Javadocs then open an enhancement request and
provide a patch.


https://issues.apache.org/bugzilla/show_bug.cgi?id=54198

Done, thanks!

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

Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve

2012-11-25 Thread Michael-O

Am 2012-11-24 23:08, schrieb Terence M. Bandoian:

On 11/23/2012 3:09 PM, Michael-O wrote:

Hi,

I've been struggling recently with this builtin valve and some
Spring-based REST services. I some cases I do return states like 404
or 400. SendError seems to be the right thing to do but Tomcat alters
the response with the HTML page. Which is highly unwanted for a REST API.

I have checked Oracle's original JavaDocs for #sendError(int) +
Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention
that an error HTML response is returned with this method. The JavaDoc
[1] says:
...If an error-page declaration has been made for the web application
corresponding to the status code passed in, it will be served back the
error page...

I did not define a custom error page.

This one is crystal clear.
sendError(int) simply calls sendError(int,String) with a null string arg.

A clarification is highly appreciated.

Thanks,

Michael

[1]
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendError%28int%29

Hi, Michael-

For services that are to be consumed programmatically and do not require
human-readable content, I would use response.setStatus. Doing so allows
for a response body, if required, that is appropriate for the associated
request.

Hi Terence,

this is what I am going to do now but I wanted clarafication on the
sendError(int) method description.

Michael

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

Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve

2012-11-26 Thread Michael-O


Am 2012-11-23 23:02, schrieb Mark Thomas:

On 23/11/2012 22:00, Michael-O wrote:

Am 2012-11-23 22:50, schrieb Mark Thomas:

On 23/11/2012 21:44, Michael-O wrote:

Am 2012-11-23 22:28, schrieb Mark Thomas:

On 23/11/2012 21:23, Michael-O wrote:

Am 2012-11-23 22:16, schrieb Mark Thomas:

On 23/11/2012 21:09, Michael-O wrote:

Hi,

I've been struggling recently with this builtin valve and some
Spring-based REST services. I some cases I do return states like
404 or
400. SendError seems to be the right thing to do but Tomcat
alters the
response with the HTML page. Which is highly unwanted for a REST
API.

I have checked Oracle's original JavaDocs for #sendError(int) +
Servlet
Spec 2.5 and 3.0 all three of them, do not explicitly mention
that an
error HTML response is returned with this method. The JavaDoc [1]
says:
...If an error-page declaration has been made for the web
application
corresponding to the status code passed in, it will be served
back the
error page...

I did not define a custom error page.

Where as the #sendError(int,String) says:
... The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message,
setting the content type to text/html.

This one is crystal clear.
sendError(int) simply calls sendError(int,String) with a null string
arg.

Am I misunderstanding the the definition? Should I avoid sendError
alltogher and resort to setStatus? What would be the implications?
I do know that sendError commits and closes the response
immediately.

A clarification is highly appreciated.


Use Tomcat 7 and define a custom, default error page. You'll then
remain
in complete control of the error response.


Well, I am still on Tomcat 6 but I would do the following:

1. Define a @Controller
2. Define @RequestMapping on a method
3. Map that controller in the web.xml

Now here's the problem, that method would return ModelAndView or
simply
a view's string name. But I would like to use ResponseEntity as it
would
be necessary for REST.

Did you had this in mind? Otherwise would produces with distinct
methods work for such an error page?


Sorry, I know next to nothing about Spring (and yes, I do work for
SpringSource).

For Tomcat 6 I'd define my own error valve but that is not portable.
You
could also define error pages for each error code you use and for
java.lang.Exception


The problem is that our Tomcat is serving a variety of apps. I do not
want to code a custom valve to one app which would impact other ones.
Neither I do want to subclass StandardHost class and disable the valve
and add one on a per-webapp base.


My reading of the specification text quoted above is that the server is
expected to create HTML error pages unless the user defines a custom
error page in web.xml. I don't see any room for an alternative
interpretation.


Well, that applies for the JavaDoc of sendError(int, String).
sendError(int) does not say that the server has to auto-generate a HTML
error page unless one is defined by the developer.
Am I correct?


No.

sendError(int) == sendError(int, null)

sendError(int, null) requires an HTML response, even if the message is
null.


I am aware of that implementation detail. I was solely referring to the
definition in the JavaDocs. They seem to be misleading. At least to me.


I was referring only to the Javadoc you quoted.


While we are talking about Javadocs, what is the sendStatus supposed to 
do? According to the docs the response remains untouched, right?


Mike


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

Invocation condition of ErrorReportValve

Hi,

why does the ErrorReportValve trigger the report on this condition only?

 if ((statusCode  400) || (response.getContentCount()  0))
return;

So, even if I do a reponse.setStatus(404), this valve is executed. According to 
the Javadoc: if setStatus is invoked [1], the response should be left untouched 
in constrast to the sendErroor method. Especially this sentence makes it clear 
If this method is used to set an error code, then the container's error page 
mechanism will not be triggered. 

Shouldn't that include a response.isError() check?

[1] 
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#setStatus%28int%29

Thanks,

Mike

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

Re: Invocation condition of ErrorReportValve

Am 2012-11-28 18:26, schrieb Mark Thomas:

Michael-O 1983-01...@gmx.net wrote:

Hi,

why does the ErrorReportValve trigger the report on this condition
only?

if ((statusCode 400) || (response.getContentCount() 0))
return;

So, even if I do a reponse.setStatus(404), this valve is executed.
According to the Javadoc: if setStatus is invoked [1], the
response should be left untouched in constrast to the sendErroor
method. Especially this sentence makes it clear If this method is
used to set an error code, then the container's error page
mechanism will not be triggered.

Shouldn't that include a response.isError() check?

[1]
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#setStatus%28int%29

Yep. This sort of thing drives me nuts with the Servlet spec. The
document is mean to be definitive but isn't. Half the requirements
are in the Javadoc and the Javadoc is no longer included in the
specification (for no good reason) and the spec lead refuses to add
it back in. You used to be able to search one doc for a phrase,
method, class, whatever and find all the references. Now it is right
pain to figure out what the expected behaviour is.

Raise a bugzilla entry for this one and it'll get looked at and
(assuming there is a problem as there does appear to be from the
fragment you quoted) it will get fixed.

Mark,

issue has been created:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54220

I have depicted a new possible condition based on the Javadocs and the
spec. Please have look.

Mike

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

Writing to response and issuing sendError


Hi,

I am having again trouble with the respone.sendError method. The docs 
say that an IllegalStateException is thrown if response has already been 
committed. So this should cause an exception:


protected void doGet(HttpServletRequest request, HttpServletResponse 
response) throws ServletException, IOException {

  PrintWriter out = response.getWriter();
  out.println(ERROR);
  out.flush();
  response.sendError(404);
}

The exception is thrown out to the console but the response is still 
written. If I leave out the flush (which commits the response). The 
error page comes up.


Is this undefined behavior or some missing code path to transform the 
ISE to a HTTP 500 error response?


I am on Tomcat 6.0.35

Thanks,

Mike

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

Re: Writing to response and issuing sendError


Am 2012-11-28 21:39, schrieb Mark Thomas:

On 28/11/2012 20:34, Michael-O wrote:

Hi,

I am having again trouble with the respone.sendError method. The docs
say that an IllegalStateException is thrown if response has already been
committed. So this should cause an exception:

protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
   PrintWriter out = response.getWriter();
   out.println(ERROR);
   out.flush();
   response.sendError(404);
}

The exception is thrown out to the console but the response is still
written. If I leave out the flush (which commits the response). The
error page comes up.

Is this undefined behavior or some missing code path to transform the
ISE to a HTTP 500 error response?


Nope. Think about it. Once the response has been committed the response
status line and the headers have been written to the client as well as
at least some if not all of the response body. Tomcat can't take back
the data it has already sent.


Sigh, I forgot that the body has already been sent over the wire. Your 
explanation makes perfectly sense then. sendError is coming too late.


I'd prefer that this ISE would have a message. The source contains a 
commented exception message.


Thanks,

Mike

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

Re: Writing to response and issuing sendError

Am 2012-11-28 21:41, schrieb Caldarale, Charles R:

From: Michael-O [mailto:1983-01...@gmx.net]
Subject: Writing to response and issuing sendError

The exception is thrown out to the console but the response is still
written.

As it should be - it's already committed, and may well have been delivered.

If I leave out the flush (which commits the response). The
error page comes up.

Also as it should be.

Is this undefined behavior

No, it's operating as required by the spec.

Yes, thanks!

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

Re: tomcat-7.0.35 ON Window Server SP 2

2013-02-27 Thread Michael-O


Am 2013-02-27 19:36, schrieb André Warnier:

dku...@ccilindia.co.in wrote:

Hi,

I have downloaded apache-tomcat-7.0.35.zip and runiing it on Window
Server SP 2 machine and it is working fine. Is it OK to run
apache-tomcat-7.0.35 setup on Window Server SP 2 machine?
Please reply.

Server version: Apache Tomcat/7.0.35
OS Name:Windows Server SP 2  32 bit




On the home page of Tomcat, at : http://tomcat.apache.org/,
- there is a link Which version, which gives a quick overview of the
available versions an the corresponding Java versions required etc.
- there is also a link Download .. Tomcat 7.0. This leads to a page
which shows the current version of Tomcat 7.x available for download.
This current version is 7.0.37.
Further down that page, in the section entitled 7.0.37, it shows the
various packages available for download, and there is also a link to a
README.  This README page provides plenty of information regarding which
package contains what, and the kind of platform and installation that it
corresponds to.

Now considering all that,
- why did you download and install a version 7.0.35, instead of the
latest 7.0.37 ? (and where did you get it from ?)
- why did you not download and install either the 32-bit Windows zip, or
the 32/64-bit Windows Service Installer ?

And in short, why do you waste /our/ time instead of spending some of
/your/ time to at least read what people have already written and posted
on the website for everyone to see ?


Why are you even answering this? The guy is not even capable to provide 
full OS information.


M



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

Re: tomcat-7.0.35 ON Window Server SP 2

2013-02-28 Thread Michael-O

 Michael-O wrote:
  Am 2013-02-27 19:36, schrieb André Warnier:
  dku...@ccilindia.co.in wrote:
  Hi,
 
  I have downloaded apache-tomcat-7.0.35.zip and runiing it on Window
  Server SP 2 machine and it is working fine. Is it OK to run
  apache-tomcat-7.0.35 setup on Window Server SP 2 machine?
  Please reply.
 
  Server version: Apache Tomcat/7.0.35
  OS Name:Windows Server SP 2  32 bit
 
 
 
  On the home page of Tomcat, at : http://tomcat.apache.org/,
  - there is a link Which version, which gives a quick overview of the
  available versions an the corresponding Java versions required etc.
  - there is also a link Download .. Tomcat 7.0. This leads to a page
  which shows the current version of Tomcat 7.x available for download.
  This current version is 7.0.37.
  Further down that page, in the section entitled 7.0.37, it shows the
  various packages available for download, and there is also a link to a
  README.  This README page provides plenty of information regarding
 which
  package contains what, and the kind of platform and installation that
 it
  corresponds to.
 
  Now considering all that,
  - why did you download and install a version 7.0.35, instead of the
  latest 7.0.37 ? (and where did you get it from ?)
  - why did you not download and install either the 32-bit Windows zip,
 or
  the 32/64-bit Windows Service Installer ?
 
  And in short, why do you waste /our/ time instead of spending some of
  /your/ time to at least read what people have already written and
 posted
  on the website for everyone to see ?
  
  Why are you even answering this? The guy is not even capable to provide 
  full OS information.
  
 Because otherwise, tomorrow he is going to come back and tell us that he
 downloaded the 
 64-bit Itanium zip version and loaded it on his iPhone, tell us that it
 works fine and ask 
 us if it is ok.

If so this would be a breakthrough achievement.

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

Register static JNDI env entry dynamically

2013-03-16 Thread Michael-O


Hi,

I'd like to make a string available as an env entry via JNDI. The string 
is static but must be created dynamically at startup time of the webapp.


I have evaluated and implemented a listener which I have added to my 
context.xml. It listens for startup and shutdown events. It works pretty 
well. Rethinking this makes me ask whether a listener is the right thing 
to do.


Would an object factory a better approach for this?
Did I abuse the listener concept?

Code is available for inspection.

Thanks,

Michael

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

Re: Register static JNDI env entry dynamically

2013-03-16 Thread Michael-O


Am 2013-03-16 10:46, schrieb Konstantin Kolinko:

2013/3/16 Michael-O 1983-01...@gmx.net:

Hi,

I'd like to make a string available as an env entry via JNDI. The string is
static but must be created dynamically at startup time of the webapp.

I have evaluated and implemented a listener which I have added to my
context.xml. It listens for startup and shutdown events. It works pretty
well. Rethinking this makes me ask whether a listener is the right thing to
do.

Would an object factory a better approach for this?
Did I abuse the listener concept?

Code is available for inspection.



1. Tomcat version =?


I am on Tomcat 6.0.35.


2. Looking at docs,
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment%20Entries
I do not see factory as an allowed attribute for environment entries.


That was not my intent. I was referring to Resource instead of 
Environment.



3. Do you have control over code that uses the value?


No(t really), it's Logback. I retrieve the value from JNDI in the 
logback.xml.



4. Listeners are OK. I wonder though whether JNDI is modifiable or
read-only at that point in time. If it works for you, then it is has
to be modifiable.


It is modifiable. See my implementation please:
http://tinyurl.com/a79jdgt

And the usecase for:
http://tinyurl.com/afu9ppl

I have this in production for almost a year now but decided finally to 
make it publically available under ASLv2. That's the reason for my doubts.


Michael


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

Re: Register static JNDI env entry dynamically

2013-03-16 Thread Michael-O


Am 2013-03-16 11:43, schrieb Konstantin Kolinko:

2013/3/16 Michael-O 1983-01...@gmx.net:

Am 2013-03-16 10:46, schrieb Konstantin Kolinko:


2013/3/16 Michael-O 1983-01...@gmx.net:


Hi,

I'd like to make a string available as an env entry via JNDI. The string
is
static but must be created dynamically at startup time of the webapp.

I have evaluated and implemented a listener which I have added to my
context.xml. It listens for startup and shutdown events. It works pretty
well. Rethinking this makes me ask whether a listener is the right thing
to
do.

Would an object factory a better approach for this?
Did I abuse the listener concept?

Code is available for inspection.



1. Tomcat version =?



I am on Tomcat 6.0.35.



2. Looking at docs,

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment%20Entries
I do not see factory as an allowed attribute for environment entries.



That was not my intent. I was referring to Resource instead of
Environment.



3. Do you have control over code that uses the value?



No(t really), it's Logback. I retrieve the value from JNDI in the
logback.xml.



4. Listeners are OK. I wonder though whether JNDI is modifiable or
read-only at that point in time. If it works for you, then it is has
to be modifiable.



It is modifiable. See my implementation please:
http://tinyurl.com/a79jdgt

And the usecase for:
http://tinyurl.com/afu9ppl

I have this in production for almost a year now but decided finally to make
it publically available under ASLv2. That's the reason for my doubts.



Generally I do not see anything substantially wrong with the code.


First of all, thank you for your valuable inspection. It is highly 
appreciated. I will comment inline.



Some comments on the code:

1. In logback-test.xml  you use ${CONTEXT_NAME}
I think it is a typo, as you are using contextName elsewhere.


No, it's not. ${CONTEXT_NAME} is a context scoped, by default predefined 
variable with the context name. Please see here: 
http://logback.qos.ch/manual/configuration.html#variableSubstitution



2. In  LogbackContextNameListener.java
Dependency on commons-lang is a bad thing here, as the class has to go
into ${catalina.base}/lib  and it would be better to minimize
dependencies. You should not use libraries that might be included into
webapps, or you will be open to classloader issues, memory leaks etc.
The method you are using is trivial to be implemented inline.


I am fully aware of that and always keep that in mind. In that case, 
there is no need to worry for the extra dependency. I am shading all 
necessary classes in an internal package in the JAR. They won't collide 
with deployed webapps. See http://tinyurl.com/cx7tzne



3. I prefer to use  constantString.equals(value) instead of
value.equals(constantString) because of nulls. Not an issue here
though. Just style.


I have seen this approach already in several spots in some Apache 
projects but haven't yet grasped the advantages because I always check 
input for validity.



4. You are not really changing JNDI. You are changing context
configuration that JNDI is populated from later.
(NamingContextListener registers itself as PropertyChangeListener on
NamingResources and propagates your changes to JNDI)


Wow, that's new. But this 
context.getNamingResources().addEnvironment(ce); does add objects to 
the context? So, if I understand correctly, startup phase has a staging 
set of objects from which the final, read-only JNDI context will be build?



5. I would not clear the value on stop event. It causes unnecessary
work (propagating the value to JNDI) and shutdown is supposed to be
fast.

Double assignments during repeated starts should not be an issue, but
if they are then you can call
context.getNamingResources().removeEnvironment(name)  before adding.


Thanks, I will remove the if loop. But reading your comment, I should 
add a checker on startup which verifies whether that env entry is 
already set?


Something like:

if (le.getType().equals(Lifecycle.START_EVENT)) {
check for presence;
if yes
 remove;

add value;
}


6. A Factory will not have access to Context. A Listener is better here.


Yes, but it would spit out the same string which will be cached and 
returned to the app. The outcome would be the same, at least from the 
app's point of view.



Michael


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

Re: Setting up tomcat to run on port 443 on ubuntu system

2013-03-29 Thread Michael-O


Am 2013-03-29 09:38, schrieb Shyam Yadav:

Hi,

I want to run my tomcat on port 443 with https on an Ubuntu machine.
what are the required steps i should take, please guide me through it.
I search Internet but did not get any proper solution that is why i am here
sending you this mail.


Hi Shyam,

a few things you need to consider:

1. You have Tomcat already prepackaged on Ubuntu which works very well.
2. Only root is allowed bind ports below 1024.

Regarding 1: This is solved by the Ubuntu package
Regarding 2: Root must start the binary and perform a so called downgrade

Now, you have following options:

1. Use Ubuntu's start-stop-daemon
2. do $ su - tomcat -c startup.sh
3. Evaluate Commons Daemon which will perform that aforementioned 
downgrade in plain C.


Ubuntu actually does that with 1 and 3. HAve a look at Ubuntu's tomcat6 
startup script.


Michael


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

Re: Tomcat how to set -Xms and -Xmx

2013-03-31 Thread Michael-O


Am 2013-03-31 19:20, schrieb Kevin Jenkins:

If I run tomcat7w.exe (windows) there is a tab where I can set the initial
and maximum memory pool to 2560. However, I don't want to use tomcat7w.exe,
I just want to run the  batch file manually (startup.bat). However, I can't
figure out how to set these memory pool values for startup.bat to use.

I read somewhere to create C:\apache-tomcat-7.0.37\bin\setenv.bat which
contains
SET JAVA_OPTS=-Xms2560 -Xmx2560


You need to set CATALINA_OPTS.


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

Re: Setting up tomcat to run on port 443 on ubuntu system

2013-04-01 Thread Michael-O


Am 2013-03-31 23:52, schrieb Ognjen Blagojevic:

Shyam,

On 29.3.2013 14:54, Shyam Yadav wrote:

I did all the setting you have mentioned for Unix Daemon for Tomcat, but
still i am getting the same problem.
i.e.  Permission Denied.


When you run your jsvc-based Tomcat startup script, you MUST do it as
root. It will bind port 443 as root, and then create child process for
unprivileged user that will actually run JVM.

There is no point in running /etc/init.d/tomcat (or whatever is Ubuntu
equivalent) as unprivileged user. You won't be able to bind port 443.


That guy is unwilling to read. I wrote this already two days ago w/o any 
further response.



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

Re: Tomcat Valve Custom args

2013-04-01 Thread Michael-O


Am 2013-04-01 08:25, schrieb N.s.Karthik:

Hi
  Spec:

JDK1.6
Tomcat 6.0.26
O/s nix Suse


I have build a Customized Valve and have done the required  settings in
context.xml for specific APP
and have them returned variables System.println on console ( Catalina.out)

Question :

1) How to get the return values  into a JSP file  [ using  request.  ]
of the specific APP


What variables? What is APP?

Valves are invisible to the app. There are Tomcat-only. If you need to 
set some values, resort to environment entries through JNDI. A listener 
should do that. I have asked this recently on the mailing list.



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

Re: Tomcat Valve Custom args

2013-04-01 Thread Michael-O


Am 2013-04-01 14:28, schrieb N.s.Karthik:

Hi

Thx for the reply

I know that Valves are invisible to the app..

Reason :
I have created a Customized valve as a separate jar  used for AAA
interception of my APPS ,
Since I cannot configure each and every application hosted on the Tomcat
with filters  and hence created a Valve to apply this at Tomcat level

I use the IWA (Integrated Window Authentication)  of IE / FFOx for Active
directory AAA Authentication.

On-sucessfull  AAA, in the valve  I need the variables such as
username/domain name  to be further  used with in each application

Hence I need to know if any possibilities to fetch the variables  into each
of the applications from the valves ...???


I hope that you have implemented AuthenticatorBase in Tomcat with your 
custom Authenticator. With that you can register a Principal object.


I have written a fully-featured SPNEGO/AD Realm package which uses a 
custom ActiveDirectoryPrincipal extends Principal. In that I have stored 
distinguished name, objectSid, etc (source code available).


First, make the Principal#getName return either the Kerberos UPN, or if 
you use NTLM (yuck) return the legacy login name.


If your need access to further attributes do in your app:

MyCustomPrincipal principal = (MyCustomPrincipal) request.getPrincipal();

...access attributes.

That is the way to go.

Michael


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

Re: Tomcat7 - ajax and connection pool : connection closed despite the use of validationQuery and testOnBorrow

2013-04-05 Thread Michael-O


Am 2013-04-05 11:37, schrieb Jean-Claude Haw-King-Chon:

Hi,

I use the connection pool of tomcat7 and set a connection in a
ThreadLocal. The context is a web application : the threadLocal is
configured when the http request is initialized. The jdbc connection is
closed and removed from the threadLocal when the resquest is destroyed.


Why do you do that at all?
Why don't you simply use such an idiom in your thead/controller:

...
Connection conn = ConnetionUtils.getReadWriteConnection(DataSource 
dataSource); // has to be implemented of course

..

Use this connetion in the entire thread, pass it along, when you are 
done. Close it.


ThreadLocals are useful in other cases but not in this one.

Michael

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

Re: Tomcat7 - ajax and connection pool : connection closed despite the use of validationQuery and testOnBorrow

2013-04-05 Thread Michael-O


Fist of all, do NOT top post. Use the power of your wondeful mail client.

Am 2013-04-05 13:05, schrieb Jean-Claude Haw-King-Chon:

I wish to avoid passing the connection through the layers of the
application (from controller to DAO).
The controller initialize the connection and must pass it to the Dao
layer. I don't want to pass the datasource or connection to the business
layer as a parameter.

Futher, the data source can be different for each user : it's not
possible to use a static attribute to store the connection or the
datasource (by example, in a connection factory).

That's why I think that threadlocal is the solution for passing the
connection between 2 non adjacent layers : is it a bad practice?


ThreadLocals have their use cases but must be used with great caution. 
Are you certain that no one else sets the ThreadLocal and you do not 
suffer from race conditions due to missing synchronization?


Michael


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

Re: Unable to start tomcat (JDBC-ORACLE CONNECTIVITY ISSUE WITYH OCI8 DRIVER using oracle 11g client.)

2013-04-06 Thread Michael-O


Am 2013-04-06 10:30, schrieb dku...@ccilindia.co.in:

Dear All,

JDBC-ORACLE CONNECTIVITY ISSUE WITYH OCI8 DRIVER using oracle 11g client..
I am getting below error when i m trying to access oracle db using oracle
11g client. It works with earlier oracle client versions. how do i resolve
this.  is there any issue with version of ojdbc6.jar that i am using??? I
cant use thin driver since its an old application for which i dont have
source files.

Apr 6, 2013 1:00:59 PM org.apache.catalina.core.StandardWrapperValve
invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.UnsatisfiedLinkError: no ocijdbc9 in java.library.path



1. This is not a Tomcat problem but a library path problem.
2. Use the native Java driver, there's no need for the OCI version.
3. Read the Oracle docs how to use OCI8 with JDBC.

Michael

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

Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool

Hi folks,

I recently enabled a QueryTimeoutInterceptor with queryTimeout of 60 seconds in 
a JDBC Pool data source (7.0.37). When the app was shut down, Tomcat said: The 
web application [/...] appears to have started a thread named 
[OracleTimeoutPollingThread] but has failed to stop it...

We are using Oracle 11.2g with 11.2.0.3 JDBC drivers. I have figured out that 
this thread is spawned by the driver itself. According to this Stackoverflow 
answer [1] this is a long-living thread, same says the JDBC FAQ [2] of Oracle.

The thread seems to work like Pool's PoolCleaner thread. A few month a ago I 
reported the same issue with the PoolCleaner thread and Filip fixed the class 
loader orders.

Can this be a false-positive by the memory leak detector since this thread 
lives only once in the entire VM?

Thanks,

Michael

[1] http://stackoverflow.com/a/3387312/696632
[2] 
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-faq-090281.html#02_14

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

Aw: Re: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool


 Von: Mark Thomas ma...@apache.org
 On 07/05/2013 09:16, Michael-O wrote:
  Hi folks,
  
  I recently enabled a QueryTimeoutInterceptor with queryTimeout of 60 
  seconds in a JDBC Pool data source (7.0.37). When the app was shut down, 
  Tomcat said: The web application [/...] appears to have started a thread 
  named [OracleTimeoutPollingThread] but has failed to stop it...
  
  We are using Oracle 11.2g with 11.2.0.3 JDBC drivers. I have figured out 
  that this thread is spawned by the driver itself. According to this 
  Stackoverflow answer [1] this is a long-living thread, same says the JDBC 
  FAQ [2] of Oracle.
  
  The thread seems to work like Pool's PoolCleaner thread. A few month a ago 
  I reported the same issue with the PoolCleaner thread and Filip fixed the 
  class loader orders.
  
  Can this be a false-positive by the memory leak detector since this thread 
  lives only once in the entire VM?
 
 No. It is a memory leak and either or bug in your application or in the
 JDBC driver.
 
 Where is the Oracle JDBC driver? CATALINA_[BASE|HOME]/lib or WEB-INF/lib

The driver is in the $CATALINA_HOME/lib only where $CATALINA_BASE != 
$CATALINA_HOME. This was done for a single webapp for testing purposes.

Does this make a difference? How do you know that this is not a false-positive?
If you really know for sure, I can open a service request with Oracle Support.

Michael

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

Re: Re: Re: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool

 Von: Mark Thomas ma...@apache.org
 On 07/05/2013 10:25, Michael-O wrote:
  
  Von: Mark Thomas ma...@apache.org On 07/05/2013 09:16,
  Michael-O wrote:
  Hi folks,
  
  I recently enabled a QueryTimeoutInterceptor with queryTimeout of
  60 seconds in a JDBC Pool data source (7.0.37). When the app was
  shut down, Tomcat said: The web application [/...] appears to
  have started a thread named [OracleTimeoutPollingThread] but has
  failed to stop it...
  
  We are using Oracle 11.2g with 11.2.0.3 JDBC drivers. I have
  figured out that this thread is spawned by the driver itself.
  According to this Stackoverflow answer [1] this is a long-living
  thread, same says the JDBC FAQ [2] of Oracle.
  
  The thread seems to work like Pool's PoolCleaner thread. A few
  month a ago I reported the same issue with the PoolCleaner thread
  and Filip fixed the class loader orders.
  
  Can this be a false-positive by the memory leak detector since
  this thread lives only once in the entire VM?
  
  No. It is a memory leak and either or bug in your application or in
  the JDBC driver.
  
  Where is the Oracle JDBC driver? CATALINA_[BASE|HOME]/lib or
  WEB-INF/lib
  
  The driver is in the $CATALINA_HOME/lib only where $CATALINA_BASE !=
  $CATALINA_HOME. This was done for a single webapp for testing
  purposes.
  
  Does this make a difference?
 
 The important thing is that it isn't in WEB-INF/lib.
 
  How do you know that this is not a false-positive?
 
 Experience, a lot of research into memory leaks and I wrote Tomcat's
 memory leak detection code.
 
  If you really know for sure, I can open a service
  request with Oracle Support.
 
 Good luck with that.
 
 The problem is that when the driver creates the thread it does so when
 the current class loader is the web application class loader. That means
 that the Thread will be created with a context class loader set to the
 web application class loader. That will trigger a memory leak when the
 web application is stopped because a reference is retained to the web
 application's class loader.
 
 What the driver should do is, after it creates the thread, set the
 thread's context class loader to the class loader that loaded the driver.
 
 What you are seeing is a variation of the leak described on page 15 of [1].

After reading the slides and your explanation this makes sense. It's the same 
issue as
Pool cleaner thread should be created using the classloader that loaded the 
pool, not the context loader (fhanik) fixed in 7.0.27.

I will file SR and let you know.

Michael

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

Aw: Re: Re: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool

 Von: Mark Thomas ma...@apache.org
 On 07/05/2013 10:25, Michael-O wrote:
  
  Von: Mark Thomas ma...@apache.org On 07/05/2013 09:16,
  Michael-O wrote:
  Hi folks,
  
  I recently enabled a QueryTimeoutInterceptor with queryTimeout of
  60 seconds in a JDBC Pool data source (7.0.37). When the app was
  shut down, Tomcat said: The web application [/...] appears to
  have started a thread named [OracleTimeoutPollingThread] but has
  failed to stop it...
  
  We are using Oracle 11.2g with 11.2.0.3 JDBC drivers. I have
  figured out that this thread is spawned by the driver itself.
  According to this Stackoverflow answer [1] this is a long-living
  thread, same says the JDBC FAQ [2] of Oracle.
  
  The thread seems to work like Pool's PoolCleaner thread. A few
  month a ago I reported the same issue with the PoolCleaner thread
  and Filip fixed the class loader orders.
  
  Can this be a false-positive by the memory leak detector since
  this thread lives only once in the entire VM?
  
  No. It is a memory leak and either or bug in your application or in
  the JDBC driver.
  
  Where is the Oracle JDBC driver? CATALINA_[BASE|HOME]/lib or
  WEB-INF/lib
  
  The driver is in the $CATALINA_HOME/lib only where $CATALINA_BASE !=
  $CATALINA_HOME. This was done for a single webapp for testing
  purposes.
  
  Does this make a difference?
 
 The important thing is that it isn't in WEB-INF/lib.
 
  How do you know that this is not a false-positive?
 
 Experience, a lot of research into memory leaks and I wrote Tomcat's
 memory leak detection code.
 
  If you really know for sure, I can open a service
  request with Oracle Support.
 
 Good luck with that.

SR created. I will keep you updated.

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

Re: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool


Hello Christopher,

Am 2013-05-07 17:20, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 5/7/13 6:43 AM, Michael-O wrote:

Von: Mark Thomas ma...@apache.org On 07/05/2013 10:25,
Michael-O wrote:



Von: Mark Thomas ma...@apache.org On 07/05/2013 09:16,
Michael-O wrote:

Hi folks,

I recently enabled a QueryTimeoutInterceptor with
queryTimeout of 60 seconds in a JDBC Pool data source
(7.0.37). When the app was shut down, Tomcat said: The web
application [/...] appears to have started a thread named
[OracleTimeoutPollingThread] but has failed to stop it...

We are using Oracle 11.2g with 11.2.0.3 JDBC drivers. I
have figured out that this thread is spawned by the driver
itself. According to this Stackoverflow answer [1] this is
a long-living thread, same says the JDBC FAQ [2] of
Oracle.

The thread seems to work like Pool's PoolCleaner thread. A
few month a ago I reported the same issue with the
PoolCleaner thread and Filip fixed the class loader
orders.

Can this be a false-positive by the memory leak detector
since this thread lives only once in the entire VM?


No. It is a memory leak and either or bug in your application
or in the JDBC driver.

Where is the Oracle JDBC driver? CATALINA_[BASE|HOME]/lib or
WEB-INF/lib


The driver is in the $CATALINA_HOME/lib only where
$CATALINA_BASE != $CATALINA_HOME. This was done for a single
webapp for testing purposes.

Does this make a difference?


The important thing is that it isn't in WEB-INF/lib.


How do you know that this is not a false-positive?


Experience, a lot of research into memory leaks and I wrote
Tomcat's memory leak detection code.


If you really know for sure, I can open a service request with
Oracle Support.


Good luck with that.

The problem is that when the driver creates the thread it does so
when the current class loader is the web application class
loader. That means that the Thread will be created with a context
class loader set to the web application class loader. That will
trigger a memory leak when the web application is stopped because
a reference is retained to the web application's class loader.

What the driver should do is, after it creates the thread, set
the thread's context class loader to the class loader that loaded
the driver.

What you are seeing is a variation of the leak described on page
15 of [1].


After reading the slides and your explanation this makes sense.
It's the same issue as Pool cleaner thread should be created using
the classloader that loaded the pool, not the context loader
(fhanik) fixed in 7.0.27.

I will file SR and let you know.


Note that you might be able to write your own code to mitigate this
problem, depending on exactly when that thread is created. If the
timeout thread isn't created until you actually try to issue a query
with a timeout, try something like this in a ServletContextListener's
contextInitialized method:

 // NOTE: No resource management is being done in this example

 // Get the current ClassLoader -- should be WebappClassLoader
 ClassLoader cl = Thread.currentThread().getContextClassLoader();

 // WebappClassLoader.getParent should be common loader
 Thread.currentThread().setContextClassLoader(cl.getParent());

 try
 {
   Connection conn = ...; // However you get a connection
   Statement s = conn.createStatement();
   s.setQueryTimeout(5000); // Doesn't really matter what TO is
   s.execute(SELECT 1 FROM dual, );
 }
 
 finally
 {
   // Pop back to the original ClassLoader
   Thread.currentThread().setContextClassLoader(cl);
 }

This is the exact technique that Tomcat's
JreMemoryLeakPreventionListener uses to prevent ClassLoader leaks.


Yes, this looks like the way JDBC Pool does with the Pool Cleaner. I 
would go for this as a last resort.



A
couple of notes:

1. This won't work under a SecurityManager. If you need to operate
under a SecurityManager, have a look at the
JreMemoryLeakPreventionListener code and adapt it to the above.

2. If the Oracle driver launches the thread when the DataSource is
created, it might happen too early for a ServletContextListener to
intervene. In that case, simply modify the
JreMEmoryLeakPreventionListener code directly. Patches are always welcome.


Not, it is not. I have attached VisualVM to Tomcat VM and have seen that 
the thread is forked when the first query is executed.



3. If Oracle fixes this bug, Tomcat should not prevent against it. If
Oracle refuses to acknowledge/fix/etc. this bug, then it may make
sense to include such code in JreMemoryLeakPreventionListener, but it
should probably be done in such a way that a) it's not enabled by
default and b) the query used for triggering the Thread to be created
is user-selectable with maybe a reasonable default (like SELECT 1
FROM dual, as that tends to be valid in most RDBMSs).


I am already in contact with an Oracle engineer who has received a demo 
WAR file

Print parameters in Tomcat JDBC Pool's SlowQueryReport

Hi,

I recently have started using the SlowQueryReport to tackle performance issues. 
The log message, unfortunately, does not contain the parameters passed to the 
prepared statements. Though AbstractQueryReport receives this information in

protected String report*Query(String query, Object[] args, final String name, 
long start, long delta)

but ignores this information. The report would highly benefit from. E.g., 
Commons DBUtils prints out the query and the parameters in the case of an 
exception. The sole query isn't really helpful.

Can we add this? Should I file a ticket?

Thanks,

Michael

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

Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport


Am 2013-05-08 14:08, schrieb Nick Williams:


On May 8, 2013, at 6:54 AM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Michael,

On 5/8/13 3:01 AM, Michael-O wrote:

I recently have started using the SlowQueryReport to tackle
performance issues. The log message, unfortunately, does not
contain the parameters passed to the prepared statements. Though
AbstractQueryReport receives this information in

protected String report*Query(String query, Object[] args, final
String name, long start, long delta)

but ignores this information. The report would highly benefit
from. E.g., Commons DBUtils prints out the query and the
parameters in the case of an exception. The sole query isn't
really helpful.

Can we add this?


Sure.


Should I file a ticket?


Yes. A BZ issue with a patch is likely to get done a whole lot
faster than one without a patch (plus you get credit for your
contribution).

- -chris


There needs to be an option to disable logging query parameters
somehow. Query parameters are sometimes sensitive, and in some
environments (medical, legal, etc.) logging them might even be in
violation of the law.


Agreed, but this won't work if someone failed to use prepared statements 
and uses StringBuilder to create the entire string.


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

Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport


Am 2013-05-08 14:38, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nick,

On 5/8/13 8:08 AM, Nick Williams wrote:


On May 8, 2013, at 6:54 AM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Michael,

On 5/8/13 3:01 AM, Michael-O wrote:

I recently have started using the SlowQueryReport to tackle
performance issues. The log message, unfortunately, does not
contain the parameters passed to the prepared statements.
Though AbstractQueryReport receives this information in

protected String report*Query(String query, Object[] args,
final String name, long start, long delta)

but ignores this information. The report would highly benefit
from. E.g., Commons DBUtils prints out the query and the
parameters in the case of an exception. The sole query isn't
really helpful.

Can we add this?


Sure.


Should I file a ticket?


Yes. A BZ issue with a patch is likely to get done a whole lot
faster than one without a patch (plus you get credit for your
contribution).

- -chris


There needs to be an option to disable logging query parameters
somehow. Query parameters are sometimes sensitive, and in some
environments (medical, legal, etc.) logging them might even be in
violation of the law.


+1

If you really want to get cute, allow the user to specify named query
parameters that should never be displayed e.g. 'password', though
this is a) perhaps not possible and b) not reliable because you can
bind parameters by position as well as by name.


Java has no support for named parameters. How is that supposed to work?


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

Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport


Christopher,

Am 2013-05-08 13:54, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 5/8/13 3:01 AM, Michael-O wrote:

I recently have started using the SlowQueryReport to tackle
performance issues. The log message, unfortunately, does not
contain the parameters passed to the prepared statements. Though
AbstractQueryReport receives this information in

protected String report*Query(String query, Object[] args, final
String name, long start, long delta)

but ignores this information. The report would highly benefit
from. E.g., Commons DBUtils prints out the query and the parameters
in the case of an exception. The sole query isn't really helpful.

Can we add this?


Sure.


Should I file a ticket?


Yes. A BZ issue with a patch is likely to get done a whole lot faster
than one without a patch (plus you get credit for your contribution).


What file should I patch, AbstractQueryReport or QueryReport? I'd 
exclude JMX for now.


Michael


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

Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport

2013-05-10 Thread Michael-O


Am 2013-05-08 19:42, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 5/8/13 1:14 PM, Michael-O wrote:

Christopher,

Am 2013-05-08 13:54, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Michael,

On 5/8/13 3:01 AM, Michael-O wrote:

I recently have started using the SlowQueryReport to tackle
performance issues. The log message, unfortunately, does not
contain the parameters passed to the prepared statements.
Though AbstractQueryReport receives this information in

protected String report*Query(String query, Object[] args,
final String name, long start, long delta)

but ignores this information. The report would highly benefit
from. E.g., Commons DBUtils prints out the query and the
parameters in the case of an exception. The sole query isn't
really helpful.

Can we add this?


Sure.


Should I file a ticket?


Yes. A BZ issue with a patch is likely to get done a whole lot
faster than one without a patch (plus you get credit for your
contribution).


What file should I patch, AbstractQueryReport or QueryReport? I'd
exclude JMX for now.


Your choice: whatever seems to make more sense. If a committer reads
and patch and thinks it goes somewhere else, you can re-write it. Or,
you can open the BZ issue, then post to the dev list asking for
suggestions for where to start.


Thanks,

give me a couple of days. I won't have access to an appropriate env 
before Monday.


Michael


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

ErrorReportValve's char encoding ignored

2013-05-15 Thread Michael-O

Hi folks,

I have modified the ErrorReportValve's messages outside of the one-byte range 
and the output got mangled. The response does not contain a char encoding 
anymore.

I know that the error valve does this:

response.setContentType(text/html);
response.setCharacterEncoding(utf-8);

but the setCharEnc method is completely ignored. Because the var usingWriter is 
already set to true. This happens in the ApplicationDispatcher#doForward line 
393/394 when a servlet performs a forward.

Though a response.getReporter() is used but this one is completely unaware of 
the char encoding.

I am on Tomcat 6.0.35.

I presume this to be a bug. Should I file a BZ issue?

Michael

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

Aw: Re: ErrorReportValve's char encoding ignored

2013-05-15 Thread Michael-O

Hi Christopher,

Von: Christopher Schultz ch...@christopherschultz.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Micheal,

On 5/15/13 3:46 AM, Michael-O wrote:
I have modified the ErrorReportValve's messages outside of the
one-byte range and the output got mangled. The response does not
contain a char encoding anymore.

Can you be more specific? What exactly did you modify, and how did you
modify it? What are the exact HTTP response headers that you get?

My modified valve is available here [1]. I did modify message layout and
structure. The logic of the valve remained the same. Important are lines 219 to
233 which are the same as in the original ErrorReportValve.

Responded headers are:
Cache-Control private
Content-Length 992
Content-Typetext/html
DateWed, 15 May 2013 14:53:15 GMT
Expires Thu, 01 Jan 1970 01:00:00 CET
Server Apache-Coyote/1.1

Content encoding is missing.

I know that the error valve does this:

response.setContentType(text/html);
response.setCharacterEncoding(utf-8);

but the setCharEnc method is completely ignored. Because the var
usingWriter is already set to true. This happens in the
ApplicationDispatcher#doForward line 393/394 when a servlet
performs a forward.

Looking at Tomcat 6.0.x/trunk line 393 is part of the cleanup code,
and the response PrintWriter is immediately closed. That does not
appear to have changed since 6.0.35. At this point, the request should
be /over/.

What else is going on? Is any content being generated before the
ErrorReportValve gets invoked? If the response has already been
committed, then Tomcat can't re-write the response headers.

Nothing else is generated, this is my doGet:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

HttpSession session = request.getSession(false);

if (session == null) {
response.sendError(HttpServletResponse.SC_FORBIDDEN, Keine Session
vorhanden);
return;
}
..
}

In my testcase, the session is null, thus the ErrorReportValve is triggered.
When I have debugged the issue, I saw that the response was not committed yet.

Though a response.getReporter() is used but this one is completely
unaware of the char encoding.

I am on Tomcat 6.0.35.

Where is response.getReporter being called?

That is called in my valve in line 227, which has the same counterpart in the
original valve.
The ReporterPrintWriter has beeen created exactly for the case that where the
original writer is not available anymore. It has already been cleaned up as you
have mentioned before.

The setCharEnc is simply not propagated to the new one. The double-byte char
\u2013 is displayed as a question mark in Firefox. Fiddler shows a 3F which
simply means that the writer did not know how to map char to bytes.

Michael

[1]
http://mo-tomcat-ext.sourceforge.net/xref/net/sf/michaelo/tomcat/extras/valves/EnhancedErrorReportValve.html

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

Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread

Hi folks,

there's now a follow-up on the issue [1].
Recap: JreMemoryLeakPreventionListener reported that my webapp has spawned 
OracleTimeoutPollingThread because I have set a QueryTimeout in the JDBC Pool.
Mark Thomas noted that this is likely a bug in the driver. I have taken action 
and created a service request with Oracle.

My personal analysis with VisualVM:
The thread is spawned when the first query is run. The thread keeps running 
when the webapp is shut down or undeployed. Classes remain in memory.
The JDBC Pool does a simple Class.forName to load the driver, it neither uses 
the DriverManager loading nor does it actively unload the driver.

Oracle answer:
They were able to reproduce the issue. The technical analysis says:

 Hi Michael,

 I confirmned internally that this message from Tomcat can be ignored as there 
 is no risk of any real leak from OracleTimeoutPollingThread thread.
 This thread is related to the JDBC driver which may be used by many apps 
 simultaneously. Unloading the app does not unload the driver and should not 
 and does not stop the thread.

 It seems to be the design behaviour.

So my questions would be:
1. Is that still not a false positive?
2. Why does the JDBC Pool not unload the driver? That my cause the thread to 
stop after the last app has been stopped/undeployed.

Thanks,

Michael

[1] http://www.mail-archive.com/users@tomcat.apache.org/msg106186.html

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

Re: Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread

Hi Mark,

thanks again for the detailed answer, details inline.

 Gesendet: Freitag, 17. Mai 2013 um 11:36 Uhr
 Von: Mark Thomas ma...@apache.org
 An: Tomcat Users List users@tomcat.apache.org
 Betreff: Re: Follow-up: Possible false-postive with 
 JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and 
 OracleTimeoutPollingThread

 On 17/05/2013 09:28, Michael-O wrote:
  Hi folks,
  
  there's now a follow-up on the issue [1].
  Recap: JreMemoryLeakPreventionListener reported that my webapp has spawned 
  OracleTimeoutPollingThread because I have set a QueryTimeout in the JDBC 
  Pool.
  Mark Thomas noted that this is likely a bug in the driver. I have taken 
  action and created a service request with Oracle.
  
  My personal analysis with VisualVM:
  The thread is spawned when the first query is run. The thread keeps running 
  when the webapp is shut down or undeployed. Classes remain in memory.
  The JDBC Pool does a simple Class.forName to load the driver, it neither 
  uses the DriverManager loading nor does it actively unload the driver.
  
  Oracle answer:
  They were able to reproduce the issue. The technical analysis says:
  
  Hi Michael,
 
  I confirmned internally that this message from Tomcat can be ignored as 
  there is no risk of any real leak from OracleTimeoutPollingThread thread.
  This thread is related to the JDBC driver which may be used by many apps 
  simultaneously. Unloading the app does not unload the driver and should 
  not and does not stop the thread.
 
  It seems to be the design behaviour.
  
  So my questions would be:
  1. Is that still not a false positive?
 
 No, that is not a false positive. The response from Oracle is wrong.
 
 There is nothing wrong with the driver creating the thread or the thread
 continuing after the web application has stopped. The problem is as follows:
 
 1. When the JDBC driver creates the Thread, the Thread's context class
 loader (as returned by Thread.getContextClassLoader()) is set to the web
 application's class loader.
 
 2. The correct behaviour at this point would be for the Driver to set
 the Thread's context class loader to the class loader that loaded the
 Driver class when the Thread is created.
 
 3. The memory leak occurs as follows:
 - the web application is stopped
 - Tomcat clears all references to the web application and its classes
 - The web application should be eligible for garbage collection
 - The JDBC driver is still loaded (as it should be)
 - The JDBC driver retains a reference to the Thread (as it should)
 - The thread retains a reference to the web application class loader
 (this is the memory leak).
 
 The reference chain is:
 a) JDBC driver
   b) Thread
 c) Web application class loader
   d) Every class loaded by the web app
 
 Everything from c) onwards should be eligible for garbage collection but
 isn't because of the leak in the Thread that is retaining a reference to
 the web application class loader.

This is what I would assume as correct behavior. If the thread is still 
attached ot the WebAppClassLoader, does that mean that the WebAppClassLoader 
cannot be garbage collected?
 
  2. Why does the JDBC Pool not unload the driver? That my cause the thread 
  to stop after the last app has been stopped/undeployed.
 
 1. Because the driver is in CATALINA_HOME/lib it is available to other
 applications.

So first app, loads driver and keeps it in memory. Even if all apps are 
undeployed, driver remains cached and GCed when Tomcat is shut down?
 
 2. JDBC drivers are never automatically unloaded. You have to do so
 explicitly (not doing so is an other source of memory leaks when the
 driver is packaged in WEB-INF/lib).

OK, this won't be the case. Driver is always shared here.
 
 You need to go back to Oracle.

Yes, I will. We're paying probably a lot of money for he company-wide license.

Thanks again,

Michael

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

Aw: Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread



 Gesendet: Freitag, 17. Mai 2013 um 14:26 Uhr
 Von: Mark Thomas ma...@apache.org

 On 17/05/2013 12:31, Michael-O wrote:
  Hi Mark,
  
  thanks again for the detailed answer, details inline.
  
  Gesendet: Freitag, 17. Mai 2013 um 11:36 Uhr
  Von: Mark Thomas ma...@apache.org
  An: Tomcat Users List users@tomcat.apache.org
  Betreff: Re: Follow-up: Possible false-postive with 
  JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and 
  OracleTimeoutPollingThread
 
  On 17/05/2013 09:28, Michael-O wrote:
  Hi folks,
 
  there's now a follow-up on the issue [1].
  Recap: JreMemoryLeakPreventionListener reported that my webapp has 
  spawned OracleTimeoutPollingThread because I have set a QueryTimeout in 
  the JDBC Pool.
  Mark Thomas noted that this is likely a bug in the driver. I have taken 
  action and created a service request with Oracle.
 
  My personal analysis with VisualVM:
  The thread is spawned when the first query is run. The thread keeps 
  running when the webapp is shut down or undeployed. Classes remain in 
  memory.
  The JDBC Pool does a simple Class.forName to load the driver, it neither 
  uses the DriverManager loading nor does it actively unload the driver.
 
  Oracle answer:
  They were able to reproduce the issue. The technical analysis says:
 
  Hi Michael,
 
  I confirmned internally that this message from Tomcat can be ignored as 
  there is no risk of any real leak from OracleTimeoutPollingThread 
  thread.
  This thread is related to the JDBC driver which may be used by many apps 
  simultaneously. Unloading the app does not unload the driver and should 
  not and does not stop the thread.
 
  It seems to be the design behaviour.
 
  So my questions would be:
  1. Is that still not a false positive?
 
  No, that is not a false positive. The response from Oracle is wrong.
 
  There is nothing wrong with the driver creating the thread or the thread
  continuing after the web application has stopped. The problem is as 
  follows:
 
  1. When the JDBC driver creates the Thread, the Thread's context class
  loader (as returned by Thread.getContextClassLoader()) is set to the web
  application's class loader.
 
  2. The correct behaviour at this point would be for the Driver to set
  the Thread's context class loader to the class loader that loaded the
  Driver class when the Thread is created.
 
  3. The memory leak occurs as follows:
  - the web application is stopped
  - Tomcat clears all references to the web application and its classes
  - The web application should be eligible for garbage collection
  - The JDBC driver is still loaded (as it should be)
  - The JDBC driver retains a reference to the Thread (as it should)
  - The thread retains a reference to the web application class loader
  (this is the memory leak).
 
  The reference chain is:
  a) JDBC driver
b) Thread
  c) Web application class loader
d) Every class loaded by the web app
 
  Everything from c) onwards should be eligible for garbage collection but
  isn't because of the leak in the Thread that is retaining a reference to
  the web application class loader.
  
  This is what I would assume as correct behavior. If the thread is still 
  attached ot the WebAppClassLoader, does that mean that the 
  WebAppClassLoader cannot be garbage collected?
 
 The correct behaviour is that there is no reference to c) held by b) and
 therefore c) onwards would be eligible for GC (assuming the web app has
 been stopped). The problem here is that because b) has a reference to
 c), c) can't be GC'd and that is a memory leak.

Exactly, WebAppClassLoader keeps in a stale status.

  2. Why does the JDBC Pool not unload the driver? That my cause the thread 
  to stop after the last app has been stopped/undeployed.
 
  1. Because the driver is in CATALINA_HOME/lib it is available to other
  applications.
  
  So first app, loads driver and keeps it in memory. Even if all apps are 
  undeployed, driver remains cached and GCed when Tomcat is shut down?
 
 The JDBC driver will be loaded though the services API as soon as any
 code references the DriverManager.
 
  2. JDBC drivers are never automatically unloaded. You have to do so
  explicitly (not doing so is an other source of memory leaks when the
  driver is packaged in WEB-INF/lib).
  
  OK, this won't be the case. Driver is always shared here.
   
  You need to go back to Oracle.
  
  Yes, I will. We're paying probably a lot of money for he company-wide 
  license.
 
 I'd expect so.
 
 From my own experience with Oracle commercial support for things Java
 related, you'll have to go through the This is a bug. No it isn't. Yes
 it is... cycle several times before you manage to get the issue in
 front of someone with the necessary knowledge and skills to correctly
 identify this is a bug in Oracle's JDBC driver. I'd recommend escalating
 it through your account manager sooner rather than later.
 
 Feel free to point Oracle support to this thread and/or my

Aw: RE: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread

  -Original Message-
  From: Mark Thomas [mailto:ma...@apache.org]
  Sent: Friday, May 17, 2013 7:26 AM
  To: Tomcat Users List
  Subject: Re: Follow-up: Possible false-postive with
  JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and
  OracleTimeoutPollingThread

  On 17/05/2013 12:31, Michael-O wrote:
   Hi Mark,

   thanks again for the detailed answer, details inline.

   Gesendet: Freitag, 17. Mai 2013 um 11:36 Uhr
   Von: Mark Thomas ma...@apache.org
   An: Tomcat Users List users@tomcat.apache.org
   Betreff: Re: Follow-up: Possible false-postive with
   JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and
   OracleTimeoutPollingThread

   On 17/05/2013 09:28, Michael-O wrote:
   Hi folks,

   there's now a follow-up on the issue [1].
   Recap: JreMemoryLeakPreventionListener reported that my webapp has
  spawned OracleTimeoutPollingThread because I have set a QueryTimeout in
  the JDBC Pool.
   Mark Thomas noted that this is likely a bug in the driver. I have
  taken action and created a service request with Oracle.

   My personal analysis with VisualVM:
   The thread is spawned when the first query is run. The thread keeps
  running when the webapp is shut down or undeployed. Classes remain in
  memory.
   The JDBC Pool does a simple Class.forName to load the driver, it
  neither uses the DriverManager loading nor does it actively unload the
  driver.

   Oracle answer:
   They were able to reproduce the issue. The technical analysis says:

   Hi Michael,

   I confirmned internally that this message from Tomcat can be
  ignored as there is no risk of any real leak from
  OracleTimeoutPollingThread thread.
   This thread is related to the JDBC driver which may be used by
  many apps simultaneously. Unloading the app does not unload the driver
  and should not and does not stop the thread.

   It seems to be the design behaviour.

   So my questions would be:
   1. Is that still not a false positive?

   No, that is not a false positive. The response from Oracle is wrong.

   There is nothing wrong with the driver creating the thread or the
   thread continuing after the web application has stopped. The problem
  is as follows:

   1. When the JDBC driver creates the Thread, the Thread's context
   class loader (as returned by Thread.getContextClassLoader()) is set
   to the web application's class loader.

   2. The correct behaviour at this point would be for the Driver to
  set
   the Thread's context class loader to the class loader that loaded
  the
   Driver class when the Thread is created.

   3. The memory leak occurs as follows:
   - the web application is stopped
   - Tomcat clears all references to the web application and its
  classes
   - The web application should be eligible for garbage collection
   - The JDBC driver is still loaded (as it should be)
   - The JDBC driver retains a reference to the Thread (as it should)
   - The thread retains a reference to the web application class loader
   (this is the memory leak).

   The reference chain is:
   a) JDBC driver
 b) Thread
   c) Web application class loader
 d) Every class loaded by the web app

   Everything from c) onwards should be eligible for garbage collection
   but isn't because of the leak in the Thread that is retaining a
   reference to the web application class loader.

   This is what I would assume as correct behavior. If the thread is
  still attached ot the WebAppClassLoader, does that mean that the
  WebAppClassLoader cannot be garbage collected?

  The correct behaviour is that there is no reference to c) held by b)
  and therefore c) onwards would be eligible for GC (assuming the web app
  has been stopped). The problem here is that because b) has a reference
  to c), c) can't be GC'd and that is a memory leak.

   2. Why does the JDBC Pool not unload the driver? That my cause the
  thread to stop after the last app has been stopped/undeployed.

   1. Because the driver is in CATALINA_HOME/lib it is available to
   other applications.

   So first app, loads driver and keeps it in memory. Even if all apps
  are undeployed, driver remains cached and GCed when Tomcat is shut
  down?

  The JDBC driver will be loaded though the services API as soon as any
  code references the DriverManager.

   2. JDBC drivers are never automatically unloaded. You have to do so
   explicitly (not doing so is an other source of memory leaks when the
   driver is packaged in WEB-INF/lib).

   OK, this won't be the case. Driver is always shared here.

   You need to go back to Oracle.

   Yes, I will. We're paying probably a lot of money for he company-wide
  license.

  I'd expect so.

  From my own experience with Oracle commercial support for things Java
  related, you'll have to go through the This is a bug. No it isn't. Yes
  it is... cycle several times before you manage to get the issue in
  front of someone

Re: ErrorReportValve's char encoding ignored


Am 2013-05-15 16:35, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Micheal,

On 5/15/13 3:46 AM, Michael-O wrote:

I have modified the ErrorReportValve's messages outside of the
one-byte range and the output got mangled. The response does not
contain a char encoding anymore.


Can you be more specific? What exactly did you modify, and how did you
modify it? What are the exact HTTP response headers that you get?


I know that the error valve does this:

response.setContentType(text/html);
response.setCharacterEncoding(utf-8);

but the setCharEnc method is completely ignored. Because the var
usingWriter is already set to true. This happens in the
ApplicationDispatcher#doForward line 393/394 when a servlet
performs a forward.


Looking at Tomcat 6.0.x/trunk line 393 is part of the cleanup code,
and the response PrintWriter is immediately closed. That does not
appear to have changed since 6.0.35. At this point, the request should
be /over/.

What else is going on? Is any content being generated before the
ErrorReportValve gets invoked? If the response has already been
committed, then Tomcat can't re-write the response headers.


Though a response.getReporter() is used but this one is completely
unaware of the char encoding.

I am on Tomcat 6.0.35.


Where is response.getReporter being called?


I presume this to be a bug. Should I file a BZ issue?


Hi Christopher,

did you get any chance to check my reply from 2013-05-15 17:13+02:00?
Hopefully, that mail made the issue clearer.

Thanks,

Michael


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

Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread

2013-05-21 Thread Michael-O


Am 2013-05-17 14:26, schrieb Mark Thomas:

On 17/05/2013 12:31, Michael-O wrote:

Hi Mark,

thanks again for the detailed answer, details inline.


Gesendet: Freitag, 17. Mai 2013 um 11:36 Uhr
Von: Mark Thomas ma...@apache.org
An: Tomcat Users List users@tomcat.apache.org
Betreff: Re: Follow-up: Possible false-postive with 
JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and 
OracleTimeoutPollingThread

On 17/05/2013 09:28, Michael-O wrote:

Hi folks,

there's now a follow-up on the issue [1].
Recap: JreMemoryLeakPreventionListener reported that my webapp has spawned 
OracleTimeoutPollingThread because I have set a QueryTimeout in the JDBC Pool.
Mark Thomas noted that this is likely a bug in the driver. I have taken action 
and created a service request with Oracle.

My personal analysis with VisualVM:
The thread is spawned when the first query is run. The thread keeps running 
when the webapp is shut down or undeployed. Classes remain in memory.
The JDBC Pool does a simple Class.forName to load the driver, it neither uses 
the DriverManager loading nor does it actively unload the driver.

Oracle answer:
They were able to reproduce the issue. The technical analysis says:


Hi Michael,

I confirmned internally that this message from Tomcat can be ignored as there is no risk 
of any real leak from OracleTimeoutPollingThread thread.
This thread is related to the JDBC driver which may be used by many apps 
simultaneously. Unloading the app does not unload the driver and should not and 
does not stop the thread.

It seems to be the design behaviour.


So my questions would be:
1. Is that still not a false positive?


No, that is not a false positive. The response from Oracle is wrong.

There is nothing wrong with the driver creating the thread or the thread
continuing after the web application has stopped. The problem is as follows:

1. When the JDBC driver creates the Thread, the Thread's context class
loader (as returned by Thread.getContextClassLoader()) is set to the web
application's class loader.

2. The correct behaviour at this point would be for the Driver to set
the Thread's context class loader to the class loader that loaded the
Driver class when the Thread is created.

3. The memory leak occurs as follows:
- the web application is stopped
- Tomcat clears all references to the web application and its classes
- The web application should be eligible for garbage collection
- The JDBC driver is still loaded (as it should be)
- The JDBC driver retains a reference to the Thread (as it should)
- The thread retains a reference to the web application class loader
(this is the memory leak).

The reference chain is:
a) JDBC driver
   b) Thread
 c) Web application class loader
   d) Every class loaded by the web app

Everything from c) onwards should be eligible for garbage collection but
isn't because of the leak in the Thread that is retaining a reference to
the web application class loader.


This is what I would assume as correct behavior. If the thread is still 
attached ot the WebAppClassLoader, does that mean that the WebAppClassLoader 
cannot be garbage collected?


The correct behaviour is that there is no reference to c) held by b) and
therefore c) onwards would be eligible for GC (assuming the web app has
been stopped). The problem here is that because b) has a reference to
c), c) can't be GC'd and that is a memory leak.



2. Why does the JDBC Pool not unload the driver? That my cause the thread to 
stop after the last app has been stopped/undeployed.


1. Because the driver is in CATALINA_HOME/lib it is available to other
applications.


So first app, loads driver and keeps it in memory. Even if all apps are 
undeployed, driver remains cached and GCed when Tomcat is shut down?


The JDBC driver will be loaded though the services API as soon as any
code references the DriverManager.


2. JDBC drivers are never automatically unloaded. You have to do so
explicitly (not doing so is an other source of memory leaks when the
driver is packaged in WEB-INF/lib).


OK, this won't be the case. Driver is always shared here.


You need to go back to Oracle.


Yes, I will. We're paying probably a lot of money for he company-wide license.


I'd expect so.


From my own experience with Oracle commercial support for things Java

related, you'll have to go through the This is a bug. No it isn't. Yes
it is... cycle several times before you manage to get the issue in
front of someone with the necessary knowledge and skills to correctly
identify this is a bug in Oracle's JDBC driver. I'd recommend escalating
it through your account manager sooner rather than later.

Feel free to point Oracle support to this thread and/or my presentation
on memory leaks. If Oracle support require further help understanding
this issue they are, of course, free to join this mailing list.


Mark,

I did receive an answer to the issue, citing your findings.
See verbatim copy below:

Hi Michael,

I received the following

Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread

2013-05-21 Thread Michael-O


Am 2013-05-21 20:38, schrieb Mark Thomas:

Seems like they understood the problem. But I do doubt that this is a
fixed size moemory leak.


I think the point they are trying to make is that it is only the first
instance of the web application to be unloaded that will be pinned in
memory. Subsequent reloads won't trigger a leak. That is correct.


Does this mean that only one WebAppClassLoader stays in memory because 
the thread is launched once and attached to that class loader?


Michael

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

Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread

2013-05-23 Thread Michael-O


Am 2013-05-21 20:38, schrieb Mark Thomas:

On 21/05/2013 19:01, Michael-O wrote:

Mark,

I did receive an answer to the issue, citing your findings.
See verbatim copy below:

Hi Michael,

I received the following update from our developer:

**
The theoretical problem is that the thread is holding the app class
loader so it remains reachable and the app is never unloaded. So if the
user loads and unloads the app, the app classes remain in memory.
Subsequent loading and unloading of the app will not get pinned in
memory as the thread is already running so the subsequent loading and
unloading will not cause additional class loaders to be pinned. It is a
fixed size memory leak. It does not grow.

The thread suggests setting the context class loader to be the parent of
the default context class loader. This may work in Tomcat but it's
pretty random. I am researching the problem to determine what if
anything the driver should do to work across all containers. A Tomcat
specific fix is not acceptable.


Almost but not quite. The correct fix is to set the context class loader
of the Thread to the class loader that loaded the Driver or,
alternatively, the class loader that loaded the thread class.


As Mark Thomas pointed out it is critical that the driver is loaded in
the boot or system or container class loader, not the app class loader.
If the driver is in the app class loader then when the app is unloaded
the driver also should be unloaded. Unfortunately this doesn't work. The
driver itself remains reachable so the app class loader is reachable so
the app is never unloaded. At present there is no general way to solve
this problem. The necessary hooks are added in JDK 8.


I'd agree to this point.


Most users put the
driver in the container, not the app, so this is rarely a problem.


I don't agree with this. I often see this with JDBC drivers which is why
Tomcat has a pile of code specifically to unpick the mess this creates.


**

I will certainly have to fill out a bug to have it investigated officially.


That is good news.


Seems like they understood the problem. But I do doubt that this is a
fixed size moemory leak.


I think the point they are trying to make is that it is only the first
instance of the web application to be unloaded that will be pinned in
memory. Subsequent reloads won't trigger a leak. That is correct.


Mark,

here's the next update from Oracle on the issue:

1. For those with Oracle Support access, here's the bug id: 16841748
2. Quote: I don't think any system property is needed. We have a 
solution for the timeout thread that should work for all app containers.


So Oracle is working on a fix, my SR remains open until I receive an 
updated ojdbc.jar.


Michael


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

Re: IE 8 and before refusing to download files (I hate IE)

2013-06-03 Thread Michael-O


Am 2013-06-04 00:40, schrieb Jeffrey Janner:

[..]
For those who might be interested, here are the two header sets returned:

Without SSLAuthenticator:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 18:00:00 CST
Content-Disposition: attachment; 
filename=SITE_VIEW_COST_SAVING_PART_NUMBER_%26QUOT%3BQUOTES_IN_PROJ_SV%26QUOT%3B_20130603.xls;
Content-Type: application/vnd.ms-excel
Transfer-Encoding: chunked
Date: Mon, 03 Jun 2013 22:34:41 GMT

With SSLAuthenticator:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Wed, 31 Dec 1969 18:00:00 CST
Content-Disposition: attachment; 
filename=SITE_VIEW_COST_SAVING_PART_NUMBER_%26QUOT%3BQUOTES_IN_PROJ_SV%26QUOT%3B_20130603.xls;
Content-Type: application/vnd.ms-excel
Transfer-Encoding: chunked
Date: Mon, 03 Jun 2013 22:29:41 GMT

Note the only real difference is the addition of a Pragma header.  Apparently, 
this is giving IE8 and earlier fits.
Anybody know how to disable the Pragma being added without using the 
SSLAuthenticator Valve?  Or remove it?


Hi Jeff,

I have observed this stupid IE behavior a couple of years ago. Took me 
almost a day to figure out. Though I use an authenticator in Tomcat 
which sets securePagesWithPragma to false.


Have you considered searching Tomcat's source code -- or better yet 
writing an always-pass-through authenticator which sets this flag by 
default?


Michael

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

Re: OT: How to use JSP outside of tomcat

2013-07-24 Thread Michael-O


Am 2013-07-24 19:22, schrieb Aryeh Friedman:

I have a number of documents that are very template like and ideal for
JSP that are 1) not intended for the web and 2) need to be
automatically batch processed (the output stored in output files).
How do I call the JSP processor from them command line? (it takes
tomcat too long to see updated files for the purpose I have in mind)


Use FreeMarker or Velocity for that. JSP was not designed for that.

Michael


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

Re: Cannot start apache tomcat 7.0 if server path contains two consecutive spaces.

2013-07-31 Thread Michael-O


Am 2013-07-31 07:11, schrieb TRAN Trung Thanh:

Hi all,
I am newbie here.
Today, I tried to start apache tomcat 7.0.42 in Linux environment.
Server path contains two consecutive spaces. When I run ./catalina.sh
run, server cannot start and there is the following exception in console

./catalina.sh run
Using CATALINA_BASE:   /home/example/twoconsecutive  spaces
Using CATALINA_HOME:   /home/example/twoconsecutive  spaces
Using CATALINA_TMPDIR: /home/example/twoconsecutive  spaces/temp
Using JRE_HOME:/home/example/java/jdk1.6
Using CLASSPATH:   /home/example/twoconsecutive
spaces/bin/bootstrap.jar:/home/example/twoconsecutive
spaces/bin/tomcat-juli.jar
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/catalina/startup/Bootstrap
Caused by: java.lang.ClassNotFoundException:
org.apache.catalina.startup.Bootstrap
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: org.apache.catalina.startup.Bootstrap.
Program will exit.

Tomcat server can start if  server path does not contain consecutive space.

Do anyone face to the same issue with me in this case? Have you any
suggestion to fix this issue?  It is quite important for my deployment.


Did you try to quote or use backslash escapes?


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

Re: Cannot start apache tomcat 7.0 if server path contains two consecutive spaces.

2013-08-01 Thread Michael-O

Am 2013-08-01 15:41, schrieb Jeffrey Janner:

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Wednesday, July 31, 2013 12:27 PM
To: Tomcat Users List
Subject: Re: Cannot start apache tomcat 7.0 if server path contains two
consecutive spaces.

TRAN Trung Thanh wrote:

Hi all,
I am newbie here.
Today, I tried to start apache tomcat 7.0.42 in Linux environment.
Server path contains two consecutive spaces. When I run ./catalina.sh
run, server cannot start and there is the following exception in
console

./catalina.sh run
Using CATALINA_BASE:   /home/example/twoconsecutive  spaces
Using CATALINA_HOME:   /home/example/twoconsecutive  spaces
Using CATALINA_TMPDIR: /home/example/twoconsecutive  spaces/temp
Using JRE_HOME:/home/example/java/jdk1.6
Using CLASSPATH:   /home/example/twoconsecutive
spaces/bin/bootstrap.jar:/home/example/twoconsecutive
spaces/bin/tomcat-juli.jar
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/catalina/startup/Bootstrap
Caused by: java.lang.ClassNotFoundException:
org.apache.catalina.startup.Bootstrap
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: org.apache.catalina.startup.Bootstrap.
Program will exit.

Tomcat server can start if  server path does not contain consecutive

space.

Do anyone face to the same issue with me in this case? Have you any
suggestion to fix this issue?

Yes : don't do that (using spaces in paths).

It is quite important for my deployment.

That's a pity.
Spaces in paths (and filenames) are evil, and should never have been
allowed in the first place.  A special place in hell is reserved for
the genius who first allowed this stupid thing in an OS.  I wish I had
0.1 cent for every programming hour lost because of this.

Technically, you can certainly find the correct way to quote them in
any particular place and environment.  But usually, this is merely
moving the problem to some other place further down the line, where it
is even less visible and harder to find the bugs.
I suppose the same could be said about any non-visible character, but
spaces (along with
TAB) are specially evil because in most environments, they are
considered either as valid separators between words/tokens or as non-
significant.

My serious recommendation would be to think really hard about a way to
nip this in the bud, and avoid allowing them and using them in the
first place.
Think that if you allow them somewhere, and even if you quote them
correctly there, you will have to continue quoting them (appropriately)
everywhere else that you are using the corresponding strings.  It is
almost guaranteed that this will bite you somewhere.

Agree with everything Andre says here. Even under Windows, where the OS seems 
to handle it fine, as long as you're in the GUI, it is a problem.  You have to 
remember to quote the path everytime you want to use it at the command line 
level, or in PowerShell, etc.
It is really easier to remember that if you want the look of a space, but need a 
non-printable character, to just use the underbar.  How much easier things could be if 
instead of My Documents you could write My_Documents.  Still looks like two 
words but it is only one.
As long as you have control over the naming, you should follow this advise.
Jeff

I guess for that reason Microsoft has replaced the C:\Documents and 
Settings folder.

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

Re: Apache Tomcat 8.0.0-RC1 release vote started


Am 2013-08-01 22:59, schrieb Mark Thomas:

If you'd like early sight of Tomcat 8 and an opportunity to contribute
to Tomcat development, the release vote has now opened for the first
Tomcat 8 release candidate.

Features include:
-[...]
- Update to DBCP2 (now includes JMX monitoring)

  ^
Why if we do have the wonderful Tomcat JDBC Pool? Can't we get rid of 
that relic?


Michael


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

Re: Apache Tomcat 8.0.0-RC1 release vote started


Am 2013-08-02 11:43, schrieb Mark Thomas:

Michael-O 1983-01...@gmx.net wrote:

Am 2013-08-01 22:59, schrieb Mark Thomas:

If you'd like early sight of Tomcat 8 and an opportunity to

contribute

to Tomcat development, the release vote has now opened for the first
Tomcat 8 release candidate.

Features include:
-[...]
- Update to DBCP2 (now includes JMX monitoring)

   ^
Why if we do have the wonderful Tomcat JDBC Pool?


1. Choice (we ship both).
2. Features (DBCP covers more edge cases).
3. Maintainability. There is more chance of a DBCP fix at the moment. That 
should change when Filip returns.
4. Performance they should be much closer but I suspect Tomcat JDBC will be 
faster (those edge cases again).


According to Apache's JIRA DBCP2 is still in the works whereas Tomcat 
JDBC Pool already works quite well. If so, I would favor the first 
option and make Tomcat JDBC Pool the default. Anyway DBCP2 will be a 
breaking change for DBCP 1.x users. Why not go the extra mile with 
Tomcat JDBC Pool and use that.



Can't we get rid of that relic?


We could but I would not support such a move.  (Relic? Hardly.)


I consinder it as a relic. Tomcat JDBC Pool's site even states that DBCP 
was written in ancient times withou multithreading in mind. Pre Java 5 
and so forth.


From my point of view, I have achieved tremendous improvements in our 
apps with Tomcat JDBC Pool and even found several bugs which would not 
have been possible with DBCP.


Michael



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

Re: Auto-loading of the SQL Server JDBC Driver in 6.0.35


Am 2013-08-02 21:24, schrieb mw...@loftware.com:

I expect that by putting the SQL Server JDBC4 driver jar
(sqljdbc4.jar) into ${CATALINA_HOME}/lib, that the driver would be
automatically available upon server start.  As expected, this works
in 6.0.33, but fails in 6.0.35.  It seems that the fix to Bug 51640
is the cause of this, and in fact, setting driverManagerProtection to
false in the JreMemoryLeakPreventionListener allows this to work in
6.0.35 as well.  I would not have expected that a change to the
MemoryLeak Listener would have changed the behavior of the JDBC
driver.

I don't know the internals of the SQL Server driver, so I don't know
exactly why this is happening.  The MySQL driver loads without any
issue.


Why should the driver being loaded into memory if no one uses it?
Actually, a driver is loaded into the container's classloader cache upon 
first access. This is what happens at least for me with the Oracle driver.


Everything else does not make sense to me.

Michael

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

Re: Apache Tomcat 8.0.0-RC1 release vote started