svn commit: r1243812 - in /tomcat/trunk/modules/jdbc-pool/src: main/java/org/apache/tomcat/jdbc/pool/interceptor/ test/java/org/apache/tomcat/jdbc/bugs/ test/java/org/apache/tomcat/jdbc/pool/intercept
Author: markt
Date: Tue Feb 14 07:59:54 2012
New Revision: 1243812
URL: http://svn.apache.org/viewvc?rev=1243812&view=rev
Log:
Fix validation errors and an Eclipse warning.=
Add missing AL2 header
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/pool/interceptor/InduceSlowQuery.java
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java?rev=1243812&r1=1243811&r2=1243812&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
Tue Feb 14 07:59:54 2012
@@ -104,7 +104,7 @@ public class SlowQueryReport extends Abs
*/
@Override
public void closeInvoked() {
-
+// NOOP
}
@Override
@@ -186,7 +186,7 @@ public class SlowQueryReport extends Abs
super.reset(parent, con);
if (parent!=null)
queries = SlowQueryReport.perPoolStats.get(parent.getName());
-else
+else
queries = null;
}
Modified:
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java?rev=1243812&r1=1243811&r2=1243812&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java
Tue Feb 14 07:59:54 2012
@@ -1,3 +1,19 @@
+/*
+ * 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.
+ */
package org.apache.tomcat.jdbc.bugs;
import java.sql.CallableStatement;
@@ -9,7 +25,6 @@ import java.util.List;
import org.apache.tomcat.jdbc.pool.ConnectionPool;
import org.apache.tomcat.jdbc.pool.PoolConfiguration;
-import org.apache.tomcat.jdbc.pool.PoolProperties;
import org.apache.tomcat.jdbc.test.DefaultProperties;
@@ -38,8 +53,8 @@ public class Bug51582
datasource.setPoolProperties(p);
datasource.setJdbcInterceptors("org.apache.tomcat.jdbc.pool.interceptor.SlowQueryReportJmx(threshold=200)");
ConnectionPool pool = datasource.createPool();
-
-
+
+
Connection con = pool.getConnection();
Statement st = con.createStatement();
try {
Modified:
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/pool/interceptor/InduceSlowQuery.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/pool/interceptor/InduceSlowQuery.java?rev=1243812&r1=1243811&r2=1243812&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/pool/interceptor/InduceSlowQuery.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/pool/interceptor/InduceSlowQuery.java
Tue Feb 14 07:59:54 2012
@@ -22,7 +22,7 @@ import java.security.SecureRandom;
/**
* @author fhanik
- *
+ *
*/
public class InduceSlowQuery extends AbstractQueryReport {
public static SecureRandom random = new SecureRandom();
@@ -35,7 +35,7 @@ public class InduceSlowQuery extends Abs
try {
int b = random.nextInt(10);
if (b == 0) {
-Thread.sleep((long) random.nextInt(2000));
+Thread.sleep(random.nextInt(2000));
}
} catch (InterruptedException x) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
DO NOT REPLY [Bug 52500] Improve client certificate authentication
https://issues.apache.org/bugzilla/show_bug.cgi?id=52500 --- Comment #23 from Michael 2012-02-14 08:00:19 UTC --- Dear Christopher, Thank you for the fast reply! >That looks great. Thanks! >I'm not sure why either of these are necessary. >I think that UserNameRetriever (maybe a better name >would be X509UserNameRetriever now that I think about it) >interface, the SubjectDNRetriever, and minimal changes to RealmBase. I am confused. According to my understanding, we want to provide the ability to use a user provided X509UserNameRetriever. The purpose of UserNameRetrieverDecorator is to return the user name by the default X509UserNameRetriever if the X509UserNameRetriever provided by a user will return the empty user name. I can move the UserNameRetrieverDecorator code to RealmBase, but I think it is clearer if it is in the different class. Please tell me what you think about it. Regarding UserNameRetrieverConfiguration – it allow easy configuration of a user provided X509UserNameRetriever. I think it is very useful if you create your own X509UserNameRetriever. Please tell me what you think about it. >Note that no changes are required to the Realm interface: the selection of a >UserNameRetriever is an implementation detail that can safely be left in >RealmBase. Ok, got it. > If you do submit another one, please don't include >"@author" tags in the source files: I will provide another patch upon your comments without the @author tag and with X509UserNameRetriever name. >Look at the file webapps/docs/config/realm.xml for the source to >the current "Realm" configuration page: > that's the proper place to document the new configuration > attributes and describe how they can be used. Ok, I will do it. I think to add the new configuration attributes into the Common Attributes section. Please tell me what you think about it. >Basically, no documentation should be required >that isn't part of your patch. So, I will not provide the client certificate description. Correct? Waiting for your comments. Best regards, Michael -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r1243813 - /tomcat/tc7.0.x/trunk/modules/
Author: markt Date: Tue Feb 14 08:01:46 2012 New Revision: 1243813 URL: http://svn.apache.org/viewvc?rev=1243813&view=rev Log: Update to pick up validation fixes and missing AL2 header Modified: tomcat/tc7.0.x/trunk/modules/ (props changed) Propchange: tomcat/tc7.0.x/trunk/modules/ -- --- svn:externals (original) +++ svn:externals Tue Feb 14 08:01:46 2012 @@ -1 +1 @@ -^/tomcat/trunk/modules/jdbc-pool@1243655 jdbc-pool +^/tomcat/trunk/modules/jdbc-pool@1243812 jdbc-pool - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPDY support
Ok, took a bit to get the Apr polling to work and add some minimal tests. Please take another look - in particular to https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java The spdy implementation seems to work with chrome, and the client seems to work with google. Probably still has plenty of bugs - but it's a start. If no objections - I'll start merging the LightProtocol/util.net changes first, than add the spdy server implementation. The spdy client and tests - probably later, I want to clean them up a bit more. Costin On Thu, Feb 2, 2012 at 6:37 AM, Mark Thomas wrote: > On 02/02/2012 14:14, Costin Manolache wrote: > > On Thu, Feb 2, 2012 at 3:33 AM, Mark Thomas wrote: > > > >> On 02/02/2012 10:05, Remy Maucherat wrote: > > >>> Ok, I think your "light protocol" concept to group any "upgraded" > >>> connections is appropriate. > >> > >> Agreed. I'll see if I can wrap this into the generic upgrade process I > >> added as part of the WebSocket support. > >> > > > > My concern with the current upgrade process added for WebSocket is that > > it's very heavy > > in memory use. > > That is what I was agreeing with. I meant that I'll see if I can turn > the current heavy-weight upgrade process into a light-weight one. As I > have said before, this is already on my to-do list. I'll bump it up and > start on it now so you have something to work with in trunk. I can steal > ideas of you along the way :). That way we can hopefully get something > pretty quickly into trunk that works for WebSocket and SPDY. > > > I think it would be better to go the other way - and use the > > LightProtoocl for WebSockets. > > Exactly. > > > If the app needs the original > > Request/Response - we could > > save them, but in most cases I don't think they'll be needed. > > I don;t see the need for that. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: svn commit: r1243508 - in /tomcat/site/trunk: docs/tools.html xdocs/tools.xml
On 13 February 2012 13:50, wrote: > Author: kkolinko > Date: Mon Feb 13 13:50:43 2012 > New Revision: 1243508 > > URL: http://svn.apache.org/viewvc?rev=1243508&view=rev > Log: > Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52652 > Correct typos in tools.html > > s/licence/license/ seems to be GB vs UK. IDE hilights "licence" as > misspelled, event though m dictionary knows this word. [GB vs US?] In the UK, different spellings are used for the noun (licence) and the verb (license). "Get your licence from the licensing authority". See for example the Ofcom website [1] Similarly for practice/practise. However, the US seems to use license for both noun and verb. [1] http://licensing.ofcom.org.uk/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52666] New: EL should coerce String to Integer in equals operation
https://issues.apache.org/bugzilla/show_bug.cgi?id=52666
Bug #: 52666
Summary: EL should coerce String to Integer in equals operation
Product: Tomcat 7
Version: 7.0.25
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: dev@tomcat.apache.org
ReportedBy: knst.koli...@gmail.com
Classification: Unclassified
This issue was reported on the users@ list, thread:
"EL String -> int coercion stopped working after TC 5.5 -> 7.0 upgrade?"
http://tomcat.markmail.org/thread/a7l45meiakblxcvz
http://marc.info/?t=13291893142&r=1&w=2
Original reporter used tag, but it is not necessary to reproduce the
issue.
The issue is reproducible in current 7.0 and 6.0. It works correctly in 5.5.35.
To reproduce,
1. save the following JSP page as ROOT/test.jsp
[[[
${param['foo'] == 1}
${1 == param['foo']}
${1 == (0+param['foo'])}
]]]
2. go to http://localhost:8080/test.jsp?foo=01
Expected result:
true
true
true
Actual result:
false
false
true
This happens for foo=01, 001 etc. The equals result happens only when foo=1
According to EL 2.2 specification chapter 1.8.2 the ==,!= operators have the
following step: "If A or B is Byte, Short, Character, Integer, or Long coerce
both A and B to Long, apply operator". This step should happen earlier than
coercion to String.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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: SPDY support
On Tue, Feb 14, 2012 at 3:29 AM, Costin Manolache wrote: > Ok, took a bit to get the Apr polling to work and add some minimal tests. > > Please take another look - in particular to > https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java > > The spdy implementation seems to work with chrome, and the client seems to > work with google. > Probably still has plenty of bugs - but it's a start. > > If no objections - I'll start merging the LightProtocol/util.net changes > first, than add the spdy server implementation. The spdy client and tests - > probably later, I want to clean them up a bit more. +1. I took a look at the previous rev of the patch, not the latest. Yoav > > Costin > > > On Thu, Feb 2, 2012 at 6:37 AM, Mark Thomas wrote: > >> On 02/02/2012 14:14, Costin Manolache wrote: >> > On Thu, Feb 2, 2012 at 3:33 AM, Mark Thomas wrote: >> > >> >> On 02/02/2012 10:05, Remy Maucherat wrote: >> >> >>> Ok, I think your "light protocol" concept to group any "upgraded" >> >>> connections is appropriate. >> >> >> >> Agreed. I'll see if I can wrap this into the generic upgrade process I >> >> added as part of the WebSocket support. >> >> >> > >> > My concern with the current upgrade process added for WebSocket is that >> > it's very heavy >> > in memory use. >> >> That is what I was agreeing with. I meant that I'll see if I can turn >> the current heavy-weight upgrade process into a light-weight one. As I >> have said before, this is already on my to-do list. I'll bump it up and >> start on it now so you have something to work with in trunk. I can steal >> ideas of you along the way :). That way we can hopefully get something >> pretty quickly into trunk that works for WebSocket and SPDY. >> >> > I think it would be better to go the other way - and use the >> > LightProtoocl for WebSockets. >> >> Exactly. >> >> > If the app needs the original >> > Request/Response - we could >> > save them, but in most cases I don't think they'll be needed. >> >> I don;t see the need for that. >> >> 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
Re: Tomcat web site UI update
Mark, On 2/13/12 5:28 PM, Mark Thomas wrote: > On 13/02/2012 20:11, Christopher Schultz wrote: >> >> IIRC, Pid did a bunch of work toward that end and it was >> ultimately vetoed > > Reference please. That is not my recollection at all. Markmail remembers: http://markmail.org/message/og235cbvrdluiejg > My recollection > was that pid started down this road but hasn't found the time to > finish it, or at least get it to a state where enough was complete > that it could be committed. Konstantin liked it for the ROOT webapp, but not the Tomcat main site. Same with Wesley Acheson. -chris signature.asc Description: OpenPGP digital signature
Re: Custom rules for commons-digester
Mark, On 2/13/12 5:35 PM, Mark Thomas wrote: > On 13/02/2012 22:01, Christopher Schultz wrote: >> Fair enough, but server.xml is processed only once on startup. > > They also process context.xml files and web.xml files. These are the classes I was looking at, which all seem to be related to server.xml, possibly context.xml, but probably not web.xml: java/org/apache/catalina//ha/ClusterRuleSet.java java/org/apache/catalina//realm/MemoryRuleSet.java java/org/apache/catalina//startup/ConnectorCreateRule.java java/org/apache/catalina//startup/ContextRuleSet.java java/org/apache/catalina//startup/CopyParentClassLoaderRule.java java/org/apache/catalina//startup/EngineRuleSet.java java/org/apache/catalina//startup/HostRuleSet.java java/org/apache/catalina//startup/LifecycleListenerRule.java java/org/apache/catalina//startup/NamingRuleSet.java java/org/apache/catalina//startup/RealmRuleSet.java java/org/apache/catalina//startup/SetAllPropertiesRule.java java/org/apache/catalina//startup/SetContextPropertiesRule.java java/org/apache/catalina//startup/SetNextNamingRule.java java/org/apache/catalina//startup/TldRuleSet.java java/org/apache/catalina//startup/WebRuleSet.java >> (This also assumes that maintaining an XML-based configuration >> file represents less effort than maintaining the equivalent source >> code, but as I said previously, it would allow us to purge our >> copies of the Digester from our own svn repo as well, which I see >> as a win). > > Not if we have to replace it with a library that is bigger than the > code we are removing. Maybe we're not talking about the same thing: we already have the digester. It has everything we need. I'm suggesting that these classes are not necessary at all, and can be replaced by capability that the digester already provides. > Further, we can't just use commons-digester. We would have to package > rename it in the same way we do with pool, dbcp, file-upload, bcel etc. That's fine: we can keep using it. Unless something other than simple package-renaming is going on, we can even make the package-renaming part of our build process and remove the sources from svn. > pool and dbcp have had enough bugs that we need to keep up to date > with the latest releases. bcel and fileupload haven't needed to be > updated for bug fixes but we have kept them up to date anyay - mainly > because we can. Digester was forked a long time ago and hasn't been > updated - and hasn't needed to be. Absent a bug that needs fixing, I'm > struggling to find a benefit to updating it. If we have a fork for a reason (none has been specified) then that's fine. I just noticed something and asked about it. > If you have been following trunk, you'll know I am slowing removing > code from digester and modeler that we no longer need. We should end > up with something smaller and more focused at the expense of having to > maintain it. Noting that there have been few/no bugs in that code. Ok. -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1243508 - in /tomcat/site/trunk: docs/tools.html xdocs/tools.xml
Sebb, On 2/14/12 6:56 AM, sebb wrote: > However, the US seems to use license for both noun and verb. License, defense, etc. We're lazy that way. One of the first things we did was to write a new dictionary and remove the "u"s from words like colour. -chris signature.asc Description: OpenPGP digital signature
Re: SPDY support
On 14/02/2012 08:29, Costin Manolache wrote: > Ok, took a bit to get the Apr polling to work and add some minimal tests. > > Please take another look - in particular to > https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java > > The spdy implementation seems to work with chrome, and the client seems to > work with google. > Probably still has plenty of bugs - but it's a start. > > If no objections - I'll start merging the LightProtocol/util.net changes > first, than add the spdy server implementation. The spdy client and tests - > probably later, I want to clean them up a bit more. I am all for adding SPDY support to Tomcat asap including if practical to the 7.0.x branch (noting that there may be some API changes that may prevent this). I think the patch needs more discussion before it is committed to trunk. There are several areas where I am uncomfortable. My key areas of concern are: 1. The patch places Protocol like code (the code that works with the processors) in the endpoints. This significantly muddies the waters between Endpoint, Protocol and Processor which will make future maintenance more difficult. 2. Generic support for upgraded protocols is now available in trunk and SPDY should use this rather than adding SPDY specific upgrade handling. The generic upgrade process supports all three endpoints. Unless I am missing something the current SPDY implementation does not support NIO. 3. Having spent a considerable amount of effort cleaning up the connector code, removing duplicate code, resolving inconsistencies and making it easier to maintain, this patch feels like a step backwards. I am more than happy to see changes to the current generic HTTP upgrade support if it is not currently able to support SPDY. I also have some more cosmetic concerns but those are easily resolved. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat web site UI update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/02/2012 16:21, Christopher Schultz wrote: > Mark, > > On 2/13/12 5:28 PM, Mark Thomas wrote: >> On 13/02/2012 20:11, Christopher Schultz wrote: >>> >>> IIRC, Pid did a bunch of work toward that end and it was >>> ultimately vetoed >> >> Reference please. That is not my recollection at all. > > Markmail remembers: > > http://markmail.org/message/og235cbvrdluiejg That isn't a veto. That is a comment that the layout needs to be cleaner (a comment I agree with). From a style point of view it is a big improvement. Mark > >> My recollection was that pid started down this road but hasn't >> found the time to finish it, or at least get it to a state where >> enough was complete that it could be committed. > > Konstantin liked it for the ROOT webapp, but not the Tomcat main > site. Same with Wesley Acheson. > > -chris > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPOpx3AAoJEBDAHFovYFnnxEIP/Rvhm+UYlVq5enUzWlPbLmWC ZPXcduolPXTVwU2jpIZpSw020677h92kq3dWFL7JSlKNhuHK2C/fS0iI9YYY0Xp/ L9qYf7fvzSvzka7wUFJxFXLwPX6uoDAFwFtr+KSBmus3S206elkCCtILB/z06itA VE31NVqOmXqLq7ZrqsE+4oxzqdkiJV1Cl1uKfR+O0LRJJ39Yl5+LyjThRDWdandC JoWDnJhz/rAWC473X4NWh9q0LXK04uiufvHN3qtq1tbjl2YQ2tkEdcgJilXXCOF/ NgcnvBlWw5R6o9w2Hm7X5xu6YAi8FS1sdWZ5QAihMud23pxT4KCUlK7DSzz2v3Yt vWXEWpbaOD7kFa2c1Wj8dxED4q9ZB8UZZfBkCpG/AGXA1W1DrygPOePkRCNMzBSe L7JWBU5CBJ6avlSnEFMXZIgXg/iVf0bGJUSZr+nL9auoDmJwyN46/HyDeK9ucWyn O6TTzCFgCrcI01k7sVt3vrmtX2/JcvF2O0XMGRYTD/6trFWg96eA7NeOab7Rq90S S6HcEFWGgM52/SibK49yc1J1oQvwNFHzZ2FNINMLBHRI4FjnbLbwxqF8IcZtKs+5 YlbpiiXz+9LIUS8negOTTStXJFqmGaauYMZmIDf7JxFfxozCCQsayifzn+62STrX bx3sI4uobJxVqoNNe++B =F97+ -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52500] Improve client certificate authentication
https://issues.apache.org/bugzilla/show_bug.cgi?id=52500 --- Comment #24 from Christopher Schultz 2012-02-14 17:49:48 UTC --- Michael, > >I'm not sure why either of these are necessary. > >I think that UserNameRetriever (maybe a better name > >would be X509UserNameRetriever now that I think about it) > >interface, the SubjectDNRetriever, and minimal changes to RealmBase. > > I am confused. According to my understanding, we want to provide the ability > to > use a user provided X509UserNameRetriever. > > The purpose of UserNameRetrieverDecorator is to return the user name by the > default X509UserNameRetriever if the X509UserNameRetriever provided by a user > will return the empty user name. I think that any X509UserNameRetriever should be required to provide something that is non-null. There's no reason for "client code" not to extend SubjectDNRetriever and simply delegate to the superclass if the name isn't otherwise found. I don't think it's necessary to provide that fallback logic in Tomcat itself: it the user is going to provide an implementation of an X509UserNameRetriever, then it should be *the* implementation that is used, not one of several that Tomcat has to manage. > Regarding UserNameRetrieverConfiguration – it allow easy configuration of a > user provided X509UserNameRetriever. I think all we need is a single method in the RealmBase class that can accept the name of the class. The default is SubjectDNRetriever, but the user can set it to whatever they want. > I think it is very useful if you create your own X509UserNameRetriever. I'm not sure what it adds. > >Basically, no documentation should be required > >that isn't part of your patch. > > So, I will not provide the client certificate description. Correct? > Waiting for your comments. You don't have to introduce the concept of client certificates, no. I think it's obvious to anyone who is reading this type of documentation what is going on: you are making it possible to customize the information used from the client certificate to produce a username that Tomcat uses. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r1244187 - in /tomcat/site/trunk: docs/sitemap-main.xml docs/sitemap.xml xdocs/sitemap-main.xml xdocs/sitemap.xml
Author: kkolinko Date: Tue Feb 14 19:40:17 2012 New Revision: 1244187 URL: http://svn.apache.org/viewvc?rev=1244187&view=rev Log: Site-map: 1. Add explicit encoding header to sitemap.xml. The FAQ says that the encoding must be UTF-8. 2. Do not use priority values that are less than the default value of 0.5 3. Add schema reference Modified: tomcat/site/trunk/docs/sitemap-main.xml tomcat/site/trunk/docs/sitemap.xml tomcat/site/trunk/xdocs/sitemap-main.xml tomcat/site/trunk/xdocs/sitemap.xml Modified: tomcat/site/trunk/docs/sitemap-main.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/sitemap-main.xml?rev=1244187&r1=1244186&r2=1244187&view=diff == --- tomcat/site/trunk/docs/sitemap-main.xml (original) +++ tomcat/site/trunk/docs/sitemap-main.xml Tue Feb 14 19:40:17 2012 @@ -1,5 +1,9 @@ -http://www.sitemaps.org/schemas/sitemap/0.9";> +http://www.sitemaps.org/schemas/sitemap/0.9"; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; + xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 + http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd"; +> http://tomcat.apache.org/ weekly @@ -15,12 +19,12 @@ http://tomcat.apache.org/whichversion.html monthly -0.6 +0.7 http://tomcat.apache.org/tomcat-6.0-doc/ monthly -0.6 +0.5 http://tomcat.apache.org/tomcat-5.5-doc/ @@ -30,91 +34,91 @@ http://tomcat.apache.org/taglibs/ monthly -0.5 +0.6 http://tomcat.apache.org/maven-plugin.html monthly -0.5 +0.6 http://tomcat.apache.org/connectors-doc/ monthly -0.5 +0.6 http://tomcat.apache.org/native-doc/ monthly -0.5 +0.6 http://tomcat.apache.org/security.html monthly -0.4 +0.6 http://tomcat.apache.org/findhelp.html weekly -0.4 +0.6 http://tomcat.apache.org/migration.html weekly -0.3 +0.6 http://tomcat.apache.org/bugreport.html weekly -0.3 +0.6 http://tomcat.apache.org/lists.html weekly -0.3 +0.6 http://tomcat.apache.org/irc.html weekly -0.2 +0.5 http://tomcat.apache.org/getinvolved.html weekly -0.2 +0.6 http://tomcat.apache.org/svn.html weekly -0.2 +0.6 http://tomcat.apache.org/ci.html weekly -0.2 +0.5 http://tomcat.apache.org/heritage.html weekly -0.1 +0.5 http://tomcat.apache.org/resources.html weekly -0.1 +0.5 http://tomcat.apache.org/oldnews.html weekly -0.1 +0.5 http://tomcat.apache.org/whoweare.html weekly -0.1 +0.5 http://tomcat.apache.org/legal.html weekly -0.1 +0.5 \ No newline at end of file Modified: tomcat/site/trunk/docs/sitemap.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/sitemap.xml?rev=1244187&r1=1244186&r2=1244187&view=diff == --- tomcat/site/trunk/docs/sitemap.xml (original) +++ tomcat/site/trunk/docs/sitemap.xml Tue Feb 14 19:40:17 2012 @@ -1,4 +1,9 @@ -http://www.sitemaps.org/schemas/sitemap/0.9";> + +http://www.sitemaps.org/schemas/sitemap/0.9"; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; + xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 + http://www.sitemaps.org/schemas/sitemap/0.9/siteindex.xsd"; +> http://tomcat.apache.org/sitemap-main.xml Modified: tomcat/site/trunk/xdocs/sitemap-main.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/sitemap-main.xml?rev=1244187&r1=1244186&r2=1244187&view=diff == --- tomcat/site/trunk/xdocs/sitemap-main.xml (original) +++ tomcat/site/trunk/xdocs/sitemap-main.xml Tue Feb 14 19:40:17 2012 @@ -1,5 +1,9 @@ -http://www.sitemaps.org/schemas/sitemap/0.9";> +http://www.sitemaps.org/schemas/sitemap/0.9"; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; + xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 + http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd"; +> http://tomcat.apache.org/ weekly @@ -15,12 +19,12 @@ http://tomcat.apache.org/whichversion.html monthly -0.6 +0.7 http://tomcat.apache.org/tomcat-6.0-doc/ monthly -0.6 +0.5 http://tomcat.apache.org/tomcat-5.5-doc/ @@ -30,91 +34,91 @@ http://tomcat.apache.org/taglibs/ monthly -0.5 +0.6 http://tomcat.apache.org/maven-plugin.html monthly -0.5 +0.6 http://tomcat.apache.org/connectors-doc/ monthly -0.5 +0.6 http://tomcat.apache.org/native-doc/ monthly -0
Re: SPDY support
On Tue, Feb 14, 2012 at 9:36 AM, Mark Thomas wrote: > On 14/02/2012 08:29, Costin Manolache wrote: > > Ok, took a bit to get the Apr polling to work and add some minimal tests. > > > > Please take another look - in particular to > > > https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java > > > > The spdy implementation seems to work with chrome, and the client seems > to > > work with google. > > Probably still has plenty of bugs - but it's a start. > > > > If no objections - I'll start merging the LightProtocol/util.net changes > > first, than add the spdy server implementation. The spdy client and > tests - > > probably later, I want to clean them up a bit more. > > I am all for adding SPDY support to Tomcat asap including if practical > to the 7.0.x branch (noting that there may be some API changes that may > prevent this). > So far I don't think I modified any API in incompatible ways. > > I think the patch needs more discussion before it is committed to trunk. > There are several areas where I am uncomfortable. My key areas of > concern are: > > 1. The patch places Protocol like code (the code that works with the > processors) in the endpoints. This significantly muddies the waters > between Endpoint, Protocol and Processor which will make future > maintenance more difficult. > I can rename LightProtocol to LightHandler (extends Endpoint.Handler ), and Processor to LightConnectionHandler and extend Endpoint.Handler. I don't care much about the name :-), but it is important ( for my and probably other use cases ) for the LightProcessor to be associated with a socket. The current Protocol/Processor are very tied to HTTP and one-request-at-a-time. > 2. Generic support for upgraded protocols is now available in trunk and > SPDY should use this rather than adding SPDY specific upgrade handling. > The generic upgrade process supports all three endpoints. The 'upgrade' process is for accepting a HTTP request and upgrading the protocol - like websocket-over-http does. SPDY is different - the protocol is negotiated in the TLS handshake, there is no HTTP request associated with it. Also: the current upgrade is quite heavy, it holds Requet/Response and a bunch of buffers. I want SPDY to scale to very large number of connections (100k+), so minimal memory is a requirement. Note that there is a 'websocket over SPDY' proposal, so we may need to merge some things. But even with normal websocket - I think there would be value in using the LightProcessor instead of the current upgrade, so you could scale to far more connections. > Unless I am > missing something the current SPDY implementation does not support NIO. > Yes, NIO doesn't make sense for SPDY - we can add the hooks, but I don't see a use case. SPDY ( as implemented by chrome/firefox or servers ) requires a special TLS extension, "next protocol negotiation", which is not implemented in JSSE/NIO. It is available as a patch to current openssl, and is part of the latest openssl. So you must use APR to use SPDY. The second use case for SPDY is as a proxy protocol, between apache ( there is a mod_spdy in progress ) or other NPN-speaking frontend and tomcat, similar with AJP. In this case JIO is more than adequate - SPDY is multiplexing, so a single JIO TCP connection can hold as many HTTP requests ( including comet, websocket, etc ). NIO would be overkill - there is no need for it's non-blocking stuff. > > 3. Having spent a considerable amount of effort cleaning up the > connector code, removing duplicate code, resolving inconsistencies and > making it easier to maintain, this patch feels like a step backwards. > Let me know how I can address your concerns :-) > > I am more than happy to see changes to the current generic HTTP upgrade > support if it is not currently able to support SPDY. > As I mentioned - there are completely different beasts. However the 'light protocol' stuff may be a better interface for websocket connections, in particular if you want extreme scalability. > > I also have some more cosmetic concerns but those are easily resolved. > Let me know :-) Costin > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
DO NOT REPLY [Bug 52627] Segmentation fault in org.apache.tomcat.jni.File.infoGet() native method
https://issues.apache.org/bugzilla/show_bug.cgi?id=52627 Ilya Maykov changed: What|Removed |Added Platform|Macintosh |All -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: SPDY support
BTW - one thing that may simplify the existing code is replacing SocketWrapper with a simple SocketWrapper, and having JIO and APR define their own SocketWrapper - like NIO does. It would also save a lot of Long->long->Long boxing. I'll try replacing Protocol/Processor with Handler, see how it looks. Costin On Tue, Feb 14, 2012 at 9:36 AM, Mark Thomas wrote: > On 14/02/2012 08:29, Costin Manolache wrote: > > Ok, took a bit to get the Apr polling to work and add some minimal tests. > > > > Please take another look - in particular to > > > https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java > > > > The spdy implementation seems to work with chrome, and the client seems > to > > work with google. > > Probably still has plenty of bugs - but it's a start. > > > > If no objections - I'll start merging the LightProtocol/util.net changes > > first, than add the spdy server implementation. The spdy client and > tests - > > probably later, I want to clean them up a bit more. > > I am all for adding SPDY support to Tomcat asap including if practical > to the 7.0.x branch (noting that there may be some API changes that may > prevent this). > > I think the patch needs more discussion before it is committed to trunk. > There are several areas where I am uncomfortable. My key areas of > concern are: > > 1. The patch places Protocol like code (the code that works with the > processors) in the endpoints. This significantly muddies the waters > between Endpoint, Protocol and Processor which will make future > maintenance more difficult. > > 2. Generic support for upgraded protocols is now available in trunk and > SPDY should use this rather than adding SPDY specific upgrade handling. > The generic upgrade process supports all three endpoints. Unless I am > missing something the current SPDY implementation does not support NIO. > > 3. Having spent a considerable amount of effort cleaning up the > connector code, removing duplicate code, resolving inconsistencies and > making it easier to maintain, this patch feels like a step backwards. > > I am more than happy to see changes to the current generic HTTP upgrade > support if it is not currently able to support SPDY. > > I also have some more cosmetic concerns but those are easily resolved. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
DO NOT REPLY [Bug 52669] New: Annotation processing for Servlets/Listeners/Filters is skipped when the web app is not extracted, classes do not have packages and for some embedded scenarios
https://issues.apache.org/bugzilla/show_bug.cgi?id=52669
Bug #: 52669
Summary: Annotation processing for Servlets/Listeners/Filters
is skipped when the web app is not extracted, classes
do not have packages and for some embedded scenarios
Product: Tomcat 7
Version: 7.0.25
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: violet...@apache.org
Classification: Unclassified
Hi,
Annotation processing for Servlets/Listeners/Filters is skipped when:
- the web app is not extracted (screenshot1),
- classes do not have packages (screenshot2),
- for some embedded scenarios (running Tomcat in OSGI environment -
screenshot3)
A test web application is attached - test-web-app.war.
I followed the history and the change that introduces that behaviour is made
with revision 1210012.
org.apache.catalina.startup.ContextConfig
The annotations are processed correctly in all use cases when we have:
1199URL webinfClasses;
1200try {
1201webinfClasses = context.getServletContext().getResource(
1202"/WEB-INF/classes");
1203processAnnotationsUrl(webinfClasses, webXml);
1204} catch (MalformedURLException e) {
1205log.error(sm.getString(
1206"contextConfig.webinfClassesUrl"), e);
1207}
The way how they are processed now is assuming that we will have FirDirContext
always.
1196try {
1197NamingEnumeration listBindings =
1198
context.getResources().listBindings("/WEB-INF/classes");
1199while (listBindings.hasMoreElements()) {
1200Binding binding = listBindings.nextElement();
1201if (binding.getObject() instanceof FileDirContext) {
1202 File webInfCLassDir =
1203 new File(
1204 ((FileDirContext)
binding.getObject()).getDocBase());
1205 processAnnotationsFile(webInfCLassDir, webXml);
1206}
1207}
1208} catch (NamingException e) {
1209log.error(sm.getString(
1210"contextConfig.webinfClassesUrl"), e);
1211}
Regards
Violeta Georgieva
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
DO NOT REPLY [Bug 52669] Annotation processing for Servlets/Listeners/Filters is skipped when the web app is not extracted, classes do not have packages and for some embedded scenarios
https://issues.apache.org/bugzilla/show_bug.cgi?id=52669 --- Comment #1 from violet...@apache.org 2012-02-14 21:40:29 UTC --- Created attachment 28333 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28333 screenshot1 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52669] Annotation processing for Servlets/Listeners/Filters is skipped when the web app is not extracted, classes do not have packages and for some embedded scenarios
https://issues.apache.org/bugzilla/show_bug.cgi?id=52669 --- Comment #2 from violet...@apache.org 2012-02-14 21:41:01 UTC --- Created attachment 28334 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28334 screenshot2 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52669] Annotation processing for Servlets/Listeners/Filters is skipped when the web app is not extracted, classes do not have packages and for some embedded scenarios
https://issues.apache.org/bugzilla/show_bug.cgi?id=52669 --- Comment #3 from violet...@apache.org 2012-02-14 21:41:35 UTC --- Created attachment 28335 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28335 screenshot3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52669] Annotation processing for Servlets/Listeners/Filters is skipped when the web app is not extracted, classes do not have packages and for some embedded scenarios
https://issues.apache.org/bugzilla/show_bug.cgi?id=52669 --- Comment #4 from violet...@apache.org 2012-02-14 21:43:03 UTC --- Created attachment 28336 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28336 test web app -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52666] EL should coerce String to Integer in equals operation
https://issues.apache.org/bugzilla/show_bug.cgi?id=52666 David Rees changed: What|Removed |Added CC||dree...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: SPDY support
On 14/02/2012 20:47, Costin Manolache wrote: > On Tue, Feb 14, 2012 at 9:36 AM, Mark Thomas wrote: > >> On 14/02/2012 08:29, Costin Manolache wrote: >>> Ok, took a bit to get the Apr polling to work and add some minimal tests. >>> >>> Please take another look - in particular to >>> >> https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java >>> >>> The spdy implementation seems to work with chrome, and the client seems >> to >>> work with google. >>> Probably still has plenty of bugs - but it's a start. >>> >>> If no objections - I'll start merging the LightProtocol/util.net changes >>> first, than add the spdy server implementation. The spdy client and >> tests - >>> probably later, I want to clean them up a bit more. >> >> I am all for adding SPDY support to Tomcat asap including if practical >> to the 7.0.x branch (noting that there may be some API changes that may >> prevent this). >> > > So far I don't think I modified any API in incompatible ways. That was more a reference to the generic HTTP upgrade that I thought SPDY should be using. >> I think the patch needs more discussion before it is committed to trunk. >> There are several areas where I am uncomfortable. My key areas of >> concern are: >> >> 1. The patch places Protocol like code (the code that works with the >> processors) in the endpoints. This significantly muddies the waters >> between Endpoint, Protocol and Processor which will make future >> maintenance more difficult. >> > > I can rename LightProtocol to LightHandler (extends Endpoint.Handler ), > and Processor to LightConnectionHandler and extend Endpoint.Handler. > > I don't care much about the name :-), I don't care about the name either. Renaming them does not remove the concern. > but it is important ( for my and > probably other > use cases ) for the LightProcessor to be associated with a socket. Does it need the socket or are input and output streams sufficient? > The current Protocol/Processor are very tied to HTTP and > one-request-at-a-time. Yes and no. The AbstractProtocol has only a minimal understanding of HTTP and AJP and that is a trade-off of not quite ideal design for significantly greater shared code and therefore much less duplication. AbstractProtocol uses only the Processor interface. The concrete implementations are obviously tied to specific protocols and endpoints. A lot of work has gone into trying to separate the generic and protocol / endpoint specific code. It isn't perfect but trunk is a lot cleaner than 7.0.x in this respect and I'd like to see it stay that way. >> 2. Generic support for upgraded protocols is now available in trunk and >> SPDY should use this rather than adding SPDY specific upgrade handling. >> The generic upgrade process supports all three endpoints. > > The 'upgrade' process is for accepting a HTTP request and upgrading the > protocol - like websocket-over-http does. > > SPDY is different - the protocol is negotiated in the TLS handshake, there > is no HTTP request associated with it. Ah. I need to better understand SPDY then. My instinct is still that the implementation should be more like the upgrade implementation than your current proposal but I obviously need to read up on SPDY to see how realistic that is. > Also: the current upgrade is quite heavy, it holds Requet/Response and a > bunch of > buffers. No it doesn't. Take another look at the code. The original implementation did but as I stated at the time my intention was to do some further refactoring to fix that. That refactoring has been complete (and is what resulted in the API changes I was referring to previously). > I want SPDY to scale to very large number of connections (100k+), > so minimal memory is a requirement. No issue there. > Note that there is a 'websocket over SPDY' proposal, so we may need to > merge some things. Having skimmed the latest SPDY draft spec at this point, it looks more like a protocol switch would be required rather than running WebSocket over SPDY. The protocols look to have a lot in common and I'm not sure I see the point of running WebSocket over SPDY. > But even with normal websocket - I think there would be value in using the > LightProcessor instead of the current upgrade, so you could scale to far > more connections. Already done. See above. >> Unless I am >> missing something the current SPDY implementation does not support NIO. >> > > Yes, NIO doesn't make sense for SPDY - we can add the hooks, but I don't > see a use case. Isn't the use case for NIO and SPDY the same as for HTTP? Lots of clients using SPDY would look a lot like lots of HTTP clients using a very long keep-alive wouldn't it? > SPDY ( as implemented by chrome/firefox or servers ) requires a special TLS > extension, "next protocol negotiation", which is not implemented in JSSE/NIO. > It is > available as a patch to current openssl, and is part of the latest openssl. > So you must > use APR to use SPDY. I
Re: SPDY support
On 14/02/2012 21:03, Costin Manolache wrote: > BTW - one thing that may simplify the existing code is replacing > SocketWrapper with a simple SocketWrapper, and having JIO and APR > define their own SocketWrapper - like NIO does. Worth adding to the 8.0.x TODO list. > It would also save a lot of Long->long->Long boxing. That would be nice to see the back off if we can. > I'll try replacing Protocol/Processor with Handler, see how it looks. What you are doing looks very much like the current coyote protocol and processor to me. That approach seems like the better fit to me at the moment. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
JNDIRealm performance
Hi! I wonder whether anyone experienced problems with performance of JNDIRealm. In essence it opens a single connection (this.context) which is not thread-safe. Thus it has to synchronize itself whenever it performs an LDAP query. There is TODO comment, "Support connection pooling", but there is no open issues in Bugzilla, nor I see many discussions of this. Some references: - "JNDIRealm connection pooling" thread from April 2008 http://tomcat.markmail.org/thread/7wisup2chr7d77ht -"Add Connection Pooling to JNDIRealm" issue for Tomcat 4.1 from July 2002 https://issues.apache.org/bugzilla/show_bug.cgi?id=10852 I see a race condition in the open() method. Both open() and close() update this.context, but they are not synchronized. There are several methods that call them, most notably authenticate(String,String). The JNDIRealm#startInternal() pre-opens context at startup, so this would be hard to observe, but once the connection fails I expect a bunch of concurrent calls to open() from authenticate(String,String), with all of them but one being wasted. There is also a little chance that the open() method returns null. Maybe that was the real cause behind BZ 42449 / r539907 and those catch(NullPointerException) statements in JNDIRealm. I think it can be fixed by adding synchronized modifier to both open() and close(), but I am afraid that it will make the things worse. If there will be a simple synchronization it means that the threads will wait on the monitor instead of wasting their time in connection attempt: If the LDAP server disappears it may lock all request processing threads: They will wait on the same monitor and then try two connection attempts each. In HTTPD there is mod_ldap that performs connection pooling and caching, so using HTTPD in front of Tomcat might be a workaround for JNDIRealm performance issues. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244302 - in /tomcat/trunk: build.xml java/org/apache/tomcat/buildutil/CheckEol.java
Author: kkolinko
Date: Wed Feb 15 01:39:55 2012
New Revision: 1244302
URL: http://svn.apache.org/viewvc?rev=1244302&view=rev
Log:
Implement check for correct end-of-line characters in the source files.
I plan to add it as a separate task in Gump.
Running it on Windows currently shows 11 problem files.
Added:
tomcat/trunk/java/org/apache/tomcat/buildutil/CheckEol.java (with props)
Modified:
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1244302&r1=1244301&r2=1244302&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Wed Feb 15 01:39:55 2012
@@ -482,6 +482,30 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/buildutil/CheckEol.java?rev=1244302&view=auto
==
--- tomcat/trunk/java/org/apache/tomcat/buildutil/CheckEol.java (added)
+++ tomcat/trunk/java/org/apache/tomcat/buildutil/CheckEol.java Wed Feb 15
01:39:55 2012
@@ -0,0 +1,167 @@
+/*
+* 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.
+*/
+
+package org.apache.tomcat.buildutil;
+
+import java.io.BufferedInputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.util.ArrayList;
+import java.util.LinkedList;
+import java.util.List;
+
+import org.apache.tools.ant.BuildException;
+import org.apache.tools.ant.DirectoryScanner;
+import org.apache.tools.ant.Project;
+import org.apache.tools.ant.Task;
+import org.apache.tools.ant.types.FileSet;
+
+/**
+ * Ant task that checks that all the files in the given fileset have
end-of-line
+ * delimiters that are appropriate for the current OS.
+ *
+ *
+ * The goal is to check whether we have problems with svn:eol-style property
+ * when files are committed on one OS and then checked on another one.
+ */
+public class CheckEol extends Task {
+
+private static final String eoln = System.getProperty("line.separator");
+
+/** The files to be checked */
+private final List filesets = new LinkedList();
+
+/**
+ * Sets the files to be checked
+ *
+ * @param fs The fileset to be checked.
+ */
+public void addFileset( FileSet fs ) {
+filesets.add( fs );
+}
+
+/**
+ * Perform the check
+ *
+ * @throws BuildException if an error occurs during execution of
+ *this task.
+ */
+@Override
+public void execute() throws BuildException {
+
+Mode mode = null;
+if ("\n".equals(eoln)) {
+mode = Mode.LF;
+} else if ("\r\n".equals(eoln)) {
+mode = Mode.CRLF;
+} else {
+log("Line ends check skipped, because OS line ends setting is
neither LF nor CRLF.",
+Project.MSG_VERBOSE);
+return;
+}
+
+int count = 0;
+
+List errors = new ArrayList();
+
+// Step through each file and check.
+for (FileSet fs : filesets) {
+DirectoryScanner ds = fs.getDirectoryScanner(getProject());
+File basedir = ds.getBasedir();
+String[] files = ds.getIncludedFiles();
+if (files.length > 0) {
+log("Checking line ends in " + files.length + " file(s)");
+for (int i = 0; i < files.length; i++) {
+File file = new File(basedir, files[i]);
+log("Checking file '" + file + "' for correct line ends",
+Project.MSG_DEBUG);
+try {
+check(file, errors, mode);
+} catch (IOException e) {
+throw new BuildException("Could not check file '"
++ file.getAbsolutePath() + "'", e);
+}
+count++;
+}
+}
+}
+if (count > 0) {
+log("Done line ends check in " + count + " file(s), "
Re: SPDY support
Uploaded another take. This time I'm just adding https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/LightHandler.java which is just a Handler - like AjpConnectionHandler, Http11ConnectionHandler. I believe this is as close to Endpoint intent as it can be - given this is a protocol at the same level with Ajp or http11. The only thing special is that the Endpoint must have both the regular Http11ConnectionHandler and a SpdyHandler - and chose one or the other based on TLS negotiation result. Sorry for not providing enough background: SPDY as specified and implemented by browsers only works over TLS, and only if the server negotiates it using the NPN TLS extension ( which only works for openssl - so APR ). Firefox doesn't support any 'non secure' mode, Chrome can be started with some parameters (--use-spdy=no-compress,no-ssl), but won't be able to connect to google or other spdy servers. I added it to the JIO endpoint for testing - and because I believe it is a great protocol for internal server-to-server connections, in which case no browser is involved and you can set it without ssl ( and without the header compression, which is another requirement ). On Tue, Feb 14, 2012 at 3:32 PM, Mark Thomas wrote: > On 14/02/2012 20:47, Costin Manolache wrote: > > On Tue, Feb 14, 2012 at 9:36 AM, Mark Thomas wrote: > > > >> On 14/02/2012 08:29, Costin Manolache wrote: > >>> Ok, took a bit to get the Apr polling to work and add some minimal > tests. > >>> > >>> Please take another look - in particular to > >>> > >> > https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java > >>> > >>> The spdy implementation seems to work with chrome, and the client seems > >> to > >>> work with google. > >>> Probably still has plenty of bugs - but it's a start. > >>> > >>> If no objections - I'll start merging the LightProtocol/util.netchanges > >>> first, than add the spdy server implementation. The spdy client and > >> tests - > >>> probably later, I want to clean them up a bit more. > >> > >> I am all for adding SPDY support to Tomcat asap including if practical > >> to the 7.0.x branch (noting that there may be some API changes that may > >> prevent this). > >> > > > > So far I don't think I modified any API in incompatible ways. > > That was more a reference to the generic HTTP upgrade that I thought > SPDY should be using. > > >> I think the patch needs more discussion before it is committed to trunk. > >> There are several areas where I am uncomfortable. My key areas of > >> concern are: > >> > >> 1. The patch places Protocol like code (the code that works with the > >> processors) in the endpoints. This significantly muddies the waters > >> between Endpoint, Protocol and Processor which will make future > >> maintenance more difficult. > >> > > > > I can rename LightProtocol to LightHandler (extends Endpoint.Handler ), > > and Processor to LightConnectionHandler and extend Endpoint.Handler. > > > > I don't care much about the name :-), > > I don't care about the name either. Renaming them does not remove the > concern. > I hope the new interface does - it's just a small extension to Handler ( the main method is present in all other protocol implementations ) > > > but it is important ( for my and > > probably other > > use cases ) for the LightProcessor to be associated with a socket. > > Does it need the socket or are input and output streams sufficient? > It needs the APR socket to call JNI getNPN. I could make it work with the UpgradeAprProtocol eventually (making the socket available), but it feels more complex and intrusive, there are too many extra things. > > The current Protocol/Processor are very tied to HTTP and > > one-request-at-a-time. > > Yes and no. The AbstractProtocol has only a minimal understanding of > HTTP and AJP and that is a trade-off of not quite ideal design for > significantly greater shared code and therefore much less duplication. > AbstractProtocol uses only the Processor interface. > Processor is tied to one request/response - Spdy protocol is a multiplexing protocol, so one spdy connection will have 100s of Requests. I am using Processor interface for each muxed spdy stream. Plus - both are quite rich objects. I think it's worth using a smaller interface ( i.e. Endpoint.Handler with few extra extensions). > > The concrete implementations are obviously tied to specific protocols > and endpoints. > > A lot of work has gone into trying to separate the generic and protocol > / endpoint specific code. It isn't perfect but trunk is a lot cleaner > than 7.0.x in this respect and I'd like to see it stay that way. > I don't think the LightHandler will affect the rest of the protocol code - it is pretty well separated, doesn't leak into coyote. > > >> 2. Generic support for upgraded protocols is now available in trunk and > >> SPDY should use this rather than adding SPDY specific upgrade handling. > >> The generic
