cvs commit: jakarta-commons/jelly/src/java/org/apache/commons/jelly JellyContext.java

[dion]

dion2003/07/23 23:43:05

  Modified:jelly/src/java/org/apache/commons/jelly JellyContext.java
  Log:
  Maven exposed issue where a map has a null value and putAll was failing with an NPE
  
  Revision  ChangesPath
  1.45  +8 -2  
jakarta-commons/jelly/src/java/org/apache/commons/jelly/JellyContext.java
  
  Index: JellyContext.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/JellyContext.java,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- JellyContext.java 11 Jul 2003 06:27:07 -  1.44
  +++ JellyContext.java 24 Jul 2003 06:43:05 -  1.45
  @@ -322,9 +322,15 @@
* Sets the Map of variables to use
*/
   public void setVariables(Map variables) {
  -// FIXME: I have seen this fail when the passed Map contains a key, value 
  +// I have seen this fail when the passed Map contains a key, value 
   // pair where the value is null
  -this.variables.putAll( variables );
  +for (Iterator iter = variables.entrySet().iterator(); iter.hasNext();) {
  +Map.Entry element = (Map.Entry) iter.next();
  +if (element.getValue() != null) {
  +this.variables.put(element.getKey(), element.getValue());
  +}
  +}
  +//this.variables.putAll( variables );
   }
   
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

graph2 VisitorAdapter

[Tomasz Skutnik]

Hi.

Here is VisitorAdapter class, which is dummy (no operation) 
implementation of Visitor interface. You know what is it for :)
Please commit.

Scooter.

--

Tomasz Skutnik, R&D Director, www.e-point.pl
tel +48 (22) 853 48 30, mob +48 501 555 705, fax +48 (22) 853 48 30
e-point S.A., ul. Filona 16, 02-658 Warsaw, Poland
PGP/GPG public key: http://scooter.ext.e-point.pl/tomasz.skutnik.gpg

package org.apache.commons.graph.algorithm.search;

import org.apache.commons.graph.Edge;
import org.apache.commons.graph.Graph;
import org.apache.commons.graph.Vertex;

/**
 * Default no-op [EMAIL PROTECTED] Visitor} adapter.
 * 
 * @author Tomasz Skutnik
 */
public class VisitorAdapter implements Visitor {

	public void discoverGraph(Graph graph) { }
	public void discoverVertex(Vertex vertex) { }
	public void discoverEdge(Edge edge) { }
	public void finishEdge(Edge edge) { }
	public void finishVertex(Vertex vertex) {	}
	public void finishGraph(Graph graph) { }

}

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[Juozas Baliuka]

Please do not misunderstand me, it is not a recomendation,
it will not help too, but you can test this workaround at home:

1. before to return from "getConnection" pool sets "currentThread" for
connection.
2. if  !connection.getOwner().isAlive(), it safe to reuse connection.

It must be safe to return the same connection for the same thread for the
most of use cases too.
It can help to hide problem and to crashe later, but it is not *common* way
to solve problems .

- Original Message -
From: "Hope, Matthew" <[EMAIL PROTECTED]>
To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 4:16 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery


>
> > -Original Message-
> > From: Glenn Nielsen [mailto:[EMAIL PROTECTED]
> > Sent: 23 July 2003 13:52
> > To: Jakarta Commons Developers List
> > Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> >
> >
> > Hope, Matthew wrote:
> > > 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).
> > >
> >
> > Using GC to log or recover an abandoned connection won't work
> > because the
> > connection is a member of the pool and will never be eligible for GC.
> >
> > Glenn
>
> I feel you may have missed my comment above to the effect that the pool is
> using a weakly referenced map.
>
> In those circumstances garbage collection would free resources. I would
> think that their use is sensible so long as the pool can handle their
> garbage collection and get another one (though that may have the knock on
> effect of causing the getting of the connection to be synchronized to the
> client request - not a huge big deal in most cases but in a well managed
> resource environment such weak references would be unnecessary.
>
> for an explanation see:
> http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakReference.html
>
> Matt
>
> **
> 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]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[Juozas Baliuka]

Please do not misunderstand me, it is not a recomendation,
it will not help too, but you can test this workaround at home:

1. before to return from "getConnection" pool sets "currentThread" for
connection.
2. if  !connection.getOwner().isAlive(), it safe to reuse connection.

It must be safe to return the same connection for the same thread for the
most of use cases too.
It can help to hide problem and to crashe later, but it is not *common* way
to solve problems .

- Original Message -
From: "Hope, Matthew" <[EMAIL PROTECTED]>
To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 4:16 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery


>
> > -Original Message-
> > From: Glenn Nielsen [mailto:[EMAIL PROTECTED]
> > Sent: 23 July 2003 13:52
> > To: Jakarta Commons Developers List
> > Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> >
> >
> > Hope, Matthew wrote:
> > > 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).
> > >
> >
> > Using GC to log or recover an abandoned connection won't work
> > because the
> > connection is a member of the pool and will never be eligible for GC.
> >
> > Glenn
>
> I feel you may have missed my comment above to the effect that the pool is
> using a weakly referenced map.
>
> In those circumstances garbage collection would free resources. I would
> think that their use is sensible so long as the pool can handle their
> garbage collection and get another one (though that may have the knock on
> effect of causing the getting of the connection to be synchronized to the
> client request - not a huge big deal in most cases but in a well managed
> resource environment such weak references would be unnecessary.
>
> for an explanation see:
> http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakReference.html
>
> Matt
>
> **
> 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]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21809] - [lang] maven-beta10 checkstyle problem

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21809

[lang] maven-beta10 checkstyle problem





--- Additional Comments From [EMAIL PROTECTED]  2003-07-24 05:21 ---
Your suggestion is without a doubt the correct long term solution.  A week or so
ago when maven-b10 was released, I looked into the new checkstyle configuration
format, but didn't have to time to learn the new syntax.  My solution was meant
to be a quick fix until a proper checkstyle.xml could be constructed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[Juozas Baliuka]

Yes, my applications have a lot of bugs too, but I am not ignoring it and I
am not going to break commons
 code  to hide my problems
 .
- Original Message -
From: "John McNally" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 10:54 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery


