Re: BIO performance issues

[Mark Thomas]

igaz  wrote:

>Is this thread/issue still *active*?

No. The issues were resolved at the time as described in the thread.
BIO is still available in Tomcat 8 but NIO is now the default.

>  I have a few ideas (and I worked on a
>similar issue awhile back).
>But this thread was last active 2 years ago and there was even discussion of
>deprecating BIO in tomcat 8, so I don't want to waste time on something
>that is dormant or has been superceded

The BIO connector is still present and there are no plans (at the moment) to 
drop it. That is probably a discussion for Tomcat 9.

In the meantime, if you have ideas on how BIO (or any other connector) 
performance may be improved do let the list know.

Mark


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

Re: [Bug 54729] new HttpParser.parseAuthorizationBasic method

[Brian Burch]

On 20/03/13 10:17, bugzi...@apache.org wrote:

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


Sorry I could not reply more quickly, Mark, but I am currently in 
Australia and I am probably asleep while you are working.


Judging by the flurry of activity in this area, I conclude my change is 
no longer necessary and you might want to close this bug report.


Just for completeness, I'll briefly answer your comments and the later 
one from Konstantin.



--- Comment #1 from Mark Thomas  ---
Regarding your points:
1. Clarity vs efficiency is always a trade off. It depends how much efficiency
has been lost. Do you have any performance numbers?


You were quick to write a performance test! Given more time, I would 
have explained that I (like Konstantin) did not like the conversion from 
MessageBytes to a StringReader, and did not like the way I had created a 
second StringReader to parse the decoded the Base64 blob. However, I 
felt the performance hit would be small relative to the original 
implementation, although it would create extra short-lived instances.


My earlier approach had attempted to push the MessageBytes into the new 
HttpParser method, but that meant the parsing logic for BASIC became 
very different to that of DIGEST. I couldn't see a way to square the 
circle, so I trashed it and started again on a more harmonious path.



2. I don't see a test case either. I'd rather get any bugs in the decoder fixed
than put sticking plasters over other bits of code.


I've worked with Base64 implementations a lot in the past, in many 
different languages. However, the last time I looked (showing my age!) 
the java class was in a sun.* package and well worth avoiding. When I 
researched the apache commons version, I did not realise it had been 
superseded by javax.xml.bind.DatatypeConverter.


I've just noticed the discussion on the dev list "Use of JAXB api to 
process Base64 in Tomcat 7 and 8". I understand the arguments presented 
to not use this converter, but if you back out your change and reinstate 
org.apache.catalina.util.Base64, then we just go back to where I started 
with a broken implementation and no unit tests



3. I'd prefer to do this first. That code is only still in the code base
because it support ByteChunk / CharChunk which should allow a more efficient
interface with the rest of the Tomcat code base. It is probably time that that
assumption is tested.


I understand. However, the two decode methods look superficially quite 
similar to me. There must be scope for refactoring them, writing a 
proper unit test suite, and fixing the bugs that I wrapped in my 
suggested change to Basic Authenticator. That is a fair amount of work 
to achieve little more than just copying another implementation and add 
some novel method signatures. Wrappering a robust implementation feels 
like a better approach to me.



4. It is very unlikely we will be adding Commons Codec as a dependency to
Tomcat. We may do an svn copy and rename much like we have done for FileUpload
but the usefulness of that depends on the ByteChunk/CharChunk issues in 3. For
FileUpload I am looking at replacing the decoder with the JVM implementation.


I didn't follow your FileUpload change closely, especially before you 
switched to the DatatypeConverter. Did you basically clone the commons 
class? If yes, surely it would be better to put that code in tomcat.util 
- FileUpload could use it from there and I suspect the 
ByteChunk/CharChunk users would only need some pre/post processing.


It seems to me there are enough developers (in the same time zone) 
working on these issues. I don't have a lot of time to spend on tomcat 
at the moment, and it is fairly disheartening to find my efforts in what 
seemed to be a quiet backwater have been washed away by a flood. I'll 
step back until the dust settles! Let me know if I can help.


Regards,

Brian




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

Re: Question for the loader used in o.a.t.util.scan.StandardJarScanner

[Violeta Georgieva]

2013/3/20 Mark Thomas wrote:
> On 20/03/2013 13:55, Violeta Georgieva wrote:
>> Hi,
>>
>> I have a question for the loader that is used in
>> o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader,
>> JarScannerCallback, Set) (7.0.x trunk).
>>
>> Why don't we use the loader that is provided as a method parameter,
>> but instead of this we are using the thread context class loader?
>
> It looks like a left over from when the code was first refactored to
> create the StandardJarScanner. I agree, we should use the passed in
> class loader.

Can I introduce this change for 7.0.39 or it is late already?

>
>> row 196 ClassLoader loader =
>> row 197Thread.currentThread().getContextClassLoader();
>>
>> And why don't we start scanning from its parent, but instead of this
>> we start with it directly?
>
> Because of the possibility of external repositories having been
> configured. There are other ways this could be handled but the current
> code works. In Tomcat 8 the new resources implementation makes all this
> a lot simpler.

I understand.

>
>> I can see that in tomcat/trunk we are using the provided loader and we
>> start scanning from its parent.
>
> The Javadoc needs correcting as well.
>

I'll correct it also.


Thanks
Vily

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

[Bug 54729] new HttpParser.parseAuthorizationBasic method

[bugzilla]

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

--- Comment #3 from Julian Reschke  ---
You may want to have a look at the the cases at:

http://greenbytes.de/tech/tc/httpauth/

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: Question for the loader used in o.a.t.util.scan.StandardJarScanner

[Mark Thomas]

On 21/03/2013 08:09, Violeta Georgieva wrote:
> 2013/3/20 Mark Thomas wrote:
>> On 20/03/2013 13:55, Violeta Georgieva wrote:
>>> Hi,
>>>
>>> I have a question for the loader that is used in
>>> o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader,
>>> JarScannerCallback, Set) (7.0.x trunk).
>>>
>>> Why don't we use the loader that is provided as a method parameter,
>>> but instead of this we are using the thread context class loader?
>>
>> It looks like a left over from when the code was first refactored to
>> create the StandardJarScanner. I agree, we should use the passed in
>> class loader.
> 
> Can I introduce this change for 7.0.39 or it is late already?

Go for it. The Base64 encoder/decoder discussion needs to be resolved
first so there is plenty of time for this.

Mark


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

Re: [Bug 54729] new HttpParser.parseAuthorizationBasic method

[Mark Thomas]

On 21/03/2013 07:56, Brian Burch wrote:
> On 20/03/13 10:17, bugzi...@apache.org wrote:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=54729
> 
> Sorry I could not reply more quickly, Mark, but I am currently in
> Australia and I am probably asleep while you are working.

Not a problem. One of the reasons the ASF insists on using mailing lists
rather than teleconferences is to ensure everyone in all timezones has
an equal chance to participate.

> Judging by the flurry of activity in this area, I conclude my change is
> no longer necessary and you might want to close this bug report.

You know that better than I. My understanding from reading your report
was that there were a number of issues of which Base64 was just one and
one that was making fixing the others look a little ugly.

> Just for completeness, I'll briefly answer your comments and the later
> one from Konstantin.
> 
>> --- Comment #1 from Mark Thomas  ---
>> Regarding your points:
>> 1. Clarity vs efficiency is always a trade off. It depends how much
>> efficiency
>> has been lost. Do you have any performance numbers?
> 
> You were quick to write a performance test! Given more time, I would
> have explained that I (like Konstantin) did not like the conversion from
> MessageBytes to a StringReader, and did not like the way I had created a
> second StringReader to parse the decoded the Base64 blob. However, I
> felt the performance hit would be small relative to the original
> implementation, although it would create extra short-lived instances.
> 
> My earlier approach had attempted to push the MessageBytes into the new
> HttpParser method, but that meant the parsing logic for BASIC became
> very different to that of DIGEST. I couldn't see a way to square the
> circle, so I trashed it and started again on a more harmonious path.

The conversions aren't ideal but I think they are a price worth paying
for not having to maintain another Base64 encoder/decoder.

>> 2. I don't see a test case either. I'd rather get any bugs in the
>> decoder fixed
>> than put sticking plasters over other bits of code.
> 
> I've worked with Base64 implementations a lot in the past, in many
> different languages. However, the last time I looked (showing my age!)
> the java class was in a sun.* package and well worth avoiding. When I
> researched the apache commons version, I did not realise it had been
> superseded by javax.xml.bind.DatatypeConverter.
> 
> I've just noticed the discussion on the dev list "Use of JAXB api to
> process Base64 in Tomcat 7 and 8". I understand the arguments presented
> to not use this converter, but if you back out your change and reinstate
> org.apache.catalina.util.Base64, then we just go back to where I started
> with a broken implementation and no unit tests

I have a plan B in mind for that. More details on that thread.

>> 3. I'd prefer to do this first. That code is only still in the code base
>> because it support ByteChunk / CharChunk which should allow a more
>> efficient
>> interface with the rest of the Tomcat code base. It is probably time
>> that that
>> assumption is tested.
> 
> I understand. However, the two decode methods look superficially quite
> similar to me. There must be scope for refactoring them, writing a
> proper unit test suite, and fixing the bugs that I wrapped in my
> suggested change to Basic Authenticator. That is a fair amount of work
> to achieve little more than just copying another implementation and add
> some novel method signatures. Wrappering a robust implementation feels
> like a better approach to me.

+1. I'm all for code re-use.

>> 4. It is very unlikely we will be adding Commons Codec as a dependency to
>> Tomcat. We may do an svn copy and rename much like we have done for
>> FileUpload
>> but the usefulness of that depends on the ByteChunk/CharChunk issues
>> in 3. For
>> FileUpload I am looking at replacing the decoder with the JVM
>> implementation.
> 
> I didn't follow your FileUpload change closely, especially before you
> switched to the DatatypeConverter. Did you basically clone the commons
> class? If yes, surely it would be better to put that code in tomcat.util
> - FileUpload could use it from there and I suspect the
> ByteChunk/CharChunk users would only need some pre/post processing.

The Base64 decoder in FileUpload was copied from Geronimo to Commons and
then I updated Tomcat's copy of FileUpload. That Base64 code has issues
of it's own. Looking for a solution to that prior to the 7.0.39 release
was co-incidental with you looking at Base64 for BASIC auth.

> It seems to me there are enough developers (in the same time zone)
> working on these issues. I don't have a lot of time to spend on tomcat
> at the moment, and it is fairly disheartening to find my efforts in what
> seemed to be a quiet backwater have been washed away by a flood. I'll
> step back until the dust settles! Let me know if I can help.

I'm sorry you feel that your efforts have been wasted. My intent

Re: [Bug 54729] new HttpParser.parseAuthorizationBasic method

[Julian Reschke]

On 2013-03-21 10:15, Mark Thomas wrote:

...
I'm sorry you feel that your efforts have been wasted. My intention was
to get you a robust Base64 implementation to work with for the other
improvements you had in mind for BASIC auth. If there are other
improvements you have in mind for BASIC auth then your help there would
be much appreciated.
...


Related to that: I'd love to hear feedback on 
.


Best regards, Julian

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

Re: Use of JAXB api to process Base64 in Tomcat 7 and 8

[Mark Thomas]

On 21/03/2013 05:35, Konstantin Kolinko wrote:
> Hi!
> 
> Recent Mark's commits in Tomcat 7, 8 replaced custom
> implementations(*) of base64
> with use of the following class from JAXB:
> 
> javax.xml.bind.DatatypeConverter
> 
> This affects base64 processing in our own classes and in our copy of
> Commons FileUpload.
> The original fileupload library in commons was not changed (I do not
> see [1] change in [2] @1459121).
> 
> [1] http://svn.apache.org/r1458726
> [2] 
> http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java?view=markup
> 
> First, it seems wrong, as this JAXB API was not designed as a general
> purpose base64 codec.
> 
> I hereby -1 on this change, on the following ground:

OK. While I don't agree with you completely, I do agree that it would be
better to find an alternative solution. I suggest that we copy the
Base64 decoder/encoder from Commons Codec to a new o.a.tomcat.util.codec
package and update Tomcat 7 & 8 to use that (and point the deprecation
markers to this implementation) rather than DatatypeConverter.

I have some other bits and bobs to look at first today but I start on
this shortly unless anyone raises an objection.

Mark


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

svn commit: r1459208 - /tomcat/trunk/SVN-MERGE.txt

[markt]

Author: markt
Date: Thu Mar 21 09:55:54 2013
New Revision: 1459208

URL: http://svn.apache.org/r1459208
Log:
New file for keeping track of svn merges etc

Added:
tomcat/trunk/SVN-MERGE.txt   (with props)

Added: tomcat/trunk/SVN-MERGE.txt
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/SVN-MERGE.txt?rev=1459208&view=auto
==
--- tomcat/trunk/SVN-MERGE.txt (added)
+++ tomcat/trunk/SVN-MERGE.txt Thu Mar 21 09:55:54 2013
@@ -0,0 +1,47 @@
+
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+
+
+$Id: $
+
+Apache Tomcat re-uses code from a number of other Apache projects. There are
+several reasons why depending on the binary releases of those projects is not
+ideal. These include:
+- potential conflicts if a web application ships with the same JAR
+- a large JAR where Tomcat only depends on a small fraction
+
+There are various approaches taken to dealing with this. Once of those
+approaches is to svn copy the classes to the Tomcat source tree, modify them
+(always a package rename, sometimes additional changes) and then keep them in
+sync with the original via regular svn merges. This file keeps track of these
+copies to assist committers in keeping them up to date.
+
+BCEL
+org.apache.tomcat.util.bcel is copied from:
+/commons/proper/bcel/trunk/src/main/java/org/apache/bcel
+
+DBCP
+org.apache.tomcat.dbcp is generated by the build process from Commons DBCP and
+Commons Pool.
+
+FileUpload
+org.apache.tomcat.util.http.fileupload is coppied from:
+/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload
+Note: Tomcat's copy of fileupload also includes classes copied manually (rather
+  than svn copied) from Commons IO.
+
+
+

Propchange: tomcat/trunk/SVN-MERGE.txt
--
svn:eol-style = native



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

svn commit: r1459209 - /tomcat/trunk/SVN-MERGE.txt

[markt]

Author: markt
Date: Thu Mar 21 09:56:30 2013
New Revision: 1459209

URL: http://svn.apache.org/r1459209
Log:
Tweak wording

Modified:
tomcat/trunk/SVN-MERGE.txt

Modified: tomcat/trunk/SVN-MERGE.txt
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/SVN-MERGE.txt?rev=1459209&r1=1459208&r2=1459209&view=diff
==
--- tomcat/trunk/SVN-MERGE.txt (original)
+++ tomcat/trunk/SVN-MERGE.txt Thu Mar 21 09:56:30 2013
@@ -23,11 +23,11 @@ ideal. These include:
 - potential conflicts if a web application ships with the same JAR
 - a large JAR where Tomcat only depends on a small fraction
 
-There are various approaches taken to dealing with this. Once of those
-approaches is to svn copy the classes to the Tomcat source tree, modify them
-(always a package rename, sometimes additional changes) and then keep them in
-sync with the original via regular svn merges. This file keeps track of these
-copies to assist committers in keeping them up to date.
+There are various approaches taken to dealing with this. One of those 
approaches
+is to svn copy the classes to the Tomcat source tree, modify them (always with 
a
+package rename, sometimes with additional changes) and then keep them in sync
+with the original via regular svn merges. This file keeps track of these copies
+to assist committers in keeping them up to date.
 
 BCEL
 org.apache.tomcat.util.bcel is copied from:



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

[Bug 53871] java.lang.StackOverflowError on deploying a web application

[bugzilla]

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

--- Comment #16 from Robert Pasztor  ---
I've tried to upgrade to 7.0.37 (latest release at this moment).
We still encounter the same issue, but this time the logged stacktrace is more
detailed than the one I've added in the initial description:

10:49:06,990 ERROR [ContainerBase:903] ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/dossier]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1637)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IllegalStateException: Unable to complete the scan for
annotations for web application [/dossier]. Possible root causes include a
 too low setting for -Xss and illegal cyclic inheritance dependencies
at
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2109)
at
org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1981)
at
org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1947)
at
org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1932)
at
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1326)
at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5179)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 11 more
Caused by: java.lang.StackOverflowError
at java.util.Random.nextInt(Random.java:239)
at sun.misc.Hashing.randomHashSeed(Hashing.java:254)
at java.util.HashMap.(HashMap.java:255)
at java.util.HashMap.(HashMap.java:305)
at java.util.HashSet.(HashSet.java:103)
at
org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2252)
at
org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2269)
at
org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2269)
...

I thought this might be helpful for further progress on this issue.
As mentioned in comment 10 and also on
http://collab.sakaiproject.org/pipermail/sakai-dev/2012-November/019574.html ,

I was able to workaround this exception by skipping the jar scannining in
catalina.properties:

# Additional JARs (over and above the default JARs listed above) to skip when
# scanning for Servlet 3.0 pluggability features. These features include web
# fragments, annotations, SCIs and classes that match @HandlesTypes. The list
# must be a comma separated list of JAR file names.
org.apache.catalina.startup.ContextConfig.jarsToSkip=*.jar

IMHO this is still a workaround and not the fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

svn commit: r1459218 - in /tomcat/trunk/java/org/apache/tomcat/util/codec: ./ binary/ digest/ language/ net/

[markt]

Author: markt
Date: Thu Mar 21 10:31:50 2013
New Revision: 1459218

URL: http://svn.apache.org/r1459218
Log:
Import a package renamed copy of Commons Codec with just those bits required 
for Base64 encoding/decoding

Added:
tomcat/trunk/java/org/apache/tomcat/util/codec/
  - copied from r1459200, 
commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/
Removed:
tomcat/trunk/java/org/apache/tomcat/util/codec/CharEncoding.java
tomcat/trunk/java/org/apache/tomcat/util/codec/Charsets.java
tomcat/trunk/java/org/apache/tomcat/util/codec/StringDecoder.java
tomcat/trunk/java/org/apache/tomcat/util/codec/StringEncoder.java
tomcat/trunk/java/org/apache/tomcat/util/codec/StringEncoderComparator.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base32.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base32InputStream.java

tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base32OutputStream.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base64InputStream.java

tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base64OutputStream.java

tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodecInputStream.java

tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodecOutputStream.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BinaryCodec.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Hex.java
tomcat/trunk/java/org/apache/tomcat/util/codec/digest/
tomcat/trunk/java/org/apache/tomcat/util/codec/language/
tomcat/trunk/java/org/apache/tomcat/util/codec/net/
tomcat/trunk/java/org/apache/tomcat/util/codec/overview.html
tomcat/trunk/java/org/apache/tomcat/util/codec/package.html
Modified:
tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryDecoder.java
tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryEncoder.java
tomcat/trunk/java/org/apache/tomcat/util/codec/Decoder.java
tomcat/trunk/java/org/apache/tomcat/util/codec/DecoderException.java
tomcat/trunk/java/org/apache/tomcat/util/codec/Encoder.java
tomcat/trunk/java/org/apache/tomcat/util/codec/EncoderException.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base64.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/StringUtils.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryDecoder.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryDecoder.java?rev=1459218&r1=1459200&r2=1459218&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryDecoder.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryDecoder.java Thu Mar 
21 10:31:50 2013
@@ -14,8 +14,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-
-package org.apache.commons.codec;
+package org.apache.tomcat.util.codec;
 
 /**
  * Defines common decoding methods for byte array decoders.

Modified: tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryEncoder.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryEncoder.java?rev=1459218&r1=1459200&r2=1459218&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryEncoder.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/codec/BinaryEncoder.java Thu Mar 
21 10:31:50 2013
@@ -14,8 +14,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-
-package org.apache.commons.codec;
+package org.apache.tomcat.util.codec;
 
 /**
  * Defines common encoding methods for byte array encoders.

Modified: tomcat/trunk/java/org/apache/tomcat/util/codec/Decoder.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/Decoder.java?rev=1459218&r1=1459200&r2=1459218&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/codec/Decoder.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/codec/Decoder.java Thu Mar 21 
10:31:50 2013
@@ -14,8 +14,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-
-package org.apache.commons.codec;
+package org.apache.tomcat.util.codec;
 
 /**
  * Provides the highest level of abstraction for Decoders.

Modified: tomcat/trunk/java/org/apache/tomcat/util/codec/DecoderException.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/DecoderException.java?rev=1459218&r1=1459200&r2=1459218&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/codec/DecoderExcep

svn commit: r1459223 - in /tomcat/trunk/java/org/apache/tomcat/util/codec/binary: Base64.java BaseNCodec.java

[markt]

Author: markt
Date: Thu Mar 21 10:55:59 2013
New Revision: 1459223

URL: http://svn.apache.org/r1459223
Log:
Add the ability to decode a subset of a byte array as this will enable Tomcat 
to use the decoder more efficiently.

Modified:
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base64.java
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base64.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base64.java?rev=1459223&r1=1459222&r2=1459223&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base64.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/codec/binary/Base64.java Thu Mar 
21 10:55:59 2013
@@ -693,7 +693,12 @@ public class Base64 extends BaseNCodec {
  * @return Array containing decoded data.
  */
 public static byte[] decodeBase64(final byte[] base64Data) {
-return new Base64().decode(base64Data);
+return decodeBase64(base64Data, 0, base64Data.length);
+}
+
+public  static byte[] decodeBase64(
+final byte[] base64Data, final int off, final int len) {
+return new Base64().decode(base64Data, off, len);
 }
 
 // Implementation of the Encoder Interface

