Re: [modeler] Introspection only for primitives?
On Mon, 21 Jul 2003, Davanum Srinivas wrote: Costin, Right now modeler just allows parameters that are listed in the supportedType method when we use introspection. #1 - How difficult/easy is it to allow other data types? (Why is this list of items limited?) It's not difficult to add more data types. We added mostly commont types - I think we should cover at least the types in open mbeans part of the spec. We could also add a generic mechanism to allow pluggable types ( i.e. to add more types to the list of supportedTypes ). #2 - How about other beans as parameters? (if you look at test\org\apache\commons\modeler\demo\mbeans-descriptors.xml, StandardServer has addService, removeService etc that take in a service as parameter) Sure - if it doesn't complicates things too much. BTW, one of the reason we have the supportedTypes is to avoid introspection extracting too much stuff. Costin Thanks, dims = Davanum Srinivas - http://webservices.apache.org/~dims/ __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [modeler] Introspection only for primitives?
On Mon, 21 Jul 2003, Costin Manolache wrote: Date: Mon, 21 Jul 2003 22:28:45 -0700 (PDT) From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Davanum Srinivas [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [modeler] Introspection only for primitives? On Mon, 21 Jul 2003, Davanum Srinivas wrote: Costin, Right now modeler just allows parameters that are listed in the supportedType method when we use introspection. #1 - How difficult/easy is it to allow other data types? (Why is this list of items limited?) It's not difficult to add more data types. We added mostly commont types - I think we should cover at least the types in open mbeans part of the spec. We could also add a generic mechanism to allow pluggable types ( i.e. to add more types to the list of supportedTypes ). #2 - How about other beans as parameters? (if you look at test\org\apache\commons\modeler\demo\mbeans-descriptors.xml, StandardServer has addService, removeService etc that take in a service as parameter) Sure - if it doesn't complicates things too much. BTW, one of the reason we have the supportedTypes is to avoid introspection extracting too much stuff. If you're using tools that rely on standard JavaBeans introspection, the classic mechanism to hide things you don't want seen is BeanInfo. Of course, the ultimate end of this whole line of I have to parse my own configuration files is that you are going to basically re-invent what Digester already does, and does well, but do it in a context that is local to commons-modeler. Tell me again why depending on something that already works is such a bad thing :-). Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-62) FMT's BundleTag should load resource bundle from JellyContext's class loader
The following issue has been updated: Updater: Willie Vu (mailto:[EMAIL PROTECTED]) Date: Tue, 22 Jul 2003 2:57 AM Comment: A patch to the problem. Now ResourceBundle is loaded from JellyContext's class loader Changes: Attachment changed to BundleTag.java.patch.txt - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-62page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-62 Here is an overview of the issue: - Key: JELLY-62 Summary: FMT's BundleTag should load resource bundle from JellyContext's class loader Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: tags Assignee: Reporter: Willie Vu Created: Tue, 22 Jul 2003 2:56 AM Updated: Tue, 22 Jul 2003 2:57 AM Description: FMT's BundleTag should load resource bundle from JellyContext's class loader - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-62) FMT's BundleTag should load resource bundle from JellyContext's class loader
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-62 Here is an overview of the issue: - Key: JELLY-62 Summary: FMT's BundleTag should load resource bundle from JellyContext's class loader Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: tags Assignee: Reporter: Willie Vu Created: Tue, 22 Jul 2003 2:56 AM Updated: Tue, 22 Jul 2003 2:56 AM Description: FMT's BundleTag should load resource bundle from JellyContext's class loader - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
Serge, 1. Remove existing abandoned recovery attempt code. 2. Log when connections are abandoned and do not add them back into the pool. 3. Optionally log stack trace of where abandoned connection was first grabbed. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. I agree with your proposal, although I don't think I have a vote here. wrt point 4 I would suggest you consider allowing users to attach a listener/listeners to the pool and propogate the following events: ConnectionBorrowed - allow users to add a handler to test and possibly replace connections as they leave the pool ConnectionReturned - allow users to add a handler to test and discard (reallyClose()) connections returning to the pool ConnectionUnallocatedIdleTimeReached - allow users to add a handler to test and reallyClose() or replace connections idle in the pool beyond a confiigured idle timeout. ConnectionAllocatedIdleTimeReached - allow users to add a handler to reclaim connections allocated but idle beyond a configured idle timeout. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StringUtils.sliceFirstRemainder behavior
I think I would expect: StringUtils.slice(foo, b) = foo get everything before the last 'b' StringUtils.sliceRemainder(foo, b) = get everything after the last 'b' StringUtils.sliceFirst(foo, b) = get everything before the first 'b' StringUtils.sliceFirstRemainder(foo, b) = foo get everything after the first 'b' slice and sliceRemainder are opposite. The results would be the same for a blank separator. But then I don't use Perl which is where I think these came from. So wait to see if you get any more answers! Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:50 AM Subject: [lang] StringUtils.sliceFirstRemainder behavior Currently, StringUtils.sliceRemainder(foo, b) = = StringUtils.sliceFirst(foo, b), but StringUtils.sliceRemainder(foo, b) = foo. Is this the intended behavior? Phil - 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: [DBCP] AbandonedTrace - Connection Recovery
Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [modeler] Introspection only for primitives?
Craig, If i hear you right...If the Java class is a well behaved JavaBean then we should not need a mbeans-descriptor.xml. Right? That was exactly my point :) I want to use modeler in axis and was wondering if i really needed the mbeans-descriptor.xml files. Of course if the tool can generate a sample mbeans-descriptor.xml given a set of java classes then folks can edit it to their hearts content. BTW, can someone commit my patch? or shall i go ahead and commit them? (fixes for both JavaBean params and extend the list of supported types to include everything mentioned in the open mbeans spec) -- dims --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 21 Jul 2003, Costin Manolache wrote: Date: Mon, 21 Jul 2003 22:28:45 -0700 (PDT) From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Davanum Srinivas [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [modeler] Introspection only for primitives? On Mon, 21 Jul 2003, Davanum Srinivas wrote: Costin, Right now modeler just allows parameters that are listed in the supportedType method when we use introspection. #1 - How difficult/easy is it to allow other data types? (Why is this list of items limited?) It's not difficult to add more data types. We added mostly commont types - I think we should cover at least the types in open mbeans part of the spec. We could also add a generic mechanism to allow pluggable types ( i.e. to add more types to the list of supportedTypes ). #2 - How about other beans as parameters? (if you look at test\org\apache\commons\modeler\demo\mbeans-descriptors.xml, StandardServer has addService, removeService etc that take in a service as parameter) Sure - if it doesn't complicates things too much. BTW, one of the reason we have the supportedTypes is to avoid introspection extracting too much stuff. If you're using tools that rely on standard JavaBeans introspection, the classic mechanism to hide things you don't want seen is BeanInfo. Of course, the ultimate end of this whole line of I have to parse my own configuration files is that you are going to basically re-invent what Digester already does, and does well, but do it in a context that is local to commons-modeler. Tell me again why depending on something that already works is such a bad thing :-). Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = Davanum Srinivas - http://webservices.apache.org/~dims/ __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - 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: [io] let's get it going
I'm still here. I'm currently drowning in work so I didn't have much time for IO lately. But I guess that changes in a few days. Please just throw your suggestions in. Any help is welcome. On 22.07.2003 07:10:09 __matthewHawthorne wrote: I'm interested in contributing to [io] project. I have a few classes and methods that may be useful, and I also would like to assist with bugs and action items to help get a release out. Is there anyone involved with [io] who is available to discuss things and possibly commit patches? Jeremias, you sent a message a few weeks ago saying you had some plans to work on the project, are you still around? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
Juozas, I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. It is easy for you to say this, but the fact remains that a number of people are quite vocal in their support for it, it is wrong for us to ignore the needs of _all_ users, particularly if we are talking about removing functionality which already exists and is in use. Therefore there we have four options: 1/ We vote and the winning proposal is implemented leaving everyone else dissatisfied 2/ We retain the status quo 3/ Someone makes a change without the general consent of the group 4/ We reach a compromise. 1 is the Apache way. 2 is ignoring the issue. 3 is unacceptable and would cause trouble. 4 is surely the most reasonable course of action to take. Now I know you favour dropping support, others don't. What would you say if we retained it? What would they say if we dropped it? Alternatively Serge's proposal is a proposal for compromise, I was attempting to provide some support for the proposal by detailing one possible way in which a compromise can be accomodated, allowing both sets of users to have DBCP behave in the way they favour without breaking it for the others. If you believe my suggestions are garbage I suggest you help the process by suggesting an alternative compromise as it looks likely that only a compromise will be generally acceptable. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [modeler] Introspection only for primitives?
See attached a diff for both issues.
Thanks,
dims
PS: Shall i commit it?
--- Davanum Srinivas [EMAIL PROTECTED] wrote:
Craig,
If i hear you right...If the Java class is a well behaved JavaBean then we should
not need a
mbeans-descriptor.xml. Right? That was exactly my point :) I want to use modeler in
axis and was
wondering if i really needed the mbeans-descriptor.xml files.
Of course if the tool can generate a sample mbeans-descriptor.xml given a set of
java classes
then
folks can edit it to their hearts content.
BTW, can someone commit my patch? or shall i go ahead and commit them? (fixes for
both JavaBean
params and extend the list of supported types to include everything mentioned in the
open
mbeans
spec)
-- dims
--- Craig R. McClanahan [EMAIL PROTECTED] wrote:
On Mon, 21 Jul 2003, Costin Manolache wrote:
Date: Mon, 21 Jul 2003 22:28:45 -0700 (PDT)
From: Costin Manolache [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Davanum Srinivas [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [modeler] Introspection only for primitives?
On Mon, 21 Jul 2003, Davanum Srinivas wrote:
Costin,
Right now modeler just allows parameters that are listed in the supportedType
method when
we
use
introspection.
#1 - How difficult/easy is it to allow other data types? (Why is this list of
items
limited?)
It's not difficult to add more data types. We added mostly commont types -
I think we should cover at least the types in open mbeans part of the
spec.
We could also add a generic mechanism to allow pluggable types ( i.e. to
add more types to the list of supportedTypes ).
#2 - How about other beans as parameters? (if you look at
test\org\apache\commons\modeler\demo\mbeans-descriptors.xml, StandardServer has
addService,
removeService etc that take in a service as parameter)
Sure - if it doesn't complicates things too much.
BTW, one of the reason we have the supportedTypes is to avoid
introspection extracting too much stuff.
If you're using tools that rely on standard JavaBeans introspection, the
classic mechanism to hide things you don't want seen is BeanInfo.
Of course, the ultimate end of this whole line of I have to parse my own
configuration files is that you are going to basically re-invent what
Digester already does, and does well, but do it in a context that is local
to commons-modeler. Tell me again why depending on something that already
works is such a bad thing :-).
Costin
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
=
Davanum Srinivas - http://webservices.apache.org/~dims/
__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
=
Davanum Srinivas - http://webservices.apache.org/~dims/
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.comcvs -z9 -q diff -u -wb -i MbeansDescriptorsIntrospectionSource.java (in directory
C:\jakarta\jakarta-commons\modeler\src\java\org\apache\commons\modeler\modules\)
Index: MbeansDescriptorsIntrospectionSource.java
===
RCS file:
/home/cvs/jakarta-commons/modeler/src/java/org/apache/commons/modeler/modules/MbeansDescriptorsIntrospectionSource.java,v
retrieving revision 1.9
diff -d -u -b -B -w -u -w -b -i -r1.9 MbeansDescriptorsIntrospectionSource.java
--- MbeansDescriptorsIntrospectionSource.java 20 Jul 2003 07:35:12 - 1.9
+++ MbeansDescriptorsIntrospectionSource.java 22 Jul 2003 12:42:31 -
@@ -1,14 +1,5 @@
package org.apache.commons.modeler.modules;
-import java.lang.reflect.Method;
-import java.lang.reflect.Modifier;
-import java.util.ArrayList;
-import java.util.Enumeration;
-import java.util.Hashtable;
-import java.util.List;
-
-import javax.management.ObjectName;
-
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.commons.modeler.AttributeInfo;
@@ -17,6 +8,17 @@
import org.apache.commons.modeler.ParameterInfo;
import org.apache.commons.modeler.Registry;
+import javax.management.ObjectName;
+import java.lang.reflect.Method;
+import java.lang.reflect.Modifier;
+import java.util.ArrayList;
+import java.util.Enumeration;
+import java.util.Hashtable;
+import java.util.List;
+import java.util.Arrays;
+import java.math.BigInteger;
+import java.math.BigDecimal;
+
public class MbeansDescriptorsIntrospectionSource extends ModelerSource
{
@@ -88,19 +90,84 @@
private static ObjectName objNameArray[]=new ObjectName[0];
// createMBean == registerClass + registerMBean
+private static
RE: [DBCP] AbandonedTrace - Connection Recovery
I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). this kind of thing almost certainly indicates a failure of application code or the library - both are things that are worth knowing about (my moneys on the app :¬). I fully agree with no attempt to 'recover' any sort of connection but it would assist debugging of legacy apps and other people's code if you could spot where the connection came from... Of course you could just take the view that p6spy does what you need and provide a pointer in that direction, commiters choice really... Matt -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 22 July 2003 13:16 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
- Original Message - From: Danny Angus [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 2:19 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery Juozas, I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. It is easy for you to say this, but the fact remains that a number of people are quite vocal in their support for it, it is wrong for us to ignore the needs of _all_ users, particularly if we are talking about removing functionality which already exists and is in use. Therefore there we have four options: 1/ We vote and the winning proposal is implemented leaving everyone else dissatisfied 2/ We retain the status quo 3/ Someone makes a change without the general consent of the group 4/ We reach a compromise. 1 is the Apache way. 2 is ignoring the issue. 3 is unacceptable and would cause trouble. 4 is surely the most reasonable course of action to take. Now I know you favour dropping support, others don't. What would you say if we retained it? I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . What would they say if we dropped it? Alternatively Serge's proposal is a proposal for compromise, I was attempting to provide some support for the proposal by detailing one possible way in which a compromise can be accomodated, allowing both sets of users to have DBCP behave in the way they favour without breaking it for the others. If you believe my suggestions are garbage I suggest you help the process by suggesting an alternative compromise as it looks likely that only a compromise will be generally acceptable. d. - 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: [DBCP] AbandonedTrace - Connection Recovery
Danny Angus wrote: Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. I don't have a vote in DBCP... Using the Observer pattern seems a fine approach, especially since the functionality was Voted on some time ago. Further, it sounds like you have tried to take others concerns into account, and discussed the issue. My 2 cents, It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rob Leland
RE: [DBCP] AbandonedTrace - Connection Recovery
Juozas, I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . I think it is sad that you would rather leave than suggest any alternative. It highlights my point though, why should we expect those in favour of its retention to remain involved if we drop this when you won't remain involved if it is not dropped? Surely we should at least _try_ to accomodate both points of view? Or are also against even helping to find a compromise that would satify your requirements? I can see no technical reason why this should not be done, perhaps you can? If so why don't you help us by explaining why a compromise can never be acceptable to you. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
--- Danny Angus [EMAIL PROTECTED] wrote: Juozas, I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . I think it is sad that you would rather leave than suggest any alternative. It highlights my point though, why should we expect those in favour of its retention to remain involved if we drop this when you won't remain involved if it is not dropped? Surely we should at least _try_ to accomodate both points of view? Or are also against even helping to find a compromise that would satify your requirements? I can see no technical reason why this should not be done, perhaps you can? If so why don't you help us by explaining why a compromise can never be acceptable to you. IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set. David d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set. I'm not sure what you mean... supporting abandoned code will not fix code, and having Jakarta code fix (and encourage better design and keep people from writing their own bad implementations to common problems) are all great precedents. There is _no_ abandoned code approach that will fix code. Waiting for a finalizer to return a database collection will never result in an application behaving well. The issue is having more control over what happens in this situation, such as preventing a rarely called piece of code from failing quickly (will fail slowly, ideally allowing you tolerate it until fix in an upcoming release). I mean, c'mon, some apache developers are so full of themselves, I think they would welcome the opportunity to correct others code. :) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
- Original Message - From: Danny Angus [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 3:18 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery Juozas, I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . I think it is sad that you would rather leave than suggest any alternative. It highlights my point though, why should we expect those in favour of its retention to remain involved if we drop this when you won't remain involved if it is not dropped? Surely we should at least _try_ to accomodate both points of view? Or are also against even helping to find a compromise that would satify your requirements? I can see no technical reason why this should not be done, perhaps you can? If so why don't you help us by explaining why a compromise can never be acceptable to you. I believe application must work with any kind of pool implementation and not to depend on wokarounds in pool. This kind of wokaround breaks contract and portability, but can not solve resource management problem. I do not think it is good idea to experiment on stable component and I think a new subproject is the best compromise in this case. Resource manager it is not a traditional pool of database connections. The idea is very simple: 1. close is a programming error in managed code. 2. Resource manager is backed by any pool implementation. It is very trivial to implement and to port/fix any legacy code. d. - 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: [DBCP] AbandonedTrace - Connection Recovery
--- Serge Knystautas [EMAIL PROTECTED] wrote: David Graham wrote: IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set. I'm not sure what you mean... supporting abandoned code will not fix code, and having Jakarta code fix (and encourage better design and keep people from writing their own bad implementations to common problems) are all great precedents. There is _no_ abandoned code approach that will fix code. Waiting for a finalizer to return a database collection will never result in an application behaving well. The issue is having more control over what happens in this situation, such as preventing a rarely called piece of code from failing quickly (will fail slowly, ideally allowing you tolerate it until fix in an upcoming release). Code should fail quickly to help debugging. If an app is worried about a resource leak, it could write a plugin to DBCP that knows what to do. DBCP has no way of knowing what the app should do in the event of a resource leak. This really isn't a coding issue; it's a policy and management issue. If you have apps that are leaking connections, give each app its own DataSource so it doesn't affect other applications. This is clearly outside of DBCP's scope. David I mean, c'mon, some apache developers are so full of themselves, I think they would welcome the opportunity to correct others code. :) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[modeler] Instrospection does not fillup info on Constructors.
FYI, There is no code in MbeansDescriptorsIntrospectionSource for adding ConstructorInfo to ManagedBean's. -- dims = Davanum Srinivas - http://webservices.apache.org/~dims/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21797] New: - [lang] Add javadoc examples and tests for StringUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21797. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21797 [lang] Add javadoc examples and tests for StringUtils Summary: [lang] Add javadoc examples and tests for StringUtils Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Lang AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The attached patch adds javadoc examples and some more test cases for the remaining non-deprecated StringUtils methods without examples. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21797] - [lang] Add javadoc examples and tests for StringUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21797. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21797 [lang] Add javadoc examples and tests for StringUtils --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 14:30 --- Created an attachment (id=7446) Patches to StringUtils, StringUtilsTest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StringUtils.sliceFirstRemainder behavior
Stephen Colebourne wrote: I think I would expect: StringUtils.slice(foo, b) = foo get everything before the last 'b' StringUtils.sliceRemainder(foo, b) = get everything after the last 'b' StringUtils.sliceFirst(foo, b) = get everything before the first 'b' StringUtils.sliceFirstRemainder(foo, b) = foo get everything after the first 'b' slice and sliceRemainder are opposite. The results would be the same for a blank separator. But then I don't use Perl which is where I think these came from. So wait to see if you get any more answers! Stephen I just submitted a patch here http://issues.apache.org/bugzilla/show_bug.cgi?id=21797 that documents current behavior with examples and test cases. Phil - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:50 AM Subject: [lang] StringUtils.sliceFirstRemainder behavior Currently, StringUtils.sliceRemainder(foo, b) = = StringUtils.sliceFirst(foo, b), but StringUtils.sliceRemainder(foo, b) = foo. Is this the intended behavior? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21800] New: - because The OutputStreamWriter not flush, so short String will encoded error...
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21800.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21800
because The OutputStreamWriter not flush, so short String will encoded error...
Summary: because The OutputStreamWriter not flush, so short
String will encoded error...
Product: Commons
Version: Nightly Builds
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Codec
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
because The OutputStreamWriter not flush, so short String will encoded error...
org.apache.commons.codec.base64 bug, i coreect,anyone can notify the committer
public static String encode(String data, String
charEncoding)
throws UnsupportedEncodingException {
// Check arguments
if (data == null) {
data = ;
}
if (charEncoding == null) {
charEncoding = DEFAULT_CHAR_ENCODING;
}
// Convert to byte[]
ByteArrayOutputStream bos = new
ByteArrayOutputStream();
OutputStreamWriter osw = new
OutputStreamWriter(bos, charEncoding);
try {
osw.write(data);
//*should add start*
osw.flush()
//*should add end*
} catch (IOException ioe) {
throw new
RuntimeException(ioe.toString());
}
// Encode
byte[] encodedData =
encode(bos.toByteArray());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 22 Jul 2003, Juozas Baliuka wrote: Date: Tue, 22 Jul 2003 14:15:53 +0200 From: Juozas Baliuka [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. The observer pattern is by no means useless. How many people have you seen ask for a way to accumulate statistics on the use of their pool? Event listeners are a very practical mechansim for anyone who wants to support this. It's also consistent with JavaBean event and listener patterns that are visible in a very large number of Java APIs. +1 for supporting events and listeners. -1 for including standard listener implementations in DBCP that attempt to do abandoned connection recovery (that's an exercise that can be left to the user). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21801] New: - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. Summary: [io] minor enhancements and action items. Product: Commons Version: 1.0 Alpha Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - Renamed IOUtil to IOUtils, and EndianUtil to EndianUtils - Added a main method to IOTestSuite - Added cvs repo information to the project.xml - Added LICENSE.txt file, so maven checkstyle plugin can function. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [modeler] Introspection only for primitives?
On Tue, 22 Jul 2003, Davanum Srinivas wrote: Date: Tue, 22 Jul 2003 03:45:15 -0700 (PDT) From: Davanum Srinivas [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [modeler] Introspection only for primitives? Craig, If i hear you right...If the Java class is a well behaved JavaBean then we should not need a mbeans-descriptor.xml. Right? Not exactly. I think you still want a place define the metadata information about your managed bean -- in the same way that BeanInfo lets you supply that externally about a standard JavaBean. We can probably figure out ways to synthesize default metadata if there is no descriptor. My comment was really directed at why the class you are proposing a patch for exists in the first place. The original version of Modeler used Commons Digester to parse the descriptor file, and Digester can already deal with the sorts of conversions you are patching to achieve -- plus a whole bunch more. But Costin decided he didn't like it, so he abstracted out a mini-Digester (with fewer features, but probably a little faster and smaller), which you're now left with having to patch to get back to where we already were. That was exactly my point :) I want to use modeler in axis and was wondering if i really needed the mbeans-descriptor.xml files. Of course if the tool can generate a sample mbeans-descriptor.xml given a set of java classes then folks can edit it to their hearts content. BTW, can someone commit my patch? or shall i go ahead and commit them? (fixes for both JavaBean params and extend the list of supported types to include everything mentioned in the open mbeans spec) -- dims Craig --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 21 Jul 2003, Costin Manolache wrote: Date: Mon, 21 Jul 2003 22:28:45 -0700 (PDT) From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Davanum Srinivas [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [modeler] Introspection only for primitives? On Mon, 21 Jul 2003, Davanum Srinivas wrote: Costin, Right now modeler just allows parameters that are listed in the supportedType method when we use introspection. #1 - How difficult/easy is it to allow other data types? (Why is this list of items limited?) It's not difficult to add more data types. We added mostly commont types - I think we should cover at least the types in open mbeans part of the spec. We could also add a generic mechanism to allow pluggable types ( i.e. to add more types to the list of supportedTypes ). #2 - How about other beans as parameters? (if you look at test\org\apache\commons\modeler\demo\mbeans-descriptors.xml, StandardServer has addService, removeService etc that take in a service as parameter) Sure - if it doesn't complicates things too much. BTW, one of the reason we have the supportedTypes is to avoid introspection extracting too much stuff. If you're using tools that rely on standard JavaBeans introspection, the classic mechanism to hide things you don't want seen is BeanInfo. Of course, the ultimate end of this whole line of I have to parse my own configuration files is that you are going to basically re-invent what Digester already does, and does well, but do it in a context that is local to commons-modeler. Tell me again why depending on something that already works is such a bad thing :-). Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = Davanum Srinivas - http://webservices.apache.org/~dims/ __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com - 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 21801] - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 15:47 --- Created an attachment (id=7448) added cvs repo information - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 22 Jul 2003, Craig R. McClanahan wrote: On Tue, 22 Jul 2003, Juozas Baliuka wrote: Date: Tue, 22 Jul 2003 14:15:53 +0200 From: Juozas Baliuka [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. The observer pattern is by no means useless. How many people have you seen ask for a way to accumulate statistics on the use of their pool? Event listeners are a very practical mechansim for anyone who wants to support this. It's also consistent with JavaBean event and listener patterns that are visible in a very large number of Java APIs. +1 for supporting events and listeners. -1 for including standard listener implementations in DBCP that attempt to do abandoned connection recovery (that's an exercise that can be left to the user). Could a standard listener implementation be something contributed and placed in dbcp under contrib/? Just an idea. Adam K. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21801] - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 15:48 --- Created an attachment (id=7449) updated refs to IOUtil and EndianUtil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [modeler] Introspection only for primitives?
On Tue, 22 Jul 2003, Davanum Srinivas wrote: Date: Tue, 22 Jul 2003 05:44:08 -0700 (PDT) From: Davanum Srinivas [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [modeler] Introspection only for primitives? See attached a diff for both issues. Thanks, dims PS: Shall i commit it? +1, as long as you add your name to STATUS.html :-). Craig --- Davanum Srinivas [EMAIL PROTECTED] wrote: Craig, If i hear you right...If the Java class is a well behaved JavaBean then we should not need a mbeans-descriptor.xml. Right? That was exactly my point :) I want to use modeler in axis and was wondering if i really needed the mbeans-descriptor.xml files. Of course if the tool can generate a sample mbeans-descriptor.xml given a set of java classes then folks can edit it to their hearts content. BTW, can someone commit my patch? or shall i go ahead and commit them? (fixes for both JavaBean params and extend the list of supported types to include everything mentioned in the open mbeans spec) -- dims --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 21 Jul 2003, Costin Manolache wrote: Date: Mon, 21 Jul 2003 22:28:45 -0700 (PDT) From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Davanum Srinivas [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [modeler] Introspection only for primitives? On Mon, 21 Jul 2003, Davanum Srinivas wrote: Costin, Right now modeler just allows parameters that are listed in the supportedType method when we use introspection. #1 - How difficult/easy is it to allow other data types? (Why is this list of items limited?) It's not difficult to add more data types. We added mostly commont types - I think we should cover at least the types in open mbeans part of the spec. We could also add a generic mechanism to allow pluggable types ( i.e. to add more types to the list of supportedTypes ). #2 - How about other beans as parameters? (if you look at test\org\apache\commons\modeler\demo\mbeans-descriptors.xml, StandardServer has addService, removeService etc that take in a service as parameter) Sure - if it doesn't complicates things too much. BTW, one of the reason we have the supportedTypes is to avoid introspection extracting too much stuff. If you're using tools that rely on standard JavaBeans introspection, the classic mechanism to hide things you don't want seen is BeanInfo. Of course, the ultimate end of this whole line of I have to parse my own configuration files is that you are going to basically re-invent what Digester already does, and does well, but do it in a context that is local to commons-modeler. Tell me again why depending on something that already works is such a bad thing :-). Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = Davanum Srinivas - http://webservices.apache.org/~dims/ __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com = Davanum Srinivas - http://webservices.apache.org/~dims/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21801] - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 15:48 --- Created an attachment (id=7450) Added main method - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21801] - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 15:49 --- Created an attachment (id=7451) updated refs to IOUtil and EndianUtil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21801] - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 15:49 --- Created an attachment (id=7452) updated refs to IOUtil and EndianUtil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21801] - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 15:49 --- Created an attachment (id=7453) license file to go in root directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [modeler] Instrospection does not fillup info on Constructors.
On Tue, 22 Jul 2003, Davanum Srinivas wrote: Date: Tue, 22 Jul 2003 07:12:32 -0700 (PDT) From: Davanum Srinivas [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [modeler] Instrospection does not fillup info on Constructors. FYI, There is no code in MbeansDescriptorsIntrospectionSource for adding ConstructorInfo to ManagedBean's. That should definitely be fixed. Unfortunately, I don't have time to work on it directly, but would be happy to review patches. -- dims Craig = Davanum Srinivas - http://webservices.apache.org/~dims/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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 21801] - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 15:50 --- Created an attachment (id=7454) IOUtil renamed to IOUtils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21801] - [io] minor enhancements and action items.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 [io] minor enhancements and action items. --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 15:50 --- Created an attachment (id=7455) EndianUtil - EndianUtils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: --- Serge Knystautas [EMAIL PROTECTED] wrote: David Graham wrote: IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set. I'm not sure what you mean... supporting abandoned code will not fix code, and having Jakarta code fix (and encourage better design and keep people from writing their own bad implementations to common problems) are all great precedents. There is _no_ abandoned code approach that will fix code. Waiting for a finalizer to return a database collection will never result in an application behaving well. The issue is having more control over what happens in this situation, such as preventing a rarely called piece of code from failing quickly (will fail slowly, ideally allowing you tolerate it until fix in an upcoming release). Code should fail quickly to help debugging. If an app is worried about a resource leak, it could write a plugin to DBCP that knows what to do. DBCP has no way of knowing what the app should do in the event of a resource leak. This really isn't a coding issue; it's a policy and management issue. If you have apps that are leaking connections, give each app its own DataSource so it doesn't affect other applications. This is clearly outside of DBCP's scope. I agree that this is an education/policy issue. But sometimes you need a stop gap solution to keep something running while the customer fixes the problem. I would like to see this stop gap solution included with the DBCP release. Along with quality docs on how to properly use a db connection pool and a big disclaimer that the recovery of abandoned connections should only be used as a stop gap in an emergency until the customer has time to fix their code. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/modeler/src/java/org/apache/commons/modeler/modules MbeansDescriptorsIntrospectionSource.java
dims2003/07/22 09:03:19
Modified:modeler STATUS.html
modeler/src/java/org/apache/commons/modeler/modules
MbeansDescriptorsIntrospectionSource.java
Log:
- Added myself to STATUS.html
- Introspection now allows all primitives listed in the open mbeans spec as method
parameters
- Introspection now allows javabeans as method parameters.
Revision ChangesPath
1.3 +6 -1 jakarta-commons/modeler/STATUS.html
Index: STATUS.html
===
RCS file: /home/cvs/jakarta-commons/modeler/STATUS.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- STATUS.html 19 Apr 2003 16:53:59 - 1.2
+++ STATUS.html 22 Jul 2003 16:03:18 - 1.3
@@ -62,5 +62,10 @@
lia href=mailto:costin at apache.orgCostin Manolache/a/li
/ul
+pThe following individuals have submitted patches for this component./p
+ul
+lia href=mailto:dims at yahoo.comDavanum Srinivas/a/li
+/ul
+
/body
/html
1.10 +88 -22
jakarta-commons/modeler/src/java/org/apache/commons/modeler/modules/MbeansDescriptorsIntrospectionSource.java
Index: MbeansDescriptorsIntrospectionSource.java
===
RCS file:
/home/cvs/jakarta-commons/modeler/src/java/org/apache/commons/modeler/modules/MbeansDescriptorsIntrospectionSource.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- MbeansDescriptorsIntrospectionSource.java 20 Jul 2003 07:35:12 - 1.9
+++ MbeansDescriptorsIntrospectionSource.java 22 Jul 2003 16:03:19 - 1.10
@@ -1,14 +1,5 @@
package org.apache.commons.modeler.modules;
-import java.lang.reflect.Method;
-import java.lang.reflect.Modifier;
-import java.util.ArrayList;
-import java.util.Enumeration;
-import java.util.Hashtable;
-import java.util.List;
-
-import javax.management.ObjectName;
-
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.commons.modeler.AttributeInfo;
@@ -17,6 +8,16 @@
import org.apache.commons.modeler.ParameterInfo;
import org.apache.commons.modeler.Registry;
+import javax.management.ObjectName;
+import java.lang.reflect.Method;
+import java.lang.reflect.Modifier;
+import java.math.BigDecimal;
+import java.math.BigInteger;
+import java.util.ArrayList;
+import java.util.Enumeration;
+import java.util.Hashtable;
+import java.util.List;
+
public class MbeansDescriptorsIntrospectionSource extends ModelerSource
{
@@ -88,21 +89,86 @@
private static ObjectName objNameArray[]=new ObjectName[0];
// createMBean == registerClass + registerMBean
-private boolean supportedType( Class ret ) {
-return ret == String.class ||
-ret == Integer.class ||
-ret == Integer.TYPE ||
-ret == Long.class ||
-ret == Long.TYPE ||
-ret == java.io.File.class ||
-ret == Boolean.class ||
-ret == Boolean.TYPE ||
-ret == strArray.getClass() ||
-ret == ObjectName.class ||
-ret == objNameArray.getClass()
-;
+private static Class[] supportedTypes = new Class[] {
+Boolean.class,
+Boolean.TYPE,
+Byte.class,
+Byte.TYPE,
+Character.class,
+Character.TYPE,
+Short.class,
+Short.TYPE,
+Integer.class,
+Integer.TYPE,
+Long.class,
+Long.TYPE,
+Float.class,
+Float.TYPE,
+Double.class,
+Double.TYPE,
+String.class,
+strArray.getClass(),
+BigDecimal.class,
+BigInteger.class,
+ObjectName.class,
+objNameArray.getClass(),
+java.io.File.class,
+};
+
+/**
+ * Check if this class is one of the supported types.
+ * @param ret
+ * @return true if the class is a supported type.
+ */
+private boolean supportedType(Class ret) {
+for (int i = 0; i supportedTypes.length; i++) {
+if (ret == supportedTypes[i]) {
+return true;
+}
+}
+if (isBeanCompatible(ret)) {
+return true;
+}
+return false;
}
+/**
+ * Check if this class conforms to JavaBeans specifications.
+ * @param javaType
+ * @return
+ */
+protected boolean isBeanCompatible(Class javaType) {
+// Must be a non-primitive and non array
+if (javaType.isArray() || javaType.isPrimitive()) {
+return false;
+}
+
+// Anything in the java or javax
[io] some minor enhancements and completed action items
I submitted patches for some small changes, everything is in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Philasophy of URI? - Re: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestURI.java
I think you should not deprecate previous constructors.
And actually no reason to be deprecated as I see.
And about String boolean constructors,
1. JUST CONVENIENCE:
that's ok though... you'd better clear up some comments on the top of the class usage
as I see.
2. FOR REVOLUTION:
when you're not gonna distiguish empty and undefiled components of URI,
you should modify the all URI documents related that...
uri string sequences and internal escpaed sequence are distinguished internally...
That's why char and String type is distiguished in the class...
java.net.URL and java.net.URI are restricted to implment that...
Sung-Gu
- Original Message -
From: [EMAIL PROTECTED]
/**
* Construct a URI as an escaped form of a character array with the given
@@ -164,6 +201,8 @@
* @throws URIException If the URI cannot be created.
* @throws NullPointerException if codeescaped/code is codenull/code
* @see #getProtocolCharset
+ *
+ * @deprecated Use #URI(String, boolean, String)
*/
public URI(char[] escaped, String charset)
throws URIException, NullPointerException {
@@ -181,6 +220,8 @@
* @throws URIException If the URI cannot be created.
* @throws NullPointerException if codeescaped/code is codenull/code
* @see #getDefaultProtocolCharset
+ *
+ * @deprecated Use #URI(String, boolean)
*/
public URI(char[] escaped)
throws URIException, NullPointerException {
@@ -196,6 +237,8 @@
* @param charset the charset string to do escape encoding
* @throws URIException If the URI cannot be created.
* @see #getProtocolCharset
+ *
+ * @deprecated Use #URI(String, boolean, String)
*/
public URI(String original, String charset) throws URIException {
protocolCharset = charset;
@@ -215,6 +258,8 @@
* It is one of absoluteURI and relativeURI.
* @throws URIException If the URI cannot be created.
* @see #getDefaultProtocolCharset
+ *
+ * @deprecated Use #URI(String, boolean)
*/
public URI(String original) throws URIException {
parseUriReference(original, false);
@@ -412,9 +457,26 @@
* @param base the base URI
* @param relative the relative URI string
* @throws URIException If the new URI cannot be created.
+ *
+ * @deprecated Use #URI(URI, String, boolean)
*/
public URI(URI base, String relative) throws URIException {
this(base, new URI(relative));
+}
+
+
+/**
+ * Construct a general URI with the given relative URI string.
+ *
+ * @param base the base URI
+ * @param relative the relative URI string
+ * @param escaped tttrue/tt if URI character sequence is in escaped form.
+ *ttfalse/tt otherwise.
+ *
+ * @throws URIException If the new URI cannot be created.
+ */
+public URI(URI base, String relative, boolean escaped) throws URIException {
+this(base, new URI(relative, escaped));
}
Re: [io] some minor enhancements and completed action items
Yup, seen them. Will look at them on Thursday or Friday if nobody acts sooner. But the rename will likely provoke some Gump failures. Do we need to inform the dependant projects prior to the renaming or shall we just make it happen and let the others sort it out (IO is not released)? On 22.07.2003 18:07:34 __matthewHawthorne wrote: I submitted patches for some small changes, everything is in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Philasophy of URI? - Re: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestURI.java
Ok, I'll say you're not gonna use char type as external interfaces... It's not confined in constructors only...methods with char type arguments and other classes like HttpURL... (Actually, I think you should be interested in HttpURL... not only URI, I believe) Please, take care of them also with consistency... Take care, Sung-Gu
Re: [DBCP] AbandonedTrace - Connection Recovery
http://java.sun.com/products/jdbc/jdbc2_0_1-stdext-javadoc/javax/sql/PooledC onnection.html +1 to implement this interface, but I do not think it can help for broken applications. - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:38 PM Subject: Re: [DBCP] AbandonedTrace - Connection Recovery On Tue, 22 Jul 2003, Juozas Baliuka wrote: Date: Tue, 22 Jul 2003 14:15:53 +0200 From: Juozas Baliuka [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. The observer pattern is by no means useless. How many people have you seen ask for a way to accumulate statistics on the use of their pool? Event listeners are a very practical mechansim for anyone who wants to support this. It's also consistent with JavaBean event and listener patterns that are visible in a very large number of Java APIs. +1 for supporting events and listeners. -1 for including standard listener implementations in DBCP that attempt to do abandoned connection recovery (that's an exercise that can be left to the user). Craig - 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: [DBCP] AbandonedTrace - Connection Recovery
I agree that this is an education/policy issue. But sometimes you need a stop gap solution to keep something running while the customer fixes the problem. I would like to see this stop gap solution included with the DBCP release. Along with quality docs on how to properly use a db connection pool and a big disclaimer that the recovery of abandoned connections should only be used as a stop gap in an emergency until the customer has time to fix their code. Try to implement yourself and I am sure the time to fix a problem will mean forever and crappers will blame you then server or app will crache. Do you want to blame apache for this code ? This problem redirection will not help, but if you want, you can maintain this crap yourself, but do not try to redirect this problem to apache please. Regards, Glenn - 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]
jelly build problems...
I downloaded the jelly src 1.0, and maven-1.0-beta-10.zip. When I build I run maven or maven test I get these errors... WARNING: Failed to download jdbc-2.0.jar. Attempting to download jms-1.0.2b.jar. Error retrieving artifact from [http://www.ibiblio.org/maven/jms/jars/jms-1.0.2b .jar]: java.lang.Exception: Can't get jms-1.0.2b.jar to C:\Documents and Setting s\dhiller\.maven\repository\jms\jars\jms-1.0.2b.jar I get this for only 4 jars. The rest worked fine. I read somewhere there was a FAQ on this in maven, but could not find it and alas gave up. I have a framework which I would like to integrate with JellyUnit, because they are so similar and it would be stupid of me not just to join in on the jelly project instead. thanks for any pointers or references to more docs, or possible solutions you know of, Dean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jelly build problems...
Dean Hiller wrote: I downloaded the jelly src 1.0, and maven-1.0-beta-10.zip. When I build I run maven or maven test I get these errors... WARNING: Failed to download jdbc-2.0.jar. Attempting to download jms-1.0.2b.jar. Error retrieving artifact from [http://www.ibiblio.org/maven/jms/jars/jms-1.0.2b cut/ thanks for any pointers or references to more docs, or possible solutions you know of, Sun libraries cannot be stored on ibiblio due to Sun licences. You've to download them from Sun site and put store in your local repository manually. Regards, Tomek PS: http://maven.apache.org/sun-licensing-journey.html Dean - 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 21815] New: - ftp transfer resume not working with passive mode.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21815.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21815
ftp transfer resume not working with passive mode.
Summary: ftp transfer resume not working with passive mode.
Product: Commons
Version: 1.0 Final
Platform: All
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Net
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
subject says it all: I think you just omitted the following code in
ftpclient.java:
instead of:
socket = _socketFactory_.createSocket(__passiveHost, __passivePort);
if (!FTPReply.isPositivePreliminary(sendCommand(command, arg)))
{
socket.close();
return null;
}
should read:
socket = _socketFactory_.createSocket(__passiveHost, __passivePort);
if ((__restartOffset 0) !restart(__restartOffset))
{
socket.close();
return null;
}
if (!FTPReply.isPositivePreliminary(sendCommand(command, arg)))
{
socket.close();
return null;
}
That is, you just forgot a simple clause (which I adapted from the active mode
code). I tested it (basically) and it works.
hope this helps your excellent project.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21797] - [lang] Add javadoc examples and tests for StringUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21797. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21797 [lang] Add javadoc examples and tests for StringUtils [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 23:39 --- Patch applied, thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StringUtils.sliceFirstRemainder behavior
OK, the current behaviour seems daft to me. Can anyone explain why this is as it is? StringUtils.sliceFirst(abc, ) = abc StringUtils.sliceFirst(abc, d) = StringUtils.sliceFirstRemainder(abc, ) = StringUtils.sliceFirstRemainder(abc, d) = abc I would expect the exact opposite: StringUtils.sliceFirst(abc, ) = StringUtils.sliceFirst(abc, d) = abc StringUtils.sliceFirstRemainder(abc, ) = abc StringUtils.sliceFirstRemainder(abc, d) = I would expect slice first to return the text before the first separator. An empty string is found at position zero, so it should return . Separator d is not found, so everything before it is the whole string. I'd like to change this, but why is it as it is??? Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 3:30 PM Subject: Re: [lang] StringUtils.sliceFirstRemainder behavior Stephen Colebourne wrote: I think I would expect: StringUtils.slice(foo, b) = foo get everything before the last 'b' StringUtils.sliceRemainder(foo, b) = get everything after the last 'b' StringUtils.sliceFirst(foo, b) = get everything before the first 'b' StringUtils.sliceFirstRemainder(foo, b) = foo get everything after the first 'b' slice and sliceRemainder are opposite. The results would be the same for a blank separator. But then I don't use Perl which is where I think these came from. So wait to see if you get any more answers! Stephen I just submitted a patch here http://issues.apache.org/bugzilla/show_bug.cgi?id=21797 that documents current behavior with examples and test cases. Phil - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:50 AM Subject: [lang] StringUtils.sliceFirstRemainder behavior Currently, StringUtils.sliceRemainder(foo, b) = = StringUtils.sliceFirst(foo, b), but StringUtils.sliceRemainder(foo, b) = foo. Is this the intended behavior? Phil - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21797] - [lang] Add javadoc examples and tests for StringUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21797. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21797 [lang] Add javadoc examples and tests for StringUtils [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Posssible bug in Betwixt alpha
Hi , I guess , when user calls method beanReader.parse(file) , the update of class org.apache.commons.betwixt._expression_.MethodUpdater gets called. I observed that if the data types are java.util.Date , int the attributes are not getting converted to the required data type and hence I get the InvalidArgumentExcetion as the default attribute type passed is String If the date is java.sql.Date then there is no problem but if it is java.util.Date type then I get this exception. One possible cause is that these data types do not have constructors accepting String as only argument. e.g java.util.Date has deprecated new Date(String) constructor. And the Interger can not be converted to int like new int(String) the code newValue = ConvertUtils.convert( (String) newValue, valueType ); will always fail to convert to int or java.util.Date. Attaching the log file where I modified MethodUpdater and the log file I got. In theMethodUpdater , I have put some statements with UJ so you will see the log has those debug statements. Thanks Ujjwala - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-63) email tag attributes do not accept Expression.
The following issue has been updated: Updater: Willie Vu (mailto:[EMAIL PROTECTED]) Date: Tue, 22 Jul 2003 9:11 PM Comment: A patch to make all attributes accept expressions Changes: Attachment changed to EmailTag.java.patch.txt - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-63page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-63 Here is an overview of the issue: - Key: JELLY-63 Summary: email tag attributes do not accept Expression. Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: tags Assignee: Reporter: Willie Vu Created: Tue, 22 Jul 2003 9:10 PM Updated: Tue, 22 Jul 2003 9:11 PM Description: All attributes should accept expression. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth CredentialsNotAvailableException.java InvalidCredentialsException.java
mbecke 2003/07/22 18:20:32
Added: httpclient/src/java/org/apache/commons/httpclient/auth
CredentialsNotAvailableException.java
InvalidCredentialsException.java
Log:
Added exceptions missing from previous patch.
PR: 19868
Revision ChangesPath
1.1
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/CredentialsNotAvailableException.java
Index: CredentialsNotAvailableException.java
===
/*
* $Header:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/CredentialsNotAvailableException.java,v
1.1 2003/07/23 01:20:32 mbecke Exp $
* $Revision: 1.1 $
* $Date: 2003/07/23 01:20:32 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2002-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.commons.httpclient.auth;
/**
* Authentication credentials required to respond to a authentication
* challenge are not available
*
* @author a href=mailto:[EMAIL PROTECTED]Oleg Kalnichevski/a
*
* @since 2.1
*/
public class CredentialsNotAvailableException extends AuthenticationException {
/**
* Creates a new CredentialsNotAvailableException with a ttnull/tt detail
message.
*/
public CredentialsNotAvailableException() {
super();
}
/**
* Creates a new CredentialsNotAvailableException with the specified message.
*
* @param message the exception detail message
*/
public CredentialsNotAvailableException(String message) {
super(message);
}
/**
* Creates a new CredentialsNotAvailableException with the specified detail
message and cause.
*
* @param message the exception detail message
* @param cause the ttThrowable/tt that caused this exception, or
ttnull/tt
* if the cause is unavailable, unknown, or not a ttThrowable/tt
*/
public CredentialsNotAvailableException(String message, Throwable cause) {
super(message, cause);
}
}
1.1
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient MultiThreadedHttpConnectionManager.java
mbecke 2003/07/22 18:28:02
Modified:httpclient/src/java/org/apache/commons/httpclient
MultiThreadedHttpConnectionManager.java
Log:
Added connection life-cycle debugging.
PR: 21788
Revision ChangesPath
1.21 +10 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java
Index: MultiThreadedHttpConnectionManager.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- MultiThreadedHttpConnectionManager.java 16 Jul 2003 20:48:27 - 1.20
+++ MultiThreadedHttpConnectionManager.java 23 Jul 2003 01:28:02 - 1.21
@@ -443,6 +443,9 @@
if ((hostPool.numConnections getMaxConnectionsPerHost())
(numConnections getMaxTotalConnections())) {
+if (LOG.isDebugEnabled()) {
+LOG.debug(Allocating new connection for hostConfig: +
hostConfiguration);
+}
connection = new HttpConnection(hostConfiguration);
connection.setHttpConnectionManager(MultiThreadedHttpConnectionManager.this);
numConnections++;
@@ -491,6 +494,9 @@
if (hostPool.freeConnections.size() 0) {
connection = (HttpConnection)
hostPool.freeConnections.removeFirst();
freeConnections.remove(connection);
+if (LOG.isDebugEnabled()) {
+LOG.debug(Getting connection for hostConfig: +
hostConfiguration);
+}
}
return connection;
}
@@ -585,7 +591,7 @@
HostConfiguration connectionConfiguration =
configurationForConnection(conn);
if (LOG.isDebugEnabled()) {
-LOG.debug(Freeing connection: + conn);
+LOG.debug(Freeing connection for hostConfig: +
connectionConfiguration);
}
synchronized (this) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 2003-07-22 at 10:15, Juozas Baliuka wrote: http://java.sun.com/products/jdbc/jdbc2_0_1-stdext-javadoc/javax/sql/PooledC onnection.html +1 to implement this interface, but I do not think it can help for broken applications. That is an interface to be implemented by a jdbc driver vendor there is no reason for dbcp to implement it. dbcp.cpdsadapter provides a simple wrapper implementation for old jdbc 1.0 driver implementation. But it is not something a connection pool would normally need to code, it represents a physical connection to the db. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient MultiThreadedHttpConnectionManager.java
mbecke 2003/07/22 18:47:20
Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH
MultiThreadedHttpConnectionManager.java
Log:
Added connection life-cycle debugging.
PR: 21788
Revision ChangesPath
No revision
No revision
1.17.2.1 +10 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java
Index: MultiThreadedHttpConnectionManager.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java,v
retrieving revision 1.17
retrieving revision 1.17.2.1
diff -u -r1.17 -r1.17.2.1
--- MultiThreadedHttpConnectionManager.java 27 Jun 2003 03:20:32 - 1.17
+++ MultiThreadedHttpConnectionManager.java 23 Jul 2003 01:47:20 -
1.17.2.1
@@ -427,6 +427,9 @@
if ((hostPool.numConnections getMaxConnectionsPerHost())
(numConnections getMaxTotalConnections())) {
+if (LOG.isDebugEnabled()) {
+LOG.debug(Allocating new connection for hostConfig: +
hostConfiguration);
+}
connection = new HttpConnection(hostConfiguration);
connection.setHttpConnectionManager(MultiThreadedHttpConnectionManager.this);
numConnections++;
@@ -475,6 +478,9 @@
if (hostPool.freeConnections.size() 0) {
connection = (HttpConnection)
hostPool.freeConnections.removeFirst();
freeConnections.remove(connection);
+if (LOG.isDebugEnabled()) {
+LOG.debug(Getting connection for hostConfig: +
hostConfiguration);
+}
}
return connection;
}
@@ -569,7 +575,7 @@
HostConfiguration connectionConfiguration =
configurationForConnection(conn);
if (LOG.isDebugEnabled()) {
-LOG.debug(Freeing connection: + conn);
+LOG.debug(Freeing connection for hostConfig: +
connectionConfiguration);
}
synchronized (this) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StringUtils.sliceFirstRemainder behavior
Must be linked to which method was which. chomp x: cut off x and everything after it prechomp x:cut off x and everything before it getChomp x:return the inverse of chomp x getPrechomp x: return the inverse of prechomp x chomp - slice [chomp changed to meet perl chomp] prechomp- sliceFirstRemainder getPrechomp - sliceFirst getChomp- sliceRemainder So, sliceFirst and sliceFirstRemainder still have the intent for being inverses so that sliceFirst( s, x ) + sliceFirstRemainder( s, x ) == s. Whether this should still hold though now, I don't know. Although I felt that chomp+getChomp should = s, I always found it made getChomp a bit painful to use as it returned the delimiter itself. I think I was overly impressed with the symmetry. Hen On Wed, 23 Jul 2003, Stephen Colebourne wrote: OK, the current behaviour seems daft to me. Can anyone explain why this is as it is? StringUtils.sliceFirst(abc, ) = abc StringUtils.sliceFirst(abc, d) = StringUtils.sliceFirstRemainder(abc, ) = StringUtils.sliceFirstRemainder(abc, d) = abc I would expect the exact opposite: StringUtils.sliceFirst(abc, ) = StringUtils.sliceFirst(abc, d) = abc StringUtils.sliceFirstRemainder(abc, ) = abc StringUtils.sliceFirstRemainder(abc, d) = I would expect slice first to return the text before the first separator. An empty string is found at position zero, so it should return . Separator d is not found, so everything before it is the whole string. I'd like to change this, but why is it as it is??? Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 3:30 PM Subject: Re: [lang] StringUtils.sliceFirstRemainder behavior Stephen Colebourne wrote: I think I would expect: StringUtils.slice(foo, b) = foo get everything before the last 'b' StringUtils.sliceRemainder(foo, b) = get everything after the last 'b' StringUtils.sliceFirst(foo, b) = get everything before the first 'b' StringUtils.sliceFirstRemainder(foo, b) = foo get everything after the first 'b' slice and sliceRemainder are opposite. The results would be the same for a blank separator. But then I don't use Perl which is where I think these came from. So wait to see if you get any more answers! Stephen I just submitted a patch here http://issues.apache.org/bugzilla/show_bug.cgi?id=21797 that documents current behavior with examples and test cases. Phil - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:50 AM Subject: [lang] StringUtils.sliceFirstRemainder behavior Currently, StringUtils.sliceRemainder(foo, b) = = StringUtils.sliceFirst(foo, b), but StringUtils.sliceRemainder(foo, b) = foo. Is this the intended behavior? Phil - 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] - 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-sandbox/mapper/src/share/org/apache/commons/mapper/jdbc JdbcHelper.java
dgraham 2003/07/22 17:12:28
Modified:mapper/src/share/org/apache/commons/mapper/jdbc
JdbcHelper.java
Log:
Added executeUpdate() method that takes no replacement
parameters for executing things like DELETE FROM table_x.
Revision ChangesPath
1.7 +76 -52
jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper/jdbc/JdbcHelper.java
Index: JdbcHelper.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper/jdbc/JdbcHelper.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JdbcHelper.java 13 Jul 2003 05:54:55 - 1.6
+++ JdbcHelper.java 23 Jul 2003 00:12:28 - 1.7
@@ -81,8 +81,8 @@
public class JdbcHelper {
/**
- * An implementation of StatementPreparer that does nothing. Useful when there
- * are no replacement parameters to be set on the PreparedStatement.
+ * An implementation of StatementPreparer that does nothing. Useful when
+ * there are no replacement parameters to be set on the PreparedStatement.
*/
private static final StatementPreparer NULL_PREPARER = new StatementPreparer() {
public void prepareStatement(PreparedStatement stmt, Object obj)
@@ -107,6 +107,9 @@
}
};
+/**
+ * The DataSource to use for queries.
+ */
protected DataSource ds = null;
/**
@@ -120,10 +123,11 @@
/**
* Executes the given INSERT, UPDATE, or DELETE SQL statement. The
- * statement is executed in it's own transaction that will be committed or
rolled
- * back depending on any SQLExceptions thrown.
+ * statement is executed in it's own transaction that will be committed or
+ * rolled back depending on any SQLExceptions thrown.
* @param sql The SQL statement to execute.
- * @param preparer Initializes the PreparedStatement's IN (ie. '?') parameters.
+ * @param preparer Initializes the PreparedStatement's IN (ie. '?')
+ * parameters.
* @param prepareObject An object to pass to the preparer to setup the
* PreparedStatement.
* @throws MapperException
@@ -165,8 +169,8 @@
/**
* Executes the given INSERT, UPDATE, or DELETE SQL statement. The
- * statement is executed in it's own transaction that will be committed or
rolled
- * back depending on any SQLExceptions thrown.
+ * statement is executed in it's own transaction that will be committed or
+ * rolled back depending on any SQLExceptions thrown.
* @param sql The SQL statement to execute.
* @param params An array of values to fill the sql '?' markers with.
* @throws MapperException
@@ -178,10 +182,10 @@
/**
* Executes the given INSERT, UPDATE, or DELETE SQL statement. The
- * statement is executed in it's own transaction that will be committed or
rolled
- * back depending on any SQLExceptions thrown. This is
- * useful for queries with only one replacement parameter and is the equivalent
of
- * calling executeUpdate(sql, new Object[] { param }).
+ * statement is executed in it's own transaction that will be committed or
+ * rolled back depending on any SQLExceptions thrown. This is
+ * useful for queries with only one replacement parameter and is the
+ * equivalent of calling executeUpdate(sql, new Object[] { param }).
* @param sql The SQL statement to execute.
* @param param An object to fill one sql '?' marker with.
* @throws MapperException
@@ -190,6 +194,19 @@
public int executeUpdate(String sql, Object param) throws MapperException {
return this.executeUpdate(sql, ARRAY_PREPARER, new Object[] { param });
}
+
+/**
+ * Executes the given INSERT, UPDATE, or DELETE SQL statement. The
+ * statement is executed in it's own transaction that will be committed or
+ * rolled back depending on any SQLExceptions thrown. This is
+ * useful for queries without any replacement parameters.
+ * @param sql The SQL statement to execute.
+ * @throws MapperException
+ * @return The number of rows updated.
+ */
+public int executeUpdate(String sql) throws MapperException {
+return this.executeUpdate(sql, NULL_PREPARER, null);
+}
/**
* Executes the given SELECT SQL query and returns a List of results.
@@ -197,8 +214,8 @@
* @param preparer Initializes the PreparedStatement's IN parameters.
* @param prepareObject An object to pass to the preparer to setup the
* PreparedStatement.
- * @param processor The processor used to create the result objects from the
- * ResultSet.
+ * @param processor
Re: [io] some minor enhancements and completed action items
A technique I have used is to deprecate the classes with a clear 'WILL BE DELETED' message. Then delete them a couple of weeks later. Stephen - Original Message - From: __matthewHawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 6:30 PM Subject: Re: [io] some minor enhancements and completed action items Maybe we can create the newly named classes, but leave the old ones and deprecate them? This may be good for the short term, but we will have to think of a strategy for removing them, since it wouldn't make sense to have a 1.0 release with deprecated classes. Jeremias Maerki wrote: Yup, seen them. Will look at them on Thursday or Friday if nobody acts sooner. But the rename will likely provoke some Gump failures. Do we need to inform the dependant projects prior to the renaming or shall we just make it happen and let the others sort it out (IO is not released)? On 22.07.2003 18:07:34 __matthewHawthorne wrote: I submitted patches for some small changes, everything is in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801 Jeremias Maerki - 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: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 2003-07-22 at 10:28, Juozas Baliuka wrote: I agree that this is an education/policy issue. But sometimes you need a stop gap solution to keep something running while the customer fixes the problem. I would like to see this stop gap solution included with the DBCP release. Along with quality docs on how to properly use a db connection pool and a big disclaimer that the recovery of abandoned connections should only be used as a stop gap in an emergency until the customer has time to fix their code. Try to implement yourself and I am sure the time to fix a problem will mean forever and crappers will blame you then server or app will crache. Do you want to blame apache for this code ? This problem redirection will not help, but if you want, you can maintain this crap yourself, but do not try to redirect this problem to apache please. This attitude is not very helpful. I don't see how dbcp supplying the ability to configure a connection pool to reclaim connections is that big of an issue. It adds code complexity, but if the implementation is modified so that it is not central to the rest of the code and the critical bug entered against the current implementation is solved, we should allow it as part of the release. I was for the removal of this code, assuming the contributor had abandoned it and it had bugs no one else wanted to fix. But it is a perfectly valid feature and the original developer is stating he is willing to rewrite it. Is it not possible for many databases to configure an idle timeout? I'm pretty sure this kind of ability is to handle the same sort of badly written client code. Does mysql get blamed if a poorly written application loses a connection because it leaked it and did not close it, but mysql reclaims it. How about if the db admin sets the timeout too low and some normal running process ends up corrupting the data because it held a connection too long. I don't think so; it is important that the configuration options are set appropriately for the apps that will be using the database/connection pool. We are not taking on any responsibility for someone's crappy code by such a feature. Consider that you are using dbcp as your connection pool and your code is error-free. You are awaiting a feature from a partner/subcontractor. The feature runs some reporting queries on an interval of 15 minutes and it is known that the queries generally take about a minute. It turns out the partners code is flawed and you are going to lose money, if you have to wait for a fix and start integration testing again after a delay. There might be all sorts of other remedies to this, but being able to configure the pool to recover the connections in the pool being used by the partners code would be optimal, imo. You can then just continue, or worse case immediately start over on, your integration testing. Features related to connection management are appropriate in a connection pool. Is it inappropriate for tomcat to allow an admin to configure a security policy, since well written code will not do anything it shouldn't? On the implementation. I have not looked closely at the current implementation as it is not used by the pool that I added to dbcp and I was trying to start it as a simple implementation of the latest specification. But it would seem an implementation of this should just maintain a reference to Connection objects that it hands out and then after the allowed time period, it should call Connection.close(). The current jdbc specification states that a Connection object should not be usable after Connection.close() is called and the jdbc2pool implementation does not allow the Connection object to be used after close is called. Note that implementation is not perfect in that it needs to use wrapper implementations of Statement and ResultSet. But the idea is that once Connection.close() is called it should be safe for the pool to use the PooledConnection, which represents the physical connection, to create another Connection object which it can hand out. It doesn't seem like an implementation that just calls Connection.close() needs to be that coupled to the rest of the pool code and a simple event/listener model is not likely to add a bug to the main code. Why is this such a contentious issue? john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
-Original Message- From: John McNally [mailto:[EMAIL PROTECTED] Why is this such a contentious issue? FWIW, because some users have business experience, and some do not. Those who do recognize that business *runs* on stopgap solutions. The fewer of those stopgap solutions you have to write, the better, IMHO. Count me among those who would like to see this ability, but as a separate plugin, or a subclass, etc. Cheers, Laird - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[functor] Minor changes to Algorithms
I have attached some minor changes to Algorithms. You may have already addressed these. 1. The example in the class level java doc, the nested expression, had some issues. 2. Tried to improve the class level javadoc a little. 3. The [EMAIL PROTECTED] javadoc references to Generator were pointing to IfaceGenerator. I was considering changing some of the calls to run() in Algorithms to foreach to possibly enhance clarity. In some methods, like select(), the word run is used 4 times. Maybe gen.run() could change to gen.foreach(). Very minor detail. -jason [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[functor] Minor changes to Algorithms (tar.gz)
Here are the changes I mentioned tar/gzipped. They didn't seem to make it as flat files. -jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
--- Laird J. Nelson [EMAIL PROTECTED] wrote: -Original Message- From: John McNally [mailto:[EMAIL PROTECTED] Why is this such a contentious issue? FWIW, because some users have business experience, and some do not. Those who do recognize that business *runs* on stopgap solutions. The fewer of those stopgap solutions you have to write, the better, IMHO. Your implication that those of us arguing against this feature do not have real business experience has not gone unnoticed. This is especially interesting considering one of the most respected developers around here, Craig McClanahan, is arguing against this feature as well. You presume to know too much about your fellow developer's experiences. I have seen enough bad JDBC code to know that a feature like this is popular. Why should I bother writing good database code if the pool will just cleanup after me? Some developers have chosen to argue from the emotional/purist point of view. I choose to argue from the practical side. A connection pool has absolutely no way of knowing when a connection has been abandoned. If you configure the pool to reclaim connections after x minutes and a new app comes along that needs it for x+1 minutes you will have a *very* confusing bug caused by DBCP. This is absolutely not a DBCP code issue; it is a management issue. Applications that leak resources should have their own separate connection pool. When they run out of connections, only that app will break and won't affect any other applications on the server. It will be much easier to debug the leak in the isolated app because DBCP won't hide it from you and you won't have to search any other apps. So, there is no need for this feature in DBCP if the above process is followed. This makes everyone's life simpler :-). David Count me among those who would like to see this ability, but as a separate plugin, or a subclass, etc. Cheers, Laird - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StringUtils.sliceFirstRemainder behavior
Henri Yandell wrote: Must be linked to which method was which. chomp x: cut off x and everything after it prechomp x:cut off x and everything before it getChomp x:return the inverse of chomp x getPrechomp x: return the inverse of prechomp x chomp - slice [chomp changed to meet perl chomp] prechomp- sliceFirstRemainder getPrechomp - sliceFirst getChomp- sliceRemainder So, sliceFirst and sliceFirstRemainder still have the intent for being inverses so that sliceFirst( s, x ) + sliceFirstRemainder( s, x ) == s. Not exactly true, since neither sliceFirst nor sliceFirstRemainder returns the delimiter, but what is true in the current implementation is that for any strings x, s, t (including null, anywhere) sliceFirst(s^x^t, x) + sliceFirstRemainder(s^x^t, x) = s^t The question is, is this symmetry worth the strange definition (at least strange to me) of sliceFirstRemainder which returns the full string when it does not include the delimiter. My recomendation would be to agree on what it means for x to occur in s in each of the following cases and then make the slice implementations follow their top line definitions based on this consistent (documented, of course :-) definition. In each case, I have put my HO in parens. Basically, my HO just amounts to being consistent with indexOf, lastIndexOf. Javadoc could provide formulas making this explicit. s null (all slices return null) s empty (all slices return ) s nontrivial, x nontrivial, s contains x (natural definitions) s nontrivial, x nontrivial, s does not contain x (there is no first or last occurrence, so all characters before the first occurrence = s and all characters after the last occurrence = ) s nontrivial, x null (s does not contain x, so same as previous) s nontrivial, x empty (s occurs both at the beginning of x and at the end of x, so all characters before the first occurrence = = all characters after the last occurrencce) Sorry to open up this can of worms just now. Bad timing, but good to get it out on the table. I will provide a patch to make and document the changes above if we want to go this route. One important disclaimer: I never bonded with Perl and I have no idea how closely the above defs would match Perl behavior. Phil Whether this should still hold though now, I don't know. Although I felt that chomp+getChomp should = s, I always found it made getChomp a bit painful to use as it returned the delimiter itself. I think I was overly impressed with the symmetry. Hen On Wed, 23 Jul 2003, Stephen Colebourne wrote: OK, the current behaviour seems daft to me. Can anyone explain why this is as it is? StringUtils.sliceFirst(abc, ) = abc StringUtils.sliceFirst(abc, d) = StringUtils.sliceFirstRemainder(abc, ) = StringUtils.sliceFirstRemainder(abc, d) = abc I would expect the exact opposite: StringUtils.sliceFirst(abc, ) = StringUtils.sliceFirst(abc, d) = abc StringUtils.sliceFirstRemainder(abc, ) = abc StringUtils.sliceFirstRemainder(abc, d) = I would expect slice first to return the text before the first separator. An empty string is found at position zero, so it should return . Separator d is not found, so everything before it is the whole string. I'd like to change this, but why is it as it is??? Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 3:30 PM Subject: Re: [lang] StringUtils.sliceFirstRemainder behavior Stephen Colebourne wrote: I think I would expect: StringUtils.slice(foo, b) = foo get everything before the last 'b' StringUtils.sliceRemainder(foo, b) = get everything after the last 'b' StringUtils.sliceFirst(foo, b) = get everything before the first 'b' StringUtils.sliceFirstRemainder(foo, b) = foo get everything after the first 'b' slice and sliceRemainder are opposite. The results would be the same for a blank separator. But then I don't use Perl which is where I think these came from. So wait to see if you get any more answers! Stephen I just submitted a patch here http://issues.apache.org/bugzilla/show_bug.cgi?id=21797 that documents current behavior with examples and test cases. Phil - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:50 AM Subject: [lang] StringUtils.sliceFirstRemainder behavior Currently, StringUtils.sliceRemainder(foo, b) = = StringUtils.sliceFirst(foo, b), but StringUtils.sliceRemainder(foo, b) = foo. Is this the intended behavior? Phil - 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: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: This is absolutely not a DBCP code issue; it is a management issue. Applications that leak resources should have their own separate connection pool. When they run out of connections, only that app will break and won't affect any other applications on the server. It will be much easier to debug the leak in the isolated app because DBCP won't hide it from you and you won't have to search any other apps. So, there is no need for this feature in DBCP if the above process is followed. This makes everyone's life simpler :-). I think business might be replaced with many situations in the real world. I dream of well run projects. Developers who follow processes that make everyone's life easier. Ah, that would be nice. Is there such a land? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
I like innovations, but try to implement and test it at home please. I am sure there are not so many situations in the real world need this feature. It takes a few minutes to find connection leak and to fix it in any applications, doe's not it ? David Graham wrote: This is absolutely not a DBCP code issue; it is a management issue. Applications that leak resources should have their own separate connection pool. When they run out of connections, only that app will break and won't affect any other applications on the server. It will be much easier to debug the leak in the isolated app because DBCP won't hide it from you and you won't have to search any other apps. So, there is no need for this feature in DBCP if the above process is followed. This makes everyone's life simpler :-). I think business might be replaced with many situations in the real world. I dream of well run projects. Developers who follow processes that make everyone's life easier. Ah, that would be nice. Is there such a land? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [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: [DBCP] AbandonedTrace - Connection Recovery
Juozas Baliuka wrote: I like innovations, but try to implement and test it at home please. I am sure there are not so many situations in the real world need this feature. It takes a few minutes to find connection leak and to fix it in any applications, doe's not it ? It does not. I have 2 new clients in the past 3 months (one medium, and one huge highly publicized screwed-up government project) that both have connection leak issues that they have been working at for a long time. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21819] New: - [lang] javadoc fixes (remove @links to non-public identifiers)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21819. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21819 [lang] javadoc fixes (remove @links to non-public identifiers) Summary: [lang] javadoc fixes (remove @links to non-public identifiers) Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Lang AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Fixes a couple of typos and removes @links to some non-public fields/objects - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21819] - [lang] javadoc fixes (remove @links to non-public identifiers)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21819. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21819 [lang] javadoc fixes (remove @links to non-public identifiers) --- Additional Comments From [EMAIL PROTECTED] 2003-07-23 05:26 --- Created an attachment (id=7467) Patch to ObjectUtils, RandomStringUtils, StringEscapeUtils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
This attitude is not very helpful. I don't see how dbcp supplying the ability to configure a connection pool to reclaim connections is that big of an issue. Have you tried to solve problems this way ? Is it tested solution and can be used for high quality software ? Try to implement and test anti patterns at home first. It adds code complexity, but if the implementation is modified so that it is not central to the rest of the code and the critical bug entered against the current implementation is solved, we should allow it as part of the release. I was for the removal of this code, assuming the contributor had abandoned it and it had bugs no one else wanted to fix. But it is a perfectly valid feature and the original developer is stating he is willing to rewrite it. Is it not possible for many databases to configure an idle timeout? I'm pretty sure this kind of ability is to handle the same sort of badly written client code. Does mysql get blamed if a poorly written application loses a connection because it leaked it and did not close it, but mysql reclaims it. It is not a feature too, It breaks transactions, I do not believe it supports autoreconnect if transactions are enabled. How about if the db admin sets the timeout too low and some normal running process ends up corrupting the data because it held a connection too long. I don't think so; it is important that the configuration options are set appropriately for the apps that will be using the database/connection pool. We are not taking on any responsibility for someone's crappy code by such a feature. Consider that you are using dbcp as your connection pool and your code is error-free. You are awaiting a feature from a partner/subcontractor. The feature runs some reporting queries on an interval of 15 minutes and it is known that the queries generally take about a minute. It turns out the partners code is flawed and you are going to lose money, if you have to wait for a fix and start integration testing again after a delay. There might be all sorts of other remedies to this, but being able to configure the pool to recover the connections in the pool being used by the partners code would be optimal, imo. You can then just continue, or worse case immediately start over on, your integration testing. Features related to connection management are appropriate in a connection pool. Is it inappropriate for tomcat to allow an admin to configure a security policy, since well written code will not do anything it shouldn't? On the implementation. I have not looked closely at the current implementation as it is not used by the pool that I added to dbcp and I was trying to start it as a simple implementation of the latest specification. But it would seem an implementation of this should just maintain a reference to Connection objects that it hands out and then after the allowed time period, it should call Connection.close(). The current jdbc specification states that a Connection object should not be usable after Connection.close() is called and the jdbc2pool implementation does not allow the Connection object to be used after close is called. Note that implementation is not perfect in that it needs to use wrapper implementations of Statement and ResultSet. But the idea is that once Connection.close() is called it should be safe for the pool to use the PooledConnection, which represents the physical connection, to create another Connection object which it can hand out. It doesn't seem like an implementation that just calls Connection.close() needs to be that coupled to the rest of the pool code and a simple event/listener model is not likely to add a bug to the main code. Why is this such a contentious issue? john mcnally - 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]
Odd Host Header Problem
Here's an odd heads up for you. I've come across an IIS server which doesn't like: GET /eljconfig.xml HTTP/1.1 User-Agent: test // Note the server interrupts at this point without waiting for the rest of the request Content-HTTP/1.1 500 Server Error Server: Microsoft-IIS/5.0 Date: Tue, 22 Jul 2003 05:50:21 GMT Content-Type: text/html Content-Length: 102 But likes: GET /eljconfig.xml HTTP/1.1 Host: 216.144.36.166 User-Agent: test 200 OK ... It appears that unless the Host header is the first header provided, the server returns a 500 response. No idea why or how they get IIS to do that, but I'll be creating a patch to add the Host header first for our use so if people would like it for HttpClient I can send it through. And in case I haven't mentioned it before - I hate non-compliant servers Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: NTLM Error
Adrian Sutton wrote: Odi, We do need to improve tests, mostly in the area of keeping the connection alive correctly, however we actually do have a test for this particular case (and it passes). There's just something screwy going on and we need to get the original exception out so we can try to track it down. oh do we... I just went through the authenticator test cases before I worte my message but the code is very cryptic. It does not clearly say what algorithm (DES?) is used. As I said, my NTLM knowledge is small... Better test cases all round and particularly with better no-host simulated connections is on my list of things to do. nice to hear that Adrian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Odd Host Header Problem
Adrian Sutton wrote:
+if (!headers[i].getName().equals(Host)) {
Shouldn't this be equalsIgnoreCase() ?
regards,
Roland
DO NOT REPLY [Bug 21788] - please log allocation of new connections to support debugging, testing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21788. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21788 please log allocation of new connections to support debugging, testing --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 08:11 --- Mike, This suggestion does make sense to me. As connection pooling is almost exclusively your department, do you mind taking a look at the patch and checking it in? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868 Exception handling in HttpClient requires redesign --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 10:09 --- Created an attachment (id=7443) Refactoring of authentication, try #2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868 Exception handling in HttpClient requires redesign --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 11:29 --- Oleg, Thanks for looking into this. The patch makes a big improvement to exception handling in authentication. Once question: does [EMAIL PROTECTED](byte[],byte[])} actually work or should it have been [EMAIL PROTECTED] #encrypt(byte[],byte[])}. My JavaDoc skills are really poor but that looks odd to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21788] - please log allocation of new connections to support debugging, testing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21788. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21788 please log allocation of new connections to support debugging, testing [EMAIL PROTECTED] changed: What|Removed |Added CC||commons-httpclient- ||[EMAIL PROTECTED] AssignedTo|commons-httpclient- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 12:17 --- Works for me. I think DEBUG might be more appropriate in this case than TRACE. Thoughts? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729 Allow redirects between hosts and ports --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 12:48 --- Created an attachment (id=7445) Patch 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729 Allow redirects between hosts and ports --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 12:49 --- Here's a first attempt at this refactor. This patch is not complete but I would like some input before I do any major polishing. Here is what's new: - Retry and redirect logic have been moved to a new class, HttpMethodSession. - Header[] getResponseHeaders(String) has been added to HttpMethod. - Support for locking has been added to HttpConnection. This allows the HttpMethodSession to hold on to connections between redirects/retries. - HttpMethodBase.used is now being ignored. Any thoughts on this method. Should this just be depreacted? - realm and proxyRealm have been deprecated in HttpMethodBase as they are now handled in HttpMethodSession. These probably need to be faked. - HttpMethodBase.getRecoverableExceptionCount() has been deprecated. This probably needs to be faked. - a test NoHostHttpConnectionManager has been added. - all of the various tests executing methods directly have been updated. Note: only those that failed have been updated, this needs to be completed. - TestNoHostBase has been added. What has not been done: - ConnectMethod support has not been added. This is my next task. - Robust comments and logging have not been added. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21788] - please log allocation of new connections to support debugging, testing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21788. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21788 please log allocation of new connections to support debugging, testing --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 13:14 --- I agree. I think DEBUG priority is more appropriate in this case Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17947] - Need setURI() methods in HttpMethod interface
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947 Need setURI() methods in HttpMethod interface --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 13:15 --- Any objections to committing this one? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10805] - UnderscoreIsDash http workaround
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10805. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10805 UnderscoreIsDash http workaround --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 13:19 --- Which section of the specs claims that? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17947] - Need setURI() methods in HttpMethodinterface
ok with me [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947 Need setURI() methods in HttpMethod interface --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 13:15 --- Any objections to committing this one? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: RES: NTLM Error
Adrian, The actual stack trace is the following: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/NoPadding at javax.crypto.Cipher.getInstance(DashoA6275) at org.apache.commons.httpclient.auth.NTLM.getCipher(NTLM.java:171) at org.apache.commons.httpclient.auth.NTLM.encrypt(NTLM.java:223) at org.apache.commons.httpclient.auth.NTLM.hashPassword(NTLM.java:520) at org.apache.commons.httpclient.auth.NTLM.getType3Message(NTLM.java:471) at org.apache.commons.httpclient.auth.NTLM.getResponseFor(NTLM.java:157) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:1 94) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:2 27) (...) I neve used JCE before, so I really don´t know its details. To me, the only possible explanation is export restrictions. But DES is a weak algorithm and I didn´t know that there was restrictions upon it. I tried downloading Cryptix JCE Provider and using it. It didn´t work, even with JCE unlimited strength jurisdiction policy files. Cryptix docs says that to use it, we only need to put it in the classpath. However, I think I should tweak the java.policy file, or use some sort of static code to initialize the new providers. I´ll search through the JCE docs... Andre -Mensagem original- De: Adrian Sutton [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 21 de julho de 2003 20:59 Para: Commons HttpClient Project Assunto: Re: RES: NTLM Error On Tuesday, July 22, 2003, at 09:28 AM, Andre Augusto de Oliveira Aragao wrote: Adrian, By the way, I couldn´t find about JCE anywhere in the httpclient home page. Analyzing the log I sent before, I found the following: 2003-07-21 18:41:44,472 [main] DEBUG org.apache.commons.httpclient.HttpClient - SunJCE 1.42: SunJCE Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1) Does it means that httpclient detected JCE correctly?? Hmm, it would seem to have detected it correctly. We're really going to need the actual error message that coming out of the NTLM class then and our current exception handling doesn't seem to provide that. I don't currently have time to do up a test build which prints the exception but if you wouldn't mind grabbing the sources from CVS and trying it yourself, I think you should find the details fairly useful. Essentially, look through org.apache.commons.httpclient.NTLM and make sure it prints out the stack trace for every exception it catches. If not, I can take a better look into this tonight when I get home. It is possible that export policies are biting you here, and it may be worth doing up a simple test app that creates the NTLM type 3 message using the NTLM class or better just tries to encrypt something with DES to see if it works. There are test cases in the source code that will try to generate a type 3 message and they may be quite informative as well. I'd actually try running the tests before modifying the HttpClient code as mentioned above. Andre Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - 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: RES: RES: NTLM Error
Could it be a classloader issue? Are you experiencing this error when running your app in an application server context, through Webstart etc. but not when running it standalone? Odi Andre Augusto de Oliveira Aragao wrote: Adrian, The actual stack trace is the following: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/NoPadding at javax.crypto.Cipher.getInstance(DashoA6275) at org.apache.commons.httpclient.auth.NTLM.getCipher(NTLM.java:171) at org.apache.commons.httpclient.auth.NTLM.encrypt(NTLM.java:223) at org.apache.commons.httpclient.auth.NTLM.hashPassword(NTLM.java:520) at org.apache.commons.httpclient.auth.NTLM.getType3Message(NTLM.java:471) at org.apache.commons.httpclient.auth.NTLM.getResponseFor(NTLM.java:157) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:1 94) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:2 27) [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: RES: RES: NTLM Error
Odi, I just tested it standalone. I didn´t test it using an application server, and my application doesn´t use any special classloader. Andre -Mensagem original- De: Ortwin Glück [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 22 de julho de 2003 10:38 Para: Commons HttpClient Project Assunto: Re: RES: RES: NTLM Error Could it be a classloader issue? Are you experiencing this error when running your app in an application server context, through Webstart etc. but not when running it standalone? Odi Andre Augusto de Oliveira Aragao wrote: Adrian, The actual stack trace is the following: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/NoPadding at javax.crypto.Cipher.getInstance(DashoA6275) at org.apache.commons.httpclient.auth.NTLM.getCipher(NTLM.java:171) at org.apache.commons.httpclient.auth.NTLM.encrypt(NTLM.java:223) at org.apache.commons.httpclient.auth.NTLM.hashPassword(NTLM.java:520) at org.apache.commons.httpclient.auth.NTLM.getType3Message(NTLM.java:471) at org.apache.commons.httpclient.auth.NTLM.getResponseFor(NTLM.java:157) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:1 94) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:2 27) [...] - 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 17947] - Need setURI() methods in HttpMethod interface
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947 Need setURI() methods in HttpMethod interface --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 13:52 --- Go for it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: RES: RES: NTLM Error
Well... Hi... I really had still not tested in REAL standalone mode... I was running it inside Eclipse. I ran it outside Eclipse and it works... It seems to be something related to Eclipse. Sorry for bothering you. Thanks!!! Andre -Mensagem original- De: Andre Augusto de Oliveira Aragao Enviada em: terça-feira, 22 de julho de 2003 10:42 Para: 'Commons HttpClient Project' Assunto: RES: RES: RES: NTLM Error Odi, I just tested it standalone. I didn´t test it using an application server, and my application doesn´t use any special classloader. Andre -Mensagem original- De: Ortwin Glück [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 22 de julho de 2003 10:38 Para: Commons HttpClient Project Assunto: Re: RES: RES: NTLM Error Could it be a classloader issue? Are you experiencing this error when running your app in an application server context, through Webstart etc. but not when running it standalone? Odi Andre Augusto de Oliveira Aragao wrote: Adrian, The actual stack trace is the following: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/NoPadding at javax.crypto.Cipher.getInstance(DashoA6275) at org.apache.commons.httpclient.auth.NTLM.getCipher(NTLM.java:171) at org.apache.commons.httpclient.auth.NTLM.encrypt(NTLM.java:223) at org.apache.commons.httpclient.auth.NTLM.hashPassword(NTLM.java:520) at org.apache.commons.httpclient.auth.NTLM.getType3Message(NTLM.java:471) at org.apache.commons.httpclient.auth.NTLM.getResponseFor(NTLM.java:157) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:1 94) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:2 27) [...] - 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]
URI parsing - strict and tolerant? Re: DO NOT REPLY [Bug 21689] - Exception in get method
- Original Message - --- Additional Comments From [EMAIL PROTECTED] 2003-07-17 15:12 --- Claus, This is a re-thrown exception from a URIException. The colon character (:) must be escaped (%3a) as it delimits the protocol identifier from the host part in a URL. HttpClient is very strict about URIs. IE beeing able to parse this URL only I assume you mean 'strict'is an escaped ones only. means that IE is very tolerant. But HttpClient complies to standards. I assume you mean that 'tolerant' is ok to be dealed with both escaped and unescaped ones. 1st step: an URI is regarded as an escaped one. (only the case currently..) 2nd step: (if URIException reason code is ESCAPING thingy,) it could be as an unescaped one. Then, it's possbile HttpClient to be tolerant about various type of URIs... (Probably, aleady you know though... ) Just let you know, Sung-Gu
When URI object use?l - Re: DO NOT REPLY [Bug 19618] - URI class constructors need revision, optimization
As I see, in the HttpClient project, URI or HttpURL class doesn't apear as an object. That means actually it's enough to ust use URIUtil class about all URI components, I guess - Original Message - From: [EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-07-18 22:44 --- Which just goes to show how confusing this is - Laura just said to assume they were already escaped, and Mike just said they should act as they currently do - not escaped. External interfaces deals with both escaped and unescaped components. Internally, in the class, they are all treated as escaped one always... It doesn't care to be used with which external interface through itself. For the same reason that String.getBytes() is dangerous, my vote would be to force the caller to explicitly indicate which they want. They would *expect* a constructor that takes one String, so they won't look up which one it is until it bites them with an unexpected result. I'd say lets make it easier for our users by forcing them to indicate which it is. String.getBytes is dangerous? But I bet it's certainly the solution for charset encoding thingy. You should't overkook it... Sung-Gu
RES: RES: RES: NTLM Error
Just for the records, when Eclipse detects the JRE, it includes sunjce_provider.jar. Running the app with the default Eclipse JRE renders JCE unusable. But, if you take sunjce_provider.jar out of the list, no problem. Andre -Mensagem original- De: Andre Augusto de Oliveira Aragao Enviada em: terça-feira, 22 de julho de 2003 11:08 Para: 'Commons HttpClient Project' Assunto: RES: RES: RES: NTLM Error Well... Hi... I really had still not tested in REAL standalone mode... I was running it inside Eclipse. I ran it outside Eclipse and it works... It seems to be something related to Eclipse. Sorry for bothering you. Thanks!!! Andre -Mensagem original- De: Andre Augusto de Oliveira Aragao Enviada em: terça-feira, 22 de julho de 2003 10:42 Para: 'Commons HttpClient Project' Assunto: RES: RES: RES: NTLM Error Odi, I just tested it standalone. I didn´t test it using an application server, and my application doesn´t use any special classloader. Andre -Mensagem original- De: Ortwin Glück [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 22 de julho de 2003 10:38 Para: Commons HttpClient Project Assunto: Re: RES: RES: NTLM Error Could it be a classloader issue? Are you experiencing this error when running your app in an application server context, through Webstart etc. but not when running it standalone? Odi Andre Augusto de Oliveira Aragao wrote: Adrian, The actual stack trace is the following: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/NoPadding at javax.crypto.Cipher.getInstance(DashoA6275) at org.apache.commons.httpclient.auth.NTLM.getCipher(NTLM.java:171) at org.apache.commons.httpclient.auth.NTLM.encrypt(NTLM.java:223) at org.apache.commons.httpclient.auth.NTLM.hashPassword(NTLM.java:520) at org.apache.commons.httpclient.auth.NTLM.getType3Message(NTLM.java:471) at org.apache.commons.httpclient.auth.NTLM.getResponseFor(NTLM.java:157) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:1 94) at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:2 27) [...] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21788] - please log allocation of new connections to support debugging, testing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21788. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21788 please log allocation of new connections to support debugging, testing --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 17:30 --- thanks very much -- it's appreciated! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868 Exception handling in HttpClient requires redesign --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 18:14 --- Patch 'Refactoring of authentication, try #2' committed Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17947] - Need setURI() methods in HttpMethod interface
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947 Need setURI() methods in HttpMethod interface [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 18:21 --- Patch committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729
Allow redirects between hosts and ports
--- Additional Comments From [EMAIL PROTECTED] 2003-07-22 18:52 ---
I REALLY like the way things are shaping up. These are those few comments that I
have at the moment
* In particular I like the idea of HttpMethodSession (maybe just HttpSession?).
I would make an interface out of it, however, as in the future we may give users
an option to provide a pluggable custom implementation of the HTTP session.
* I would not deprecate 'used' flag as yet. I helps prevent the user from
executing the same method multiple times and getting ambiguous results. In the
future (3.0) this flag should disappear along with the entire concept of method
recycling.
* I would pass state connection manager as HttpMethodSession's constructor
parameters. We, then, later may completely do away with those setter methods
(setSoTimeout, setConnectionTimeout, setHttpConnectionFactoryTimeout and so on),
as I think we should be using a hash map to store HttpClient preferences instead
of just keeping on extending APIs with all those numerous options. I'll expand
later on this point when we get to discuss the new preferences architecture.
* I would also provide Header[] getRequestHeaders(String) at the very least for
the sake of API completeness.
+if (method instanceof HttpMethodBase) {
+return ((HttpMethodBase) method).getMethodRetryHandler();
+} else {
+return new DefaultMethodRetryHandler();
+}
* IMHO things like that should strongly hint at some design improvements. Do you
think there is way doing without that ugly HttpMethodBase cast? I would suggest
adding getMethodRetryHandler to HttpMethod interface, if there are no other
alternatives
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729 Allow redirects between hosts and ports --- Additional Comments From [EMAIL PROTECTED] 2003-07-22 19:19 --- I added the recoverableExceptionCount for test case purposes. I think deprecating it (or removing it - are we working on 3.0?), would be OK, and the deprecated implementation could return a constant. The only question here would be whether the corresponding test case actually tests the relevant code. Alas, I don't have time this week to look at the patch, so the above is just based on your comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