> >
> > Do not use broken code for production, but it must be possible to solve
> > without broken pool.
> >
> What utopia do you live in?  I think it would be a close approximation
> to say that every piece of software in production use in the world today
> has bugs.  And it is not a broken pool that allows the admin to set an
> idle timeout for connections anymore than it is a broken db that allows
> the same thing.  You can keep calling it broken or crap, but your
> opinion does not matter much to me, have you contributed any code to
> dbcp, do you use it?  I certainly hope not in production because its
> broken according to you.
>
> 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]

DO NOT REPLY [Bug 21809] - [lang] maven-beta10 checkstyle problem

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21809

[lang] maven-beta10 checkstyle problem





--- Additional Comments From [EMAIL PROTECTED]  2003-07-24 04:55 ---
Another way to deal with this problem is to create 

1. an xml config file, checkstyle.xml containing the properties in
checkstyle.properties

2. add a line to your local build.properties file (create one if you aren't
using one) that sets maven.checkstyle.properties = checkstyle.xml. This will
override the setting in project.properties.  

That way, the maven checkstyle plugin will still work for people using the old
version.

I am no maven expert, but the above is working for me.  It would probably be a
good idea for someone to add a good checkstyle.xml to cvs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [lang] StringUtils.sliceFirstRemainder behavior

[Phil Steitz]

Phil Steitz wrote:
[EMAIL PROTECTED] wrote:

from:Phil Steitz <[EMAIL PROTECTED]>
I assume you also agree that all slice functions should fix "", null, 
i.e.,

slice[Xxx](null, *) = null,
slice[Xxx]("", *) = ""


Yes, these seem like the simple cases.

Stephen

OK.  Unless there are objections or someone else commits the changes, I 
will submit a patch this eve (MST, US) to make and document the changes 
discussed above, i,e,



("abc", "z") = no match = end of "abc"
- slice = "abc"
- sliceRemainder = ""
- sliceFirst = "abc"
- sliceFirstRemainder = ""
("abc", "") = first match at start, last match at end
- slice = "abc"
- sliceRemainder = ""
- sliceFirst = ""
- sliceFirstRemainder = "abc"
("abc", null)
??? could mean the same as "", or no match.
No match strikes me as the better choice.

Patch submitted here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=21841

The patch also refactors all of the slice functions to take advantage of 
(and ensure consistency with) StringUtils.indexOf, lastIndexOf.

Phil



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]

DO NOT REPLY [Bug 21841] - [lang] Rationalize StringUtils slice functions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21841

[lang] Rationalize StringUtils slice functions





--- Additional Comments From [EMAIL PROTECTED]  2003-07-24 03:39 ---
Created an attachment (id=7483)
patch to StringUtils, StringUtilsTest

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21841] New: - [lang] Rationalize StringUtils slice functions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21841

[lang] Rationalize StringUtils slice functions

   Summary: [lang] Rationalize StringUtils slice functions
   Product: Commons
   Version: Nightly Builds
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The attached patch modifies the behavior of StringUtils.sliceFirst and
StringUtils.sliceFirstRemainder to consistently handle  pairs
where the delimiter is null, empty or does not occur in the string, as discussed
on the list.

The patch also refactors the slice functions to take advantage of
StringUtils.indexOf and StringUtils.lastIndexOf.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21838] New: - Weird HTML makes the pool example doc hard to read

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21838

Weird HTML makes the pool example doc hard to read

   Summary: Weird HTML makes the pool example doc hard to read
   Product: Commons
   Version: 1.0.1 Final
  Platform: Other
   URL: http://jakarta.apache.org/commons/pool/examples.html
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Pool
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The commons.pool project has an example page,
http://jakarta.apache.org/commons/pool/examples.html
which would be useful but it's hard to read because
the code uses both a  block and many  tags
with vertical whitespace, which makes it kind of look
like abstract poetry instead of a useful example.

The problem could be fixed by not using font tags, or
by changing font tag placement so they cause no vertical
whitespace, or by changing the pre tag to a  tag
block and using  at the end of every line.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VFS] ftp usage problem

[Dyrdahl, Steve]

I have encountered a problem where my starting uri is something similar
to:
ftp://user:[EMAIL PROTECTED]/dir1/dir2/

I would like to be able to do a listing on dir2 to determine what files
exist.  I have privileges to list dir2, but not dir1.  I am using the
resolveFile method which makes no assumption about the type of dir2.  An
attempt is made to list dir1 to determine the type of dir2 which, in my
case, fails.

It seems to me that the interface needs an easy way of allowing the user
to resolve a directory which would skip the is this a directory
checking.  I understand that this is less than clean.  However, the
scenario described above is extremely common.

As a work around, various classes could be made public, but this seems
to be more of a hack.

sd

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[JELLY][PATCH] Focus and Key Listeners added

[Sean W. Ferguson]

Hi,

This is my first ever attempt at a patch.  If I am doing wrong, please 
advise.

The purpose of this patch is to include new functionality in the jelly 
swing tag library.  I added a FocusListenerTag and a KeyListenerTag and 
modified ComponentTag and SwingTagLibrary.  In my zip are these four 
files plus the patchfile.txt

Thanks

Sean


patch.zip
Description: Zip compressed data
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VFS] [PATCH] DefaultFileSystemManager.java StandardFileSystemManager.java

[Dyrdahl, Steve]

For ease of integration, being able to effectively sub-class these two
classes is very useful.


Index: DefaultFileSystemManager.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/
vfs/impl/DefaultFileSystemManager.java,v
retrieving revision 1.22
diff -r1.22 DefaultFileSystemManager.java
115c115
< private boolean init;
---
> protected boolean init;
253c253
< private void setupComponent( final Object component )
---
> protected void setupComponent( final Object component )


Index: StandardFileSystemManager.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/
vfs/impl/StandardFileSystemManager.java,v
retrieving revision 1.13
diff -r1.13 StandardFileSystemManager.java
81c81
< private ClassLoader classLoader;
---
> protected ClassLoader classLoader;
296c296
< private FileProvider createProvider( final String
providerClassName )
---
> protected FileProvider createProvider( final String
providerClassName )

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[lang] Findbugs output for Lang 2.0

[Henri Yandell]

Taking current CVS I get the following as output from the Findbugs
project.

Lang output: http://www.flamefew.net/~hen/lang-2.0-findbugs-output.html
Findbugs:http://www.cs.umd.edu/~pugh/java/bugs/


Just in case anyone's interested :)

Hen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[John McNally]

