from:"Jess"

We're seeing a bizarre failure of getParameterMap() wherein this servlet 
API returns an empty map.


I thought we'd loused this up somehow via our servlet request filters, 
but the debugger shows this result on the very first line of our very 
first filter -- with the request object being Tomcat's own.


To make matters worse, this is a GET request with a /very /simple URL.

The query string is very simple ?ids=41jsonSupport=true.  The value 
of ids varies, but it's numeric and the cases I'm looking at are 2 to 
4 digits in length.  The rest of the request URI is short and all ASCII, 
being of the form {webAppName}//yy.


This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk 
1.2.37 and httpd 2.2.26.


As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we are 
using Spring MVC -- and getting a similar error message.  Given the 
point in request handling at which we're getting the erroneous result, I 
don't see how this is actually related to Spring MVC, but I also don't 
have any idea how one could reproduce the issue without Spring MVC or 
our (large proprietary) web application.


Any suggestions for getting to the bottom of this issue would be greatly 
appreciated!


--
Jess Holle

Re: Bizarre getParameterMap() failure

P.S. The only way I currently know to reproduce this issue is with a 
full install of our full commercial product plus optional modules -- and 
then to load large, sensitive customer data into this product and 
execute a very specific use case.


How this could possibly be related to Spring or /any /specifics of this 
use is a mystery to me.


I understand, however, that the requirements to reproduce this issue 
throw at least the initial troubleshooting and debugging squarely into 
my lap, which is why I'm asking for pointers, not filing bugs.


A little more version information (in case it is relevant):

 * Sprint 3.2.2
 * JDK 7u51

--
Jess Holle

On 4/7/2014 10:21 AM, Jess Holle wrote:
We're seeing a bizarre failure of getParameterMap() wherein this 
servlet API returns an empty map.


I thought we'd loused this up somehow via our servlet request filters, 
but the debugger shows this result on the very first line of our very 
first filter -- with the request object being Tomcat's own.


To make matters worse, this is a GET request with a /very /simple URL.

The query string is very simple ?ids=41jsonSupport=true. The value 
of ids varies, but it's numeric and the cases I'm looking at are 2 
to 4 digits in length.  The rest of the request URI is short and all 
ASCII, being of the form {webAppName}//yy.


This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk 
1.2.37 and httpd 2.2.26.


As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we 
are using Spring MVC -- and getting a similar error message. Given the 
point in request handling at which we're getting the erroneous result, 
I don't see how this is actually related to Spring MVC, but I also 
don't have any idea how one could reproduce the issue without Spring 
MVC or our (large proprietary) web application.


Any suggestions for getting to the bottom of this issue would be 
greatly appreciated!


--
Jess Holle

Re: Bizarre getParameterMap() failure

And looking at the data in Request *before* I invoke getParameter*() in 
our code, I see that parametersParsed is set to true.


I'm not sure if I should expect this to true at this point (entry to 
my first filter) for a GET request with a fairly stock Tomcat 7.0.50/53 
configuration.  It doesn't seem like it should be...


Tinkering with the internal state of the Request object, to set 
parametersParsed to false and/or parameterMap to null in the debugger 
doesn't help getParameterMap() succeed, though...


--
Jess Holle

On 4/7/2014 11:52 AM, Jess Holle wrote:
P.S. The only way I currently know to reproduce this issue is with a 
full install of our full commercial product plus optional modules -- 
and then to load large, sensitive customer data into this product and 
execute a very specific use case.


How this could possibly be related to Spring or /any /specifics of 
this use is a mystery to me.


I understand, however, that the requirements to reproduce this issue 
throw at least the initial troubleshooting and debugging squarely into 
my lap, which is why I'm asking for pointers, not filing bugs.


A little more version information (in case it is relevant):

  * Sprint 3.2.2
  * JDK 7u51

--
Jess Holle

On 4/7/2014 10:21 AM, Jess Holle wrote:
We're seeing a bizarre failure of getParameterMap() wherein this 
servlet API returns an empty map.


I thought we'd loused this up somehow via our servlet request 
filters, but the debugger shows this result on the very first line of 
our very first filter -- with the request object being Tomcat's own.


To make matters worse, this is a GET request with a /very /simple URL.

The query string is very simple ?ids=41jsonSupport=true. The value 
of ids varies, but it's numeric and the cases I'm looking at are 2 
to 4 digits in length.  The rest of the request URI is short and all 
ASCII, being of the form {webAppName}//yy.


This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk 
1.2.37 and httpd 2.2.26.


As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we 
are using Spring MVC -- and getting a similar error message. Given 
the point in request handling at which we're getting the erroneous 
result, I don't see how this is actually related to Spring MVC, but I 
also don't have any idea how one could reproduce the issue without 
Spring MVC or our (large proprietary) web application.


Any suggestions for getting to the bottom of this issue would be 
greatly appreciated!


--
Jess Holle

Re: Bizarre getParameterMap() failure


Thanks for the pointers -- I'll make good use of these.

As for #2, yes, the value of getQueryString() is as per expectations.

On 4/7/2014 1:01 PM, Konstantin Kolinko wrote:

Several quick thoughts

1. What is the value of
request.getAttribute(org.apache.catalina.parameter_parse_failed)
after you obtain that parameters map?

See Tomcat's o.a.c.filters.FailedRequestFilter for an example.

It will be non-null if there was any trouble when parsing the parameters.


2. What is the value of HttpServletRequest.getQueryString() ?

Is it what you expect?

I think you may also configure AccessLogValve to print it and maybe
also to print the parameters.

3. Put a breakpoint into o.a.c.connector.Request#getParameterMap().
Does it work as expected?

If I understand it correctly, from a quick look the method is not
thread-safe. There should not be concurrent requests to it.

4. Try to set RECYCLE_FACADES system property to true? (See
sysprops page of configuration reference for the full name of the
property).

E.g. if request object is shared between threads, there will be problems.

5.

   * Sprint 3.2.2

There are several known (unrelated) issues,
http://www.gopivotal.com/security/


Best regards,
Konstantin Kolinko

-
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: servlet 3.1, etc?

2013-07-10 Thread Jess Holle


Thanks!

On 7/10/2013 5:18 AM, Mark Thomas wrote:

On 10/07/2013 00:06, Jess Holle wrote:

Is there an ETA (in terms of both a version and rough date) for Tomcat
moving to the new spec versions introduced by Java EE 7?

Tomcat 8.

Implementation complete? Best guess is a couple of months. The more help
we get with the EL 3.0 implementation, the sooner we'll finish.

Stable? Best guess is late this year / early next.


I'm talking about new servlet, JSP, EL, etc, specs, not about
non-web-tier stuff that's not even part of Tomcat.

Servlet 3.1
Implementation complete. The HTTP upgrade code is very well tested as it
is used as the basic for WebSockets. The other areas are less well tested.

JSP 2.3 has minimal changes from 2.2 - mainly small changes due to
changes in EL. It isn't complete but could be within a day or so of the
EL being complete.

EL 3.0. The API changes have been completed. The current focus is adding
unit tests for the new API elements. Once the unit tests for the API are
complete, work will start on the new syntax. This is where the bulk of
the work remains for Tomcat 8.

WebSocket 1.0
Implementation complete. Both client and server code pass the Autobahn
testsuite. There are folks stress testing this implementation at the
moment and that has highlighted a few implementation (and spec) issues.
Those issues should be resolved (although I haven't looked at the dev
list yet this morning...)

So overall, I think progress looks pretty good. Folks that want to try
out these new features can build Tomcat 8 from trunk (it really is very
easy - ask here if you need some pointers). Snapshot releases are
available for those folks that want to help with testing but can't /
don't want to build Tomcat for themselves. Details on the dev list.

Mark

.




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

servlet 3.1, etc?

2013-07-09 Thread Jess Holle

Is there an ETA (in terms of both a version and rough date) for Tomcat 
moving to the new spec versions introduced by Java EE 7?


I'm talking about new servlet, JSP, EL, etc, specs, not about 
non-web-tier stuff that's not even part of Tomcat.


--
Jess Holle


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

Re: websockets questions

2013-07-03 Thread Jess Holle


Unfortunately I don't have any information -- just related questions.

1. For someone currently using Apache httpd+mod_jk to load balance
   requests, what does one do about load balancing WebSockets requests
   between Tomcat instances?
 * As Andre alluded to, the only mention of websocket handling in
   Apache httpd really appears to be in its infancy.
 * It would kind of seem like mod_jk should be expanded to deal
   with WebSockets...
 * In any case, there would still be questions as to how this
   interacts with mod_jk within the same web app.
2. Any other browser considerations beyond requiring IE 10+? Are
   relatively recent Chrome, Firefox, and Safari WebSocket ready?
3. How well do WebSockets play with existing network infrastructure?
 * IP load balancers
 * HTTP(S) forward and reverse proxy servers
 * Timeouts (idle, response, etc...)

   In general, if WebSockets don't just get along with existing
   network infrastructure in this regard but rather place requirements
   and restrictions upon it to function properly, then it will be a
   while before those of us who need to deploy a single solution into
   many disparate environments can leverage WebSockets in any
   substantive fashion.

--
Jess Holle

Re: permgen space increases every day

2013-05-21 Thread Jess Holle


Note:

If you use various things like RMI and CMS GC and don't set one or two 
key properties you'll always have a perm gen leak.


It's a nice feature of CMS :-)

On 5/21/2013 10:44 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Fachhoch,

On 5/21/13 10:53 AM, fachhoch wrote:

My application running on tomcat ,every day I see an increase in
permgen space

What was PermGen usage after your webapp reached a steady-state
(usually a few minutes after launch)? How much does it grow every day?
Have you ever run out of PermGen or are you just concerned that you
/might/ run out?


does this ever garbage collected?

Yes.


how can I see whats in the permgen space?

Use a memory profiler.


I guess Heap dump shows whats in the heap memory, how about
permgen space , I want to know why its increasing everyday?

I believe heap dump does give you PermGen info, but the mat tool
might not be great for visualizing it.


Tomcat 6.35 jdk 1.6

Note# I am not redeploying any application in tomcat and I just
have my app and not even the manager app.I always restart the
server if I have to redeploy my app.

That is good information to have. Do you do anything with RMI or use a
lot of proxy classes or anything like that? PermGen is mostly filled
with java.lang.Class objects. The more classes you have loaded, the
more PermGen you need. If you generate lots of on-the-fly Class
objects and their instances don't get collected, then the
java.lang.Class objects stick around forever and fill-up your PermGen.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRm5ZPAAoJEBzwKT+lPKRYTawQAJc0t5BGRSAtOtFcL/gNMi70
dsxOvL0FOXbYBcM5WE3OXOyPYMiHxQVGqe5tBTwcZrkF+cQ64V+tITrJvmRlHPMT
D9TjQNBgIvI5oFX4Ik8gcCxBgEW823Nn6+Qqa7ZKIrcMCNRi76hfGYfuXopJyD0I
WgsjKvbB8hgZbrCsN7uF5jfpf6CD6ataXO35jYB/Na1RAZ9az4Me5Q7Ray67svvw
XY0frWD6I7oUmsfyvuwNlXkdCoB6SWZDGjqn7d/3pzFhEqUi5Th5N/qeQkKNX3kk
gMc5Mt5jvd358Odc3gh4kdpbgo+BuBuEg6nXhlehhhMSvYHrbY/hNNkRhybQej3v
wxLK7NY90o/i2hQHo3SrXFt9HnVOG1JVBG/hT0K5saJH5DSoMULvJ/bLvCDvNwoR
+lUW6p/zyY1rZKminKlF6wyj0Kn14oXMF7ueRCGIaP05H8fwvakuOfk21nTEFptN
sn3jdrvvWMggZAWcjOKFVyBSxqAFAxTqikuYgE0Hjz82mj2L2GZl8cvKcqA8r34b
k9GDnshZOFMuR9dfe9o4mzTMy/RAXNkLrB3ioqRE79dMy/e8PShLNgkmzPjbasoY
aqNvYsXVMF1+HvuRw+XzliwCx2EdssGhk0yT4ZfvTH1PKMHPYRP89yy7SWf7HT5B
CuHOTq7lKyvpur49BNm6
=YlR/
-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

Re: Monitoring Tomcat - Delta Values

2013-05-03 Thread Jess Holle


On 5/3/2013 11:58 AM, Rainer Jung wrote:

Although AFAIR last time it couldn't do my favorite quotient of
deltas, but until now I haven't found a standard tool doing that.

Average response time in last intervall = delta(cumulatedResponseTime)/
   delta(RequestCount)

Tomcat provides cumulatedResponseTime and RequestCount per Servlet,
Webapp and globally, but unfortunately the tools lack for this one.
You can always add an MBean for such things -- and for cumulative CPU 
time per request, cumulative time spent blocked and waiting per request, 
etc, etc.


[Been there done that.]


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

Re: Monitoring Tomcat - Delta Values

2013-05-03 Thread Jess Holle


On 5/3/2013 12:26 PM, Rainer Jung wrote:

On 03.05.2013 19:03, Jess Holle wrote:

On 5/3/2013 11:58 AM, Rainer Jung wrote:

Although AFAIR last time it couldn't do my favorite quotient of
deltas, but until now I haven't found a standard tool doing that.

Average response time in last intervall = delta(cumulatedResponseTime)/
delta(RequestCount)

Tomcat provides cumulatedResponseTime and RequestCount per Servlet,
Webapp and globally, but unfortunately the tools lack for this one.

You can always add an MBean for such things -- and for cumulative CPU
time per request, cumulative time spent blocked and waiting per request,
etc, etc.

We do have the above cumulative stuff for Tomcat as MBeans. But if you
want the above statistics on a client controlled interval, the client
needs to be able to do quotient of deltas. Haven't seen any standard
client that can do that yet (they can do deltas and rates and some
quotients, but not the needed combination). So that's something one
might need to implement oneself.
I meant an MBean that does the deltas and quotients itself, of course, 
e.g. logging the results periodically.



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

Re: Attacks in Apache servers

2013-05-02 Thread Jess Holle

http://blogs.cisco.com/security/linuxcdorked-faqs/ claims this is not a 
cPanel vulnerability per se...


On 5/2/2013 6:22 AM, Darryl Lewis wrote:

Last Friday (April 26), ESET and Sucuri simultaneously blogged about the
discovery of Linux/Cdorked, a backdoor impacting Apache servers running
cPanel. -http://blogs.cisco.com/security/linuxcdorked-faqs/

So it looks like an cPanel application vulnerability, not an Apache
vulnerability. The title of that first article in simple WRONG.
And seriously, who manages a site via cPanel? If you use cPanel, maybe
linux isn't a good fit for you.


On 2/05/13 7:48 PM, Brian Burch br...@pingtoo.com wrote:


On 02/05/13 09:32, André Warnier wrote:

M Eashwar wrote:

Hi,

Anyone attacked with reference to below URL?


http://efytimes.com/e1/fullnews.asp?edid=105167ntype=moredate=4/29/201
3


Never heard of EFYtimes before, but considering what I have been
reading lately about bots, I would advise a modicum of caution before
following this link.
(And also maybe a modicum of healthy scepticism about that news article
itself).

