Re: how to prevent user access to JSP pages?

[David Wall]

Has any decision been made on how the original poster will do this?

As I read through the various responses, while you can always argue 
certain structures are better, it's simply not true that if you create 
messy/insecure JSPs, you'll somehow create clean/secure servlets.  Any 
error you would make in a JSP you'd make for sure in a servlet.  Again, 
JSPs are servlets.  You either protect requests coming in or not.  You 
can play with or hack parameters being sent to a servlet just as you can 
to a JSP.


For sure, if you go through a servlet controller that does the user 
login checks first before forwarding, that can make sense to concentrate 
the requests, and JSPs would just be coded to stop processing (or 
redirect to a login page, or return an error status) if it doesn't have 
a session/request parameter added by the servlet that did the 
authorization.


You can put all parameter checking into such a servlet, but that seems 
not much better than having each servlet/JSP do parameter checking for 
those it makes use of (if this were a known good, then we'd have just 
one big servlet that does everything rather than dividing the work among 
lots of them).  It seems that if you have JSPs, you'll want those to be 
checking params they expect (and safely ignore those you don't expect, 
or report them, or produce an error, whatever it is you expect to do 
when you see bad params come in).


It's unclear how direct access to a JSP is less secure than a servlet 
that will route requests to all of those same JSPs, other than your JSPs 
can somehow progress without caring who the authenticated user is.  In 
the end, a JSP typically doesn't just care that you are authenticated, 
but who exactly you are as your user account is sure to have permissions 
associated with it and will vary its processing based on the user.


Are there known exploits of direct JSP access that is shown to be solved 
by putting all JSPs under WEB-INF?


Also, if server identification is so bad (it does seem to make it a bit 
easier to look for known exploits), why does Tomcat not block reporting 
anything about itself as the default?  I can't imagine there are many 
deployments that prefer to be insecure so that they can provide Tomcat 
versioning info or the like.  I mean, how many deployments need the 
Tomcat version info returned as they would know what version they are 
because they installed it.



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

Re: how to prevent user access to JSP pages?

[David Wall]

I'll be curious to see the answers.

JSPs are servlets.

For us, the common way would be for your non-JSP servlets to 
authenticate the request (and save the results in the request), and then 
your JSPs can check if the request has been authenticated before 
progressing further.  Of course, if it's just a login check, you can 
save the results of the authentication in the session, and when missing, 
redirect to your login.



On 8/16/18 10:19 AM, Berneburg, Cris J. - US wrote:

Due to security concerns and general fussiness on my part, I'd like to prevent 
users from requesting JSP pages directly, except for the login page.  I want 
all requests to be handled by servlets.  That way I can legitimately claim that 
all requests are being validated, input scrubbed, JSP's cannot be taken 
advantage of w/o their servlet chaperones being present, etc.

a. One way I read is by adding a  for each folder.  One use case is 
for JSP include files.  That looks possible but makes it seem like these are exceptions and not 
the rule.  I want "deny, deny, deny" to be the default and the one or 2 allowable JSP 
pages to be the exception.

b. Another way mentioned is by having most of the JSP files under the WEB-INF 
folder.  That way the users don't have access to the JSP's but the servlets do. 
 My understanding is a little wobbly here, because I can't conceptualize the 
virtual path for files under WEB-INF when sending a response.  (See line of 
code below.)  Also, that would require moving most of the JSP files.


request.getRequestDispatcher("folder/file.jsp"); // what about WEB-INF?

Is there a "smart" way of doing this?  Perhaps it would have been prudent to organize the 
JSP folders "properly" in the first place, but we're way beyond that now.

Got any comments, suggestions, advice?

Thanks.  :-)

--
Cris Berneburg
CACI Lead Software Engineer





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

Re: configuring ciphers for SSL Labs server test

[David Wall]

We're doing good with this:

    protocols="TLSv1.1, TLSv1.2" honorCipherOrder="true"

ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256"
    >


On 5/10/18 2:45 PM, Baron Fujimoto wrote:

I'm trying to improve our grade on SSL Labs SSL server test[1] for our
Tomcat configuraton. Currently, their report caps our grade at B because,
"This server does not support Authenticated encryption (AEAD) cipher
suites". They report that we support the following cipher suites:

# TLS 1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

# TLS 1.1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are
using Java 1.8.0_162, and I believe we have the Java Cryptography
Extension (JCE) properly installed. I have the following connector
defined (this version explicitly lists ciphers I think should satisfy the
AEAD cipher requirement[2]):

 
 
 
 
 
 

I've mapped the cipher suite names using the OpenSSL cipher suite name
list[3]. I originally started with
ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK", but had the same
result, so subsequently tried adding the specific ciphers shown above. The
tomcat SSLHostConfig docs state that either the OpenSSL or JSSE cipher
names may be used[4].

Any suggestions on what I may be doing wrong or for further troubleshooting?

References:
[1] 
[2] 

[3] 

[4] 





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

Re: Session timeout despite user activity - websockets on Tomcat 8.5.16

[David Wall]

On 8/9/17 8:35 AM, Mark Thomas wrote:

On 09/08/17 16:09, David Wall wrote:

We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
Atmosphere Websockets.

We have had reports of sessions logging out while users are active with
our Vaadin-based application.  This has been frustrating as we can't
seem to track down why Tomcat's session is not being updated, but figure
it's something to do with the websockets/push not updating Tomcat reliably.

Our app shows a "last sent to server" timestamp that seems to keep
current with user activity, updating as the user clicks on buttons,
checkboxes, etc.

We also have a "list of active sessions" screen that shows all active
sessions including the HttpSession.getCreationTime() and
HttpSession.getLastAccessedTime().  We see it appears as if the last
accessed time stops being updated when using simple forms that perhaps
update via websockets rather than HTTP requests.  Our "last sent to
server" timestamp shows each of these clicks updating it, but the
HttpSession.getLastAccessedTime() is not updating.

Is there something about push/websockets or anything else that would
cause the HttpSession access time not to update?  I don't think we have
a way to update it ourselves as I believe it's managed by Tomcat itself,
but as Tomcat is handling the websocket requests, it's unclear why they
are not tied to the HttpSession.

Anybody have any ideas?  Thanks as we have a lot of frustrated users who
would love for us to find out what's going astray.

What you are seeing is expected behaviour. This was discussed in the
WebSocket EG. The short version is:
- WebSocket requests don't update the session's last accessed time
- you need an HTTP request from the browser to update the session's
   last accessed time (and update the expiry time of the browser's
   session cookie)
- so the application has to do periodic HTTP requests.

You can reduce the frequency of these requests by extending the session
timeout (remembering you need an HTTP request after this to update the
browser's cookie). You then need to be careful to reduce the timeout
again once WebSocket comms end.

Mark


Thanks, Mark.  Let me check but it is my impression that a HEARTBEAT 
type request is sent every 5 minutes, but I'll investigate further. You 
at least answered my question and we should be able to find a solution 
of that nature.


David

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

Session timeout despite user activity - websockets on Tomcat 8.5.16

[David Wall]

We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and 
Atmosphere Websockets.


We have had reports of sessions logging out while users are active with 
our Vaadin-based application.  This has been frustrating as we can't 
seem to track down why Tomcat's session is not being updated, but figure 
it's something to do with the websockets/push not updating Tomcat reliably.


Our app shows a "last sent to server" timestamp that seems to keep 
current with user activity, updating as the user clicks on buttons, 
checkboxes, etc.


We also have a "list of active sessions" screen that shows all active 
sessions including the HttpSession.getCreationTime() and 
HttpSession.getLastAccessedTime().  We see it appears as if the last 
accessed time stops being updated when using simple forms that perhaps 
update via websockets rather than HTTP requests.  Our "last sent to 
server" timestamp shows each of these clicks updating it, but the 
HttpSession.getLastAccessedTime() is not updating.


Is there something about push/websockets or anything else that would 
cause the HttpSession access time not to update?  I don't think we have 
a way to update it ourselves as I believe it's managed by Tomcat itself, 
but as Tomcat is handling the websocket requests, it's unclear why they 
are not tied to the HttpSession.


Anybody have any ideas?  Thanks as we have a lot of frustrated users who 
would love for us to find out what's going astray.


David


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

Re: [ANN] Apache Tomcat 8.0.35 available

[David Wall]

Does anybody know if the AES+GCM bug that causes a JVM Crash (I believe 
only under JDK 8) when running TLS in Tomcat using Java's JSSE has been 
fixed?  I doubt this is a Tomcat issue, but since the bug likely only 
appears for uses of TLS's AES+GCM in Tomcat, I hope someone here may 
know the details.  I can't seem to track the fix (it's a rather old bug 
considering the severity of a JVM crash just using TLS) in Java.


Thanks,
David


On 5/25/16 10:52 AM, Mark Thomas wrote:

Apologies for the delay in sending this out.

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.0.35.

Apache Tomcat 8.0 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language and Java
WebSocket technologies.

Apache Tomcat 8.0.35 includes fixes for issues identified in 8.0.33 as
well as other enhancements and changes. The notable changes since 8.0.33
include:

- Make the default TLS configuration more secure.

- Update the packaged version of the Tomcat Native Library to 1.2.7
   to pick up the Windows binaries that are based on OpenSSL 1.0.2h
   and APR 1.5.2.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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




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

Re: Can filters be loaded more than once?

[David Wall]

Thanks for the help, Chris.  I did note that some of the webapp web.xml 
files didn't include the async option.  I've decided for now we'll use 
Tomcat's conf/web.xml to set this basic filter and let our webapps not 
have to think about it.


On 8/28/15 12:27 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 8/28/15 2:47 PM, David Wall wrote:

I'm using Tomcat 8.0.23, but wondered if a filter defined in the
Tomcat conf/web.xml as well as defined in my app's WEB-INF/web.xml
file causes the filter to be loaded twice or whether duplicate
filters are ignored?

If duplicates are ignored, what makes it a duplicate?  Just the
name, the filter-name and url-pattern combo?  The filter-class?

I've never looked into this, but I would imagine that Tomcat does no
checking for duplicate filter definitions. Otherwise, the above
questions are raised :)


Is the filter-name field can sensitive?

Almost certainly.


Noted that Tomcat uses a lowercase 's' for it's filter name.

In Tomcat's conf/web.xml:

filter filter-namesetCharacterEncodingFilter/filter-name
filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/

filter-class

  init-param param-nameencoding/param-name
param-valueUTF-8/param-value /init-param
async-supportedtrue/async-supported /filter

filter-mapping
filter-namesetCharacterEncodingFilter/filter-name
url-pattern/*/url-pattern /filter-mapping

Note that the above Filter is commented-out by default.


In my webapp's WEB-INF/web.xml:

filter filter-nameSetCharacterEncodingFilter/filter-name
filter-class
org.apache.catalina.filters.SetCharacterEncodingFilter
/filter-class async-supportedtrue/async-supported !-- Enable
if using Vaadin PUSH -- init-param
param-nameencoding/param-name param-valueUTF-8/param-value
/init-param /filter

filter-mapping
filter-nameSetCharacterEncodingFilter/filter-name
url-pattern/*/url-pattern /filter-mapping

When using Atmosphere with Vaadin PUSH, I occasionally get an
exception that indicates an issue with async operations, and it
shows my filter twice in the stack trace:

*java.lang.IllegalStateException: A filter or servlet of the
current chain does not support asynchronous operations.** *
at
org.apache.catalina.connector.Request.startAsync(Request.java:1610)