> 
> Do not use broken code for production, but it must be possible to solve
> without broken pool.
> 
What utopia do you live in?  I think it would be a close approximation
to say that every piece of software in production use in the world today
has bugs.  And it is not a broken pool that allows the admin to set an
idle timeout for connections anymore than it is a broken db that allows
the same thing.  You can keep calling it broken or crap, but your
opinion does not matter much to me, have you contributed any code to
dbcp, do you use it?  I certainly hope not in production because its
broken according to you.

john mcnally


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/modeler build.properties.default build.properties.sample build.xml project.xml STATUS.html

[dims]

dims2003/07/23 13:41:02

  Modified:modeler  build.properties.default build.properties.sample
build.xml project.xml STATUS.html
  Log:
  - Reflect the reality that modeler does not depend on beanutils (or) collections.
  - Ensure that build/test works even when digester jars are absent as this is an 
optional component now.
  
  Revision  ChangesPath
  1.2   +4 -16 jakarta-commons/modeler/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-commons/modeler/build.properties.default,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.properties.default  20 Apr 2003 20:19:58 -  1.1
  +++ build.properties.default  23 Jul 2003 20:41:02 -  1.2
  @@ -11,30 +11,18 @@
   #base.path=../repository
   
   # --
  -#REQUIRED LIBRARIES
  +#OPTIONAL LIBRARIES
   # --
   
  -
  -# - Commons Beanutils, version 1.4 or later -
  -commons-beanutils.home=${base.path}/commons-beanutils-1.6.1
  -commons-beanutils.lib=${commons-beanutils.home}
  -commons-beanutils.jar=${commons-beanutils.lib}/commons-beanutils.jar
  
-commons-beanutils.loc=http://www.apache.org/dist/jakarta/commons/beanutils/binaries/commons-beanutils-1.6.1.tar.gz
  -
  -
  -# - Commons Collections, version 2.0 or later -
  -commons-collections.home=${base.path}/commons-collections-2.1
  -commons-collections.lib=${commons-collections.home}
  -commons-collections.jar=${commons-collections.lib}/commons-collections.jar
  
-commons-collections.loc=http://www.apache.org/dist/jakarta/commons/collections/binaries/collections-2.1.tar.gz
  -
  -
   # - Commons Digester, version 1.4 or later -
   commons-digester.home=${base.path}/commons-digester-1.4.1
   commons-digester.lib=${commons-digester.home}
   commons-digester.jar=${commons-digester.lib}/commons-digester.jar
   
commons-digester.loc=http://www.apache.org/dist/jakarta/commons/digester/binaries/commons-digester-1.4.1.tar.gz
   
  +# --
  +#REQUIRED LIBRARIES
  +# --
   
   # - Commons Logging, version 1.0.1 or later -
   commons-logging.home=${base.path}/commons-logging-1.0.3
  
  
  
  1.2   +0 -4  jakarta-commons/modeler/build.properties.sample
  
  Index: build.properties.sample
  ===
  RCS file: /home/cvs/jakarta-commons/modeler/build.properties.sample,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.properties.sample   30 Apr 2002 20:58:50 -  1.1
  +++ build.properties.sample   23 Jul 2003 20:41:02 -  1.2
  @@ -8,14 +8,10 @@
   jmx.home=/usr/local/jmx-ri_1.0.1/jmx
   
   # Derived home directories
  -beanutils.home=${commons.home}/beanutils
  -collections.home=${commons.home}/collections
   digester.home=${commons.home}/digester
   logging.home=${commons.home}/logging
   
   # Jakarta JAR files
  -commons-beanutils.jar=${beanutils.home}/dist/commons-beanutils.jar
  -commons-collections.jar=${collections.home}/dist/commons-collections.jar
   commons-digester.jar=${digester.home}/dist/commons-digester.jar
   commons-logging.jar=${logging.home}/dist/commons-logging.jar
   
  
  
  
  1.19  +3 -19 jakarta-commons/modeler/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons/modeler/build.xml,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- build.xml 20 Apr 2003 20:37:05 -  1.18
  +++ build.xml 23 Jul 2003 20:41:02 -  1.19
  @@ -25,8 +25,6 @@
 
 
 
  -  
  -  
 
 
 
  @@ -41,8 +39,6 @@
 
 
 
  -  
  -  
 
 
   
  @@ -95,8 +91,6 @@
   
   
   
  -
  -
   
   
   
  @@ -114,8 +108,6 @@
   
   
   
  -
  -
   
   
   
  @@ -160,6 +152,7 @@
   
 
   
  +
   
   
 
 
  +  
   
   
 
 
 
  -
  -
  -
  -  
  -  
  -
  -
  -
  -  
  -  
   
   
   
  
  
  
  1.4   +0 -10 jakarta-commons/modeler/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/modeler/project.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- project.xml   29 Jan 2003 11:40:40 -  1.3
  +++ project.xml   23 Jul 2003 20:41:02 -  1.4
  @@ -25,16 +25,6 @@
 
   
   
  -  commons-beanutils
  -  SNAPSHOT
  -
  -
  -
  -  com

Re: [DBCP] AbandonedTrace - Connection Recovery

[Juozas Baliuka]

- Original Message -
From: "John McNally" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 8:54 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery


> > I get the impression that some of you believe connection cleanup is
> > difficult.  It really is trivial to properly dispose of connections in a
> > finally block.
>
> It is not always trivial.  Yes, you can have some high level try/finally
> block to clean up resources, but you must make sure the code in the
> finally block has access to a Connection reference.

ThreadLocal is used for this stuff.

Obviously, in the
> simple case where the Connection can be borrowed and returned in the
> same method, it is trivial.  Not every case is that easy.
>
> > It's even easier to find problems if you've properly
> > layered the app so the database calls are all in one place.
> >
>
> How do you do that when your application makes use of other components
> written by other teams/companies that have different policies.

Do not use broken code for production, but it must be possible to solve
without broken pool.

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

Re: [DBCP] AbandonedTrace - Connection Recovery

[John McNally]

> 
> Using a weak reference for pooled connections which are in use is a good idea
> and I am all for it.
> 
> The only problem is that there is no guarantee when the weak referenced
> db connection pool object will be GC'd.  That is highly dependent upon
> how the JVM implements GC.  There is no guarantee that this would prevent
> abandoned connections from causing the pool to be exhausted.
> 
> 