This vulnerability applies only to apache httpd and is not relevant to
tomcat.

ALSO, it only applies to apache httpd when installed via a third-party
automated management system that is reported to not verify the digital
signature of the binary... which would be very negligent.

You should always verify apache packages against the published
signatures. Although linux distribution rpm and deb packages are
automatically verified during installation, we strongly recommend
installing packages directly from the official apache distribution
servers and then verifying the signature yourself - prior to installation!

Regards,

Brian

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



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

.




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

Re: Tomcat and Sun/Oracle Java 7

2013-02-04 Thread Jess Holle

It's not that Tomcat doesn't *run* fine with Java 7 even if you're 
making use of JDBC.


And it's not that you can't have code that calls JDBC APIs that works 
fine with Java 6 and Java 7.


It's that you can't make Java source code which /implements /JDBC 
interfaces and make it compilable with both Java 6 and Java 7. The JDBC 
interfaces have new methods in Java 7 *and* some of these new methods 
use classes new to Java 7.


One approach to work around this is to use dynamic proxies, but this can 
be obnoxious.  Otherwise you're stuck with code that will compile only 
with Java 6 or Java 7 -- take your pick.


This isn't a Tomcat issue -- it applies to anything which ends up 
needing to implement a JDBC interface.


Standard, built-in Java classes to wrap Connection, PreparedStatement, 
etc, would go a long way towards resolving this -- as one could simply 
extend the wrapper class and override the necessary methods.  This is a 
lot easier to read than InvocationHandler code required by the dynamic 
proxy approach. I'd bet that most who end up doing any substantive work 
in this area end up creating their own reusable pass-through wrapper 
classes for easy extension.


--
Jess Holle

On 2/4/2013 8:39 AM, André Warnier wrote:

Mark Thomas wrote:

On 04/02/2013 13:41, Caldarale, Charles R wrote:

From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Tomcat and
Sun/Oracle Java 7

What is the status of Tomcat vs Sun/oracle Java 7 ? I vaguely
remember seeing some messages on this list about some kind of 
incompatibility.

There are no known issues.

Although there are no issues with running Tomcat under Java 7, I was
under the impression that Tomcat 7 and below could not be built with
Java 7 due to JRE interface incompatibilities.


Correct. JDBC. Again.



Ok, then sorry about my persistent deep lack of knowledge of 
Java-things, but are the following assumptions correct ? (and if not, 
why ?)


- tomcat 6 will run fine under a Sun/Oracle Java 1.6 JVM
- tomcat 7 will run fine under a Sun/Oracle Java 1.6 JVM
- tomcat 6 will run fine under a Sun/Oracle Java 1.7 JVM
- tomcat 7 will run fine under a Sun/Oracle Java 1.7 JVM
- tomcat 6 will run fine under an OpenJDK Java 1.7 JVM
- tomcat 7 will run fine under an OpenJDK Java 1.7 JVM

and, there may (or may not) be problems compiling a servlet that uses 
JDBC under a Sun/Oracle Java 1.7 JDK, but assuming that this servlet 
does not use JDBC in any way :


- the classes of a servlet that has been compiled under a Sun/Oracle 
Java 1.6 JDK will run fine under Tomcat 6 and a Sun/Oracle Java 1.7 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle 
Java 1.7 JDK will run fine under Tomcat 6 and a Sun/Oracle Java 1.6 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle 
Java 1.6 JDK will run fine under Tomcat 6 and a OpenJDK Java 1.6 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle 
Java 1.6 JDK will run fine under Tomcat 6 and a OpenJDK Java 1.7 JVM


or alternatively, is it so that to run a servlet compiled under some 
JDK only works under the corresponding JRE/JVM ?
(or any other simpler rule-of-thumb rather than my exhaustive kind of 
list above)


I apologise if these are more Java-level questions than Tomcat-level 
questions, but as a sysadmin I have to decide which JVM to install, to 
run Tomcat along with webapps which I receive pre-compiled, and other 
non-Tomcat Java applications also precompiled.
And I have to decide this for several Linux and Windows platforms, 
whereas I am told that for some of these platforms at least, the 
pre-packaged versions of Java and/or Tomcat are not always the most 
recent ones. Hence my confusion.


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

.

Re: Tomcat and Sun/Oracle Java 7

2013-02-04 Thread Jess Holle


On 2/4/2013 9:32 AM, Williams, Nick wrote:

-Original Message-
From: Jess Holle [mailto:je...@ptc.com]

...
It's that you can't make Java source code which /implements /JDBC interfaces 
and make it compilable with both Java 6 and Java 7. The JDBC interfaces have 
new methods in Java 7 *and* some of these new methods use classes new to Java 7.
...

Just a quick correction. You CAN implement the JDBC interfaces so that they 
compile under both Java 7 and Java 6, as long as you don't use the @Override 
annotation on the methods you implement that were added in JDBC 4.1 (Java 7).
I stand corrected.  Perhaps it was with 1.5 and 1.6 where I tried and 
failed to do this.


At any rate, I no bother trying such things.  I have a version of such 
code to be compiled and used with 1.5, another for 1.6 and another for 1.7.


--
Jess Holle


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

JspC failure in Tomcat 7.0.35???

2013-01-17 Thread Jess Holle

As part of testing Tomcat 7.0.35 when I moved to it, I run an Ant script 
to pre-compile all our JSP pages.


When doing so I get a huge number of new failures which boil down to the 
following stack trace.  Any ideas here?  I can dig in to try to see 
what's causing this, but this is new behavior.


Poking around in the running web app, things seem to work, so the issue 
seems specific to using Jasper for pre-compilation.


  [jasper2] java.lang.NullPointerException
  [jasper2] at 
org.apache.jasper.compiler.TagPluginManager.init(TagPluginManager.java:83)
  [jasper2] at 
org.apache.jasper.compiler.TagPluginManager.apply(TagPluginManager.java:57)
  [jasper2] at 
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:240)
  [jasper2] at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
  [jasper2] at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
  [jasper2] at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
  [jasper2] at 
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646)
  [jasper2] at 
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrapper.java:240)
  [jasper2] at 
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:578)
  [jasper2] at 
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:49)
  [jasper2] at 
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:655)
  [jasper2] at 
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1539)
  [jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
  [jasper2] at 
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
  [jasper2] at 
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:659)
  [jasper2] at 
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1539)
  [jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
  [jasper2] at 
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
  [jasper2] at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2434)
  [jasper2] at org.apache.jasper.compiler.Node$Root.accept(Node.java:475)
  [jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
  [jasper2] at 
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
  [jasper2] at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2452)
  [jasper2] at 
org.apache.jasper.compiler.Node$IncludeDirective.accept(Node.java:639)
  [jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
  [jasper2] at 
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
  [jasper2] at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2434)
  [jasper2] at org.apache.jasper.compiler.Node$Root.accept(Node.java:475)
  [jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
  [jasper2] at 
org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:673)
  [jasper2] at 
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:229)
  [jasper2] at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
  [jasper2] at org.apache.jasper.JspC.processFile(JspC.java:1179)
  [jasper2] at org.apache.jasper.JspC.execute(JspC.java:1329)
  [jasper2] at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
  [jasper2] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
  [jasper2] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  [jasper2] at java.lang.reflect.Method.invoke(Method.java:601)
  [jasper2] at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
  [jasper2] at org.apache.tools.ant.Task.perform(Task.java:348)
  [jasper2] at org.apache.tools.ant.Target.execute(Target.java:392)
  [jasper2] at org.apache.tools.ant.Target.performTasks(Target.java:413)
  [jasper2] at 
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
  [jasper2] at 
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
  [jasper2] at 
org.apache.tools.ant.Project.executeTargets(Project.java:1251)
  [jasper2] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
  [jasper2] at 
org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
  [jasper2] at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
  [jasper2] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
  [jasper2] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  [jasper2] at java.lang.reflect.Method.invoke(Method.java:601)
  [jasper2] at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)

Re: JspC failure in Tomcat 7.0.35???

2013-01-17 Thread Jess Holle

Thanks.  I'm moving forward to 7.0.35 with the patch, whereas without 
the patch 7.0.35 would have been a non-starter (not because it's that 
bad but rather because 7.0.34 was good enough that this issue, if 
unresolved, more than cancels out 7.0.35's fixes from my perspective).


On 1/17/2013 12:36 PM, Violeta Georgieva wrote:

2013/1/17 Jess Holle je...@ptc.com


As part of testing Tomcat 7.0.35 when I moved to it, I run an Ant script
to pre-compile all our JSP pages.

When doing so I get a huge number of new failures which boil down to the
following stack trace.  Any ideas here?  I can dig in to try to see what's
causing this, but this is new behavior.

Poking around in the running web app, things seem to work, so the issue
seems specific to using Jasper for pre-compilation.

   [jasper2] java.lang.NullPointerException
   [jasper2] at org.apache.jasper.compiler.**TagPluginManager.init(**
TagPluginManager.java:83)
   [jasper2] at org.apache.jasper.compiler.**TagPluginManager.apply(**
TagPluginManager.java:57)
   [jasper2] at org.apache.jasper.compiler.**Compiler.generateJava(**
Compiler.java:240)


Check this https://issues.apache.org/bugzilla/show_bug.cgi?id=54440

Regards
Violeta




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

Re: Tomcat 7.0.34 and ecj 3.7.2/4.2.1

2013-01-10 Thread Jess Holle


Stick with the older ecj -- the newer one is broken.

On 1/10/2013 9:22 PM, Ralph Schaer wrote:

Hi

Tomcat 7.0.34 bumped ecj to version 4.2.1. But the pom file
of tomcat-embed-jasper still points to version 3.7.2 of ecj.
Is it safe to use ecj 3.7.2 with Tomcat 7.0.34?
It's unfortunately not possible to override this, because I haven't found
the 4.2.1 artifact in the central repository.

Ralph




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

Re: Tomcat 7.0.34 JspC issue?

2012-12-13 Thread Jess Holle

No, unfortunately I have no small test case.  Our JSPs are the opposite 
of standalone test cases and I've not had time to try to find a trigger 
within them -- and quite likely won't have such time.


Out of our 1000's of JSP pages I saw a dozen or so JSP precompilation 
failures that weren't present prior to stopping the precompilation early 
-- hence I don't know how many failures I would have had.


I tested this with Java 6 and Java 7 against 2 different versions of our 
application (compiled with Java 6 and Java 7, respectively) where Tomcat 
7.0.33 worked fine.  Tomcat 7.0.34 failed in both cases -- until I 
reverted to the old ecj.jar.


There *may* be a relationship to how my pre-compilation runs. Even if 
that's the case I'll be sticking with the old ecj.jar as it clearly works.


The pre-compilation script that I was running does the following:

1. Try to compile everything en masse excluding known failures (mostly
   legacy JSP fragments that were improperly named .jspf rather than .jsp)
2. Catch (via ant-contrib) any failure and re-try to compile everything
   en masse excluding known failure
 * The first attempt has been consistently failing for quite a
   number of Tomcat releases for no apparent reason on a tag file
   or some such as I recall (too many nested dependencies?) where
   the second would succeed.
3. Catch any failure one again
 * If there was a failure try to recompile each JSP individually so
   as to generate an accurate list of failures.
4. If there was no failure on the second attempt, then try to compile
   every JSP in the known failure list so as to verify that the entire
   known failure list is still failing.

The need to re-try the en-masse JspC has been bothersome for quite some 
time -- and doesn't seem to be addressed by simple things like giving 
the script more memory.  That said, this issue has been there for quite 
some time.


The new issue shows up when trying to compile one of the failing JSPs 
all by itself and results in a stack trace into the bowels of ECJ, so 
this really looks like an issue in ECJ.


--
Jess Holle

On 12/13/2012 1:07 AM, Mark Thomas wrote:

Jess Holle je...@ptc.com wrote:

I moved to Tomcat 7.0.34 -- apparently with inadequate testing / too
much trust.

Some JSPs that precompiled just fine with 7.0.33 and many previous
Tomcat versions now produce the error shown below

Moving back to the ecj jar from Tomcat 7.0.33 resolves the issue. I'm
assuming buggy JDT compiler until proven otherwise.

It certainly sounds like a bug in ecj.jar

Do you have a sample JSP you can share that demonstrates the issue?

Mark


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

Tomcat 7.0.34 JspC issue?

2012-12-12 Thread Jess Holle

I moved to Tomcat 7.0.34 -- apparently with inadequate testing / too 
much trust.


Some JSPs that precompiled just fine with 7.0.33 and many previous 
Tomcat versions now produce the error shown below


Moving back to the ecj jar from Tomcat 7.0.33 resolves the issue. I'm 
assuming buggy JDT compiler until proven otherwise.


--
Jess Holle

  [jasper2] java.lang.ArrayStoreException: 
org.eclipse.jdt.internal.compiler.ast.ReturnStatement
  [jasper2] at 
org.eclipse.jdt.internal.compiler.flow.FinallyFlowContext.recordNullReference(FinallyFlowContext.java:440)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.flow.FinallyFlowContext.recordUsingNullReference(FinallyFlowContext.java:405)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.flow.LoopingFlowContext.complainOnDeferredNullChecks(LoopingFlowContext.java:278)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.DoStatement.analyseCode(DoStatement.java:112)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:102)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.TryStatement.analyseCode(TryStatement.java:260)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:102)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.LabeledStatement.analyseCode(LabeledStatement.java:54)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.DoStatement.analyseCode(DoStatement.java:69)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:102)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.DoStatement.analyseCode(DoStatement.java:69)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:102)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.DoStatement.analyseCode(DoStatement.java:69)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:102)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.DoStatement.analyseCode(DoStatement.java:69)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:102)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.DoStatement.analyseCode(DoStatement.java:69)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:102)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:39)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.TryStatement.analyseCode(TryStatement.java:336)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.analyseCode(MethodDeclaration.java:110)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:710)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:255)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.analyseCode(CompilationUnitDeclaration.java:111)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:776)
  [jasper2] at 
org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:470)
  [jasper2] at 
org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:458)
  [jasper2] at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:378)
  [jasper2] at org.apache.jasper.JspC.processFile(JspC.java:1179)
  [jasper2] at org.apache.jasper.JspC.execute(JspC.java:1329)
  [jasper2] at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
  [jasper2] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
  [jasper2] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke

Re: Java 6u35, 7u07 are available

2012-08-31 Thread Jess Holle


Well, don't give Oracle too much credit -- or grief.

According to various articles (look them up, I didn't save the URLs), 
they were notified of these vulnerabilities ~4 months ago.


Unfortunately several days ago serious attacks in the wild using these 
vulnerabilities were discovered -- after which Oracle responded rather 
quickly.


So one can give Oracle hell for not triaging these particular 
vulnerabilities as needing redress far more quickly than 4 months or 
laud them for fixing the issue quickly once a zero-day attack was found 
in the wild.  I'd say the reasonable response is somewhere in between 
and that overall most companies make some mistakes in this area (just 
look at some of the issue Microsoft has sat on)


On 8/31/2012 10:16 AM, Williams, Nick wrote:

Just my smarmy reply to Tony's when Sun owned Java comment...

Used to be when Sun owned Java you got security updates months, not days, after 
a vulnerability like this was discovered. :-)

