Re: commons-vfs release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You've got my time if you need it. Push on with getting each one of these moving, and whenever you hit a karma issue, just hit me and I'll deal with patches etc. I'll try to find time to dig into the issues themselves, but far more realistic to have those interested driving things (yourself, vfs, others?). Thank you. Yesterday evening i checked out plexus-archiver, the issues and so on. I see that the issues are not to hard to solve, in fact, 3 issues have a working patch included, 1 must be solved when the API has been cleaned up. So these issues are not a matter by now. The plexus thing is interesting. We can only use few parts of the code. A lot of it is allready in our code, some parts are nice to have, like f.e. war-archiver. A complete merge will need time, but i think we will check out some features and take it over. I looks like we will have a bit other architecture then they have now. Next step (IMHO): - - having the interface working for unpack/pack operations (as simple as possible) - - having examples running Step two: - - having interface for Input/Output Streams I will try to have the first step as soon as possible. Cheers, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDUd4kv8rKBUE/T4RAtPhAJ98aFWyGNmFmN3tnwhzI3z4Cnb4BwCeKU5s r+JJnIsZbEr0zYNkZ/YxuH4= =HBFj -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38873] New: - setCharset() in Email does not set the charset for the message content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38873. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38873 Summary: setCharset() in Email does not set the charset for the message content Product: Commons Version: 1.0 Final Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Email AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hello More accurately, the charset is not used in buildMimeMessage() as it is not part of the contentType used when calling message.setContent(). Since setContentType() updates the charset, I think it makes for setCharset() to update the contentType? James -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Discussing compress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have updated: http://grobmeier.de/commons-compress-draft-2.zip + input/output streams are all in finally-blocks + Examples for the old tar/bzip2 way included + Patch in Bug 30494 included: fixes these examples :-) Cheers, Chris C. Grobmeier wrote: 1) Please take care to always close your input/output streams. ie. do this in a finally() block so that in any case (excpetion) the streams were closed OK, i will check this tonight or tomorrow evening :-) 2) you cant handle directories now, maybe something you have on your todo list? Yes, it's on my TODO, this package should only introduce the direction. 2) The archiver uses java.io.File in its public interface. PLEASE provide Streams too. Internally you can create temp-files or whatever you would like to. So you might have something like OutputStream os = Archiver.createEntry(String pathname); Why? From the view of VFS its simply easier to handle ;-) It would be great if you could handle this in your abstract archiver. I think this should be no problem. I have it on my TODO by now. Regards, Chris - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDUhOkv8rKBUE/T4RAsTBAJ0ReEDicWq80b4GG+l+RUcUGWenKACfdXkh dQ7XcOGowMslJyNPUx1w+6Y= =mbN/ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38067] - [net] FTP - WinZip file downloads are corrupted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38067. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38067 --- Additional Comments From [EMAIL PROTECTED] 2006-03-07 12:14 --- Albert - can you please try again explaining what is the problem you think you see in the existing code that you have pasted in here? You evidently see something here that doesn't look right but it's not at all clear to me what that might be. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Drinking beer in Vienna/Austria
For those of us who can't afford to travel to Austria, is there any chance we can teleconference in for this meeting? I don't want to miss an opportunity/excuse to drink a beer. ;-) -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 3:51 PM To: MyFaces Development; MyFaces Discussion; Jakarta Commons Users List; Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Drinking beer in Vienna/Austria Hi! I'll invite everyone who has some time to a meeting in vienna/austria. Location: Ma Pitom Date: 28.3.2006 Time: 18:30 We have no free stickers, no t-shirts or any other gift, just a meeting to drink a beer - or two - maximum. You meet me (if this is of any interest) and some guys from the myfaces (which might me more interesting ;-) ) team. Please send a PM if you plan to come, just to have an oversight of the number of people to await. See you! Ciao, Mario - 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 38881] New: - Item Iterator found empty in second pass for the same request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38881.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38881
Summary: Item Iterator found empty in second pass for the same
request
Product: Commons
Version: 1.1 Final
Platform: Other
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: File Upload
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
I am using common file upload version 1.1.
I am parsing the reqyest object twice in a servlet. I observed that during
first pass every thing works fine but during second pass the irerator object
is coming as empty.
In other words it appears that you cannot parse the reqyest object for the
second time in a single pass. In second pass it is observed that the method
discardBodyData of MultipartStream class is throwing MalformedStreamException
exception .
Following is the code snippet.
DiskFileItemFactory factory = new DiskFileItemFactory();
ServletFileUpload upload = new ServletFileUpload(factory);
List items = upload.parseRequest(req);
Iterator iter = items.iterator();
while (iter.hasNext())
{
// do some thing
}
I am not sure if this bug is fixed in subsequent release. If so please ignore
this bug and let me know the details.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[compress] Introducing the Compress-Interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, after thinking a lot about the difference of archivers and compressors, i am not sure how to proceed with it. At the moment [1], we have an Archiv Interface. This fits fine for Tar and Zip. If we imagine gunzip or bzip2 as an archive for an single file, we would be fine aswell. For the compression portion, we could have an Archiv::setCompression( new TarCompressor()); method. For Zip we could have Archiv::setCompression( new ZipCompressor()); (just an example, we will not have static methods here!) We could implement a default Compressor for every Component, for example, ZipArchiver would have ZipCompressor as a default, so it's not a must to care about it. A compressor could be used standalone. In case of bzip2 it would be not problem, but how would a zipcompressor act? Archiving simply in zipformat? Having said this i am afraid my thoughts could make everything to complex. On the other hand, this sounds like a good idea for [compress]. Every comment on this important question is welcome. Regards, Chris [1] http://grobmeier.de/commons-compress-draft-2.zip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDZ7Nkv8rKBUE/T4RAnbcAJ9pAEFWFUkaRc5y1HzEMLdTMKDPBgCaAidw nJ6OCUMKp8rm3UeK/rp/KUI= =mx3B -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38881] - [fileupload] Item Iterator found empty in second pass for the same request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38881 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Item Iterator found empty in|[fileupload] Item Iterator |second pass for the same|found empty in second pass |request |for the same request -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38881] - [fileupload] Item Iterator found empty in second pass for the same request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38881 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-03-07 15:09 --- http://jakarta.apache.org/commons/fileupload/faq.html (of particular interest may be question 1 under General section of the FAQ -- during the second parse, the request has already been consumed). Please ask questions on the user list unless you are reasonably sure it is a bug. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] Re: svn commit: r383771 - /jakarta/commons/proper/logging/contrib/simon/jcl2/build.xml
Er, I think I would have to -1 a release without an ant build, so I'm hoping this is temporary :-) Stephen [EMAIL PROTECTED] wrote: Author: skitching Date: Mon Mar 6 20:17:34 2006 New Revision: 383771 URL: http://svn.apache.org/viewcvs?rev=383771view=rev Log: Ant buildfile now obsolete, replaced by maven2 build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons Metadata?
I believe I brought this up before, but I really think there's a need for this. We need a metadata framework which abstracts away the details of exactly how the metadata is found/provided. For example, some applications use only JDK5 annotations to add metadata to their classes. Others might use Jakarta Commons Attributes. Others might want to use XML files (if they don't want to have to touch the source). So, what we could provide is a MetadataFactory (or whatever you want to call it) which can have metadata decorators added to it. The decorators are added to a pipeline and are given a chance to append metadata information to the metadata object. We created something like this for the Trails (www.trailsframework.org) project so that we could use off-the-shelf domain models (how many times have you seen those at Best Buy?) within the framework by providing metadata via XML files as opposed to using JDK5 annotations. We could start this off in the sandbox, of course. Anyone interested in helping out? I could start off developing the core classes (the metatdata holder classes). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Metadata?
On 3/7/06, James Carman [EMAIL PROTECTED] wrote: I believe I brought this up before, but I really think there's a need for this. We need a metadata framework which abstracts away the details of exactly how the metadata is found/provided. For example, some applications use only JDK5 annotations to add metadata to their classes. Others might use Jakarta Commons Attributes. Others might want to use XML files (if they don't want to have to touch the source). So, what we could provide is a MetadataFactory (or whatever you want to call it) which can have metadata decorators added to it. The decorators are added to a pipeline and are given a chance to append metadata information to the metadata object. We created something like this for the Trails (www.trailsframework.org) project so that we could use off-the-shelf domain models (how many times have you seen those at Best Buy?) within the framework by providing metadata via XML files as opposed to using JDK5 annotations. We could start this off in the sandbox, of course. Anyone interested in helping out? I could start off developing the core classes (the metatdata holder classes). +1 That sounds useful, especially if it also can be used at compile time, and if it can work with XDoclet-style Javadoc tags (e.g. using qdox or similar). cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Introducing the Compress-Interface
First, I don't think a compress project does much new. VFS already seems to provide read-only access to common archive types. The JDK comes with read-write support for Zip and Gzip files. And Ant has read-write support for Zip, Tar, Gzip, Bzip2 and maybe others. If you're going to start a new project I think you should plan big and long term. I'd call it [archiver] or something and anticipate support for the basics: .zip and .tar (tgz and tbz2) and plan for possibly supporting other archive formats such as .iso, whatever DVD's use, Microsoft's .cab, .dmg (the Apple disk image), .rar, and obscure archive formats like raw filesystem images (think mount over the loopback in unix). Different formats support different features. Not all allow you to update an existing archive (zip) and some only allow it a few times (.iso can be updated no more than 4 times). .dmg files can be updated so long as it doesn't grow the pre-allocated file. To support all these formats with a mostly unified interface would require a two step process. To create an archive: 1. create a set of files and their dir structure that you will want into an archive. 2. generate the archive with the contents of that file set. To read an archive: 1. figure out what type of archive a file or input stream is (possible autodetect somehow) and create an archive object instance 2. Grab the file set from the archive so you can then get input streams of each file If you have a file set you should be able to: * Pass it to another archive object which can be used to convert from one type to another. * Query if the file set is backed by a updateable archive type and what operations it supports. Then after you've made changes call a saveChanges method. I'd also plan for making the implementations pluggable and discoverable with the service discovery feature introduced in Java 1.2, I think. On 3/7/06, C. Grobmeier [EMAIL PROTECTED] wrote: after thinking a lot about the difference of archivers and compressors, i am not sure how to proceed with it. At the moment [1], we have an Archiv Interface. This fits fine for Tar and Zip. If we imagine gunzip or bzip2 as an archive for an single file, we would be fine aswell. For the compression portion, we could have an Archiv::setCompression( new TarCompressor()); method. For Zip we could have Archiv::setCompression( new ZipCompressor()); (just an example, we will not have static methods here!) We could implement a default Compressor for every Component, for example, ZipArchiver would have ZipCompressor as a default, so it's not a must to care about it. A compressor could be used standalone. In case of bzip2 it would be not problem, but how would a zipcompressor act? Archiving simply in zipformat? Having said this i am afraid my thoughts could make everything to complex. On the other hand, this sounds like a good idea for [compress]. Every comment on this important question is welcome. Regards, Chris [1] http://grobmeier.de/commons-compress-draft-2.zip -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons Metadata?
Well, that's the thing. That's up to the decorator to decide how it gets the metadata information. Jakarta Commons Attributes does a pre-compilation step to set up the .class files so that their attributes can be read from them (from what I can glean from the docs). -Original Message- From: Thomas Dudziak [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 12:57 PM To: Jakarta Commons Developers List Subject: Re: Commons Metadata? On 3/7/06, James Carman [EMAIL PROTECTED] wrote: I believe I brought this up before, but I really think there's a need for this. We need a metadata framework which abstracts away the details of exactly how the metadata is found/provided. For example, some applications use only JDK5 annotations to add metadata to their classes. Others might use Jakarta Commons Attributes. Others might want to use XML files (if they don't want to have to touch the source). So, what we could provide is a MetadataFactory (or whatever you want to call it) which can have metadata decorators added to it. The decorators are added to a pipeline and are given a chance to append metadata information to the metadata object. We created something like this for the Trails (www.trailsframework.org) project so that we could use off-the-shelf domain models (how many times have you seen those at Best Buy?) within the framework by providing metadata via XML files as opposed to using JDK5 annotations. We could start this off in the sandbox, of course. Anyone interested in helping out? I could start off developing the core classes (the metatdata holder classes). +1 That sounds useful, especially if it also can be used at compile time, and if it can work with XDoclet-style Javadoc tags (e.g. using qdox or similar). cheers, Tom - 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 38887] New: - Warning in javascript with firefox 1.5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38887. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38887 Summary: Warning in javascript with firefox 1.5 Product: Commons Version: 1.2 Final Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Validator AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Avertissement : function retrieveFormName does not always return a value -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38887] - Warning in javascript with firefox 1.5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38887. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38887 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2006-03-07 18:59 --- This issue was fixed recently when the change for Bug 38159 was implemented. http://svn.apache.org/viewcvs?rev=366458view=rev You can download and try out the nightly build here: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-validator/ Closing as WORKSFORME -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] lazy load of PADDING in StringUtils and Release
Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, March 05, 2006 11:34 PM To: Jakarta Commons Developers List Subject: [lang] lazy load of PADDING in StringUtils Anyone against switching the PADDING variable to lazily load in the padding function? http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 Hen - 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: [logging] Re: svn commit: r383771 - /jakarta/commons/proper/logging/contrib/simon/jcl2/build.xml
On Tue, 2006-03-07 at 17:01 +, Stephen Colebourne wrote: Er, I think I would have to -1 a release without an ant build, so I'm hoping this is temporary :-) AIUI simon's working in contrib on some ideas for JCL2. the work on the (much delayed) JCL 1.1 release is happening on trunk. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] lazy load of PADDING in StringUtils and Release
I think there is still work in the text package, notably on the formatter. Stephen Gary Gregory wrote: Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, March 05, 2006 11:34 PM To: Jakarta Commons Developers List Subject: [lang] lazy load of PADDING in StringUtils Anyone against switching the PADDING variable to lazily load in the padding function? http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 Hen - 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] lazy load of PADDING in StringUtils and Release
Since no one seems to object I'll commit what I described here shortly: http://issues.apache.org/bugzilla/show_bug.cgi?id=38792#c3 On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, March 05, 2006 11:34 PM To: Jakarta Commons Developers List Subject: [lang] lazy load of PADDING in StringUtils Anyone against switching the PADDING variable to lazily load in the padding function? http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 Hen - 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] -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] lazy load of PADDING in StringUtils and Release
If you commit - remove the cache - its a bad idea - use o.a.c.l.StrBuilder not StringBuffer its non-sync Stephen Sandy McArthur wrote: Since no one seems to object I'll commit what I described here shortly: http://issues.apache.org/bugzilla/show_bug.cgi?id=38792#c3 On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, March 05, 2006 11:34 PM To: Jakarta Commons Developers List Subject: [lang] lazy load of PADDING in StringUtils Anyone against switching the PADDING variable to lazily load in the padding function? http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 Hen - 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] -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - 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] lazy load of PADDING in StringUtils and Release
Ah? It turns out that I want to use the formatter in the text package. The last time I looked at it and added more tests it seemed fine. Is there anything in particular that needs addressing? The unit test coverage from Corbertura is 98% which should be easy to get to 100% Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 12:20 PM To: Jakarta Commons Developers List Subject: Re: [lang] lazy load of PADDING in StringUtils and Release I think there is still work in the text package, notably on the formatter. Stephen Gary Gregory wrote: Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, March 05, 2006 11:34 PM To: Jakarta Commons Developers List Subject: [lang] lazy load of PADDING in StringUtils Anyone against switching the PADDING variable to lazily load in the padding function? http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] lazy load of PADDING in StringUtils and Release
Dunno yet, I'm just starting to go through the issues. Abougt 33% of them are new since the last release I think. Another question - 2.2 or 3.0? Hen On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, March 05, 2006 11:34 PM To: Jakarta Commons Developers List Subject: [lang] lazy load of PADDING in StringUtils Anyone against switching the PADDING variable to lazily load in the padding function? http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38792] - [lang] Memory leak in StringUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38792. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 --- Additional Comments From [EMAIL PROTECTED] 2006-03-07 20:47 --- I think we should let call sites decide whether or not Strings should be interned. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] lazy load of PADDING in StringUtils and Release
On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: If you commit - remove the cache - its a bad idea by cache do you mean PADDING? yea, that is gone. - use o.a.c.l.StrBuilder not StringBuffer its non-sync I actually just now decied it will be fastest to just create and fill a char[] array and then return new String(char[]) that. Stephen Sandy McArthur wrote: Since no one seems to object I'll commit what I described here shortly: http://issues.apache.org/bugzilla/show_bug.cgi?id=38792#c3 On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, March 05, 2006 11:34 PM To: Jakarta Commons Developers List Subject: [lang] lazy load of PADDING in StringUtils Anyone against switching the PADDING variable to lazily load in the padding function? http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 Hen - 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] -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - 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] -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Introducing the Compress-Interface
On 3/7/06, Sandy McArthur [EMAIL PROTECTED] wrote: First, I don't think a compress project does much new. VFS already seems to provide read-only access to common archive types. The JDK comes with read-write support for Zip and Gzip files. And Ant has read-write support for Zip, Tar, Gzip, Bzip2 and maybe others. VFS uses compress for that I thought? JDK has read-entire/write-entire, rather than the ability to add,remove etc. Ant's code is [compress], it was pulled out of there. However, what do people think about: https://truezip.dev.java.net/ It appears to target the compress goals, is an active project(?) with releases, and most importantly uses a sane license (ASL). I'm not sure how much of a one-man show it is; but maybe we could be helping out there rather than trying to create something out of [compress]. Hen Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384017 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Author: sandymac
Date: Tue Mar 7 13:17:46 2006
New Revision: 384017
URL: http://svn.apache.org/viewcvs?rev=384017view=rev
Log:
Removed PADDING cache which leaked memory. Issue #38792.
Updated padding(int,char) JavaDoc about it's I18N incompatabilities.
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java?rev=384017r1=384016r2=384017view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Tue Mar 7 13:17:46 2006
@@ -150,18 +150,6 @@
private static final int PAD_LIMIT = 8192;
/**
- * pAn array of codeString/codes used for padding./p
- *
- * pUsed for efficient space padding. The length of each String expands
as needed./p
- */
-private static final String[] PADDING = new String[Character.MAX_VALUE +
1];
-
-static {
-// space padding is most common, start with 64 chars
-PADDING[32] =
;
-}
-
-/**
* pcodeStringUtils/code instances should NOT be constructed in
* standard programming. Instead, the class should be used as
* codeStringUtils.trim( foo );/code./p
@@ -3515,23 +3503,28 @@
* StringUtils.padding(-2, 'e') = IndexOutOfBoundsException
* /pre
*
+ * pNote: this method doesn't not support padding with
+ * a
href=http://www.unicode.org/glossary/#supplementary_character;Unicode
Supplementary Characters/a
+ * as they require a pair of codechar/codes to be represented.
+ * If you are needing to support full I18N of your applications
+ * consider using [EMAIL PROTECTED] #repeat(String, int)} instead.
+ * /p
+ *
* @param repeat number of times to repeat delim
* @param padChar character to repeat
* @return String with repeated character
* @throws IndexOutOfBoundsException if coderepeat lt; 0/code
+ * @see #repeat(String, int)
*/
-private static String padding(int repeat, char padChar) {
-// be careful of synchronization in this method
-// we are assuming that get and set from an array index is atomic
-String pad = PADDING[padChar];
-if (pad == null) {
-pad = String.valueOf(padChar);
+private static String padding(int repeat, char padChar) throws
IndexOutOfBoundsException {
+if (repeat 0) {
+throw new IndexOutOfBoundsException(Cannot pad a negative amount:
+ repeat);
}
-while (pad.length() repeat) {
-pad = pad.concat(pad);
+final char[] buf = new char[repeat];
+for (int i=0; i buf.length; i++) {
+buf[i] = padChar;
}
-PADDING[padChar] = pad;
-return pad.substring(0, repeat);
+return new String(buf);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38792] - [lang] Memory leak in StringUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38792. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38792 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-03-07 21:22 --- Fix commited. I choose to use a char[] array instead of a StringBuffer but otherwise it's just like what comment #3 describes. http://svn.apache.org/viewcvs?rev=384017view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] Rest of commons
Rahul Akolkar wrote: To the effect of what Hen says later in this thread, its the narrow-deep bits that have been the ugly ducklings, whereas it has been proven sufficient number of times that both categories are extremely useful (for example, think of the number of ASF projects that use digester). Just as its said that Jakarta is multiple communities based on what it has grown into organically, we must also agree Commons has grown into a community that harbors both flavors of components. If this proposal means a departure from the rest of Commons of the part of the community that is interesting only in JLC, then this is a loss. While you (Stephen) may be inclined towards the shallow-broad variety, the fact that the latest usecase for scxml comes out of your slides is still invaluable, IMO. We have to address the future of *all* of Commons in such proposals, I tend to feel they're a tad incomplete otherwise. You asked about the 'rest of commons'. But I don't want to dictate, I really don't. I'd prefer that those who are active in these areas made a couple more groups from the remainder of commons. But, as some people like an example, I'll post one. But its an example. Remember however, that everyone will be working on Jakarta components, its just that some will be in the commons package structure. - Language - Enhancing Java SE lang, collections, io, primitives, beanutils, codec, id, cli +oro, +regexp - Enterprise - Enhancing Java EE (Expertise in Java EE spec issues, classloader issues) logging, email, modeler, launcher, daemon, dbutils, dbcp, pool, el, transaction, fileupload, discovery +taglibs (formerly Jakarta Web Components) - Network - Network protocols, Http, Ftp, ... (Expertise in protocols) net +httpclient (formerly Jakarta Http Components) - Application - Reusable modules validator, chain, configuration, betwixt, digester, jxpath, jelly, vfs, math, jexl, attributes +bcel, +bsf Note that POI, Velocity, Hivemind and Turbine are not included as they may have enough community of their own. I REALLY DIDN'T WANT TO WRITE THIS. I'm not that attached to these names or groups. Whether you like it or loath it isn't really the point of this thread. The point is to indicate how many groups I would aim for (3-5) and one example setup. (The best approach may be to let Jakarta Language Components setup and see if it works!) Its up to those involved in these projects to choose their next steps. And ideally, to change a mindset to working on Jakarta components not commons components. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384022 - /jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
Author: scolebourne Date: Tue Mar 7 13:34:17 2006 New Revision: 384022 URL: http://svn.apache.org/viewcvs?rev=384022view=rev Log: Reword compatibility sectin title Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?rev=384022r1=384021r2=384022view=diff == --- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Tue Mar 7 13:34:17 2006 @@ -15,8 +15,8 @@ and endian transformation classes. -Incompatible changes from 1.1 -- +Compatibility with 1.1 +-- Binary compatible - Yes Source compatible - Yes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33591] - [dbcp] Connection leak in PoolableConnection.close() (Oracle 10g driver)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 --- Additional Comments From [EMAIL PROTECTED] 2006-03-07 21:34 --- We have also experienced this problem at my company. Is the DBCP project dead? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Introducing the Compress-Interface
Henri Yandell wrote: However, what do people think about: https://truezip.dev.java.net/ It doesn't yet have tar support (seems to have a different initial focus than what we are looking for), one developer, zero users (4 messages to the user list, all from the devleoper), and a rapid change of major version numbers seems to indicate it may not be as stable as needed. It appears to target the compress goals, is an active project(?) with releases, and most importantly uses a sane license (ASL). I'm not sure how much of a one-man show it is; but maybe we could be helping out there rather than trying to create something out of [compress]. Compress is stable code that just needs to be made easily reusable. I need to do a review of the last couple of messages, but there are at least 2 or 3 keen people involved. I think it's got promise. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Rest of commons
On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: To the effect of what Hen says later in this thread, its the narrow-deep bits that have been the ugly ducklings, whereas it has been proven sufficient number of times that both categories are extremely useful (for example, think of the number of ASF projects that use digester). Just as its said that Jakarta is multiple communities based on what it has grown into organically, we must also agree Commons has grown into a community that harbors both flavors of components. If this proposal means a departure from the rest of Commons of the part of the community that is interesting only in JLC, then this is a loss. While you (Stephen) may be inclined towards the shallow-broad variety, the fact that the latest usecase for scxml comes out of your slides is still invaluable, IMO. We have to address the future of *all* of Commons in such proposals, I tend to feel they're a tad incomplete otherwise. You asked about the 'rest of commons'. But I don't want to dictate, I really don't. I'd prefer that those who are active in these areas made a couple more groups from the remainder of commons. But, as some people like an example, I'll post one. But its an example. Remember however, that everyone will be working on Jakarta components, its just that some will be in the commons package structure. - Language - Enhancing Java SE lang, collections, io, primitives, beanutils, codec, id, cli +oro, +regexp - Enterprise - Enhancing Java EE (Expertise in Java EE spec issues, classloader issues) logging, email, modeler, launcher, daemon, dbutils, dbcp, pool, el, transaction, fileupload, discovery +taglibs (formerly Jakarta Web Components) - Network - Network protocols, Http, Ftp, ... (Expertise in protocols) net +httpclient (formerly Jakarta Http Components) - Application - Reusable modules validator, chain, configuration, betwixt, digester, jxpath, jelly, vfs, math, jexl, attributes +bcel, +bsf Note that POI, Velocity, Hivemind and Turbine are not included as they may have enough community of their own. They don't. Well, Hivemind does I think, the rest are only different from bcel/bsf in terms of conceived size. I REALLY DIDN'T WANT TO WRITE THIS. I'm not that attached to these names or groups. Whether you like it or loath it isn't really the point of this thread. The point is to indicate how many groups I would aim for (3-5) and one example setup. (The best approach may be to let Jakarta Language Components setup and see if it works!) Someone had to write it, and I suspect if I do any more of these emails that I'll get lynched :) 3-5 seems good (I'd go with the human's can only handle up to 7 choices bit). Its up to those involved in these projects to choose their next steps. And ideally, to change a mindset to working on Jakarta components not commons components. Let's get this on [EMAIL PROTECTED] I've some suggestions for other groupings, but should wait til we get it in front of all of Jakarta. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384025 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Author: rdonkin
Date: Tue Mar 7 13:54:57 2006
New Revision: 384025
URL: http://svn.apache.org/viewcvs?rev=384025view=rev
Log:
Improved diagnostics and added more information to the message thrown when a
custom LogFactory cannot be loaded due to classloader incompatibilities.
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java?rev=384025r1=384024r2=384025view=diff
==
---
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Tue Mar 7 13:54:57 2006
@@ -1101,13 +1101,29 @@
// loading with that loader (not the TCCL). Just throw
an
// appropriate exception here.
+ final boolean implementsLogFactory =
implementsLogFactory(logFactoryClass);
+
+//
+// Construct a good message: users may not actual
expect that a custom implementation
+// has been specified. Several well known containers
use this mechanism to adapt JCL
+// to their native logging system.
+//
String msg =
+ The application has specified that a custom
LogFactory implementation should be used but +
Class ' + factoryClass + ' cannot be converted
to '
-+ LogFactory.class.getName() + '.
-+ Perhaps you have multiple copies of LogFactory
in
-+ the classpath? If so, consider using the
-+ commons-logging-adapters.jar file.;
-
++ LogFactory.class.getName() + '. ;
+if (implementsLogFactory) {
+msg = msg + The conflict is caused by the
presence of multiple LogFactory classes in incompatible classloaders. +
+ Background can be found in
http://jakarta.apache.org/commons/logging/tech.html. +
+ If you have not explicitly specified a custom
LogFactory then it is likely that +
+ the container has set one without your
knowledge. +
+ In this case, consider using the
commons-logging-adapters.jar file or +
+ specifying the standard LogFactory from the
command line. ;
+} else {
+ msg = msg + Please check the custom
implementation. ;
+}
+msg = msg + Help can be found
@http://jakarta.apache.org/commons/logging/troubleshooting.html.;;
+
if (isDiagnosticsEnabled()) {
logDiagnostic(msg);
}
@@ -1171,6 +1187,70 @@
return new LogConfigurationException(e);
}
}
+
+/**
+ * Determines whether the given class actually implements
codeLogFactory/code.
+ * Diagnostic information is also logged.
+ * p
+ * strongUsage:/strong to diagnose whether a classloader conflict is
the cause
+ * of incompatibility. The test used is whether the class is assignable
from
+ * the codeLogFactory/code class loaded by the class's classloader.
+ * @param logFactoryClass codeClass/code which may implement
codeLogFactory/code
+ * @return true if the codeClass/code is assignable from the
+ */
+ private static boolean implementsLogFactory(Class logFactoryClass) {
+ boolean implementsLogFactory = false;
+ if (logFactoryClass != null) {
+ try {
+ ClassLoader logFactoryClassLoader =
logFactoryClass.getClassLoader();
+ if (logFactoryClassLoader == null) {
+ logDiagnostic([CUSTOM LOG FACTORY] was loaded
by the boot classloader);
+ } else {
+ logHierarchy([CUSTOM LOG FACTORY] ,
logFactoryClassLoader);
+ Class factoryFromCustomLoader
+ =
Class.forName(org.apache.commons.logging.LogFactory, false,
logFactoryClassLoader);
+ implementsLogFactory =
factoryFromCustomLoader.isAssignableFrom(logFactoryClass);
+ if (implementsLogFactory) {
+
Re: svn commit: r384025 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
please take a look and check for typo's, bugs etc.
i'm working on something for the troubleshooting documentation about
this.
- robert
On Tue, 2006-03-07 at 21:54 +, [EMAIL PROTECTED] wrote:
Author: rdonkin
Date: Tue Mar 7 13:54:57 2006
New Revision: 384025
URL: http://svn.apache.org/viewcvs?rev=384025view=rev
Log:
Improved diagnostics and added more information to the message thrown when a
custom LogFactory cannot be loaded due to classloader incompatibilities.
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java?rev=384025r1=384024r2=384025view=diff
==
---
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Tue Mar 7 13:54:57 2006
@@ -1101,13 +1101,29 @@
// loading with that loader (not the TCCL). Just
throw an
// appropriate exception here.
+ final boolean implementsLogFactory =
implementsLogFactory(logFactoryClass);
+
+//
+// Construct a good message: users may not actual
expect that a custom implementation
+// has been specified. Several well known containers
use this mechanism to adapt JCL
+// to their native logging system.
+//
String msg =
+ The application has specified that a custom
LogFactory implementation should be used but +
Class ' + factoryClass + ' cannot be
converted to '
-+ LogFactory.class.getName() + '.
-+ Perhaps you have multiple copies of
LogFactory in
-+ the classpath? If so, consider using the
-+ commons-logging-adapters.jar file.;
-
++ LogFactory.class.getName() + '. ;
+if (implementsLogFactory) {
+msg = msg + The conflict is caused by the
presence of multiple LogFactory classes in incompatible classloaders. +
+ Background can be found in
http://jakarta.apache.org/commons/logging/tech.html. +
+ If you have not explicitly specified a custom
LogFactory then it is likely that +
+ the container has set one without your
knowledge. +
+ In this case, consider using the
commons-logging-adapters.jar file or +
+ specifying the standard LogFactory from the
command line. ;
+} else {
+ msg = msg + Please check the custom
implementation. ;
+}
+msg = msg + Help can be found
@http://jakarta.apache.org/commons/logging/troubleshooting.html.;;
+
if (isDiagnosticsEnabled()) {
logDiagnostic(msg);
}
@@ -1171,6 +1187,70 @@
return new LogConfigurationException(e);
}
}
+
+/**
+ * Determines whether the given class actually implements
codeLogFactory/code.
+ * Diagnostic information is also logged.
+ * p
+ * strongUsage:/strong to diagnose whether a classloader conflict is
the cause
+ * of incompatibility. The test used is whether the class is assignable
from
+ * the codeLogFactory/code class loaded by the class's classloader.
+ * @param logFactoryClass codeClass/code which may implement
codeLogFactory/code
+ * @return true if the codeClass/code is assignable from the
+ */
+ private static boolean implementsLogFactory(Class logFactoryClass) {
+ boolean implementsLogFactory = false;
+ if (logFactoryClass != null) {
+ try {
+ ClassLoader logFactoryClassLoader =
logFactoryClass.getClassLoader();
+ if (logFactoryClassLoader == null) {
+ logDiagnostic([CUSTOM LOG FACTORY] was loaded
by the boot classloader);
+ } else {
+ logHierarchy([CUSTOM LOG FACTORY] ,
logFactoryClassLoader);
+ Class factoryFromCustomLoader
+ =
svn commit: r384037 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/FileUtils.java java/org/apache/commons/io/IOUtils.java java/org/apache/commons/io/LineIterator.java test/org/a
Author: scolebourne
Date: Tue Mar 7 14:26:37 2006
New Revision: 384037
URL: http://svn.apache.org/viewcvs?rev=384037view=rev
Log:
Further adjustments to javadoc/implementation of LineIterator
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/LineIteratorTestCase.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?rev=384037r1=384036r2=384037view=diff
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Tue Mar 7 14:26:37 2006
@@ -24,8 +24,6 @@
import java.io.InputStream;
import java.io.OutputStream;
import java.io.UnsupportedEncodingException;
-import java.io.FileReader;
-import java.io.Reader;
import java.net.URL;
import java.util.Collection;
import java.util.Date;
@@ -70,6 +68,7 @@
* @author Chris Eldredge
* @author Jim Harrington
* @author Niall Pemberton
+ * @author Sandy McArthur
* @version $Id$
*/
public class FileUtils {
@@ -925,9 +924,28 @@
/**
* Return an Iterator for the lines in a codeFile/code.
- * This neccessitates creating an InputStream for the file. The only ways
- * to close this stream are to call [EMAIL PROTECTED]
LineIterator#close()} or let
- * the codeLineIterator/code be garbage collected.
+ * p
+ * This method opens an codeInputStream/code for the file.
+ * When you have finished with the iterator you should close the stream
+ * to free internal resources. This can be done by calling the
+ * [EMAIL PROTECTED] LineIterator#close()} or
+ * [EMAIL PROTECTED] LineIterator#closeQuietly(LineIterator)} method.
+ * p
+ * The recommended usage pattern is:
+ * pre
+ * LineIterator it = FileUtils.lineIterator(file, UTF-8);
+ * try {
+ * while (it.hasNext()) {
+ * String line = it.nextLine();
+ * /// do something with line
+ * }
+ * } finally {
+ * LineIterator.closeQuietly(iterator);
+ * }
+ * /pre
+ * p
+ * If an exception occurs during the creation of the iterator, the
+ * underlying stream is closed.
* p
* There is no lineIterator method without encoding parameter because
* the default encoding can differ between platforms and will have
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?rev=384037r1=384036r2=384037view=diff
==
--- jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java
(original)
+++ jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java
Tue Mar 7 14:26:37 2006
@@ -74,6 +74,7 @@
* @author Gareth Davis
* @author Ian Springer
* @author Niall Pemberton
+ * @author Sandy McArthur
* @version $Id$
*/
public class IOUtils {
@@ -509,13 +510,30 @@
//---
/**
* Return an Iterator for the lines in a codeReader/code.
- * Unless you keep a reference to the codeInputStream/code the
- * only way to close it is to call [EMAIL PROTECTED] LineIterator#close()}
or
- * wait for the garbage collector.
+ * p
+ * codeLineIterator/code holds a reference to the open
+ * codeReader/code specified here. When you have finished with the
+ * iterator you should close the reader to free internal resources.
+ * This can be done by closing the reader directly, or by calling the
+ * [EMAIL PROTECTED] #close()} or [EMAIL PROTECTED]
#closeQuietly(LineIterator)} method on
+ * the iterator.
+ * p
+ * The recommended usage pattern is:
+ * pre
+ * try {
+ * LineIterator it = IOUtils.lineIterator(reader);
+ * while (it.hasNext()) {
+ * String line = it.nextLine();
+ * /// do something with line
+ * }
+ * } finally {
+ * IOUtils.closeQuietly(reader);
+ * }
+ * /pre
*
* @param reader the codeReader/code to read from, not null
* @return an Iterator of the lines in the reader, never null
- * @throws NullPointerException if the reader is null
+ * @throws IllegalArgumentException if the reader is null
* @since Commons IO 1.2
*/
public static LineIterator lineIterator(Reader reader) {
@@ -525,14 +543,31 @@
/**
Re: [io] LineIterator suggestions [was: LineIterator finalize]
I made some more adjustments to your checkin. In particular I put the example code back in. I am choosing not to mention garbage collection, as I don't trust our users not to complain. (If a particular user knows enough to leave it to gc then they don't need to docs anyway) I also put closeQuietly back into the tests. Without the try-finally and closeQuietly, a test failure was hidden by other errors. This emphasises the value of the usage pattern to me. I have also added a filter method to LineIterator and made it non-final. Let me know if you still have issues, as I'd like to release. Stephen Stephen Colebourne wrote: Your patch got lost, but perhaps you could commit it and then I'll review. I think I agree with most of your points, but I still want to be able to manually close the iterator, and to have a closeQuietly to help with that (closeQuietly is [io] style) Stephen Sandy McArthur wrote: Attached is the changed I'd make. If no one objects to those changes I can commit it myself. On 3/5/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Sandy McArthur wrote: I don't think LineIterator should have a finalizer method and I believe the JavaDocs in that class about resource leaks are wrong and unnecessarily alarming. How is the javadoc over the top? I'll happily make changes, or go ahead yourself. I checked out the IO trunk and here is what I'd change relating to the current LineIterator: * I think IOIterator should be removed. It's based on the premise that an Iterator needs special action else it will leak resources. Also there is only one implementation of this interface, which doesn't actually leak anything. I don't believe it's utility justify it's existence. Maybe in a later release if you find yourself adding a number of Iterators with a close() method you can add it back in and retro fit LineIterator to implement it. * Don't automatically closing the Reader when the last line is read. The LineIterator potentially breaks being used with the java.io.PushbackReader. PushbackReader lets the Reader backup so to speak but it cannot do that if the Reader is closed. * Either make LineIterator final or change the way hasNext works to allow meaningful subclassing. As hasNext() is currently implemented there is no way for a sub-class that filters lines that only match a regex without reimplementing hasNext() completely. * Remove the static method closeQuietly(LineIterator). I don't think it's useful enough to justify itself. * Change the constructor to throw an IllegalArguementException not a NullPointerException. I personally view an NPE as the result of trying to dereference a field or method of null. The constructor doesn't actually dereference reader, we are testing that the argument reader is a legal and meaningful value to preemptively prevent a future NPE. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - 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: [all] Rest of commons
On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: snip/ If this proposal means a departure from the rest of Commons of the part of the community that is interesting only in JLC, then this is a loss. While you (Stephen) may be inclined towards the shallow-broad variety, the fact that the latest usecase for scxml comes out of your slides is still invaluable, IMO. We have to address the future of *all* of Commons in such proposals, I tend to feel they're a tad incomplete otherwise. You asked about the 'rest of commons'. But I don't want to dictate, I really don't. I'd prefer that those who are active in these areas made a couple more groups from the remainder of commons. snap/ Stephen - I appreciate you taking a stab at this. While I did use an example that had your API style preference in it, it wasn't my intent to put you (or any single person) on the spot at all. As I mentioned, I believe *we* need to think about Commons/Jakarta as a whole -- and JLC isn't declaring victory by itself. Lets hope this thread (and the others already on general@) spawn the beginnings of good things for roC. Again, thank you. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384043 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Author: scolebourne
Date: Tue Mar 7 14:43:39 2006
New Revision: 384043
URL: http://svn.apache.org/viewcvs?rev=384043view=rev
Log:
Fix code style
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java?rev=384043r1=384042r2=384043view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Tue Mar 7 14:43:39 2006
@@ -3521,7 +3521,7 @@
throw new IndexOutOfBoundsException(Cannot pad a negative amount:
+ repeat);
}
final char[] buf = new char[repeat];
-for (int i=0; i buf.length; i++) {
+for (int i = 0; i buf.length; i++) {
buf[i] = padChar;
}
return new String(buf);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33591] - [dbcp] Connection leak in PoolableConnection.close() (Oracle 10g driver)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 --- Additional Comments From [EMAIL PROTECTED] 2006-03-07 22:54 --- Created an attachment (id=17845) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17845action=view) Huw Lewis' change in patch format Not tested beyond regression tests. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33591] - [dbcp] Connection leak in PoolableConnection.close() (Oracle 10g driver)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 --- Additional Comments From [EMAIL PROTECTED] 2006-03-07 22:58 --- There hasn't been a source code change to dbcp in like 12 months. If this patch fixes what seems like a pretty nasty bug, can we get dbcp pushed out to release? Maybe 1.2.2? Thanks! Regards, James -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33591] - [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 [EMAIL PROTECTED] changed: What|Removed |Added Summary|[dbcp] Connection leak in |[dbcp][PATCH] Connection |PoolableConnection.close() |leak in |(Oracle 10g driver) |PoolableConnection.close() ||(Oracle 10g driver) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] VariableFormatter and text package
This class is my main hold-up for release 2.2. Somehow, I just don't
like it. It seems way complex for what it appears to do.
Thats a gut feel reaction however - I can't get my head around the code
easily (another negative).
More specifically, there is no way to substitute the variables in a
StrBuilder, which is kindof the point of the package.
I just wonder if we should rewrite the class much more simply, allowing
it to operate on a StrBuilder. Isn't it just a loop through a map doing
a search and replace on ${key} - value ?
Not sure how others feel about the class.
The other item in the text package is StrBuilder.asTokenizer(). This
method does not cuurrently actually link the tokenizer to the builder
(as the writer/reader do). I think that what should happen is that the
following sequence should work:
Create and populate StrBuilder
Call asTokenizer()
Tokenize
Add text to the builder*
Call StrTokenizer.reset()
Tokenize (and get results including added text*)
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VariableFormatter and text package
As a reference, here is a thread about this class:
http://marc.theaimsgroup.com/?t=11230087692r=1w=2
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 07, 2006 3:04 PM
To: Jakarta Commons Developers List
Subject: [lang] VariableFormatter and text package
This class is my main hold-up for release 2.2. Somehow, I just don't
like it. It seems way complex for what it appears to do.
Thats a gut feel reaction however - I can't get my head around the
code
easily (another negative).
More specifically, there is no way to substitute the variables in a
StrBuilder, which is kindof the point of the package.
I just wonder if we should rewrite the class much more simply,
allowing
it to operate on a StrBuilder. Isn't it just a loop through a map
doing
a search and replace on ${key} - value ?
Not sure how others feel about the class.
The other item in the text package is StrBuilder.asTokenizer(). This
method does not cuurrently actually link the tokenizer to the builder
(as the writer/reader do). I think that what should happen is that the
following sequence should work:
Create and populate StrBuilder
Call asTokenizer()
Tokenize
Add text to the builder*
Call StrTokenizer.reset()
Tokenize (and get results including added text*)
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VariableFormatter and text package
Hello:
Personally, I like the VariableFormatter class and plan on using it in
production. For me, this class is what is motivating me to push for a
2.2 release (3.0 seems like release inflation ;)
I agree that VariableFormatter appears complex, but that is OK to me
given the flexibility it provides. In addition, it works for some fancy
cases as demonstrated in the unit tests.
I recall vaguely being involved in the class' integration into [lang] so
I am happy to talk about it.
If the original author, Oliver Heger, is here, please feel free to pipe
in. I found Oliver very flexible and easy to deal with in the past :)
I just wonder if we should rewrite the class much more simply snip
If someone does this, I would humbly suggest that we refactor with
interfaces such that, at least for development, we can plugin the new
implementation and see if the same tests still pass.
WRT using StrBuilder, I like the idea of eating our own dog food but I
would only do so in this case if there is a real point in doing so. I
could be wrong ;)
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 07, 2006 3:04 PM
To: Jakarta Commons Developers List
Subject: [lang] VariableFormatter and text package
This class is my main hold-up for release 2.2. Somehow, I just don't
like it. It seems way complex for what it appears to do.
Thats a gut feel reaction however - I can't get my head around the
code
easily (another negative).
More specifically, there is no way to substitute the variables in a
StrBuilder, which is kindof the point of the package.
I just wonder if we should rewrite the class much more simply,
allowing
it to operate on a StrBuilder. Isn't it just a loop through a map
doing
a search and replace on ${key} - value ?
Not sure how others feel about the class.
The other item in the text package is StrBuilder.asTokenizer(). This
method does not cuurrently actually link the tokenizer to the builder
(as the writer/reader do). I think that what should happen is that the
following sequence should work:
Create and populate StrBuilder
Call asTokenizer()
Tokenize
Add text to the builder*
Call StrTokenizer.reset()
Tokenize (and get results including added text*)
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang] this.foo() vs. foo()
Hello: This could be a religious issue... look out! In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] this.foo() vs. foo()
Hi Gary, On Wednesday 08 March 2006 10:35, Gary Gregory wrote: Hello: This could be a religious issue... look out! In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. Will this.foo() and foo() always result in the same behaviour, particularly when you're dealing with overridden methods? I ask because I am unsure! How does the list feel about cleaning up foo()'s to this.foo()'s? I personally think that foo() is just fine, especially when calling private helper methods. I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. My (unimportant, meaningless ;) vote is to leave it. Gary Regards, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] this.foo() vs. foo()
Will this.foo() and foo() always result in the same behaviour, particularly when you're dealing with overridden methods? I ask because I am unsure! Yes. I consider the missing receiver a syntactic shortcut which only creates an exception to the simple object.message() syntax. Gary -Original Message- From: James Ring [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 3:46 PM To: Jakarta Commons Developers List Subject: Re: [lang] this.foo() vs. foo() Hi Gary, On Wednesday 08 March 2006 10:35, Gary Gregory wrote: Hello: This could be a religious issue... look out! In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. Will this.foo() and foo() always result in the same behaviour, particularly when you're dealing with overridden methods? I ask because I am unsure! How does the list feel about cleaning up foo()'s to this.foo()'s? I personally think that foo() is just fine, especially when calling private helper methods. I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. My (unimportant, meaningless ;) vote is to leave it. Gary Regards, James - 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] this.foo() vs. foo()
This could be a religious issue... look out! yepp In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? hate it :) cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: [lang] this.foo() vs. foo()
On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. My position is that as you're working on a chunk of code, clean it up to whatever you like but DO NOT go changing code just for cosmetic sake. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] this.foo() vs. foo()
hate it :) Joke and emotion aside, I am interested in what makes programmers take an opinion on topics like this. Could you describe what you like about the one syntax? Could you categorize your POV, perhaps one of: - I do like change - I like foo() because: - I like this.foo() because: - I do not like foo() because: - I do not like this.foo() because: The idea being is this liking one solution vs. just disliking the another solution, etc. Thanks! Gary -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 3:53 PM To: Jakarta Commons Developers List Subject: Re: [lang] this.foo() vs. foo() This could be a religious issue... look out! yepp In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? hate it :) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] this.foo() vs. foo()
On 3/7/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. My position is that as you're working on a chunk of code, clean it up to whatever you like but DO NOT go changing code just for cosmetic sake. I would look at it slightly differently. One of the first principles I learned about open source development was that if I proposed a patch, I should conform to the local style of the code I am patching, no matter what my personal preferences might be ... advice that I still think is appropriate for today. If the committers want to focus on stylistic conformance codebase-wide that's fine (but I try to stand well back from such conversations :-) -- and, if that means changes to existing code, it's preferable that ONLY the cosmetic changes be done at that point. Mixing functional and cosmetic changes makes it much harder to review things. -- Sandy McArthur Craig
Re: [lang] this.foo() vs. foo()
On 3/7/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. My position is that as you're working on a chunk of code, clean it up to whatever you like but DO NOT go changing code just for cosmetic sake. Phil says +1 to the remark above. Of course you could tell it is Phil speaking by the from header and the sig below ;-) Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] this.foo() vs. foo()
My position is that as you're working on a chunk of code, clean it up to whatever you like but DO NOT go changing code just for cosmetic sake. Fair enough. Personally, I like the idea that a release has a uniform look and feel, it give me the feeling that I am dealing with a /coherent whole/, not a bunch of unrelated little piles. This is of course, only based on the look of the code, but it seems important to me, especially when the source is open and part of the public face of the product. My 2c, Gary -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sandy McArthur Sent: Tuesday, March 07, 2006 4:03 PM To: Jakarta Commons Developers List Subject: Re: [lang] this.foo() vs. foo() On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. My position is that as you're working on a chunk of code, clean it up to whatever you like but DO NOT go changing code just for cosmetic sake. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] LineIterator suggestions [was: LineIterator finalize]
On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Let me know if you still have issues, as I'd like to release. No issues. I still have my opinions but until I've conqured the world don't let that hold anything up. :-) -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] this.foo() vs. foo()
On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote:
Hello:
This could be a religious issue... look out!
In our product code bases, we use the this.foo() convention. The
argument being, that in object oriented programming, a message is sent
to an object, always.
How does the list feel about cleaning up foo()'s to this.foo()'s?
For the same reason I'm against mindless javadoc:
/**
* Gets the name
*
* @return the name
*/
public String getName() {
return this.name;
}
I'm also against this.foo() everywhere - it's non-useful noise for the
sake of being right.
--
However, with Java 1.5 the addition of static imports has given us a
reason to want to use it.
this.name() clearly states that it is on this class; while name()
might be pulled from another class.
If I was forced to use static imports (which generally I'm avoiding
like the plague), the above might be a tempting convention as it would
have a use.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] this.foo() vs. foo()
On 08.03.2006, at 11:05, Gary Gregory wrote: hate it :) Joke and emotion aside, I am interested in what makes programmers take an opinion on topics like this. Could you describe what you like about the one syntax? As long as we don't make long winded discussion out of it - sure :) Well, I don't recall having any issues mixing up super.foo() and this.foo() ...so it's just typing overhead. The big ruby wave is just one of the expressions of I want to type less ;) But IMO it's just personal style in the end. And I am usually sticking with the style of the class I am working on ...as long as that style is obvious ;) cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: [lang] this.foo() vs. foo()
On 08.03.2006, at 11:17, Henri Yandell wrote: On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: Hello: This could be a religious issue... look out! In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? For the same reason I'm against mindless javadoc: Could not agree more - see my old blog http://vafer.org/blog/tcurdt/archives/000183.html cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
[Jakarta-commons Wiki] Update of Logging/StaticLog by SimonKitching
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki
for change notification.
The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Logging/StaticLog
The comment on the change is:
Add sections on java.util.logging and on static methods
--
fundamental conflict between isolating logging between applications while
sharing a static Log reference,
and therefore SLF4J faces the same constraints as commons-logging in these
scenarios.
+ == Does java.util.logging have this problem? ==
+
+ Yes. Code using the java.util.logging api can suffer from exactly the issues
listed above, and the
+ recommendation is the same: avoid static references to log objects from code
that might be deployed
+ in a shared classpath.
+
+ The java1.4 java.util.logging package is an API, allowing multiple
implementations of that API.
+ Java runtimes provide one very simple implementation of the API, but
containers such as J2EE servers
+ typically plug in an alternate more sophisticated implementation.
+
+ When using the default implementation, the static problem doesn't exist
because the standard
+ implementation is not container-aware. Of course this has the side-effect of
making per-application
+ configuration impossible for the reasons described earlier.
+
+ When a container provides an implementation that '''is''' container-aware (so
that per-application log
+ configuration is possible), then exactly the same situation occurs: when code
in the shared
+ classpath creates a Log object, it '''must''' be:
+ * initialised with config NOT from any application, or
+ * initialised with config from one of the available applications, or
+ * a proxy that determines the appropriate config each time a method is called
+
+ As described above, the first gives no per-app config, the second misdirects
logging to the
+ wrong app when called from a different application, and the third is
extremely inefficient.
+
+ So just as for commons-logging and SLF4J, it is necessary to avoid static Log
objects
+ when using java.util.logging unless you '''know''' that the underlying
implementation that
+ will be available at runtime is not container-aware.
+
+ Just to be completely clear: this only applies to code deployed via a
classloader that is shared
+ across multiple independent applications. None of this discussion is
relevant to
+ normal application code, or to library code that is never deployed into a
shared classpath.
+ These categories of code can safely use static references.
+
== Alternatives to static loggers ==
In most cases, simply leaving out the static qualifier from the Log
reference is the correct solution.
@@ -153, +186 @@
Note that this applies only to code that may be deployed in a shared
!ClassLoader. Normal application code
need not be concerned with this issue at all.
+
+ == What about static methods? ==
+
+ When Log objects are not static then logging from static methods presents a
particular problem.
+
+ In general, calling !LogFactory.getLog within the static method is the
appropriate solution:
+ {{{
+ public static void doStuff(...) {
+ Log log = LogFactory.getLog(stuff);
+ log.warn(...);
+ }
+ }}}
+
+ If the static method has a reference to some object that it could retrieve a
logger from it, eg
+ {{{
+ public static void doStuff(AppContext context, ...) {
+ context.getStuffLog().warn(oops);
+ }
+ }}}
+ This doesn't seem widely applicable though. Fancier solutions like retrieving
log objects from a
+ collection in a thread-local variableare probably not worth trying; the
!LogFactory.getLog method
+ isn't ''that'' slow.
== Container-assisted logging ==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] this.foo() vs. foo()
How does the list feel about cleaning up foo()'s to this.foo()'s? IMO, a waste of time. Java isn't Smalltalk, and this isn't self. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Re: svn commit: r383771 - /jakarta/commons/proper/logging/contrib/simon/jcl2/build.xml
On Tue, 2006-03-07 at 20:15 +, robert burrell donkin wrote: On Tue, 2006-03-07 at 17:01 +, Stephen Colebourne wrote: Er, I think I would have to -1 a release without an ant build, so I'm hoping this is temporary :-) AIUI simon's working in contrib on some ideas for JCL2. the work on the (much delayed) JCL 1.1 release is happening on trunk. Yep, as Robert says this removal of the ant build.xml was only for my experimental code. It was removed mainly because it is currently broken and as the mvn2 build works I can't be bothered fixing it right now. However I personally don't see any reason why we would want an ant buildfile for JCL2 if the maven one works fine (and it uses the appropriate JDKs to do the actual compile and test steps). Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] this.foo() vs. foo()
On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/7/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. My position is that as you're working on a chunk of code, clean it up to whatever you like but DO NOT go changing code just for cosmetic sake. Phil says +1 to the remark above. Of course you could tell it is Phil speaking by the from header and the sig below ;-) Phil Seriously, Craig makes an important point as does Gary (about the code being public). I should not have responded categorically. I personally do not agree in this case, but agree that style changes are OK if community (meaning those actually maintaining the code base) agree. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384095 - /jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/CharEncodingTest.java
Author: ggregory
Date: Tue Mar 7 18:25:50 2006
New Revision: 384095
URL: http://svn.apache.org/viewcvs?rev=384095view=rev
Log:
Cobertura unit test coverage is now 100%.
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/CharEncodingTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/CharEncodingTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/CharEncodingTest.java?rev=384095r1=384094r2=384095view=diff
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/CharEncodingTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/CharEncodingTest.java
Tue Mar 7 18:25:50 2006
@@ -44,6 +44,13 @@
assertTrue(Encoding should be supported: + name,
CharEncoding.isSupported(name));
}
+/**
+ * The class can be instantiated.
+ */
+public void testConstructor() {
+new CharEncoding();
+}
+
public void testMustBeSupportedJava1_3_1() {
if (SystemUtils.isJavaVersionAtLeast(1.3f)) {
this.assertSupportedEncoding(CharEncoding.ISO_8859_1);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] Jumping in...
There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. I plan to start with http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 I would appreciate any feedback that community members have on prioritization of open tickets. Also, as always, tickets with patches and test cases are likely to get addressed quicker and comments / testing / feedback are always welcome. Any help from other commons committers, even if just in the form of screams, will be most appreciated. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
Hi Phil, On Wednesday 08 March 2006 13:32, Phil Steitz wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. I plan to start with http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 Here here! I'm not a committer, but I would really like to see some of this backlog cleared. Especially with regards to 33591, which has had a fix available for a while and which is quite a nasty one. I would appreciate any feedback that community members have on prioritization of open tickets. Also, as always, tickets with patches and test cases are likely to get addressed quicker and comments / testing / feedback are always welcome. Any help from other commons committers, even if just in the form of screams, will be most appreciated. There haven't been any code changes in over twelve months. It would be nice to fix the outstanding issues and then push out a bugfix release. Phil Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
On 3/7/06, James Ring [EMAIL PROTECTED] wrote: Hi Phil, On Wednesday 08 March 2006 13:32, Phil Steitz wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. I plan to start with http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 Here here! I'm not a committer, but I would really like to see some of this backlog cleared. Especially with regards to 33591, which has had a fix available for a while and which is quite a nasty one. Thanks in advance for your help. On 33591 specifically, any comments that you have on which of the solutions in the ticket is cleanest / safest would be appreciated. I am testing your patch now, but am also evaluating Dirk's. A test case showing the leak (i.e. fails with current code) would also be great. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
Hi Phil, On Wednesday 08 March 2006 14:07, Phil Steitz wrote: Thanks in advance for your help. On 33591 specifically, any comments that you have on which of the solutions in the ticket is cleanest / safest would be appreciated. I am testing your patch now, but am also evaluating Dirk's. A test case showing the leak (i.e. fails with current code) would also be great. Ok, if nobody else submits one before tonight (12 hours or so), I'll try and come up with a test case. I wish my day job would pay me to work on Commons. ;-) Phil Thanks for your time. Regards, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
I'm not familar with the dbcp codebase yet but near the release of Pool 2.0 it is my intention to get familar with it and make sure it works well with the semantic changes. Maybe also switch dbcp to the composite pool impl if that is acceptable to everyone. In the mean go for it. On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. I plan to start with http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 I would appreciate any feedback that community members have on prioritization of open tickets. Also, as always, tickets with patches and test cases are likely to get addressed quicker and comments / testing / feedback are always welcome. Any help from other commons committers, even if just in the form of screams, will be most appreciated. Phil -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. +1 (and thanks) for Phil stepping up to the plate! Craig
Re: [lang] this.foo() vs. foo()
On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/7/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/7/06, Gary Gregory [EMAIL PROTECTED] wrote: In our product code bases, we use the this.foo() convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? I am willing to do this clean up, actually, I'll let Eclipse do it ;) Or, we can leave it all as is, with some classes doing it one way and others the other way. My position is that as you're working on a chunk of code, clean it up to whatever you like but DO NOT go changing code just for cosmetic sake. Phil says +1 to the remark above. Of course you could tell it is Phil speaking by the from header and the sig below ;-) Phil Seriously, Craig makes an important point as does Gary (about the code being public). I should not have responded categorically. I personally do not agree in this case, but agree that style changes are OK if community (meaning those actually maintaining the code base) agree. Phil I don't think there should ever be a sweeping code reformat if for no other reason than it obscures how recently a block of code has been reviewed by `svn blame`. I try to make commits that only change lines that I've thought about and will own up to regardles if they end up being good or bad. Back to the original post, my preference is against this.foo() because I'd bet the compiler generates more bytecode for the this. and because it doesn't really add anything unless you are using a text editor without syntax highlight and other built in Java intelligence. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] LineIterator suggestions [was: LineIterator finalize]
Stephen Colebourne wrote: snip I also put closeQuietly back into the tests. Without the try-finally and closeQuietly, a test failure was hidden by other errors. This emphasises the value of the usage pattern to me. (non-binding) +1 to retaining closeQuietly. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
On 3/7/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. +1 (and thanks) for Phil stepping up to the plate! +1. Let me know how I can help. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33591] - [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 05:24 --- Created an attachment (id=17846) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17846action=view) Possible testcase to illustrate bug Hi there, The testPoolableConnectionLeak method in this test case *may* illustrate the bug. It shows that the connection pool has a getNumActive() equal to 1 even after calling PoolableConnection.close() with already closed delegate connection. Applying Huw's patch shows no active objects in the connection pool after the connection is closed. This is what I'd *expect* to happen, but correct me if I'm wrong... I am new to DBCP and I might not completely understand the issue, so if somebody with more experience with these classes could check this out, that'd be cool. Thanks! Regards, James -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30483] - [codec] Base64 decoder throws exception if byte sent in 0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30483. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30483 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 05:47 --- Lack of reply from reporter - so closing. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384125 - /jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml
Author: psteitz Date: Tue Mar 7 21:50:46 2006 New Revision: 384125 URL: http://svn.apache.org/viewcvs?rev=384125view=rev Log: Added new standard issue tracking page. Added: jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml (with props) Added: jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml?rev=384125view=auto == --- jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml (added) +++ jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml Tue Mar 7 21:50:46 2006 @@ -0,0 +1,61 @@ +?xml version=1.0? +!-- +Copyright 2006 The Apache Software Foundation. + +Licensed under the Apache License, Version 2.0 (the License); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an AS IS BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +-- +document + properties + titleIssue tracking/title + author email=commons-dev@jakarta.apache.orgCommons Documentation Team/author + /properties +body +!-- == -- +section name=Issue tracking +p + Commons DBCP uses a href=http://issues.apache.org/bugzilla/;ASF Bugzilla/a for tracking issues. + To use Bugzilla you may need to a href=http://issues.apache.org/bugzilla/createaccount.cgi;create an account/a. +/p +p + If you would like to report a bug, or raise an enhancement request with + Commons DBCP please do the following: + ol + lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_status=NEEDINFOamp;product=Commonsamp;component=Dbcp;Search existing open bugs/a. + If you find your issue listed then please add a comment with your details./li + lia href=http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/;Search the mailing list archive/a. + You may find your issue or idea has already been discussed./li + lia href=http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commonsamp;version=unspecifiedamp;component=Dbcpamp;rep_platform=Allamp;op_sys=Allamp;priority=P1amp;bug_severity=normalamp;bug_status=NEWamp;assigned_to=commons-dev%40jakarta.apache.orgamp;short_desc=%5Bmath%5D%20%22Your%20subject%20heading%20here%22amp;comment=Please%20provide%20details%20here.%20Its%20best%20to%20submit%20patches%20that%20alter%0D%0Aexisting%20file%20content%20in%20%22unified%20cvs%20diff%22%20format.%20%0D%0A%0D%0ASubmissions%20that%20provide%20new%20files%20can%20be%20supplied%20as%20direct%20file%0D%0Aattachments%20or%20archives%20in%20zip%20or%20tar.gz%20format.%20please%20be%20kind%20%0D%0Aenough%20to%20identify%20the%20format%20of%20the%20attached%20archive%20as%20bugzilla%0D%0Atends%20to%20strip%20these%20characterstics%20by%20removing%20the%20files%20extension.amp;commentprivacy=0amp;form_name=enter_bug;Submit a bug report or enhancement request/a. + Please prefix all new issues with [dbcp] in the summary line. + /li + /ol +/p +p + Please also remember these points: + ul + lithe more information you provide, the better we can help you/li + litest cases are vital, particularly for any proposed enhancements/li + lithe developers of Commons DBCP are all unpaid volunteers/li + /ul +/p +p + You may also find these links useful: + ul + lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_status=NEEDINFOamp;product=Commonsamp;component=Dbcp;All Open DBCP bugs/a/li + lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;bug_status=VERIFIEDamp;bug_status=CLOSEDamp;product=Commonsamp;component=Dbcp;All Closed DBCP bugs/a/li + lia href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_status=NEEDINFOamp;bug_status=RESOLVEDamp;bug_status=VERIFIEDamp;bug_status=CLOSEDamp;product=Commonsamp;component=Dbcp;All DBCP bugs/a/li + /ul +/p +/section +!-- == -- +/body +/document Propchange: jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27997] - [messenger] Patch - Messenger instance continues to work after JMS server crash
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27997. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27997 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 05:55 --- Sorry to close this David, but the Messenger component headed over to codehaus where I think it's pretty much dead. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23217] - [messenger] Messenger.dtd's JNDI attributes rules mistakenly require className
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=23217. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=23217 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 05:57 --- Messenger headed over to codehaus, where I think it's hidden away in inactivity. So closing this as unfortunately I can't see it ever being applied. Sorry Matt. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
Thanks! I added the new commons std issue tracking page here: http://jakarta.apache.org/commons/dbcp/issue-tracking.html One of the links on that page will generate an open bug list. There are also instructions for entering new ones (though we are certainly not lacking in open tickets ;-) Anyone wanting to contribute who needs help getting set up with ant/maven, svn, generating patches, etc., don't hesitate to ask. We don't usually use the voting feature in Bugzilla, but I am willing to try anything once. In any case, weighing in somehow on priorities will help us decide which ones to go after first. Phil On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/7/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. +1 (and thanks) for Phil stepping up to the plate! +1. Let me know how I can help. Hen - 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]
svn commit: r384127 - in /jakarta/commons/proper/cli/trunk: maven.xml project.properties
Author: bayard
Date: Tue Mar 7 22:05:02 2006
New Revision: 384127
URL: http://svn.apache.org/viewcvs?rev=384127view=rev
Log:
Removed the pdf and svg bits - not sure why [cli] would have these, yell at me
if there's a reason
Modified:
jakarta/commons/proper/cli/trunk/maven.xml
jakarta/commons/proper/cli/trunk/project.properties
Modified: jakarta/commons/proper/cli/trunk/maven.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/maven.xml?rev=384127r1=384126r2=384127view=diff
==
--- jakarta/commons/proper/cli/trunk/maven.xml (original)
+++ jakarta/commons/proper/cli/trunk/maven.xml Tue Mar 7 22:05:02 2006
@@ -54,15 +54,6 @@
tofile=target/test-classes/org/apache/commons/cli2/resource/TestBundle.properties/
/postGoal
- postGoal name=xdoc:transform
- attainGoal name=pdf:pdf/
- /postGoal
-
- preGoal name=pdf:prepare
- attainGoal name=svg:init/
- attainGoal name=svg:convert/
- /preGoal
-
preGoal name=dist:prepare-bin-filesystem
attainGoal name=ant:generate-build/
/preGoal
Modified: jakarta/commons/proper/cli/trunk/project.properties
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/project.properties?rev=384127r1=384126r2=384127view=diff
==
--- jakarta/commons/proper/cli/trunk/project.properties (original)
+++ jakarta/commons/proper/cli/trunk/project.properties Tue Mar 7 22:05:02 2006
@@ -31,12 +31,3 @@
maven.jar.manifest.attribute.Implementation-Vendor-Id=org.apache
maven.jar.manifest.attribute.X-Compile-Source-JDK=${maven.compile.source}
maven.jar.manifest.attribute.X-Compile-Target-JDK=${maven.compile.target}
-
-maven.pdf.navigationFile=navigation-pdf.xml
-
-# Used in conjuction with the maven-svg-plugin.
-# see http://www.mvdb.org/maven/plugins/svg on howto install the plugin.
-# You need version 1.2
-maven.svg.target=all
-maven.svg.type=all
-maven.svg.onload=true
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384129 - in /jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2: DocumentationTest.java PrecedenceTest.java WriteableCommandLineTestCase.java jdepend/JDependTest.java
Author: bayard
Date: Tue Mar 7 22:11:58 2006
New Revision: 384129
URL: http://svn.apache.org/viewcvs?rev=384129view=rev
Log:
Removed Eclipse auto generated crap
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/DocumentationTest.java
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/PrecedenceTest.java
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/WriteableCommandLineTestCase.java
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/jdepend/JDependTest.java
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/DocumentationTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/DocumentationTest.java?rev=384129r1=384128r2=384129view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/DocumentationTest.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/DocumentationTest.java
Tue Mar 7 22:11:58 2006
@@ -35,9 +35,6 @@
/**
* @author Rob
- *
- * To change the template for this generated type comment go to Window -
- * Preferences - Java - Code Generation - Code and Comments
*/
public class DocumentationTest extends TestCase {
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/PrecedenceTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/PrecedenceTest.java?rev=384129r1=384128r2=384129view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/PrecedenceTest.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/PrecedenceTest.java
Tue Mar 7 22:11:58 2006
@@ -28,9 +28,6 @@
/**
* @author Rob Oxspring
- *
- * To change the template for this generated type comment go to Window -
- * Preferences - Java - Code Generation - Code and Comments
*/
public class PrecedenceTest extends TestCase {
private final String[] args = new String[] { -file };
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/WriteableCommandLineTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/WriteableCommandLineTestCase.java?rev=384129r1=384128r2=384129view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/WriteableCommandLineTestCase.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/WriteableCommandLineTestCase.java
Tue Mar 7 22:11:58 2006
@@ -19,9 +19,6 @@
/**
* @author Rob Oxspring
- *
- * To change the template for this generated type comment go to
- * Window - Preferences - Java - Code Generation - Code and Comments
*/
public abstract class WriteableCommandLineTestCase extends CommandLineTestCase
{
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/jdepend/JDependTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/jdepend/JDependTest.java?rev=384129r1=384128r2=384129view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/jdepend/JDependTest.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/jdepend/JDependTest.java
Tue Mar 7 22:11:58 2006
@@ -26,9 +26,6 @@
/**
* @author Rob Oxspring
- *
- * To change the template for this generated type comment go to Window -
- * Preferences - Java - Code Generation - Code and Comments
*/
public class JDependTest extends TestCase {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33591] - [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:16 --- James, the testPoolableConnectionLeak() in Possible testcase to illustrate bug has a problem I think. GenericObjectPool (and any non-custom ObjectPool) doesn't have any special knowledge about objects borrowed from it. That test cased: 1. borrows an object from the pool, in this case a Connection instance 2. closes said Connection 3. asks the pool again how many objects were borrowed from it The ObjectPool.getNumActive() method simply returns how many objects were returned from ObjectPool.borrowObject() minus how many were returned with ObjectPool.returnObject(...) or were invalidated with ObjectPool.invalidateObject(...) For the ObjectPool to return the right value for getNumActive() you should invalidate the connection by adding a pool.invalidateObject(conn); just before the assertEquals(). Now the added pool.invalidateObject(conn); line does thown an exception and it really shouldn't. The point of the ObjectPool.invalidateObject(...) method is that the object being invalidated is in a broken state and the PoolableObjectFactory.destroyObject(...) method should be prepared for anything. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38842] - [cli] Dependecy on commons-lang-2.0 but commons-lang-1.0 is obtained
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38842. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38842 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:19 --- Updated. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38843] - [cli] testNewMessage1Param fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38843. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38843 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:24 --- Regenerating the build.xml took care of this (38842). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33591] - [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:27 --- (In reply to comment #8) Nevermind, pretend I never said that. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28482] - [cli] clone() method doesn't fully clone contents
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28482. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28482 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:40 --- clone() showed up in a commit from jkeyes, whose comment doesn't indicate any reason for the addition: http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java?rev=129799r1=129796r2=129799 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29908] - [cli] clone method in Option should use super.clone()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29908. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29908 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:40 --- clone() showed up in a commit from jkeyes, whose comment doesn't indicate any reason for the addition: http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java?rev=129799r1=129796r2=129799 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28482] - [cli] clone() method doesn't fully clone contents
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28482. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28482 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:41 --- Removed clone() from Option - thus resolving this bug. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29908] - [cli] clone method in Option should use super.clone()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29908. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29908 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:42 --- Removed clone() from Option - thus resolving this bug. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384132 - /jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java
Author: bayard
Date: Tue Mar 7 22:42:27 2006
New Revision: 384132
URL: http://svn.apache.org/viewcvs?rev=384132view=rev
Log:
Removed clone() method - it was incorrectly implemented, but more importantly
there is no obvious reason for Option to be cloneable. This resolves #28482 and
#29908
Modified:
jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java
Modified:
jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java?rev=384132r1=384131r2=384132view=diff
==
---
jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java
Tue Mar 7 22:42:27 2006
@@ -32,7 +32,7 @@
* @author a href=mailto:[EMAIL PROTECTED]James Strachan/a
* @version $Revision$
*/
-public class Option implements Cloneable {
+public class Option {
/** constant that specifies the number of argument values has
not been specified */
@@ -550,23 +550,6 @@
public java.util.List getValuesList()
{
return this.values;
-}
-
-/**
- * @return a copy of this Option
- */
-public Object clone()
-{
-Option option = new Option(getOpt(), getDescription());
-
-option.setArgs(getArgs());
-option.setOptionalArg(hasOptionalArg());
-option.setRequired(isRequired());
-option.setLongOpt(getLongOpt());
-option.setType(getType());
-option.setValueSeparator(getValueSeparator());
-
-return option;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34831] - [cli] Parameter value -something misinterpreted as a parameter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34831. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34831 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:45 --- The usual strategy here is to allow -- as a way to indicate that the rest of the line is pure text. If it's not available, this should be added. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36185] - [cli] supporting options without a short option
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36185. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36185 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:48 --- *** Bug 36295 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36295] - [cli] options group cannot have long options
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36295. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36295 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:48 --- *** This bug has been marked as a duplicate of 36185 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] Connection.close() implementation issues [was: Jumping in...]
Sorry, ment to send this to commons-dev, not commons-user.
/me needs sleep asap.
-- Forwarded message --
From: Sandy McArthur [EMAIL PROTECTED]
Date: Mar 8, 2006 2:00 AM
Subject: [dbcp] Connection.close() implementation issues [was: Jumping in...]
To: Jakarta Commons Users List commons-user@jakarta.apache.org
On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote:
There is a growing backlog of bugs open against [dbcp]. Unless other
committers object, I am going to jump in and start committing patches
and develop a maintenance release plan. I plan to start with
http://issues.apache.org/bugzilla/show_bug.cgi?id=33591
http://issues.apache.org/bugzilla/show_bug.cgi?id=38073
I would appreciate any feedback that community members have on
prioritization of open tickets. Also, as always, tickets with patches
and test cases are likely to get addressed quicker and comments /
testing / feedback are always welcome.
Any help from other commons committers, even if just in the form of
screams, will be most appreciated.
I've looked into some, as you can tell from my retracted bugzilla
comment and I think I've found a large source of the problems.
The method Connection.close() interface states: Calling the method
close on a Connection object that is already closed is a no-op.
This is violated in a number of places:
* PoolableConnection.java:77: throws an exception when close is called
and it's already closed. It should be replaced with a line similar to:
try {
if (!hasBeenReturnedToPool) {
hasBeenReturnedToPool = true;
_pool.invalidateObject(this);
}
} catch (Exception e) {
// ignored
}
* ConnectionImpl.java:115: calls assertOpen() which throws an
SQLException when it isn't open. This line should be removed.
* PoolingDataSource.java:179: the call to checkOpen() is like the call
to assertOpen() mentioned above and should be removed.
* PoolingDriver:258: another call to checkOpen(), same solution as before.
* TesterConnection.java:67: another call to checkOpen(), same solution
as before.
Someone should also audit:
* DelegatingConnection.java:184: make sure the call to passivate() is
fine being called more than once.
--
Sandy McArthur
He who dares not offend cannot be honest.
- Thomas Paine
--
Sandy McArthur
He who dares not offend cannot be honest.
- Thomas Paine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384139 - /jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
Author: bayard
Date: Tue Mar 7 23:13:07 2006
New Revision: 384139
URL: http://svn.apache.org/viewcvs?rev=384139view=rev
Log:
As #38845 states, three tests in this class fail. This is because they make
assumptions about the default datetime formatting instances. I've made them
non-default, which should allow tests to pass. Two do pass for me, but the
third oddly enough doesn't - somehow it turns 23-Dec-2003 into 2003-12-22. Very
odd.
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java?rev=384139r1=384138r2=384139view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
Tue Mar 7 23:13:07 2006
@@ -60,7 +60,7 @@
throws InvalidArgumentException {
final Object[] array = new Object[] { 23-Dec-2003 };
final List list = Arrays.asList(array);
-final Validator validator = DateValidator.getDateInstance();
+final Validator validator = new DateValidator( new
SimpleDateFormat(dd-MMM-) );
validator.validate(list);
@@ -73,7 +73,7 @@
throws InvalidArgumentException {
final Object[] array = new Object[] { 18:00:00 };
final List list = Arrays.asList(array);
-final Validator validator = DateValidator.getTimeInstance();
+final Validator validator = new DateValidator( new
SimpleDateFormat(HH:mm:ss) );
validator.validate(list);
@@ -87,7 +87,7 @@
throws InvalidArgumentException {
final Object[] array = new Object[] { 23-Jan-2003 18:00:00 };
final List list = Arrays.asList(array);
-final Validator validator = DateValidator.getDateTimeInstance();
+final Validator validator = new DateValidator( new
SimpleDateFormat(dd-MMM- HH:mm:ss) );
validator.validate(list);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38845] - [cli] DateValidatorTest FileValidatorTest problems
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38845 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 07:13 --- Fixed the 3 datetime ones by specifying specific dateformats. One still errors for me - which is bizarre as I don't see how it's turning 23-Dec-2003 into 2003-12-22. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38611] - [cli][PATCH] HelpFormatter shouldn't throw IOException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38611. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38611 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 07:15 --- Latest patch applied. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r384140 - in /jakarta/commons/proper/cli/trunk/src: java/org/apache/commons/cli2/util/HelpFormatter.java test/org/apache/commons/cli2/util/HelpFormatterTest.java
Author: bayard
Date: Tue Mar 7 23:17:00 2006
New Revision: 384140
URL: http://svn.apache.org/viewcvs?rev=384140view=rev
Log:
Applying patch #17677. Remove the Writer API in favour of the PrintWriter API
it is using elsewhere anyway - with the advantage that the IOException throws
go away
Modified:
jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli2/util/HelpFormatter.java
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/util/HelpFormatterTest.java
Modified:
jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli2/util/HelpFormatter.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli2/util/HelpFormatter.java?rev=384140r1=384139r2=384140view=diff
==
---
jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli2/util/HelpFormatter.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli2/util/HelpFormatter.java
Tue Mar 7 23:17:00 2006
@@ -15,9 +15,7 @@
*/
package org.apache.commons.cli2.util;
-import java.io.IOException;
import java.io.PrintWriter;
-import java.io.Writer;
import java.util.ArrayList;
import java.util.Collections;
@@ -156,10 +154,8 @@
/**
* Prints the Option help.
- * @throws IOException if an error occurs
*/
-public void print()
-throws IOException {
+public void print() {
printHeader();
printException();
printUsage();
@@ -170,10 +166,8 @@
/**
* Prints any error message.
- * @throws IOException if an error occurs
*/
-public void printException()
-throws IOException {
+public void printException() {
if (exception != null) {
printDivider();
printWrapped(exception.getMessage());
@@ -182,10 +176,8 @@
/**
* Prints detailed help per option.
- * @throws IOException if an error occurs
*/
-public void printHelp()
-throws IOException {
+public void printHelp() {
printDivider();
final Option option;
@@ -253,10 +245,8 @@
/**
* Prints a single line of usage information (wrapping if necessary)
- * @throws IOException if an error occurs
*/
-public void printUsage()
-throws IOException {
+public void printUsage() {
printDivider();
final StringBuffer buffer = new StringBuffer(Usage:\n);
@@ -267,10 +257,8 @@
/**
* Prints a header string if necessary
- * @throws IOException if an error occurs
*/
-public void printHeader()
-throws IOException {
+public void printHeader() {
if (header != null) {
printDivider();
printWrapped(header);
@@ -279,10 +267,8 @@
/**
* Prints a footer string if necessary
- * @throws IOException if an error occurs
*/
-public void printFooter()
-throws IOException {
+public void printFooter() {
if (footer != null) {
printWrapped(footer);
printDivider();
@@ -292,10 +278,8 @@
/**
* Prints a string wrapped if necessary
* @param text the string to wrap
- * @throws IOException if an error occurs
*/
-protected void printWrapped(final String text)
-throws IOException {
+protected void printWrapped(final String text) {
for (final Iterator i = wrap(text, pageWidth).iterator();
i.hasNext();) {
printGutterLeft();
pad((String) i.next(), pageWidth, out);
@@ -333,8 +317,7 @@
protected static void pad(final String text,
final int width,
- final Writer writer)
-throws IOException {
+ final PrintWriter writer) {
final int left;
// write the text and record how many characters written
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/util/HelpFormatterTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/util/HelpFormatterTest.java?rev=384140r1=384139r2=384140view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/util/HelpFormatterTest.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/util/HelpFormatterTest.java
Tue Mar 7 23:17:00 2006
@@ -414,28 +414,28 @@
public void testPad()
throws IOException {
final StringWriter writer = new StringWriter();
-HelpFormatter.pad(hello, 10, writer);
+HelpFormatter.pad(hello, 10, new PrintWriter(writer));
assertEquals(hello , writer.toString());
}
public void testPad_Null()
throws IOException {
final StringWriter writer = new
DO NOT REPLY [Bug 38609] - [cli][PATCH] HelpWriter.printWrapped() should have public access
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38609. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38609 --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 07:18 --- +1 to Martin's suggestion. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38873] - [email] setCharset() in Email does not set the charset for the message content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38873. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38873 [EMAIL PROTECTED] changed: What|Removed |Added Summary|setCharset() in Email does |[email] setCharset() in |not set the charset for the |Email does not set the |message content |charset for the message ||content -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36998] - [cli] Parsing error?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36998. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36998 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-03-08 07:22 --- We could do a first parse of the line for any -file style flags - if they 'happened' to match an existing word then we would throw an error and ask the user to rearrange them into a non-clashing set of letters. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