I had a case like this just a week ago, where an object that should have
been closed when its use was done, because it was maintaining internally
an open Connection.  The bug never presented itself in our dev
environments because the memory was low enough that gc was closing the
object.  Thankfully the test environments are more similar to production
and the increased memory on those boxes caught the oversight.

john mcnally


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[John McNally]

> I get the impression that some of you believe connection cleanup is
> difficult.  It really is trivial to properly dispose of connections in a
> finally block.  

It is not always trivial.  Yes, you can have some high level try/finally
block to clean up resources, but you must make sure the code in the
finally block has access to a Connection reference.  Obviously, in the
simple case where the Connection can be borrowed and returned in the
same method, it is trivial.  Not every case is that easy.

> It's even easier to find problems if you've properly
> layered the app so the database calls are all in one place.
> 

How do you do that when your application makes use of other components
written by other teams/companies that have different policies.

john mcnally


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [DBCP] AbandonedTrace - Connection Recovery

[Noel J. Bergman]

> That sounds like a better implementation as it is unlikely to timeout
> long running transactions.  But implementing an Observer pattern in
> the Connection, Statement, ResultSet implementations would still allow
> such an implementation, right?

Let me please take advantage of this moment of sanity to point out that
there have been over 100 messages on this topic, and we're still were we
were back on June 29th, when David Graham said "I am open to designing DBCP
in such a way that allows people to plugin the behaviors they need including
reclaming connections (the Strategy pattern may be useful here)."

If anyone can point to any real new ground, I've missed it in the noise.
There has been more spinning on this discussion than in the Tour de France.

Are we agreed that the base functionality will facilitate pluggable
behavior?  If so, let's move on, shall we?  There are other issues worth
discussing, such as the state of logging, and the unfortunate use of
System.out.println ... 

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[John McNally]

> 
> The current implementation recover's the abandoned connection based
> on an inactivity timeout.  So it has to track the last time the
> connection was used.  This more tightly couples it to DBCP.

That sounds like a better implementation as it is unlikely to timeout
long running transactions.  But implementing an Observer pattern in the
Connection, Statement, ResultSet implementations would still allow such
an implementation, right?

john mcnally


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[Glenn Nielsen]

David Graham wrote:
Using a WeakHashMap might be a good solution.  Connections are
guaranteed

to be closed when they are garbage collected so if a client doesn't
return

a connection and loses all pointers to it, the pool would lose its
reference to it and the Connection would get gc'd.  This is *much*
better

than grabbing a connection away from the client application that may
still

be using it.

Using a weak reference for pooled connections which are in use is a good
idea
and I am all for it.
The only problem is that there is no guarantee when the weak referenced
db connection pool object will be GC'd.  That is highly dependent upon
how the JVM implements GC.  There is no guarantee that this would
prevent
abandoned connections from causing the pool to be exhausted.


That's a valid point but unlikely to happen in a highly loaded server JVM
that's creating and destroying many objects.  I think it's sufficient to
say that the pool won't hold onto connections that apps have lost but it's
up to the apps not to lose them in the first place.


It depends on which generation the connection pool object ends up in.
In this case connection pool objects would end up in the GC generation
which is least often swept for GC.  Most likely these objects would only
get GC'd during a Full GC. Full GC's can happen very infrequently, even
on a heavily loaded server if the JVM is tuned right.
Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [DBCP] AbandonedTrace - Connection Recovery

[Hope, Matthew]

the weak reference should be to the true connection object itself or (making
far easier to manage code) the finalize method on the class 'holding' the
actual connection (this is not necessarily the ConnectionWrapper that
manages putting it back in the pool - indeed it would be a good idea not to
be) defers to the real connection and removes it from the pool.

Not guaranteed to work because connection starvation can happen way before
garbage collection can kick in with sufficient force to touch weak
refrences. the generational stuff probably doesn't care about them for
speed...

Matt

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED] 
> Sent: 23 July 2003 15:48
> To: Jakarta Commons Developers List
> Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
> 
> 
> --- "Hope, Matthew" <[EMAIL PROTECTED]> wrote:
> > 
> > > -Original Message-
> > > From: Glenn Nielsen [mailto:[EMAIL PROTECTED] 
> > > Sent: 23 July 2003 13:52
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> > > 
> > > 
> > > Hope, Matthew wrote:
> > > > 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).
> > > > 
> > > 
> > > Using GC to log or recover an abandoned connection won't work 
> > > because the
> > > connection is a member of the pool and will never be 
> eligible for GC.
> > > 
> > > Glenn
> > 
> > I feel you may have missed my comment above to the effect 
> that the pool
> > is
> > using a weakly referenced map.
> 
> Using a WeakHashMap might be a good solution.  Connections 
> are guaranteed
> to be closed when they are garbage collected so if a client 
> doesn't return
> a connection and loses all pointers to it, the pool would lose its
> reference to it and the Connection would get gc'd.  This is 
> *much* better
> than grabbing a connection away from the client application 
> that may still
> be using it.
> 
> What would happen to the connection when it gets closed by garbage
> collection though?  Since it's a pooled connection, calling 
> close() tries
> to return it to the pool but the pool lost its reference to 
> the connection
> when the client didn't return it.  How would the pool ensure the
> connection originated from the pool?
> 
> David
> 
> 
> > 
> > In those circumstances garbage collection would free 
> resources. I would
> > think that their use is sensible so long as the pool can 
> handle their
> > garbage collection and get another one (though that may 
> have the knock
> > on
> > effect of causing the getting of the connection to be 
> synchronized to
> > the
> > client request - not a huge big deal in most cases but in a 
> well managed
> > resource environment such weak references would be unnecessary.
> > 
> > for an explanation see:
> > 
> http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakRefe
rence.html
> 
> Matt
>  
>
**
> 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]
> 


__
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]
 
**
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: jelly build problems...

[Dean Hiller]

thanks for the info and the link.  I finally got all the jars.  'maven 
test' on 1.0 didn't seem to work(test failures due to missing files). 
Checking out just jelly doesn't work either.  I had to check out all of 
commons and then it worked, because it was looking for the commons 
Project.xml.  Is this typical?  Is there a way just to check out jelly 
from cvs and have it work without the commons Project.xml file???
thanks,
dean

Tomasz Pik wrote:

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




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]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [lang] StringUtils.sliceFirstRemainder behavior

[Phil Steitz]