Not saying I like Oracle (I loathe it most days); just making the point that 
they were REALLY good about jumping on this issue so quickly.

Nick

-Original Message-
From: Tony Anecito [mailto:adanec...@yahoo.com]
Sent: Friday, August 31, 2012 10:02 AM
To: Tomcat Users List
Subject: Re: Java 6u35, 7u07 are available

Hi All,

I looked at the release notes and there was nearly nothing there. So 
justification to update was impossible. Oracle needs to realize that releases 
with just one security and one time clock change makes it impossible to explain 
to anyone why we need to update an Enterprise.

Just my inital reaction. Used to be you got actual release notes when Sun owned 
Java.

Regards,
-Tony

--- On Fri, 8/31/12, Konstantin Kolinko knst.koli...@gmail.com wrote:


From: Konstantin Kolinko knst.koli...@gmail.com
Subject: Java 6u35, 7u07 are available
To: Tomcat Users List users@tomcat.apache.org
Date: Friday, August 31, 2012, 8:54 AM


Hi!

Just noting that Java 6u35, 7u07 were released by Oracle a day ago 
http://www.oracle.com/technetwork/java/javase/downloads/

Those contain security fixes for issues exploitable when running Java from 
within a web browser. (Those running it on server or standalone are said to be 
unaffected).
http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html

BTW, some media wrote that CVE-2012-4681 affects only Java 7, but not Java 6.
Oracle page, linked above, says the update includes fixes for two other 
vulnerabilities and affects both Java 6 and Java 7.

Best regards,
Konstantin Kolinko

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


This e-mail may contain privileged or confidential information. If you are not 
the intended recipient: (1) you may not disclose, use, distribute, copy or rely 
upon this message or attachment(s); and (2) please notify the sender by reply 
e-mail, and then delete this message and its attachment(s). Underwriters 
Laboratories Inc. and its affiliates disclaim all liability for any errors, 
omissions, corruption or virus in this message or any attachments.


-
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: Java 6u35, 7u07 are available

2012-08-31 Thread Jess Holle

In case it's not clear, Oracle normally strictly alternates between 
security-only (or very, very nearly security only) and 
performance/bug-fix updates.


In this particular case they had to alter their plans -- as they had to 
get a security fix out the door immediately.


On 8/31/2012 10:31 AM, Tony Anecito wrote:

Thanks Everyone. I agree on the security issue just seemed the last couple of 
updates had no substance beyond just security. MS sends updates quite often but 
I look forward to advances in other areas like performance ect.
  
Regards,

-Tony

--- On Fri, 8/31/12, Jess Holle je...@ptc.com wrote:


From: Jess Holle je...@ptc.com
Subject: Re: Java 6u35, 7u07 are available
To: Tomcat Users List users@tomcat.apache.org
Cc: Williams, Nick nicholas.willi...@ul.com
Date: Friday, August 31, 2012, 9:22 AM


Well, don't give Oracle too much credit -- or grief.

According to various articles (look them up, I didn't save the URLs),
they were notified of these vulnerabilities ~4 months ago.

Unfortunately several days ago serious attacks in the wild using these
vulnerabilities were discovered -- after which Oracle responded rather
quickly.

So one can give Oracle hell for not triaging these particular
vulnerabilities as needing redress far more quickly than 4 months or
laud them for fixing the issue quickly once a zero-day attack was found
in the wild.  I'd say the reasonable response is somewhere in between
and that overall most companies make some mistakes in this area (just
look at some of the issue Microsoft has sat on)

On 8/31/2012 10:16 AM, Williams, Nick wrote:

Just my smarmy reply to Tony's when Sun owned Java comment...

Used to be when Sun owned Java you got security updates months, not days, after 
a vulnerability like this was discovered. :-)

Not saying I like Oracle (I loathe it most days); just making the point that 
they were REALLY good about jumping on this issue so quickly.

Nick

-Original Message-
From: Tony Anecito [mailto:adanec...@yahoo.com]
Sent: Friday, August 31, 2012 10:02 AM
To: Tomcat Users List
Subject: Re: Java 6u35, 7u07 are available

Hi All,

I looked at the release notes and there was nearly nothing there. So 
justification to update was impossible. Oracle needs to realize that releases 
with just one security and one time clock change makes it impossible to explain 
to anyone why we need to update an Enterprise.

Just my inital reaction. Used to be you got actual release notes when Sun owned 
Java.

Regards,
-Tony

--- On Fri, 8/31/12, Konstantin Kolinko knst.koli...@gmail.com wrote:


From: Konstantin Kolinko knst.koli...@gmail.com
Subject: Java 6u35, 7u07 are available
To: Tomcat Users List users@tomcat.apache.org
Date: Friday, August 31, 2012, 8:54 AM


Hi!

Just noting that Java 6u35, 7u07 were released by Oracle a day ago 
http://www.oracle.com/technetwork/java/javase/downloads/

Those contain security fixes for issues exploitable when running Java from 
within a web browser. (Those running it on server or standalone are said to be 
unaffected).
http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html

BTW, some media wrote that CVE-2012-4681 affects only Java 7, but not Java 6.
Oracle page, linked above, says the update includes fixes for two other 
vulnerabilities and affects both Java 6 and Java 7.

Best regards,
Konstantin Kolinko

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


This e-mail may contain privileged or confidential information. If you are not 
the intended recipient: (1) you may not disclose, use, distribute, copy or rely 
upon this message or attachment(s); and (2) please notify the sender by reply 
e-mail, and then delete this message and its attachment(s). Underwriters 
Laboratories Inc. and its affiliates disclaim all liability for any errors, 
omissions, corruption or virus in this message or any attachments.


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




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





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

Re: Tomcat 7.0.29 vs. Groovy with Java 7

2012-08-17 Thread Jess Holle

On 8/17/2012 3:18 PM, Konstantin Kolinko wrote:

2012/8/16 Jess Holle je...@ptc.com:

It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat
web app, BCEL chokes on the Java 7 specific byte-code therein ala

org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte
tag in constant pool: 15
at
org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
at
org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)
at
org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
at
org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
at
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)
...

Is there an update planned to make org.apache.tomcat.util.bcel savvy to Java
7 or replace it with ASM (which is fully Java 7 savvy)? [Please!]

BCEL is now being developed at Apache Commons. If one contributes a
patch there, I think it will make its way into Tomcat as well.

I do not think that anyone would bother replacing the annotation
scanning code with ASM one.

http://commons.apache.org/bcel/
BCEL does not appear to be terribly actively maintained -- else it
wouldn't have had an issue with Java 7 byte code...

Until it is updated, Tomcat's annotation scanning will be broken for
/some /Java 7 byte code. That's not really a tenable state long term.

ASM handles Java 7 byte code now. That's the only reason I bring it up
(well, it's fast too...)

--
Jess Holle

Tomcat 7.0.29 vs. Groovy with Java 7

2012-08-16 Thread Jess Holle

It appears that when one installs the groovy-all-2.0.1-indy.jar in a 
Tomcat web app, BCEL chokes on the Java 7 specific byte-code therein ala


   org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag 
in constant pool: 15
at 
org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
at 
org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)
at 
org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
at 
org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
at 
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)
...

Is there an update planned to make org.apache.tomcat.util.bcel savvy to 
Java 7 or replace it with ASM (which is fully Java 7 savvy)? [Please!]


Until then, can I completely exclude this jar from annotation scanning?

--
Jess Holle

Re: Tomcat 7.0.29 vs. Groovy with Java 7

2012-08-16 Thread Jess Holle


On 8/16/2012 11:14 AM, Pid * wrote:

On 16 Aug 2012, at 17:10, Jess Holle je...@ptc.com wrote:

It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat web 
app, BCEL chokes on the Java 7 specific byte-code therein ala

   org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag 
in constant pool: 15
   at 
org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
   at 
org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)
   at 
org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
   at 
org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
   at 
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)
...

Is there an update planned to make org.apache.tomcat.util.bcel savvy to Java 7 
or replace it with ASM (which is fully Java 7 savvy)? [Please!]

Until then, can I completely exclude this jar from annotation scanning?

Yes!

Sorry, but how?

--
Jess Holle


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

Re: Speeding up RMI calls

2012-07-28 Thread Jess Holle

The only way I know to address this obnoxious issue is to create your 
own custom RMIClassLoaderSpi and install it early enough.


The custom RMIClassLoaderSpi is very simple:

  public String  getClassAnnotation( final Class cl )
  {
return ( null );  // we don't need no stinking bloated RMI
   class annotations!
  }

otherwise the implementation can simply default to 
DefaultSpiHolder.instance.getDefaultSpi().


Of course, it is extremely silly that this issue has existed for many 
years and there's still no simple -Djava.rmi.disableClassAnnotations or 
the like.

Re: two instances of Tomcat in same machine

2012-05-16 Thread Jess Holle

On Windows 32-bit JVMs are often limited to less than 1.3GB of heap due 
to fragmentation of the 32-bit address space.  Sometimes one cannot even 
get 1GB of heap!


For any hefty server process on Windows you really want a 64-bit JVM for 
this reason.


On other OS's one can often allocate much more heap under 32-bit 
addressing.  How much depends on the OS, etc, but generally is much more 
like 3GB.


--
Jess Holle

On 5/16/2012 8:04 AM, André Warnier wrote:

Miguel Gonzalez wrote:

there wasn't a limit of 32 bits OS for running JVM for more than 1.5 Gb?


Not exactly.  I'm not sure that my knowledge is totally accurate here, 
but here is my take on it :


- a 32 bit OS generally means that the total address space available 
to *a process* running at any point in time under that OS is 2^32 = 
4,294,967,296 bytes, which is 4 GB (give or take :-)).
- this includes the memory accupied by the resident part of the OS, so 
that in the practice nowadays, a process can use only a fraction of 
that, say 2-3 GB.
- that available addressable space is shared between the code of the 
process, and the in-memory data needed by that process
- the JVM (which runs Tomcat) is one such process.  The code of the 
JVM itself occupies some memory. For the JVM, the Tomcat code and your 
application code is data, which uses a part of the addressable space 
available to the JVM process. The JVM also allocates some space for 
the data that Tomcat and your applications use, dynamically, as needed 
and requested by Tomcat and your applications.  In Java, most of that 
work memory is allocated in a memory structure called the Heap.
- in the practice thus, if you are running a Java application under a 
Java JVM under a 32-bit OS, the maximum size of the Heap that your 
application will be able to use is likely to limited to around 2-2.5 
GB.  OS-specific characteristics may further reduce this.


On hardware that can use 64-bit addresses, and with an OS that can use 
a 64-bit address space, these limits are much higher (2^64 = 
18,446,744,073,709,551,616 bytes), so that in the practice you would 
run out of money long before your run out of Heap space.

(And you would also run out of time before you fill up all that memory).


-
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

servlet 3.1 support?

2012-03-13 Thread Jess Holle

So I read that the servlet 3.1 spec (and related EL specs, etc) is to go 
final in the second half of 2012.


Approximately when should we expect a Tomcat that supports the new specs 
-- in terms of number of months after the specs' final release?


--
Jess Holle


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

Re: servlet 3.1 support?

2012-03-13 Thread Jess Holle


On 3/13/2012 8:49 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jess,

On 3/13/12 8:47 AM, Jess Holle wrote:

So I read that the servlet 3.1 spec (and related EL specs, etc) is
to go final in the second half of 2012.

Approximately when should we expect a Tomcat that supports the new
specs -- in terms of number of months after the specs' final
release?

There's no guarantee of anything. Remember: everyone around here is a
volunteer, and there's no mandated schedule.
Of course!  This is an open-source community, not a commercial 
enterprise.  Even if it were a commercial enterprise, they get their 
schedules wrong more often than they get them right!

Here are some dates that may be relevant, but again, everything is up
in the air:

Servlet 3.0 spec finalized:December 2009
Tomcat 7.0.0 (beta) released:  June 2010
Tomcat 7.0.6 (first non-beta): January 2011

Now, servlet 3.0 was a fairly big jump from 2.5 and 3.0-3.1 is likely
to be less effort in general. As happened with Tomcat 7.0.x, Tomcat
8.0.x (first to support spec 3.1) is currently in active development
and lots of little things (mostly clarifications) from 3.1 have
already gone into the trunk.
I am hoping that the delay between 3.1 and non-beta 8.0.x isn't 12-13 
months as 3.1 is a much smaller step, but I understand there are no 
guarantees.  It is good to know that 8.0.x development is ongoing, though.


--
Jess Holle


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

Re: JMX JVM bug workaround question

2012-03-07 Thread Jess Holle


How can this be a low priority JVM bug!?!

On 3/7/2012 11:21 AM, Konstantin Kolinko wrote:

2012/3/7 Kari Scottkari.sc...@cdw.com:


We are using Tomcat 7.0.23 with jdk1.6.0_30 on Solaris 10, mod_ajp 1.3  and 
Apache 2.2.21.

I'm using the following code to retrieve memory information from our JMX server:


ObjectName contextObjectName = new ObjectName(java.lang:type=Memory);
CompositeData memoryUsage = (CompositeData)server.getAttribute(contextObjectName, 
HeapMemoryUsage);


This works really well most of the time but we occasionally we get this 
exception when trying to retrieve HeapMemoryUsage:

javax.management.RuntimeMBeanException:
java.lang.IllegalArgumentException: committed = 1607688192 should be  max = 
1607270400


After some digging, I found that it is a bug in the JVM (It occurs in 1.7, too):

  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7100266


My questions for the list then are has anyone else come across this and, if so, 
how did you get around it? Is there an alternative way for retrieving used and 
committed memory from a JMX MBean?

The issue seems like some threading issue when max and committed
memory settings are calculated independently at different moments and
fail to pass a consistency check between them.

I think I would wait a while and retry, but only once.

Do you check what Runtime.freeMemory(), Runtime.totalMemory() return
at the same time? Maybe there is so little free memory that it is
worth to worry.

Best regards,
Konstantin Kolinko

-
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

Known ECJ issue?

2012-03-01 Thread Jess Holle


In some cases we are seeing:

2012-03-01 18:43:55,624 ERROR [ajp-bio-9920-exec-2] 
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/PDMPJL100].[jsp]
  - Servlet.service() for servlet [jsp] in context with path [/PDMPJL100] threw 
exception [wt.util.WTRuntimeException: org.apache.jasper.JasperException: 
Unable to compile class for JSP; nested exception is:
org.apache.jasper.JasperException: Unable to compile class for JSP] 
with root cause
java.lang.ArrayIndexOutOfBoundsException: 67
at 
org.eclipse.jdt.internal.compiler.codegen.CodeStream.isDefinitelyAssigned(CodeStream.java:4548)

whereas in others for the same JSPs, tags, etc (as best we can tell) 
we're not.