Boy,
it would be nice if Tomcat told you which Filter of or Servlet of
the current change didn't support asynchronous operations. I don't
immediately see a good way of getting that information from the
Request object. :(

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV4LYQAAoJEBzwKT+lPKRYjMoQAJuw/bu4Efmw/Mc0tm6hXaaU
fJBSSsfZJfPGzahCvMGRTciTEe/E7cjsSIHgkdZKy1UUYSx2mnLZNTkiMaQRu2Sg
XmmN6nzKC7dtNPrYGgkN+RqbUJXjpeO0vV6RLJHdzGcQ9vQ4409t733QQuFbuzeS
DfcCCnSiwK8i4APQyuQWpuT4Th/kyehZfp4mtlIQHN6BsmekRH6VUIHI9rRajPgF
zUtPEXnqdlXOD5B2dtRDePQNBVIO5s8Es+GzD68L2m/XseIt6WxbHUYe8lGcKp6g
7O7LBfe+VhgCaIsoC/aPJ9hyA75z1p/O1h8Rcb8ft4G8BYdvVYQl6Dc76XzYdVYy
RdSu5FaGBRsCAromAJ0/ThSa2oKPMcrINUkMDdoMGE12Rr5+d/QVO6jMlpq0MgqY
PkXox+eB7pzcFFUkU4wWDOe3xqVHgMWW4E3dop+tfCHti9HDhfcgUNP6ch7MAEIm
8+3iZ8DKeyqmvp1TQn9HQcM/I+or0qE3GvQsYZR00Z4C7Rp4/QdmMMhZwNoqgnHw
kCxrIgCA2KPeEBYVkTsx9LG0P8dzitDps3EFLTsETSygfd1JmrCPx+8PlrAgjkcM
7FnrJAHX1fZ28EoNMmdf8f0FJ3InmBB9APO3Kw+YbayJeZxuV4gg/dAPZT3PGI0p
RYZ2Ubhc8zpwgOTjEHMC
=DJRR
-END PGP SIGNATURE-

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




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

Can filters be loaded more than once?

[David Wall]

I'm using Tomcat 8.0.23, but wondered if a filter defined in the Tomcat 
conf/web.xml as well as defined in my app's WEB-INF/web.xml file causes 
the filter to be loaded twice or whether duplicate filters are ignored?


If duplicates are ignored, what makes it a duplicate?  Just the name, 
the filter-name and url-pattern combo?  The filter-class?


Is the filter-name field can sensitive?  Noted that Tomcat uses a 
lowercase 's' for it's filter name.


In Tomcat's conf/web.xml:

filter
filter-namesetCharacterEncodingFilter/filter-name
filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter-class
init-param
param-nameencoding/param-name
param-valueUTF-8/param-value
/init-param
async-supportedtrue/async-supported
/filter

filter-mapping
filter-namesetCharacterEncodingFilter/filter-name
url-pattern/*/url-pattern
/filter-mapping

In my webapp's WEB-INF/web.xml:

filter
filter-nameSetCharacterEncodingFilter/filter-name
filter-class
org.apache.catalina.filters.SetCharacterEncodingFilter
/filter-class
async-supportedtrue/async-supported !-- Enable if using Vaadin 
PUSH --

init-param
 param-nameencoding/param-name
 param-valueUTF-8/param-value
/init-param
/filter

filter-mapping
filter-nameSetCharacterEncodingFilter/filter-name
url-pattern/*/url-pattern
/filter-mapping

When using Atmosphere with Vaadin PUSH, I occasionally get an exception 
that indicates an issue with async operations, and it shows my filter 
twice in the stack trace:


*java.lang.IllegalStateException: A filter or servlet of the current 
chain does not support asynchronous operations.**
*at 
org.apache.catalina.connector.Request.startAsync(Request.java:1610)
  at 
org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1037)
  at 
javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:392)
  at 
org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:723)
  at 
org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:93)
  at 
org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:68)
  at 
org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:2075)
  at 
com.vaadin.server.communication.PushRequestHandler.handleRequest(PushRequestHandler.java:226)
  at 
com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1408)

  at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:351)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
  at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
*at 
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)*
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
*at 
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)*
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
  at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
  at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
  at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:614)
  at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
  at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
  at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:617)
  at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
  at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
  at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
  at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)

Re: Need configuration example for Tomcat 7.0.55 TLS configuration

[David Wall]

We're on Tomcat 8 with Java 8, so it has more options for ciphers, but 
this is what we use:


Connector port=8443 
protocol=org.apache.coyote.http11.Http11NioProtocol SSLEnabled=true
   connectionTimeout=2 acceptorThreadCount=2 
URIEncoding=UTF-8

   maxThreads=100 scheme=https secure=true
compression=on 
compressableMimeType=text/html,text/xml,text/plain,application/xml,application/json,application/javascript,application/pdf
keystoreFile=tomcatKeystoreFileName keystorePass=PUT 
YOUR KEYSTORE PASSWORD HERE

ciphers=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA
   clientAuth=false sslEnabledProtocols=TLSv1, TLSv1.1, 
TLSv1.2 /


As I understand it, we no longer can be connected by IE6 or even Java 6 
clients because they won't have the ciphers required.


Hope that helps some even if a bit off the main question of using Tomcat 
7 (though I see no advantage to using the older one unless there's some 
problem).



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

Re: Lambda expression question on Tomcat_8_0_15

[David Wall]

On 12/15/2014 12:19 PM, Anup Aggarwal wrote:

Hi,

I am new to learn the LambdaExpression , and I am trying to run a test with
JDK7 on Tomcat_8_0_15 server


Don't you need JDK8 for Lamdas?


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

Re: http status 400 question

[David Wall]

On 4/17/2014 7:50 AM, Christopher Schultz wrote:
I'll take a look at the code to see if maybe we can conditionally log 
something somewhere when we get a 400 error. You can probably get 
information about it by enabling DEBUG logging on the component that 
throws the 400 error, but you'll likely get a huge amount of output in 
that log file, which you obviously don't want. 


Our first remedial action was to to add URIEncoding=UTF-8 to our HTTP 
and HTTPS connectors defined in server.xml, as well as added a character 
encoding filter to our webapp's web.xml:


filter
filter-nameSetCharacterEncodingFilter/filter-name
filter-class
org.apache.catalina.filters.SetCharacterEncodingFilter
/filter-class
init-param
param-nameencoding/param-name
param-valueUTF-8/param-value
/init-param
/filter

filter-mapping
filter-nameSetCharacterEncodingFilter/filter-name
url-pattern*/url-pattern
/filter-mapping

We've not see any issues since.  Could this have played a role somehow 
in resolving this, or just coincidence for now?


Do you know if using the above setup we can remove our own JSP page 
bean init code shown below that sets the character encoding like we 
have now?  Seems like our code below was trying to accomplish what I 
believe the SetCharacterEncodingFilter is now doing for every request 
(not just those that reach our JSPs).


try
{
if ( request.getCharacterEncoding() == null )
request.setCharacterEncoding(CHARSET_UTF_8);
response.setCharacterEncoding(CHARSET_UTF_8);
}
catch( UnsupportedEncodingException e )
{
app.warning(PageBean.init() - Failed to set request/response to 
UTF-8 encoding.);

}

Our JSPs already specify charset=UTF-8 in the content type and/or HTML 
meta tag for Content-Type.


We're keeping our fingers crossed!



It could also be possible that a browser is incorrectly-formatting
something. Do you make extensive use of cookies Do you ever store
anything in a cookie name or value that isn't in US-ASCII? If so, you
might have some edge cases where the overwhelming majority of your
users are find but some folks with Greek names or whatever step-over
into non-US-ASCII and hit some edge cases with either the browser or
Tomcat itself.


Aside from the session cookie for JSESSIONID done by Tomcat, we 
generally only have one cookie that is optional for those who want to 
save their login email address.  For these, we are using 
java.net.URLDecoder.decode/java.net.URLEncoder.encode of the email 
address string specifying the UTF-8 charset param to the encoder/decoder.


Does that sound like it could be an issue for these edge cases you are 
talking about since my impression is that such encoding would ensure 
US-ASCII was the cookie value?


Thanks for your help and consideration, Christopher!

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

Re: http status 400 question

[David Wall]

Thanks, Christopher.

One last question has to do with the filter-mapping's url-pattern element.

Are url-pattern/*/url-pattern and url-pattern*/url-pattern the 
same?