[EMAIL PROTECTED] wrote:
from:Phil Steitz <[EMAIL PROTECTED]>
I assume you also agree that all slice functions should fix "", null, i.e.,
slice[Xxx](null, *) = null,
slice[Xxx]("", *) = ""
Yes, these seem like the simple cases.

Stephen

OK.  Unless there are objections or someone else commits the changes, I 
will submit a patch this eve (MST, US) to make and document the changes 
discussed above, i,e,



("abc", "z") = no match = end of "abc"
- slice = "abc"
- sliceRemainder = ""
- sliceFirst = "abc"
- sliceFirstRemainder = ""
("abc", "") = first match at start, last match at end
- slice = "abc"
- sliceRemainder = ""
- sliceFirst = ""
- sliceFirstRemainder = "abc"
("abc", null)
??? could mean the same as "", or no match.
No match strikes me as the better choice.


Phil



Phil



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[David Graham]

> > Using a WeakHashMap might be a good solution.  Connections are
> guaranteed
> > to be closed when they are garbage collected so if a client doesn't
> return
> > a connection and loses all pointers to it, the pool would lose its
> > reference to it and the Connection would get gc'd.  This is *much*
> better
> > than grabbing a connection away from the client application that may
> still
> > be using it.
> > 
> 
> Using a weak reference for pooled connections which are in use is a good
> idea
> and I am all for it.
> 
> The only problem is that there is no guarantee when the weak referenced
> db connection pool object will be GC'd.  That is highly dependent upon
> how the JVM implements GC.  There is no guarantee that this would
> prevent
> abandoned connections from causing the pool to be exhausted.
> 

That's a valid point but unlikely to happen in a highly loaded server JVM
that's creating and destroying many objects.  I think it's sufficient to
say that the pool won't hold onto connections that apps have lost but it's
up to the apps not to lose them in the first place.

David

> 
> > What would happen to the connection when it gets closed by garbage
> > collection though?  Since it's a pooled connection, calling close()
> tries
> > to return it to the pool but the pool lost its reference to the
> connection
> > when the client didn't return it.  How would the pool ensure the
> > connection originated from the pool?
> > 
> 
> I'm sure that can be worked through.
> 
> > David
> > 
> > 
> > 
> >>In those circumstances garbage collection would free resources. I
> would
> >>think that their use is sensible so long as the pool can handle their
> >>garbage collection and get another one (though that may have the knock
> >>on
> >>effect of causing the getting of the connection to be synchronized to
> >>the
> >>client request - not a huge big deal in most cases but in a well
> managed
> >>resource environment such weak references would be unnecessary.
> >>
> >>for an explanation see:
>
>>http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakReference.html
> >>
> >>Matt
> >> 
> >>
> > 
> >
>
**
> > 
> >>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]
> >>
> > 
> > 
> > 
> > __
> > 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]
> > 
> 
> 
> -- 
> --
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> MOREnet System Programming   |  * if iz ina coment.  |
> Missouri Research and Education Network  |  */   |
> --
> 
> 
> -
> 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]

DO NOT REPLY [Bug 21815] - ftp transfer resume not working with passive mode.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-07-23 13:44 ---
Report looks valid.  I applied the appropriate changes.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/net/src/java/org/apache/commons/net/ftp FTPClient.java

[dfs]

dfs 2003/07/23 06:40:41

  Modified:net/src/java/org/apache/commons/net/ftp FTPClient.java
  Log:
  Applied patch correcting oversight that prevented restart from working
  in passive mode.
  
  Revision  ChangesPath
  1.11  +5 -0  
jakarta-commons/net/src/java/org/apache/commons/net/ftp/FTPClient.java
  
  Index: FTPClient.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/net/src/java/org/apache/commons/net/ftp/FTPClient.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- FTPClient.java18 May 2003 04:03:16 -  1.10
  +++ FTPClient.java23 Jul 2003 13:40:41 -  1.11
  @@ -467,6 +467,11 @@
   __parsePassiveModeReply((String)_replyLines.elementAt(0));
   
   socket = _socketFactory_.createSocket(__passiveHost, __passivePort);
  +if ((__restartOffset > 0) && !restart(__restartOffset))
  +{
  +socket.close();
  +return null;
  +}
   
   if (!FTPReply.isPositivePreliminary(sendCommand(command, arg)))
   {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[Glenn Nielsen]

Juozas Baliuka wrote:
 /**
 * Get a db connection from the pool.
 *
 * If removeAbandoned=true, recovers db connections which
 * have been idle > removeAbandonedTimeout.
 *
 * @return Object jdbc Connection
 */
As I remember we have decided to log stack trace, but not to break pool.
There has been alot of discussion but no consensus has been reached yet
nor has there been a vote.
Is this code released as commons component ?

Yes, the ability to recover abandoned connections was in the DBCP 1.0 release.

Regards,

Glenn

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[Juozas Baliuka]

 /**
 * Get a db connection from the pool.
 *
 * If removeAbandoned=true, recovers db connections which
 * have been idle > removeAbandonedTimeout.
 *
 * @return Object jdbc Connection
 */

As I remember we have decided to log stack trace, but not to break pool.
Is this code released as commons component ?


- Original Message -
From: "Glenn Nielsen" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 2:56 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery


> John McNally wrote:
>
> [snip]
>
> >
> > 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.
> >
>
> The current implementation recover's the abandoned connection based
> on an inactivity timeout.  So it has to track the last time the
> connection was used.  This more tightly couples it to DBCP.
>
> 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]

Re: [lang] StringUtils.sliceFirstRemainder behavior

[scolebourne]

These make sense:

("abc", "z") = no match = end of "abc"
- slice = "abc"
- sliceRemainder = ""
- sliceFirst = "abc"
- sliceFirstRemainder = ""

("abc", "") = first match at start, last match at end
- slice = "abc"
- sliceRemainder = ""
- sliceFirst = ""
- sliceFirstRemainder = "abc"

("abc", null)
??? could mean the same as "", or no match.
No match strikes me as the better choice.

2.0 waits until we sort this

Stephen

>  from:Phil Steitz <[EMAIL PROTECTED]>
> 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" = "")
("abc", "z") 
- slice = "abc"
- sliceRemainder = ""
- sliceFirst = "abc"
- sliceFirstRemainder = ""

> 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]
> 
> >>>
> >>>
> >>>
> >>>
> >>>-
> >>>T

Re: [DBCP] AbandonedTrace - Connection Recovery

[Juozas Baliuka]