This is with Tomcat 7.0.23 and thus ecj 3.7.  Are there known issues in 
this regard with ecj 3.7?  Are they addressed by 3.7.1?  Is there a 
reasonable way to obtain and try a newer ecj.jar?  [I couldn't find one.]


I've seen some other odd behavior with the latest Tomcat 6 (also using 
3.7) -- where it will compile a given JSP page fine most of the time, 
but in others (for exactly the same JSP and tags with no changes) will 
produce the dreaded method too big (65K) error.  This is maddening when 
nothing has changed -- the compiler should produce the same results in 
any case.  This particular issue is hard enough to reproduce that I've 
not had a chance to try it with 3.7.1.


--
Jess Holle


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

Re: Known ECJ issue?

2012-03-01 Thread Jess Holle


On 3/1/2012 9:50 AM, Jess Holle wrote:

In some cases we are seeing:

2012-03-01 18:43:55,624 ERROR [ajp-bio-9920-exec-2] 
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/PDMPJL100].[jsp]  
- Servlet.service() for servlet [jsp] in context with path 
[/PDMPJL100] threw exception [wt.util.WTRuntimeException: 
org.apache.jasper.JasperException: Unable to compile class for JSP; 
nested exception is:
org.apache.jasper.JasperException: Unable to compile class 
for JSP] with root cause

java.lang.ArrayIndexOutOfBoundsException: 67
at 
org.eclipse.jdt.internal.compiler.codegen.CodeStream.isDefinitelyAssigned(CodeStream.java:4548)


whereas in others for the same JSPs, tags, etc (as best we can tell) 
we're not.


This is with Tomcat 7.0.23 and thus ecj 3.7.  Are there known issues 
in this regard with ecj 3.7?  Are they addressed by 3.7.1?  Is there a 
reasonable way to obtain and try a newer ecj.jar?  [I couldn't find one.]
Sorry for the noise on this part of my post -- we've found the issue 
here.  Someone stuck an old ecj jar into lib in these cases!
I've seen some other odd behavior with the latest Tomcat 6 (also using 
3.7) -- where it will compile a given JSP page fine most of the time, 
but in others (for exactly the same JSP and tags with no changes) will 
produce the dreaded method too big (65K) error.  This is maddening 
when nothing has changed -- the compiler should produce the same 
results in any case.  This particular issue is hard enough to 
reproduce that I've not had a chance to try it with 3.7.1.

I'm still wondering about this issue, though...

--
Jess Holle

Re: Form Authentication POST data not preserved?

I've done all the basic troubleshooting tweaks I can think of, trying 
7.0.25 and 7.0.23, switching my web.xml back to the 2.5 spec level, 
reducing from a combination of 2 JNDI realms to 1, cranking lots of 
loggers up to full verbosity, etc.


In all cases I lose the POST parameters.

I guess I either ignore this (ouch) or really dig into debugging 
Tomcat's internals (which while far easier than trying to do so with 
httpd is still not where I'd wanted to spend my time).


--
Jess Holle

On 2/4/2012 5:49 PM, Jess Holle wrote:
Yes, I'm using Tomcat authentication.  Yes, the issue is after 
authentication on the POST retry.



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

Re: Form Authentication POST data not preserved?


On 2/5/2012 8:29 AM, Konstantin Kolinko wrote:

2012/2/5 Jess Holleje...@ptc.com:

I've done all the basic troubleshooting tweaks I can think of, trying 7.0.25
and 7.0.23, switching my web.xml back to the 2.5 spec level, reducing from a
combination of 2 JNDI realms to 1, cranking lots of loggers up to full
verbosity, etc.

In all cases I lose the POST parameters.

1. You have to pay attention to Cookie/Set-Cookie headers that are
sent between Server and Client. The value there is session id.

Just a note: upon successful authentication there should be one more
Set-Cookie header sent by the server, because session id will be
changed (but not the session itself).

You can use browser plugins (like Firefox  Live Http Headers or
Firebug), network sniffers (Wireshark) or just configure your access
log to log those headers.

The standard Tomcat Manager web application can be used to inspect
active sessions and their attributes.

Nothing appears to be amiss with respect to Set-Cookie and Cookie headers.

2. Enable debug logging for FormAuthenticator class.

org.apache.catalina.authenticator.FormAuthenticator.level=FINE

If you configure logging to use OneLineFormatter, it will include
thread id and it will be easier to match it against access log (if
access log is configured to print thread ids as well). E.g.
1catalina.org.apache.juli.FileHandler.formatter =
org.apache.juli.OneLineFormatter
I had already increased verbosity for FormAuthenticator -- nothing 
seemed amiss from what I could tell there.  It /said/ it was restoring 
the original request from the session.  I never see anything about a 
POST body being restored, but I'm not sure if there is any logging to 
this effect.

http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
Thanks.  I've got that part down.  The harder part is rebuilding pieces 
of Tomcat with full debug information (I'm assuming Tomcat is normally 
not built with local variable debug information) and finding my way 
through unfamiliar code.  But that's life :-)


--
Jess Holle

Re: Form Authentication POST data not preserved?


On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:

build.xml:
 javac srcdir=java destdir=${tomcat.classes}
