RE: commons cache
Hi, Can I see the API so I can get a better feel for what you have in mind? Although I use it extensively, I'm not exactly sure of the value of commons-logging. I have no intention of switching from log4j. It does everything I want in a logger. Adding the commons-logging gives me flexibility to change, but since I can't imagine changing, the overall effect of using commons-logging is additional complexity with no substantial benefit. There may be reasons to use commons-logging in an open source project, since it gives our users a choice of loggers. However, I don't see the point of using it in private projects except to stay consistent with the opensource projects I use . . . Then again, caching may be different, since there doesn't seem to be a cache at the level of maturity of log4j. I hope JCS will be that soon. Cheers, Aaron --- Baum, Karl [EMAIL PROTECTED] wrote: Hi Emmanuel. I read over your emails and it sounds like we are both on the same page with the caching abstraction project. You have put way more thought into it than me, and your ideas sound great. I am surprised others are not on board. Is there any way we can get some kind of formal decision out of the commons-dev community? Should Emmanuel take his idea elsewhere? It would be a shame because I really think this project would benefit from the jakarta commons name. -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 7:18 AM To: Jakarta Commons Developers List Subject: Re: commons cache Hi Karl, thank you for bringing this topic back up, I suggested the same thing earlier this year (see http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] apache.orgmsgId=1165823 and http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] apache.orgmsgId=1226378) but didn't receive much feedback. I have an implementation supporting EHCache, JCS, OSCache and SwarmCache, I intended to host it on SourceForge once the work on commons-configuration 1.0 is done (http://sourceforge.net/projects/opencache), but if the commons community supports this idea I'll be glad to bring the code back here and start a proposal for a sandbox component. Is there any interest in such a component among the jakarta-commons developpers ? Emmanuel Bourg Baum, Karl wrote: Hi. I am new to this list and have joined to ask some questions regarding the commons caching subproject. I think there is a definite need in the java community for a thin wrapper around caching implementations such as EHCache, JCS, or SwarmCache. This wrapper would wrap cache implementations the way commons logging wrapped logging implementations. I looked at the commons caching page and there is little explanation of the purpose of the project aside from the name. The project almost seems like yet another caching implementation in itself, not a thin wrapper (I could be wrong though since I just quickly looked it over.). I am wondering what the aim of commons caching is and if it's still actively being developed? Thanks. Karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons cache
Aaron Smuts wrote: Can I see the API so I can get a better feel for what you have in mind? The API is attached to the previous message I linked: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1228418attachId=1 (it's not the latest version, this one still sits on my computer with SwarmCache and EHCache support, and unit tests) The API consists basically in Map decorators combined with a factory derived from commons-logging. Example: Cache cache = CacheFactory.getCache(region); cache.put(key, object); cache.get(key); The cache implementation is determined by a commons-caching.properties file on the classpath. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: commons cache
Hi Aaron. I think you're right. For the most part private users will not change logging API's very often, but for open source projects commons-logging is a must. In the case of caching, performance is of the highest concern. Swapping in different caching implementations during performance testing poses obvious benefits. Even after performance testing, different features of caching implementations can often be buggy. As I have experienced personally, dependecies on a caching implementation can cause huge issues down the road. As for open source projects, caching dependencies causes big reusability issues. A great example right now is cocoon using JCS. Suppose a developer wanted to use cocoon along with the latest release of Hibernate. Hibernate has discontinued using JCS. Should the developers use two different caching implementations? -Original Message- From: Aaron Smuts [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 10:04 AM To: Jakarta Commons Developers List Subject: RE: commons cache Hi, Can I see the API so I can get a better feel for what you have in mind? Although I use it extensively, I'm not exactly sure of the value of commons-logging. I have no intention of switching from log4j. It does everything I want in a logger. Adding the commons-logging gives me flexibility to change, but since I can't imagine changing, the overall effect of using commons-logging is additional complexity with no substantial benefit. There may be reasons to use commons-logging in an open source project, since it gives our users a choice of loggers. However, I don't see the point of using it in private projects except to stay consistent with the opensource projects I use . . . Then again, caching may be different, since there doesn't seem to be a cache at the level of maturity of log4j. I hope JCS will be that soon. Cheers, Aaron --- Baum, Karl [EMAIL PROTECTED] wrote: Hi Emmanuel. I read over your emails and it sounds like we are both on the same page with the caching abstraction project. You have put way more thought into it than me, and your ideas sound great. I am surprised others are not on board. Is there any way we can get some kind of formal decision out of the commons-dev community? Should Emmanuel take his idea elsewhere? It would be a shame because I really think this project would benefit from the jakarta commons name. -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 7:18 AM To: Jakarta Commons Developers List Subject: Re: commons cache Hi Karl, thank you for bringing this topic back up, I suggested the same thing earlier this year (see http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] apache.orgmsgId=1165823 and http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] apache.orgmsgId=1226378) but didn't receive much feedback. I have an implementation supporting EHCache, JCS, OSCache and SwarmCache, I intended to host it on SourceForge once the work on commons-configuration 1.0 is done (http://sourceforge.net/projects/opencache), but if the commons community supports this idea I'll be glad to bring the code back here and start a proposal for a sandbox component. Is there any interest in such a component among the jakarta-commons developpers ? Emmanuel Bourg Baum, Karl wrote: Hi. I am new to this list and have joined to ask some questions regarding the commons caching subproject. I think there is a definite need in the java community for a thin wrapper around caching implementations such as EHCache, JCS, or SwarmCache. This wrapper would wrap cache implementations the way commons logging wrapped logging implementations. I looked at the commons caching page and there is little explanation of the purpose of the project aside from the name. The project almost seems like yet another caching implementation in itself, not a thin wrapper (I could be wrong though since I just quickly looked it over.). I am wondering what the aim of commons caching is and if it's still actively being developed? Thanks. Karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL
DO NOT REPLY [Bug 30184] New: - CompositeFormat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30184.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30184
CompositeFormat
Summary: CompositeFormat
Product: Commons
Version: unspecified
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I wonder if this can be added.
/**
* Formats using one formatter and parses using a different formatter.
* An example of use for this would be a webapp where data is taken in one way
* and stored in a database another way.
* @author Archimedes Trajano
*/
public class CompositeFormat extends Format {
private final Format parser;
private final Format formatter;
public CompositeFormat(final Format parser, final Format formatter) {
this.parser = parser;
this.formatter = formatter;
}
public StringBuffer format(final Object obj, final StringBuffer toAppendTo,
final FieldPosition pos) {
return formatter.format(obj,toAppendTo,pos);
}
public Object parseObject(final String source, final ParsePosition pos) {
return parser.parseObject(source,pos);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons-sandbox/sql/lib ant-1.5.jar commons-beanutils-1.6.jar commons-cli-1.0-beta-2.jar commons-betwixt-20030211.133854.jar xml-apis-1.0.b2.jar commons-jelly-20030902.160215.jar hsqldb-1.7.1.jar dom4j-1.4.jar xerces-2.4.0.jar
What was the problem with maven ??
Arnaud
-Message d'origine-
De : Dion Gillard [mailto:[EMAIL PROTECTED]
Envoyé : lundi 19 juillet 2004 08:03
À : Jakarta Commons Developers List
Objet : Re: cvs commit: jakarta-commons-sandbox/sql/lib ant-1.5.jar
commons-beanutils-1.6.jar
commons-cli-1.0-beta-2.jar commons-betwixt-20030211.133854.jar xml-apis-1.0.b2.jar
commons-jelly-
20030902.160215.jar hsqldb-1.7.1.jar dom4j-1.4.jar xerces-2.4.0.jar
Out of curiosity, how are you generating the web site now?
On 17 Jul 2004 10:27:23 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
tomdz 2004/07/17 03:27:23
Modified:sql build.xml .classpath
Added: sql build.properties
sql/lib ant-1.5.jar commons-beanutils-1.6.jar
commons-cli-1.0-beta-2.jar
commons-betwixt-20030211.133854.jar
xml-apis-1.0.b2.jar
commons-jelly-20030902.160215.jar hsqldb-1.7.1.jar
dom4j-1.4.jar xerces-2.4.0.jar ant-optional-1.5.jar
commons-collections-3.0-dev.jar
commons-digester-1.5.jar commons-logging-1.0.3.jar
axion-1.0-M1.jar junit-3.8.1.jar
Removed: sql project.properties maven.xml project.xml
Log:
Build process now uses plain Ant (no maven anymore)
Revision ChangesPath
1.7 +129 -174 jakarta-commons-sandbox/sql/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/sql/build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.xml 16 Dec 2003 16:03:07 - 1.6
+++ build.xml 17 Jul 2004 10:27:22 - 1.7
@@ -1,179 +1,134 @@
?xml version=1.0 encoding=UTF-8?
-!--build.xml generated by maven from project.xml version 1.0-dev
- on date December 16 2003, time 0716--
+!--
+/* Copyright 2002-2004 Apache Software Foundation
+ *
+ * Licensed 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.
+ */
+--
-project default=jar name=commons-sql basedir=.
- property name=defaulttargetdir value=target
- /property
- property name=libdir value=target/lib
- /property
- property name=classesdir value=target/classes
- /property
- property name=testclassesdir value=target/test-classes
- /property
- property name=testreportdir value=target/test-reports
- /property
- property name=distdir value=dist
- /property
- property name=javadocdir value=dist/docs/api
- /property
- property name=final.name value=commons-sql-1.0-dev
- /property
- target name=init description=o Initializes some properties
-mkdir dir=${libdir}
-/mkdir
-condition property=noget
- equals arg2=only arg1=${build.sysclasspath}
- /equals
-/condition
- /target
- target name=compile description=o Compile the code depends=get-deps
-mkdir dir=${classesdir}
-/mkdir
-javac destdir=${classesdir} deprecation=true debug=true
optimize=false
excludes=**/package.html
- src
-pathelement location=src/java
-/pathelement
- /src
- classpath
-fileset dir=${libdir}
- include name=*.jar
- /include
-/fileset
- /classpath
-/javac
- /target
- target name=jar description=o Create the jar depends=compile,test
-jar jarfile=target/${final.name}.jar excludes=**/package.html
basedir=${classesdir}
-/jar
- /target
- target name=clean description=o Clean up the generated directories
-delete dir=${defaulttargetdir}
-/delete
-delete dir=${distdir}
-/delete
- /target
- target name=dist description=o Create a distribution depends=jar,
javadoc
-mkdir dir=dist
-/mkdir
-copy todir=dist
- fileset dir=${defaulttargetdir} includes=*.jar
- /fileset
- fileset dir=${basedir} includes=LICENSE*, README*
- /fileset
-/copy
- /target
- target name=test description=o Run the test cases if=test.failure
depends=internal-
test
-fail message=There were
Re: Bad deadlock on commons-dbcp 1.2.1?
Can you send me your pool configs?
(and other standard info like platform, OS, JVM, ...)
(the one that locks up on startup and the one with the deadlock)
The initialSize property is only available in BasicDataSource and not
on SharedPoolDataSource or did you add it yourself?
I don't see a deadlock in the stacktrace. There should be a locked
in the DBCP somewhere... (do you keep the full trace?)
Is it possible that the SharedPoolDataSource is just slow under these
conditions?
-- Dirk
Kevin A. Burton wrote:
I have a highly multhreaded app...We use about 300 threads which are
constantly using 100% of the CPU (its designed to do this to make
efficient use of the hardware)...
I've noticed two bugs with dbcp 1.2.1...
The first is that if you use a shallow pool with a high number of
threads it will lock at startup. I've also noticed this with older
versions of dbcp but theres a workaround. I just set initialSize to the
maxActive size of the pool.. that way all the connections are allocated
in a single thread.
Now I've noticed a bad deadlock after running for about 7 hours.
I did a killall -3 to get the running stacktrace.
They all seem to be locked :
org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:155)
Which is:
152:protected synchronized PooledConnectionAndInfo
153:getPooledConnectionAndInfo(String username, String password)
154:throws SQLException {
155:if (pool == null) {
156:try {
157:registerPool(username, password);
158:} catch (NamingException e) {
159:throw new SQLNestedException(RegisterPool failed, e);
160:}
161:}
162:
163:PooledConnectionAndInfo info = null;
164:try {
165:info = (PooledConnectionAndInfo) pool
166:.borrowObject(getUserPassKey(username, password));
167:}
168:catch (Exception e) {
169:throw new SQLNestedException(
170:Could not retrieve connection info from pool, e);
180:}
181:return info;
190:}
I used a tool I wrote to remove duplicate stack traces to see if there
was any obvious contention and I didn't see any:
http://www.peerfear.org/rss/permalink/2003/10/26/MiningForExceptionsInLogFiles/
trace removed
... any idea?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Stopwatch improvements
I now understand better what split was intended to do (current lap time concept). I was being misled by the code :-) and the absence of a getSplitTime method. If we want to keep it, I think it does logically lead to another state, split connected to running in the obvious way (split out, unsplit in). Both getTime and getSplitTime should be available from the split state and getSplitTime should only be available in that state. One more thing that we should think about and at least acknowledge in the docs is the lack of synchronization. It's probably not a good idea to try to make the watch thread-safe; but we should make this explicit in the docs. Phil -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sun 7/18/2004 8:41 PM To: Jakarta Commons Developers List Cc: Subject: Re: [lang] Stopwatch improvements Deprecating split() is a very good point. While a real physical stopwatch has a split concept (not a stack, just a single last split time), I've never had a use for it in code. Having played with the code a bit again, the amount of pain caused by split() far outweighs any advantage I can think of having it so I'm +1 to deprecating it in 2.1 and removing in 3.0. Hen On Sun, 18 Jul 2004, Phil Steitz wrote: Steven Caswell wrote: I think it makes sense to be able to stop from suspend. That would give the caller the most options. Otherwise, if the stopwatch were suspended, you'd have to restart it before stopping, which would change the time of the stopwatch. Being able to stop while suspended means you can stop from suspend without the time changing, but a caller could still resume and then stop if they wanted that functionality. For reset when state is running or split, I think that should not be allowed. I think the stopwatch can only be reset if the stopwatch is stopped. That keeps the methods cleaner while still providing the necessary functionality. I agree with both points above, but I don't think we have the states quite right. Unless the watch is going to be able to store splits, I see no value to the split state or actually the split()/unsplit() methods. Note that in the current code, stop(), split() and suspend() all do the same thing (set the stopTime to the current time). I would suggest that either split() enable actual storage of a (stack of) split(s) or it be deprecated. Could be I am missing something here. In any case, I think we can start with the simple state diagram below to model the control states of the watch. Self-loops decorated with getTime() should appear on all three states. Self loops for split.unsplit should decorate Running. I am ambivalent on reset(). I would be OK with letting it be invoked in any of the three states (causing no state transition). stop - - | Stopped | |Running | ^-^ - start/ || | ^ / || | | /reset \ |/ stop \_ |resume / suspend | | / v | / / | Suspended | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30167] - [collections] Implementation of SynchronizedBidiMap and SynchronizedMap, with tests
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30167. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30167 [collections] Implementation of SynchronizedBidiMap and SynchronizedMap, with tests --- Additional Comments From [EMAIL PROTECTED] 2004-07-19 18:37 --- Stephen, I think I've addressed your comments. But, there is one remaining problem: I'm trying to get the inverseBidiMap() function to work properly such that assertSame(bidimap, bidimap.inverseBidiMap().inverseBidiMap()) works. I see that TreeBidiMap does this by using the View, Inverse, and EntryView static/inner classes. Obviously, I don't want to have to recreate nearly similar classes that do the same thing for SynchronizedBidiMap. Any ideas on how best you'd like to see this problem solved? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30167] - [collections] Implementation of SynchronizedBidiMap and SynchronizedMap, with tests
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30167. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30167 [collections] Implementation of SynchronizedBidiMap and SynchronizedMap, with tests --- Additional Comments From [EMAIL PROTECTED] 2004-07-19 20:05 --- See UnmodifiableSortedBidiMap - you have to hold an instance variable in the decorator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpConnection.java
olegk 2004/07/19 13:06:26
Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH HttpConnection.java
Log:
PR #29897 (questionable default value for BufferedOutputStream size in
HttpConnection)
Changelog:
BufferedOutputStream buffer size is 2k max
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
No revision
No revision
1.67.2.12 +14 -6
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java
Index: HttpConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.67.2.11
retrieving revision 1.67.2.12
diff -u -r1.67.2.11 -r1.67.2.12
--- HttpConnection.java 25 Jun 2004 03:27:40 - 1.67.2.11
+++ HttpConnection.java 19 Jul 2004 20:06:26 - 1.67.2.12
@@ -682,10 +682,14 @@
if (sendBufferSize != -1) {
socket.setSendBufferSize(sendBufferSize);
}
+int outbuffersize = socket.getSendBufferSize();
+if (outbuffersize 2048) {
+outbuffersize = 2048;
+}
inputStream = new PushbackInputStream(socket.getInputStream());
outputStream = new BufferedOutputStream(
new WrappedOutputStream(socket.getOutputStream()),
-socket.getSendBufferSize()
+outbuffersize
);
isOpen = true;
used = false;
@@ -735,10 +739,14 @@
if (sendBufferSize != -1) {
socket.setSendBufferSize(sendBufferSize);
}
+int outbuffersize = socket.getSendBufferSize();
+if (outbuffersize 2048) {
+outbuffersize = 2048;
+}
inputStream = new PushbackInputStream(socket.getInputStream());
outputStream = new BufferedOutputStream(
new WrappedOutputStream(socket.getOutputStream()),
-socket.getSendBufferSize()
+outbuffersize
);
usingSecureSocket = true;
tunnelEstablished = true;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpConnection.java
olegk 2004/07/19 13:08:06
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpConnection.java
Log:
PR #29897 (questionable default value for BufferedOutputStream size in
HttpConnection)
Changelog:
BufferedOutputStream buffer size is 2k max
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
1.97 +16 -12
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java
Index: HttpConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.96
retrieving revision 1.97
diff -u -r1.96 -r1.97
--- HttpConnection.java 5 Jul 2004 22:46:58 - 1.96
+++ HttpConnection.java 19 Jul 2004 20:08:06 - 1.97
@@ -686,10 +686,12 @@
if (rcvBufSize = 0) {
socket.setReceiveBufferSize(rcvBufSize);
}
-inputStream = new PushbackInputStream(
-socket.getInputStream());
-outputStream = new BufferedOutputStream(
-socket.getOutputStream(), socket.getSendBufferSize());
+int outbuffersize = socket.getSendBufferSize();
+if (outbuffersize 2048) {
+outbuffersize = 2048;
+}
+inputStream = new PushbackInputStream(socket.getInputStream());
+outputStream = new BufferedOutputStream(socket.getOutputStream(),
outbuffersize);
isOpen = true;
used = false;
} catch (IOException e) {
@@ -735,10 +737,12 @@
if (rcvBufSize = 0) {
socket.setReceiveBufferSize(rcvBufSize);
}
-inputStream = new PushbackInputStream(
-socket.getInputStream());
-outputStream = new BufferedOutputStream(
-socket.getOutputStream(), socket.getSendBufferSize());
+int outbuffersize = socket.getSendBufferSize();
+if (outbuffersize 2048) {
+outbuffersize = 2048;
+}
+inputStream = new PushbackInputStream(socket.getInputStream());
+outputStream = new BufferedOutputStream(socket.getOutputStream(),
outbuffersize);
usingSecureSocket = true;
tunnelEstablished = true;
LOG.debug(Secure tunnel created);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestStatusLine.java
olegk 2004/07/19 13:24:21
Modified:httpclient/src/java/org/apache/commons/httpclient
StatusLine.java
httpclient/src/test/org/apache/commons/httpclient
TestStatusLine.java
Log:
PR #30175 (StatusLine IndexOutOfBounds)
Contributed by Oleg Kalnichevski
Revision ChangesPath
1.14 +31 -37
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/StatusLine.java
Index: StatusLine.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/StatusLine.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- StatusLine.java 18 Apr 2004 23:51:35 - 1.13
+++ StatusLine.java 19 Jul 2004 20:24:21 - 1.14
@@ -92,47 +92,41 @@
throw new HttpException(Status-Line ' + statusLine
+ ' does not start with HTTP);
}
-} catch (StringIndexOutOfBoundsException e) {
-throw new HttpException(Status-Line ' + statusLine + ' is not
valid);
-}
-//handle the HTTP-Version
-at = statusLine.indexOf( , at);
-if (at = 0) {
-throw new ProtocolException(
-Unable to parse HTTP-Version from the status line: '
-+ statusLine + ');
-}
-this.httpVersion = (statusLine.substring(start, at)).toUpperCase();
-
-//advance through spaces
-while (statusLine.charAt(at) == ' ') {
-at++;
-}
+//handle the HTTP-Version
+at = statusLine.indexOf( , at);
+if (at = 0) {
+throw new ProtocolException(
+Unable to parse HTTP-Version from the status line: '
++ statusLine + ');
+}
+this.httpVersion = (statusLine.substring(start, at)).toUpperCase();
-//handle the Status-Code
-int to = statusLine.indexOf( , at);
-if (to 0) {
-to = length;
-}
-try {
-this.statusCode = Integer.parseInt(statusLine.substring(at, to));
-} catch (NumberFormatException e) {
-throw new ProtocolException(
-Unable to parse status code from status line: '
-+ statusLine + ');
-}
+//advance through spaces
+while (statusLine.charAt(at) == ' ') {
+at++;
+}
-//handle the Reason-Phrase
-at = to + 1;
-try {
+//handle the Status-Code
+int to = statusLine.indexOf( , at);
+if (to 0) {
+to = length;
+}
+try {
+this.statusCode = Integer.parseInt(statusLine.substring(at, to));
+} catch (NumberFormatException e) {
+throw new ProtocolException(
+Unable to parse status code from status line: '
++ statusLine + ');
+}
+//handle the Reason-Phrase
+at = to + 1;
if (at length) {
this.reasonPhrase = statusLine.substring(at).trim();
} else {
this.reasonPhrase = ;
}
} catch (StringIndexOutOfBoundsException e) {
-throw new ProtocolException(Status text not specified: '
-+ statusLine + ');
+throw new HttpException(Status-Line ' + statusLine + ' is not
valid);
}
//save the original Status-Line
this.statusLine = new String(statusLine);
1.9 +8 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestStatusLine.java
Index: TestStatusLine.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestStatusLine.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TestStatusLine.java 22 Feb 2004 18:08:49 - 1.8
+++ TestStatusLine.java 19 Jul 2004 20:24:21 - 1.9
@@ -139,6 +139,10 @@
fail();
} catch (HttpException e) { /* expected */ }
+try {
+statusLine = new StatusLine(HTTP/1.1);
+fail();
+} catch (HttpException e) { /* expected */ }
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestStatusLine.java
olegk 2004/07/19 13:25:02
Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH StatusLine.java
httpclient/src/test/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH TestStatusLine.java
Log:
PR #30175 (StatusLine IndexOutOfBounds)
Contributed by Oleg Kalnichevski
Revision ChangesPath
No revision
No revision
1.9.2.4 +30 -38
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/StatusLine.java
Index: StatusLine.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/StatusLine.java,v
retrieving revision 1.9.2.3
retrieving revision 1.9.2.4
diff -u -r1.9.2.3 -r1.9.2.4
--- StatusLine.java 22 Feb 2004 18:21:13 - 1.9.2.3
+++ StatusLine.java 19 Jul 2004 20:25:02 - 1.9.2.4
@@ -96,47 +96,39 @@
throw new HttpException(Status-Line ' + statusLine
+ ' does not start with HTTP);
}
-} catch (StringIndexOutOfBoundsException e) {
-throw new HttpException(Status-Line ' + statusLine + ' is not
valid);
-}
-//handle the HTTP-Version
-at = statusLine.indexOf( , at);
-if (at = 0) {
-throw new HttpException(
-Unable to parse HTTP-Version from the status line: '
+//handle the HTTP-Version
+at = statusLine.indexOf( , at);
+if (at = 0) {
+throw new HttpException(
+Unable to parse HTTP-Version from the status line: '
++ statusLine + ');
+}
+this.httpVersion = (statusLine.substring(start, at)).toUpperCase();
+//advance through spaces
+while (statusLine.charAt(at) == ' ') {
+at++;
+}
+//handle the Status-Code
+int to = statusLine.indexOf( , at);
+if (to 0) {
+to = length;
+}
+try {
+this.statusCode = Integer.parseInt(statusLine.substring(at, to));
+} catch (NumberFormatException e) {
+throw new HttpException(
+Unable to parse status code from status line: '
+ statusLine + ');
-}
-this.httpVersion = (statusLine.substring(start, at)).toUpperCase();
-
-//advance through spaces
-while (statusLine.charAt(at) == ' ') {
-at++;
-}
-
-//handle the Status-Code
-int to = statusLine.indexOf( , at);
-if (to 0) {
-to = length;
-}
-try {
-this.statusCode = Integer.parseInt(statusLine.substring(at, to));
-} catch (NumberFormatException e) {
-throw new HttpException(
-Unable to parse status code from status line: '
-+ statusLine + ');
-}
-
-//handle the Reason-Phrase
-at = to + 1;
-try {
+}
+//handle the Reason-Phrase
+at = to + 1;
if (at length) {
this.reasonPhrase = statusLine.substring(at).trim();
} else {
this.reasonPhrase = ;
}
} catch (StringIndexOutOfBoundsException e) {
-throw new HttpException(Status text not specified: '
-+ statusLine + ');
+throw new HttpException(Status-Line ' + statusLine + ' is not
valid);
}
//save the original Status-Line if everything is OK
this.statusLine = new String(statusLine);
No revision
No revision
1.6.2.3 +8 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestStatusLine.java
Index: TestStatusLine.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestStatusLine.java,v
retrieving revision 1.6.2.2
retrieving revision 1.6.2.3
diff -u -r1.6.2.2 -r1.6.2.3
--- TestStatusLine.java 22 Feb 2004 18:21:16 - 1.6.2.2
+++ TestStatusLine.java 19 Jul 2004 20:25:02 - 1.6.2.3
@@ -139,6 +139,10 @@
fail();
} catch (HttpException e) { /* expected */ }
+try {
+statusLine = new StatusLine(HTTP/1.1);
+fail();
+} catch (HttpException e) { /* expected */ }
}
}
-
To unsubscribe, e-mail: [EMAIL
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/params HttpConnectionManagerParams.java
olegk 2004/07/19 13:37:43
Modified:httpclient/src/java/org/apache/commons/httpclient/params
HttpConnectionManagerParams.java
Log:
Removed Java 1.3 dependent code
Contributed by Oleg Kalnichevski
Revision ChangesPath
1.8 +10 -5
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/params/HttpConnectionManagerParams.java
Index: HttpConnectionManagerParams.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/params/HttpConnectionManagerParams.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- HttpConnectionManagerParams.java 17 Jul 2004 18:58:33 - 1.7
+++ HttpConnectionManagerParams.java 19 Jul 2004 20:37:43 - 1.8
@@ -107,7 +107,12 @@
Map currentValues = (Map) getParameter(MAX_HOST_CONNECTIONS);
// param values are meant to be immutable so we'll make a copy
// to modify
-Map newValues = new HashMap(currentValues == null ? Collections.EMPTY_MAP :
currentValues);
+Map newValues = null;
+if (currentValues == null) {
+newValues = new HashMap();
+} else {
+newValues = new HashMap(currentValues);
+}
newValues.put(hostConfiguration, new Integer(maxHostConnections));
setParameter(MAX_HOST_CONNECTIONS, newValues);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30191] New: - [collections] minor javadoc fixes for OrderedIterator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30191. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30191 [collections] minor javadoc fixes for OrderedIterator Summary: [collections] minor javadoc fixes for OrderedIterator Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Collections AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Minor javadoc fixes for org.apache.commons.collections.OrderedIterator. diff -u attached. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30191] - [collections] minor javadoc fixes for OrderedIterator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30191. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30191 [collections] minor javadoc fixes for OrderedIterator --- Additional Comments From [EMAIL PROTECTED] 2004-07-19 20:41 --- Created an attachment (id=12166) diff -u patch file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] OrderedMap.valuesAsList?
Would be very nice if the values of an OrderedMap were available as a List as well as the keys. Any reason why this would be bad? As ListOrderedMap.asList is but a view on the Map, valuesAsList would be the same way, so largely it's just the same code as asList with a tweak to call get on the Map. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool - New directory
olegk 2004/07/19 14:37:50 jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool HttpPoolConnectionManager.java HttpPoolConnectionManagerConfiguration.java PoolableHttpConnectionFactory.java
olegk 2004/07/19 14:41:09 Added: httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool Tag: HTTPCLIENT_2_0_BRANCH HttpPoolConnectionManager.java HttpPoolConnectionManagerConfiguration.java PoolableHttpConnectionFactory.java Log: MultiThreadedConnectionManager based on commons-pool Contributed by Andrea Fabris cavaliereoscuro -at- email.it Reviewed by Oleg Kalnichevski Revision ChangesPath No revision No revision 1.1.2.1 +167 -0 jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool/Attic/HttpPoolConnectionManager.java 1.1.2.1 +155 -0 jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool/Attic/HttpPoolConnectionManagerConfiguration.java 1.1.2.1 +98 -0 jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool/Attic/PoolableHttpConnectionFactory.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient build.xml
olegk 2004/07/19 14:57:30
Modified:httpclient Tag: HTTPCLIENT_2_0_BRANCH build.xml
Log:
Do not compile 'contrib' packages, as some of the classes may have additional
compile dependencies. The 'contrib' packages are to be distributed in source code as
reference material only
Revision ChangesPath
No revision
No revision
1.29.2.5 +1 -9 jakarta-commons/httpclient/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/build.xml,v
retrieving revision 1.29.2.4
retrieving revision 1.29.2.5
diff -u -r1.29.2.4 -r1.29.2.5
--- build.xml 15 Feb 2004 15:48:42 - 1.29.2.4
+++ build.xml 19 Jul 2004 21:57:30 - 1.29.2.5
@@ -164,7 +164,6 @@
mkdir dir=${build.home}/docs/api/
mkdir dir=${build.home}/tests/
mkdir dir=${build.home}/examples/
-mkdir dir=${build.home}/contrib/
mkdir dir=${test-webapp.dest}/
mkdir dir=${test-webapp.dest}/${httpclient.test.webappContext}/
mkdir dir=${test-webapp.dest}/${httpclient.test.webappContext}/WEB-INF/
@@ -235,13 +234,6 @@
/javac
javac srcdir =${source.home}/examples
destdir =${build.home}/examples
- debug =${compile.debug}
- deprecation =${compile.deprecation}
- optimize=${compile.optimize}
- classpath refid=compile.classpath/
-/javac
-javac srcdir =${source.home}/contrib
- destdir =${build.home}/contrib
debug =${compile.debug}
deprecation =${compile.deprecation}
optimize=${compile.optimize}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient release_notes.txt
olegk 2004/07/19 14:59:01 Modified:httpclient Tag: HTTPCLIENT_2_0_BRANCH release_notes.txt Log: PR #29897, PR #30175 Revision ChangesPath No revision No revision 1.9.2.12 +4 -0 jakarta-commons/httpclient/release_notes.txt Index: release_notes.txt === RCS file: /home/cvs/jakarta-commons/httpclient/release_notes.txt,v retrieving revision 1.9.2.11 retrieving revision 1.9.2.12 diff -u -r1.9.2.11 -r1.9.2.12 --- release_notes.txt 6 Jul 2004 22:01:05 - 1.9.2.11 +++ release_notes.txt 19 Jul 2004 21:59:01 - 1.9.2.12 @@ -2,6 +2,10 @@ --- Changes since Release 2.0 + * 30175 - Fixed StringIndexOutOfBoundsException in StatusLine + + * 29897 - Connection output buffer is set to a value not greater than 2k + * 29549 - Split wire log into header and body parts * 29377 - Cookies with names containing blanks or starting with $ rejected by RFC2109 spec only. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient release_notes.txt
olegk 2004/07/19 15:02:35 Modified:httpclient release_notes.txt Log: PR #29897 Revision ChangesPath 1.31 +2 -0 jakarta-commons/httpclient/release_notes.txt Index: release_notes.txt === RCS file: /home/cvs/jakarta-commons/httpclient/release_notes.txt,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- release_notes.txt 17 Jul 2004 18:58:33 - 1.30 +++ release_notes.txt 19 Jul 2004 22:02:35 - 1.31 @@ -2,6 +2,8 @@ --- Changes since Alpha 1: + * 29897 - Connection output buffer is set to a value not greater than 2k + * 29636 - MultiThreadedHttpConnectionManager now support configuring the maximum number of connections on a per host basis. Contributed by Michael Becke mbecke at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/sql/src/test-input jdbc-type-mappings.csv
tomdz 2004/07/19 15:14:00
Modified:sql/src/java/org/apache/commons/sql/model Column.java
IndexColumn.java Database.java Reference.java
Table.java ForeignKey.java UniqueColumn.java
Unique.java Index.java
Added: sql/src/test-input jdbc-type-mappings.csv
Log:
Added ability to merge two database models
Revision ChangesPath
1.13 +22 -2
jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/model/Column.java
Index: Column.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/model/Column.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Column.java 18 Jul 2004 21:55:58 - 1.12
+++ Column.java 19 Jul 2004 22:14:00 - 1.13
@@ -15,8 +15,7 @@
*/
package org.apache.commons.sql.model;
-
-public class Column
+public class Column implements Cloneable
{
private String name;
private String javaName;
@@ -35,6 +34,27 @@
{
}
+/* (non-Javadoc)
+ * @see java.lang.Object#clone()
+ */
+public Object clone() throws CloneNotSupportedException
+{
+Column result = new Column();
+
+result.name= name;
+result.javaName= javaName;
+result.primaryKey = primaryKey;
+result.required= required;
+result.autoIncrement = autoIncrement;
+result.typeCode= typeCode;
+result.type= type;
+result.size= size;
+result.defaultValue= defaultValue;
+result.scale = scale;
+result.precisionRadix = precisionRadix;
+result.ordinalPosition = ordinalPosition;
+return result;
+}
public Column(String name, String javaName, int typeCode, String size, boolean
required, boolean
primaryKey, boolean autoIncrement, String defaultValue)
1.4 +26 -4
jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/model/IndexColumn.java
Index: IndexColumn.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/model/IndexColumn.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- IndexColumn.java 28 Feb 2004 03:35:48 - 1.3
+++ IndexColumn.java 19 Jul 2004 22:14:00 - 1.4
@@ -15,13 +15,25 @@
*/
package org.apache.commons.sql.model;
-public class IndexColumn
+public class IndexColumn implements Cloneable
{
-private String name;
-private String size;
+protected String name;
+protected String size;
public IndexColumn() {}
-
+
+/* (non-Javadoc)
+ * @see java.lang.Object#clone()
+ */
+public Object clone() throws CloneNotSupportedException
+{
+IndexColumn result = new IndexColumn();
+
+result.name = name;
+result.size = size;
+return result;
+}
+
public String getName()
{
return name;
@@ -30,5 +42,15 @@
public void setName(String name)
{
this.name = name;
+}
+
+public String getSize()
+{
+return size;
+}
+
+public void setSize(String size)
+{
+this.size = size;
}
}
1.8 +28 -0
jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/model/Database.java
Index: Database.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/model/Database.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Database.java 28 Feb 2004 03:35:48 - 1.7
+++ Database.java 19 Jul 2004 22:14:00 - 1.8
@@ -41,6 +41,34 @@
{
}
+/**
+ * Adds all tables from the other database to this database.
+ * Note that the other database is not changed.
+ *
+ * @param otherDb The other database model
+ * @exception IllegalArgumentException If duplicated tables were found
+ */
+public void mergeWith(Database otherDb) throws IllegalArgumentException
+{
+for (Iterator it = otherDb.tables.iterator(); it.hasNext();)
+{
+Table table = (Table)it.next();
+
+if (findTable(table.getName()) != null)
+{
+throw new IllegalArgumentException(Table +table.getName()+
already defined in this database);
+}
+try
+{
+addTable((Table)table.clone());
+
Re: [VOTE] 2.0.1 release
+1 -- Vote: HttpClient 2.0.1 release [x] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2.0.1 release
+1 On 19/07/2004, at 12:21 PM, Michael Becke wrote: Pending the patch to bug #29897, I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.1 and proceed with a release. Please vote as follows: --- --- Vote: HttpClient 2.0.1 release [ ] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). --- --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
DO NOT REPLY [Bug 30175] New: - StatusLine IndexOutOfBounds
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30175. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30175 StatusLine IndexOutOfBounds Summary: StatusLine IndexOutOfBounds Product: Commons Version: 2.0 Final Platform: Other URL: http://bugs.limewire.com/bugs/searching.jsp?disp1=ldisp 2=cdisp3=odisp4=jl=151c=204m=416_205 OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Reported by Sam Berlin on the developers mailing list: I'm not sure if this problem is still on CVS HEAD, but we're seeing it against 2.0rc2. In StatusLine (line 139 in my version), when it walks through the spaces, it is possible that the entire line was spaces (and thus a malformed response). The code will throw an StringIndexOutOfBoundsException now instead of the correct HttpException. See the following bug: http://bugs.limewire.com/bugs/ searching.jsp?disp1=ldisp2=cdisp3=odisp4=jl=151c=204m=416_205 Thanks, Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30175] - StatusLine IndexOutOfBounds
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30175. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30175 StatusLine IndexOutOfBounds [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |2.0 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30175] - StatusLine IndexOutOfBounds
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30175. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30175 StatusLine IndexOutOfBounds --- Additional Comments From [EMAIL PROTECTED] 2004-07-19 08:14 --- Created an attachment (id=12154) Patch against 2.0 branch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 2.0.1 release
Folks, I apologize for 'waking up' so late, after already having cast my vote. (1) There are two patches that I would like to see committed before the release is cut http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29897 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30175 Both problems are relatively minor. If there are no loud objections I commit the patches around 20:00 GMT (2) I would also like to propose Commons Pool based connection manager contributed by Andrea Fabris be included into the contrib package for the coming release. It is a fine contribution which may be valuable for some of our users http://marc.theaimsgroup.com/?t=10838575947r=1w=2 The only trouble I see here is that an additional dependency on commons-pool. I personally feel this is acceptable as the contrib package is not meant to be an integral part of HttpClient and thus its dependencies should not be limited to those of HttpClient. I believe it is just matter of time until someone will come up with useful stuff that goes beyond the original scope of HttpClient which we may still want to ship with the official source distribution as reference material. How do you feel about it? Oleg -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 8:26 To: Commons HttpClient Project Subject: Re: [VOTE] 2.0.1 release +1 -- Vote: HttpClient 2.0.1 release [x] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2.0.1 release
(1) There are two patches that I would like to see committed before the release is cut http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29897 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30175 Both problems are relatively minor. If there are no loud objections I commit the patches around 20:00 GMT Sounds good. (2) I would also like to propose Commons Pool based connection manager contributed by Andrea Fabris be included into the contrib package for the coming release. It is a fine contribution which may be valuable for some of our users http://marc.theaimsgroup.com/?t=10838575947r=1w=2 I haven't taken a close look at it, but contrib sounds like the right place to me. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JUnit cookies test failures
Hello, I am running into the same issue found by Eric http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=708 when running against tomcat 4.1.30. My tomcat env is on windows XP, httpclient 2.0, jdk 1.4.2 The archive does not seem to have any conclusion yet. Any suggestion? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27426] - [API Doc] Document exceptions thrown on execute methods
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27426. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27426 [API Doc] Document exceptions thrown on execute methods --- Additional Comments From [EMAIL PROTECTED] 2004-07-19 19:23 --- Created an attachment (id=12165) exception handling guide (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27426] - [API Doc] Document exceptions thrown on execute methods
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27426. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27426 [API Doc] Document exceptions thrown on execute methods --- Additional Comments From [EMAIL PROTECTED] 2004-07-19 19:25 --- Folks, Here's the first draft version of the exception handling guide. Please let me know how it is shaping up. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29897] - questionable default value for BufferedOutputStream size in HttpConnection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29897. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29897 questionable default value for BufferedOutputStream size in HttpConnection [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-19 20:11 --- Patch committed to CVS HEAD and 2.0 branch Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30175] - StatusLine IndexOutOfBounds
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30175. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30175 StatusLine IndexOutOfBounds [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-19 20:29 --- Patch applied to CVS HEAD and 2.0 branch Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MultiThreadedConnectionManager based on commons pool
Andrea,
The code you contributed has been committed to the 2.0 branch. Many
thanks for this contribution.
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool/Attic/
I have applied some minor corrections to the source code to make it a
little more compatible with the overall coding and formating guidelines.
There's still potential for improvement: some additional javadocs would
be nice; comments and debug logs should ideally be translated from
Italian to English. So, feel free to submit incremental patches ;-)
If you would like the authorship attribution for this code, please
consider signing the CLA
http://www.apache.org/licenses/
http://www.apache.org/licenses/cla.txt
Cheers,
Oleg
On Thu, 2004-05-06 at 15:10, Andrea Fabris wrote:
Hello Everybody!
I'm Andrea from italy, and i'm very interested about the jakarta httpclient.
I tried it and i find it very easy to use, but i found (i wrote about it
some time ago) a bug in the multithredconnectionmanger.
It seems that the opened connections are tested for closure only when
they ahve to be given back from the pool to the client. In this way,
after some time where the connections are not used, the connections are
still open but the are in CLOSE_WAIT state: they are shut down when a
client request for a new connection form the pool, but the pool finds
the old conenction in a CLOSE_WAIT state, so it shuts down the
conenction and creates a new one.
Now, int this manner there could be a wate of resources, if nobody uses
connections for a long time.
I have seen that something has been done (in cvs) about auto closing
idle connection, but i still think that the multithreaded connection
manager needs a reimplementation.
I think that could be a great idea to reimplement the manager using
commons pool as a base.
Simply, the manager has to trak a list of open pools based on
GenericObjectPool: every pool in the manager (one for each host) must be
created using a factory that manages the connection life-cycle in the
pool (in the common pool framework).
I attach the code i've written, so you can take a look at it.
Regards
Andrea Fabris
Errore Apertura DB
__
package org.apache.commons.httpclient.pool;
import org.apache.commons.pool.PoolableObjectFactory;
import org.apache.commons.httpclient.HttpConnection;
import org.apache.commons.httpclient.HostConfiguration;
import org.apache.commons.logging.*;
/**
* pTitle: /p
* pDescription: /p
* pCopyright: Copyright (c) 2004/p
* pCompany: /p
* @author not attributable
* @version 1.0
*/
public class PoolableHttpConnectionFactory implements PoolableObjectFactory {
private HostConfiguration connConf;
private HttpPoolConnectionManager manager;
private static Log log = LogFactory.getLog(PoolableHttpConnectionFactory.class);
public PoolableHttpConnectionFactory(HostConfiguration hc,
HttpPoolConnectionManager manager) {
connConf = hc;
this.manager = manager;
}
/**
* Create a new connection using the HostConfiguration passed in the Factory
* @return a new connection
*/
public Object makeObject() {
log.debug(PoolableHttpConnectionFactory - makeObject Inizio metodo);
HttpConnection conn = new HttpConnection(connConf);
conn.setHttpConnectionManager(manager);
log.debug(PoolableHttpConnectionFactory - makeObject Fine metodo);
return conn;
}
public void destroyObject(Object in) {
log.debug(PoolableHttpConnectionFactory - destroyObject Inizio metodo);
if (in != null) {
log.debug(PoolableHttpConnectionFactory - destroyObject Connection not
null);
HttpConnection conn = (HttpConnection) in;
if (conn.isOpen()) {
log.debug(PoolableHttpConnectionFactory - destroyObject Closing
connection);
conn.close();
}
in = null;
log.debug(PoolableHttpConnectionFactory - destroyObject Fine metodo);
}
}
public boolean validateObject(Object in) {
log.debug(PoolableHttpConnectionFactory - validateObject Inizio metodo);
boolean result = false;
if (in != null) {
HttpConnection conn = (HttpConnection) in;
if (conn.isOpen())
log.debug(PoolableHttpConnectionFactory - validateObject Connection
opened: valid connection);
result = true;
}
log.debug(PoolableHttpConnectionFactory - validateObject Inizio metodo);
return result;
}
public void activateObject(Object in) {
log.debug(PoolableHttpConnectionFactory - activateObject No action);
}
public void passivateObject(Object in){
log.debug(PoolableHttpConnectionFactory - passivateObject No action);
}
}
__
package org.apache.commons.httpclient.pool;
import
Re: JUnit cookies test failures
Dan It was later discovered that different Tomcat connectors appear to have different cookie parsing/formating logic. The problem shows up only when the newer Coyote connector is being used. !-- works fine -- Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0 / !-- applies different cookie paring/formatting rules -- !-- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 useURIValidationHack=false disableUploadTimeout=true/ -- However, the real problem is that the TestWebApp based cookie test cases are completely meaningless as they in fact test Tomcat's functionality rather than that of HttpClient. In the CVS HEAD (HttpClient 3.0) these test cases have been removed and replaced with a completely new set of test cases. I hope this explains things a little Oleg On Mon, 2004-07-19 at 18:54, dan tran wrote: Hello, I am running into the same issue found by Eric http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=708 when running against tomcat 4.1.30. My tomcat env is on windows XP, httpclient 2.0, jdk 1.4.2 The archive does not seem to have any conclusion yet. Any suggestion? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please Help !
Hi, I'm getting the error: Error in parsing the status line from the response: unable to find line starting with HTTP. and i´m pretty sure that its related to the consideration documented by Daniel C. Amadei : JSSE prior to Java 1.4 incorrectly reports socket timeout. Prior to Java 1.4, in Sun's JSSE implementation, a read operation that has timed out incorrect reports end of stream condition instead of throwing java.io.InterruptedIOException as expected. HttpClient responds to this exception by assuming that the connection was dropped and throws a recoverable HTTP exception: Error in parsing the status line from the response: unable to find line starting with HTTP. It should instead report java.io.InterruptedIOException: Read timed out. If you see the unable to find line... message when working with an older version of JDK and JSSE, it can be caused by the timeout waiting for data and not by a problem with the connection. Work-around: One possible solution is to increase the timeout value as the server is taking too long to start sending the response. Alternatively you may choose to upgrade to Java 1.4 or above which does not exhibit this problem Unfortunely in my company´s tech unit is not going to be easy neither quick to upgrade to the Java version 1.4. And I already tried to increase the client setTimeOut method and didn´t work So is there a way you can help to modified the necesary components in order to fix the problem from the HttpClient side. Or give me some hints on how to fix it and generate a new commons-httpclient-2.0.jar that includes the fix. Or if there is already a version of the HttpClient v2.0 that fix this problem The version that i´m using is the 2.0. I really really appreciate your help Best Regards Arturo
Re: Please Help !
Hello Arturo, This problem could be caused by a number of things. Please post a wire log http://jakarta.apache.org/commons/httpclient/logging.html and some sample code and we should be able to get to the bottom of the problem. Mike On Jul 19, 2004, at 2:31 PM, Esquivel Sanchez, Arturo wrote: Hi, I'm getting the error: Error in parsing the status line from the response: unable to find line starting with HTTP. and i´m pretty sure that its related to the consideration documented by Daniel C. Amadei : JSSE prior to Java 1.4 incorrectly reports socket timeout. Prior to Java 1.4, in Sun's JSSE implementation, a read operation that has timed out incorrect reports end of stream condition instead of throwing java.io.InterruptedIOException as expected. HttpClient responds to this exception by assuming that the connection was dropped and throws a recoverable HTTP exception: Error in parsing the status line from the response: unable to find line starting with HTTP. It should instead report java.io.InterruptedIOException: Read timed out. If you see the unable to find line... message when working with an older version of JDK and JSSE, it can be caused by the timeout waiting for data and not by a problem with the connection. Work-around: One possible solution is to increase the timeout value as the server is taking too long to start sending the response. Alternatively you may choose to upgrade to Java 1.4 or above which does not exhibit this problem Unfortunely in my company´s tech unit is not going to be easy neither quick to upgrade to the Java version 1.4. And I already tried to increase the client setTimeOut method and didn´t work So is there a way you can help to modified the necesary components in order to fix the problem from the HttpClient side. Or give me some hints on how to fix it and generate a new commons-httpclient-2.0.jar that includes the fix. Or if there is already a version of the HttpClient v2.0 that fix this problem The version that i´m using is the 2.0. I really really appreciate your help Best Regards Arturo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27426] - [API Doc] Document exceptions thrown on execute methods
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27426. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27426 [API Doc] Document exceptions thrown on execute methods --- Additional Comments From [EMAIL PROTECTED] 2004-07-20 02:40 --- Wow Oleg! Nice work. This is quite a thorough addition. I read it mostly for content and it looks quite good. There were a few minor grammatical problems which we can fix once it's checked in. The only error I noticed was a typo in the ProtocolException section where HttpException was accidentally used at the beginning of the paragraph. Content-wise the only part that stuck out to me was the inclusion of the many exceptions that users will never see. It's nice that they're documented, but being that it's a user guide I think it may confuse people. If we could separate the non-user exceptions somehow that would be good. A separate section may be enough. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