> What happens is that the broken app ends up sucking up resources for
> each concurrent request being made to it which is waiting for the
> db connection timeout.  Usually this is set to 5-10 seconds.
> This can suck up alot of resources.  Memory, threads, etc.

Web server with limited request/thread count will hung if app leaks
connections and workarounds will not help, it will hung later, but it can be
a solution for people who want to blame pool and ignore problems in
application.
It moves crap from  application and makes it "reusable component", is not it
? I see no problems if people want to produce crap at home,
but I see no place for "Observers" in DBCP.

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

Re: [DBCP] AbandonedTrace - Connection Recovery

[Glenn Nielsen]

John McNally wrote:

[snip]

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.

The current implementation recover's the abandoned connection based
on an inactivity timeout.  So it has to track the last time the
connection was used.  This more tightly couples it to DBCP.
Regards,

Glenn

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[Glenn Nielsen]

Hope, Matthew wrote:
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).
Using GC to log or recover an abandoned connection won't work because the
connection is a member of the pool and will never be eligible for GC.
Glenn

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DBCP] AbandonedTrace - Connection Recovery

[Glenn Nielsen]

David Graham wrote:
--- "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.


[SNIP]

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 :-).
A web application which leaks db connections until it exhausts its pool
can impact other applications running on the app server.
What happens is that the broken app ends up sucking up resources for
each concurrent request being made to it which is waiting for the
db connection timeout.  Usually this is set to 5-10 seconds.
This can suck up alot of resources.  Memory, threads, etc.
Regards,

Glenn

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Graph2 DFS patch

[David Dixon-Peugh]

Scooter,

I didn't see the patch in your email.  Can you send
it again?

Also, it turns out there are no DFS tests in the 
project.  (It is still in the sandbox after all.)
If you provide one, you will have our undying 
grattitude.

Thanks,

DDP


--- Tomasz Skutnik <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi!
> 
> Here's patch against HEAD version of DFS algorithm
> in
> jakarta-commons-sandbox/graph2 package - it uses
> less memory, which is
> important for very large graphs (as in my case).
> Additionally DFS now
> can use lazy graph implementations without causing
> full, in-memory
> vertex retrieval on search initialization.
> 
> All existing tests passed.
> 
> I've modified only
> org.apache.commons.graph.algorithm.search version,
> didn't touch org.apache.commons.graph.search one -
> is it still used?
> Whever responsible, please apply.
> 
> Scooter
> 
> - --
> 
> Tomasz Skutnik, R&D Director, www.e-point.pl
> tel +48 (22) 853 48 30, mob +48 501 555 705, fax +48
> (22) 853 48 30
> e-point S.A., ul. Filona 16, 02-658 Warsaw, Poland
> PGP/GPG public key:
> http://scooter.ext.e-point.pl/tomasz.skutnik.gpg
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> http://enigmail.mozdev.org
> 
>
iD8DBQE/Hmo6ZH/nE/TPGGQRAso8AJ9YNfI8gOEbiIKKyp/DxVW60wj7UQCeLmlb
> wwC3K22vkyCC+qOVYu9sj8A=
> =h+1P
> -END PGP SIGNATURE-
> 
> >
-
> 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

[Juozas Baliuka]

It is true, some of resource menegement way have  overhead, like Filter for
web application, it closes connection after output is sent and uses
connection too long, but it is not a problem if resources are managed by
controler, it is very trivial to handle with struts.
I use callback interface to manage prepared statements and resultsets.
http://voruta.sourceforge.net this is an exotic framework, I use it myself,
but do not recommend it for production at this time
(experimental).

> I have only had a cursory read through this  - using someone elses
> (hopefully better tested both in unit and real world) implementation is
> better than writing your own...
>
> ...however any system attempting to remove resource cleanup
responsibilites
> from the developer either has to place extremely restrictive constraints
on
> the use or sacrifice optimal resoucre utilization.
>
> if you don't need optimal resource use then or can handle the constraints
> then by all means work within a framework - just remember that if you ever
> change your situation to requiring optimal use or working outside the
> constraints you have a problem.
>
> Matt
>
> > -Original Message-
> > From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
> > Sent: 23 July 2003 11:34
> > To: Jakarta Commons Developers List
> > Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> >
> >
> >
> >
> > You misunderstand me. http://www.springframework.org/ I have
> > never used this
> > framework, but I use the same ideas.
> >
> > > > I did a lot of this kind of bugs myself too and it is very
> > > > trivial to fix.
> > > > 1. Set maxConnections to 1 for testing
> > >
> > > useful
> > >
> > > > 2. Use lazy decorator for connection to throw exeption
> > from "close"
> > > ???
> > > > 3. Use "find/replace" to remove all "}finally{
> > connection.close(); }"
> > > ??!?!?!?!
> > > > 4. Store decorator in ThreadLocal and close connection in
> > > > single place per application.
> > >
> > > Ahhh now I see what you are doing - this then requires
> > maxConnectionsInPool
> > > == max threads or the app will break under heavy load, not
> > IMO a good
> > design
> > > decision.
> > >
> > > > I am sure we are talking about web applications and it is
> > very trivial
> > to
> > > > close connection in controler or to implement Filter for
> > Model 1  web
> > > > application, but this solution works for any kind of
> > > > applications, I use it for JMS too.
> > >
> > >
> > > The simplest way to avoid requiring the use of such approaches or of
> > > abandonded connection reclamation is to do the exacty
> > oppositie of 3. any
> > > call which genuinely brings a connection into active play
> > (get from pool,
> > > use datasource, DriverManager etc should include a finally
> > block closing
> > the
> > > resource. If this is followed there will be no problems
> > with leaks and an
> > > optimal put back in pool strategy is possible. If there is
> > no need for a
> > > call to open a connection it is not opened (you could
> > achieve this on your
> > > method with the lazy decorator but at the cost of maintaing it).
> > >
> > > finally blocks are one of the great benefits of using a
> > modern high level
> > > language - use them.
> > >
> > > If I am reviewing someone else's code I search for every connection
> > opening
> > > and statement creating and require a corresponding finally
> > block to close
> > > them. If I am responsible for quality gating outsourced
> > code I do the
> > same.
> > >
> > > If we purchase a library that does this I will likely never
> > recommend we
> > use
> > > it or that company again...
> > >
> > > I see why people desire a stop gap solution but as this message
> > indicates -
> > > shortcuts to doing proper resource management will be looked for and
> > > (ab)used if they exist - frequently incorrectly...
> > >
> > > Matt
> > >
> > >
> > **
> > 
> > > 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]
> > >
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> *