debug=${compile.debug}
deprecation=${compile.deprecation}
source=${compile.source}
target=${compile.target}
optimize=${compile.optimize}
excludes=**/.svn/**
encoding=ISO-8859-1
includeAntRuntime=true

build.properties.default:
compile.debug=true

Thus debug information should already be there.

I usually start with setting some breakpoints. In your case take a
look at FormAuthenticator#saveRequest() and #restoreRequest() methods
and where they are called from.
Thanks.  I've already seen via a heap dump that the request is saved 
with the correct content body.  So now the only question that remains is 
why it does not get restored.


--
Jess Holle


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

Re: Form Authentication POST data not preserved?


On 2/5/2012 9:43 AM, Jess Holle wrote:

On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:

build.xml:
javac srcdir=java destdir=${tomcat.classes}
debug=${compile.debug}
deprecation=${compile.deprecation}
source=${compile.source}
target=${compile.target}
optimize=${compile.optimize}
excludes=**/.svn/**
encoding=ISO-8859-1
includeAntRuntime=true

build.properties.default:
compile.debug=true

Thus debug information should already be there.

I usually start with setting some breakpoints. In your case take a
look at FormAuthenticator#saveRequest() and #restoreRequest() methods
and where they are called from.
Thanks.  I've already seen via a heap dump that the request is saved 
with the correct content body.  So now the only question that remains 
is why it does not get restored.


Diving in deeper, I see that AbstractAjpProcessor.action() is setting 
the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.


After that is done, however, I don't see anything that tries to read 
AbstractAjpProcessor.bodyBytes.  
org.apache.catalina.connector.Request.readPostBody() seems to completely 
ignore this data.


I'm thinking some refactoring in this area completely broke this use 
case at least for the AJP BIO path.  Or can someone offer evidence that 
the breakage is less general than this?


--
Jess Holle


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

Re: Form Authentication POST data not preserved?


On 2/5/2012 10:38 AM, Jess Holle wrote:
Diving in deeper, I see that AbstractAjpProcessor.action() is setting 
the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.


After that is done, however, I don't see anything that tries to read 
AbstractAjpProcessor.bodyBytes.  
org.apache.catalina.connector.Request.readPostBody() seems to 
completely ignore this data.


I'm thinking some refactoring in this area completely broke this use 
case at least for the AJP BIO path.  Or can someone offer evidence 
that the breakage is less general than this?


I'm not seeing any evidence as to how 
org.apache.catalina.connector.Request is convinced to use the new 
bodyBytes from AbstractAjpProcessor here, neither in 7.0.25 or looking 
back at previous tags.


Am I missing something here?

Note that I can see how the HTTP connectors could work in this regard -- 
I'm just not seeing how the AJP connectors could.


--
Jess Holle


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

Re: Form Authentication POST data not preserved?


On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:

I think this issue is specific to AJP.

For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9

I think adding the following line to REQ_SET_BODY_REPLAY case in
AbstractAjpProcessor#action() will fix this bug:

endOfStream = false;


That did the trick!  [I just did this via the debugger without a 
rebuild, but same thing.]


Could someone please patch this into trunk so it's in the next Tomcat 
release?


Until then I can certainly patch it into my own Tomcat.  I just don't 
want to maintain this patch forever (nor have everyone else suffer from 
this bug in the AJP case).


--
Jess Holle


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

Re: Form Authentication POST data not preserved?


On 2/5/2012 11:22 AM, Jess Holle wrote:

On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:

I think this issue is specific to AJP.

For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9

I think adding the following line to REQ_SET_BODY_REPLAY case in
AbstractAjpProcessor#action() will fix this bug:

endOfStream = false;


That did the trick!  [I just did this via the debugger without a 
rebuild, but same thing.]


Could someone please patch this into trunk so it's in the next Tomcat 
release?

By patch, I mean commit, of course :-)
Until then I can certainly patch it into my own Tomcat.  I just don't 
want to maintain this patch forever (nor have everyone else suffer 
from this bug in the AJP case).


--
Jess Holle


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

Re: Form Authentication POST data not preserved?


On 2/5/2012 11:24 AM, Jess Holle wrote:

On 2/5/2012 11:22 AM, Jess Holle wrote:

On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:

I think this issue is specific to AJP.

For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9

I think adding the following line to REQ_SET_BODY_REPLAY case in
AbstractAjpProcessor#action() will fix this bug:

endOfStream = false;


That did the trick!  [I just did this via the debugger without a 
rebuild, but same thing.]


Could someone please patch this into trunk so it's in the next Tomcat 
release?

By patch, I mean commit, of course :-)
Until then I can certainly patch it into my own Tomcat.  I just don't 
want to maintain this patch forever (nor have everyone else suffer 
from this bug in the AJP case).


Also it strikes me that maxSavePostSize should really be backed up by a 
use of a SoftReference in SavedRequest.


This would allow one to allow relatively large POST bodies to be saved 
unless/until this threatened to consume the JVM's overall memory 
resources, at which point the POST bodies could be dropped.


As it stands now one has to choose between vicious treatment of large 
POST bodies (i.e. dropping all the user's data) and opening oneself wide 
open to quick and easy (and possibly accidental) DOS attacks.


--
Jess Holle


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

Re: [somewhat OT] Form Authentication POST data not preserved?


On 2/5/2012 12:04 PM, André Warnier wrote:

Hi.

I've just been following this thread, and this is not about the 
problem per se, but a comment about the overall design of the 
application.


The fact that you do a POST without being authenticated, and that you 
rely on the server to save the POST content while the authentication 
is taking place, and to replay this POST after a succesful 
authentication, is not really a part of the HTTP protocol (as per RFC 
2616).
Form-based authentication is not part of the HTTP protocol.  The 
entirety of form-based authentication is a complete hack of an 
application convention.  Some specifications, e.g. the Java servlet 
specification, provide /some/ rules for form-based authentication within 
their realm, but in general form-based authentication is an anything 
goes that a user running an interactive browser session can follow 
convention.
It is a nice feature of Tomcat, and it simplifies the design of an 
application, and it avoids some user frustration.
And maybe the paragraph cited below from the Servlet Spec is what 
motivates Tomcat to implement this.


But I don't think tjat you can count on this behaviour with all HTTP 
servers, or all authentication schemes.  For example, if instead of 
using Tomcat's container-driven authentication (declarative security), 
your application came at some point to have to use a servlet-filter 
based authentication mechanism (programmatic security), this design 
may not work anymore (unless the filter itself had some POST-saving 
scheme).


Just thought I'd point that out.
Certainly this is an optional / quality of implementation feature.  I'm 
perfectly aware that other form-based authentication solutions will not 
save POST data and may even fail to replay requests at all.  That's fine 
and good.  The application design is not dependent on this behavior.  
Rather, Tomcat documentation says this should work and it doesn't -- 
that's the issue.


Of course this isn't just an application design issue.  If you're in 
the midst of your application, fill out a complex form, go out to lunch, 
come back and submit the form chances are good your session will have 
timed out.  In this case, you really want to have POST body capture 
working -- otherwise usability will suffer.

Servlet Spec 3.0, 13.6.3.1 :
...
If the form based login is invoked because of an HTTP request, the 
original request

parameters must be preserved by the container for use if, on successful
authentication, it redirects the call to the requested resource.
...

Note the if.

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

Re: Form Authentication POST data not preserved?


On 2/5/2012 12:22 PM, Konstantin Kolinko wrote:

2012/2/5 Jess Holle je...@ptc.com:

Also it strikes me that maxSavePostSize should really be backed up by a use
of a SoftReference in SavedRequest.

This would allow one to allow relatively large POST bodies to be saved
unless/until this threatened to consume the JVM's overall memory resources,
at which point the POST bodies could be dropped.

As it stands now one has to choose between vicious treatment of large POST
bodies (i.e. dropping all the user's data) and opening oneself wide open to
quick and easy (and possibly accidental) DOS attacks.


Interesting idea. I think it is worth filing an enhancement request.
Though I see the following caveat:

Using SoftReference here will lead to non-deterministic behaviour. I
wonder whether admins will be puzzled by this feature.  Though this
can be solved by logging an INFO message wrapped by
org.apache.juli.logging.UserDataHelper.
Yeah, there is the element of uncertainty as to how strongly a 
SoftReference really holds on to its data, etc.


This would be nice opt in behavior if nothing else.

--
Jess Holle


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

Re: [somewhat OT] Form Authentication POST data not preserved?


On 2/5/2012 2:53 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jess,

On 2/5/12 1:23 PM, Jess Holle wrote:

Certainly this is an optional / quality of implementation feature.
I'm perfectly aware that other form-based authentication solutions
will not save POST data and may even fail to replay requests at
all.  That's fine and good.  The application design is not
dependent on this behavior. Rather, Tomcat documentation says this
should work and it doesn't -- that's the issue.

FWIW, SecurityFilter also provides similar capabilities. I'd be
shocked if this wasn't industry-wide capability for servlet containers.
I was considering form-based authentication on an even broader basis -- 
as one can do this in the web server as instead of in the servlet engine.


That said, yes, most solutions do cover this base -- and Tomcat says it 
does, but doesn't if you use an AJP connector.


Fortunately the fix is trivial to patch in.

--
Jess Holle


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

Re: Form Authentication POST data not preserved?

2012-02-04 Thread Jess Holle

Yes, I'm using Tomcat authentication.  Yes, the issue is after 
authentication on the POST retry.


On 2/4/2012 12:27 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jess,

On 2/3/12 5:59 PM, Jess Holle wrote:

Or could this be getting loused up by having a servlet request
filter that calls getParameterMap() first thing?

I'd *assume* not -- as that would be pretty hokey...

Probably not: Tomcat's valves (including the one that performs
authentication) all fire before any of the webapp-specified filters
run. In any case, the problem you observe is *after* authentication
when the POST should be re-tried, right?

Silly question: you *are* using Tomcat's authentication, right? I
mean, if you're using something else like ACEGI (does that even still
exist -- other than as Spring Security?) then you'll have to look
somewhere else.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8teKEACgkQ9CaO5/Lv0PAmYwCeI0qfe5iNv/8X3z3eN4PyKtm1
6YYAoKteM140ZuIVbr9e01IP9aZf+rZq
=aUyr
-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

Form Authentication POST data not preserved?

I posted a query recently wherein I thought that POST data was being 
lost *only* if the user had been authenticated, their session timed out, 
and then they POST'ed to a URL requiring authentication -- thus having 
their request interrupted for a form-based login.


I know Tomcat is supposed to preserve the POST data in this case as well 
as in the case where one had not yet authenticated prior to the POST, 
but I'd thought that the latter case worked.


As someone nicely pointed out, that makes no sense.

So here's the issue:

Neither case works.  My POST data is always lost here.  I've tried 
various values of maxSavePostSize, including leaving it unspecified -- 
to no avail.  [I had it set to -1 and maxPostSize also set to -1, which 
I also tried leaving unspecified.]


I've tried various things -- all with no luck.

This is with Tomcat 7.0.23.  I'm pretty sure I was having similar issues 
with 7.0.25 as well.  [No, I didn't really downgrade -- I'm just working 
in a context that's still using 7.0.23 at the moment.]


I'm left wondering what could be causing the issue.

--
Jess Holle

P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me 
now.  I'll be setting this to a large but still not egregious value once 
I figure out the rest of this...


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

Re: Form Authentication POST data not preserved?


In case this makes any difference this is with the AJP BIO connector.

On 2/3/2012 4:51 PM, Jess Holle wrote:
I posted a query recently wherein I thought that POST data was being 
lost *only* if the user had been authenticated, their session timed 
out, and then they POST'ed to a URL requiring authentication -- thus 
having their request interrupted for a form-based login.


I know Tomcat is supposed to preserve the POST data in this case as 
well as in the case where one had not yet authenticated prior to the 
POST, but I'd thought that the latter case worked.


As someone nicely pointed out, that makes no sense.

So here's the issue:

Neither case works.  My POST data is always lost here.  I've tried 
various values of maxSavePostSize, including leaving it unspecified -- 
to no avail.  [I had it set to -1 and maxPostSize also set to -1, 
which I also tried leaving unspecified.]


I've tried various things -- all with no luck.

This is with Tomcat 7.0.23.  I'm pretty sure I was having similar 
issues with 7.0.25 as well.  [No, I didn't really downgrade -- I'm 
just working in a context that's still using 7.0.23 at the moment.]


I'm left wondering what could be causing the issue.

--
Jess Holle

P.S. The lack of wisdom of setting maxSavePostSize is clear enough to 
me now.  I'll be setting this to a large but still not egregious value 
once I figure out the rest of this...



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

Re: Form Authentication POST data not preserved?

Or could this be getting loused up by having a servlet request filter 
that calls getParameterMap() first thing?


I'd *assume* not -- as that would be pretty hokey...

On 2/3/2012 4:53 PM, Jess Holle wrote:

In case this makes any difference this is with the AJP BIO connector.

On 2/3/2012 4:51 PM, Jess Holle wrote:
I posted a query recently wherein I thought that POST data was being 
lost *only* if the user had been authenticated, their session timed 
out, and then they POST'ed to a URL requiring authentication -- thus 
having their request interrupted for a form-based login.


I know Tomcat is supposed to preserve the POST data in this case as 
well as in the case where one had not yet authenticated prior to the 
POST, but I'd thought that the latter case worked.


As someone nicely pointed out, that makes no sense.

So here's the issue:

Neither case works.  My POST data is always lost here.  I've tried 
various values of maxSavePostSize, including leaving it unspecified 
-- to no avail.  [I had it set to -1 and maxPostSize also set to -1, 
which I also tried leaving unspecified.]


I've tried various things -- all with no luck.

This is with Tomcat 7.0.23.  I'm pretty sure I was having similar 
issues with 7.0.25 as well.  [No, I didn't really downgrade -- I'm 
just working in a context that's still using 7.0.23 at the moment.]


I'm left wondering what could be causing the issue.

--
Jess Holle

P.S. The lack of wisdom of setting maxSavePostSize is clear enough to 
me now.  I'll be setting this to a large but still not egregious 
value once I figure out the rest of this...





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

Re: Form Authentication POST data not preserved?


On 2/3/2012 5:26 PM, Konstantin Kolinko wrote:

2012/2/4 Jess Holleje...@ptc.com:

I posted a query recently wherein I thought that POST data was being lost
*only* if the user had been authenticated, their session timed out, and then
they POST'ed to a URL requiring authentication -- thus having their request
interrupted for a form-based login.

I know Tomcat is supposed to preserve the POST data in this case as well as
in the case where one had not yet authenticated prior to the POST, but I'd
thought that the latter case worked.

As someone nicely pointed out, that makes no sense.


Why? The saved data is kept in session. If session times out (that
means: it is removed from the server) the data that was kept in it
becomes lost as well as the session itself.
Or maybe I do not quite understand you (try rephrase your statements,
listing the events in chronological order).

How's this?

Case 1:

1. Browse to (anonymously accessible) data entry form without having
   logged in yet
2. Click to POST data to authenticated result page URL
3. Fill in login form
4. See result page

Case 2:

1. Log in
2. Browse to data entry form (anonymous or otherwise)
3. Allow session to time out (or force this on the server)
4. Click to POST data to authenticated result page URL
5. Fill in login form
6. See result page

I'd expect to see the results in both cases reflect the POST data.

Initially I had thought that Case #1 worked but Case #2 didn't.  That 
makes no sense -- as others pointed out.


Now I see that neither case works.

--
Jess  Holle

Tomcat Form Authentication Timeout Behavior

2012-02-01 Thread Jess Holle

I've noticed that if I POST to an authenticated URL in a web app 
configured for form-based authentication, Tomcat delivers the login 
form, and then replays the POST just fine *unless* the current state of 
the browser is one where I had already been authenticated but that 
session had timed out.  In that case, Tomcat fails to deliver the POST data.


I assume this is a known issue/limitation.  If not, is there some 
configuration setting I'm missing or some such?  This is with Tomcat 7.0.23.


--
Jess Holle


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

Re: ThreadLocals, context listeners and classloader leaks

2012-01-26 Thread Jess Holle


On 1/26/2012 10:38 AM, Mark Thomas wrote:

OK. ThreadLocals have no place in a web application. Period. If a
programmer insists on using them, then it is their responsibility to
clean up the mess they leave behind.

Tomcat's memory leak detection and prevention code goes some way to
clearing up things like this but it is never going to cover every case.

Mark

Or put another way, you have a choice:

1. Use ThreadLocals the way you'd have assumed you could, but don't
   expect to ever restart your web app without leaking tons of memory.
2. Use ThreadLocals, but be sure you religiously clean up after
   yourself by the time your web app is fully shut down.
3. Don't use ThreadLocals.

If you use someone else's library that uses ThreadLocals then you'll 
probably end up in forced into A.


That said, there could and arguably should be another choice:

4. Select a special mode in a servlet engine that shuts down all
   threads that have ever serviced requests for a given web app when it
   is shutdown (and code your web app to shutdown any threads it
   creates, obviously!), e.g. after they complete servicing any request
   in progress.  [It could just replace all request threads with new
   ones after the requests currently in progress complete.]

That's assuming the servlet engine is nice enough to provide such a 
mode.  If it did, however, I believe that would resolve any ThreadLocal 
issues without one having to avoid using a perfect natural and useful 
Java language feature.  I'd argue all servlet engines should really 
provide this feature for just this reason.  That said, I can live with A.


--
Jess Holle

Re: Form Authentication vs. Tomcat Restart

I should have noted that this is with Tomcat 7.0.23, but it seemed 
unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific.


Of course given that I found that the documentation clearly states this 
behavior, I suspect this is longstanding Tomcat behavior.


My remaining question is /why/ Tomcat behaves this way.  If one quickly 
restarts Tomcat for some reason and session data is preserved, you 
really don't want all the users to have to login again do you?


--
Jess Holle

On 12/6/2011 7:05 PM, André Warnier wrote:

Jess Holle wrote:
When doing a graceful shutdown of Tomcat, the sessions are persisted 
to disk and then re-read on startup (at least in all reasonably 
recent versions).


Oddly, however, form-based authentication does not seem to survive a 
graceful restart.  Rather one has to log in again.  Is this known?  
Intentional?  Configurable?



There should be a template for messages on this list :

Tomcat version :
Java version :
platform OS  version :


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

Re: Form Authentication vs. Tomcat Restart


Yes, I now note this in the documentation.

The question remains, however: /why /does it work this way?

On 12/7/2011 6:34 AM, Mohammad M. AbuZer wrote:

Tomcat does that for every all Form Authentication even if you used
`DatabaseRealm` it doesn't save logged user.

On Wed, Dec 7, 2011 at 2:24 PM, Jess Holleje...@ptc.com  wrote:


I should have noted that this is with Tomcat 7.0.23, but it seemed
unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific.

Of course given that I found that the documentation clearly states this
behavior, I suspect this is longstanding Tomcat behavior.

My remaining question is /why/ Tomcat behaves this way.  If one quickly
restarts Tomcat for some reason and session data is preserved, you really
don't want all the users to have to login again do you?

--
Jess Holle


On 12/6/2011 7:05 PM, André Warnier wrote:


Jess Holle wrote:


When doing a graceful shutdown of Tomcat, the sessions are persisted to
disk and then re-read on startup (at least in all reasonably recent
versions).

Oddly, however, form-based authentication does not seem to survive a
graceful restart.  Rather one has to log in again.  Is this known?
  Intentional?  Configurable?

  There should be a template for messages on this list :

Tomcat version :
Java version :
platform OS  version :


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

Any servlet API event to denote change in session id

I note that in recent versions of Tomcat (e.g. 7.0.23), the session id 
changes when you do a form-based authentication.


I do not see any sort of notice via anything one can listen to via the 
servlet API to receive notice of this change.


This makes things rather ugly if one is monitoring the sessions oneself 
-- as their identity changes out from under you without any notice.


Am I missing something here?  [Yes, I note the container event, but that 
necessitates Tomcat-specific code, etc -- especially given that this 
isn't fired as a JMX notification anywhere that I can see.]


--
Jess Holle


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

Re: Any servlet API event to denote change in session id


On 12/7/2011 11:47 AM, Mark Thomas wrote:

On 07/12/2011 17:04, Jess Holle wrote:

I note that in recent versions of Tomcat (e.g. 7.0.23), the session id
changes when you do a form-based authentication.

I do not see any sort of notice via anything one can listen to via the
servlet API to receive notice of this change.

This makes things rather ugly if one is monitoring the sessions oneself
-- as their identity changes out from under you without any notice.

Am I missing something here?  [Yes, I note the container event, but that
necessitates Tomcat-specific code, etc -- especially given that this
isn't fired as a JMX notification anywhere that I can see.]

No, you aren't missing anything.

Note the session object does not change, just the value returned for the ID.

This will hopefully get fixed in Servlet 3.1

Your other option is to turn off the session fixation protection (not
recommended).
Thanks.  I have a request listener and can use it to notice session id 
changes by the end of a request at least, update all my tracking data, 
and log the occurrence for interested parties.  It's a little later in 
the scheme of things than I'd like, but efficient enough.


--
Jess Holle


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

Re: Form Authentication vs. Tomcat Restart


You get an error when that's what's occurring, though.

On 12/7/2011 12:55 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jess,

On 12/6/11 6:17 PM, Jess Holle wrote:

Okay, I now notice this plainly stated in the documentation for
JNDIRealm (which I'm using):

The cached user is *not* saved and restored across sessions
serialisations.

That seems a bit odd...

I wouldn't think that should be a problem: subsequent requests (after
a restart) should re-create whatever data are necessary.

We used to have this problem, and it turned out that we had a few
objects in the session that were serializable yet still not
un-serializable (because they didn't have no-arg constructors, for
instance).

Is it possible you are having a problem like that?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7ftpgACgkQ9CaO5/Lv0PAxJgCfW8G91XwwLTiUAXoYO16NCojL
aNUAoLysh1BGs942flGrKpVv1i40AsPN
=zzm/
-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

Form Authentication vs. Tomcat Restart

2011-12-06 Thread Jess Holle

When doing a graceful shutdown of Tomcat, the sessions are persisted to 
disk and then re-read on startup (at least in all reasonably recent 
versions).


Oddly, however, form-based authentication does not seem to survive a 
graceful restart.  Rather one has to log in again.  Is this known?  
Intentional?  Configurable?


--
Jess Holle


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

Re: Form Authentication vs. Tomcat Restart

2011-12-06 Thread Jess Holle

Okay, I now notice this plainly stated in the documentation for 
JNDIRealm (which I'm using):


   The cached user is *not* saved and restored across sessions
   serialisations.

That seems a bit odd...

On 12/6/2011 5:12 PM, Jess Holle wrote:
When doing a graceful shutdown of Tomcat, the sessions are persisted 
to disk and then re-read on startup (at least in all reasonably recent 
versions).


Oddly, however, form-based authentication does not seem to survive a 
graceful restart.  Rather one has to log in again.  Is this known?  
Intentional?  Configurable?


--
Jess Holle

Re: Form Authentication and status (response) code

2011-09-01 Thread Jess Holle

That's the unfortunate way of form-based authentication.  It's an 
application convention rather than a protocol-level standard -- it's not 
a standard but rather a loose convention and has to be handled by the 
application code rather than seamlessly with at protocol handling level.


As such it's fine and good for consumption by interactive user sessions 
in a web browser -- as users can grok conventions just fine unless 
they're horrifically convoluted.


Unfortunately, for any other form of client (e.g. a programmatic, 
non-interactive service in the extreme case or even an interactive 
client that is not browser based but rather is written against some HTTP 
client library or another) form-based authentication is a royal mess.


It would be a lot better if form-based authentication standardized 
around returning a 401 -- ideally with some header information as to how 
to proceed to respond to the challenge.


Unfortunately, responding with a 401 is not really legal here and indeed 
results in bad behavior from some HTTP client libraries (e.g. that built 
into Java, for instance).


So form-based authentication is an obnoxious mutt -- but a mutt that 
everyone seems to have fallen in love with.


This isn't Tomcat's fault, however, and Tomcat is doing the normal thing 
by returning a 200 here.


As for tricks to see if your 200 isn't really a 200, you can:

1. Check the response Content-Type if the expected Content-Type isn't
   one that could possibly be used by a login form or
2. Add some other custom header to your response.  If it's not there
   but you got a 200, then something hijacked the response -- quite
   probably a login form.

--
Jess Holle

On 9/1/2011 5:49 PM, Mabry Tyson wrote:
Summary: When requiring form authentication, Tomcat responds to an 
unauthenticated GET request with a HTTP status code of 200 (OK) and 
the login page.

I believe that to be in violation of the HTTP standards.

The problem:  Software makes a GET request to a web server.  It gets 
back a 200 status code.  By RFC 2616, that code indicates the request 
has succeeded.
The software then takes the resulting page as the successful response 
to the GET request.   However, in some cases this response is NOT a 
successful response

but is instead a login form.

By using a 200 status code, Tomcat is misrepresenting that the login 
form is the response to the request.   My believe is a 4xx code 
(client error) is appropriate, or possibly a 3xx code (Redirection) 
might be appropriate.  Unfortunately, the RFC indicates that a 401 
(Unauthorized) response MUST have a header that is only appropriate 
for basic or digest authentication.  So a status code of 401 is not 
legal in this situation.


It seems unlikely that I'm the first to comment on this.  It must have 
been discussed extensively before.   Can anyone tell me
  (1) What is the reason behind saying the login form is a successful 
response?

  (2) Where is a pointer to the discussions?
  (3) What is an appropriate (non-ad hoc) way to determine that Tomcat 
is returning a login form rather than the requested resource?


(I have done a quick search of the Internet, of Tomcat FAQ, and of 
outstanding Tomcat bugs, but didn't find this.)



For instance, here are the headers when doing a GET of a login 
protected page from the examples shipped with Tomcat:


 GET /examples/jsp/security/protected/index.jsp HTTP/1.1
 User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 
OpenSSL/0.9.8r zlib/1.2.3

 Host: xxx.example.com
 Accept: */*

 HTTP/1.1 200 OK
 Server: Apache-Coyote/1.1
 Pragma: No-cache
 Cache-Control: no-cache
 Expires: Wed, 31 Dec 1969 19:00:00 EST
 Set-Cookie: JSESSIONID=99FD7582647EEF539C449AEBBA5365EB; Path=/examples
 Content-Type: text/html
 Content-Length: 1413
 Date: Thu, 01 Sep 2011 22:15:29 GMT