My impression is that /* is more correct since a * pattern implies a 
file name suffix but there's nothing after it.  Is that true, or do /* 
and * work the same to mean to match every request?  The spec does not 
seem to describe * all by itself and so sounds less correct.


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

http status 400 question

[David Wall]

I am running Tomcat 7.0.47 and it occasionally returns HTTP status codes 
of 400, such as the following from my access log.


A 400 suggests a malformed request, but many of these are simple GET 
requests on an image, so it seems odd they are malformed.  We're not 
positive, but it seems that as these occur on JSP requests, we appear to 
be able to process a request though we get 'null' for various things 
like request.getRequestURI(), request.getScheme(), etc.


I read something about these and perhaps character set encoding, and we 
do have code like this at the beginning of our page processing (though 
the cannot be directly tied as our JSP/servlets don't process images and 
javascript requests):


try
{
if ( request.getCharacterEncoding() == null )
request.setCharacterEncoding(CHARSET_UTF_8);
response.setCharacterEncoding(CHARSET_UTF_8);
}
catch( UnsupportedEncodingException e )
{
app.warning(PageBean.init() - Failed to set request/response to 
UTF-8 encoding.);

}


Here's our access log of some recent 400s:

199.231.xx.xxx - - [16/Apr/2014:12:16:31 -0400] GET 
/XXX/esfapp/images/esignFormsPlain.gif HTTP/1.1 400 - 0 Mozilla/4.0 
(compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET 
CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 
6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E)
199.231.xx.xxx - - [16/Apr/2014:12:16:33 -0400] GET 
/XXX/esfapp/scripts/sorttable.js HTTP/1.1 400 - 0 Mozilla/4.0 
(compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET 
CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 
6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E)
199.231.xx.xxx - - [16/Apr/2014:12:16:33 -0400] GET 
/XXX/esfapp/scripts/sorttable.js HTTP/1.1 400 - 4 -
199.231.xx.xxx - - [16/Apr/2014:12:16:33 -0400] GET 
/XXX/esfapp/images/calendar20x14.gif HTTP/1.1 400 - 0 Mozilla/4.0 
(compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET 
CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 
6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E)


160.109.NN.NN - - [16/Apr/2014:12:17:18 -0400] GET 
//images/logoR.gif HTTP/1.1 400 - 2 Mozilla/4.0 (compatible; MSIE 
8.0; Windows NT 5.1; Trident/4.0; InfoPath.2; .NET CLR 1.1.4322; .NET 
CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C)
160.109.NN.NN - - [16/Apr/2014:12:17:18 -0400] GET 
//images/logoR.gif HTTP/1.1 400 - 0 Mozilla/4.0 (compatible; MSIE 
8.0; Windows NT 5.1; Trident/4.0; InfoPath.2; .NET CLR 1.1.4322; .NET 
CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C)


71.220.ZZZ.ZZZ - - [16/Apr/2014:12:28:44 -0400] GET 
/ZZ/leaserenewal/js/form-functions.js HTTP/1.1 400 - 0 Mozilla/5.0 
(Windows NT 5.1; rv:28.0) Gecko/20100101 Firefox/28.0



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

Re: http status 400 question

[David Wall]

On 4/16/2014 3:17 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


The access log of course does not give the whole story. It's possible
that the client sent for example a badly-formed HTTP header value. In
those cases, the request-line (shown in the access log) can be read
and the target context determined, but the headers can fail.

Can you narrow-down the types of requests that cause this to occur at
all? If so, you could enable a request dumper and set it to match
those requests (I think you have to write a Valve to sniff the request
and place an attribute in the request in order to trigger the request
dumper to dump the request). I wouldn't recommend using the
request-dumper on all requests: it would slow everything to a crawl
and likely represent a privacy problem as well).

- -chris


Chris,

Thanks for the reply.  We're not sure about the status 400s -- like 
today, we show 349 of them, but yesterday it was 157, and on Monday 
122.  The prior Wednesday, there were 0.


Some appear to be hack attempts or the like with requests like this:
62.210.114.138 - - [10/Apr/2014:04:02:28 -0400] GET 
/w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1 400 - 0 -
62.210.114.138 - - [10/Apr/2014:04:02:28 -0400] GET 
/w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1 400 - 0 -


But most seem to be a combination of images and JSPs that are on our 
system.  Even the user agent strings appear to be highly varied and 
requests come throughout the day.


I've never done a request dumper before, but is there a way to trigger 
it only if Tomcat is going to issue a 400?


We run the same sort of software on other servers that seem to have 
these only rarely, and the access logs make them appear like they are 
hacker/sniffers perhaps:


107.152.128.226 - - [31/Dec/1969:16:00:00 -0800] - 400 - 0 -
107.152.128.226 - - [31/Dec/1969:16:00:00 -0800] - 400 - 0 -
188.95.234.6 - - [16/Apr/2014:04:59:58 -0700] HEAD / HTTP/1.1 400 - 0 -

But the ones originally mentioned seem to be more likely coming from 
regular users.  What is odd is we've never had any reports of users 
complaining, but you'd think those 400s would cause someone to grumble.  
Because they appear to have valid URLs in the access logs, often 
containing the unique 20 random characters that are used by our 
application to identify a specific resource, it seems unlikely they are 
also hacker types.  The links otherwise work if we enter them into our 
browser and they should be impossible for others to guess.


David



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

Re: http status 400 question

[David Wall]

I've never done a request dumper before, but is there a way to trigger 
it only if Tomcat is going to issue a 400?


Sorry for replying to my own posting, but for JSP urls, we do seem to 
know that request.getScheme() for example returns null when things are 
bad, though I'm not sure how a bad request even makes it to my JSP if 
it's truly malformed.


Could I use that somehow so do the request dumper aspect?  I need a few 
pointers for doing it, but it sounds like I need to install some code 
that would check for the scheme being null and then do something else to 
cause the request to dump.


Is that right?  Is that a possible approach I should take?   The issue 
is this is a customer system so we cannot make changes but in the 
evenings when they are not using it and then it probably will have to 
run all day before it can be removed later.


Thanks for any tips!

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

Re: Tomcat bug 53814 - PDF plugin in IE cannot download correctly

[David Wall]

On 10/15/2012 6:37 PM, 孙文 wrote:

You are not suitable the open source community and you are a selfish guy.



Wonderful, helpful and insightful!

I egregiously suggested that reverting a line of code back to 7.0.26, 
which was also standards-compliant, would have been easy and would have 
helped many who use PDF and IE, an apparently selfish request even 
though I rarely use IE myself.


It seemed practical and helpful to me, in the spirit of open source, a 
community I respect and contribute to daily.


By the way, the web.xml change we made was suggested in the bug report 
and seems to resolve it for our IE site visitors.


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

Tomcat bug 53814 - PDF plugin in IE cannot download correctly

[David Wall]

In researching a bug our users are now suffering, I found that it was 
reported already as *Bug 53814- Could not display PDF file on Tomcat 
7.0.27 above.*


Sadly, it also shows that's it's considered invalid and won't be fixed 
because the change made between 7.0.26 and 7.0.27 is standards compliant.


That's a rather unsatisfying answer considering it affects PDFs and IE, 
a rather common combination.


The change was made in the 7.0.27 release, causing the bug to appear.  
Yes, the bug is in fact in the PDF reader of IE, but it is sad when a 
bug release (not going from 7.0 to 7.1, but 7.0.26 to 7.0.27) introduces 
new problems.


Putting the space separator back in seems so straightforward unless 
removing the space actually fixes something else. It is not clear in the 
bug report if the change was made for a particular reason or not since 
bug 52811 doesn't appear to be an issue with 'boundary' at all.


It is not clear that having the space would not be compliant with the 
spec.  The comment in the bug report even says that all of the examples 
in the specification have a whitespace before parameter.


I guess I can understand a change like this that will break working 
systems if the change were required to be standards compliant and 
standards-compliant browsers had trouble because of the space being 
there, but if not, it shouldn't occur in such a late patch release 
(7.0.27) rather than a new minor release like 7.1.


I hope that keeping things working is the prevailing idea behind patch 
releases.  Of course, it's not surprising that IE would be the one 
browser to have this problem handling standards-compliant syntax!


David

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

[David Wall]

Chris,

Thanks for the 'findbugs' tip.  I'm running it now in Eclipse and it has 
indeed found real bugs and some good stylistic ideas as well.


David

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

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

[David Wall]

Just a quick update on these several threads of Tomcat 7 oddball 
exceptions.  It looks to be as Chuck believed that it was a coding error 
on our end that was causing this.  In particular, it was the no-no 
misuse of instance variables in a controlling servlet.


Thanks for everyone's help!

David

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

Re: Tomcat 7 Exception initializing page context; Cannot create a session after the response has been committed

[David Wall]

Just a quick update on these several threads of Tomcat 7 oddball 
exceptions.  It looks to be as Chuck believed that it was a coding error 
on our end that was causing this.  In particular, it was the no-no 
misuse of instance variables in a controlling servlet.


Thanks for everyone's help!

David

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

Re: Tomcat 7 - .ApplicationDispatcher invoke - Cannot create a session after the response has been committed

[David Wall]

Just a quick update on these several threads of Tomcat 7 oddball 
exceptions.  It looks to be as Chuck believed that it was a coding error 
on our end that was causing this.  In particular, it was the no-no 
misuse of instance variables in a controlling servlet.


Thanks for everyone's help!

David

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

Tomcat 7 Exception initializing page context; Cannot create a session after the response has been committed

[David Wall]

We are running Tomcat 7.0.26 (no httpd front end) with BIO/NIO and SSL 
(entire webapp is in security context) and see this exception 
periodically on our Linux server:


May 2, 2012 3:03:45 AM org.apache.jasper.runtime.JspFactoryImpl 
internalGetPageContext

SEVERE: Exception initializing page context
java.lang.IllegalStateException: Cannot create a session after the 
response has been committed
at 
org.apache.catalina.connector.Request.doGetSession(Request.java:2855)
at 
org.apache.catalina.connector.Request.getSession(Request.java:2306)
at 
org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:897)
at 
org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:909)
at 
org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:146)
at 
org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:125)
at 
org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:112)
at 
org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:65)
*at 
org.apache.jsp.playerRegistration2_jsp._jspService(playerRegistration2_jsp.java:72)*
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

*at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)*
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)

*at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)*
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1600)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:662)

That line of code in our JSP's .java file show it to be method 
_jspService's second statement:


  pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);

What might cause this?  Curious as to why the 'service' method of 
HttpServlet line 722 is called twice in the call stack.  How could any 
response have been sent out and committed when this seems to be before 
my JSP's main body of code is even executed?  After that line of code, 
about 7 statements down is the code that emits the first HTML line from 
our JSP:


  out.write(!DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\ 
\http://www.w3.org/TR/html4/strict.dtd\;\r\n);


And right after that is where my page bean class is instantiated or 
retrieved:


  bean = (org.example.PlayerRegistration2Page) 
_jspx_page_context.getAttribute(bean, 
javax.servlet.jsp.PageContext.REQUEST_SCOPE);

  if (bean == null){
bean = new org.example.PlayerRegistration2Page();
_jspx_page_context.setAttribute(bean, bean, 
javax.servlet.jsp.PageContext.REQUEST_SCOPE);

  }

My actual JSP source file top lines looks normal:

!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN 
http://www.w3.org/TR/html4/strict.dtd;
%@page contentType=text/html; charset=ISO-8859-1 
import=org.example.PlayerRegistration2Page%
jsp:useBean id=bean scope=request 
class=org.example.PlayerRegistration2Page /


So this is Tomcat throwing an exception before it even reaches my code.  
What might be the cause since of course the webapp works fine most of 
the time.


Thanks,
David

Tomcat 7 NIO Socket accept failed - Too many open files

[David Wall]

I am running Tomcat 7.0.26 on Linux we received a lot of the following 
exceptions during load testing:


May 2, 2012 3:04:03 AM org.apache.tomcat.util.net.NioEndpoint$Acceptor run
SEVERE: Socket accept failed
java.io.IOException: Too many open files
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:152)
at 
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:784)

at java.lang.Thread.run(Thread.java:662)

Is there something I can tune to remove this as a problem?  My NIO+SSL 
connector is configured like this:


Connector port=8443 
protocol=org.apache.coyote.http11.Http11NioProtocol SSLEnabled=true
   maxThreads=800 scheme=https secure=true 
acceptCount=200 connectionTimeout=4000 acceptorThreadCount=2

keystoreFile=keys/tomcatkeys keystorePass=VALUEREMOVED
   clientAuth=false sslProtocol=TLS /

During the test, we had created about 1,800 concurrent sessions, though 
I think many of those were active because of the exceptions kept the 
user's transaction from completing and when their session would end 
normally.


Thanks,
David


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

Re: Tomcat 7 NIO Socket accept failed - Too many open files

[David Wall]

On 5/2/2012 12:34 PM, Pid * wrote:

It's an OS issue: google 'ulimit'.


p


Yes, I am familiar with ulimit -Sn (it's 1024), but I suspect this could 
be a Tomcat issue somehow opening too many files and/or not releasing 
them.  I had never seen this issue before we upgraded from Tomcat 5.5 
(all using BIO) to Tomcat 7.0 (all using NIO).  We run on lots of 
servers, and none have shown this error before (and they are all Linux 
servers all set to 1024 for open files).  But we will give it a try by 
setting to a higher number.


The reason we suspect it's Tomcat is that we're getting other 
exceptions, too, those that indicate our session/request objects are not 
valid when our JSPs are running (and of course work fine when the loads 
are normal, but start to fail when we push lots of concurrent requests 
at Tomcat).


David

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

Tomcat 7 - No modifications are allowed to a locked ParameterMap

[David Wall]

We are running Tomcat 7.0.26 and have not see this except before running 
high load testing.  It's an odd exception in that our getParam() code is 
just calling: String[] pv = request.getParameterValues(name);


That is, we are not making a call that should be attempting to change 
any parameter value/map.  We are just trying to retrieve a parameter 
value using the standard HttpServletRequest given to JSP/servlet code.


May 2, 2012 1:55:03 AM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: No modifications are allowed to a 
locked ParameterMap

at org.apache.catalina.util.ParameterMap.put(ParameterMap.java:170)
at 
org.apache.catalina.connector.Request.getParameterMap(Request.java:1167)
at 
org.apache.catalina.connector.RequestFacade.getParameterMap(RequestFacade.java:444)
at 
org.apache.catalina.core.ApplicationHttpRequest.parseParameters(ApplicationHttpRequest.java:755)
at 
org.apache.catalina.core.ApplicationHttpRequest.getParameterValues(ApplicationHttpRequest.java:416)

at com.esignforms.html.ServletUtil.getParam(ServletUtil.java:128)
at com.esignforms.jsp.PageBean.getParam(PageBean.java:2813)
at 
com.esignforms.jsp.PageBean.getViewOnlyPickupCodeFromRequest(PageBean.java:4131)

at com.esignforms.jsp.PageBean.init(PageBean.java:277)
at 
org.apache.jsp.playerRegistration2_jsp._jspService(playerRegistration2_jsp.java:92)
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:329)

at com.esignforms.servlet.Launch.doGet(Launch.java:100)
at com.esignforms.servlet.Launch.doPost(Launch.java:116)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1600)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:662)

It is coming from our Launch servlet at the line where we essentially 
are forwarding the request to a JSP page using: 
request.getRequestDispatcher(url).forward(request, response);


Why would Tomcat be changing the map when I'm just requesting to get a 
value from it?


Thanks,
David


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

Tomcat 7 - .ApplicationDispatcher invoke - Cannot create a session after the response has been committed

[David Wall]

Here's another odd exception we are receiving on Tomcat 7.0.26 when 
doing load testing.


When this exception occurs, our code is basically calling: 
response.encodeURL(url);


It's in a FORM tag we created that is defined on a JSP page that should 
already have a session object created by:


%@page contentType=text/html; charset=ISO-8859-1 
import=org.example.PlayerRegistration2Page%


or more likely by our Launch servlet that is called before forwarding to 
the JSP with code like:


HttpSession session = request.getSession();
if ( session == null )
  return;

So we should already have a session created, and our FORM tag is in the 
middle of the JSP page where there is no code to invalidate the 
session.  It really seems like Tomcat is confusing sessions or the like 
when the load gets high, but not sure how to show/prove that.


May 2, 2012 1:55:48 AM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: Cannot create a session after the 
response has been committed
at 
org.apache.catalina.connector.Request.doGetSession(Request.java:2855)
at 
org.apache.catalina.connector.Request.getSessionInternal(Request.java:2465)
at 
org.apache.catalina.connector.Response.encodeURL(Response.java:1236)
at 
org.apache.catalina.connector.ResponseFacade.encodeURL(ResponseFacade.java:406)

at com.esignforms.jsp.PageBean.encodeSession(PageBean.java:3321)
at com.esignforms.jsp.PageBean.getMySessionUrl(PageBean.java:3276)
at com.esignforms.html.taglibs2.Form.doStartTag(Form.java:95)
at 
org.apache.jsp.playerRegistration2_jsp._jspService(playerRegistration2_jsp.java:230)
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:329)

at com.esignforms.servlet.Launch.doGet(Launch.java:100)
at com.esignforms.servlet.Launch.doPost(Launch.java:116)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1600)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:662)

Has anybody seen this?  We never saw it under Tomcat 5.5, but then we're 
not sure it was ever under the same load we are now throwing at Tomcat 7.


Thanks,
David


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

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

[David Wall]

On 5/2/2012 2:17 PM, Caldarale, Charles R wrote:

Both this symptom and your earlier one about creating a session after a 
response has been committed are representative of the kinds of errors seen when 
a webapp stores references in an inappropriate scope.  For example, keeping a 
reference to a request or response object in a static field, a session, or a 
thread-local, will often result in the wrong object being used later on.  This 
is especially evident under high-load situations...

  - Chuck


Thanks, Chuck.  I know you are an expert here.  That could be since it's 
very odd to have all of these different sorts of exceptions occurring on 
what should be standard JSP/servlet code, as if my 
request/response/session objects are messed up.


That being said, our PageBean class associated with our JSPs are all 
at the 'request' scope:


jsp:useBean id=bean scope=request 
class=org.example.PlayerRegistration2Page /


The PageBean holds a reference to the request, response and session 
objects, as defined in the JSP's java code, but we are passing in the 
standard objects our page should be getting from Tomcat:


bean.init(session,request,response);

I am pretty sure we never store the request/response objects in the 
session, static field or thread-local.  So once a response is sent back, 
it seems that our PageBean class should fall out of scope as it was tied 
into the request scope.


We have implemented our own HttpSessionListener so we can track 
sessionCreated and sessionDestroyed events.  So I am saving the session 
objects between the two events which we use to show all active users 
including the session start time and last accessed time (which is why we 
store the actual session object).   We started 13,350 sessions during 
the test, with a max of 1800 concurrent sessions.  But we don't seem to 
have trouble keeping track of them because now that the testing is done, 
we can see just the current user sessions listed (in this case, just 
two, both started recently), so all of those sessions eventually ended 
or expired and were then removed from our tracking list.


Is it possible that if we keep a handle on the session (though we remove 
that on sessionDestroyed) this prevents Tomcat from some sort of GC 
issue with respect to the sessions?


Your thoughts on this are much appreciated.

David


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

Re: Tomcat 7 - .ApplicationDispatcher invoke - Cannot create a session after the response has been committed

[David Wall]

On 5/2/2012 2:41 PM, Caldarale, Charles R wrote:
Look carefully at the code in your webapp(s) for issues like the ones 
described in an earlier response.

Has anybody seen this?

Lots of times - and it's _always_ been a problem in a webapp.

  - Chuck


I hope my comment about our session tracking may somehow be related, as 
that's a webapp-wide shared list.  I am pretty sure we don't have static 
references to session/request/response, store request/response objects 
in a session, or use thread-locals.  All of our code uses request scope 
operations.


Is there any tool or method I should use to find such a problem?  I 
mean, I can look over the key code areas, but do you know of anything 
that might help me find it?


Thanks again,
David

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

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

[David Wall]

On 5/2/2012 2:17 PM, Caldarale, Charles R wrote:

Both this symptom and your earlier one about creating a session after a 
response has been committed are representative of the kinds of errors seen when 
a webapp stores references in an inappropriate scope.  For example, keeping a 
reference to a request or response object in a static field, a session, or a 
thread-local, will often result in the wrong object being used later on.  This 
is especially evident under high-load situations...

  - Chuck


Okay, it looks like you put me on the right track. Just discovered that 
one of the servlets uses an instance variable to hold the 
request/response/session objects. Oy, and it was like that since 2008!  
Not positive this will resolve all the issues, but it's a clear bug.  
Thanks for your tip.


David

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

Re: Tomcat 7.0.19 character encoding issue with JSP

[David Wall]

Thanks for the ideas, Mark, but it's still the same undesirable result.

On 9/1/2011 6:58 AM, Mark Thomas wrote:

I suspect you need:
%@ page pageEncoding=UTF-8 %
at the start of your JSP.

.java files are written using UTF-8 by default so if what you see there
is wrong then the original .jsp file was read with the wrong encoding.


My JSP file that I write shows it correctly since changing my 
PrintWriter to set the stream to UTF-8.


!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
%@ page pageEncoding=UTF-8 contentType=text/html; charset=UTF-8 
session=true isELIgnored=true %
%@ taglib uri=http://open.esignforms.com/libdocsgen/taglib; 
prefix=esf %

...
pThese have issues: ► Ŵ but these don#39;t: trade; hArr; diams; 
aacute; para; yen;/p

...

But the generated .java files still shows:

out.write(pThese have issues: â–º Å´ but these don#39;t: trade; 
hArr; diams; aacute; para; yen;/p\n);


I checked and the file mod timestamps are updated so I know these are 
newly created files when I run the generated JSP.  I noted that the 
compiler was looking for UTF-8 (and not allowing UTF8 or utf-8 or 
other variants).


My only guess now is to know what's the file encoding used when the 
Tomcat compiler (Jasper?) READS my JSP file. Is it possible that it is 
messed up reading my UTF-8 encoded JSP file, even though it then writes 
the .java file with UTF-8 also?


I am running Windows 7, Tomcat 7.0.19, latest Java 6, and running this 
in Eclipse Helios Service Release 2.


Any other thoughts I can try?

Thanks,
David


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

Re: Tomcat 7.0.19 character encoding issue with JSP

[David Wall]

You are right about the encoding of the .java file in Eclipse.  I tried 
in 'vi' and sure enough the codes are in there correctly.  Interesting 
that Eclipse opened the .jsp file and showed it nicely, but the .java 
file was not.  I couldn't do the properties, though, since these files 
are not part of my project, but I was able to drag them into Eclipse.


Anyway, I was still having the problem, but noted that my URL actually 
runs a servlet that does a RequestDispatcher.include() of my generated 
JSP page, so even though the JSP says everything was UTF-8 in the @page 
directive, apparently the response was already set to the default 
charset in the servlet itself.  So I added 
response.setCharacterEncoding(UTF-8); to the top of my servlet's 
doGet/doPost and that seems to have resolved it.


Thanks for all the tips and ideas!

David



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

Tomcat 7.0.19 character encoding issue with JSP

[David Wall]

I'm trying to track down a character encoding issue that I've been 
having, but don't really understand. Hopefully one of you will know what 
the answer is.


I am using CKEditor to generate some user-specified HTML. CKEditor 
offers an insert special character function that often creates named 
HTML entities like yen; but they also have a few like the solid black 
right arrow that is a UTF8 character rather than an entity spec. I then 
generate a JSP file that includes that HTML produced by CKEditor.


Initially, because I was using the Java 6 FileWriter without specifying 
a character encoding and I'd end up with a generated JSP where the HTML 
entities were fine, but the other special characters appeared as just 
'?' in the file. I changed to use FileOutputStream/OutputStreamWriter 
and specified UTF-8 and the JSP looked good:


%@ page contentType=text/html; charset=utf-8 session=true 
isELIgnored=true %

...
pThese have issues: ► Ŵ but these don#39;t: trade; hArr; diams; 
aacute; para; yen;/p


With the UTF8 encoding on writing the JSP, the right arrow and latin-W 
appeared in the JSP file instead of two question marks. I thought maybe 
I had won, but when I look at the .java class file that is generated by 
Tomcat, I see this instead:


out.write(pThese have issues: â–º Å´ but these don#39;t: trade; 
hArr; diams; aacute; para; yen;/p\n);


And when I view that in a web browser, I'm back to question marks again. 
View source in the browser shows:


pThese have issues: ? ? but these don#39;t:trade;  hArr;  diams;  aacute;  para;  
yen;/p

So I figured it was the default character encoding of the JVM causing me 
some grief. I checked and the default on my Windows PC is Cp1252. But 
when I change this with the JVM argument -Dfile.encoding=UTF8, I am no 
better off. The JSP looks okay, but the .java generated looks like 
above. I did note that I could revert back to writing the JSP using 
FileWriter and it produced the correct JSP file, but the 
Tomcat-generated .java file still was wrong.


What might I need to do to ensure that the .java file created from my 
JSP can both read my JSP correctly encoded and write the .java file 
correctly encoded so that these special character appear nice. It's not 
really Tomcat that is the issue since CKEditor is running in Vaadin 
which is running in Tomcat and it looks fine there, but as soon as I run 
the generated JSP, the characters get lost and I end up with question 
marks instead.


Thanks for any ideas,
David

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

Re: TC 7.0.16 IllegalStateException thrown by pageContext.include

[David Wall]

On 6/24/2011 5:48 AM, Rainer Jung wrote:

On 24.06.2011 14:08, Tim Funk wrote:Looks like this is the root cause from 
DefaultServlet ...

While the ISE is caught ... since the mimetype for js was changed - it
doesn't match the fallback method 

 try {
 ostream = response.getOutputStream();
 } catch (IllegalStateException e) {
 // If it fails, we try to get a Writer instead if we're
 // trying to serve a text file
 if ( (contentType == null)
 || (contentType.startsWith(text))
 || (contentType.endsWith(xml)) ) {
 writer = response.getWriter();
 // Cannot reliably serve partial content with a Writer
 ranges = FULL;
 } else {
 throw e;
 }
 }

So one patch is this (which will catch all javascript variants if multiple
exist)
 if ( (contentType == null)
 || (contentType.startsWith(text))
 || (contentType.endsWith(xml))
+|| (contentType.contains(/javascript)) ) {

Patch applied and credited to you in r1139280.

Thanks!

Rainer


Thanks you all for fixing this.  I think that makes good sense that TC 
7's DefaultServlet recognize javascript as a text type like 'text' and 
'xml'.


David


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

TC 7.0.16 IllegalStateException thrown by pageContext.include

[David Wall]

This was working under TC 6, but I have a tag that extends 
BodyTagSupport, and in my doStartTag() method I get my JspWRiter 'out' 
using pageContext.getOut().


I have a bunch of out.write() statements that all work fine.

Then I have these:

out.write(style type=\text/css\\n/* platform esf.css */\n);
pageContext.include(/static/esf/esf.css,true);
pageContext.include(docPage.context.getDocumentStyleIncludeUrl(),true);
out.write(/style\n);

