https://issues.apache.org/bugzilla/show_bug.cgi?id=51953
--- Comment #10 from Francis Galiegue 2011-10-05 09:22:33
UTC ---
Created attachment 27694
--> https://issues.apache.org/bugzilla/attachment.cgi?id=27694
Alternative netmask class, using byte arrays
Here is another implementation using
Found by FindBugs. startService() and stopService() both return boolean, so it
is likely that the '&' is a typo and '&&' was meant.
---
.../tribes/membership/McastServiceImpl.java|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/java/org/apache/catalina/tribes/membe
File a bug, attach the patch to the bug etc...
p
On 5 October 2011 11:33, Francis Galiegue wrote:
> Found by FindBugs. startService() and stopService() both return boolean, so it
> is likely that the '&' is a typo and '&&' was meant.
> ---
> .../tribes/membership/McastServiceImpl.java |
https://issues.apache.org/bugzilla/show_bug.cgi?id=51960
Bug #: 51960
Summary: Fix suspicious boolean operator usage in
org.apache.catalina.tribes.membership.McastServiceImpl
Product: Tomcat 7
Version: trunk
Platform: PC
https://issues.apache.org/bugzilla/show_bug.cgi?id=51953
--- Comment #11 from Francis Galiegue 2011-10-05 12:51:19
UTC ---
This crude test using the following code shows indeed that the byte array based
implementation is indeed MUCH faster:
private static final int COUNT = 5;
https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #4 from Kari Scott 2011-10-05 13:57:57 UTC ---
If I had to choose between a new context attribute or mucking with my
CompressionFilter with something "that isn't pretty", well, I'm going to go
with the attribute. :-)
Was the o
https://issues.apache.org/bugzilla/show_bug.cgi?id=51953
--- Comment #12 from Christopher Schultz
2011-10-05 14:21:03 UTC ---
I like this NetMask implementation *much* better. It took me a while to
convince myself that it was correct, but it looks good to me, now. :)
There are only a few nits o
https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #5 from Christopher Schultz
2011-10-05 14:33:50 UTC ---
FWIW, the javadoc for javax.servlet.Filter specifically mentions "compression"
as a type of Filter one might want to build. Though not exactly part of the
spec, Tomcat sho
https://issues.apache.org/bugzilla/show_bug.cgi?id=51953
--- Comment #13 from Francis Galiegue 2011-10-05 14:38:27
UTC ---
(In reply to comment #12)
> I like this NetMask implementation *much* better. It took me a while to
> convince myself that it was correct, but it looks good to me, now. :)
>
https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #6 from Jess Holle 2011-10-05 14:41:46 UTC ---
If you look at the JSP source in question, it simply calls sendRedirect() in a
scriptlet. The issue here is that the auto-generated JSP source, whitespace,
etc, will try to write m
https://issues.apache.org/bugzilla/show_bug.cgi?id=51960
Christopher Schultz changed:
What|Removed |Added
Severity|normal |trivial
--- Comment #1 from
https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #7 from Jess Holle 2011-10-05 14:46:20 UTC ---
I'd think the ideal case might be to hide the sendRedirect() response body
generation from getOutputStream() and getWriter() entirely. getOutputStream()
and getWriter() could reall
https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #8 from Kari Scott 2011-10-05 14:51:20 UTC ---
It's exactly what Jess said, it's the auto-generated JSP code that's the
problem. And, we do have returns after all of our sendRedirects but in this
simple test it wouldn't compile
https://issues.apache.org/bugzilla/show_bug.cgi?id=51960
--- Comment #2 from Konstantin Kolinko 2011-10-05
14:56:19 UTC ---
(In reply to comment #1)
> That means that & and && are equivalent
They are not equivalent. The difference is that "&&" returns result immediately
of its left operand is f
https://issues.apache.org/bugzilla/show_bug.cgi?id=51960
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=51960
--- Comment #4 from Francis Galiegue 2011-10-05 15:29:30
UTC ---
OK, but a comment above this operator usage wouldn't be lost code imnsho
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are re
https://issues.apache.org/bugzilla/show_bug.cgi?id=51953
--- Comment #14 from Christopher Schultz
2011-10-05 15:35:07 UTC ---
(In reply to comment #13)
> But I'm really not convinced that string matching is a good idea. It
> may be for IPv4, but for IPv6 it will be a mess.
I think you're right.
Author: kkolinko
Date: Wed Oct 5 15:38:38 2011
New Revision: 1179268
URL: http://svn.apache.org/viewvc?rev=1179268&view=rev
Log:
Resolve "Redundant null check: the variable cannot be null at this location"
warning.
The JspC constructor cannot throw a JasperException.
Modified:
tomcat/trunk/
Author: kkolinko
Date: Wed Oct 5 15:44:58 2011
New Revision: 1179274
URL: http://svn.apache.org/viewvc?rev=1179274&view=rev
Log:
Resolve a warning about unboxing operation. Perform unboxing explicitly.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java
Modified: tomc
https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #9 from Jess Holle 2011-10-05 16:39:59 UTC ---
If making this behavior transparent to callers is seen as too much
overhead/mess/whatever, then I'd vote to revert the sendRedirect() RFC fix. I
actually prefer that sendRedirect()
I'm a little confused. On a quick glance of the method ... it appears the
method setProperty should be returning true if it did something, and false
if not. This would mean the cast is not needed (actually wrong). The fact
that the method did NOT throw an exception should mean that we should return
2011/10/5 Tim Funk :
> I'm a little confused. On a quick glance of the method ... it appears the
> method setProperty should be returning true if it did something, and false
> if not. This would mean the cast is not needed (actually wrong).
We are calling a method that returns boolean, and cast is
https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #10 from Konstantin Kolinko 2011-10-05
17:03:49 UTC ---
1. Making the behaviour optional, as suggested in Comment 2, should not hurt.
2. I think that CompressionServletResponseWrapper in this example could
overwrite the sendRe
https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
Bug #: 51966
Summary: Tomcat does not support ssha hashed of passwords in
all contexts
Product: Tomcat 6
Version: 6.0.33
Platform: PC
Status: NEW
https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
Adam Caldwell changed:
What|Removed |Added
Summary|Tomcat does not support |Tomcat does not support
https://issues.apache.org/bugzilla/show_bug.cgi?id=51741
--- Comment #7 from Larry Isaacs 2011-10-05 21:06:41 UTC
---
Sylvain,
Thanks for your work on this. I've verified the ".getResource()"
is fixed in Tomcat 7.0.22 for "Serve modules without publishing".
Unfortunately, the testing revealed
https://issues.apache.org/bugzilla/show_bug.cgi?id=51972
Bug #: 51972
Summary: sendRedirect does not support protocol relative URLs
Product: Tomcat 7
Version: 7.0.22
Platform: All
OS/Version: All
Status: NEW
Seve
https://issues.apache.org/bugzilla/show_bug.cgi?id=51952
--- Comment #11 from Christopher Schultz
2011-10-05 21:36:31 UTC ---
(In reply to comment #6)
> If you look at the JSP source in question, it simply calls sendRedirect() in a
> scriptlet. The issue here is that the auto-generated JSP sour
https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
Christopher Schultz changed:
What|Removed |Added
Attachment #27699|0 |1
is patch|
https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
--- Comment #2 from Christopher Schultz
2011-10-05 21:58:49 UTC ---
I like this idea (and have been considering it for a while), but I don't like
the implementation due to the following reasons:
1. Uses part of the password as the salt, w
https://issues.apache.org/bugzilla/show_bug.cgi?id=51972
--- Comment #1 from Mark Thomas 2011-10-05 22:12:49 UTC ---
The JavaDoc for sendRedirect requires that anything that starts with '/' is
treated as server relative. I'm not sure if that is what was intended but it is
certainly what the spec
https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
--- Comment #3 from Adam Caldwell 2011-10-05 22:16:39 UTC
---
Thank you for the great feedback. The salt isn't part of the users password. If
you look at the digest method that's used to generate the encoded password, it
is 4 random bytes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
Adam Caldwell changed:
What|Removed |Added
Attachment #27699|0 |1
is obsolete|
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "Roger Mbiama" page has been changed by Roger Mbiama:
http://wiki.apache.org/tomcat/Roger%20Mbiama
New page:
##language:en
== Your Name ==
Email: <>
...
CategoryHomepage
--
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "Roger Mbiama" page has been changed by Roger Mbiama:
http://wiki.apache.org/tomcat/Roger%20Mbiama?action=diff&rev1=1&rev2=2
##language:en
- == Your Name ==
+ == Roger Mbiama ==
35 matches
Mail list logo