Modified: tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java?rev=1459223&r1=1459222&r2=1459223&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java Thu 
Mar 21 10:55:59 2013
@@ -377,12 +377,16 @@ public abstract class BaseNCodec impleme
  */
 @Override
 public byte[] decode(final byte[] pArray) {
-if (pArray == null || pArray.length == 0) {
-return pArray;
+return decode(pArray, 0, pArray.length);
+}
+
+public byte[] decode(final byte[] pArray, final int off, final int len) {
+if (pArray == null || len == 0) {
+return new byte[0];
 }
 final Context context = new Context();
-decode(pArray, 0, pArray.length, context);
-decode(pArray, 0, EOF, context); // Notify decoder of EOF.
+decode(pArray, off, len, context);
+decode(pArray, off, EOF, context); // Notify decoder of EOF.
 final byte[] result = new byte[context.pos];
 readResults(result, 0, result.length, context);
 return result;



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

svn commit: r1459225 - in /tomcat/tc7.0.x/trunk: java/org/apache/tomcat/util/scan/StandardJarScanner.java webapps/docs/changelog.xml

[violetagg]

Author: violetagg
Date: Thu Mar 21 11:19:53 2013
New Revision: 1459225

URL: http://svn.apache.org/r1459225
Log:
Ensure that StandardJarScanner#scan will use the provided class loader when 
scanning the class loader hierarchy.

Modified:

tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java?rev=1459225&r1=1459224&r2=1459225&view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java 
(original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java 
Thu Mar 21 11:19:53 2013
@@ -188,13 +188,12 @@ public class StandardJarScanner implemen
 }
 
 // Scan the classpath
-if (scanClassPath) {
+if (scanClassPath && classloader != null) {
 if (log.isTraceEnabled()) {
 log.trace(sm.getString("jarScan.classloaderStart"));
 }
 
-ClassLoader loader =
-Thread.currentThread().getContextClassLoader();
+ClassLoader loader = classloader;
 
 ClassLoader stopLoader = null;
 if (!scanBootstrapClassPath) {

Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1459225&r1=1459224&r2=1459225&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Mar 21 11:19:53 2013
@@ -100,6 +100,10 @@
 Deprecate Tomcat's internal Base 64 encoder/decoder and switch to
 using the JRE provided implementation. (markt)
   
+  
+Ensure that StandardJarScanner#scan will use the provided class loader
+when scanning the class loader hierarchy. (violetagg)
+  
 
   
   



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

svn commit: r1459230 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

[violetagg]

Author: violetagg
Date: Thu Mar 21 11:28:29 2013
New Revision: 1459230

URL: http://svn.apache.org/r1459230
Log:
Reorder sections in ascending order according to the issue number.

Modified:
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1459230&r1=1459229&r2=1459230&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Mar 21 11:28:29 2013
@@ -127,17 +127,17 @@
   
 
   
-54684: Add javax.naming.spi to 
-Import-Package header in MANIFEST.MF in order to resolve
-ClassNotFoundException when running in OSGi environment.
-(violetagg)
-  
-  
 52318: Version for imported package
 org.apache.juli.logging is extended to include also 7.0.x
 versions. The fix is applicable only when running in OSGi environment.
 Patch provided by Martin Lichtin. (violetagg)
   
+  
+54684: Add javax.naming.spi to 
+Import-Package header in MANIFEST.MF in order to resolve
+ClassNotFoundException when running in OSGi environment.
+(violetagg)
+  
 
   
   



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

[Tomcat Wiki] Update of "LocalBadContent" by KonstantinKolinko

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "LocalBadContent" page has been changed by KonstantinKolinko:
http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=96&rev2=97

  breathefreshecigs\.com
  bricodgeasirgesalia\.blogbaker\.com
  buchete\.ro
+ buddy-mash\.de
  buyyourall\.com
  buymaternitymaxidresses\.iwannayou\.com
  buzzbacklinks\.com
@@ -89, +90 @@

  goldbetreview
  gradhome\.com
  grandnationalpro\.com
+ guruchetra
  hbgm\.cn
  hfire\.cn
  hiring\.cz

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

buildbot failure in ASF Buildbot on tomcat-7-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-7-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/tomcat-7-trunk/builds/1139

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-vm_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1459225
Blamelist: violetagg

BUILD FAILED: failed compile_1

sincerely,
 -The Buildbot

svn commit: r1459288 - in /tomcat/trunk/java: javax/servlet/http/ org/apache/coyote/http11/upgrade/ org/apache/tomcat/websocket/server/

[markt]

Author: markt
Date: Thu Mar 21 13:09:41 2013
New Revision: 1459288

URL: http://svn.apache.org/r1459288
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54734
Partial fix
javax.servlet.http.WebConnection needs to extend AutoCloseable
Based on a patch by Nick Williams

Modified:
tomcat/trunk/java/javax/servlet/http/WebConnection.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractProcessor.java
tomcat/trunk/java/org/apache/tomcat/websocket/server/LocalStrings.properties

tomcat/trunk/java/org/apache/tomcat/websocket/server/WsHttpUpgradeHandler.java

Modified: tomcat/trunk/java/javax/servlet/http/WebConnection.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/http/WebConnection.java?rev=1459288&r1=1459287&r2=1459288&view=diff
==
--- tomcat/trunk/java/javax/servlet/http/WebConnection.java (original)
+++ tomcat/trunk/java/javax/servlet/http/WebConnection.java Thu Mar 21 13:09:41 
2013
@@ -27,7 +27,7 @@ import javax.servlet.ServletOutputStream
  *
  * @since Servlet 3.1
  */
-public interface WebConnection {
+public interface WebConnection extends AutoCloseable {
 
 /**
  * Provides access to the {@link ServletInputStream} for reading data from

Modified: 
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractProcessor.java?rev=1459288&r1=1459287&r2=1459288&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractProcessor.java 
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractProcessor.java 
Thu Mar 21 13:09:41 2013
@@ -52,6 +52,15 @@ public abstract class AbstractProcessor<
 }
 
 
+// --- AutoCloseable 
methods
+
+@Override
+public void close() throws Exception {
+upgradeServletInputStream.close();
+upgradeServletOutputStream.close();
+}
+
+
 // --- WebConnection 
methods
 
 @Override

Modified: 
tomcat/trunk/java/org/apache/tomcat/websocket/server/LocalStrings.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/server/LocalStrings.properties?rev=1459288&r1=1459287&r2=1459288&view=diff
==
--- 
tomcat/trunk/java/org/apache/tomcat/websocket/server/LocalStrings.properties 
(original)
+++ 
tomcat/trunk/java/org/apache/tomcat/websocket/server/LocalStrings.properties 
Thu Mar 21 13:09:41 2013
@@ -24,6 +24,7 @@ serverContainer.servletContextMissing=No
 
 uriTemplate.noMatch=The input template [{0}] generated the pattern [{1}] which 
did not match the supplied pathInfo [{2}]
 
+wsHttpUpgradeHandler.destroyFailed=Failed to close WebConnection while 
destroying the WebSocket HttpUpgradeHandler
 wsHttpUpgradeHandler.noPreInit=The preInit() method must be called to 
configure the WebSocket HttpUpgradeHandler before the container calls init(). 
Usually, this means the Servlet that created the WsHttpUpgradeHandler instance 
should also call preInit()
 
 wsRemoteEndpointServer.closeFailed=Failed to close the ServletOutputStream 
connection cleanly
\ No newline at end of file

Modified: 
tomcat/trunk/java/org/apache/tomcat/websocket/server/WsHttpUpgradeHandler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/server/WsHttpUpgradeHandler.java?rev=1459288&r1=1459287&r2=1459288&view=diff
==
--- 
tomcat/trunk/java/org/apache/tomcat/websocket/server/WsHttpUpgradeHandler.java 
(original)
+++ 
tomcat/trunk/java/org/apache/tomcat/websocket/server/WsHttpUpgradeHandler.java 
Thu Mar 21 13:09:41 2013
@@ -32,6 +32,8 @@ import javax.websocket.DeploymentExcepti
 import javax.websocket.Endpoint;
 import javax.websocket.EndpointConfig;
 
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
 import org.apache.tomcat.util.res.StringManager;
 import org.apache.tomcat.websocket.WsIOException;
 import org.apache.tomcat.websocket.WsSession;
@@ -41,6 +43,11 @@ import org.apache.tomcat.websocket.WsSes
  */
 public class WsHttpUpgradeHandler implements HttpUpgradeHandler {
 
+private static final Log log =
+LogFactory.getLog(WsHttpUpgradeHandler.class);
+private static final StringManager sm =
+StringManager.getManager(Constants.PACKAGE_NAME);
+
 private final ClassLoader applicationClassLoader;
 
 private Endpoint ep;
@@ -50,12 +57,10 @@ public class WsHttpUpgradeHandler implem
 private String subProtocol;
 private Map pathParameters;
 private boolean secure;
+WebConnection connection;
 
 private WsSession wsSession;
 
-priva

svn commit: r1459289 - in /tomcat/trunk: java/org/apache/catalina/ant/ java/org/apache/catalina/authenticator/ java/org/apache/catalina/realm/ java/org/apache/tomcat/util/http/fileupload/util/mime/ ja

[markt]

Author: markt
Date: Thu Mar 21 13:10:08 2013
New Revision: 1459289

URL: http://svn.apache.org/r1459289
Log:
Switch to Base64 encoder/decoder from Commons Codec

Modified:
tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java
tomcat/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java
tomcat/trunk/java/org/apache/catalina/authenticator/SpnegoAuthenticator.java
tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java

tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/util/mime/MimeUtility.java
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
tomcat/trunk/java/org/apache/tomcat/websocket/server/WsServlet.java

tomcat/trunk/test/org/apache/catalina/authenticator/TestNonLoginAndBasicAuthenticator.java

tomcat/trunk/test/org/apache/catalina/authenticator/TestSSOnonLoginAndBasicAuthenticator.java

Modified: tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java?rev=1459289&r1=1459288&r2=1459289&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java Thu Mar 
21 13:10:08 2013
@@ -27,9 +27,8 @@ import java.net.HttpURLConnection;
 import java.net.URL;
 import java.net.URLConnection;
 
-import javax.xml.bind.DatatypeConverter;
-
 import org.apache.tomcat.util.buf.B2CConverter;
+import org.apache.tomcat.util.codec.binary.Base64;
 import org.apache.tools.ant.BuildException;
 import org.apache.tools.ant.Project;
 
@@ -202,7 +201,7 @@ public abstract class AbstractCatalinaTa
 
 // Set up an authorization header with our credentials
 String input = username + ":" + password;
-String output = DatatypeConverter.printBase64Binary(
+String output = Base64.encodeBase64String(
 input.getBytes(B2CConverter.ISO_8859_1));
 hconn.setRequestProperty("Authorization",
  "Basic " + output);

Modified: 
tomcat/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java?rev=1459289&r1=1459288&r2=1459289&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java 
Thu Mar 21 13:10:08 2013
@@ -24,7 +24,6 @@ import java.security.Principal;
 
 import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpServletResponse;
-import javax.xml.bind.DatatypeConverter;
 
 import org.apache.catalina.connector.Request;
 import org.apache.juli.logging.Log;
@@ -32,6 +31,7 @@ import org.apache.juli.logging.LogFactor
 import org.apache.tomcat.util.buf.B2CConverter;
 import org.apache.tomcat.util.buf.ByteChunk;
 import org.apache.tomcat.util.buf.MessageBytes;
+import org.apache.tomcat.util.codec.binary.Base64;
 
 
 
@@ -111,10 +111,10 @@ public class BasicAuthenticator
 if (authorizationBC.startsWithIgnoreCase("basic ", 0)) {
 authorizationBC.setOffset(authorizationBC.getOffset() + 6);
 
-// Use the StringCache as these will be the same between
-// requests
-String encoded = authorizationBC.toStringInternal();
-byte[] decoded = DatatypeConverter.parseBase64Binary(encoded);
+byte[] decoded = Base64.decodeBase64(
+authorizationBC.getBuffer(),
+authorizationBC.getOffset(),
+authorizationBC.getLength());
 
 // Get username and password
 int colon = -1;

Modified: 
tomcat/trunk/java/org/apache/catalina/authenticator/SpnegoAuthenticator.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/authenticator/SpnegoAuthenticator.java?rev=1459289&r1=1459288&r2=1459289&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/authenticator/SpnegoAuthenticator.java 
(original)
+++ 
tomcat/trunk/java/org/apache/catalina/authenticator/SpnegoAuthenticator.java 
Thu Mar 21 13:10:08 2013
@@ -27,15 +27,14 @@ import javax.security.auth.Subject;
 import javax.security.auth.login.LoginContext;
 import javax.security.auth.login.LoginException;
 import javax.servlet.http.HttpServletResponse;
-import javax.xml.bind.DatatypeConverter;
 
 import org.apache.catalina.LifecycleException;
 import org.apache.catalina.connector.Request;
 import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
-import org.apache.tomcat.util

svn commit: r1459299 - /tomcat/trunk/test/org/apache/catalina/connector/TestMaxConnections.java

[markt]

Author: markt
Date: Thu Mar 21 13:24:09 2013
New Revision: 1459299

URL: http://svn.apache.org/r1459299
Log:
Increase socket timeout in an effort to reduce false failures on buildbot

Modified:
tomcat/trunk/test/org/apache/catalina/connector/TestMaxConnections.java

Modified: 
tomcat/trunk/test/org/apache/catalina/connector/TestMaxConnections.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestMaxConnections.java?rev=1459299&r1=1459298&r2=1459299&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/connector/TestMaxConnections.java 
(original)
+++ tomcat/trunk/test/org/apache/catalina/connector/TestMaxConnections.java Thu 
Mar 21 13:24:09 2013
@@ -33,7 +33,7 @@ import org.apache.catalina.startup.Tomca
 import org.apache.catalina.startup.TomcatBaseTest;
 
 public class TestMaxConnections extends TomcatBaseTest {
-public static final int soTimeout = 3000;
+public static final int soTimeout = 5000;
 public static final int connectTimeout = 1000;
 
 @Test



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

Re: buildbot failure in ASF Buildbot on tomcat-7-trunk

[Violeta Georgieva]

Hi,

Test org.apache.catalina.connector.TestMaxConnections FAILED

I cannot reproduce this failure neither on Windows nor on MAC.

Can somebody help me to understand what's happening with this test?

Thanks
Violeta

2013/3/21  :
> The Buildbot has detected a new failure on builder tomcat-7-trunk while 
> building ASF Buildbot.
> Full details are available at:
>  http://ci.apache.org/builders/tomcat-7-trunk/builds/1139
>
> Buildbot URL: http://ci.apache.org/
>
> Buildslave for this Build: bb-vm_ubuntu
>
> Build Reason: scheduler
> Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1459225
> Blamelist: violetagg
>
> BUILD FAILED: failed compile_1
>
> sincerely,
>  -The Buildbot
>
>
>

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

Re: buildbot failure in ASF Buildbot on tomcat-7-trunk

[Mark Thomas]

On 21/03/2013 13:28, Violeta Georgieva wrote:
> Hi,
> 
> Test org.apache.catalina.connector.TestMaxConnections FAILED
> 
> I cannot reproduce this failure neither on Windows nor on MAC.
> 
> Can somebody help me to understand what's happening with this test?

The machine is really slow at times. A number of the timing based tests
have failed over time.

Mark


> 
> Thanks
> Violeta
> 
> 2013/3/21  :
>> The Buildbot has detected a new failure on builder tomcat-7-trunk while 
>> building ASF Buildbot.
>> Full details are available at:
>>  http://ci.apache.org/builders/tomcat-7-trunk/builds/1139
>>
>> Buildbot URL: http://ci.apache.org/
>>
>> Buildslave for this Build: bb-vm_ubuntu
>>
>> Build Reason: scheduler
>> Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1459225
>> Blamelist: violetagg
>>
>> BUILD FAILED: failed compile_1
>>
>> sincerely,
>>  -The Buildbot
>>
>>
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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

Re: buildbot failure in ASF Buildbot on tomcat-7-trunk

[Violeta Georgieva]

2013/3/21 Mark Thomas wrote:
> On 21/03/2013 13:28, Violeta Georgieva wrote:
>> Hi,
>>
>> Test org.apache.catalina.connector.TestMaxConnections FAILED
>>
>> I cannot reproduce this failure neither on Windows nor on MAC.
>>
>> Can somebody help me to understand what's happening with this test?
>
> The machine is really slow at times. A number of the timing based tests
> have failed over time.
>


Thanks

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

Adding Connectors

[Steffen Heil (Mailinglisten)]

Hi


I have a servlet that creates a new Connector and adds it to the Service it is 
running in.
However it does this during startup of the Servlet.

Obviously the connectors specified in the server.xml are added and NOT started.
So tomcat starts its connectors as last thing after loading other components 
(including servlets).

Therefor I get:
INFO: The start() method was called on component 
[Connector[org.apache.coyote.http11.Http11NioProtocol-1001]] after start() had 
already been called. The second call will be ignored.

Now, that would not be a problem for me, but I would like to add my connectors 
without starting them, so that at the end of startup sequence tomcat would 
start them as it does for all other connectors defined in server.xml.

But I cannot. The following code shows the issue.


package org.apache.catalina.core;

public class StandardService extends LifecycleMBeanBase implements Service {

  public void addConnector(Connector connector) {
...
if (getState().isAvailable()) {
  try {
connector.start();
  } catch (LifecycleException e) {

log.error(sm.getString("standardService.connector.startFailed",connector), e);
  }
}
...
  }

}


During servlet initialization getState().isAvailable() returns true, therefore 
the connector is started right away.
Also, during start, if anything is accessed before the tomcat startup sequence 
completes, I get the following:

Mar 21, 2013 1:36:34 PM org.apache.tomcat.util.net.NioEndpoint processSocket
SEVERE: Error allocating socket processor
java.lang.IllegalStateException: StandardThreadPool not started.
at 
org.apache.catalina.core.StandardThreadExecutor.execute(StandardThreadExecutor.java:173)
at 
org.apache.tomcat.util.net.NioEndpoint.processSocket(NioEndpoint.java:728)
at 
org.apache.tomcat.util.net.NioEndpoint$Poller.processKey(NioEndpoint.java:1257)
at 
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1193)
at java.lang.Thread.run(Thread.java:662)


This is probably, because my connector is already started, while the Executor 
is not.


Now, my two questions: 


a) Can I assume that those error messages do no harm?

b) Isn't this a bug, that tomcat starts connectors while it regards all 
self-created connectors as not started?


Regards,
   Steffen


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

Re: svn commit: r1458187 - in /tomcat/trunk/java/org/apache/tomcat/util/http/fileupload: ./ util/mime/Base64Decoder.java util/mime/MimeUtility.java

[Christopher Schultz]

Konstantin,

On 3/19/13 6:09 AM, Konstantin Kolinko wrote:
>>  } else if (data[end - 1] == PADDING) {
>> -b1 = DECODING_TABLE[data[end - 4]];
>> -b2 = DECODING_TABLE[data[end - 3]];
>> -b3 = DECODING_TABLE[data[end - 2]];
>> +b1 = DECODING_TABLE[data[end - MASK_4BITS]];
>> +b2 = DECODING_TABLE[data[end - BYTES_PER_UNENCODED_BLOCK]];
>> +b3 = DECODING_TABLE[data[end - MASK_2BITS]];
> 
> 
> ??? (A question to commons team though).
> 
> I do not know FileUpload code, but from my generic knowledge of base64,
> the above replacement is suspicious.
> 
> I think the above replacement of 2,3,4 with constants is incorrect.
> They are just indexes in the table.

+1

The code will still run properly but if the constants were ever to be
changed (which they shouldn't!), chaos would ensue. It's also misleading
to read the code.

>>  } else {
>> -b1 = DECODING_TABLE[data[end - 4]];
>> -b2 = DECODING_TABLE[data[end - 3]];
>> -b3 = DECODING_TABLE[data[end - 2]];
>> +b1 = DECODING_TABLE[data[end - MASK_4BITS]];
>> +b2 = DECODING_TABLE[data[end - BYTES_PER_UNENCODED_BLOCK]];
>> +b3 = DECODING_TABLE[data[end - MASK_2BITS]];
>>  b4 = DECODING_TABLE[data[end - 1]];

Also here +1

-chris



signature.asc
Description: OpenPGP digital signature

Re: [Bug 54721] New: RemoteEndpoint blocks indefinitely if sendObject called with BinaryStream of TextStream encoders

[Christopher Schultz]

Nick,

On 3/18/13 6:03 PM, Nick Williams wrote:
> 
> I've been busy fleshing out all kinds of problems. :-)

Careful: you might inadvertently become the babysitter of Tomcat's
Websocket implementation.

-chris



signature.asc
Description: OpenPGP digital signature

OT: Will web containers be required to implement WebSockets

[Nicholas Williams]

I know that WebSockets will be a part of the Java EE 7 specification
for full application servers. But will web containers also be required
to implement this? Or will it be optional, and Tomcat is just being
nice? :-)

Nick

Sent from my iPhone, so please forgive brief replies and frequent typos


smime.p7s
Description: S/MIME cryptographic signature

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

Re: [Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale

[Christopher Schultz]

Mark,

+1 on locking-down the wiki, at least for a short period of time.

On 3/19/13 7:04 PM, Mark Thomas wrote:
> On 19/03/2013 23:02, sebb wrote:
>> On 18 March 2013 21:54, Mark Thomas  wrote:
> 
>>> I'll note that while the spammers entries to the wiki get removed pretty
>>> quickly (thanks Chunk) their content is in our mail archive which is
>>
>> s/Chunk/Chuck/ !
> 
> Sorry. Too much time spent typing ByteChunk and CharChunk recently. My
> fingers just do it automatically.

He seems more like a ByteChunk to me.

-chris



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1458187 - in /tomcat/trunk/java/org/apache/tomcat/util/http/fileupload: ./ util/mime/Base64Decoder.java util/mime/MimeUtility.java

[Konstantin Kolinko]

2013/3/21 Christopher Schultz :
> Konstantin,
>
> On 3/19/13 6:09 AM, Konstantin Kolinko wrote:
>>>  } else if (data[end - 1] == PADDING) {
>>> -b1 = DECODING_TABLE[data[end - 4]];
>>> -b2 = DECODING_TABLE[data[end - 3]];
>>> -b3 = DECODING_TABLE[data[end - 2]];
>>> +b1 = DECODING_TABLE[data[end - MASK_4BITS]];
>>> +b2 = DECODING_TABLE[data[end - BYTES_PER_UNENCODED_BLOCK]];
>>> +b3 = DECODING_TABLE[data[end - MASK_2BITS]];
>>
>>
>> ??? (A question to commons team though).
>>
>> I do not know FileUpload code, but from my generic knowledge of base64,
>> the above replacement is suspicious.
>>
>> I think the above replacement of 2,3,4 with constants is incorrect.
>> They are just indexes in the table.
>
> +1
>
> The code will still run properly but if the constants were ever to be
> changed (which they shouldn't!), chaos would ensue. It's also misleading
> to read the code.
>

This particular change has been reverted in Commons Fileupload in one
of subsequent commits [1], which Mark picked up in subsequent merges.
The final patch that was ported to Tomcat 7 did not have anything of
the above.

[1] http://svn.apache.org/viewvc?view=revision&revision=1457865

Best regards,
Konstantin Kolinko

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

Re: Wiki (was: Update of "LocalBadContent")

[Christopher Schultz]

Konstantin,

On 3/20/13 8:36 AM, Konstantin Kolinko wrote:
> Previous discussions:
> [2] (Jun 2011) http://tomcat.markmail.org/thread/nndyb3elaee6nduv
> [3] (Dec 2011) http://tomcat.markmail.org/thread/llawwzb4jxgwbt6z
> 
> +0. It is a bit of a pity, but I would not oppose the change.
> 
> I'd say that if we go this tight security way, then I think we should
> remove most of "Powered by" page (maybe all besides articles) and do
> not bother maintaining it.
> 
> The last time [3] people were saying that that page is needed.
> 
> 
> If mailing list is the target, maybe configure a separate mailing list
> for wiki edit notifications, which is not so widely mirrored as the
> dev one?

Most of what I have seen recently are folks creating new "personal"
pages and dropping a link on them. Perhaps we can simply lock-down
page-creation to a set of users, but still allow edits to existing pages?

-chris



signature.asc
Description: OpenPGP digital signature

Re: Adding Connectors

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steffen,

I think this should be discussed on the users' list. I'm cross-posting
this message one time for that purpose. See below.

On 3/21/13 9:59 AM, Steffen Heil (Mailinglisten) wrote:
> I have a servlet that creates a new Connector and adds it to the
> Service it is running in. However it does this during startup of
> the Servlet.
> 
> Obviously the connectors specified in the server.xml are added and
> NOT started. So tomcat starts its connectors as last thing after
> loading other components (including servlets).
> 
> Therefor I get: INFO: The start() method was called on component
> [Connector[org.apache.coyote.http11.Http11NioProtocol-1001]] after
> start() had already been called. The second call will be ignored.
> 
> Now, that would not be a problem for me, but I would like to add my
> connectors without starting them, so that at the end of startup
> sequence tomcat would start them as it does for all other
> connectors defined in server.xml.
> 
> But I cannot. The following code shows the issue.
> 
> 
> package org.apache.catalina.core;
> 
> public class StandardService extends LifecycleMBeanBase implements
> Service {
> 
> public void addConnector(Connector connector) { ... if
> (getState().isAvailable()) { try { connector.start(); } catch
> (LifecycleException e) { 
> log.error(sm.getString("standardService.connector.startFailed",connector),
> e); } } ... }
> 
> }
> 
> 
> During servlet initialization getState().isAvailable() returns
> true, therefore the connector is started right away. Also, during
> start, if anything is accessed before the tomcat startup sequence
> completes, I get the following:
> 
> Mar 21, 2013 1:36:34 PM org.apache.tomcat.util.net.NioEndpoint
> processSocket SEVERE: Error allocating socket processor 
> java.lang.IllegalStateException: StandardThreadPool not started. at
> org.apache.catalina.core.StandardThreadExecutor.execute(StandardThreadExecutor.java:173)
>
> 
at
org.apache.tomcat.util.net.NioEndpoint.processSocket(NioEndpoint.java:728)
> at
> org.apache.tomcat.util.net.NioEndpoint$Poller.processKey(NioEndpoint.java:1257)
>
> 
at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1193)
> at java.lang.Thread.run(Thread.java:662)
> 
> 
> This is probably, because my connector is already started, while
> the Executor is not.
> 
> 
> Now, my two questions:
> 
> 
> a) Can I assume that those error messages do no harm?
> 
> b) Isn't this a bug, that tomcat starts connectors while it regards
> all self-created connectors as not started?

What happens if you set bindOnInit=false in server.xml? That may only
affect those connectors defined there, but it may also put Tomcat into
a state where none of the Connectors are started until after webapp
initialization.

- -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/

iQIcBAEBCAAGBQJRSx1PAAoJEBzwKT+lPKRYDvcP/2+PTj7cA4ebJ2wcYV0CzLI8
y6qc+aDvls6BJf84lzzOtbZrGEiWvbGwp/dtNmHBmRJkOShlF790qqdKfhglhVCx
HckjEi0bpQLLv9IXB3y/5+byDITM43SAtgI2otUhaKy/vonE/TuHbE91pQZIZV4B
jHWpYUIhDXO6fzwfF69/mjEny6ekg1QtGfDTYVqG8Qle4HpXCEZFpSMAo8W97n2n
s6AMD/lbf2NRXbyExeV9vLcLd8XKXcxm4hUrOxiDVeEXk3OFUcoLR3+yLYVD4gfV
C7hUvmWdhiWPVjnAaTqY+JYHdgSTXfDdLg0dswtHtzKKRVxky0aR3ydDiZ3PqHR+
lGDZFJLfFGN6KXhYUMUhgnV4R0Mr6084zwCs5Af4LTP6yaeaeEtP7fQHFbQbZezr
gpA0+gaw3LWTJJWZw/hb4VHRt23XB+0N07xgHAL0g5FpPxPk0l1LxOzGPEtEW1vo
M35xTjA6eZQmYa9NGTW4gWQakSdjq+m341+OrFZmjmU4QMAPakcqfnzAS/IxA3TR
CaL2nw9b4kejDYBIxdI++CpOnTBnB4xTd+nnbD6XqMt0UUsm9kacNy4LkzJnwht/
hLZsmUpWBDCID2b3A8nB80ODDcnCxcvl7+0I+39IR5pWdWzArOTH1f32L9bZUP0j
KVPBk5kgar7W6/txeKsz
=sfnh
-END PGP SIGNATURE-

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

Re: OT: Will web containers be required to implement WebSockets

[Christopher Schultz]

Nick,

On 3/21/13 10:17 AM, Nicholas Williams wrote:
> I know that WebSockets will be a part of the Java EE 7 specification
> for full application servers. But will web containers also be required
> to implement this? Or will it be optional, and Tomcat is just being
> nice? :-)

Do you mean "will the J2EE 7 Web Profile include Websocket?"

I think it would be foolish for J2EE 7 Web Profile /not/ to include
Websocket, since it's really distinct from all other kinds of
J2EE-related stuff and squarely falls into the web-related pool of slop.

As for Tomcat's pursuit of Websocket: our community has demanded it, so
we are providing it, regardless of any standards body. Tomcat has
cherry-picked various J2EE standards to implement and AFAICT isn't
required to do anything other than make its users happy. Obviously,
making users happy means properly supporting the Servlet and JSP specs
which of course requires the EL spec to be implemented as well. At this
point, including Websocket is another of those things we must do to keep
our users happy.

There is a line, though, and I'm not sure if everyone exactly agrees
where that is. Clearly, Tomcat will never implement EJB. It's been great
that TomEE has stepped-in and created a product that bundles existing
J2EE services that a lot of folks want/need but don't want to bother
with the heft of WebSphere, JBoss, etc.

-chris



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1458187 - in /tomcat/trunk/java/org/apache/tomcat/util/http/fileupload: ./ util/mime/Base64Decoder.java util/mime/MimeUtility.java

[Christopher Schultz]

Konstantin,

On 3/21/13 10:18 AM, Konstantin Kolinko wrote:
> 2013/3/21 Christopher Schultz :
>> Konstantin,
>>
>> On 3/19/13 6:09 AM, Konstantin Kolinko wrote:
  } else if (data[end - 1] == PADDING) {
 -b1 = DECODING_TABLE[data[end - 4]];
 -b2 = DECODING_TABLE[data[end - 3]];
 -b3 = DECODING_TABLE[data[end - 2]];
 +b1 = DECODING_TABLE[data[end - MASK_4BITS]];
 +b2 = DECODING_TABLE[data[end - BYTES_PER_UNENCODED_BLOCK]];
 +b3 = DECODING_TABLE[data[end - MASK_2BITS]];
>>>
>>>
>>> ??? (A question to commons team though).
>>>
>>> I do not know FileUpload code, but from my generic knowledge of base64,
>>> the above replacement is suspicious.
>>>
>>> I think the above replacement of 2,3,4 with constants is incorrect.
>>> They are just indexes in the table.
>>
>> +1
>>
>> The code will still run properly but if the constants were ever to be
>> changed (which they shouldn't!), chaos would ensue. It's also misleading
>> to read the code.
>>
> 
> This particular change has been reverted in Commons Fileupload in one
> of subsequent commits [1], which Mark picked up in subsequent merges.
> The final patch that was ported to Tomcat 7 did not have anything of
> the above.

Sorry for the noise... just catching up on the dev list this morning.

-chris



signature.asc
Description: OpenPGP digital signature

svn commit: r1459346 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/ant/ java/org/apache/catalina/authenticator/ java/org/apache/catalina/realm/ java/org/apache/catalina/util/ java/org/apache

[markt]

Author: markt
Date: Thu Mar 21 15:05:54 2013
New Revision: 1459346

URL: http://svn.apache.org/r1459346
Log:
Switch to Base64 encoder/decoder from Commons Codec.
Performance testing shows it to be ~25-30x slower than Tomcat's implementation.

Added:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/codec/
  - copied from r1459218, tomcat/trunk/java/org/apache/tomcat/util/codec/
Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java

tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java

tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/SpnegoAuthenticator.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/realm/JNDIRealm.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/util/Base64.java
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/codec/binary/Base64.java

tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/fileupload/   (props 
changed)

tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/fileupload/util/mime/MimeUtility.java

tomcat/tc7.0.x/trunk/test/org/apache/catalina/authenticator/TestNonLoginAndBasicAuthenticator.java

tomcat/tc7.0.x/trunk/test/org/apache/catalina/authenticator/TestSSOnonLoginAndBasicAuthenticator.java

tomcat/tc7.0.x/trunk/test/org/apache/catalina/util/TesterBase64Performance.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1459218,1459223,1459289

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java?rev=1459346&r1=1459345&r2=1459346&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java 
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java 
Thu Mar 21 15:05:54 2013
@@ -27,9 +27,8 @@ import java.net.HttpURLConnection;
 import java.net.URL;
 import java.net.URLConnection;
 
-import javax.xml.bind.DatatypeConverter;
-
 import org.apache.tomcat.util.buf.B2CConverter;
+import org.apache.tomcat.util.codec.binary.Base64;
 import org.apache.tools.ant.BuildException;
 import org.apache.tools.ant.Project;
 
@@ -202,7 +201,7 @@ public abstract class AbstractCatalinaTa
 
 // Set up an authorization header with our credentials
 String input = username + ":" + password;
-String output = DatatypeConverter.printBase64Binary(
+String output = Base64.encodeBase64String(
 input.getBytes(B2CConverter.ISO_8859_1));
 hconn.setRequestProperty("Authorization",
  "Basic " + output);

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java?rev=1459346&r1=1459345&r2=1459346&view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/BasicAuthenticator.java
 Thu Mar 21 15:05:54 2013
@@ -24,7 +24,6 @@ import java.security.Principal;
 
 import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpServletResponse;
-import javax.xml.bind.DatatypeConverter;
 
 import org.apache.catalina.connector.Request;
 import org.apache.catalina.deploy.LoginConfig;
@@ -33,6 +32,7 @@ import org.apache.juli.logging.LogFactor
 import org.apache.tomcat.util.buf.B2CConverter;
 import org.apache.tomcat.util.buf.ByteChunk;
 import org.apache.tomcat.util.buf.MessageBytes;
+import org.apache.tomcat.util.codec.binary.Base64;
 
 
 
@@ -136,10 +136,10 @@ public class BasicAuthenticator
 if (authorizationBC.startsWithIgnoreCase("basic ", 0)) {
 authorizationBC.setOffset(authorizationBC.getOffset() + 6);
 
-// Use the StringCache as these will be the same between
-// requests
-String encoded = authorizationBC.toStringInternal();
-byte[] decoded = DatatypeConverter.parseBase64Binary(encoded);
+byte[] decoded = Base64.decodeBase64(
+authorizationBC.getBuffer(),
+authorizationBC.getOffset(),
+authorizationBC.getLength());
 
 // Get username and password
 int colon = -1;

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/

Re: svn commit: r1459346 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/ant/ java/org/apache/catalina/authenticator/ java/org/apache/catalina/realm/ java/org/apache/catalina/util/ java/org/ap

[Mark Thomas]

On 21/03/2013 15:05, ma...@apache.org wrote:
> Author: markt
> Date: Thu Mar 21 15:05:54 2013
> New Revision: 1459346
> 
> URL: http://svn.apache.org/r1459346
> Log:
> Switch to Base64 encoder/decoder from Commons Codec.
> Performance testing shows it to be ~25-30x slower than Tomcat's 
> implementation.

I'm currently doing some work to figure out:
a) how much of an issue this really is
b) what we can do about

There is a trade-off here. The closer we keep to the Commons
implementation the easier it will be to keep it up to date with bug
fixes etc.

Mark


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

[Bug 54738] New: WebSocket messages does not set lastAccessTime to session, and after the session.maxIntervalTimeout() my session is deleted

[bugzilla]

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

Bug ID: 54738
   Summary: WebSocket messages does not set lastAccessTime to
session, and after the session.maxIntervalTimeout() my
session is deleted
   Product: Tomcat 7
   Version: 7.0.37
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P2
 Component: Servlet & JSP API
  Assignee: dev@tomcat.apache.org
  Reporter: radu.m.toa...@gmail.com
Classification: Unclassified

WebSocket messages does not set lastAccessTime to session, and after the
session.maxIntervalTimeout() my session is deleted

I have attributes on httpsession, and I check them every time I want to send a
message to browser-client through WebSocket.

If the client is not making any other requests to page like AJAX or open
another link, his sessions is deleted along with the attributes on the session.

   I have implemented ping-pong from client to server on WebSocket, I could
reset the lastAccessTime of the session there, but the problem is that there is
no visibility to session's lastAccessedTime so there is no way you can change
it. The framework should do that for you.

I belive that a reset must be added whenever a message is received/send to/from
client through WebSocket.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 54738] WebSocket messages does not set lastAccessTime to session, and after the session.maxIntervalTimeout() my session is deleted

[bugzilla]

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

Radu Toader  changed:

   What|Removed |Added

 CC||radu.m.toa...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: OT: Will web containers be required to implement WebSockets

[Nick Williams]

On Mar 21, 2013, at 9:54 AM, Christopher Schultz wrote:

> Nick,
> 
> On 3/21/13 10:17 AM, Nicholas Williams wrote:
>> I know that WebSockets will be a part of the Java EE 7 specification
>> for full application servers. But will web containers also be required
>> to implement this? Or will it be optional, and Tomcat is just being
>> nice? :-)
> 
> Do you mean "will the J2EE 7 Web Profile include Websocket?"

No, I meant web container, which I could mention is synonymous with servlet 
container [1]. Tomcat does not implement Web Profile. It is a web 
container/servlet container. The primary reason I'm wondering if web containers 
will be required to implement WebSockets is due to the integration with the new 
HttpServletRequest#upgrade(). Obviously this was added to facilitate 
WebSockets, but that doesn't mean that WebSockets will be required for web 
containers.

> 
> I think it would be foolish for J2EE 7 Web Profile /not/ to include
> Websocket, since it's really distinct from all other kinds of
> J2EE-related stuff and squarely falls into the web-related pool of slop.

However, you remind me of Web Profile, so I would /also/ like to know if Web 
Profile will require WebSockets. I agree with you that it would be foolish not 
to.

> 
> As for Tomcat's pursuit of Websocket: our community has demanded it, so
> we are providing it, regardless of any standards body. Tomcat has
> cherry-picked various J2EE standards to implement and AFAICT isn't
> required to do anything other than make its users happy. Obviously,
> making users happy means properly supporting the Servlet and JSP specs
> which of course requires the EL spec to be implemented as well. At this
> point, including Websocket is another of those things we must do to keep
> our users happy.

Agreed. :-)

> 
> There is a line, though, and I'm not sure if everyone exactly agrees
> where that is. Clearly, Tomcat will never implement EJB. It's been great
> that TomEE has stepped-in and created a product that bundles existing
> J2EE services that a lot of folks want/need but don't want to bother
> with the heft of WebSphere, JBoss, etc.
> 
> -chris
> 

[1] http://en.wikipedia.org/wiki/Web_container
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 54738] WebSocket messages does not set lastAccessTime to session, and after the session.maxIntervalTimeout() my session is deleted

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Mark Thomas  ---
This should be raised with the WebSocket EG. It is not an implementation issue
(it might become one if the spec is changed).

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: [Bug 54721] New: RemoteEndpoint blocks indefinitely if sendObject called with BinaryStream of TextStream encoders

[Nick Williams]

On Mar 21, 2013, at 9:07 AM, Christopher Schultz wrote:

> Nick,
> 
> On 3/18/13 6:03 PM, Nick Williams wrote:
>> 
>> I've been busy fleshing out all kinds of problems. :-)
> 
> Careful: you might inadvertently become the babysitter of Tomcat's
> Websocket implementation.

Careful: you might be talking to a future committer. ;-)

I'm actually surprised how much I've enjoyed contributing code to Tomcat in the 
last couple of months, despite the hoops I've had to jump through since I'm not 
a committer. I intend to do more in the future. Once this book is done, I have 
several ideas I'm working on. :-)

> 
> -chris
> 


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

Re: svn commit: r1459346 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/ant/ java/org/apache/catalina/authenticator/ java/org/apache/catalina/realm/ java/org/apache/catalina/util/ java/org/ap

[Mark Thomas]

On 21/03/2013 15:07, Mark Thomas wrote:
> On 21/03/2013 15:05, ma...@apache.org wrote:
>> Author: markt
>> Date: Thu Mar 21 15:05:54 2013
>> New Revision: 1459346
>>
>> URL: http://svn.apache.org/r1459346
>> Log:
>> Switch to Base64 encoder/decoder from Commons Codec.
>> Performance testing shows it to be ~25-30x slower than Tomcat's 
>> implementation.
> 
> I'm currently doing some work to figure out:
> a) how much of an issue this really is

Hmm. Testing with ab suggests this adds ~5% to the mean request
processing time when I tune the test for max throughput. Not good.

> b) what we can do about