Re: [lang] StringUtils.sliceFirstRemainder behavior

[Henri Yandell]

On Tue, 22 Jul 2003, Phil Steitz wrote:

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

Nope. I'm +1 to remove it.

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

Good timing.

> One important disclaimer: I never bonded with Perl and I have no idea
> how closely the above defs would match Perl behavior.

Nah, I abused the perl chomp concept to make it more useful to me. Nothing
perl-ish in these methods anymore.

Hen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)

[Danny Angus]

Well I never,
There's been a lot of talk generated by my innocent proposal of using the
Observer pattern, or in more java-esque terms events and listeners to arrive
at a compromise in the Connection Recovery War. I'd like to clarify some
points raised.

In the first place to address the criticism of any compromise being levelled
by Juozas, this was intended not to appeal to one camp or the other, but to
be a neutral proposal which would accomodate both modes of use.
There is nothing in the addition of an event model that should offend either
camp, and properly impelemented users who don't choose to listen for events
should not notice any impact on performance.

Secondly, to address Craig's opinion that we shoudl abandon connection
recovery altogether, I proposed that the existing recovery code be
refactored to be usable as a listener in the event model because there *are*
some users, and some vocal supporters and I would like to think that this
community is not so arrogant that we would remove support for them without
phaseing it out gradually. The listener implementing connection recovery
could be immediately deprecated with text to explain why we don't like it,
and scheduled for removal at the next release, giving people time to make
other arrangements (probably just fork it :) .

Third there are *way* more uses for this than for supporting the forceable
recovery of connections, for instance this could be used to log and trace
pool activity allowing people to attach tools which will help them to
improve their code. It really is much more than just a way in which users
can avoid the responsibility of handling connections correctly.

Finally it allows the DBCP project to have a finite scope. By providing an
API for the attachment of additional functionality we would allow DBCP to
encapsulate JDBC Connection pooling, the implementation would not be the
concern of users nor necessarily of the majority of implementors of
listeners. DBCP could move towards maturity and low maintenance without
restricting the creation of new behaviours and tools.

d.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Graph2 DFS patch

[Tomasz Skutnik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!

Here's patch against HEAD version of DFS algorithm in
jakarta-commons-sandbox/graph2 package - it uses less memory, which is
important for very large graphs (as in my case). Additionally DFS now
can use lazy graph implementations without causing full, in-memory
vertex retrieval on search initialization.
All existing tests passed.

I've modified only org.apache.commons.graph.algorithm.search version,
didn't touch org.apache.commons.graph.search one - is it still used?
Whever responsible, please apply.
Scooter

- --

Tomasz Skutnik, R&D Director, www.e-point.pl
tel +48 (22) 853 48 30, mob +48 501 555 705, fax +48 (22) 853 48 30
e-point S.A., ul. Filona 16, 02-658 Warsaw, Poland
PGP/GPG public key: http://scooter.ext.e-point.pl/tomasz.skutnik.gpg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/Hmo6ZH/nE/TPGGQRAso8AJ9YNfI8gOEbiIKKyp/DxVW60wj7UQCeLmlb
wwC3K22vkyCC+qOVYu9sj8A=
=h+1P
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [DBCP] AbandonedTrace - Connection Recovery

[Hope, Matthew]

I have only had a cursory read through this  - using someone elses
(hopefully better tested both in unit and real world) implementation is
better than writing your own...

...however any system attempting to remove resource cleanup responsibilites
from the developer either has to place extremely restrictive constraints on
the use or sacrifice optimal resoucre utilization.

if you don't need optimal resource use then or can handle the constraints
then by all means work within a framework - just remember that if you ever
change your situation to requiring optimal use or working outside the
constraints you have a problem.

Matt

> -Original Message-
> From: Juozas Baliuka [mailto:[EMAIL PROTECTED] 
> Sent: 23 July 2003 11:34
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> 
> 
> 
> 
> You misunderstand me. http://www.springframework.org/ I have 
> never used this
> framework, but I use the same ideas.
> 
> > > I did a lot of this kind of bugs myself too and it is very
> > > trivial to fix.
> > > 1. Set maxConnections to 1 for testing
> >
> > useful
> >
> > > 2. Use lazy decorator for connection to throw exeption 
> from "close"
> > ???
> > > 3. Use "find/replace" to remove all "}finally{ 
> connection.close(); }"
> > ??!?!?!?!
> > > 4. Store decorator in ThreadLocal and close connection in
> > > single place per application.
> >
> > Ahhh now I see what you are doing - this then requires
> maxConnectionsInPool
> > == max threads or the app will break under heavy load, not 
> IMO a good
> design
> > decision.
> >
> > > I am sure we are talking about web applications and it is 
> very trivial
> to
> > > close connection in controler or to implement Filter for 
> Model 1  web
> > > application, but this solution works for any kind of
> > > applications, I use it for JMS too.
> >
> >
> > The simplest way to avoid requiring the use of such approaches or of
> > abandonded connection reclamation is to do the exacty 
> oppositie of 3. any
> > call which genuinely brings a connection into active play 
> (get from pool,
> > use datasource, DriverManager etc should include a finally 
> block closing
> the
> > resource. If this is followed there will be no problems 
> with leaks and an
> > optimal put back in pool strategy is possible. If there is 
> no need for a
> > call to open a connection it is not opened (you could 
> achieve this on your
> > method with the lazy decorator but at the cost of maintaing it).
> >
> > finally blocks are one of the great benefits of using a 
> modern high level
> > language - use them.
> >
> > If I am reviewing someone else's code I search for every connection
> opening
> > and statement creating and require a corresponding finally 
> block to close
> > them. If I am responsible for quality gating outsourced 
> code I do the
> same.
> >
> > If we purchase a library that does this I will likely never 
> recommend we
> use
> > it or that company again...
> >
> > I see why people desire a stop gap solution but as this message
> indicates -
> > shortcuts to doing proper resource management will be looked for and
> > (ab)used if they exist - frequently incorrectly...
> >
> > Matt
> >
> > 
> **
> 
> > 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]
> >
> >
> 
> 
> -
> 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

[Juozas Baliuka]

Logging is useless in this case,
it is not a problem if it doe's not inspire crap like "autorecovery",
but it was a mistake too and this dicussion proves it, does not it ?

- Original Message -
From: "Hope, Matthew" <[EMAIL PROTECTED]>
To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 10:50 AM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery


a viewpoint I can sympathise with but I don't see how that effects the use
case I outlined below. This is not recovery, it is logging that resources
are not being cleaned up properly...

> -Original Message-
> From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
> Sent: 23 July 2003 09:19
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
>
>
>
> "Connection Recovery" can not help to solve resouce leak and
> performance
> problems, but It can produce more problems.
> I can not let to break stable component to prove it.
>
> - Original Message -
> From: "Hope, Matthew" <[EMAIL PROTECTED]>
> To: "'Jakarta Commons Developers List'"
> <[EMAIL PROTECTED]>
> Sent: Tuesday, July 22, 2003 2:34 PM
> Subject: 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 communicati

Re: Posssible bug in Betwixt alpha

[James Strachan]

Betwixt uses BeanUtils's ConverterUtils to do type conversions. You 
could always register your own special converter object to handle the 
conversion of String -> Date. Though I would have throught this worked 
out of the box as I thought java.util.Date was supported.

Any chance you could create a little test case of a bean & some XML 
that doesn't work correctly and we can add it to the JUnit test cases & 
then fix the problem.

BTW your bean is following the Java beans property naming rules? i.e. 
one getter & one setter with the same type?

On Wednesday, July 23, 2003, at 12:01  am, Ujjwala Kulkarni wrote:

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]
James
---
http://radio.weblogs.com/0112098/