out.write(script type=\text/javascript\\n);
pageContext.include(/static/esf/esf.js,true);
out.write(/script\n);

But the exception IllegalStateException is thrown on the include of the 
esf.js file.  The reason is null, so there's no more details.  I find it 
odd in that the two prior includes works okay, but that third one 
fails.  The file is definitely there (and has been working under TC 6.0 
before).


If I comment out that include, my tag works fine.  What might be causing 
this?


Thanks,
David


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

Re: TC 7.0.16 IllegalStateException thrown by pageContext.include

[David Wall]

out.write(script type=\text/javascript\\n);
pageContext.include(/static/esf/esf.js,true);
out.write(/script\n);

But the exception IllegalStateException is thrown on the include of 
the esf.js file.  The reason is null, so there's no more details.  I 
find it odd in that the two prior includes works okay, but that third 
one fails.  The file is definitely there (and has been working under 
TC 6.0 before).


When I change the code to use /static/esf/esf.javascript and rename the 
file to have the same suffix, the exception is not thrown.


Is there anything special about the .js suffix on a file for 
pageContext.include()?




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

Re: TC 7.0.16 IllegalStateException thrown by pageContext.include

[David Wall]

out.write(script type=\text/javascript\\n);
pageContext.include(/static/esf/esf.js,true);
out.write(/script\n);

But the exception IllegalStateException is thrown on the include of 
the esf.js file.  The reason is null, so there's no more details.  I 
find it odd in that the two prior includes works okay, but that third 
one fails.  The file is definitely there (and has been working under 
TC 6.0 before).


When I change the code to use /static/esf/esf.javascript and rename 
the file to have the same suffix, the exception is not thrown.


Is there anything special about the .js suffix on a file for 
pageContext.include()?


Okay, I learned that this is because web.xml for TC 6 uses:

mime-mapping
extensionjs/extension
mime-typetext/javascript/mime-type
/mime-mapping

But TC 7 uses:

mime-mapping
extensionjs/extension
mime-typeapplication/javascript/mime-type
/mime-mapping

If I put the old TC 6 version in my app's web.xml, then it works again.

Question: Is this to be expected?  Is TC 7 doing the right thing 
here?  Am I breaking something when I update my app's web.xml to say 
it's 'text' again?


Seems like javascript is really text, and so treating as something else 
is not correct, even if the mime type is correctly supposed to be 
application/javascript.  Maybe TC needs to know this particular mime 
type is text and not binary data?


David


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

Re: Can JSP code be served from a DB instead of files?

[David Wall]

Yes. You'll need to extend BaseDirContext in
org.apache.naming.resources. For some examples, see FileDirContext and
WarDirContext in the same package.

Thanks for the pointers, Mark.  From what you are saying, this would be
a Tomcat-specific solution.  I was hoping for something that would work
in standard way so it would be portable.

I'm not sure there is going to be a pure-Java, container-agnostic
solution. There is certainly nothing in the servlet spec that will help
you with this, so your solution is likely to be either
container-specific, or not a container-related solution (like using a
db-based filesystem mounted at the OS level).


Thanks, Chris.  Yeah, I figured this could be a tough one as there 
cannot be too many folks who want to store their JSPs in a database.  
It's a first for me and it seems like forever I've been doing 
JSP/servlets... ;-)



While we use Tomcat ourselves,
we've had users who run on other containers.  I'll take a look though
since maybe it's something that can be plugged into other containers, too.

Good luck. In either case, a DataSourceDirContext would be a nice
addition to Tomcat. ;)


Indeed!  You guys have done a wonderful job with Tomcat, that's for 
sure.  I think we'll muddle along with writing the JSPs to the 
filesystem for now and see what sort of issues pop up in the future.  
The higher priority for us now is to make those generated JSPs do 
something useful!


Thanks for your answers and consideration...

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

Re: Can JSP code be served from a DB instead of files?

[David Wall]

On 12/26/2010 2:04 AM, Mark Thomas wrote:
Yes. You'll need to extend BaseDirContext in 
org.apache.naming.resources. For some examples, see FileDirContext and 
WarDirContext in the same package.





Thanks for the pointers, Mark.  From what you are saying, this would be 
a Tomcat-specific solution.  I was hoping for something that would work 
in standard way so it would be portable.  While we use Tomcat ourselves, 
we've had users who run on other containers.  I'll take a look though 
since maybe it's something that can be plugged into other containers, too.


David



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

Can JSP code be served from a DB instead of files?

[David Wall]

Is there a way to have Jasper (or other...) retrieve the JSP source code 
it'll compile from a database instead of a regular file?  It's fine that 
Jasper write the .java/.class files as normal, but the .jsp would come 
from my database instead.   A servlet that could return the JSP source 
code so it was then processed/compiled normally would be perfect if it's 
possible.  I'd like to have some auto-generated JSP code used in our 
system without writing it to disk in a directory in my webapp's real path.


Is this possible?  Thanks for any ideas...

David

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

Re: Tomcat writing the wrong timestamp on compiled JSP's

[David Wall]

Another issue to consider is that Tomcat runs a single instance of Java 
VM, but often runs multiple webapps.  If each webapp takes the approach 
that it can set the default timezone to its liking, you'll find that 
you get a mixed bag based on which webapp was the last to reload.  At 
least that's what we think we experienced since there are some oddities 
with dates and timezones in Java!


