RE: [GUMP@brutus]: jakarta-commons/commons-logging failed
By the way, commons-logging developers could issue a maintenance release of c-l now, months before log4j 1.3 is released. At 09:55 AM 5/12/2004, Ceki Gülcü wrote: Hello, All hail gump. The use of Priority has been deprecated for over 2 years and it will be removed in log4j 1.3. Fortunately, the required changes are easy and are backward compatible. Commons-logging code needs to be changed as follows. Lines such as getLogger().log(FQCN, Priority.FATAL, message, t ); need to be changed to getLogger().log(FQCN, Logger.FATAL, message, t ); There 5 or 6 such lines in commons-logging. Note that the resulting commons-logging code will run on both log4j 1.2.x and 1.3 I hope this helps, At 12:56 AM 5/12/2004, Paul Smith wrote: Hi All, Not sure if this will get sufficient attention without bringing it here, so doing so... Yes, there has been a few changes under the hood in log4j recently. We'll have to chat internally to see what we can do, and get back to you. All hail gump for picking it up. cheers, Paul Smith -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28925] New: - conversion Float String
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=28925. 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=28925 conversion Float String Summary: conversion Float String Product: Commons Version: 1.6 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28925] - conversion Float String
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=28925. 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=28925 conversion Float String --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 12:14 --- Hi, I m working with tomcat 4.1.30 and Struts 1.1 My conversion from String to float or to double doesn't work. -- My sample code: My current Locale is FR; String montantp = 1789.89; String montantv = 1789,89; System.err.println(Le test sur les floats ); Number cliEncours8 = (Number) LocaleConvertUtils.convert( montantp , Float.class, getLocale(), null); System.err.println(storeToRecord v2 de montantp = + cliEncours8.floatValue() ); Number cliEncours9 = (Number) LocaleConvertUtils.convert( montantv, Float.class, getLocale(), null); System.err.println(storeToRecord de montantv = + cliEncours9.floatValue() ); My result : Le test sur les floats storeToRecord v2 de montantp =1789.0 storeToRecord v3 de montantv =1789.0 Have you got an idear ? Thanks .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] Cloning statistics
Phil Steitz wrote:
Ken Geis wrote:
I'm playing with commons-math to implement a data mining algorithm and
I am having a performance problem.
I am doing running statistics over an ordered set of data, storing the
statistics at each new value I come across. One way of doing this
would be to have an array of SummaryStatistics and do
for (int i = 0; i length; i++)
{
for (int j = i; j length; j++)
{
statsArray[j].addValue(values[i]);
}
}
another way is to do
for (int i = 0; i length; i++)
{
stats.addValue(values[i]);
statsArray[i] = SerializationUtils.clone(stats);
}
A lot of these objects are marked Serializable, but clone methods do
not exist. That's why I use commons-lang SerializationUtils.
Unfortunately, that makes the cloning take up 50% of my runtime
because (de)serialization is expensive.
I will probably patch the statistics classes, implementing enough of
clone() to make me happy. Would you like this patch?
An efficient cloning method might be useful, but it would still carry
around extra baggage and overhead for your use case
(SummaryStatisticsImpl nests a bunch of little stats objects and other
instance data).
What we might want to do is add a StatisticalSummaryBean, implementing
the StatisticalSummary interface and add a getSummary method to
SummaryStatistics returning an instance of this value bean containing
only the values of the statistics. Then you could just do
for (int i = 0; i length; i++)
{
stats.addValue(values[i]);
statsArray[i] = stats.getSummary();
}
since I presume that all you will want to do with statsArray[i] is
things like getMean(), getVariance(), etc. This would require much less
overhead than cloning the whole SummaryStatisticsImpl instance each time.
Since this would amount to a change to the SummaryStatistics interface,
if we want to do it, we should do it now, before 1.0. I am +1 to this
change and willing to implement it if no one objects.
Phil
Phil,
What would a Summary object contain? I suspect it would contain a double
value for each statistic (mean, var ...)? I assume a summary is read
only? I get the feeling this is something that would contain various
methods to return the statistical values. The ultimate debate arises,
Which statistics to place in it? In such a case different users have
different needs. If all we are talking about is an object that contains
the current state of the SummaryStatisticsImpl, I'll argue this should
be an exercise left up to the user.
Ken,
I guess I am a little confused by the purpose of all this cloning? Are
you attempting to maintain instantaneous statistics up to that point in
the array? Are the copies in the statsArray ever incremented, or are
they just replaced by new copies?
I'm still interested in well established specs for cloning and
serialization on these objects. We need to be able to persist and
duplicate without any resulting errors.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] Cloning statistics
Mark R. Diggory wrote:
Phil Steitz wrote:
Ken Geis wrote:
I'm playing with commons-math to implement a data mining algorithm
and I am having a performance problem.
I am doing running statistics over an ordered set of data, storing
the statistics at each new value I come across. One way of doing
this would be to have an array of SummaryStatistics and do
for (int i = 0; i length; i++)
{
for (int j = i; j length; j++)
{
statsArray[j].addValue(values[i]);
}
}
another way is to do
for (int i = 0; i length; i++)
{
stats.addValue(values[i]);
statsArray[i] = SerializationUtils.clone(stats);
}
A lot of these objects are marked Serializable, but clone methods do
not exist. That's why I use commons-lang SerializationUtils.
Unfortunately, that makes the cloning take up 50% of my runtime
because (de)serialization is expensive.
I will probably patch the statistics classes, implementing enough of
clone() to make me happy. Would you like this patch?
An efficient cloning method might be useful, but it would still carry
around extra baggage and overhead for your use case
(SummaryStatisticsImpl nests a bunch of little stats objects and
other instance data).
What we might want to do is add a StatisticalSummaryBean, implementing
the StatisticalSummary interface and add a getSummary method to
SummaryStatistics returning an instance of this value bean
containing only the values of the statistics. Then you could just do
for (int i = 0; i length; i++)
{
stats.addValue(values[i]);
statsArray[i] = stats.getSummary();
}
since I presume that all you will want to do with statsArray[i] is
things like getMean(), getVariance(), etc. This would require much
less overhead than cloning the whole SummaryStatisticsImpl instance
each time.
Since this would amount to a change to the SummaryStatistics
interface, if we want to do it, we should do it now, before 1.0. I am
+1 to this change and willing to implement it if no one objects.
Phil
Phil,
What would a Summary object contain? I suspect it would contain a double
value for each statistic (mean, var ...)? I assume a summary is read
only?
Yes, a read-only value bean representing current values of statistics.
I get the feeling this is something that would contain various
methods to return the statistical values. The ultimate debate arises,
Which statistics to place in it?
The most commonly used ones -- those in the StatisticalSummary interface.
In such a case different users have
different needs. If all we are talking about is an object that contains
the current state of the SummaryStatisticsImpl, I'll argue this should
be an exercise left up to the user.
I think that it would be useful to provide direct support for this, since
anyone who wants to pass statistical summaries around in an efficient way
will need this.
Phil
Ken,
I guess I am a little confused by the purpose of all this cloning? Are
you attempting to maintain instantaneous statistics up to that point in
the array? Are the copies in the statsArray ever incremented, or are
they just replaced by new copies?
I'm still interested in well established specs for cloning and
serialization on these objects. We need to be able to persist and
duplicate without any resulting errors.
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FileUpload-Modifying request content-type
All, I'm working with the FileUpload utility to grab images out of the request, I'd like to be able to pass the request (HttpServletRequest) object back to it's original handler, but the handler cannot take the 'multipart/form-data' encoding. Have any of you run into a solution for converting the request (HttpServletRequest) object back to a plain encoding? Thanks, Dave Rowe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils] remove dependency on commons-logging
The only real issue i have with commons-logging is the hardcoded list of loggers that are available, and having to include the adapters for those loggers in our programs no matter what. It would be nice to have a service provider (read discovery mechanism) to figure out what log package adapters were available. In that way, each adapter implementation could be put in it's own jar, as well as having a strictly api/factory jar. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 8:25 PM To: Jakarta Commons Developers List Subject: Re: [beanutils] remove dependency on commons-logging I haven't heard any complaints from the community that commons components are tied to commons-logging so I'm a bit confused about why we need to decouple it. We created logging to isolate us from specific logging packages in the first place. Now we need to decouple from our own library? IMO, the most compelling reasons for decoupling collections from other commons components were: 1. The dependency wasn't really needed 2. So we don't trap users in dependency hell when 2 different commons components use different versions of collections. I don't see either of those benefits in removing a logging dependency. David --- Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2004-05-12 at 00:53, David Graham wrote: I was reluctantly in favor of copying certain Collections classes as a temporary solution to removing that dependency but I don't see why we want to permanently copy Logging classes to other projects. Commons Logging is an abstraction for Log4j and java.util.logging; now we're going to add yet another abstraction above Commons Logging? That doesn't make any sense to me. I understand your concerns. A layer between libs and commons-logging does seem a little odd at first. It would be nice if commons-logging were so small that it could be copied in its entirety into each project, allowing every project to access any logging library. However that isn't the case. Commons-logging is small and stable, but not small and stable enough for that. Duplication of code *is* a reasonable solution, sometimes. If you wanted to sum up the values in an array of ints, would you find, download and use a library that had that code in it, or would you just write the necessary 3 lines of code? But of course anyone duplicating a complex piece of code like a fourier transform would deserve a good LARTing. It's a grey line. I think duplicating one simple class and one interface in order to avoid a dependency on commons-logging is reasonable. However I'm happy to go with the majority opinion on that; as I said in another email, for the work *I* do with java, bundling commons-logging is not an issue. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover - 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 28819] - Submission of BigMatrix, a RealMatrix clone to support BigDecimal values
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=28819. 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=28819 Submission of BigMatrix, a RealMatrix clone to support BigDecimal values --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 13:37 --- I've tried two ways to attach this, and it won't preserve the filename either way. Just save the later attachment as BigMatrix.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils] remove dependency on commons-logging
Hi, Just how many of the 50 first off will be logging? So take this subclass Every single one hopefully. Have you benchmarked this IoC logging approach for performance (versus say a log4j for a given set of classes)? Are we making a mountain out of a mole hill? ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FileUpload-Modifying request content-type
Return Receipt Your FileUpload-Modifying request content-type document : was Richard Sitze/Austin/IBM received by: at: 05/12/2004 08:52:40 CDT
DO NOT REPLY [Bug 28829] - [bug report] Commons-Math binomial distribution method returns 1 when it should return 0
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=28829. 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=28829 [bug report] Commons-Math binomial distribution method returns 1 when it should return 0 --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 14:41 --- I would have thought it should have returned 1 only for zero and zero for all values greater then zero - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28829] - [bug report] Commons-Math binomial distribution method returns 1 when it should return 0
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=28829. 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=28829 [bug report] Commons-Math binomial distribution method returns 1 when it should return 0 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 14:50 --- I would like to hold off on closing this. If this returned value is disputed, I'd like to see each party document it with references as to where, why and what they are basing thier results on. I'm not suggesting that either is correct or incorrect, but both opinions need evidence to back them up. We want be returning an expected result, if we are deviating from expected for some reason, lets clearly document it. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TX (=transaction) Package in commons?
Hi Stephen! Decorator is a very good idea indeed! Due to internal mechanisms this works for Maps that do not loose data (unlike LRUMap) only, but for them I will provide decorators an option. As the package will depend on commons.collections I will have a closer look at AbstractHashedMap and AbstractLinkedMap! I noticed much has changed in the 3.0 version of commons.collections, so I will have to refactor stuff anyway. Where do you think would be the right place for the transactional file system? Somewhere inside commons? Oliver - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] Subject: TX (=transaction) Package in commons? Date: Wed, 12 May 2004 11:50:02 +0100 Hi! This looks like an intruiging package and fits what commons started out to do. I'm +1 to using the sandbox here, but, as always, reserve the right to kick it elsewhere on promotion if that is most applicable. Firstly I would prefer transaction over tx as its more immediately obvious as to the meaning. Secondly, are you depending on [collections]? Collections has the useful AbstractHashedMap and AbstractLinkedMap classes which enable additional collections like this to be built easily. They also have the MapIterator which make accessing the map much easier. Finally, you might want to consider whether you can provide an XAMapDecorator that can decorate any other map, as this provides a lot of flexibility in design. (You may not even need your own hash/LRU implementations that way) Stephen - Original Message - From: Oliver Zeigermann [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 11:22 AM Subject: TX (=transaction) Package in commons? Folks! I just started an effort to create a package for transactional utility classes in the commons sandbox area. The aim is to seperate common transaction utilities used in Jakarta Slide into a project of its own. As a side-effect I would clean up interfaces and code. All this would result in a package called org.apache.commons.tx (or org.apache.commons.transaction?). It would contain at least the following stuff: interface XAMap extends Map, XAResource --- All retrieval / insertion of data is done using the well known Map methods. Tx controll will also be done using a standard interface from the JTA. This also allows to link this cache / map into a distributed transaction in a J2EE container, even though this required the implementation of a connector. abstract class XAMapBase implements XAMap - Base class that mainly implements XAResource class XAHashMap extends XAMapBase; uses HashMap, PriorityLock - Transactional HashMap based on HashMap from java.util. Uses PriorityLock from org.apache.commons.tx to allow for several isolation levels that are configured in the ctor. clsss XALRUCache extendes XAMapBase; uses LRUMap, PriorityLock -- Transactional Cache based on LRUMap from org.apache.commons.collections. Uses PriorityLock from org.apache.commons.tx to allow for several isolation levels that are configured in the ctor. interface MultiLevelLock / class GenericLock implements MultiLevelLock / --- class PriorityLock implements MultiLevelLock Interfaces and implementations for locks that can have more than one owner at different compatible levels. PriorityLock allows to specify preferences of lock levels. E.g. this would allow to prefer write locks over read locks. Preferences can be specified either by direction (higher level over lower or vice-versa) or by an array explicitely decribing the sequqnece of preferred levels. MAYBE: Transactional file system Slide also contains a transactional file system that allows you to create / delete / modify a set of files using full ACID transactions. But, maybe, commons is not the right place for this? WHAT DO I WANT FROM YOU? I am looking for comments / opinions / etc. E.g. Is commons sandbox the right place for such a package? , Does all this already exist somewhere in Jakarata or somewhere else?, Are there any reasons I should *not* do what I plan?, Would anyone except my be interested in this? ... That's it and cheers, Oliver - 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
DO NOT REPLY [Bug 28930] New: - TreeList with inproved iterator() and listIterator() implementation
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=28930. 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=28930 TreeList with inproved iterator() and listIterator() implementation Summary: TreeList with inproved iterator() and listIterator() implementation Product: Commons Version: 3.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Collections AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Added references to next and and prev using a flag. This is called Faedelung in German :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28930] - TreeList with inproved iterator() and listIterator() implementation
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=28930. 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=28930 TreeList with inproved iterator() and listIterator() implementation --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 16:09 --- Created an attachment (id=11523) Source ofnew version - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28930] - TreeList with inproved iterator() and listIterator() implementation
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=28930. 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=28930 TreeList with inproved iterator() and listIterator() implementation --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 16:11 --- Created an attachment (id=11524) Forgot to rename _height to height - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TX (=transaction) Package in commons?
Hi, I'm also intrigued, and I also second Senor Colebourne's thought of starting this out in the sandbox. Yoav Shapira Millennium Research Informatics -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 11:00 AM To: Jakarta Commons Developers List Subject: Re: TX (=transaction) Package in commons? Hi Stephen! Decorator is a very good idea indeed! Due to internal mechanisms this works for Maps that do not loose data (unlike LRUMap) only, but for them I will provide decorators an option. As the package will depend on commons.collections I will have a closer look at AbstractHashedMap and AbstractLinkedMap! I noticed much has changed in the 3.0 version of commons.collections, so I will have to refactor stuff anyway. Where do you think would be the right place for the transactional file system? Somewhere inside commons? Oliver - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] Subject: TX (=transaction) Package in commons? Date: Wed, 12 May 2004 11:50:02 +0100 Hi! This looks like an intruiging package and fits what commons started out to do. I'm +1 to using the sandbox here, but, as always, reserve the right to kick it elsewhere on promotion if that is most applicable. Firstly I would prefer transaction over tx as its more immediately obvious as to the meaning. Secondly, are you depending on [collections]? Collections has the useful AbstractHashedMap and AbstractLinkedMap classes which enable additional collections like this to be built easily. They also have the MapIterator which make accessing the map much easier. Finally, you might want to consider whether you can provide an XAMapDecorator that can decorate any other map, as this provides a lot of flexibility in design. (You may not even need your own hash/LRU implementations that way) Stephen - Original Message - From: Oliver Zeigermann [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 11:22 AM Subject: TX (=transaction) Package in commons? Folks! I just started an effort to create a package for transactional utility classes in the commons sandbox area. The aim is to seperate common transaction utilities used in Jakarta Slide into a project of its own. As a side-effect I would clean up interfaces and code. All this would result in a package called org.apache.commons.tx (or org.apache.commons.transaction?). It would contain at least the following stuff: interface XAMap extends Map, XAResource --- All retrieval / insertion of data is done using the well known Map methods. Tx controll will also be done using a standard interface from the JTA. This also allows to link this cache / map into a distributed transaction in a J2EE container, even though this required the implementation of a connector. abstract class XAMapBase implements XAMap - Base class that mainly implements XAResource class XAHashMap extends XAMapBase; uses HashMap, PriorityLock - Transactional HashMap based on HashMap from java.util. Uses PriorityLock from org.apache.commons.tx to allow for several isolation levels that are configured in the ctor. clsss XALRUCache extendes XAMapBase; uses LRUMap, PriorityLock -- Transactional Cache based on LRUMap from org.apache.commons.collections. Uses PriorityLock from org.apache.commons.tx to allow for several isolation levels that are configured in the ctor. interface MultiLevelLock / class GenericLock implements MultiLevelLock / --- class PriorityLock implements MultiLevelLock Interfaces and implementations for locks that can have more than one owner at different compatible levels. PriorityLock allows to specify preferences of lock levels. E.g. this would allow to prefer write locks over read locks. Preferences can be specified either by direction (higher level over lower or vice-versa) or by an array explicitely decribing the sequqnece of preferred levels. MAYBE: Transactional file system Slide also contains a transactional file system that allows you to create / delete / modify a set of files using full ACID transactions. But, maybe, commons is not the right place for this? WHAT DO I WANT FROM YOU? I am looking for comments / opinions / etc. E.g. Is commons sandbox the right place for such a package? , Does all this already exist somewhere in Jakarata or somewhere else?, Are there any reasons I should *not* do what I plan?, Would anyone except my be interested in this? ... That's it and cheers, Oliver
DO NOT REPLY [Bug 28933] New: - patch to make commons-logging compileable againt cvs-head of log4j
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=28933. 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=28933 patch to make commons-logging compileable againt cvs-head of log4j Summary: patch to make commons-logging compileable againt cvs- head of log4j Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Logging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] patch to make commons-logging compileable againt cvs-head of log4j slightly changed CustomConfigTestCase - getThrowable() on ThrowableInfo is no longer accessible - in fact it isnt any longer stored in ThrowableInfor, now only the string representation is stored. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28933] - patch to make commons-logging compileable againt cvs-head of log4j
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=28933. 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=28933 patch to make commons-logging compileable againt cvs-head of log4j --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 18:02 --- Created an attachment (id=11525) [PATCH] implement log4j changes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbcp/src/java/org/apache/commons/dbcp PoolableConnectionFactory.java
dirkv 2004/05/12 11:28:59 Modified:dbcp/src/java/org/apache/commons/dbcp PoolableConnectionFactory.java Log: Bugzilla Bug 28893: PoolableConnectionFactory has incomplete javadoc on validationQuery - update javadoc (reported by Hontvari Jozsef) Revision ChangesPath 1.21 +8 -8 jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/PoolableConnectionFactory.java Index: PoolableConnectionFactory.java === RCS file: /home/cvs/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/PoolableConnectionFactory.java,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- PoolableConnectionFactory.java29 Feb 2004 20:18:25 - 1.20 +++ PoolableConnectionFactory.java12 May 2004 18:28:58 - 1.21 @@ -38,7 +38,7 @@ * @param connFactory the [EMAIL PROTECTED] ConnectionFactory} from which to obtain base [EMAIL PROTECTED] Connection}s * @param pool the [EMAIL PROTECTED] ObjectPool} in which to pool those [EMAIL PROTECTED] Connection}s * @param stmtPoolFactory the [EMAIL PROTECTED] KeyedObjectPoolFactory} to use to create [EMAIL PROTECTED] KeyedObjectPool}s for pooling [EMAIL PROTECTED] java.sql.PreparedStatement}s, or ttnull/tt to disable [EMAIL PROTECTED] java.sql.PreparedStatement} pooling - * @param validationQuery a query to use to [EMAIL PROTECTED] #validateObject validate} [EMAIL PROTECTED] Connection}s. Should return at least one row. May be ttnull/tt + * @param validationQuery a query to use to [EMAIL PROTECTED] #validateObject validate} [EMAIL PROTECTED] Connection}s. Should return at least one row. Using ttnull/tt turns off validation. * @param defaultReadOnly the default read only setting for borrowed [EMAIL PROTECTED] Connection}s * @param defaultAutoCommit the default auto commit setting for returned [EMAIL PROTECTED] Connection}s */ @@ -57,7 +57,7 @@ * @param connFactory the [EMAIL PROTECTED] ConnectionFactory} from which to obtain base [EMAIL PROTECTED] Connection}s * @param pool the [EMAIL PROTECTED] ObjectPool} in which to pool those [EMAIL PROTECTED] Connection}s * @param stmtPoolFactory the [EMAIL PROTECTED] KeyedObjectPoolFactory} to use to create [EMAIL PROTECTED] KeyedObjectPool}s for pooling [EMAIL PROTECTED] java.sql.PreparedStatement}s, or ttnull/tt to disable [EMAIL PROTECTED] java.sql.PreparedStatement} pooling - * @param validationQuery a query to use to [EMAIL PROTECTED] #validateObject validate} [EMAIL PROTECTED] Connection}s. Should return at least one row. May be ttnull/tt + * @param validationQuery a query to use to [EMAIL PROTECTED] #validateObject validate} [EMAIL PROTECTED] Connection}s. Should return at least one row. Using ttnull/tt turns off validation. * @param defaultReadOnly the default read only setting for borrowed [EMAIL PROTECTED] Connection}s * @param defaultAutoCommit the default auto commit setting for returned [EMAIL PROTECTED] Connection}s * @param defaultTransactionIsolation the default Transaction Isolation setting for returned [EMAIL PROTECTED] Connection}s @@ -78,7 +78,7 @@ * @param connFactory the [EMAIL PROTECTED] ConnectionFactory} from which to obtain base [EMAIL PROTECTED] Connection}s * @param pool the [EMAIL PROTECTED] ObjectPool} in which to pool those [EMAIL PROTECTED] Connection}s * @param stmtPoolFactory the [EMAIL PROTECTED] KeyedObjectPoolFactory} to use to create [EMAIL PROTECTED] KeyedObjectPool}s for pooling [EMAIL PROTECTED] java.sql.PreparedStatement}s, or ttnull/tt to disable [EMAIL PROTECTED] java.sql.PreparedStatement} pooling - * @param validationQuery a query to use to [EMAIL PROTECTED] #validateObject validate} [EMAIL PROTECTED] Connection}s. Should return at least one row. May be ttnull/tt + * @param validationQuery a query to use to [EMAIL PROTECTED] #validateObject validate} [EMAIL PROTECTED] Connection}s. Should return at least one row. Using ttnull/tt turns off validation. * @param defaultReadOnly the default read only setting for borrowed [EMAIL PROTECTED] Connection}s * @param defaultAutoCommit the default auto commit setting for returned [EMAIL PROTECTED] Connection}s * @param config the AbandonedConfig if tracing SQL objects @@ -108,7 +108,7 @@ * @param connFactory the [EMAIL PROTECTED] ConnectionFactory} from which to obtain base [EMAIL PROTECTED] Connection}s * @param pool the [EMAIL PROTECTED] ObjectPool} in which to pool those [EMAIL PROTECTED] Connection}s * @param stmtPoolFactory the [EMAIL PROTECTED] KeyedObjectPoolFactory} to use to create [EMAIL PROTECTED] KeyedObjectPool}s for pooling [EMAIL PROTECTED] java.sql.PreparedStatement}s, or ttnull/tt to disable [EMAIL PROTECTED]
DO NOT REPLY [Bug 28893] - PoolableConnectionFactory has incomplete javadoc on validationQuery
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=28893. 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=28893 PoolableConnectionFactory has incomplete javadoc on validationQuery [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 18:31 --- javadoc updated: Using null turns off validation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [beanutils] remove dependency on commons-logging
From: Shapira, Yoav [EMAIL PROTECTED] Date: 2004/05/12 Wed AM 08:45:45 EDT To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: RE: [beanutils] remove dependency on commons-logging Just how many of the 50 first off will be logging? So take this subclass Every single one hopefully. Have you benchmarked this IoC logging approach for performance (versus say a log4j for a given set of classes)? No I have not but I don't think an extra call is going to make or break an application. Again everyone has valid concerns about the approach and it may not be the best fit but worth considering. Are we making a mountain out of a mole hill? ;) Maybe as I'm beginning to see. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28912] - Connection re-use conflates logical and physical connections
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=28912. 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=28912 Connection re-use conflates logical and physical connections --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 18:44 --- PoolingDataSource has a PoolGuardConnectionWrapper doing what you describe. (preventing access after closing the wrapped pooled connection) How did you create your pool? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jakarta-commons/commons-logging failed
-Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/logging] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-xalan2.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-lf5-20040512.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-chainsaw-20040512.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-20040512.jar:/usr/local/gump/public/workspace/avalon-logkit/target/avalon-logkit-20040512.jar- [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.WARN, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:145: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,nulltype) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.ERROR, message, null ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:153: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,java.lang.Throwable) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.ERROR, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:161: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,nulltype) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.FATAL, message, null ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:169: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,java.lang.Throwable) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.FATAL, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:196: isEnabledFor(org.apache.log4j.Level) in org.apache.log4j.Category cannot be applied to (org.apache.log4j.Priority) [javac] return getLogger().isEnabledFor(Priority.ERROR); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:204: isEnabledFor(org.apache.log4j.Level) in org.apache.log4j.Category cannot be applied to (org.apache.log4j.Priority) [javac] return getLogger().isEnabledFor(Priority.FATAL); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:228: isEnabledFor(org.apache.log4j.Level) in org.apache.log4j.Category cannot be applied to (org.apache.log4j.Priority) [javac] return getLogger().isEnabledFor(Priority.WARN); [javac] ^ [javac] 30 errors BUILD FAILED /usr/local/gump/public/workspace/jakarta-commons/logging/build.xml:246: Compile failed; see the compiler error output for details. at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268) at org.apache.tools.ant.Task.perform(Task.java:363) at org.apache.tools.ant.Target.execute(Target.java:321) at org.apache.tools.ant.Target.performTasks(Target.java:348) at org.apache.tools.ant.Project.executeTarget(Project.java:1212) at org.apache.tools.ant.Project.executeTargets(Project.java:1060) at org.apache.tools.ant.Main.runBuild
DO NOT REPLY [Bug 28912] - Connection re-use conflates logical and physical connections
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=28912. 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=28912 Connection re-use conflates logical and physical connections --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 19:12 --- Pretty much copying out one of the examples, but I'm using driver, not data source: ObjectPool connectionPool = new GenericObjectPool(null); ConnectionFactory connectionFactory = new DriverManagerConnectionFactory(dbc.getURL(), props); new PoolableConnectionFactory(connectionFactory, connectionPool, null, null, false, true); Class.forName(org.apache.commons.dbcp.PoolingDriver); String poolURLBase = jdbc:apache:commons:dbcp:; PoolingDriver driver = (PoolingDriver) DriverManager.getDriver(poolURLBase); driver.registerPool(poolName, connectionPool); dbc.setPoolURL(poolURLBase + poolName); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [New Proposal] An Imaging wrapper package
Sorry for the delay. On 07.05.2004 12:37:52 Abey Mullassery wrote: Thanks a lot for the detailed mail and very useful suggestions. I agree with Martin that Apache Commons would be a better place. Another place could be the shared code base in the upcoming XML Graphics project but I think Apache Commons is still preferred. I'd rather not have such a package outside the ASF if possible. There are enough potential customers here that we can justify a shared ASF-homed API adapter for images. That was my understanding as well eventhough upcoming XML Graphics project was news to me. I personally would love to share this code with ASF than anywhere else. Since many of you say that its better fit to be an Apche commons project, I will send this proposal to the Apache-commons list. Is the procedure same for Apache Commons as well? I think so. Since you're an Apache committer already, it might not be so difficult to bring the code in. But if it's not grown within the ASF it might have to go through the incubator. But I think it is best to propose the package to Apache commons after we redefine the scope based on the feedback that we have got here. I started writing this library for myself :-) and hence I designed it in such as way that was easy for me to use (for Image Taglib and Image ANT Tasks). However it is just in a preliminary stage to be an apache commons package. If this is to succeed I think this needs to be more than a one-man-show. As I said before my priorities currently don't allow me to participate enough to make a difference. I can only lend moral support. snip what=scope definition/ I agree with your analysis. If you had to support the code all by yourself (i.e. without the help of others) it might be best if you kept the code or include it with the rest of the taglib code. Only if you get additional help will make the transition to Apache Commons make sense. It's probably best to ping FOP-land to see if anyone (with resources) is interested to help out. I'll drop a note on [EMAIL PROTECTED] so they know what's on the table. Could you elaborate what you mean by SVG operations? All I meant was a simpe interface with methods that take SVG string/file/stream as input, does some manipulation on it and returns SVG. That sounds to me as it would really belong into Batik. Let me know your thoughts, I'm sorry that I cannot be more of a help but I sympathize with your goal. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map LRUMap.java
scolebourne2004/05/12 12:51:28
Modified:collections/src/test/org/apache/commons/collections/map
TestLRUMap.java
collections/src/java/org/apache/commons/collections/map
LRUMap.java
Log:
Add behaviour to scan map to find a removable element when full
bug 28887, from Mario Ivankovits
Revision ChangesPath
1.8 +51 -4
jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestLRUMap.java
Index: TestLRUMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestLRUMap.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TestLRUMap.java 16 Apr 2004 23:53:59 - 1.7
+++ TestLRUMap.java 12 May 2004 19:51:28 - 1.8
@@ -240,9 +240,11 @@
LinkEntry entry;
Object key;
Object value;
+
MockLRUMapSubclass(int size) {
super(size);
}
+
protected boolean removeLRU(LinkEntry entry) {
this.entry = entry;
this.key = entry.getKey();
@@ -252,7 +254,22 @@
}
public void testRemoveLRUBlocksRemove() {
-MockLRUMapSubclassBlocksRemove map = new MockLRUMapSubclassBlocksRemove(2);
+MockLRUMapSubclassBlocksRemove map = new MockLRUMapSubclassBlocksRemove(2,
false);
+assertEquals(0, map.size());
+map.put(A, a);
+assertEquals(1, map.size());
+map.put(B, b);
+assertEquals(2, map.size());
+map.put(C, c); // should remove oldest, which is A=a, but this is
blocked
+assertEquals(3, map.size());
+assertEquals(2, map.maxSize());
+assertEquals(true, map.containsKey(A));
+assertEquals(true, map.containsKey(B));
+assertEquals(true, map.containsKey(C));
+}
+
+public void testRemoveLRUBlocksRemoveScan() {
+MockLRUMapSubclassBlocksRemove map = new MockLRUMapSubclassBlocksRemove(2,
true);
assertEquals(0, map.size());
map.put(A, a);
assertEquals(1, map.size());
@@ -267,14 +284,44 @@
}
static class MockLRUMapSubclassBlocksRemove extends LRUMap {
-MockLRUMapSubclassBlocksRemove(int size) {
-super(size);
+MockLRUMapSubclassBlocksRemove(int size, boolean scanUntilRemove) {
+super(size, scanUntilRemove);
}
+
protected boolean removeLRU(LinkEntry entry) {
return false;
}
}
+public void testRemoveLRUFirstBlocksRemove() {
+MockLRUMapSubclassFirstBlocksRemove map = new
MockLRUMapSubclassFirstBlocksRemove(2);
+assertEquals(0, map.size());
+map.put(A, a);
+assertEquals(1, map.size());
+map.put(B, b);
+assertEquals(2, map.size());
+map.put(C, c); // should remove oldest, which is A=a but this is
blocked - so advance to B=b
+assertEquals(2, map.size());
+assertEquals(2, map.maxSize());
+assertEquals(true, map.containsKey(A));
+assertEquals(false, map.containsKey(B));
+assertEquals(true, map.containsKey(C));
+}
+
+static class MockLRUMapSubclassFirstBlocksRemove extends LRUMap {
+MockLRUMapSubclassFirstBlocksRemove(int size) {
+super(size, true);
+}
+
+protected boolean removeLRU(LinkEntry entry) {
+if (a.equals(entry.getValue())) {
+return false;
+} else {
+return true;
+}
+}
+}
+
//public void testCreate() throws Exception {
//resetEmpty();
//writeExternalFormToDisk((java.io.Serializable) map,
D:/dev/collections/data/test/LRUMap.emptyCollection.version3.obj);
1.13 +83 -6
jakarta-commons/collections/src/java/org/apache/commons/collections/map/LRUMap.java
Index: LRUMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/LRUMap.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- LRUMap.java 25 Apr 2004 23:30:07 - 1.12
+++ LRUMap.java 12 May 2004 19:51:28 - 1.13
@@ -47,6 +47,7 @@
* @author Morgan Delagrange
* @author Stephen Colebourne
* @author Mike Pettypiece
+ * @author Mario Ivankovits
*/
public class LRUMap
extends AbstractLinkedMap implements BoundedMap, Serializable, Cloneable {
@@ -55,15 +56,19 @@
static final long serialVersionUID = -612114643488955218L;
/** Default maximum size */
protected static final int DEFAULT_MAX_SIZE = 100;
cvs commit: jakarta-commons/collections RELEASE-NOTES.html
scolebourne2004/05/12 12:55:56 Modified:collections RELEASE-NOTES.html Log: Add behaviour to scan map to find a removable element when full bug 28887, from Mario Ivankovits Revision ChangesPath 1.47 +1 -0 jakarta-commons/collections/RELEASE-NOTES.html Index: RELEASE-NOTES.html === RCS file: /home/cvs/jakarta-commons/collections/RELEASE-NOTES.html,v retrieving revision 1.46 retrieving revision 1.47 diff -u -r1.46 -r1.47 --- RELEASE-NOTES.html3 May 2004 22:43:57 - 1.46 +++ RELEASE-NOTES.html12 May 2004 19:55:56 - 1.47 @@ -56,6 +56,7 @@ liSingletonIterator - make remove() functionality optional/li liAbstractLinkedList/NodeCachingLinkedList - added getValue() and setValue() to Node, and made everything use them/li liLRUMap - The addMapping() method now uses isFull() to determine whether it is full/li +liLRUMap - Add boolean flag, scanUntilRemovable, giving the removeLRU() method more power [28887]/li /ul h4Made Serializable/h4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TX (=transaction) Package in commons?
From: Oliver Zeigermann [EMAIL PROTECTED] Where do you think would be the right place for the transactional file system? Somewhere inside commons? There is currently a move for one commons project to produce multiple jars. ie. the project groups like-minded people and similar area code together. Thus I would code under the same project to start with but separable into a different jar file. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28887] - add flag to LRUMap to allow scan of next removeable entry
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=28887. 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=28887 add flag to LRUMap to allow scan of next removeable entry [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 19:58 --- Patch applied, minor changes. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] BeanMap
Looks good. It may be worth renaming the inner class MyMapEntry to something more sensible like MapEntry at this point - it is an exposed API class, and annoyingly named. Stephen - Original Message - From: robert burrell donkin [EMAIL PROTECTED] BeanMap is now in bean-collections. - robert On 10 May 2004, at 21:23, Stephen Colebourne wrote: From: robert burrell donkin [EMAIL PROTECTED] I want to eject it from [collections], as it fits logically better with [beanutils] (as it deals with beans and reflection) and is quite a large size. The test cases can now be taken too, as [collections] produces its test framework as a jar. fine. want to handle it (or shall i)? I'm not all that familiiar with beanutils - I can make a stab, but it might be easier for you, especially as you are moving things around to create this new jar anyway. Stephen - 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]
Re: [PATCH] : [primitives] IntHashMap -- A hash map that uses primitive interger for the key rather than objects.
Your patch got lost - perhaps you could attach it to a bugzilla request? Thanks Stephen - Original Message - From: Ahimanikya Satapathy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 1:26 AM Subject: [PATCH] : [primitives] IntHashMap -- A hash map that uses primitive interger for the key rather than objects. I initially wrote this for Axion. But I think this is a good candidate for commons collection-primitives. I searched around to get similar implementation, but I did not found a complete implementation for the same. Any improvement suggestion will be greatly appreciated. - 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]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server ProxyRequestHandler.java
olegk 2004/05/12 13:43:54
Modified:httpclient/src/examples ChunkEncodedPost.java PostXML.java
UnbufferedPost.java
httpclient/src/java/org/apache/commons/httpclient
MultiThreadedHttpConnectionManager.java
httpclient/src/java/org/apache/commons/httpclient/methods
EntityEnclosingMethod.java
httpclient/src/test/org/apache/commons/httpclient
TestMethodCharEncoding.java TestMethodsNoHost.java
TestWebappBasicAuth.java TestWebappMethods.java
TestWebappNoncompliant.java
TestWebappPostMethod.java TestWebappRedirect.java
httpclient/src/test/org/apache/commons/httpclient/server
ProxyRequestHandler.java
Log:
Cleanup of deprecated methods in the test cases and sample applications
Contributed by Oleg Kalnichevski
Revision ChangesPath
1.6 +18 -12jakarta-commons/httpclient/src/examples/ChunkEncodedPost.java
Index: ChunkEncodedPost.java
===
RCS file: /home/cvs/jakarta-commons/httpclient/src/examples/ChunkEncodedPost.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ChunkEncodedPost.java 22 Feb 2004 18:08:45 - 1.5
+++ ChunkEncodedPost.java 12 May 2004 20:43:53 - 1.6
@@ -31,6 +31,7 @@
import java.io.FileInputStream;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.HttpStatus;
+import org.apache.commons.httpclient.methods.InputStreamRequestEntity;
import org.apache.commons.httpclient.methods.PostMethod;
/**
@@ -50,16 +51,21 @@
PostMethod httppost = new
PostMethod(http://localhost:8080/httpclienttest/body;);
-httppost.setRequestBody(new FileInputStream(new File(args[0])));
-httppost.setRequestContentLength(PostMethod.CONTENT_LENGTH_CHUNKED);
+File file = new File(args[0]);
-client.executeMethod(httppost);
+httppost.setRequestEntity(new InputStreamRequestEntity(new
FileInputStream(file)));
+httppost.setContentChunked(true);
-if (httppost.getStatusCode() == HttpStatus.SC_OK) {
-System.out.println(httppost.getResponseBodyAsString());
-} else {
- System.out.println(Unexpected failure: +
httppost.getStatusLine().toString());
-}
-httppost.releaseConnection();
+try {
+client.executeMethod(httppost);
+
+if (httppost.getStatusCode() == HttpStatus.SC_OK) {
+System.out.println(httppost.getResponseBodyAsString());
+} else {
+ System.out.println(Unexpected failure: +
httppost.getStatusLine().toString());
+}
+} finally {
+httppost.releaseConnection();
+}
}
}
1.13 +18 -20jakarta-commons/httpclient/src/examples/PostXML.java
Index: PostXML.java
===
RCS file: /home/cvs/jakarta-commons/httpclient/src/examples/PostXML.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- PostXML.java 22 Feb 2004 18:08:45 - 1.12
+++ PostXML.java 12 May 2004 20:43:53 - 1.13
@@ -32,7 +32,7 @@
import java.io.FileInputStream;
import org.apache.commons.httpclient.HttpClient;
-import org.apache.commons.httpclient.methods.EntityEnclosingMethod;
+import org.apache.commons.httpclient.methods.InputStreamRequestEntity;
import org.apache.commons.httpclient.methods.PostMethod;
/**
@@ -78,17 +78,12 @@
PostMethod post = new PostMethod(strURL);
// Request content will be retrieved directly
// from the input stream
-post.setRequestBody(new FileInputStream(input));
// Per default, the request content needs to be buffered
// in order to determine its length.
// Request body buffering can be avoided when
-// = content length is explicitly specified
-// = chunk-encoding is used
-if (input.length() Integer.MAX_VALUE) {
-post.setRequestContentLength(input.length());
-} else {
-
post.setRequestContentLength(EntityEnclosingMethod.CONTENT_LENGTH_CHUNKED);
-}
+// content length is explicitly specified
+post.setRequestEntity(new InputStreamRequestEntity(
+new FileInputStream(input), input.length()));
// Specify content type and encoding
// If content encoding is not explicitly specified
// ISO-8859-1 is assumed
@@ -96,13 +91,16 @@
// Get HTTP client
HttpClient httpclient = new HttpClient();
// Execute request
-int result =
[all][collections] Solving binary incompatability
What should commons do when projects get released with unplanned binary incompatabilities that cause issues, as with collections IteratorUtils? I can see two basic solutions: 1) Procede onwards, and tell users to upgrade to the later version. This may not be possible if two OSS projects have built against two versions of the library. 2) Produce a replacement build that puts the API back to how things were. This causes problems for anyone who built against the newer version of the library. For example, should [collections] next release be 4.0 instead of 3.1, such that 4 is compatible with 2.1 but not 3? Release 3 then becomes deprecated. Or does this just create another round of problems. Any other bright ideas??? Stephen PS. The particular problem is in IteratorUtils where 6 methods and 2 constants changed return type, which is binary incompatible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][collections] Solving binary incompatability
We've been using major version numbers to allow non-deprecated incompatible changes. For example, if you deprecate something for 1.1 you can remove it in 1.2 but if you want to make major breaking changes that deprecation can't solve you need to go to 2.0. If I understand correctly, incompatible changes were made to collections after 3.0 and the next planned release is 3.1. So, since you haven't released 3.1 yet, you can still go back and fix the incompatibilities. Or, you could release 3.1 as 4.0 but that seems like a big jump for a small amount of fixable changes. David --- Stephen Colebourne [EMAIL PROTECTED] wrote: What should commons do when projects get released with unplanned binary incompatabilities that cause issues, as with collections IteratorUtils? I can see two basic solutions: 1) Procede onwards, and tell users to upgrade to the later version. This may not be possible if two OSS projects have built against two versions of the library. 2) Produce a replacement build that puts the API back to how things were. This causes problems for anyone who built against the newer version of the library. For example, should [collections] next release be 4.0 instead of 3.1, such that 4 is compatible with 2.1 but not 3? Release 3 then becomes deprecated. Or does this just create another round of problems. Any other bright ideas??? Stephen PS. The particular problem is in IteratorUtils where 6 methods and 2 constants changed return type, which is binary incompatible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/list AbstractTestList.java
scolebourne2004/05/12 15:20:54
Modified:collections/src/test/org/apache/commons/collections/list
AbstractTestList.java
Log:
Add tests of specific ListIterator behaviour
Revision ChangesPath
1.7 +35 -2
jakarta-commons/collections/src/test/org/apache/commons/collections/list/AbstractTestList.java
Index: AbstractTestList.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/list/AbstractTestList.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- AbstractTestList.java 18 Feb 2004 01:20:34 - 1.6
+++ AbstractTestList.java 12 May 2004 22:20:54 - 1.7
@@ -771,12 +771,45 @@
*/
public void testListListIteratorByIndex() {
resetFull();
-for (int i = 0; i confirmed.size(); i++) {
+try {
+getList().listIterator(-1);
+} catch (IndexOutOfBoundsException ex) {}
+resetFull();
+try {
+getList().listIterator(getList().size() + 1);
+} catch (IndexOutOfBoundsException ex) {}
+resetFull();
+for (int i = 0; i = confirmed.size(); i++) {
forwardTest(getList().listIterator(i), i);
backwardTest(getList().listIterator(i), i);
}
+resetFull();
+for (int i = 0; i = confirmed.size(); i++) {
+backwardTest(getList().listIterator(i), i);
+}
}
+/**
+ * Tests remove on list iterator is correct.
+ */
+public void testListListIteratorPreviousRemove() {
+if (isRemoveSupported() == false) return;
+resetFull();
+ListIterator it = getList().listIterator();
+Object zero = it.next();
+Object one = it.next();
+Object two = it.next();
+Object two2 = it.previous();
+Object one2 = it.previous();
+assertSame(one, one2);
+assertSame(two, two2);
+assertSame(zero, getList().get(0));
+assertSame(one, getList().get(1));
+assertSame(two, getList().get(2));
+it.remove();
+assertSame(zero, getList().get(0));
+assertSame(two, getList().get(1));
+}
/**
* Traverses to the end of the given iterator.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[workflow] outstanding bugs
Hi, I have a few bugs outstanding on the Workflow component that I would quite like to see fixed - I have supplied patches. Craig is a very busy person, so I don't know if he has time to look at those. Is there anyone else who can take a look at them and apply the patches? The bug numbers are: 26902 26903 28238 Thanks. Colin Sharples IBM IT Architect Email: [EMAIL PROTECTED] Mobile: +64 21 402 085
Re: [all][collections] Solving binary incompatability
From: David Graham [EMAIL PROTECTED] If I understand correctly, incompatible changes were made to collections after 3.0 and the next planned release is 3.1. So, since you haven't released 3.1 yet, you can still go back and fix the incompatibilities. If only it was that easy :-) The incompatible change is between 2.1 and 3.0 - two released versions. The question is what to do about it. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [beanutils] remove dependency on commons-logging
On Thu, 2004-05-13 at 06:35, Alex Karasulu wrote: From: Shapira, Yoav [EMAIL PROTECTED] No I have not but I don't think an extra call is going to make or break an application. Again everyone has valid concerns about the approach and it may not be the best fit but worth considering. Are we making a mountain out of a mole hill? ;) Maybe as I'm beginning to see. The monitor or callback or observer pattern is a good solution for many problems. However it only has a very small overlap with logging. Alex's initial post, and the contents of the web page he references, gave me the impression that he was suggesting the observer pattern (or monitor) as a replacement for direct calls to commons-logging in most or all cases, which is clearly wrong as it would result in a huge explosion of interfaces and method calls. There may be *some* situations in commons where logging is used and an observer pattern would be more appropriate. Using an observer pattern does give an application the ability to respond to events, or provide context for log messages, which direct calls to commons-logging don't. However the overhead for this feature can be large, so I think it must be used sparingly. When designing the basic interfaces for an IOC framework, defining appropriate observer functionality seems like a very good idea. So I am not criticising the general concept described by Alex, but do believe strongly that logging is quite a different tool, and one cannot replace the other. I do hope this thread is now over... Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28930] - TreeList with inproved iterator() and listIterator() implementation
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=28930. 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=28930 TreeList with inproved iterator() and listIterator() implementation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 23:19 --- Patch applied thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils] remove dependency on commons-logging
On Thu, 2004-05-13 at 01:32, Inger, Matthew wrote: The only real issue i have with commons-logging is the hardcoded list of loggers that are available, and having to include the adapters for those loggers in our programs no matter what. It would be nice to have a service provider (read discovery mechanism) to figure out what log package adapters were available. In that way, each adapter implementation could be put in it's own jar, as well as having a strictly api/factory jar. Hi Matthew, I don't understand what the issue is.. Commons-logging does implement the standard service provider mechanism: put a FooLogFactory and FooLog implementation in your classpath, then in META-INF/services, include a file named org.apache.commons.logging.LogFactory, with its first line being: com.acme.FooLogFactory And there are 2 other mechanisms for dynamically configuring the logging adaptor used by commons-logging. There isn't anything hard-coded about that as far as I can see... Commons-logging does bundle adaptors for avalon LogKit and log4j. But if you don't use them, then what is the problem? And jar commons-logging-api leaves these out, if you really wish. It does include NoOpLog and SimpleLog for obvious reasons. It also includes JDK1.4 logger; I'm not sure why, but I can't see any problem with this either. I don't think I would be in favour of commons-logging distributing separate jars with the logkit and log4j adaptors in, because these jars would be *ridiculously* small. Have I missed something? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/list TreeList.java
scolebourne2004/05/12 16:24:45
Modified:collections/src/test/org/apache/commons/collections/list
TestTreeList.java
collections/src/java/org/apache/commons/collections/list
TreeList.java
Log:
Improve implementation of TreeList to perform better, fix bugs
bug 26680, 28930
Revision ChangesPath
1.2 +4 -5
jakarta-commons/collections/src/test/org/apache/commons/collections/list/TestTreeList.java
Index: TestTreeList.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/list/TestTreeList.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestTreeList.java 10 May 2004 19:59:03 - 1.1
+++ TestTreeList.java 12 May 2004 23:24:44 - 1.2
@@ -37,15 +37,14 @@
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
-//System.out.println( add; insert; get; indexOf; remove);
+//System.out.println( add; toArray; iterator; insert; get;
indexOf; remove);
//System.out.print( TreeList = );
//benchmark(new TreeList());
//System.out.print(\n ArrayList = );
//benchmark(new java.util.ArrayList());
//System.out.print(\n LinkedList = );
-//benchmark(new NodeCachingLinkedList());
-
//benchmark(new java.util.LinkedList());
+//benchmark(new NodeCachingLinkedList());
}
public static Test suite() {
@@ -83,7 +82,7 @@
System.out.print(System.currentTimeMillis() - start + ;);
start = System.currentTimeMillis();
-for (int i = 0; i 1; i++) {
+for (int i = 0; i 5; i++) {
int j = (int) (Math.random() * 11);
l.get(j);
}
1.2 +471 -299
jakarta-commons/collections/src/java/org/apache/commons/collections/list/TreeList.java
Index: TreeList.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/list/TreeList.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TreeList.java 10 May 2004 19:59:03 - 1.1
+++ TreeList.java 12 May 2004 23:24:45 - 1.2
@@ -17,6 +17,12 @@
import java.util.AbstractList;
import java.util.Collection;
+import java.util.ConcurrentModificationException;
+import java.util.Iterator;
+import java.util.ListIterator;
+import java.util.NoSuchElementException;
+
+import org.apache.commons.collections.OrderedIterator;
/**
* A codeList/code implementation that is optimised for fast insertions and
@@ -27,21 +33,21 @@
* than both an codeArrayList/code and a codeLinkedList/code where elements
* are inserted and removed repeatedly from anywhere in the list.
* p
- * The trade-off versus codeArrayList/code is memory usage.
codeTreeList/code
- * stores each entry in an object which uses up more memory. Also,
codeArrayList/code
- * is faster if additions and removals only occur at the end of the list, not in
the middle.
- * p
- * The trade-off versus codeLinkedList/code is based on how you use the list.
- * If additions and removals only occur at the start or end of the list, not in the
- * middle then codeLinkedList/code is faster.
- * p
- * The following performance statistics are indicative of this class:
+ * The following relative performance statistics are indicative of this class:
* pre
- * add insert get
- * TreeList 300 501 110
- * ArrayList 7020390 20
- * LinkedList 50 226636 279742
+ * get add insert iterate remove
+ * TreeList 35 1 2 1
+ * ArrayList 11 40 1 40
+ * LinkedList 58001 350 2 325
* /pre
+ * codeArrayList/code is a good general purpose list implementation.
+ * It is faster than codeTreeList/code for most operations except inserting
+ * and removing in the middle of the list. codeArrayList/code also uses less
+ * memory as codeTreeList/code uses one object per entry.
+ * p
+ * codeLinkedList/code is rarely a good choice of implementation.
+ * codeTreeList/code is almost always a good replacement for it, although it
+ * does use sligtly more memory.
*
* @since Commons Collections 3.1
* @version $Revision$ $Date$
@@ -50,10 +56,10 @@
* @author Stephen Colebourne
*/
public class TreeList extends AbstractList {
-//Add; insert; get
-//tree = 980;170;50;
-//array = 280;6920;0;
-//linked = 380;55480;55800;
+//add; toArray; iterator; insert; get; indexOf; remove
+//
DO NOT REPLY [Bug 26680] - [collections] Implementation of List with an AVLTree (TreeList)
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=26680. 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=26680 [collections] Implementation of List with an AVLTree (TreeList) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|Implementation of List with |[collections] Implementation |an AVLTree (TreeList) |of List with an AVLTree ||(TreeList) Target Milestone|--- |3.1 --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 23:26 --- List added and tested, thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][collections] Solving binary incompatability
--- Stephen Colebourne [EMAIL PROTECTED] wrote: From: David Graham [EMAIL PROTECTED] If I understand correctly, incompatible changes were made to collections after 3.0 and the next planned release is 3.1. So, since you haven't released 3.1 yet, you can still go back and fix the incompatibilities. If only it was that easy :-) The incompatible change is between 2.1 and 3.0 - two released versions. The question is what to do about it. You're allowed to have incompatibilities between different major version numbers. A big problem with Collections is its overuse in other commons components which is in the process of being fixed. Clients don't have to migrate to 3.0 if they don't want so I don't see a problem. If there's demand you can always release bugfixes from the 2.1 series (ie. 2.1.1). David Stephen __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][collections] Solving binary incompatability
On Thu, 2004-05-13 at 11:46, David Graham wrote: --- Stephen Colebourne [EMAIL PROTECTED] wrote: From: David Graham [EMAIL PROTECTED] If I understand correctly, incompatible changes were made to collections after 3.0 and the next planned release is 3.1. So, since you haven't released 3.1 yet, you can still go back and fix the incompatibilities. If only it was that easy :-) The incompatible change is between 2.1 and 3.0 - two released versions. The question is what to do about it. You're allowed to have incompatibilities between different major version numbers. A big problem with Collections is its overuse in other commons components which is in the process of being fixed. Clients don't have to migrate to 3.0 if they don't want so I don't see a problem. If there's demand you can always release bugfixes from the 2.1 series (ie. 2.1.1). For what it's worth, my opinion is that things are ok as they are. It is valid to introduce binary incompatibilities for major releases. Ok, these ones weren't intentional, and could have been avoided. But projects that use commons libs should have a plan for migrating across major lib releases. Ok, it might slow the adoption of commons-collections 3.0, as projects wait for new releases of all the other commons libs they depend on so that none of the other libs require collections 2.1. But they'll get there eventually. If you really feel like releasing a 4.0, that would be a solution. But I'm not sure projects will be happy leaping from 2.1 to 4.0, so this may not speed up adoption of the new version anyway. I certainly don't think a 3.1 release which is incompatible with 3.0 is a good idea! Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28938] New: - [PATCH] : [primitives] IntHashMap -- A hash map that uses primitive interger for the key rather than objects.
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=28938. 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=28938 [PATCH] : [primitives] IntHashMap -- A hash map that uses primitive interger for the key rather than objects. Summary: [PATCH] : [primitives] IntHashMap -- A hash map that uses primitive interger for the key rather than objects. Product: Commons Version: Nightly Builds Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Collections AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A hash map that uses primitive interger for the key rather than objects. I initially wrote this for Axion. But I think this is a good candidate for commons collection-primitives. I searched around to get similar implementation, but I did not found a complete implementation for the same. Any improvement suggestion will be greatly appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28938] - [PATCH] : [primitives] IntHashMap -- A hash map that uses primitive interger for the key rather than objects.
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=28938. 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=28938 [PATCH] : [primitives] IntHashMap -- A hash map that uses primitive interger for the key rather than objects. --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 23:59 --- Created an attachment (id=11526) IntHashMap.java (new file) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods PostMethod.java EntityEnclosingMethod.java StringRequestEntity.java RequestEntity.java InputStreamRequestEntity.java ByteArrayRequestEntity.java
mbecke 2004/05/12 19:26:09
Modified:httpclient/src/java/org/apache/commons/httpclient/methods
PostMethod.java EntityEnclosingMethod.java
StringRequestEntity.java RequestEntity.java
InputStreamRequestEntity.java
ByteArrayRequestEntity.java
Log:
Added @since 3.0 tags.
Revision ChangesPath
1.56 +9 -6
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/PostMethod.java
Index: PostMethod.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/PostMethod.java,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- PostMethod.java 12 May 2004 03:07:03 - 1.55
+++ PostMethod.java 13 May 2004 02:26:08 - 1.56
@@ -153,8 +153,11 @@
super.clearRequestBody();
}
-/* (non-Javadoc)
- * @see
org.apache.commons.httpclient.methods.EntityEnclosingMethod#generateRequestEntity()
+/**
+ * Generates a request entity from the post parameters, if present. Calls
+ * [EMAIL PROTECTED] EntityEnclosingMethod#generateRequestBody()} if parameters
have not been set.
+ *
+ * @since 3.0
*/
protected RequestEntity generateRequestEntity() {
if (!this.params.isEmpty()) {
1.36 +15 -6
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java
Index: EntityEnclosingMethod.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- EntityEnclosingMethod.java12 May 2004 20:43:53 - 1.35
+++ EntityEnclosingMethod.java13 May 2004 02:26:08 - 1.36
@@ -238,8 +238,13 @@
this.requestContentLength = length;
}
-/* (non-Javadoc)
- * @see org.apache.commons.httpclient.HttpMethodBase#getRequestCharSet()
+/**
+ * Returns the request's charset. The charset is parsed from the request
entity's
+ * content type, unless the content type header has been set manually.
+ *
+ * @see RequestEntity#getContentType()
+ *
+ * @since 3.0
*/
public String getRequestCharSet() {
if (getRequestHeader(Content-Type) == null) {
@@ -506,6 +511,8 @@
/**
* @return Returns the requestEntity.
+ *
+ * @since 3.0
*/
public RequestEntity getRequestEntity() {
return generateRequestEntity();
@@ -513,6 +520,8 @@
/**
* @param requestEntity The requestEntity to set.
+ *
+ * @since 3.0
*/
public void setRequestEntity(RequestEntity requestEntity) {
clearRequestBody();
1.2 +5 -3
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/StringRequestEntity.java
Index: StringRequestEntity.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/StringRequestEntity.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StringRequestEntity.java 12 May 2004 03:07:03 - 1.1
+++ StringRequestEntity.java 13 May 2004 02:26:08 - 1.2
@@ -40,6 +40,8 @@
/**
* A RequestEntity that contains a String.
+ *
+ * @since 3.0
*/
public class StringRequestEntity implements RequestEntity {
1.3 +4 -3
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/RequestEntity.java
Index: RequestEntity.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/RequestEntity.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- RequestEntity.java12 May 2004 03:07:03 - 1.2
+++ RequestEntity.java13 May 2004 02:26:08 - 1.3
@@ -33,6 +33,7 @@
import java.io.OutputStream;
/**
+ * @since 3.0
*/
public interface RequestEntity {
1.3 +5 -3
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/InputStreamRequestEntity.java
Index: InputStreamRequestEntity.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/InputStreamRequestEntity.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
---
HttpClient initialization, when/where?
Hi, I will be writing a gateway which will invoke URLs in behalf of several threads and they will return the content. Each thread needs to invoke different URLs with different context (cookies, etc). It looks like right way of doing this is to instantiate the HttpClient once with MultiThreadedHttpConnectionManager and each thread will use httpClient.executeMethod on this HttpClient instance. Or the other alternative is to instantiate one object for each thread, and keep calling executeMethods on them. However, since you can set the state of the HttpClient, I was wondering if I can use the HttpClient for iterative http invocations with different contexts? I mean, is there an in-memory state other than the HttpState that is preserved between these invocations? Would it be enough to create an HttpState and GetMethod for each call, and set it before calling executeMethod? Shortly, what is the optimum mechanism for this functionality? TIA... __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient initialization, when/where?
Hello, you need one HttpState for each thread, since the cookies are stored there. Creating a new state for each request will not work, unless the threads manage the cookies themselves. The HttpClient is associated with a connection pool. If you require independently configured connection pools for each thread, you have to create multiple HttpClient objects. Otherwise, one HttpClient with MultiThreadedHCM is ok. hope that helps, Roland Cabbar Duzayak [EMAIL PROTECTED] 12.05.2004 09:32 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:HttpClient initialization, when/where? Hi, I will be writing a gateway which will invoke URLs in behalf of several threads and they will return the content. Each thread needs to invoke different URLs with different context (cookies, etc). It looks like right way of doing this is to instantiate the HttpClient once with MultiThreadedHttpConnectionManager and each thread will use httpClient.executeMethod on this HttpClient instance. Or the other alternative is to instantiate one object for each thread, and keep calling executeMethods on them. However, since you can set the state of the HttpClient, I was wondering if I can use the HttpClient for iterative http invocations with different contexts? I mean, is there an in-memory state other than the HttpState that is preserved between these invocations? Would it be enough to create an HttpState and GetMethod for each call, and set it before calling executeMethod? Shortly, what is the optimum mechanism for this functionality? TIA... __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HttpClient initialization, when/where?
Duzayak (I hope I got your name right),
You can create an instance of the HttpState class per thread and pass the respective
HttpState object along with the HTTP method to be executed:
// shared by all the worker threads
HttpConnectionManager connman = new MultiThreadedHttpConnectionManager();
HttpClient agent = new HttpClient(connman);
// one per thread
HttpState httpstate = new HttpState();
// in the worker thread
GetMethod httpget = new GetMethod(http://www.whatever.com;);
try {
agent.executeMethod(null, httpget, httpstate);
// do something useful with the result
} finally {
httpget.releaseConnection();
}
For more details see
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/HttpClient.html#executeMethod(org.apache.commons.httpclient.HostConfiguration,%20org.apache.commons.httpclient.HttpMethod,%20org.apache.commons.httpclient.HttpState)
HTH
Oleg
-Original Message-
From: Cabbar Duzayak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 9:33
To: [EMAIL PROTECTED]
Subject: HttpClient initialization, when/where?
Hi,
I will be writing a gateway which will invoke URLs in
behalf of several threads and they will return the
content. Each thread needs to invoke different URLs
with different context (cookies, etc).
It looks like right way of doing this is to
instantiate the HttpClient once with
MultiThreadedHttpConnectionManager and each thread
will use httpClient.executeMethod on this HttpClient
instance. Or the other alternative is to instantiate
one object for each thread, and keep calling
executeMethods on them.
However, since you can set the state of the
HttpClient, I was wondering if I can use the
HttpClient for iterative http invocations with
different contexts? I mean, is there an in-memory
state other than the HttpState that is preserved
between these invocations? Would it be enough to
create an HttpState and GetMethod for each call, and
set it before calling executeMethod?
Shortly, what is the optimum mechanism for this
functionality?
TIA...
__
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861
-
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]
DO NOT REPLY [Bug 28728] - HttpUrl does not accept unescaped passwords
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=28728. 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=28728 HttpUrl does not accept unescaped passwords [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-05-12 09:04 --- The same applies to HttpsURL. The relevant piece of code is duplicated in these two classes, but it was only fixed in HttpURL. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient initialization, when/where?
Can you please elaborate a bit how this connection pool and multithreaded HCM work? Cause, given that httpclient will be executed within my thread, why do we need a multithreaded HCM? Also, connection pool is used for sharing connections between threads? How exactly does it work, what does it improve? Thanks a lot for the information! --- Roland Weber [EMAIL PROTECTED] wrote: Hello, you need one HttpState for each thread, since the cookies are stored there. Creating a new state for each request will not work, unless the threads manage the cookies themselves. The HttpClient is associated with a connection pool. If you require independently configured connection pools for each thread, you have to create multiple HttpClient objects. Otherwise, one HttpClient with MultiThreadedHCM is ok. hope that helps, Roland Cabbar Duzayak [EMAIL PROTECTED] 12.05.2004 09:32 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:HttpClient initialization, when/where? Hi, I will be writing a gateway which will invoke URLs in behalf of several threads and they will return the content. Each thread needs to invoke different URLs with different context (cookies, etc). It looks like right way of doing this is to instantiate the HttpClient once with MultiThreadedHttpConnectionManager and each thread will use httpClient.executeMethod on this HttpClient instance. Or the other alternative is to instantiate one object for each thread, and keep calling executeMethods on them. However, since you can set the state of the HttpClient, I was wondering if I can use the HttpClient for iterative http invocations with different contexts? I mean, is there an in-memory state other than the HttpState that is preserved between these invocations? Would it be enough to create an HttpState and GetMethod for each call, and set it before calling executeMethod? Shortly, what is the optimum mechanism for this functionality? TIA... __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient initialization, when/where?
Hi Duzayak (?), the MultiThreadedHCM is called so because it allows for multiple threads to use the same HttpClient. It has to be used if the application is multithreaded. The connection pool limits the number of simultaneous connections, to a particular host and in general. It keeps resource usage in check. Also, if there are many requests to the same host, open connections may be reused, which avoids the overhead of establishing a new connection for each request. If you want to know how it works, feel free to look at the source code. It's open :-) cheers, Roland Cabbar Duzayak [EMAIL PROTECTED] 12.05.2004 12:26 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: HttpClient initialization, when/where? Can you please elaborate a bit how this connection pool and multithreaded HCM work? Cause, given that httpclient will be executed within my thread, why do we need a multithreaded HCM? Also, connection pool is used for sharing connections between threads? How exactly does it work, what does it improve? Thanks a lot for the information!
Cookie Bug?
Hi, I am trying to run the following code for www.google.com: Cookie cookie = initialState.getCookies()[0]; CookieSpec cs = CookiePolicy.getDefaultSpec(); Header h = cs.formatCookieHeader(cookie); Cookie[] cookie2 = cs.parse(cookie.getDomain(), 80, cookie.getPath(), cookie.getSecure(), h); And, it is throwing an exception as: org.apache.commons.httpclient.cookie.MalformedCookieException: Cookie name may not start with $ It looks like h.getValue returns name with $ sign (which was indeed created by the cookiespec), but the same cookiespec can not read this back, because it has a $ sign??? BTW, h.getValue() is: $Version=0; PREF=ID=069e080d47cd4332:TM=1084362072:LM=1084362072:S=0u9G4CTYGPvhxJzn; $Domain=.google.com; $Path=/ Looks like, cookieSpec.parse is expecting the same string without $ signs, in fact, when I remove dollar signs manually, the code works fine. Did I hit the jackpot and found a bug;) Thanks... __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient initialization, when/where?
Well, This information is more than I need;) Appreciate your help. --- Roland Weber [EMAIL PROTECTED] wrote: Hi Duzayak (?), the MultiThreadedHCM is called so because it allows for multiple threads to use the same HttpClient. It has to be used if the application is multithreaded. The connection pool limits the number of simultaneous connections, to a particular host and in general. It keeps resource usage in check. Also, if there are many requests to the same host, open connections may be reused, which avoids the overhead of establishing a new connection for each request. If you want to know how it works, feel free to look at the source code. It's open :-) cheers, Roland Cabbar Duzayak [EMAIL PROTECTED] 12.05.2004 12:26 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: HttpClient initialization, when/where? Can you please elaborate a bit how this connection pool and multithreaded HCM work? Cause, given that httpclient will be executed within my thread, why do we need a multithreaded HCM? Also, connection pool is used for sharing connections between threads? How exactly does it work, what does it improve? Thanks a lot for the information! __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cookie Bug?
Duzayak, 'Set-Cookie' (request) header is not the same thing as the 'Cookie' (response) header. CookieSpec#formatCookieHeader() method produces a 'Set-Cookie' (request) header, whereas CookieSpec#parse() method is intended to parse 'Cookie' (response) headers I hope this clarifies things a bit Oleg -Original Message- From: Cabbar Duzayak [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 13:47 To: Commons HttpClient Project Subject: Cookie Bug? Hi, I am trying to run the following code for www.google.com: Cookie cookie = initialState.getCookies()[0]; CookieSpec cs = CookiePolicy.getDefaultSpec(); Header h = cs.formatCookieHeader(cookie); Cookie[] cookie2 = cs.parse(cookie.getDomain(), 80, cookie.getPath(), cookie.getSecure(), h); And, it is throwing an exception as: org.apache.commons.httpclient.cookie.MalformedCookieException: Cookie name may not start with $ It looks like h.getValue returns name with $ sign (which was indeed created by the cookiespec), but the same cookiespec can not read this back, because it has a $ sign??? BTW, h.getValue() is: $Version=0; PREF=ID=069e080d47cd4332:TM=1084362072:LM=1084362072:S=0u9G4CTYGPvhxJzn; $Domain=.google.com; $Path=/ Looks like, cookieSpec.parse is expecting the same string without $ signs, in fact, when I remove dollar signs manually, the code works fine. Did I hit the jackpot and found a bug;) Thanks... __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - 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]
'Socket closed' exception using
Hello, We are trying to use HTTPClient.execute(PostMethod) for sending SOAP requests to Connotate's Web Mining Server (WMS). The requests are sent every 1 minute, and in most cases everything works fine. However, every so often (sometimes way too often!) we are getting the 'Socket closed' exception. The socket timeout was initially set to 10 seconds (1 millis), but even after I set it to 120 seconds (12 millis), we are still seeing it happening quite often. I tried to use both the getResponseBodyAsString() and getResponseBodyAsStream() to retrieve the response, but it does not change anything. The application is running on Windows 2000 (SP4). I tried both the HTTPClient v2.0 (final) and the latest night build (as of yesterday), but the results are the same. We are using HTTP 1.0 (PostMethod.setHttp11(false)), with the application running on the same computer as the WMS. I will appreciate any suggestions about what can be done here. Thank you, Sofya Stack trace: 08:54:37 DEBUG [Thread-19] - enter PostMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter EntityEnclosingMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter getContentCharSet( Header contentheader ) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parse(String) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - Using buffered request body 08:54:37 DEBUG [Thread-19] - enter HttpConnection.getRequestOutputStream() 08:54:37 DEBUG [Thread-19] - Request body sent 08:54:37 DEBUG [Thread-19] - enter HttpConnection.flushRequestOutputStream() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.releaseConnection() 08:54:37 ERROR [Thread-19] - I/O exception executing the get data request 'Execute'. java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H ttpConnection.java:1368) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht tpConnection.java:799) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase .java:2324) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa se.java:2657) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 75) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5 29) at pbf.travinfo.dcol.CHPDI.AgentLibrary.getSOAPResponse(AgentLibrary.java:6 48) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'Socket closed' exception using
How are you setting your headers? That is sometimes the issue on socket closings. At 10:25 AM 5/12/2004, Preygel, Sofya wrote: Hello, We are trying to use HTTPClient.execute(PostMethod) for sending SOAP requests to Connotate's Web Mining Server (WMS). The requests are sent every 1 minute, and in most cases everything works fine. However, every so often (sometimes way too often!) we are getting the 'Socket closed' exception. The socket timeout was initially set to 10 seconds (1 millis), but even after I set it to 120 seconds (12 millis), we are still seeing it happening quite often. I tried to use both the getResponseBodyAsString() and getResponseBodyAsStream() to retrieve the response, but it does not change anything. The application is running on Windows 2000 (SP4). I tried both the HTTPClient v2.0 (final) and the latest night build (as of yesterday), but the results are the same. We are using HTTP 1.0 (PostMethod.setHttp11(false)), with the application running on the same computer as the WMS. I will appreciate any suggestions about what can be done here. Thank you, Sofya Stack trace: 08:54:37 DEBUG [Thread-19] - enter PostMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter EntityEnclosingMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter getContentCharSet( Header contentheader ) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parse(String) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - Using buffered request body 08:54:37 DEBUG [Thread-19] - enter HttpConnection.getRequestOutputStream() 08:54:37 DEBUG [Thread-19] - Request body sent 08:54:37 DEBUG [Thread-19] - enter HttpConnection.flushRequestOutputStream() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.releaseConnection() 08:54:37 ERROR [Thread-19] - I/O exception executing the get data request 'Execute'. java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H ttpConnection.java:1368) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht tpConnection.java:799) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase .java:2324) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa se.java:2657) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 75) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5 29) at pbf.travinfo.dcol.CHPDI.AgentLibrary.getSOAPResponse(AgentLibrary.java:6 48) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 'Socket closed' exception using
Here it is: PostMethod post = new PostMethod(m_URL); post.setHttp11(false); post.setRequestHeader(Content-Length, Integer.toString(payload.toString().length())); post.setRequestHeader(Content-type, text/xml;charset=utf-8); post.setRequestHeader(Content-type, text/xml; charset=ISO-8859-1); post.setRequestHeader(SOAPAction, http://tempuri.org/action/Agent.; + action); post.setRequestContentLength(payload.toString().length()); post.setRequestBody(payload.toString()); I tried to also use keep-alive connection option (even though I know it makes little sense for HTTP 1.0), but to no avail. Thanks, Sofya -Original Message- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 1:29 PM To: Commons HttpClient Project Cc: [EMAIL PROTECTED]; Preygel, Sofya Subject: Re: 'Socket closed' exception using How are you setting your headers? That is sometimes the issue on socket closings. At 10:25 AM 5/12/2004, Preygel, Sofya wrote: Hello, We are trying to use HTTPClient.execute(PostMethod) for sending SOAP requests to Connotate's Web Mining Server (WMS). The requests are sent every 1 minute, and in most cases everything works fine. However, every so often (sometimes way too often!) we are getting the 'Socket closed' exception. The socket timeout was initially set to 10 seconds (1 millis), but even after I set it to 120 seconds (12 millis), we are still seeing it happening quite often. I tried to use both the getResponseBodyAsString() and getResponseBodyAsStream() to retrieve the response, but it does not change anything. The application is running on Windows 2000 (SP4). I tried both the HTTPClient v2.0 (final) and the latest night build (as of yesterday), but the results are the same. We are using HTTP 1.0 (PostMethod.setHttp11(false)), with the application running on the same computer as the WMS. I will appreciate any suggestions about what can be done here. Thank you, Sofya Stack trace: 08:54:37 DEBUG [Thread-19] - enter PostMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter EntityEnclosingMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter getContentCharSet( Header contentheader ) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parse(String) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - Using buffered request body 08:54:37 DEBUG [Thread-19] - enter HttpConnection.getRequestOutputStream() 08:54:37 DEBUG [Thread-19] - Request body sent 08:54:37 DEBUG [Thread-19] - enter HttpConnection.flushRequestOutputStream() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.releaseConnection() 08:54:37 ERROR [Thread-19] - I/O exception executing the get data request 'Execute'. java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H ttpConnection.java:1368) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht
RE: 'Socket closed' exception using
I meant how do you set the response headers? That is probably where the problem is. At 10:32 AM 5/12/2004, Preygel, Sofya wrote: Here it is: PostMethod post = new PostMethod(m_URL); post.setHttp11(false); post.setRequestHeader(Content-Length, Integer.toString(payload.toString().length())); post.setRequestHeader(Content-type, text/xml;charset=utf-8); post.setRequestHeader(Content-type, text/xml; charset=ISO-8859-1); post.setRequestHeader(SOAPAction, http://tempuri.org/action/Agent.; + action); post.setRequestContentLength(payload.toString().length()); post.setRequestBody(payload.toString()); I tried to also use keep-alive connection option (even though I know it makes little sense for HTTP 1.0), but to no avail. Thanks, Sofya -Original Message- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 1:29 PM To: Commons HttpClient Project Cc: [EMAIL PROTECTED]; Preygel, Sofya Subject: Re: 'Socket closed' exception using How are you setting your headers? That is sometimes the issue on socket closings. At 10:25 AM 5/12/2004, Preygel, Sofya wrote: Hello, We are trying to use HTTPClient.execute(PostMethod) for sending SOAP requests to Connotate's Web Mining Server (WMS). The requests are sent every 1 minute, and in most cases everything works fine. However, every so often (sometimes way too often!) we are getting the 'Socket closed' exception. The socket timeout was initially set to 10 seconds (1 millis), but even after I set it to 120 seconds (12 millis), we are still seeing it happening quite often. I tried to use both the getResponseBodyAsString() and getResponseBodyAsStream() to retrieve the response, but it does not change anything. The application is running on Windows 2000 (SP4). I tried both the HTTPClient v2.0 (final) and the latest night build (as of yesterday), but the results are the same. We are using HTTP 1.0 (PostMethod.setHttp11(false)), with the application running on the same computer as the WMS. I will appreciate any suggestions about what can be done here. Thank you, Sofya Stack trace: 08:54:37 DEBUG [Thread-19] - enter PostMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter EntityEnclosingMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter getContentCharSet( Header contentheader ) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parse(String) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - Using buffered request body 08:54:37 DEBUG [Thread-19] - enter HttpConnection.getRequestOutputStream() 08:54:37 DEBUG [Thread-19] - Request body sent 08:54:37 DEBUG [Thread-19] - enter HttpConnection.flushRequestOutputStream() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.releaseConnection() 08:54:37 ERROR [Thread-19] - I/O exception executing the get data request 'Execute'. java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H ttpConnection.java:1368) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht tpConnection.java:799)
Re: 'Socket closed' exception using
Hi Sofya, There are a couple of possibilities, but it sounds like you are experiencing some connection management issues. If you could, please send some sample code showing how you are using HttpClient, as well as a wire log http://jakarta.apache.org/commons/httpclient/logging.html (just the headers please). Mike Preygel, Sofya wrote: Hello, We are trying to use HTTPClient.execute(PostMethod) for sending SOAP requests to Connotate's Web Mining Server (WMS). The requests are sent every 1 minute, and in most cases everything works fine. However, every so often (sometimes way too often!) we are getting the 'Socket closed' exception. The socket timeout was initially set to 10 seconds (1 millis), but even after I set it to 120 seconds (12 millis), we are still seeing it happening quite often. I tried to use both the getResponseBodyAsString() and getResponseBodyAsStream() to retrieve the response, but it does not change anything. The application is running on Windows 2000 (SP4). I tried both the HTTPClient v2.0 (final) and the latest night build (as of yesterday), but the results are the same. We are using HTTP 1.0 (PostMethod.setHttp11(false)), with the application running on the same computer as the WMS. I will appreciate any suggestions about what can be done here. Thank you, Sofya Stack trace: 08:54:37 DEBUG [Thread-19] - enter PostMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter EntityEnclosingMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter getContentCharSet( Header contentheader ) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parse(String) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - Using buffered request body 08:54:37 DEBUG [Thread-19] - enter HttpConnection.getRequestOutputStream() 08:54:37 DEBUG [Thread-19] - Request body sent 08:54:37 DEBUG [Thread-19] - enter HttpConnection.flushRequestOutputStream() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.releaseConnection() 08:54:37 ERROR [Thread-19] - I/O exception executing the get data request 'Execute'. java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H ttpConnection.java:1368) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht tpConnection.java:799) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase .java:2324) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa se.java:2657) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 75) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5 29) at pbf.travinfo.dcol.CHPDI.AgentLibrary.getSOAPResponse(AgentLibrary.java:6 48) - 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]
@since tags (3.0alpha1 blocker)
We are almost there. Before we can cut the release, though, there's one tedious and laborious task to be taken care of. To help people identify API changes, the new classes and methods must be properly marked with the @since 3.0 tag. We (I in the first place) have been too undisciplined to put @since tags as we hacked away. The pay time is now. I'll deal with the problem in the coming days. A helping hand would be appreciated, though. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 'Socket closed' exception using
Hi Mike,
Here is the code:
PostMethod post = new PostMethod(m_URL);
post.setHttp11(false);
post.setRequestHeader(Content-Length,
Integer.toString(payload.toString().length()));
post.setRequestHeader(Content-type, text/xml;charset=utf-8);
post.setRequestHeader(Content-type, text/xml;
charset=ISO-8859-1);
post.setRequestHeader(SOAPAction,
http://tempuri.org/action/Agent.; + action);
post.setRequestContentLength(payload.toString().length());
post.setRequestBody(payload.toString());
// Log the request (debug mode only)
try
{
m_logger.debug(*** Request: +
post.getRequestBodyAsString());
}
catch (Exception e)
{
}
// Create an instance of HttpClient
HttpClient httpclient = new HttpClient();
// Set the connection and socket timeouts
int requestTimeout = m_socketTimeoutInMillis;
httpclient.setConnectionTimeout(m_connTimeoutInMillis);
httpclient.setTimeout(requestTimeout);
m_logger.info (Setting HTTP timeouts: connection to +
m_connTimeoutInMillis +
millis., socket to + requestTimeout +
millis.);
// Execute the request
int statusCode = -1;
for (int attempt = 1; statusCode == -1 attempt =
m_executeRetries; attempt++)
{
try
{
statusCode = httpclient.executeMethod(post);
}
catch (HttpRecoverableException e)
{
m_logger.debug(Recoverable exception occurred while
executing the +
get data request: + e.getMessage() +
(attempt +
attempt + out of + m_executeRetries +
).);
if
(e.getMessage().startsWith(java.net.SocketTimeoutException: Read timed
out))
{
// Increase the timeout for this request
requestTimeout = requestTimeout * 2;
m_logger.debug(Increasing the request timeout to +
requestTimeout +
millis.);
httpclient.setTimeout(requestTimeout);
}
}
catch (IOException e)
{
m_logger.error(I/O error sending the get data request: +
action + '. , e);
post.releaseConnection();
PBFException ex = new PBFException(I/O error sending the
get data request.);
throw ex;
}
}
// Check if the request succeeded or we just ran out of retry
attempts
if (statusCode == -1)
{
// Request failed. Log the exception, release the connection
and
// throw an exception
m_logger.error(Get data request failed. Unable to recover from
the HTTP +
recoverable exception after +
m_executeRetries + retries.);
post.releaseConnection();
PBFException ex =
new PBFException(Unable to recover from the HTTP
recoverable exception after +
m_executeRetries + retries.);
throw ex;
}
// Request succeeded, get the response )
StringBuffer retval = new StringBuffer();
try
{
InputStream is = post.getResponseBodyAsStream();
if (is != null)
{
ByteArrayOutputStream os = new ByteArrayOutputStream();
byte[] buffer = new byte[8192];
int len;
while ((len = is.read(buffer)) 0)
{
os.write(buffer, 0, len);
}
os.close();
String response = os.toString();
retval = new StringBuffer(response);
// Log the response (debug mode only)
if (m_logger.isDebugEnabled() m_logSOAPCommsFlag)
{
m_logger.debug(*** Response: + decode(response));
}
}
else
{
// Shall see if this ever happens... if yes, will throw an
exception
m_logger.error(No data received (getResponseBodyAsStream()
is null).);
}
}
catch (IOException e)
{
m_logger.error(I/O error receiving the get data response: +
action + '. , e);
PBFException ex = new PBFException(I/O error receiving the get
data response.);
throw ex;
}
finally
{
// Release the current connection to the connection pool
post.releaseConnection();
}
Here are the request headers:
18:04:53 DEBUG [Thread-17] - POST /WS/AgentLibrary.asp
HTTP/1.0[\r][\n]
18:04:53 DEBUG [Thread-17] - Content-Length: 868[\r][\n]
18:04:53 DEBUG [Thread-17] - Content-type: text/xml;
charset=ISO-8859-1[\r][\n]
18:04:53 DEBUG [Thread-17] - SOAPAction:
http://tempuri.org/action/Agent.Execute[\r][\n];
18:04:53 DEBUG [Thread-17] - User-Agent: Jakarta
Commons-HttpClient/2.0final[\r][\n]
18:04:53 DEBUG [Thread-17] - Host: dcgate1[\r][\n]
18:04:53 DEBUG [Thread-17] - [\r][\n]
And this are the
RE: 'Socket closed' exception using
Thank you for your response, Oleg.
1. The application development started when the server application supported only
HTTP1.0.
2. The application is multi-threaded, but all HTTP requests are issued from a single
thread. It is not the main thread, though, which I hope makes no difference as this is
where all the HTTPClient objects are created.
3. I have contacted Connotate tech support and hope they will be able to answer some
of the guestions about what is happening on on the server side.
What I cannot understand, though, is this fragment of the log file:
08:54:37 DEBUG [Thread-19] - Request body sent
08:54:37 DEBUG [Thread-19] - enter .flushRequestOutputStream()
08:54:37 DEBUG [Thread-19] - enter HttpConnection.close()
08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams()
08:54:37 DEBUG [Thread-19] - enter HttpConnection.close()
08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams()
08:54:37 DEBUG [Thread-19] - enter HttpConnection.releaseConnection()
Does not this prove that the socket is closed from the application side, i.e from
inside the HTTPClient? Or it is possible for the HttpConnection.close() to be called
when a closed socket is detected (to clean up the resources, etc.)?
Thank you!
Sofya
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wed 5/12/2004 6:41 PM
To: Commons HttpClient Project
Cc:
Subject: RE: 'Socket closed' exception using
Sofya,
(1) What's the reason for using HTTP/1.0 if the target server is clearly
capable of doing HTTP/1.1?
18:04:53 DEBUG [Thread-17] - POST /WS/AgentLibrary.asp
HTTP/1.0[\r][\n]
(2) Are you executing HTTP requests using multiple threads by any
chance?
(3) 'Socket closed' IO exception is usually caused when the target
server drops connection on the unsuspecting HttpClient while it is still
in the process of sending request or reading response. The problem you
have been experiencing in fact _may_ well be on the server side. If you
have access to the target server you may want to examine the server
logs.
In your case the connection to the server gets dropped as soon as
HttpClient is done sending the request body (to be more precise while
flushing the output buffer). That makes me believe that the server is
the most likely culprit, not HttpClient
Oleg
On Thu, 2004-05-13 at 00:09, Preygel, Sofya wrote:
Hi Mike,
Here is the code:
PostMethod post = new PostMethod(m_URL);
post.setHttp11(false);
post.setRequestHeader(Content-Length,
Integer.toString(payload.toString().length()));
post.setRequestHeader(Content-type, text/xml;charset=utf-8);
post.setRequestHeader(Content-type, text/xml;
charset=ISO-8859-1);
post.setRequestHeader(SOAPAction,
http://tempuri.org/action/Agent.; + action);
post.setRequestContentLength(payload.toString().length());
post.setRequestBody(payload.toString());
// Log the request (debug mode only)
try
{
m_logger.debug(*** Request: +
post.getRequestBodyAsString());
}
catch (Exception e)
{
}
// Create an instance of HttpClient
HttpClient httpclient = new HttpClient();
// Set the connection and socket timeouts
int requestTimeout = m_socketTimeoutInMillis;
httpclient.setConnectionTimeout(m_connTimeoutInMillis);
httpclient.setTimeout(requestTimeout);
m_logger.info (Setting HTTP timeouts: connection to +
m_connTimeoutInMillis +
millis., socket to + requestTimeout +
millis.);
// Execute the request
int statusCode = -1;
for (int attempt = 1; statusCode == -1 attempt =
m_executeRetries; attempt++)
{
try
{
statusCode = httpclient.executeMethod(post);
}
catch (HttpRecoverableException e)
{
m_logger.debug(Recoverable exception occurred while
executing the +
get data request: + e.getMessage() +
(attempt +
attempt + out of + m_executeRetries +
).);
if
Re: 'Socket closed' exception using
Hi Sofya, I agree with Oleg, it seems that the server is closing the connection in the middle of a request. Does not this prove that the socket is closed from the application side, i.e from inside the HTTPClient? Or it is possible for the HttpConnection.close() to be called when a closed socket is detected (to clean up the resources, etc.)? Yes, HttpClient closes the connection when it encounters the Exception while writing the request. see http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/ httpclient/HttpMethodBase.html#2657 Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @since tags (3.0alpha1 blocker)
Docs updated. Mike On May 12, 2004, at 5:53 PM, Oleg Kalnichevski wrote: We are almost there. Before we can cut the release, though, there's one tedious and laborious task to be taken care of. To help people identify API changes, the new classes and methods must be properly marked with the @since 3.0 tag. We (I in the first place) have been too undisciplined to put @since tags as we hacked away. The pay time is now. I'll deal with the problem in the coming days. A helping hand would be appreciated, though. Oleg - 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]
Persistent HTTPS connections
Using HttpClient 2.0
JDK 1.4.2_04 on Fedora
Is there anything special that I have to do to make use of persistent
HTTP(S) connections with HttpClient other than using
MultiThreadedHttpConnectionManager ?
Basically, what I am doing is the following ( more explanation after the
snippet of the source code ):
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
connectionManager.setConnectionStaleCheckingEnabled( true );
connectionManager.setMaxConnectionsPerHost( 10 );
connectionManager.setMaxTotalConnections( 100 );
this.httpClient = new HttpClient( connectionManager );
this.httpClient.setConnectionTimeout( 3 );
this.httpClient.setTimeout( 3 );
and then within a thread, the thread does this:
String content;
HttpMethod method;
try {
method = new PostMethod( connectionURL );
method.setDoAuthentication( true );
method.setRequestHeader( Content-Type, contentType + ;
charset= + this.outboundEncoding);
if( method instanceof PostMethod ) {
PostMethod postMethod = (PostMethod) method;
postMethod.setRequestBody( content );
}
int responseCode = this.httpClient.executeMethod( method );
String response = method.getResponseBodyAsString();
.
}
catch( Exception ex ) {}
finally {
if( method != null ) method.releaseConnection();
}
What I am doing, then, from a JUnit test class, is:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Send another HTTP POST to the same URL.
What I am seeing with ethereal is that, after 30 seconds of no activity
( no TCP ACKs whatever on the socket ), the web server sends a a TLS alert.
So what actually happens is this:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Web server sends a TLS alert after 30 seconds of inactivity. Web
server sends a TCP FIN, Java sends a TCP ACK _only_ .
4) Wake up from sleep at the 40 second mark, send another HTTP POST to
the same URL.
5) Receive a TLS alert instead of a HTTP response. The TLS alert
according to JSSE's debug mode is:
main, RECV TLSv1 ALERT: warning, close_notify
main, called closeInternal(false)
main, SEND TLSv1 ALERT: warning, description = close_notify
6) HttpClient throws an HttpRecoverableException, shown below:
org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in parsing
the status line from the response: unable to find line starting with HTTP
Question is, was I correct in initially assuming that
MultiThreadedHttpConnectionManager should have handled this case ?
e.g... .detected that the exception, and retried the HTTP POST by
creating a new HTTPS socket ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