while the content starts with
html
head
titleLogin Page for Examples/title
body bgcolor=white
form method=POST 
action='j_security_check;jsessionid=99FD7582647EEF539C449AEBBA5365EB' 



P.S.  For anyone maintaining the examples, shouldn't vendor examples 
demonstrate the best practices?  I'd suggest you indicate the 
Content-Type and the charset.
Also, it would be handy if the web.xml showed how to have the login 
page be served up by https (along with a note explaining that you 
don't do it here since you don't know that https willl be available).




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

Re: Slower start with Tomcat 7.0.14 and higher


On 6/22/2011 9:08 AM, Mark Thomas wrote:

Another issue is that WEB-INF/lib is visible to the parent classloader
embedding Tomcat and to Tomcat as part of the web application and thus
I'm probably getting double scanning -- though really Tomcat should be
avoiding this by detecting that the same jar file is involved in both
cases.  The reasons for the duplication in this classpath are long and
historic.  Overall I'd rather not try to unwind this now.  I'd
hope/assume that an annotation on a class, e.g. a filter annotation,
would only result in one filter instance irrespective of how many times
that class is visible to the classloader(s) in question.

That sounds like it might cause trouble. Classes are identified by the
combination of name and class loader so the same class loaded in two
different class loaders is treated as a different class. If both the web
application class loader and its parent class loader can see WEB-INF/lib
I can image all sorts of things may go wrong.
Well the classloaders are clearly hierarchical, so only one Class 
instance is loaded.  The fact that both ClassLoaders can see the jar 
does not result in 2 Class objects -- nor should it result in an 
annotation being applied multiple times.  The jars are in fact exactly 
the same here -- as one of the web app's WEB-INF/lib directories is 
visible to the parent classloader.  It may be possible to move the jars 
somewhere else so that they're only part of the parent classloader, but 
that will require more reshuffling of the longstanding configuration.

Given that the JNDI node maps to a file if the web app is expanded -- as
mine always is (being deployed originally as an expanded directory in
.war layout not as a .ware archive), it seems there should be a back
door for Tomcat to notice this and simply use the file location to
begin with rather than doing any extra temporary file shenanigans in any
case.  The JNDI wrapping is nice and all, but shouldn't cause a
substantially sub-optimal performance approach when it is clear enough
how to attain the appropriate File object.

It should be doing that already. I'll double check

Is there any danger -- other than worse performance in use cases I don't
have -- in me patching my own Tomcat to always use FileUrlJar?  Should
this perhaps be a config option?  Or possibly a config option based on
file size?  [FileUrlJar may only be faster for larger jars from what
little I know...]

That local patch should be safe. In terms of config, I'd like to keep
this as automated as possible. More research required.

For reference, how big are the JAR files we are talking about here?

They range in size from 48K to 46MB.  Only 3 jars are over 25MB in size.

--
Jess Holle

Re: Slower start with Tomcat 7.0.14 and higher


On 6/22/2011 10:16 AM, Jess Holle wrote:

On 6/22/2011 9:08 AM, Mark Thomas wrote:

Another issue is that WEB-INF/lib is visible to the parent classloader
embedding Tomcat and to Tomcat as part of the web application and thus
I'm probably getting double scanning -- though really Tomcat should be
avoiding this by detecting that the same jar file is involved in both
cases.  The reasons for the duplication in this classpath are long and
historic.  Overall I'd rather not try to unwind this now.  I'd
hope/assume that an annotation on a class, e.g. a filter annotation,
would only result in one filter instance irrespective of how many times
that class is visible to the classloader(s) in question.

That sounds like it might cause trouble. Classes are identified by the
combination of name and class loader so the same class loaded in two
different class loaders is treated as a different class. If both the web
application class loader and its parent class loader can see WEB-INF/lib
I can image all sorts of things may go wrong.
Well the classloaders are clearly hierarchical, so only one Class 
instance is loaded.  The fact that both ClassLoaders can see the jar 
does not result in 2 Class objects -- nor should it result in an 
annotation being applied multiple times.  The jars are in fact exactly 
the same here -- as one of the web app's WEB-INF/lib directories is 
visible to the parent classloader.  It may be possible to move the 
jars somewhere else so that they're only part of the parent 
classloader, but that will require more reshuffling of the 
longstanding configuration.
I increased the verbosity for the StandardJarScanner logger.  Based on 
that output everything appears ok for our use case.  The only duplicated 
jars we have are in WEB-INF/lib which is already automatically ignored 
when scanning the classpath.


The only issue I found at this level is that both 
tomcat-juli-adapters.jar and tomcat-juli-adapters.jar are scanned.  I'd 
think that all the Tomcat extras jars should be in Tomcat's 
out-of-the-box list of jars to be ignored -- unless they actually 
shouldn't be ignored, of course.  That's a rather minor issue, though -- 
and presumably accounts for very, very little of the startup time.


--
Jess Holle

Re: Slower start with Tomcat 7.0.14 and higher

Since delegation is downwards the only issue that should possibly occur 
is if a class gets loaded in the parent classloader that then needs a 
class in the child (e.g. web app) classloader.  That will fail, of 
course, but that's ok as this should never occur.

On 6/22/2011 12:27 PM, Caldarale, Charles R wrote:

From: Jess Holle [mailto:je...@ptc.com]
Subject: Re: Slower start with Tomcat 7.0.14 and higher
Well the classloaders are clearly hierarchical, so only one Class
instance is loaded.  The fact that both ClassLoaders can see the jar
does not result in 2 Class objects

I think we need some experimentation (or browsing through some really ugly C++ 
code in the JVM) to verify the above.  I have a vague memory of the class 
dependency resolution being routed through the classloader of the class with 
the dependency, not the thread's current classloader, thus avoiding downward 
pointer issues.  However, since I've been looking at JVM code since 1.2 days, I 
can't be sure that's the way it works today without doing some more homework.

If dependency resolution does work the way I remember, then it would be 
possible for the same .class file to be processed by different classloaders in 
your environment.

  - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

Re: Slower start with Tomcat 7.0.14 and higher


On 6/22/2011 12:44 PM, Caldarale, Charles R wrote:

I think it can happen, without detection, if you have the same class directly 
visible to multiple classloaders - which I recall that you do (but perhaps I 
misunderstood this statement: the base classloader includes a lot more than 
CATALINA_BASE/lib.  Some of these jars are huge -- and the intent (and effect) is 
that these are shared by
any/all web app instances.).

So before pursuing this any further, is the same class visible to more than one 
classloader in your environment?  If not, then there should be no problem, 
regardless of internal classloader logic.
Overall I'm pretty confident that things are okay here -- especially as 
we've been using and testing this configuration for quite some time now.


--
Jess Holle


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

Re: Slower start with Tomcat 7.0.14 and higher

2011-06-21 Thread Jess Holle

If I alter JarFactory to always use FileUrlJar, then my startup is 
around 20 seconds faster, i.e. the speed is fully back to that of 7.0.12.


It turns out the issue is the large jars I have in my WEB-INF/lib 
directory -- and FileUrlJar is still much faster in this case than using 
UrlJar even with a JNDI URL.


Another issue is that WEB-INF/lib is visible to the parent classloader 
embedding Tomcat and to Tomcat as part of the web application and thus 
I'm probably getting double scanning -- though really Tomcat should be 
avoiding this by detecting that the same jar file is involved in both 
cases.  The reasons for the duplication in this classpath are long and 
historic.  Overall I'd rather not try to unwind this now.  I'd 
hope/assume that an annotation on a class, e.g. a filter annotation, 
would only result in one filter instance irrespective of how many times 
that class is visible to the classloader(s) in question.


Given that the JNDI node maps to a file if the web app is expanded -- as 
mine always is (being deployed originally as an expanded directory in 
.war layout not as a .ware archive), it seems there should be a back 
door for Tomcat to notice this and simply use the file location to 
begin with rather than doing any extra temporary file shenanigans in any 
case.  The JNDI wrapping is nice and all, but shouldn't cause a 
substantially sub-optimal performance approach when it is clear enough 
how to attain the appropriate File object.


Is there any danger -- other than worse performance in use cases I don't 
have -- in me patching my own Tomcat to always use FileUrlJar?  Should 
this perhaps be a config option?  Or possibly a config option based on 
file size?  [FileUrlJar may only be faster for larger jars from what 
little I know...]


--
Jess Holle


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

Slower start with Tomcat 7.0.14 and higher

Start up takes around 20 seconds longer with Tomcat 7.0.14 and 7.0.16 
than it did with 7.0.12.


This appears to be due to time spent scanning jars for annotations, 
etc.  We have a number of /very /large jar files in both the base 
classloader for Tomcat (which we're embedding) and in our web apps.


This raises 2 questions:

  1. Was jar scanning not working for such uses cases in 7.0.12, e.g.
 was the scanning incomplete?
  2. Did something change to make the performance of the scanning
 perform much worse in 7.0.14 /and /7.0.16 than in 7.0.12?
 * The release notes suggest that 7.0.14 had an issue and that
   it was resolved in 7.0.16, but we're seeing both 7.0.14 and
   7.0.16 being approximately equally slow to start up.

Clearly the answer to both questions could be yes.  If only #2 is a 
yes, then I'd really like to get this resolved and get back to the 
previous performance.  If, however, #1 explains much of the degradation, 
then I'll need to look into excluding jars from scanning, etc.


--
Jess Holle

Re: Slower start with Tomcat 7.0.14 and higher


On 6/20/2011 2:16 PM, Mark Thomas wrote:

It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
to the pre 7.0.14 performance levels.
We're embedding Tomcat in a larger server process and the base 
classloader includes a lot more than CATALINA_BASE/lib.  Some of these 
jars are huge -- and the intent (and effect) is that these are shared by 
any/all web app instances.


My initial guess is that the 7.0.16 fix may have overlooked this 
possibility and be special-cased for jars in CATALINA_BASE/lib vs. 
applying to any jar coming from the base classloader and a file: (vs. 
HTTP or JNDI) URL.

It looks like there may still be an issue. Profiling data on where the
time is being spent would be useful.

I should be able to drum up such a profile here in a bit...

--
Jess Holle

Re: Slower start with Tomcat 7.0.14 and higher


On 6/20/2011 2:41 PM, Jess Holle wrote:

On 6/20/2011 2:16 PM, Mark Thomas wrote:

It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
to the pre 7.0.14 performance levels.
We're embedding Tomcat in a larger server process and the base 
classloader includes a lot more than CATALINA_BASE/lib.  Some of these 
jars are huge -- and the intent (and effect) is that these are shared 
by any/all web app instances.


My initial guess is that the 7.0.16 fix may have overlooked this 
possibility and be special-cased for jars in CATALINA_BASE/lib vs. 
applying to any jar coming from the base classloader and a file: (vs. 
HTTP or JNDI) URL.

It looks like there may still be an issue. Profiling data on where the
time is being spent would be useful.

I should be able to drum up such a profile here in a bit...
There's a lot more data in the profile than I really want to post/share, 
but with heavy/frequent (20ms) VisualVM sampling profiler overhead, I 
see that ~31 seconds are spent on ContextConfig.webConfig() -- mostly in 
ContextConfig.processAnnotations(), etc.  I also see ~8 seconds spent on 
TldConfig.execute().  The numbers are clearly inflated from the original 
metrics due to the crude sampling approach, but the overhead is clearly 
in these areas.


--
Jess Holle

Re: Slower start with Tomcat 7.0.14 and higher


On 6/20/2011 3:16 PM, Rainer Jung wrote:

Sure we want to make scaning as fast as possible. But did you realize,
that you can exclude Jars from being scanned? There's a list f
exclusions defined in catalina.properties.
Yes -- and I'll go there is the speed from 7.0.12 (which was quite 
reasonable despite scanning all our jars) cannot be re-attained.


I might go there anyway for *some* of our jars, but I will likely want 
to start doing more via annotations and less via web.xml as well -- and 
would like to minimize the startup performance penalty entailed in doing so.


--
Jess Holle


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

Re: Slower start with Tomcat 7.0.14 and higher


On 6/20/2011 4:35 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jess,

On 6/20/2011 3:41 PM, Jess Holle wrote:

On 6/20/2011 2:16 PM, Mark Thomas wrote:

It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
to the pre 7.0.14 performance levels.

We're embedding Tomcat in a larger server process and the base
classloader includes a lot more than CATALINA_BASE/lib.  Some of these
jars are huge -- and the intent (and effect) is that these are shared by
any/all web app instances.

Couldn't you place the libraries in question at a level /higher/ than
Tomcat's base ClassLoader? Or, do you need some of those libraries to be
scanned for annotations but not all.

Maybe you could move /some/ of them?
The libraries in question are actually loaded by the application 
classloader -- as is Tomcat's Bootstrap class.


And, yes, eventually I'll want to scan some of these jars for 
annotations -- but not all unless this is really fast/cheap.


--
Jess Holle


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

Re: Slower start with Tomcat 7.0.14 and higher


On 6/20/2011 5:05 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jess,

On 6/20/2011 5:47 PM, Jess Holle wrote:

On 6/20/2011 4:35 PM, Christopher Schultz wrote:

Maybe you could move /some/ of them?

The libraries in question are actually loaded by the application
classloader -- as is Tomcat's Bootstrap class.

Application being that which embeds Tomcat, or the webapp(s) eventually
deployed by Tomcat? ;)

The embedding application, i.e. the system classloader.

--
Jess Holle


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

Re: how to track tomcat throughput?

2011-05-18 Thread Jess Holle


I've done a servlet request filter for this and many other such things.

I've always been a bit surprised by how little of this data Tomcat 
collects -- but that's fine as one can do a servlet request filter that 
will work in any servlet engine and collect everything you want.


That said, collecting some of this information becomes a lot more 
challenging with asynchronous requests, which is something I've not yet 
tackled.  For instance, it's easy to track the CPU usage for each 
synchronous request (obviously from the servlet filter on down in the 
call stack, not counting the Tomcat calls before/after this), but not so 
easy for an asynchronous request...