I have some ideas. I'll see how far they get me.

Mark


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

[Bug 54738] WebSocket messages does not set lastAccessTime to session, and after the session.maxIntervalTimeout() my session is deleted

[bugzilla]

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

--- Comment #2 from Radu Toader  ---
At least there should be a way to setLastAccessed time to a session.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: WebServlets and HttpSessions (again) ... How to update last accessed time?

[Nick Williams]

On Mar 20, 2013, at 5:24 PM, Nick Williams wrote:

> Reading through the expert mailing list for the WebSocket spec, I gather that 
> the experts did not feel it appropriate to update the last access time for 
> HttpSession objects when messages are received. I DO agree with this; there's 
> no way to know what the user really wants here, and it could be a security 
> vulnerability to arbitrarily update the last accessed time.
> 
> However, I CAN imagine many scenarios where a developer DOES want to update 
> the HttpSession last access time regularly. Consider a customer support chat 
> application, where a user may be chatting with support for many minutes or 
> even hours. Or a multiplayer online game, where the user is playing for hours 
> at a time. It is very reasonable to expect that the developer may want to 
> update the HttpSession's last access time every time a message is received 
> (or at some other developer-defined interval) so that the user is not logged 
> out (assuming the developer is using HttpSession for login/logout). Since, in 
> my personal use, I was already grabbing the HttpSession from the handshake 
> and associating it with the Session onOpen, I just decided I'd manually 
> update the HttpSession's last access time each time a message came in. Wrong. 
> HttpSession doesn't have a way to update the last access time.
> 
> My thoughts are that there are two different approaches that could be taken 
> to address the inability of the developer to keep the session alive:
> 
> 1) Update the Servlet spec to add HttpSession#updateLastAccessTime(), which 
> would be useful for more than just WebSockets, but it may be (probably is) 
> too late to get it in Servlet 3.1 (and thus we'd have to wait another 3 years 
> for it).
> 2) Update the WebSocket spec to add 
> Session#updateHttpSessionLastAccessTime(), but then that would be useful only 
> for WebSockets (at that point, you might as well also add a 
> Session#getHttpSession() method, which does not exist either and so makes 
> getting the HttpSession tricky).
> 
> Before I file an improvement JIRA against either of these projects, I wanted 
> to get some feedback from the developers here (Mark) on what they thought the 
> best/right approach was based on their experience and previous discussions on 
> the expert list. Of course, if I'm overlooking some other way to update the 
> last access time or otherwise keep the session from expiring, please let me 
> know.
> 
> Nick