David

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

Re: TC 6.0.20 - how to know session restored on restart?

[David Wall]

Caldarale, Charles R wrote:

From: David Wall [mailto:d.w...@computer.org]
Subject: Re: TC 6.0.20 - how to know session restored on restart?

This must be a multi-thread timing issue because I had 
not had this happen on several other restarts.



AFAIK, Tomcat initialization is single-thread.
  


Odd.  I noted that if I use the tomcat manager and reload the webapp, it 
works as I'd normally expect:


2009-08-10 12:10:15,375 DEBUG 
(com.esignforms.open.servlet.ContextListener) ContextListener() instantiated
2009-08-10 12:10:15,375 DEBUG 
(com.esignforms.open.servlet.SessionListener) SessionListener() instantiated
2009-08-10 12:10:15,391 DEBUG 
(com.esignforms.open.servlet.ContextListener) ContextListener() 
contextInitialized: /test
2009-08-10 12:10:15,407 DEBUG 
(com.esignforms.open.admin.SessionTrackerInfo) 
SessionTracker.SessionInfo() - Session did activate: 
E977295FD564F79471427627CB422D23


But if I stop tomcat and restart it, I get the other:

2009-08-10 12:12:55,922 DEBUG 
(com.esignforms.open.admin.SessionTrackerInfo) 
SessionTracker.SessionInfo() - Session did activate: 
E977295FD564F79471427627CB422D23
2009-08-10 12:12:55,922 DEBUG 
(com.esignforms.open.servlet.ContextListener) ContextListener() instantiated
2009-08-10 12:12:55,922 DEBUG 
(com.esignforms.open.servlet.SessionListener) SessionListener() instantiated
2009-08-10 12:12:56,453 DEBUG 
(com.esignforms.open.servlet.ContextListener) ContextListener() 
contextInitialized: /test



  
Does this behavior make sense that Tomcat resumes passivated 
sessions before it even sets up the context?



Do you have the SingleSignOn valve enabled, by any chance?
  


No, it's a rather default install on Windows XP with Java 6.  The only 
change I have made to Tomcat's server.xml was to turn compression on and 
use the NIO connector.


David

Re: TC 6.0.20 - how to know session restored on restart?

[David Wall]

work well enough for me.  We already stored some info in the session 
so that we could also determine the user who is associated with the 
session among others, so we just created an object to hold this info 
and it implements HttpSessionActivationListener and sure enough, on 
tomcat restart, it gets called so I can rebuild the list.


Well, I cheered too soon  Tomcat appears to be able to reactivate 
sessions even before my listeners are installed and my context has been 
initialized, meaning, I get these session object activations too early 
for my app to handle them.  Here's my log showing the did activate 
method being called before my context and session listeners were even 
instantiated by Tomcat:


On shutdown, we see the session being passivated:

2009-08-09 14:10:32,328 DEBUG 
(com.esignforms.open.admin.SessionTrackerInfo) 
SessionTracker.SessionInfo() - Session will passivate: 
9260160A7F18354F635AC5519F19FC5A
2009-08-09 14:10:32,344 DEBUG 
(com.esignforms.open.servlet.ContextListener) ContextListener() 
contextDestroyed: /test


On restart, we see the session be activated before the context is 
instantiated or initialized:


2009-08-09 14:10:41,188 DEBUG 
(com.esignforms.open.admin.SessionTrackerInfo) 
SessionTracker.SessionInfo() - Session did activate: 
9260160A7F18354F635AC5519F19FC5A
2009-08-09 14:10:41,594 DEBUG 
(com.esignforms.open.servlet.ContextListener) ContextListener() instantiated
2009-08-09 14:10:41,594 DEBUG 
(com.esignforms.open.servlet.SessionListener) SessionListener() instantiated
2009-08-09 14:10:41,610 INFO  (OpenESignForms) 
Application.loadOpenesignformsProperties() successfully loaded 
properties from: openesignforms
2009-08-09 14:10:41,766 DEBUG 
(com.esignforms.open.servlet.ContextListener) ContextListener() 
contextInitialized: /test


The line shows Tomcat giving me the session did activate, and the second 
line shows my context/session listeners being instantiated by Tomcat, 
and the final line is emitted when my context listener completes 
contextInitialized().  This must be a multi-thread timing issue because 
I had not had this happen on several other restarts.  Does this behavior 
make sense that Tomcat resumes passivated sessions before it even sets 
up the context?   I'm sure I can store them until my context is 
initialized, but the order sounds off to me.


David


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

Re: TC 6.0.20 - how to know session restored on restart?

[David Wall]

I am using Tomcat 6.0.20 and have implemented the SessionListener 
interface.  We can then use this to show a list of active sessions to 
our users, and when they are logged in, we even know which user is 
tied to the session.  This is very handy.


However, on tomcat restart, all existing sessions are serialized as 
tomcat stops and then reactivated when tomcat starts.  But I have no 
way of building my list of active sessions since those that are 
started do not call the sessionCreated() method.


Is there any way to get a list of sessions tomcat resumes on restart?


This capability was available back in servlet 2.1 with 
HttpSessionContext.getIds() and getSession(sessionId), which would allow 
me to build my initial list based on the sessions when the system starts 
up.  These are deprecated now.


It seems if I can see all sessions that are started and stopped using 
SessionListener, there should be no reason why we can't get the sessions 
auto-built from session persistence when Tomcat restarts a web app, 
too.  Any tricks to figure this out?


Thanks,
David


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

Re: TC 6.0.20 - how to know session restored on restart?

[David Wall]

It seems if I can see all sessions that are started and stopped using
SessionListener, there should be no reason why we can't get the sessions
auto-built from session persistence when Tomcat restarts a web app,
too.  Any tricks to figure this out?



Try reading the reply I wrote about 9 hours ago.
  


Boy, I was watching the list, so it must have been spam filtered on me 
or something.  Anyway, you (Mark) mention using 
HttpSessionActivationListener, but what's the trick to make that work so 
on startup I can find all the sessions automatically created by Tomcat 
from the serialized session file?


My first attempt was to implement those two methods in my class that 
already implements HttpSessionListener, but these methods were never 
called.  On closer reading, it appears that this is an interface to be 
implemented by an object that I then store in the session attributes.  
Do I create an object that implements HttpSessionActivationListener, 
store that in all sessions so on restart Tomcat will then notify those 
objects that they have been activated so I can then store the session 
info in my list? 


Thanks,
David

Re: TC 6.0.20 - how to know session restored on restart?

[David Wall]

My first attempt was to implement those two methods in my class that
already implements HttpSessionListener, but these methods were never
called.  On closer reading, it appears that this is an interface to be
implemented by an object that I then store in the session attributes. 
Do I create an object that implements HttpSessionActivationListener,

store that in all sessions so on restart Tomcat will then notify those
objects that they have been activated so I can then store the session
info in my list?



Short of delving into the Tomcat internals, I think that is your only
option.
  
That appears to work well enough for me.  We already stored some info in 
the session so that we could also determine the user who is associated 
with the session among others, so we just created an object to hold this 
info and it implements HttpSessionActivationListener and sure enough, on 
tomcat restart, it gets called so I can rebuild the list.


Thanks much,
David

TC 6.0.20 - how to know session restored on restart?

[David Wall]

I am using Tomcat 6.0.20 and have implemented the SessionListener 
interface.  We can then use this to show a list of active sessions to 
our users, and when they are logged in, we even know which user is tied 
to the session.  This is very handy.


However, on tomcat restart, all existing sessions are serialized as 
tomcat stops and then reactivated when tomcat starts.  But I have no way 
of building my list of active sessions since those that are started do 
not call the sessionCreated() method.


Is there any way to get a list of sessions tomcat resumes on restart?

Thanks,
David

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

Force recompile of JSP in Tomcat 6

[David Wall]

In a production environment in which JSPs do not change frequently, I'd 
like to reduce the overhead of checking for JSP recompiles, assuming 
that such checks are in fact costly, and instruct Tomcat to recompile a 
given JSP should it change.  In our environment, the JSP is written out 
by our web app.


I noted the page.jsp?jsp_precompile=true type of option, but this seems 
to have no effect if Tomcat's web.xml sets the JspServlet param 
development=false.


Thanks,
David

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

Programmatically reload webapp in Tomcat 6

[David Wall]

Manually, the Tomcat Manager web app allows me to easily restart a web 
app.  So, assuming I have the tomcat manager username and password, I 
can make a program invoke the same URL that probably would cause the web 
app to reload, using something like:


https://myhost.com/manager/html/reload?path=/THISONE