Re: [DBCP] AbandonedTrace - Connection Recovery

[Juozas Baliuka]

You misunderstand me. http://www.springframework.org/ I have never used this
framework, but I use the same ideas.

> > I did a lot of this kind of bugs myself too and it is very
> > trivial to fix.
> > 1. Set maxConnections to 1 for testing
>
> useful
>
> > 2. Use lazy decorator for connection to throw exeption from "close"
> ???
> > 3. Use "find/replace" to remove all "}finally{ connection.close(); }"
> ??!?!?!?!
> > 4. Store decorator in ThreadLocal and close connection in
> > single place per application.
>
> Ahhh now I see what you are doing - this then requires
maxConnectionsInPool
> == max threads or the app will break under heavy load, not IMO a good
design
> decision.
>
> > I am sure we are talking about web applications and it is very trivial
to
> > close connection in controler or to implement Filter for Model 1  web
> > application, but this solution works for any kind of
> > applications, I use it for JMS too.
>
>
> The simplest way to avoid requiring the use of such approaches or of
> abandonded connection reclamation is to do the exacty oppositie of 3. any
> call which genuinely brings a connection into active play (get from pool,
> use datasource, DriverManager etc should include a finally block closing
the
> resource. If this is followed there will be no problems with leaks and an
> optimal put back in pool strategy is possible. If there is no need for a
> call to open a connection it is not opened (you could achieve this on your
> method with the lazy decorator but at the cost of maintaing it).
>
> finally blocks are one of the great benefits of using a modern high level
> language - use them.
>
> If I am reviewing someone else's code I search for every connection
opening
> and statement creating and require a corresponding finally block to close
> them. If I am responsible for quality gating outsourced code I do the
same.
>
> If we purchase a library that does this I will likely never recommend we
use
> it or that company again...
>
> I see why people desire a stop gap solution but as this message
indicates -
> shortcuts to doing proper resource management will be looked for and
> (ab)used if they exist - frequently incorrectly...
>
> Matt
>
> **
> 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]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [DBCP] AbandonedTrace - Connection Recovery

[Hope, Matthew]

a viewpoint I can sympathise with but I don't see how that effects the use
case I outlined below. This is not recovery, it is logging that resources
are not being cleaned up properly...

> -Original Message-
> From: Juozas Baliuka [mailto:[EMAIL PROTECTED] 
> Sent: 23 July 2003 09:19
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> 
> 
> 
> "Connection Recovery" can not help to solve resouce leak and 
> performance
> problems, but It can produce more problems.
> I can not let to break stable component to prove it.
> 
> - Original Message -
> From: "Hope, Matthew" <[EMAIL PROTECTED]>
> To: "'Jakarta Commons Developers List'" 
> <[EMAIL PROTECTED]>
> Sent: Tuesday, July 22, 2003 2:34 PM
> Subject: 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]
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL

RE: [DBCP] AbandonedTrace - Connection Recovery

[Hope, Matthew]

> I did a lot of this kind of bugs myself too and it is very 
> trivial to fix.
> 1. Set maxConnections to 1 for testing

useful

> 2. Use lazy decorator for connection to throw exeption from "close"
???
> 3. Use "find/replace" to remove all "}finally{ connection.close(); }"
??!?!?!?!
> 4. Store decorator in ThreadLocal and close connection in 
> single place per application.

Ahhh now I see what you are doing - this then requires maxConnectionsInPool
== max threads or the app will break under heavy load, not IMO a good design
decision.
 
> I am sure we are talking about web applications and it is very trivial to
> close connection in controler or to implement Filter for Model 1  web
> application, but this solution works for any kind of 
> applications, I use it for JMS too.


The simplest way to avoid requiring the use of such approaches or of
abandonded connection reclamation is to do the exacty oppositie of 3. any
call which genuinely brings a connection into active play (get from pool,
use datasource, DriverManager etc should include a finally block closing the
resource. If this is followed there will be no problems with leaks and an
optimal put back in pool strategy is possible. If there is no need for a
call to open a connection it is not opened (you could achieve this on your
method with the lazy decorator but at the cost of maintaing it).

finally blocks are one of the great benefits of using a modern high level
language - use them.

If I am reviewing someone else's code I search for every connection opening
and statement creating and require a corresponding finally block to close
them. If I am responsible for quality gating outsourced code I do the same.

If we purchase a library that does this I will likely never recommend we use
it or that company again...

I see why people desire a stop gap solution but as this message indicates -
shortcuts to doing proper resource management will be looked for and
(ab)used if they exist - frequently incorrectly...

Matt
 
**
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

[Juozas Baliuka]

"Connection Recovery" can not help to solve resouce leak and performance
problems, but It can produce more problems.
I can not let to break stable component to prove it.

- Original Message -
From: "Hope, Matthew" <[EMAIL PROTECTED]>
To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 2:34 PM
Subject: 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]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]