And, as expected, I am not the only one wondering about this [1]. Based on 
Mark's response to that bug, I'm have raised this issue as a WebSocket API JIRA 
[2]. Mark, if you could get some a discussion going in the EG about this issue, 
that would be great. =D I'll keep my eye on the EG mailing list archive to see 
how the discussion goes.

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=54738
[2] http://java.net/jira/browse/WEBSOCKET_SPEC-175
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

buildbot success in ASF Buildbot on tomcat-7-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-7-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/tomcat-7-trunk/builds/1141

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-vm_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1459346
Blamelist: markt

Build succeeded!

sincerely,
 -The Buildbot

[Bug 54738] WebSocket messages does not set lastAccessTime to session, and after the session.maxIntervalTimeout() my session is deleted

[bugzilla]

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

--- Comment #3 from Nick Williams  ---
I have created an issue for this on the WebSocket API project JIRA [1]. You
will need to login/register on java.net to view and/or watch it for updates.
Registration is free.

[1] http://java.net/jira/browse/WEBSOCKET_SPEC-175

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

svn commit: r1459389 - /tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

[markt]

Author: markt
Date: Thu Mar 21 16:37:49 2013
New Revision: 1459389

URL: http://svn.apache.org/r1459389
Log:
Improve performance for typical use cases by roughly an order of magnitude