Is there a programmatic way to do this directly instead to make it 
easier to detect any errors or the like?  I basically would like a web 
app to be able to reload itself, without stopping Tomcat itself, such as 
after an automated download that installed some new versions of JARs and 
JSPs for the web app (allowing the web app to download upgrades, install 
them, then restart the web app so it's put into use).


Thanks,
David

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

Java/Tomcat 5 CPU utilization very high under low load

[David Wall]

We are running Tomcat 5.5.27 on Linux 2.6.18-53.1.4.el5xen (Red Hat 
4.1.2-14) with Java 1.6.0_05 (32 bit) in a Xen virtualization 
environment (not my server, so unsure what version that is).  It has 3 
webapps running, two of ours and Tomcat's manager.


Normally, when we run 'top', Java and it's related PG 8.3.3 database 
that drives the Tomcat webapps show very low CPU utilization (0-1%) and 
even leave the 'top' listing.  When there is higher user activity, we 
see Java increase to 4-20% utilization, but these are spikes that also 
tend to return to the low utilization shortly after the burst.  We run 
Java with options: -server -Xms2200m -Xmx2200m -XX:MaxPermSize=128m.


But every so often, Java goes crazy and reaches 95-99% CPU 
utilization, and it sticks there, even though there is little Tomcat 
activity.  What is unusual to me is that during this initial phase of 
high CPU utilization, the webapps themselves appear to run smoothly 
(don't really notice a slowdown like you'd expect from such high 
utilization), logging in, using the web interface, doing queries, 
updates, etc.  Also, the tomcat access log show little actual user 
activity while it's running so busy.


Unfortunately, after some time, it seems that Tomcat eventually locks up 
and we have to restart the system, where the process repeats itself: 
initially normal low utilization, followed by 99% utilization with the 
system still working okay, followed by a lock-up and restart.


So it seems like there's a Java thread that is running amok, yet not a 
critical thread (at least not initially) since the apps appear to be 
working fine.


How best can I find the troubled thread on a running production system? 


Thanks,
David

P.S.  Note that our webapps run on lots of servers in a similar 
configuration (albeit without Xen) and we've never seen this before 
after years of running production systems -- it's just this one system.


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

Re: Java/Tomcat 5 CPU utilization very high under low load

[David Wall]

F.ex. from my toy machine;
$ ps -fLp 7044
UIDPID  PPID   LWP  C NLWP STIME TTY  TIME CMD
tomcat7044 1  7044  0   40  2008 ?00:00:12 /usr/lib/jvm/java/bin
tomcat7044 1  7118  0   40  2008 ?00:02:58 /usr/lib/jvm/java/bin
tomcat7044 1  7119  0   40  2008 ?00:00:00 /usr/lib/jvm/java/bin
...
tomcat7044 1  7892  0   40  2008 ?00:36:26 /usr/lib/jvm/java/bin
... (there are a number of other threads)

Then, at least on my JVM, the thread ids are shown in hexadecimal, so
it's best to convert the interesting thread ids to hex; from the above,
7044=0x1b84
7118=0x1bce
7119=0x1bcf
7892=0x1ed4

... and the thread info from the dump matchind to the above:
main prio=1 tid=0x0805cfb8 nid=0x1b84 runnable [0xbfffc000..0xbfffd708]
VM Thread prio=1 tid=0x08099f38 nid=0x1bce runnable
Reference Handler daemon prio=1 tid=0x0809cae0 nid=0x1bcf in Object.wait() 
[0xb2519000..0xb2519f20]
ContainerBackgroundProcessor[StandardEngine[Catalina]] daemon prio=1 
tid=0x083444e0 nid=0x1ed4 waiting on condition [0xb135c000..0xb135cfa0]

In the dump there is also the call stack for each of the threads,
so if it's an application thread that's using CPU, you'll get at least
some glimpse where in the code the time is spent.
  


Thanks for the detailed explanation, Juha.  When I get some info, I'll 
post back what I find.  I've added your 'ps' commands to our checking, 
along with the jmap and thread dumps suggested as well.   Hopefully 
we'll be able to find it.


I was interested to see that it could also be SOAP threads that get in 
trouble, since another aspect of this particular deployment is that it 
uses the Salesforce SOAP APIs to update data back in Salesforce, so 
perhaps it will be something there. 


David


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

Re: Supporting Large Number of Web Application Instances

[David Wall]

John Shilling wrote:

I am looking at having to support tens or even hundres of instances of our
web application in an ASP Model.  
We basically do this now using a single Tomcat instance with multiple 
webapps (https://host.com/App1/, https//host.com/App2/ etc) and 
don't use virtual servers because we use SSL, and to make that work, 
you'd need multiple IP addresses, multiple keystores and multiple SSL 
certs.  In our model, that's not a requirement.


We're only doing about 50 webapps per Tomcat now, so whether it could do 
hundreds, is hard to say.  Also, obviously, it depends on the 
networking, memory, processor and disk capabilities to support all of 
those.  I mean, if one webapp is doing millions of transactions per day, 
you may find few servers that could handle lots of those together, and 
if one is transferring lots of data in and out, it could hog up 
bandwidth, etc.  And of course one webapps usage will impact the 
performance of others, so you'll probably need to balance webapps as you 
scale up.


Each of our webapps can run different versions of our base software, but 
as mentioned before, they all must run on the same version of Tomcat and 
Java -- and in and our case, the same version of the backend PostgreSQL 
database which hosts a database per webapp. 


It's worked well for us so far.

David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Download Tracking

[David Wall]

I have a java application under Tomcat that is supposed to track people'
downloads.

 


The user clicks on a link (to download a file) and a new record has to be
inserted into a postgreSQL table informing which file was downloaded.

 


However, I need to insert into postgreSQL only after the user hits the save
button of the second window that windows shows. The one that the user
selects the physical place to store the file.

 


I don't know how can I get which button the user clicked since the download
manager window is provided by Windows and not one of mine.
  
I don't think it's possible to know if they click Open/Save/Cancel, at 
least not if using a standard web browser function and not a plug-in of 
some sort.


David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Download Tracking

[David Wall]

It may not be worth the resources, but you can develop/use a download
manager could do this for you. Especially if these are large files, the
users may be happy to use something like that.

The manager would basically tell the service to start the download and
if you do something like resume functionality, it would probably need to
enter other records to show the progress.
  
Is there any open source download manager like that for IE and Firefox 
(and what about Safari, Opera,)?  Getting people to install plug-ins 
is often hard to accomplish, and is banned by nearly every company's IT.


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cookie.setSecure -- cookie not persisted in IE 6/7

[David Wall]

We set a secure cookie over HTTPS using:

javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie(name, 
value);

cookie.setVersion(1);
cookie.setMaxAge(60*60*24*90); // 90 days in seconds
cookie.setSecure(request.isSecure());
response.addCookie(cookie);

This works in Firefox and Chrome.  But in IE 6 and 7 (and I think 
Safari) it appears to work okay as long as the browser is not closed, 
when it appears to be forgotten.  Do those browsers not persist secure 
cookies, or is there something else we're doing wrong?


In Firefox, the cookie info appears correct and reports values like we 
expect:

Name: e
Value: [EMAIL PROTECTED]
Host: myhostname.com
Path: /MyWebapp/
Expires: Wed, 21 Jan 2009 21:55:13 GMT
Session cookie: No
Secure cookie: Yes

Any ideas why IE is not persisting?  Is this a security function not to 
write a secure cookie to disk?


Thanks,
David



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookie.setSecure -- cookie not persisted in IE 6/7

[David Wall]

cookie.setVersion(1);


I think I found my own answer in that it appears that Firefox can accept 
a version 1 (RFC 2109) cookie, which we were using because the email 
address contains an '@' that's not allowed as a value in version 0 
cookies.  When we converted to version 0 and encoded the @, it worked on IE.


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

TC 5.5.27 upgrade JSP tag attribute quoting

[David Wall]

While it makes sense, I was just checking to see if upgrading from 
Tomcat 5.5.26 to 5.5.27, not thinking such an upgrade would require JSP 
source code changes, will hold true going forward with subsequent Tomcat 
releases.


We have a few places where JSP tag attribute values have Java code that 
itself contains double quotes, such as:


tt:mytag value=%=(field+i)%/
or
tt:mytag value=%=bean.get(name)%/

In 5.5.26, this compiled okay, but in 5.5.27, it results in an error like:

org.apache.jasper.JasperException: /app/mypage.jsp(43,21) Attribute value 
(field+i) is quoted with  which must be escaped when used within the value

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)


It does make some sense, yet it worked fine for years.  Is this 
something that will be true going forward with Tomcat releases, or is 
this some sort of bug that was introduced in 5.5.27?  It is only 
interesting because even the error message shows it parses the attribute 
value correctly.


Thanks,
David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Non-secure HTTP connector with secure=true requires a keystore?

[David Wall]

No, I don't want SSL enabled. I want Tomcat to NOT do SSL, but I want it
to report to my application that SSL is being used.
  
So you want quality software to lie to you?  It would be a bug if Tomcat 
said it was secure when it's not, and it sounds pretty goofy to want it.



The deal is that I want to be able to have a localhost-only Connector
that appears to be secure, but isn't actually using SSL so I can avoid
the SSL performance hit.
  
So use HTTP.  Appearing secure buys you nothing other than fooling 
yourself.  You are not telling us something because such a spec makes no 
sense.  Your app can assume anything it wants (boolean isSecure = true; 
int one = 2;).


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Non-secure HTTP connector with secure=true requires a keystore?

[David Wall]

I'm trying to configure an HTTP Connector that reports to the
application that the connection is secure. According to the TC
documentation
(http://tomcat.apache.org/tomcat-5.5-doc/config/http.html), you should
be able to simply set:

secure=true

in the Connector and all should be well.
  
Yes, this is used when you'll be using SSL/TLS with https type URLs.  To 
do SSL, you'll need a keystore to with a key created that represents the 
web server's domain name (i.e. cn=www.webserver.org).



I would have expected an HTTP connector to be created, but it appears
that an HTTPS connector is being created instead.
  
If you only want http, then secure will always be false.  Of course, I'm 
not sure which of the scheme and secure attributes tells it to use SSL 
HTTP/1.1 connector.  If you don't want a keystore and want HTTP instead 
of HTTPS, just leave the secure attribute off.


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question about TLS Ciphers in tomcat

[David Wall]

We've used the following in Tomcat 5.5 with JDK 1.6:

   Connector port=8443 maxHttpHeaderSize=8192 maxPostSize=0
  maxThreads=2000 minSpareThreads=25 maxSpareThreads=75
  enableLookups=false disableUploadTimeout=true
  acceptCount=100 scheme=https secure=true
   keystoreFile=XX keystorePass=
ciphers=TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,SSL_DHE_DSS_WITH_3D
ES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SH
A,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5,TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  clientAuth=false sslProtocol=TLS /

David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Parsing a URL to see if a param exists

[David Wall]

Thanks for the code idea.  I like what you wrote.


If there's no '?' in the URL, then you can return false right away, 
right?

Indeed!


public boolean isParamInUrl(String url, String paramName)
{
~   return url.contains('?' + paramName + '=')
~   || url.contains('' + paramName + '=');
}

This looks simpler, easier to read, and less error-prone. I would
venture a guess that it runs faster than your implementation, too. 
Yes, I think I like it.  I think I have to save a 
URLEncoder.encode(paramName) first and then use that in the to 
url.contains calls just to be safe.  Your code is much easier to 
understand and no doubt runs faster.


Thanks,
David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Parsing a URL to see if a param exists

[David Wall]

Is there an API call to parse an URL I have as a String so that I can 
determine if a given param exists? 

I know that when processing from Tomcat, I can do 
request.getParameterValues() for the URL of my servlet, but I'd like to 
know if the URL used to arrive at my page includes a given parameter on 
the URL itself (and not from a POST hidden param that will also be 
returned by getParameterValues).


Thanks,
David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Parsing a URL to see if a param exists

[David Wall]

http://java.sun.com/docs/books/tutorial/networking/urls/urlInfo.html

It breaks down every component of the url (protocol, domain name, etc).  Is 
that what you're looking for?
  


Not really since I just need to process the query string portion to see 
if a given param exists or not.  I'm using a simple homegrown parser now:


   public boolean isParamInUrl(String url, String paramName)
   {
   int pos = url.indexOf(?);
   if ( pos  0 )
   url = url.substring(pos);
   String[] paramValues = url.split();
   if ( paramValues == null )
   return false;
  
   for( String paramValue : paramValues )

   {
   String[] paramAndValue = paramValue.split(=);
   if ( paramAndValue == null || paramAndValue.length != 2 )
   return false;
   if ( paramAndValue[0].equals(paramName) )
   return true;
   }
   return false;
   }

The concern is whether this is valid should the URL have complex params 
and such based on encoding schemes.  I mean, it just splits the url 
query string into an array of param-values '', and then splits that by 
'=' without concern for any encoding.


David



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Parsing a URL to see if a param exists

[David Wall]

if ( pos  0 )
url = url.substring(pos);


Found a bug in that this should be pos+1 to remove the ?.


if ( paramAndValue[0].equals(paramName) )
return true;

We're also doing a URLDecoder.decode on the paramAndValue[0] in case the 
param name was encoded (though in practice it's rarely done).




Wouldn't be faster/less coding if you just use this?

URL aURL = new URL(url);
String urlParams = aURL.getQuery();
if (urlParams.contains(paramName)) {
// proccess as needed if paramName exists
} else {
// process as otherwise
}
  
That would find the paramName even if was a substring of a param name or 
the param value.  That is, if I'm checking if param name exists, and 
the URL query string was firstname=bob or sort=nameOrder that code 
would say name exists but no such name param is there.


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Adding transactional classloader for dynamic code in webapp?

[David Wall]

I'd like to allow a web app to define custom code, such as for custom 
data validators or data formatters to be added by a user through 
configuration in my web app. 

That is, I'd like to have a user of my web app specify some Java code 
snippets (either a few lines of code, or perhaps a complete method) that 
my base code would call back to do customized data validations if they 
have been configured in my web app.  An example would be a form that 
needs to validate a phone number, but some want a strict NPA-NXX- 
style format, others allow phone extensions, others may allow an 
optional country code prefix, etc.  So I'd like my based code to be able 
to do something like call a method the user has defined that follows a 
naming convention, such as


boolean validatePhone(String phone)

and it would then do the code check set by the user who perhaps only 
filled in the code snippet into a textarea in my JSP and I've saved to 
the database.


My guess is I'd need to develop some sort of transactional class loader, 
one that would be created after dynamically generating the Java code, or 
compiling the Java code entered and storing the resulting .class file, 
etc.  But since they could change the code through my web app, I would 
need to be able to auto-recompile (sort like a JSP does in Tomcat) and 
by recreating a new classloader on the fly, it would obsolete the old 
code during garbage collection and would use the new code going forward.


Is there any place that I can read about some proven approaches to this 
sort of dynamic Java class creation, compilation, class loader?  Tips? 


Thanks,
David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 64 bits

[David Wall]

Is there any problem run Tomcat under 64 bits platform? And about JDK? Is it
possible install JDK 32 bits for 64 bits platform?
  
We run Tomcat 5.5 using CentOS 5 X86_64 and Java 6 (x64 -- previously 
amd64 also worked) without any issues.


David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CATALINA_HOME

[David Wall]

My Tomcat directory is c:\Tomcat6\apache-tomcat-6.0.14.  I tried starting 
startup.bat but got the error:
The CATALINA_HOME environment variable is not defined correctly This 
environment variable is needed to run this program
My CATALINA_HOME environment variable is set to 
c:\Tomcat6\apache-tomcat-6.0.14\conf
  
Drop the \conf directory as catalina home should point to the tomcat 
base for most deployments and not the conf folder.


Also, if you are using the Windows Tomcat Monitor process, this value 
should be set in the Java tab where you configure things, with an entry 
like -Dcatalina.home=c:\Tomcat6\apache-tomcat-6.0.14


Note that I'm only running 5.5, so pardon my answer if it doesn't apply 
to 6.


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.5 OutOfMemoryError (PermGen space)

[David Wall]

After some times, my Tomcat will stop responding and the stdout log
says OutOfMemoryError!
  
You could try increasing the perm space with the Java option: 
-XX:MaxPermSize=256m


Obviously, you can choose any value you want.  We've seen the same 
problem on systems that have lots of webapps that are reloaded or newly 
deployed.  From time to time, we have to restart Tomcat 5.5 to get 
everything clean as we run lots of webapps (50-100) in a single Tomcat 
instance.


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Key store password via console

[David Wall]

Moritz wrote:
But still I think it's never a good idea to write a password in plain 
text in any file. If the password is stored in plain text and 
something goes wrong an attacker could be able to steal my private key 
and use it. And this would be really bad.
Obviously, this depends on your web site's hacker desirability), but if 
they can read your server.xml, they can likely hijack your entire web 
app and install their exploit into your existing pages since the SSL 
encryption is in the clear for the webapp itself and thus they can see 
whatever data was entered by users.  So, if you cannot secure your 
server.xml, then your entire web app is vulnerable to attacks EVEN IF 
they couldn't get the password to your private key. 

Stealing your SSL cert private key is probably worth less and harder to 
exploit than simply changing your login page or the like to capture user 
credentials (of course, such changes can be discovered using tools like 
snort).  A stolen set of SSL cert keys is harder to exploit and hide.




Therefore I'm looking for a possibility to pass the password via the 
console.
This has been discussed many times before.  I'm sure if you write code 
that allows this to work, some will want to use it, too.  It's open 
source after all...  And you can always put httpd in front since it's 
openssl implementation allows for cert password prompts.


David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: subdomain name redirect to different context path

[David Wall]

Assuming you'll want to do other redirects in the future to different 
webapps (not all sharing ROOT's / for example and just using subdirs, 
but actual distinct webapps), you might take a look at URL rewrite at 
http://tuckey.org/urlrewrite/


David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Session IDs XMLHttpRequests

[David Wall]

Frank W. Zammetti wrote:

I can say with 100% certainty that a servlet invoked with XMLHttpRequest
**DOES** have the same access to server-side objects as a non-AJAX
request.  I say this based on two applications in production that do this
all day long, one Struts-based, one not.  I also say it based on a number
of other applications, some using other frameworks, some using plain
servlets, all that do this as well, with no problems.
  
When using the Dojo toolkit with Tomcat 5.5, I noted that the session id 
was being sent transparently.  This was critical for us because users 
login and so it's important that each request be associated with their 
respective sessions, and it worked like that out of the box.  Again, 
just one experience that this can work under Tomcat just fine.


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Encrypting passwords in the connection pool setup

[David Wall]

Martin,

All encryption systems need a way to boot themselves.  This either means 
you store the password somewhere so the program can self-boot itself, or 
you need user intervention, such as typing in the password (or inserting 
a dongle or other security hardware device).


Once the system has booted itself, then it can store things safely using 
encryption.  A hash value is simply a transformation of one string into 
another, so if the program that retrieves the password retrieves the 
real password or its hash, there is no added security, the hash has 
simply become the password (after all, you cannot go from the hash to 
the password value, at least not easily with a good hash, as that's it's 
main reason for being).


Hashed passwords are very useful if you have others who will be entering 
the password in, since you can then store only hashes, and when you need 
to verify the password entered, you create a hash of the entered 
password and then compare it to the stored hashed value.


This isn't the case for applications that need to bootstrap themselves.  
You really either need to require manual intervention to start it (and 
enter the password), or it will be stored in the clear somewhere.


David


Martin Dubuc wrote:

Chris,

I am not sure I buy your argument that because there is somewhere else
in an implementation that is as insecure as cleartext password, then
there is no point in fixing the cleartext password issue. With this
argument, we would never care about fixing any security holes, because
one can always find a new security hole to exploit. Plus, well, the
assumption that someone is using a password-less key with Apache
running with SSL is pretty weak, because there are ways to avoid using
password-less key.

As far as the UNIX password analogy, tomcat may be seen as a user, not
UNIX, but it still performs authentication. So in my mind, it is
filling in for both roles (UNIX and user). I have the impression that
using MD5/SHA hashing would be a good option, because it would be
simple, would not require any additional key, would provide some sense
of security. Not the silverlining, but better than cleartext, for
sure.

Martin




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT]Re: Large number of active sessions

[David Wall]

I hope all this 'bot' talk doesn't prevent a resolution to the bug 
long-standing bug regarding sessions that never terminate, long after 
they should have expired.  All of our web apps have a background thread 
that periodically terminates sessions that haven't been accessed in 24 
hours, even though most of our web apps should auto-expire after 30 
minutes, with the longest one being 120 minutes because users need to 
fill out a lengthy form.


David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Large number of active sessions

[David Wall]

It seems that Tomcat 5.5.17 (and earlier) has had some sort of problem 
in timing out sessions.  I'm not sure if it would clean itself up if the 
person really came back and did another HTTP transaction or not, but 
I've noted that Tomcat Manager will show sessions that are have been 
idle much longer than the session timeout value (based on the last 
access timestamp in the session).


Our application also has a registered listener HttpSessionListener and 
we've seen that these old sessions do not trigger that callback either 
as we also list the session as active.


As for suggestion (1), this won't matter and 30 minutes is the default.

As for suggestion (4), this could clearly create extra sessions for 
those few who don't allow session cookies, but even those sessions 
should time out.


David



Pid wrote:

1) Lower your session timeout.
2) How are you measuring/calculating statistics?
3) Which version of Tomcat?
4) Are you url encoding all of your links?