--
Jess Holle

On 5/18/2011 6:31 AM, Dan Checkoway wrote:

I've messed around a bit, and I figured out a more reliable way to do
it...but it's pretty nasty.  Basically I'm iterating and grabbing the
requestCount attribute from all of the RequestProcessor mbeans, and just
tallying them up.

Like I said, it's nasty, since you need to know the max possible # of
RequestProcessor beans, there are gaps in the sequence, etc.  I'm hoping
there's an easier way to get just a single JMX-exposed attribute
representing total requestCount.

Possible?  Wish list item...open a bugzilla ticket?  Bueller...Bueller...?
:-)

Dan

On Tue, May 17, 2011 at 4:22 AM, Dan Checkowaydchecko...@gmail.com  wrote:


I'm looking for advice on the most reliable  efficient way to track tomcat
throughput...preferably via JMX.  I've written a simple app that uses JMX to
grab the completedTaskCount attribute on the Executor.  My assumption was
that the Executor's completedTaskCount would be a fairly accurate way to
watch, in real-time, the number of HTTP requests served...and a heck of a
lot simpler than just counting access log lines.  Basically the app grabs
the completedTaskCount every 10 seconds and does a simple how many more
since the last time I checked rate calculation.

But what I think I'm seeing is that the Executor's completedTaskCount grows
at a rate higher than the actual number of HTTP requests being served.  So
I'm wondering...is a shared Executor being used for purposes other than just
serving requests, and if so, what other types of tasks are being executed?

Is there any other attribute exposed by JMX that might be a more reliable
way of counting actual HTTP requests served?  Is there a simpler way of
accomplishing the same goal that doesn't involve access log analysis?

Thanks,
Dan




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

General Async Request Question

2011-05-17 Thread Jess Holle

I'm trying to get up to speed with the Servlet 3.0 specification -- 
specifically asynchronous requests vs. all my existing filters, etc.


I have an existing response compression filter.  Yes, I know Tomcat's 
HTTP connector can do this, but our filter has some special features, 
works with the AJP connector (which we use), and works with other 
servlet engines besides Tomcat.


Part of the existing logic is:

final GzippingResponse  gzippingResponse = new GzippingResponse( 
origHttpRequest, origHttpResponse );
try
{
  filterChain.doFilter( origRequest, gzippingResponse );
  gzippingResponse.finish();
}
finally
{
  gzippingResponse.end();
}

where finish() calls ServletResponse.flushBuffer() and 
GZIPOutputStream.finish() and end() calls Deflator.end() to do timely 
release of resources.


My issue here is how can I ensure that gzippingResponse.finish() is 
called prior to the response stream being closed but after all calls 
writes to the response?  AsyncContext.complete() sounds like it closes 
the output streams/sockets and *then* calls the completion listeners.  
Is this simply a misunderstanding on my part or is there some other 
means for a filter to interject itself between the final write to a 
response and stream/socket closure?


--
Jess Holle


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

Re: Multiple context paths for single deployment

2011-05-13 Thread Jess Holle


Hmm

In Tomcat versions up through 6.0, I have cases where I have 1 expanded 
WAR directory (outside Tomcat's webapps, etc) and then numerous 
disparate Context XML files under Tomcat/conf, each with their own 
overrides to the original web.xml (e.g. each getting their own data 
sources, JNDI env values, context name, etc).


It was my understanding that the web.xml override capability of Context 
was broken in Tomcat 7 (and/or the most recent Tomcat 6??) -- at least 
for a while, hopefully this has been fixed.


Otherwise, however, this seems to work nicely -- 1 deployment, 'n' URLs 
with 'n' disparate context paths.  It does, of course, load 'n' copies 
of all the JSPs, etc, etc -- so there's definitely some downside in 
terms of overhead.  It is a quick and dirty way to deploy numerous 
instances of a web app which has unfortunate singletons, e.g. data 
sources, where you belatedly discover you want a cardinality of 'n' 
rather than 1.


--
Jess Holle

On 5/13/2011 8:56 AM, Caldarale, Charles R wrote:

From: JanAa [mailto:jan.aage...@norse-solutions.com]
Subject: Re: Multiple context paths for single deployment
What I want is an alias for the context so that more than
one url can be used for the same application and that the
url used is reflected in HttpServletRequest.getContextPath().

Those are conflicting requirements.  Pick one or the other - you can't have 
both.

(Actually, you can, but it would be a major pain.  If you wrote a filter that 
wrapped every HttpServletRequest object and implemented your own 
getContextPath() method, you could choose to return whatever you want for the 
result.)

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
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: Async servlets and Tomcat 7 vs. mod_jk

2011-05-03 Thread Jess Holle


On 5/3/2011 3:18 AM, Mark Thomas wrote:

As I write this it occurs to me that an AJP-NIO connector would be a big
help to you here. I don't know how much work that would be to write but
with the refactoring already completed for Tomcat 7 it might be as
little as 1000 lines of code. If you would be interested in such a
connector create an enhancement request in Bugzilla.
That would almost certainly be the biggest help to me, yes.  While I 
have nothing against Apache HTTPD or APR in theory, in practice native 
builds (and bugs) across numerous platforms are just too much to deal with.

In Apache, I note that there are noises about broader/better support for
the mod_event MPM worker.  Does mod_jk work with mod_event there to
reduce the threads required in Apache?

Sorry, don't know. I have relatively little to do with the native mod_jk
code.
Thanks.  I was hoping someone on this list could answer (Mladen?), but 
realize there are relatively few involved in mod_jk code.


--
Jess Holle

Re: Async servlets and Tomcat 7 vs. mod_jk

2011-05-03 Thread Jess Holle


On 5/3/2011 6:14 AM, Jess Holle wrote:

On 5/3/2011 3:18 AM, Mark Thomas wrote:

As I write this it occurs to me that an AJP-NIO connector would be a big
help to you here. I don't know how much work that would be to write but
with the refactoring already completed for Tomcat 7 it might be as
little as 1000 lines of code. If you would be interested in such a
connector create an enhancement request in Bugzilla.
That would almost certainly be the biggest help to me, yes.  While I 
have nothing against Apache HTTPD or APR in theory, in practice native 
builds (and bugs) across numerous platforms are just too much to deal 
with.

Bug 51145 https://issues.apache.org/bugzilla/show_bug.cgi?id=51145 filed.

--
Jess Holle

Re: Async servlets and Tomcat 7 vs. mod_jk

2011-05-03 Thread Jess Holle


On 5/3/2011 2:55 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 5/3/2011 4:18 AM, Mark Thomas wrote:

In Apache, I note that there are noises about broader/better support for
the mod_event MPM worker.  Does mod_jk work with mod_event there to
reduce the threads required in Apache?

Sorry, don't know. I have relatively little to do with the native mod_jk
code.

I'm also not sure about mod_jk support for mod_event, but at ApacheCon
one of the presenters said that httpd 2.4 will have the event MPM as the
default.

Given that, looking to get mod_jk working well with the event MPM sounds
like a good thing for us to do.
If mod_event is going to be the default, then ensuring mod_jk works well 
with it sounds like a rather critical thing to do.


--
Jess Holle


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

Async servlets and Tomcat 7 vs. mod_jk

2011-05-02 Thread Jess Holle

What are the limitations/requirements of using asynchronous servlets in 
Tomcat 7?


We use Apache and mod_jk to balance load over multiple Tomcats.  I note 
that there is no NIO AJP connector -- only BIO and APR.  I have /no 
/interest in the native APR connectors -- as it's simply /*far* /too 
painful to produce 7 different native builds of this (some on platforms 
with unbelievably horrific linkers).


What does this mean for us?  Does this mean asynchronous servlets won't 
work for us?  Or that they'll work, but we won't actually reduce the 
thread usage in Tomcat at all?


In Apache, I note that there are noises about broader/better support for 
the mod_event MPM worker.  Does mod_jk work with mod_event there to 
reduce the threads required in Apache?


--
Jess Holle

RE: mod_jk / AJP and compression

2011-04-01 Thread Holle, Jess

If you want compression here, then just do it in a servlet filter based on 
Accept-Encoding thus resulting in compression in Tomcat and the stream 
remaining compressed all the way to the client.

From: Mark Thomas [mailto:ma...@apache.org]
Sent: Fri 4/1/2011 5:20 AM
To: Tomcat Users List
Subject: Re: mod_jk / AJP and compression

On 01/04/2011 11:15, John Baker wrote:
 Hello,

 The Tomcat AJP Connector does not support compression. Why has this been
 ommitted?

Because the link between Tomcat and reverse proxy will nearly always
have significantly more capacity than the link between the client and
the reverse proxy. Adding compression gains very little but adds delay
and increases CPU usage.

Mark

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

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

Re: OT: a good jmx browser?

2011-03-14 Thread Jess Holle

Or for a somewhat better UI and more capability overall, VisualVM.  
[Note that VisualVM's MBean tree is via a plug-in, so you need to 
install the plug-in before you get this functionality.]


On 3/14/2011 2:42 PM, Leon Rosenberg wrote:

thanx guys.
Leon

On Mon, Mar 14, 2011 at 11:34 AM, Mikolaj Rydzewskim...@ceti.pl  wrote:

On Mon, 14 Mar 2011 11:28:58 +0100, Leon Rosenberg
rosenberg.l...@gmail.com  wrote:


sorry for the off-topic-ness, but what jmx browser are you guys using if
any.
By jmx browser i mean something with a GUI where I can enter my
server's adress and click through the tree of available values.

jconsole

--
Mikolaj Rydzewskim...@ceti.pl

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



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





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

Re: OT: a good jmx browser?

2011-03-14 Thread Jess Holle

If you use a recent version of Java 6 both jconsole and VisualVM come 
with the JDK (at least in most cases -- VisualVM does not run on or come 
with IBM's JVM).


On 3/14/2011 2:55 PM, Jess Holle wrote:
Or for a somewhat better UI and more capability overall, VisualVM.  
[Note that VisualVM's MBean tree is via a plug-in, so you need to 
install the plug-in before you get this functionality.]


On 3/14/2011 2:42 PM, Leon Rosenberg wrote:

thanx guys.
Leon

On Mon, Mar 14, 2011 at 11:34 AM, Mikolaj Rydzewskim...@ceti.pl  
wrote:

On Mon, 14 Mar 2011 11:28:58 +0100, Leon Rosenberg
rosenberg.l...@gmail.com  wrote:

sorry for the off-topic-ness, but what jmx browser are you guys 
using if

any.
By jmx browser i mean something with a GUI where I can enter my
server's adress and click through the tree of available values.

jconsole

--
Mikolaj Rydzewskim...@ceti.pl

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



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







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

Re: JSP class size increase in Tomcat 7

2011-03-12 Thread Jess Holle


On 3/11/2011 6:04 AM, Jess Holle wrote:

On 3/11/2011 3:22 AM, Mark Thomas wrote:

The obvious difference is that Tomcat 6 compilation targets Java 5
whereas Tomcat 7 targets Java 6. For a simple test JSP:
Tomcat 6 (1.5) - 3,488
Tomcat 7 (1.5) - 3,530 +1%
Tomcat 7 (1.6) - 3,668 +6%

The 1% will be a combination of:
- Tomcat 7 uses version 3.6 of the Eclipse compiler while Tomcat 6 uses
3.3.1.
- the source code differences you can see in the .java files.

Hmm

I tried forcing 1.5 as the source/target version for JspC -- I'm still 
over 65K with Tomcat 7.


I wonder if there's enough extra hidden code generated by use of 
generics...


Anyway, I guess the page owners will have to try to clean things up.
Is it possible that the source/target version is being ignored, e.g. for 
the Ant task form of JspC?


I ask as javac fails to compile the Java code generated by jasper as 
well for the same reason -- the _jspService method is too big.  When I 
force 1.5 as the target and source version, however, javac compiles the 
generated Java code just fine.


When I try the same trick with my precompilation Ant script, however, ala

jasper2 uriroot=${docBaseLocation} 
classpath=${wcWebAppClasspathAsString}
 compile=true outputDir=${outputDir}
 classDebugInfo=true smapSuppressed=${smapSuppressed}
 compilerSourceVM=1.5 compilerTargetVM=1.5
 validateXml=false listErrors=true
 verbose=${jspcVerbosityLevel} jspFiles=${jspFileList}/

I still get the same failure, which seems rather odd.  You'd think that 
JDT/EJC can't be generating that much larger code than javac.


--
Jess Holle


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

Re: JSP class size increase in Tomcat 7

2011-03-12 Thread Jess Holle

Nevermind -- I examined other classes produced with 1.5 specified.  
These were compiled for 1.5 (version 49.0 byte code).


On another ugly JSP, I note:

   * Tomcat 6 - JDT targeting 1.5: 93K
   * Tomcat 7 - JDT targeting 1.6: 149K
   * Tomcat 7 - JDT targeting 1.5: 133K
   * Tomcat 7 - javac (externally from command line) targeting 1.6: 118K
   * Tomcat 7 - javac (externally from command line) targeting 1.5: 68K
   * Tomcat 7 - JDT targeting 1.5 with debug off and smap suppressed: 68K

Clearly there's normally extra expense for debug/smap information, 
though it's not clear to me whether this works against the 65K limit or not.


Note the last 2 results are essentially identical (I didn't compare byte 
counts).


Yet when I try this last configuration with the JSP that goes over 65K 
it fails with JDT and succeeds with javac.


--
Jess Holle

On 3/12/2011 9:50 AM, Jess Holle wrote:

On 3/11/2011 6:04 AM, Jess Holle wrote:

On 3/11/2011 3:22 AM, Mark Thomas wrote:

The obvious difference is that Tomcat 6 compilation targets Java 5
whereas Tomcat 7 targets Java 6. For a simple test JSP:
Tomcat 6 (1.5) - 3,488
Tomcat 7 (1.5) - 3,530 +1%
Tomcat 7 (1.6) - 3,668 +6%

The 1% will be a combination of:
- Tomcat 7 uses version 3.6 of the Eclipse compiler while Tomcat 6 uses
3.3.1.
- the source code differences you can see in the .java files.

Hmm

I tried forcing 1.5 as the source/target version for JspC -- I'm 
still over 65K with Tomcat 7.


I wonder if there's enough extra hidden code generated by use of 
generics...


Anyway, I guess the page owners will have to try to clean things up.
Is it possible that the source/target version is being ignored, e.g. 
for the Ant task form of JspC?


I ask as javac fails to compile the Java code generated by jasper as 
well for the same reason -- the _jspService method is too big.  When I 
force 1.5 as the target and source version, however, javac compiles 
the generated Java code just fine.


When I try the same trick with my precompilation Ant script, however, ala

jasper2 uriroot=${docBaseLocation} 
classpath=${wcWebAppClasspathAsString}

 compile=true outputDir=${outputDir}
 classDebugInfo=true smapSuppressed=${smapSuppressed}
 compilerSourceVM=1.5 compilerTargetVM=1.5
 validateXml=false listErrors=true
 verbose=${jspcVerbosityLevel} jspFiles=${jspFileList}/

I still get the same failure, which seems rather odd.  You'd think 
that JDT/EJC can't be generating that much larger code than javac.


--
Jess Holle

Re: JSP class size increase in Tomcat 7

2011-03-11 Thread Jess Holle


On 3/11/2011 3:22 AM, Mark Thomas wrote:

The obvious difference is that Tomcat 6 compilation targets Java 5
whereas Tomcat 7 targets Java 6. For a simple test JSP:
Tomcat 6 (1.5) - 3,488
Tomcat 7 (1.5) - 3,530 +1%
Tomcat 7 (1.6) - 3,668 +6%

The 1% will be a combination of:
- Tomcat 7 uses version 3.6 of the Eclipse compiler while Tomcat 6 uses
3.3.1.
- the source code differences you can see in the .java files.

Hmm

I tried forcing 1.5 as the source/target version for JspC -- I'm still 
over 65K with Tomcat 7.


I wonder if there's enough extra hidden code generated by use of generics...

Anyway, I guess the page owners will have to try to clean things up.

--
Jess Holle


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

Re: JSP class size increase in Tomcat 7

2011-03-11 Thread Jess Holle


On 3/11/2011 4:25 PM, Christopher Schultz wrote:

I'm interested in how you were able to do this. The 65k limitation is
for a single method, not the entire JSP. Yes, JSPs compile into a single
jspService method but when taglibs are used, each use generates its own
method which then gets called and each method tends to thin out.

Are you using lots of scriptlets and/or /not/ using any tag libraries?

Would it be possible to post the source to one of these problematic
JSPs? We may have some simple suggestions on how to reduce the size of
the generated methods.
I can't share the code, unfortunately.  There are lots of scriptlets and 
a fair number of tag libraries in use.  It's not my code -- though 
that's not to say mine is better, just smaller :-)

Oddly enough, generics are a compiler-only feature in Java. It's
basically a giant scam to avoid having to use casts while adding dozens
ofWhatevers  to your code rendering it unreadable. Oh, and the
compiler complains if you don't specify them, too, which is nice.

Anyhow, the presence of generics should not alter a .class file by a
single byte. I'd be happy to see a case where it does matter.
Yes, generics are almost a compiler-only feature, but that translates 
into (1) some extra metadata and (2) hidden casts inserted into calling 
code.  Both increase class file size.


I haven't gotten to it, but I've been meaning to toggle out the JDT/EJC 
compilation from my precompilation and use javac and see what that does 
-- just as a point of comparison.


--
Jess Holle


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

JSP class size increase in Tomcat 7


I've been looking at moving to Tomcat 7 from Tomcat 6.

Most things look good.

I have been surprised by one thing, however: Tomcat 7 produces larger 
JSP class files than Tomcat 6 from the same JSP source files, tag 
libraries, etc.  Around 12% larger in some examples I've been looking at 
(whereas the intermediate Java sources increase in size by ~1%).


For one thing, I'm not sure how to explain this.  Worse, however, it 
shed light on the fact that we had at least one JSP that was near the 
dreaded 65K limit.  With Tomcat, 6 it's under the limit.  With Tomcat 7, 
it's over the limit.


While I'm aware that getting near this limit is a sign of a problem 
JSP, having a new Tomcat release push more JSPs over the edge is both 
mysterious and unhelpful.


Any clues here?  I've obvious asked the page authors to look into 
amending it, but aside from that I don't have any bright ideas here.


--
Jess Holle


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

Re: JSP class size increase in Tomcat 7


P.S. This was with Tomcat 7.0.10.

On 3/10/2011 9:10 PM, Jess Holle wrote:

I've been looking at moving to Tomcat 7 from Tomcat 6.

Most things look good.

I have been surprised by one thing, however: Tomcat 7 produces larger 
JSP class files than Tomcat 6 from the same JSP source files, tag 
libraries, etc.  Around 12% larger in some examples I've been looking 
at (whereas the intermediate Java sources increase in size by ~1%).


For one thing, I'm not sure how to explain this.  Worse, however, it 
shed light on the fact that we had at least one JSP that was near the 
dreaded 65K limit.  With Tomcat, 6 it's under the limit.  With Tomcat 
7, it's over the limit.


While I'm aware that getting near this limit is a sign of a problem 
JSP, having a new Tomcat release push more JSPs over the edge is both 
mysterious and unhelpful.


Any clues here?  I've obvious asked the page authors to look into 
amending it, but aside from that I don't have any bright ideas here.


--
Jess Holle


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

Re: JSP class size increase in Tomcat 7


Yes, both Java 6 Update 24.

Both using the same doc-base, file paths, etc.  I renamed the old Tomcat 
directory and put the new one in its place.


On 3/10/2011 10:01 PM, Bob Hall wrote:

Jess,

--- On Thu, 3/10/11 at 7:10 PM, Jess Holleje...@ptc.com  wrote:


P.S. This was with Tomcat 7.0.10.

On 3/10/2011 9:10 PM, Jess Holle wrote:

I've been looking at moving to Tomcat 7 from Tomcat

6.

Most things look good.

I have been surprised by one thing, however: Tomcat 7

produces larger JSP class files than Tomcat 6 from the same
JSP source files, tag libraries, etc.  Around 12%
larger in some examples I've been looking at (whereas the
intermediate Java sources increase in size by ~1%).

Is the same version of Java used in both cases?

- Bob




-
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: JSP class size increase in Tomcat 7

On 3/10/2011 10:34 PM, Caldarale, Charles R wrote:

From: Jess Holle [mailto:je...@ptc.com]
Subject: Re: JSP class size increase in Tomcat 7
Yes, both Java 6 Update 24.

Just to verify, are both instances Tomcat running in the same JVM mode (-client 
or -server)?  (That shouldn't affect the .class file size, but just checking...)

Yes.

--
Jess Holle

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

Connector lifecycle

I want to stop all incoming requests at a given point.  I am running 
Tomcat within a larger process and I want to stop accepting new requests 
-- ideally in such a way that those requests are immediately routed to 
another Tomcat by mod_jk.


In Tomcat 6.0.x, I tried to do this by invoking the stop() operation on 
the Connector MBeans.  This almost works -- it allows one more request 
through (and maybe more in cases, I'm not sure, but always at least one) 
and then stops accepting additional requests.  I then tried destroy().  
This works.  Both operations log an error stating Coyote connector has 
not been started, which I am currently ignoring.


In Tomcat 7.0.10, stop() exhibits the same issue -- it lets at least one 
request through after the connector is supposedly stopped.  It does not, 
however, log an error.  destroy(), however, no longer works at all -- 
producing a lifecycle exception.


It seems like there's at least one bug here -- unless there is no intent 
to allow one to reliably stop accepting connections on a given connector.


Stopping the Engine or Service MBean instead results in a 404, which is 
not really what I want -- as I want mod_jk load balancing to go 
elsewhere, not return a 404.


--
Jess Holle


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

Re: Connector lifecycle

P.S. I certainly want to finish processing requests that are already 
being processed -- I want a graceful shutdown.


On 3/9/2011 8:16 AM, Jess Holle wrote:
I want to stop all incoming requests at a given point.  I am running 
Tomcat within a larger process and I want to stop accepting new 
requests -- ideally in such a way that those requests are immediately 
routed to another Tomcat by mod_jk.


In Tomcat 6.0.x, I tried to do this by invoking the stop() operation 
on the Connector MBeans.  This almost works -- it allows one more 
request through (and maybe more in cases, I'm not sure, but always at 
least one) and then stops accepting additional requests.  I then tried 
destroy().  This works.  Both operations log an error stating Coyote 
connector has not been started, which I am currently ignoring.


In Tomcat 7.0.10, stop() exhibits the same issue -- it lets at least 
one request through after the connector is supposedly stopped.  It 
does not, however, log an error.  destroy(), however, no longer works 
at all -- producing a lifecycle exception.


It seems like there's at least one bug here -- unless there is no 
intent to allow one to reliably stop accepting connections on a given 
connector.


Stopping the Engine or Service MBean instead results in a 404, which 
is not really what I want -- as I want mod_jk load balancing to go 
elsewhere, not return a 404.


--
Jess Holle




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

Re: Connector lifecycle


So there's no way to do this from the Tomcat side?

The process embedding Tomcat knows it's stopping.  It does not 
necessarily even have an ability to connect to the web server(s) that 
are connecting to it [Apache, IIS, or SJWS, but all via the JK 
connector].  I therefore want to say this Tomcat no longer open for 
business from the Tomcat side while finishing all requests already in 
progress.


Also I was somewhat inaccurate/mistaken in my summary of Tomcat 7.0.10 
behavior.  If you invoke stop() and then destroy() on a connector(), 
then an exception is logged /but /the destroy() call succeeds.  That 
said, when it succeeds you get a 200 with no content on the next 
request.  The request *after* that is returns a 503 from Apache -- and 
presumably would have been load balanced to another Tomcat (I only have 
1 in my test at the moment).  There's still odd behavior for a single 
request after the stop/destroy().


--
Jess Holle

On 3/9/2011 8:50 AM, Mladen Turk wrote:

On 03/09/2011 03:26 PM, Jess Holle wrote:
P.S. I certainly want to finish processing requests that are already 
being processed -- I want a graceful shutdown.




It's a two way process.
First in mod_jk mark the node as stopped (best by using status worker).
Then after all sessions times out in Tomcat you can do what ever 
pleases you.



Regards

Re: Connector lifecycle


Well the exception when invoking destroy() directly is:

2011-03-09 09:28:16,238 ERROR [RMI TCP Connection(13)-10.196.0.84] 
org.apache.tomcat.util.modeler.BaseModelMBean  - Exception invoking method 
destroy
org.apache.catalina.LifecycleException: An invalid Lifecycle transition was 
attempted ([before_destroy]) for component [Connector[AJP/1.3-8008]] in state 
[STARTED]
at 
org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:386)
at 
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:278)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
...

I can kind of understand this -- destroy() does not auto-invoke stop() 
and is complaining that the incoming state is not what it expects.


When invoking stop() and then destroy() the destroy() succeeds 
[something I missed in my original post], but an exception is still logged:


2011-03-09 09:29:21,939 ERROR [RMI TCP Connection(21)-10.196.0.84] 
org.apache.catalina.core.StandardService  - Failed to stop connector 
[Connector[AJP/1.3-8010]]
org.apache.catalina.LifecycleException: An invalid Lifecycle transition was 
attempted ([before_stop]) for component [Connector[AJP/1.3-8010]] in state 
[DESTROYING]
at 
org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:386)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:212)
at 
org.apache.catalina.core.StandardService.removeConnector(StandardService.java:309)
at 
org.apache.catalina.connector.Connector.destroyInternal(Connector.java:984)
at 
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:284)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
...