Modified:
tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java?rev=1459389&r1=1459388&r2=1459389&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java Thu 
Mar 21 16:37:49 2013
@@ -140,7 +140,7 @@ public abstract class BaseNCodec impleme
  * Defines the default buffer size - currently {@value}
  * - must be large enough for at least one encoded block+separator
  */
-private static final int DEFAULT_BUFFER_SIZE = 8192;
+private static final int DEFAULT_BUFFER_SIZE = 128;
 
 /** Mask used to extract 8 bits, used in decoding bytes */
 protected static final int MASK_8BITS = 0xff;



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

svn commit: r1459390 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

[markt]

Author: markt
Date: Thu Mar 21 16:38:39 2013
New Revision: 1459390

URL: http://svn.apache.org/r1459390
Log:
Improve performance for typical use cases by roughly an order of magnitude

Modified:
tomcat/tc7.0.x/trunk/   (props changed)

tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1459389

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java?rev=1459390&r1=1459389&r2=1459390&view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java 
(original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java 
Thu Mar 21 16:38:39 2013
@@ -140,7 +140,7 @@ public abstract class BaseNCodec impleme
  * Defines the default buffer size - currently {@value}
  * - must be large enough for at least one encoded block+separator
  */
-private static final int DEFAULT_BUFFER_SIZE = 8192;
+private static final int DEFAULT_BUFFER_SIZE = 128;
 
 /** Mask used to extract 8 bits, used in decoding bytes */
 protected static final int MASK_8BITS = 0xff;



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

Re: svn commit: r1459389 - /tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

[Nick Williams]

On Mar 21, 2013, at 11:37 AM, ma...@apache.org wrote:

> Author: markt
> Date: Thu Mar 21 16:37:49 2013
> New Revision: 1459389
> 
> URL: http://svn.apache.org/r1459389
> Log:
> Improve performance for typical use cases by roughly an order of magnitude
> 
> Modified:
>tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
> 
> Modified: 
> tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java?rev=1459389&r1=1459388&r2=1459389&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java 
> (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java Thu 
> Mar 21 16:37:49 2013
> @@ -140,7 +140,7 @@ public abstract class BaseNCodec impleme
>  * Defines the default buffer size - currently {@value}
>  * - must be large enough for at least one encoded block+separator
>  */
> -private static final int DEFAULT_BUFFER_SIZE = 8192;
> +private static final int DEFAULT_BUFFER_SIZE = 128;
> 
> /** Mask used to extract 8 bits, used in decoding bytes */
> protected static final int MASK_8BITS = 0xff;

Wow. THAT change alone had an order of magnitude impact? That's fascinating...
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1459395 - /tomcat/tc7.0.x/trunk/test/org/apache/catalina/util/TesterBase64Performance.java

[markt]

Author: markt
Date: Thu Mar 21 16:43:48 2013
New Revision: 1459395

URL: http://svn.apache.org/r1459395
Log:
Add an order of magnitude to check results are roughly the same (they are)

Modified:

tomcat/tc7.0.x/trunk/test/org/apache/catalina/util/TesterBase64Performance.java

Modified: 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/util/TesterBase64Performance.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/catalina/util/TesterBase64Performance.java?rev=1459395&r1=1459394&r2=1459395&view=diff
==
--- 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/util/TesterBase64Performance.java 
(original)
+++ 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/util/TesterBase64Performance.java 
Thu Mar 21 16:43:48 2013
@@ -29,7 +29,7 @@ import org.apache.tomcat.util.buf.CharCh
 
 public class TesterBase64Performance {
 
-private static final int SIZE = 100;
+private static final int SIZE = 1000;
 
 @SuppressWarnings("deprecation")
 @Test



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

RE: svn commit: r1459389 - /tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

[Caldarale, Charles R]

> From: Nick Williams [mailto:nicho...@nicholaswilliams.net] 
> Subject: Re: svn commit: r1459389 - 
> /tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

> > -private static final int DEFAULT_BUFFER_SIZE = 8192;
> > +private static final int DEFAULT_BUFFER_SIZE = 128;

> Wow. THAT change alone had an order of magnitude impact? That's fascinating...

And counterintuitive.  Bigger is not always better, it seems.  Is there a quick 
explanation, or should we go read the code?

 - 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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1459389 - /tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java

[Mark Thomas]

On 21/03/2013 16:57, Caldarale, Charles R wrote:
>> From: Nick Williams [mailto:nicho...@nicholaswilliams.net] 
>> Subject: Re: svn commit: r1459389 - 
>> /tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
> 
>>> -private static final int DEFAULT_BUFFER_SIZE = 8192;
>>> +private static final int DEFAULT_BUFFER_SIZE = 128;
> 
>> Wow. THAT change alone had an order of magnitude impact? That's 
>> fascinating...
> 
> And counterintuitive.  Bigger is not always better, it seems.  Is there a 
> quick explanation, or should we go read the code?

The test was doing 1,000,000 iterations of a Base64 decode and this was
the default buffer size for the result. A new buffer was being created
on every iteration and it was much bigger than necessary - both for the
test and for normal use cases.

I didn't look into whether allocation or GC was taking the time. I
suspect allocation.

Mark


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

[Tomcat Wiki] Trivial Update of "Georgiana" by Georgiana

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "Georgiana" page has been changed by Georgiana:
http://wiki.apache.org/tomcat/Georgiana

New page:
The name of the author is Lyndon Gamino. Business office supervising is 
actually he really does for a residing and he is not going to change it out any 
time soon.<>
He or she currently hails from Wisconsin. Just what he loves performing is to 
keep bees but he could be desperate for time for it. He's not godd from design 
however, you should check his website: 
http://Www.Moneymakingparents.com/How-To-Proceed-In-Case-A-Business-Performs-Unethical-Procedures.html

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

[Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "LocalBadContent" page has been changed by ChuckCaldarale:
http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=97&rev2=98

  mathsolutions\.50webs\.com
  maxref\.co\.cc
  meratolreviewblog\.com
+ moneymakingparents\.com
  mnsp\.cn
  muscleandfitness\.net
  myeurowatches\.com

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

buildbot failure in ASF Buildbot on tomcat-7-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-7-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/tomcat-7-trunk/builds/1142

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-vm_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1459390
Blamelist: markt

BUILD FAILED: failed compile_1

sincerely,
 -The Buildbot

Can we get another Maven 8.0.0.SNAPSHOT?

[Nick Williams]

Been a week since the last snapshot. LOTS of big WebSocket changes since then, 
including a fix for a problem with the core artifact JAR. Can we get another 
snapshot build sometime today?

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

[Bug 54740] New: Aggressive scan for ServerEndpointConfig

[bugzilla]

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

Bug ID: 54740
   Summary: Aggressive scan for ServerEndpointConfig
   Product: Tomcat 8
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: rstoyanc...@yahoo.com
Classification: Unclassified

The SCI scan picks up a ServerEndpointConfig declaration even if is package
private, a private inner class, or an anonymous class. This may not be
specifically related to the websocket support but rather to the way the SCI
scan works. Either way there doesn't seem to be a way to "hide" a class from
the scan short of turning it off completely. Is it by design? I could not find
any references to that level of detail in the spec. It seems rather aggressive.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: [Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale

[sebb]

On 21 March 2013 17:48, Apache Wiki  wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for 
> change notification.
>
> The "LocalBadContent" page has been changed by ChuckCaldarale:
> http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=97&rev2=98

By the way, as per [1], if you update the master BadContent page at
[2] instead (or as well), the prohibition will be applied to all
MoinMoin Wikis worldwide (and of course all ASF Wikis).

[1] http://wiki.apache.org/general/OurWikiFarm#BadContent
[2] http://master.moinmo.in/BadContent

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

svn commit: r1459523 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

[markt]

Author: markt
Date: Thu Mar 21 21:01:32 2013
New Revision: 1459523

URL: http://svn.apache.org/r1459523
Log:
Fix a JVM crash with the unit tests on Windows.
Only add the socket back to the poller if the poller did not report an error in 
the previous poll.

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1459523&r1=1459522&r2=1459523&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Thu Mar 21 
21:01:32 2013
@@ -1629,9 +1629,6 @@ public class AprEndpoint extends Abstrac
 AprSocketWrapper wrapper = connections.get(
 Long.valueOf(desc[n*2+1]));
 wrapper.pollerFlags = wrapper.pollerFlags & 
~((int) desc[n*2]);
-if (wrapper.pollerFlags != 0) {
-add(desc[n*2+1], 1, wrapper.pollerFlags);
-}
 // Check for failed sockets and hand this 
socket off to a worker
 if (wrapper.isComet()) {
 // Event processes either a read or a 
write depending on what the poller returns
@@ -1643,11 +1640,17 @@ public class AprEndpoint extends Abstrac
 destroySocket(desc[n*2+1]);
 }
 } else if ((desc[n*2] & Poll.APR_POLLIN) 
== Poll.APR_POLLIN) {
+if (wrapper.pollerFlags != 0) {
+add(desc[n*2+1], 1, 
wrapper.pollerFlags);
+}
 if (!processSocket(desc[n*2+1], 
SocketStatus.OPEN_READ)) {
 // Close socket and clear pool
 destroySocket(desc[n*2+1]);
 }
 } else if ((desc[n*2] & Poll.APR_POLLOUT) 
== Poll.APR_POLLOUT) {
+if (wrapper.pollerFlags != 0) {
+add(desc[n*2+1], 1, 
wrapper.pollerFlags);
+}
 if (!processSocket(desc[n*2+1], 
SocketStatus.OPEN_WRITE)) {
 // Close socket and clear pool
 destroySocket(desc[n*2+1]);



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

svn commit: r1459524 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

[markt]

Author: markt
Date: Thu Mar 21 21:03:39 2013
New Revision: 1459524

URL: http://svn.apache.org/r1459524
Log:
Default poller size always needs to be equal to maxConnections

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1459524&r1=1459523&r2=1459524&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Thu Mar 21 
21:03:39 2013
@@ -1298,9 +1298,10 @@ public class AprEndpoint extends Abstrac
 // Adjust poller size so that it won't reach the limit. This is
 // a limitation of XP / Server 2003 that has been fixed in
 // Vista / Server 2008 onwards.
-defaultPollerSize = 1024;
+actualPollerSize = 1024;
+} else {
+actualPollerSize = defaultPollerSize;
 }
-actualPollerSize = defaultPollerSize;
 
 timeouts = new SocketTimeouts(defaultPollerSize);
 
@@ -1335,7 +1336,6 @@ public class AprEndpoint extends Abstrac
 connectionCount = 0;
 addList = new SocketList(defaultPollerSize);
 localAddList = new SocketList(defaultPollerSize);
-
 }
 
 



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

Re: Time for 7.0.39

[Mark Thomas]

On 20/03/2013 20:55, Mark Thomas wrote:
> I plan to get the most recent FileUpload changes (if any), run the unit
> tests, run the TCKs and then tag 7.0.39 so that should happen some time
> early tomorrow if all goes well.

Second attempt.

Unit tests for 7.0.x/trunk both passed. Running the TCKs now. Tag early
tomorrow barring problems / objections.

Mark

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

[Bug 54740] Aggressive scan for ServerEndpointConfig

[bugzilla]

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

--- Comment #1 from Mark Thomas  ---
The Servlet 3.0 scanning mechanism only requires that the class may be loaded.

The WebSocket spec limits @ServerEndpoint to "public, concrete, and have a
public no-args constructor". It seems reasonable to me to limit
ServerEndpointConfig  classes with the same rules.

Discovered ServerEndpointConfig classes may be filters with a
ServerApplicationConfig implementation (section 6.2 of the WebSocket spec).

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: Can we get another Maven 8.0.0.SNAPSHOT?

[Mark Thomas]

On 21/03/2013 18:06, Nick Williams wrote:
> Been a week since the last snapshot. LOTS of big WebSocket changes since 
> then, including a fix for a problem with the core artifact JAR. Can we get 
> another snapshot build sometime today?

In progress. Should be complete in less than an hour from now.

Mark


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

[Bug 54475] SMAP broken in Java 8 for JSP compile

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Mark Thomas  ---
This was a Java issue. I just tested this with jdk1.8.0_b81_x64 and everything
works as expected. I confirmed the major version of the compiled class with
javap.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: Can we get another Maven 8.0.0.SNAPSHOT?

[Nick Williams]

On Mar 21, 2013, at 5:49 PM, Mark Thomas wrote:

> On 21/03/2013 18:06, Nick Williams wrote:
>> Been a week since the last snapshot. LOTS of big WebSocket changes since 
>> then, including a fix for a problem with the core artifact JAR. Can we get 
>> another snapshot build sometime today?
> 
> In progress. Should be complete in less than an hour from now.
> 
> Mark

"Less than an hour from now" turned in to 10 minutes. Hah!

:-) thanks!

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

Re: Use of JAXB api to process Base64 in Tomcat 7 and 8

[sebb]

On 21 March 2013 09:39, Mark Thomas  wrote:
> On 21/03/2013 05:35, Konstantin Kolinko wrote:
>> Hi!
>>
>> Recent Mark's commits in Tomcat 7, 8 replaced custom
>> implementations(*) of base64
>> with use of the following class from JAXB:
>>
>> javax.xml.bind.DatatypeConverter
>>
>> This affects base64 processing in our own classes and in our copy of
>> Commons FileUpload.
>> The original fileupload library in commons was not changed (I do not
>> see [1] change in [2] @1459121).
>>
>> [1] http://svn.apache.org/r1458726
>> [2] 
>> http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java?view=markup
>>
>> First, it seems wrong, as this JAXB API was not designed as a general
>> purpose base64 codec.
>>
>> I hereby -1 on this change, on the following ground:
>
> OK. While I don't agree with you completely, I do agree that it would be
> better to find an alternative solution. I suggest that we copy the
> Base64 decoder/encoder from Commons Codec to a new o.a.tomcat.util.codec
> package and update Tomcat 7 & 8 to use that (and point the deprecation
> markers to this implementation) rather than DatatypeConverter.

Also, there are a couple of fairly basic bugs in the Java 6 method as
currently implemented.
It cannot handle non-ASCII input (codepoints above 127) - instead of
being ignored as non-Base64, they cause AIOOB Exceptions.

As does a trailing pad if it immediately follows a 4-char chunk ending
in a pad, for example:

"Zm8==" => AIOOBE: 1
whereas
"Zm8=A" => OK, ignores the trailing "A"

> I have some other bits and bobs to look at first today but I start on
> this shortly unless anyone raises an objection.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

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

[Bug 54741] New: Add org.apache.catalina.startup.Tomcat#addWebapp(String, URL) method

[bugzilla]

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

Bug ID: 54741
   Summary: Add
org.apache.catalina.startup.Tomcat#addWebapp(String,
URL) method
   Product: Tomcat 8
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: nicho...@nicholaswilliams.net
Classification: Unclassified

Currently Tomcat can only deploy from a WAR file or directory that exists on
the real file system. It would be nice, in an embedded Tomcat (one JAR)
situation, to be able deploy an application using a JAR file resource without
having to first copy that resource to the local file system.

URL war = this.getClass().getResource("/MyApp.war")
Tomcat tomcat = new Tomcat();
...
tomcat.addWebapp("", war);

I tried doing this with the actual URL string, but that did not work:

URL war = this.getClass().getResource("/MyApp.war")
Tomcat tomcat = new Tomcat();
...
tomcat.addWebapp("", war.toString());

SEVERE: Exception fixing docBase for context []
java.io.FileNotFoundException:
C:\Users\Nicholas\Desktop\Project\target\.extract\webapps\jar:file:\C:\Users\Nicholas\Desktop\Project\target\MyApp-1.0.0-SNAPSHOT.jar
(The filename, directory name, or volume label syntax is incorrect)

I had to do this instead:

URL war = this.getClass().getResource("/MyApp.war")
File warFile = new File(extractDirectory, "MyApp.war");
FileUtils.copyURLToFile(war, warFile);
Tomcat tomcat = new Tomcat();
...
tomcat.addWebapp("", warFile.getAbsolutePath());

Of course, that's ignoring all the error-checking logic. It's just a nuisance
to have to do this. Surely, since Tomcat unzips the WAR file anyway, it could
do it on a URL resource instead of having to copy the file to the local
filesystem.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Tomcat Wiki] Trivial Update of "BrianHoy" by BrianHoy

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "BrianHoy" page has been changed by BrianHoy:
http://wiki.apache.org/tomcat/BrianHoy

New page:
Got nothing to say about me really.<>
Yes! Im a member of apache.org.<>
I just hope I am useful in some way .<>
<>
My homepage; [[http://mp3sdown.com/music/download/1/prince.html|mouse click the 
up coming website page]]

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

Re: [Bug 54729] new HttpParser.parseAuthorizationBasic method

[Brian Burch]

On 21/03/13 09:15, Mark Thomas wrote:

On 21/03/2013 07:56, Brian Burch wrote:

On 20/03/13 10:17, bugzi...@apache.org wrote:

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


Sorry I could not reply more quickly, Mark, but I am currently in
Australia and I am probably asleep while you are working.


Not a problem. One of the reasons the ASF insists on using mailing lists
rather than teleconferences is to ensure everyone in all timezones has
an equal chance to participate.


Judging by the flurry of activity in this area, I conclude my change is
no longer necessary and you might want to close this bug report.


You know that better than I. My understanding from reading your report
was that there were a number of issues of which Base64 was just one and
one that was making fixing the others look a little ugly.


Just for completeness, I'll briefly answer your comments and the later
one from Konstantin.


--- Comment #1 from Mark Thomas  ---
Regarding your points:
1. Clarity vs efficiency is always a trade off. It depends how much
efficiency
has been lost. Do you have any performance numbers?


You were quick to write a performance test! Given more time, I would
have explained that I (like Konstantin) did not like the conversion from
MessageBytes to a StringReader, and did not like the way I had created a
second StringReader to parse the decoded the Base64 blob. However, I
felt the performance hit would be small relative to the original
implementation, although it would create extra short-lived instances.

My earlier approach had attempted to push the MessageBytes into the new
HttpParser method, but that meant the parsing logic for BASIC became
very different to that of DIGEST. I couldn't see a way to square the
circle, so I trashed it and started again on a more harmonious path.


The conversions aren't ideal but I think they are a price worth paying
for not having to maintain another Base64 encoder/decoder.


2. I don't see a test case either. I'd rather get any bugs in the
decoder fixed
than put sticking plasters over other bits of code.


I've worked with Base64 implementations a lot in the past, in many
different languages. However, the last time I looked (showing my age!)
the java class was in a sun.* package and well worth avoiding. When I
researched the apache commons version, I did not realise it had been
superseded by javax.xml.bind.DatatypeConverter.

I've just noticed the discussion on the dev list "Use of JAXB api to
process Base64 in Tomcat 7 and 8". I understand the arguments presented
to not use this converter, but if you back out your change and reinstate
org.apache.catalina.util.Base64, then we just go back to where I started
with a broken implementation and no unit tests


I have a plan B in mind for that. More details on that thread.


3. I'd prefer to do this first. That code is only still in the code base
because it support ByteChunk / CharChunk which should allow a more
efficient
interface with the rest of the Tomcat code base. It is probably time
that that
assumption is tested.


I understand. However, the two decode methods look superficially quite
similar to me. There must be scope for refactoring them, writing a
proper unit test suite, and fixing the bugs that I wrapped in my
suggested change to Basic Authenticator. That is a fair amount of work
to achieve little more than just copying another implementation and add
some novel method signatures. Wrappering a robust implementation feels
like a better approach to me.


+1. I'm all for code re-use.


4. It is very unlikely we will be adding Commons Codec as a dependency to
Tomcat. We may do an svn copy and rename much like we have done for
FileUpload
but the usefulness of that depends on the ByteChunk/CharChunk issues
in 3. For
FileUpload I am looking at replacing the decoder with the JVM
implementation.


I didn't follow your FileUpload change closely, especially before you
switched to the DatatypeConverter. Did you basically clone the commons
class? If yes, surely it would be better to put that code in tomcat.util
- FileUpload could use it from there and I suspect the
ByteChunk/CharChunk users would only need some pre/post processing.


The Base64 decoder in FileUpload was copied from Geronimo to Commons and
then I updated Tomcat's copy of FileUpload. That Base64 code has issues
of it's own. Looking for a solution to that prior to the 7.0.39 release
was co-incidental with you looking at Base64 for BASIC auth.


It seems to me there are enough developers (in the same time zone)
working on these issues. I don't have a lot of time to spend on tomcat
at the moment, and it is fairly disheartening to find my efforts in what
seemed to be a quiet backwater have been washed away by a flood. I'll
step back until the dust settles! Let me know if I can help.


I'm sorry you feel that your efforts have been wasted. My intention was
to get you a robust Base64 implementation to work with for the other
improvements you had in mind for

Re: [Bug 54729] new HttpParser.parseAuthorizationBasic method

[Brian Burch]

On 21/03/13 09:33, Julian Reschke wrote:

On 2013-03-21 10:15, Mark Thomas wrote:

...
I'm sorry you feel that your efforts have been wasted. My intention was
to get you a robust Base64 implementation to work with for the other
improvements you had in mind for BASIC auth. If there are other
improvements you have in mind for BASIC auth then your help there would
be much appreciated.
...


Related to that: I'd love to hear feedback on
.


Thanks for pointing it out to me, Julian. At first glance it seems to 
very relevant and interesting. I'll read it carefully and get back to you.


Brian



Best regards, Julian

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



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

[Bug 54693] Add a validationQueryTimeout property

[bugzilla]

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

Daniel Mikusa  changed:

   What|Removed |Added

  Attachment #30045|0   |1
is obsolete||
  Attachment #30086|0   |1
is obsolete||

--- Comment #6 from Daniel Mikusa  ---
Created attachment 30094
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=30094&action=edit
Third patch

Ok, so there was an issue with my second patch.  When "testOnConnect" was
enabled, the validation query specified times out and a connection was
requested, an NPE would be thrown from "setupConnection", where
"con.getHandler()" is called.

protected Connection setupConnection(PooledConnection con) throws
SQLException {
//fetch previously cached interceptor proxy - one per connection
JdbcInterceptor handler = con.getHandler();
if (handler==null) {

This was because "borrowConnection", at the point below, returns null.

public Connection getConnection() throws SQLException {
//check out a connection
PooledConnection con = borrowConnection(-1,null,null);
return setupConnection(con);
}

It returned null because of the following conditions...

  - there are no available connections
  - "borrowConnection(..)" tries to create one by calling
"createConnection(..)"
  - because "testOnConnect" is true, "createConnection(..)" will call
"con.validate(..)" and the validation query will run
  - because we use a slow query and set a low validation query timeout, the
validation query is interrupted
  - "con.validate(..)" returns false
  - this causes "createConnection(..)" to clean up and return null
  - "borrowConnection(..)" returns what was returned by "createConnection(..)",
which is null
  - the null then slips through to "setupConnection(con)" and causes the NPE.

I fixed this by throwing an SQLException in "createConnection(..)" when
"con.validate(..)" returns false.  This causes "createConnection(..)" to clean
up and then re-throw the SQLException.  This exception bubbles up to the user's
code alerting them that the pool cannot create any new connections because the
validation query fails.

A very similar situation happens if the validation query is invalid, such as
"SELECT".  This fixes both conditions.  Unit tests included in the latest
patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "LocalBadContent" page has been changed by ChuckCaldarale:
http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=98&rev2=99

  meratolreviewblog\.com
  moneymakingparents\.com
  mnsp\.cn
+ mp3sdown\.com
  muscleandfitness\.net
  myeurowatches\.com
  mystreyguy

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

[Tomcat Wiki] Trivial Update of "KelseySil" by KelseySil

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "KelseySil" page has been changed by KelseySil:
http://wiki.apache.org/tomcat/KelseySil

New page:
Always exercise the human brain. We wore gold sashes at our high school 
graduations, forever more labeling us in the top5%. You want to study from your 
experiences in daily life, and experience everything in daily life. This 
article explains how phishing works and just how you can easily raise your 
employees (along with your own) awareness in order to avoid be burned. In this 
mode ought to be listening for the end with the curriculum, then your frequency 
must be again raised to some level of wakefulness. <>
<>
Watch movie trailers, find movie times and theaters near you, read reviews plus 
much more in this cool app. It isn't taught there. 110-119:Higher average(High 
Cleverness) (sixteen - Per cent). The second assumes that men and women really 
know whatever they value. Lewis Terman of Standford University took interest 
and standardized the Binet-Simon Scale to the American culture. <>
<>
Therefore, we cannot apply these results to conclusions about suicide in women 
or suicide about those who live in other areas of the world. being tested. 40. 
We will simply refer to I as financial Self-Image. This simple registration can 
meet you using the pool of education resources. <>
<>
To know your individual IQ, search intelligence test on search engines. There 
are sections for verbal knowledge, perception, and spatial knowledge. Verbal 
Reasoning. Their mental age is constantly on the increase with ones 
chronological age due towards the development in the brain, specifically in 
that of your child when brain development is in a vital stage. Writers and 
psychologists almost certainly have this sort of intelligence. <>
<>
But your strengths may also be your weakness. For example, students that 
consider the SAT and score well are considered exceptional students; however, 
trainees that receives average scores, but excels in music or sports or has 
several extracurricular activities is more likely to be accepted in to a 
prestigious college especially if there GPA is desirable. It isn't any 
coincidence that IQ tests reflect the social order. " Now the question that 
must definitely be rattling your minds is - Can this IQ test really determine 
the genius and choose the best in the lot. I always feel great after these 
sessions.<>
<>
Also visit my page :: 
[[http://www.yepcheck.com/chansonwiki/index.php?title=Gebruiker:MaisxWood|visit 
home page]]

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

[Tomcat Wiki] Update of "LocalBadContent" by KonstantinKolinko

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "LocalBadContent" page has been changed by KonstantinKolinko:
http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=99&rev2=100

  xcyouth\.org\.cn
  xn--lnakuten-9za\.se
  yehuo\.cn
+ yepcheck\.com
  yesbo\.de
  yuyu\.vn
  zetaclearx
@@ -213, +214 @@

  zx\.slave\.ca
  zyseo\.com
  # Temporary measures
- (my)[\s]+(name)
+ (my)[\s]+(name|page|web|site)
  youtube\.com
  ##--Apache/LocalBadContent
  

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