Christer Nordvik wrote:

Hi!

I've got a website with pretty low traffic (200 visitors a day). 
Lately it's
been very slow and when I look in Tomcat's manager it says that it 
has a lot

of sessions.
Once I had 13000(!) active sessions. The session timeout is set to 30
minutes.

How can this happen? Isn't this something that Tomcat should handle 
itself?
Can it be related to my code somehow? I have only basic JSP/Servlet 
stuff so

nothing fancy going on.

Any help would be very appreciated!

-Christer




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC 5.5.17 w/ JDK 1.5 - SSL ciphers to use list

[David Wall]

Mark Thomas wrote:

David Wall wrote:
  

Does anybody know how to find the list of SSL ciphers that TC will use
(I'm running on Linux)?  There's a Connector param to set the ciphers,
but I don't know where to find the list of available ciphers that I have.



http://marc.theaimsgroup.com/?l=tomcat-userm=115495064905326w=2

Mark
  
This didn't help as much as I had hoped.  Does anybody know where Sun's 
JDK 1.5 (Linux) keeps the list of SSL ciphers it implements?  What 
document would I look at? 

What Java API is called by Tomcat to get the list of SSL ciphers that 
are available?


Thanks,
David

Re: TC 5.5.17 w/ JDK 1.5 - SSL ciphers to use list

[David Wall]

I have tracked down two methods that should give me what I want in the 
abstract class javax.net.ssl.SSLSocket:


String[] getEnabledCipherSuites()
String[] getSupportedCipherSuites()

Is there any way to retrieve the SSLSocket object created by Tomcat that 
is associated with a given HttpRequest?


Thanks,
David


David Wall wrote:
Does anybody know how to find the list of SSL ciphers that TC will use 
(I'm running on Linux)?  There's a Connector param to set the ciphers, 
but I don't know where to find the list of available ciphers that I have.


Thanks,
David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC 5.5.17 w/ JDK 1.5 - SSL ciphers to use list - RESOLVED

[David Wall]

That's exactly what I was looking for.  Thanks. David

Mark Thomas wrote:

$JAVA_HOME/docs/guide/security/jsse/JSSERefGuide.html

You want appendix A.

Mark
  



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

TC 5.5.17 w/ JDK 1.5 - SSL ciphers to use list

[David Wall]

Does anybody know how to find the list of SSL ciphers that TC will use 
(I'm running on Linux)?  There's a Connector param to set the ciphers, 
but I don't know where to find the list of available ciphers that I have.


Thanks,
David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Weak SSL detection w/ TC5.5

[David Wall]

What are most people doing to detect so-called weak SSL ciphers in 
Tomcat? 

I've noted that I can configure the Tomcat Connector's 'ciphers' list to 
specify only those that are not weak, but I'm not sure how best to 
generate that list.  For example, how would I list all ciphers except 
DES-CBC-SHA, EXP-RC4-MD5 and EXP-DES-CBC-SHA from what's offered by 
default?  Is there a way to get an exhaustive list of what ciphers 
Tomcat's SSL will use on Java 5?


Or are people simply checking the javax.servlet.request.key_size 
attribute to determine if it's at least 128 bits and then either 
allowing the connection or redirecting to an error page or the like?  It 
seems like checking the javax.servlet.request.cipher_suite attribute 
won't be enough because it lists all ciphers that it can use, not the 
one that's actually being used.


Thanks,
David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Retrieving ListMyType from a request/session attribute

[David Wall]

Is there a correct way to retrieve a typed List from a request/session 
attribute?  The attribute is returned as an Object, but using a cast like:


ListMyType var = (ListMyType)request.getAttribute(name);

results in a warning:

Type safety: The cast from Object to ListMyType is actually checking 
against the erased type List


The code works fine, but I'd like to get rid of the warning if there's a 
correct way to do this cast.


Thanks,
David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Calling URL in same web app to get resulting HTML?

[David Wall]

Is there a way to call a JSP within my web app so that I can capture the 
HTML that the JSP produces?  I'd like to capture that HTML and store it 
in a file rather than returning it as part of the response. 

I have tried java.net.URL, but it has issues when testing over HTTPS 
(self-signed certs) and was hoping that servlets allowed something like 
request dispatcher include/forward that would make it easier for me to 
invoke a page within my webapp and capture it.


Thanks,
David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to hide the keystorePass at the server.xml

[David Wall]

Leon Rosenberg wrote:

On 6/2/06, Bill Barker [EMAIL PROTECTED] wrote:

TC 3.3.x had an optional module to do this.  It never got ported.

I generally agree with most of the people that say that this is the 
least of

your problems.  If you are usings a self-signed cert, then you are just
getting what you deserve.  Otherwise, you simply contact the CA and 
revoke
the cert:  At least this problem solved :).  Now, how to deal with 
the fact

that the hacker just uploaded 10,000 credit-card numbers, since my jdbc
password was in the clear :).


Actually you are not allowed to save credit card numbers unless you
are a certified payment provider (which implies major security
constraints).
Even a certified payment provider is not allowed to store cvc codes,
and without the codes the credit card numbers are useless. (amazon of
course is an exception to this rule...)
However, if you saving cc-numbers or bank accounts or any other
payment related data in your database unencrypted you belong in jail
:-)
But please feel free to tell us that you are doing one of the above,
so we know which sites to avoid :-)
Somewhat true, but nearly every site that collects payment information 
and charges at a later date stores that information until the card is 
actually processed, and many businesses do not charge the card until the 
product/service has been delivered. 

Furthermore, that simply begs the issue, since it could be SSN, 
salaries, student loan info, job histories, etc. that become vulnerable.  

I don't think there's much argument that allowing the option to manually 
enter the keystore password is a bad thing, just that protecting an SSL 
cert is only a small concern if your filesystem has been compromised.


David

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC 5.5.17 problem with multiple webapps using JCE provider and security manager - RESOLVED

[David Wall]

On reading more in the release notes 
(http://tomcat.apache.org/tomcat-5.5-doc/RELEASE-NOTES.txt), I figured 
I'd give the shared/lib idea a try.  I found that just by moving the 
BouncyCastle JCE jar into shared/lib and out of the WEB-INF/lib of the 
various webapps, all seems to work okay.


Note that when using a security manager, I had to add the following 
additional GRANTs before TC would actually start up, so these should 
probably be added to the default catalina.policy file in the 
distribution (under the default grant {} entry):


// Extra permission found by Yozons that need to be set for whatever reason
permission java.lang.RuntimePermission 
accessClassInPackage.org.apache.catalina;
permission java.lang.RuntimePermission 
accessClassInPackage.org.apache.catalina.*;
permission java.lang.RuntimePermission 
accessClassInPackage.org.apache.jasper.compiler;
permission java.lang.RuntimePermission 
accessClassInPackage.org.apache.tomcat.util.net;


David

David Wall wrote:
Since upgrading from Tomcat from 5.5.9 to 5.5.17, I found that my two 
webapps that both need to use encryption via JCE providers are not 
working.  Only the first to load webapp works as it installs the 
provider just fine, but the other cannot and then fails.
It seems that a single JVM can only load the security providers once.  
When running tomcat with a security manager, it appears that the first 
webapp to initialize loads the provider successfully (says in slot 
7).  The second webapp tries to also load the provider, gets the 
routine error saying it was installed in slot -1, but now fails to be 
able to find the provider.
If I turn off the security manager in TC (no -security startup 
option), it works fine, even though the second to load still gets the 
-1 slot error installing the JCE provider.  This all worked fine 
under 5.5.9 with a security manager.


So, the problem appears to be with the security manager in 5.5.17 is 
not able to find the provider as it once could because it's been 
loaded into the JVM by another webapp.  At the bottom is the exception 
stack trace.


I am running Tomcat 5.5.17 with a security manager (started with 
-security) under RedHat Linux using BouncyCastle JCE 1.33 with JDK 1.5.


Thanks,
David


java.security.NoSuchAlgorithmException: class configured for 
SecretKeyFactory(provider: BC)cannot be found.

   at java.security.Provider$Service.getImplClass(Provider.java:1178)
   at java.security.Provider$Service.newInstance(Provider.java:1129)
   at sun.security.jca.GetInstance.getInstance(GetInstance.java:220)
   at javax.crypto.SunJCE_b.a(DashoA12275)
   at javax.crypto.SecretKeyFactory.getInstance(DashoA12275)
   at com.test.cryptotest.PbeUtil.init(PbeUtil.java:48)
   at com.test.BootService.init(BootService.java:62)
   at com.test.Context.loadSessionKeys(YoContext.java:547)
   at com.test.Context.init(YoContext.java:154)
   at com.test.Application.init(Application.java:825)
   at 
com.test.servlet.ContextListener.contextInitialized(ContextListener.java:38) 

   at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729) 

   at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4187)
   at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) 

   at 
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:121)
   at 
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:143) 


   at java.security.AccessController.doPrivileged(Native Method)
   at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:737)
   at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
   at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:608) 

   at 
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535) 

   at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
   at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
   at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) 

   at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) 

   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
   at 
org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
   at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
   at 
org.apache.catalina.core.StandardService.start(StandardService.java:450)
   at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:709)

   at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke

Re: Webapp reload failing, but restarting tomcat allows webapp to load fine

[David Wall]

On reading more in the release notes 
(http://tomcat.apache.org/tomcat-5.5-doc/RELEASE-NOTES.txt), I figured 
I'd give the shared/lib idea a try.  I found that just by moving the 
BouncyCastle JCE jar into shared/lib and out of the WEB-INF/lib of the 
various webapps, all seems to work okay.


On another note, I tried moving log4j's JAR into shared/lib, but it 
didn't seem to work.  Even though each webapp has its own 
log4j.properties file in the WEB-INF/classes, with each pointing to a 
distinct log, when the log4j jar was put in shared/lib, all of the 
output from all of the webapps went into the same file.  So it seems to 
have some static initializations too that introduce this oddity.


David


David Wall wrote:

Martin,

Thanks for your suggestion, but it's unlikely that web.xml was 
misconfigured just because of this TC upgrade (it wouldn't have needed 
to change).  Also, when I restart tomcat (rather than just reload via 
the manager), the webapp comes up just fine.  It's only on a reload 
that things fail, and they didn't even fail under 5.5.12, but do under 
5.5.17.  It seems very likely this is related to a TC bug when 
contexts are being reloaded with some classpath-related issue 
remaining.  I know that such classpath issues can be tricky when the 
webapp has to be dropped from the running JVM and then later added 
back in.


David



Martin Gainty wrote:
If you check the logs ..more than likely you may be trying to pull a 
class that is not on classpath or maybe an aberrant configuration

abeerant config is servlet-mapping may be munged in web.xml HTH,
Martin --


- Original Message -  
It seems there's something that's gone wrong between TC 5.5.12 and 
TC 5.5.17 as it relates to reloading webapps through the Manager 
app.  I upgraded to get the fix related to webapp reloads for 
listeners, and that seemed to work (on restart with a new web.xml, 
it didn't call the listeners from the previous web.xml anymore).
But I now get an odd error on restart related to decryption via 
JCE.  I've not been able to track down why this is occuring, but it 
seems to be related to some sort of context/classpath issue on the 
reload.  This can be seen in that when I start tomcat, all of my 
webapps load fine.  If I click to reload a webapp via the Manager, 
that webapp will fail.  If I then restart tomcat, that webapp loads 
fine again.


Is this a known issue?  It may be related to other issues I've run 
into with respect to JCE providers on reloads that did not occur in 
5.5.12.


Thanks,
David



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to hide the keystorePass at the server.xml

[David Wall]

Shankar Unni wrote:

Robert Harper wrote:

One thing to think of is that if you have to do that to protect it, then
everything else on that system is suspect. 


Yeah, yeah. I used to use this argument a lot, too. But that's like 
saying: if your harness isn't secure, then why bother with an 
additional safety net below you? You might as well fall and die..


It's not that obfuscating or encrypting the keystorePass is a 
fool-proof answer, but that it adds an additional step of complexity 
in the way of anyone who might crack your system. Stuff happens. Just 
because a burglar got past your front door doesn't mean that you have 
to lay out your valuables in the foyer..


The problem is that if you encrypt the keystore password somewhere (or 
even still embedded in the server.xml file), how do you tell Tomcat how 
to decrypt that?  In the end, you have to enter a password or other 
credential into the system. 

A possible sounding solution would be to have tomcat start in a 
protected mode that requires an admin connect and enter a password 
before TC would allow the webapps to load.  But even this would require 
that TC be configured to do so since most would not want this.  And if 
you can access the filesystem, then you could change that configuration 
so that TC would start and NOT require that.  You can even change the 
java security policy file.  So you'd need to create a forked TC that 
always requires the password to be entered.  But then again, if they can 
access the filesystem, they could just change out the version of TC.


And if they can work on your file system, they can probably insert new 
code into the WEB-INF/lib or WEB-INF/classes or any of the JSPs.


And if they can do all that, you probably have no security to begin with.

In the end, a secure version of Tomcat that always required a password 
or other credential be provided before it starts, with an encrypted JSP 
and configuration file store, etc. would be needed. 


David


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

System down web.xml partially working when restart webapp via tomcat manager

[David Wall]

We have multiple webapps running in a single Tomcat instance, and when 
we need to upgrade a given webapp, we install a system down web.xml 
that defines a null operation listener (we normally have one that 
bootstraps the application, connects to databases, etc.) and maps 
everything to a servlet that displays an error message.


What we found is that if we stop/start or reload the webapp using the 
Tomcat Manager application, the original context listener class is still 
being invoked, which of course we don't want since it initializes the 
application and such.  We do find that the all requests to any URL will 
use the system down servlet, so the system is restarting using the 
system down version of web.xml.


If we restart Tomcat entirely, then it works as expected, giving us the 
system down errors, but not running the real context listener.


Is there a way to allow this to work using the Manager app?  This would 
be preferable as we'd like to be able to do maintenance on a given 
webapp without affecting all of the others.


We're using Tomcat 5.5.12 with JDK 1.5 on Red Hat Linux.

Thanks,
David


P.S.  Here's that web.xml:

?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;

version=2.4

display-nameSystem down/display-name
descriptionSystem down/description

listener
   
listener-classcom.test.servlet.SystemDownContextListener/listener-class

/listener

servlet
   servlet-nameSystemDown/servlet-name
   servlet-classcom.test.servlet.SystemDown/servlet-class
/servlet

servlet-mapping
   servlet-nameSystemDown/servlet-name
   url-pattern/*/url-pattern
/servlet-mapping

session-config
 session-timeout1/session-timeout
/session-config
/web-app


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: System down web.xml partially working when restart webapp via tomcat manager

[David Wall]

I may have found this was fixed in 5.5.17 since I see this line in the 
changelog:


Correctly reset listeners when reloading a webapp (remm)

I'll give that a try

David


David Wall wrote:
We have multiple webapps running in a single Tomcat instance, and when 
we need to upgrade a given webapp, we install a system down web.xml 
that defines a null operation listener (we normally have one that 
bootstraps the application, connects to databases, etc.) and maps 
everything to a servlet that displays an error message.


What we found is that if we stop/start or reload the webapp using the 
Tomcat Manager application, the original context listener class is 
still being invoked, which of course we don't want since it 
initializes the application and such.  We do find that the all 
requests to any URL will use the system down servlet, so the system is 
restarting using the system down version of web.xml.


If we restart Tomcat entirely, then it works as expected, giving us 
the system down errors, but not running the real context listener.


Is there a way to allow this to work using the Manager app?  This 
would be preferable as we'd like to be able to do maintenance on a 
given webapp without affecting all of the others.


We're using Tomcat 5.5.12 with JDK 1.5 on Red Hat Linux.

Thanks,
David


P.S.  Here's that web.xml:

?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;

version=2.4

display-nameSystem down/display-name
descriptionSystem down/description

listener
   
listener-classcom.test.servlet.SystemDownContextListener/listener-class 


/listener

servlet
   servlet-nameSystemDown/servlet-name
   servlet-classcom.test.servlet.SystemDown/servlet-class
/servlet

servlet-mapping
   servlet-nameSystemDown/servlet-name
   url-pattern/*/url-pattern
/servlet-mapping

session-config
 session-timeout1/session-timeout
/session-config
/web-app


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: redirect with tomcat

[David Wall]

We've used UrlRewriteFilter with good success so far: 
http://tuckey.org/urlrewrite/


David

Lothar Krenzien wrote:


Hi there,

I'm using tomcat 5.5 and want to redirect some requests to another URL. For example the URL 
localhost:80/siteA  should be forwarded to localhost:8080/siteB. Of course on Port 8080 
listen another web-server. Does anybody know a good explanation how to do that ? I've tried 
with filters in catalina_home/conf/web.xml and put the classes in the  
catalina_home/server/classes and also by defining forwarding-rules in a rules.xml 
file. But all with no success.


Thanks for your answer.

Lothar
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!

Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: redirect with tomcat

[David Wall]

Well, you should check out the url rewrite documention for details.  In 
your webapp's web.xml, you put something like this in to tell it you 
want it to examine all URLs that come into the web app:


filter
   filter-nameUrlRewriteFilter/filter-name
   
filter-classorg.tuckey.web.filters.urlrewrite.UrlRewriteFilter/filter-class

   init-param
   param-namelogLevel/param-name
   param-valuelog4j/param-value
   /init-param
   init-param
   param-nameconfReloadCheckInterval/param-name
   param-value60/param-value
   /init-param
/filter
filter-mapping
   filter-nameUrlRewriteFilter/filter-name
   url-pattern/*/url-pattern
/filter-mapping

Note that I have set the logLevel to 'log4j' because that's what we use, 
but you can set it values like DEBUG, etc. or 'commons' if you use the 
commons logging.


In the same WEB-INF location where web.xml is defined, you configure the 
urlrewrite.xml file, with something like:


?xml version=1.0 encoding=utf-8?
!DOCTYPE urlrewrite PUBLIC -//tuckey.org//DTD UrlRewrite 2.5//EN
   http://tuckey.org/res/dtds/urlrewrite2.5.dtd;

!--

   Configuration file for UrlRewriteFilter
   http://tuckey.org/urlrewrite/

--
urlrewrite

   rule
   note
   Anything coming to / or any number of subsequent slashes 
should just go to the public site.

   /note
   from^/siteB(.*)$/from
   to type=redirecthttp://localhost:8080/sideB$1/to
   /rule

Note that the actual rule depends a bit on where you define this.  The 
above from entry assumes that /siteB is specified and being processed 
by the root webapp (context /).  If you are defining url rewrite in a 
webapp with a context of '/siteB' then you would assume the /siteB/ 
context path and use a from of just:  /(.*)$


No doubt there are better ways to configure it, but I'm not a URL 
rewrite expert.  But what you are doing sounds very straightforward and 
it should work for you.


David


Lothar Krenzien wrote:


Hi David ,

it looks interesting. But what I don't understand, when I define the filter in the project web.xml how does tomcat knows where to look when the entered url in the browser contains a project name which doesn't exits ? I think, when a user enters localhost:80/siteB I need to have a project in my webapp dir called projectB. What I want is, to redirect some specific urls to another server . 


My previous post contains a mistake :

localhost:80/siteB should be forwared to localhost:8080/siteB because I don't 
have an app siteB, but the clients would like to use only one hostname.

Thanks, Lothar

 


-Ursprüngliche Nachricht-
Von: Tomcat Users List users@tomcat.apache.org
Gesendet: 16.03.06 19:36:46
An: Tomcat Users List users@tomcat.apache.org
Betreff: Re: redirect with tomcat
   




 

We've used UrlRewriteFilter with good success so far: 
http://tuckey.org/urlrewrite/


David

Lothar Krenzien wrote:

   


Hi there,

I'm using tomcat 5.5 and want to redirect some requests to another URL. For example the URL 
localhost:80/siteA  should be forwarded to localhost:8080/siteB. Of course on Port 8080 
listen another web-server. Does anybody know a good explanation how to do that ? I've tried 
with filters in catalina_home/conf/web.xml and put the classes in the  
catalina_home/server/classes and also by defining forwarding-rules in a rules.xml 
file. But all with no success.


Thanks for your answer.

Lothar
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!

Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

   




__
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 

Off topic: Email bounce handler code?

[David Wall]

Does anybody know of any good Java/servlet code that handles email 
bounce processing?  When our automated systems send an email that 
bounces (lots of hotmail bounce if the user has an account but just 
hasn't logged in the past 30 days), we'd like a somewhat reliable 
mechanism to associate the bounce with a transaction in our system.  I'd 
guess I'd put a special header in so that bounces that return headers or 
return the original message can be parsed.


I've seen some mailman type code, but they rely on the SMTP server being 
able to handle mangled email addresses, but that's not generally an 
option for us as we often need to rely on existing SMTP systems in which 
at best we can configure the return path to be a given mailbox that we 
can analyze.


Thanks,
David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SSL Certificate Beginner Question

[David Wall]

-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --
!--
Connector
  port=8443 minProcessors=5 maxProcessors=75
  enableLookups=true disableUploadTimeout=true
  acceptCount=100 debug=0 scheme=https secure=true;
  clientAuth=false sslProtocol=TLS/
--
 


You probably want to add the following attributes to the Connector above:

keystoreFile=keys/tomcatkeys keystorePass=123

Obviously, make the keystoreFile point to the name of the Java keystore 
that you put your certificate inside, along with the password for that 
keystore.  I believe the base is $CATALINA_HOME if you use a relative 
pathname like above.


You'll also need to update your webapp's web.xml file with something 
like (that is, if you want Tomcat to enforce SSL on your webapp):


(after any servlet-mapping XML elements, before the session-config 
and/or welcome-file-list XML elements of web-app element in WEB-INF/web.xml)


security-constraint
 web-resource-collection
   web-resource-nameEntire site/web-resource-name
   url-pattern/*/url-pattern
   http-methodGET/http-method
   http-methodPOST/http-method
 /web-resource-collection
 user-data-constraint
   transport-guaranteeCONFIDENTIAL/transport-guarantee
 /user-data-constraint
/security-constraint



Hope that helps...

David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]