That seems quite inappropriate.  Note that Tomcat 6.0.x also logs errors 
(but not exception traces) when one attempts to invoke either stop() or 
destroy().


What's more troublesome to me is that with every approach I've tried at 
least 1 request still gets through.  In some cases this request works 
normally.  In other cases the request gets a 200 and no content or a 
404.  After this initial request things behave more appropriately -- 
with the particulars depending on what I try to stop.


It really is troubling me that I have to reach back up to all the web 
servers targeting a Tomcat to tell them to take a given Tomcat out of 
the rotation rather than just make a simple Java call in Tomcat to tell 
it to stop taking new requests.


--
Jess Holle

On 3/9/2011 9:09 AM, Mark Thomas wrote:

On 09/03/2011 15:06, Jess Holle wrote:

So there's no way to do this from the Tomcat side?

The process embedding Tomcat knows it's stopping.  It does not
necessarily even have an ability to connect to the web server(s) that
are connecting to it [Apache, IIS, or SJWS, but all via the JK
connector].  I therefore want to say this Tomcat no longer open for
business from the Tomcat side while finishing all requests already in
progress.

Also I was somewhat inaccurate/mistaken in my summary of Tomcat 7.0.10
behavior.  If you invoke stop() and then destroy() on a connector(),
then an exception is logged /but /the destroy() call succeeds.  That
said, when it succeeds you get a 200 with no content on the next
request.  The request *after* that is returns a 503 from Apache -- and
presumably would have been load balanced to another Tomcat (I only have
1 in my test at the moment).  There's still odd behavior for a single
request after the stop/destroy().

Can you post the Exception? That sounds like a bug that needs to be fixed.

I recall coming across this before. I think it was related to keep-alive
connections and was non-trivial to solve. Open a bugzilla entry and I'll
take another look. No promises though. It might end up as won't fix.

Mark

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

Re: Connector lifecycle


On 3/9/2011 12:50 PM, Mark Thomas wrote:

On 09/03/2011 15:47, Jess Holle wrote:

When invoking stop() and then destroy() the destroy() succeeds
[something I missed in my original post], but an exception is still logged:

2011-03-09 09:29:21,939 ERROR [RMI TCP Connection(21)-10.196.0.84]
org.apache.catalina.core.StandardService  - Failed to stop connector
[Connector[AJP/1.3-8010]]
org.apache.catalina.LifecycleException: An invalid Lifecycle transition
was attempted ([before_stop]) for component [Connector[AJP/1.3-8010]] in
state [DESTROYING]
 at
org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:386)

Hmm. That looks like a bug. Let me go look at the code...
Yep. Fixed in http://svn.apache.org/viewvc?rev=1079930view=rev Will be
in 7.0.11 onwards.

Thanks.

What's more troublesome to me is that with every approach I've tried at
least 1 request still gets through.  In some cases this request works
normally.  In other cases the request gets a 200 and no content or a
404.  After this initial request things behave more appropriately --
with the particulars depending on what I try to stop.

Let me do some more testing in this area.
In case it matters, I'm primarily interested in the BIO/JIO AJP 
connector and secondarily in the BIO/JIO HTTP connector.  [However good 
it might be building the APR connector across numerous platforms and 
then having to deal with the possibility of bugs in native code but 
outside the core JVM native code is just not worth it to me.]


--
Jess Holle


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

Re: Connector lifecycle


On 3/9/2011 1:40 PM, Mark Thomas wrote:

On 09/03/2011 18:50, Mark Thomas wrote:

On 09/03/2011 15:47, Jess Holle wrote:

What's more troublesome to me is that with every approach I've tried at
least 1 request still gets through.  In some cases this request works
normally.  In other cases the request gets a 200 and no content or a
404.  After this initial request things behave more appropriately --
with the particulars depending on what I try to stop.

Let me do some more testing in this area.

I can reproduce this. Fixing it shouldn't be too hard. However there are
a couple of different states:
a) Request not received when connector stopped
b) Request line being read when connector stopped
c) Request headers being read when connector stopped
d) Request body being read when connector stopped
and we need to decided how far a request has to get before it is
rejected when the connector is stopped.

I am leaning towards rejecting a) and allowing the rest to proceed.
Comments welcome at:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50903

This won't get into 7.0.11 but it should make it into 7.0.12.
Thanks.  Fixing this (and knowing which files to patch prior to 7.0.12's 
release) would be /very/ helpful.


(a) is fine by me.  Any request that we've started to process even in 
the slightest can proceed as far as I'm concerned -- it's preventing any 
further requests from being processed that's critical.


--
Jess Holle

Re: Connector lifecycle