Re: [math] Priority
J.Pietschmann wrote: Brent Worden wrote: In the chi-square patch, I created a root finding utility class. I used the bisection method to provide a default mechanism for computing inverse CDFs. It's driven by a simple Function interface. Check it out and see if it's something you can use or improve. Here's my take on root finding. Note that BrentSolver uses only inverse quadratic interpolation rather than the full Brent algorithm. Can you provide a math reference desribing this? I have been referring to Atkinson and I am having a hard time following the implementation. What exactly do you mean by only inverse quadratic interpolation? Am I correct in assuming that what you mean by this is that you *never* use Secant or Bisection? Looks to me like this is the case, but I am having a little difficulty following the code. If it is the case, what impact does this have on convergence/stability? THere are a few issues with accuracy, there should really be a relative accuracy too, as well as some plausiblity checks. What do you have in mind re: plausibility? I guess I like your rootfinding framework better than Brent's (Here I mean Brent Worden, the famous commons-math contributor, not the numerical analyst). I suggest that we agree to use your interfaces and UnivariateRealSolverImpl base,include Brent's bisection implementation strategy and modify his CDF inversion to use the new rootfinding framework. I do have a few small questions/comments on the framework: 1. Having solve() *require* brackets makes it impossible (or at least, un-natural) to add Newton's method or any other method that just starts with one initial value. Brent W. includes a method that will try to find a bracket from initial values. I suppose that we could add a solve() with only one initial value and if necessary push it out to a bracket. Personally, given the multiple good implementations available now, I am OK with dropping Newton altogether, so this could be a moot point at least for the initial release. 2. I am curious as to why the result property is there. How exactly do we expect clients to make use of this? 3. What were you thinking about putting into the base solve() implementation as diagnostics? Do you mean things like checking to make sure the bracket is good? 4. Thinking of the developers who will use this stuff, I feel like we need a way to insulate them from having to think about rootfinding strategy choice. As Al has pointed out, we are not (at least yet ;-)) in the AI business, so we can't automagically make the best choice for them; but it might be a good idea to somehow specify a default strategy. Unfortunately, the safe choice would likely be bisection. We could obviously annoint bisection as the default by naming it something like Solver, but there might be simpler/better ways to do this. flame-invitation I bet that in most real world applications the difference in convergence speed is not a big deal and guaranteed convergence/domain of application is more important than expected speed of convergence. Consider, for example, our own use in CDF inversion to get critical values for stat tests. /flame-invitation. Phil J.Pietschmann - 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: [math] Priority
Howdy, 4. Thinking of the developers who will use this stuff, I feel like we need a way to insulate them from having to think about rootfinding strategy choice. As Al has pointed out, we are not (at least yet ;-)) in the AI business, so we can't automagically make the best choice for them; but it might be a good idea to somehow specify a default strategy. Unfortunately, the safe choice would likely be bisection. We could obviously annoint bisection as the default by naming it something like Solver, but there might be simpler/better ways to do this. flame-invitation I bet that in most real world applications the difference in convergence speed is not a big deal and guaranteed convergence/domain of application is more important than expected speed of convergence. Consider, for example, our own use in CDF inversion to get critical values for stat tests. /flame-invitation. As someone who plans to use commons-math but does not plan to contribute code to it (though I do plan on testing, commenting in this forum, and using in production), I definitely need guaranteed convergence more than convergence speed. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Priority
--- Shapira, Yoav [EMAIL PROTECTED] wrote: Howdy, 4. Thinking of the developers who will use this stuff, I feel like we need a way to insulate them from having to think about rootfinding strategy choice. As Al has pointed out, we are not (at least yet ;-)) in the AI business, so we can't automagically make the best choice for them; but it might be a good idea to somehow specify a default strategy. Unfortunately, the safe choice would likely be bisection. We could obviously annoint bisection as the default by naming it something like Solver, but there might be simpler/better ways to do this. flame-invitation I bet that in most real world applications the difference in convergence speed is not a big deal and guaranteed convergence/domain of application is more important than expected speed of convergence. Consider, for example, our own use in CDF inversion to get critical values for stat tests. /flame-invitation. As someone who plans to use commons-math but does not plan to contribute code to it (though I do plan on testing, commenting in this forum, and using in production), I definitely need guaranteed convergence more than convergence speed. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. Phil, Brent never replied about my patches to his bisection code, and now I have an (as-yet untested) implementation of Ridders' method, which is a simple but substantial improvement on bisection and not as complex as Brent or its descendants. Should I just create attachments in Bugzilla so folks can examine my code? Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH][SITE] change of translation url and creation of unified diff howto
Hello, I made a patch for changing 1. xdocs/patches.xml 2. xdocs/stylesheets/project.xml 1 is for the new guide of the creation of unified diff using WinCVS (This was once applied to by my submission, but I noticed something to be added). 2 is for the change of the url of the translation site (Japanese) from http://www.terra-intl.com/jakarta/commons/ to http://jakarta.terra-intl.com/commons/ This patch attached to this e-mail, zipped, contains -- commons_site.txt Please apply this. Sincerely, -- Tetsuya Kitahata [EMAIL PROTECTED] commons_site.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Priority
Al Chou wrote: --- Shapira, Yoav [EMAIL PROTECTED] wrote: Howdy, 4. Thinking of the developers who will use this stuff, I feel like we need a way to insulate them from having to think about rootfinding strategy choice. As Al has pointed out, we are not (at least yet ;-)) in the AI business, so we can't automagically make the best choice for them; but it might be a good idea to somehow specify a default strategy. Unfortunately, the safe choice would likely be bisection. We could obviously annoint bisection as the default by naming it something like Solver, but there might be simpler/better ways to do this. flame-invitation I bet that in most real world applications the difference in convergence speed is not a big deal and guaranteed convergence/domain of application is more important than expected speed of convergence. Consider, for example, our own use in CDF inversion to get critical values for stat tests. /flame-invitation. As someone who plans to use commons-math but does not plan to contribute code to it (though I do plan on testing, commenting in this forum, and using in production), I definitely need guaranteed convergence more than convergence speed. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. Phil, Brent never replied about my patches to his bisection code, and now I have an (as-yet untested) implementation of Ridders' method, which is a simple but substantial improvement on bisection and not as complex as Brent or its descendants. Should I just create attachments in Bugzilla so folks can examine my code? Al Yes. We are getting a bit backed up here. I think the best thing to do is to wait until one of the committers commits Brent's stuff and then submit a Bugzilla patch against the cvs source. I would suggest the following order of events: 1. commit 20279 (Brent's CDF, chi-square stuff, including bisection) 2. submit your patch to Brent's bisection 3. commit J.Pietschmann's submission 4. Brent's stuff refactored to fit into J.Pietschmann's framework 5. Declare rootfinding victory :-) (at least for the first release, modulo test/doc/validation) Phil = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Priority
Phil Steitz wrote: Can you provide a math reference desribing this? H.M.Antia: Num. Methods for Scientists and Engineers. I have been referring to Atkinson and I am having a hard time following the implementation. What exactly do you mean by only inverse quadratic interpolation? Brent's method requires a bracketed root as a start. The primary method for shrinking the bracket is inverse quadratic interpolation. This means you get three points x0,y0 x1,y1 x2,y2 x0x2x1 and interpolate a parabola x=a*y^2+b*y+c and because your goal is to find the x for y=0, your next estimate for the root is c (set y=0). The convergence is of the order 1.8, which is better than the secant method (~1.4 if non bracketing, 1..1.2 on average if bracketing). The full Brent algorithm measures how well the interval shrinks, and resorts to bisection if progress is too slow. I didn't implement this because I forgot to take the book with me and had only a hazy memory of the control parameters. All in all the algorithm combines near-guaranteed convergence (occasionally problems might falsely detected as ill-conditioned) with near Newton-speed. What do you have in mind re: plausibility? If the interval to search is (x0,x1), then absAccuracy should be of the order of max(abs(x0),abs(x1))*relAccuracy. Achievable relative accuracy depends on underlying hardware, although nowadays basically everyone uses IEEE 754 (means, uh, 52 bit for double? Damn, have to look it up!). Both relative and absolute accuracy of function evaluation are also important, which is the reason to let the user override defaults. This means if relAcc is given then reject absAcc if max(abs(x0),abs(x1))*relAcc+c*absAcc == max(abs(x0),abs(x1))*relAcc for some predermined constant c in 0.2..1. I guess I like your rootfinding framework better than Brent's (Here I mean Brent Worden, the famous commons-math contributor, not the numerical analyst). I suggest that we agree to use your interfaces and UnivariateRealSolverImpl base,include Brent's bisection implementation strategy and modify his CDF inversion to use the new rootfinding framework. No argument against :-) I took special care for the JavaDocs, which seems to pay off... I do have a few small questions/comments on the framework: 1. Having solve() *require* brackets makes it impossible (or at least, un-natural) to add Newton's method or any other method that just starts with one initial value. Why? Start with -400,+40 or so. The algorithm is not *required* to start with a bracket, just with an interval. Individual solver implementations should document whether they require a bracket. Apart from this, there is always the possiblity to add another method. 2. I am curious as to why the result property is there. How exactly do we expect clients to make use of this? The client can ask for the last result as long as no further attempt to solve for another root was made. I found this handy. I don't insist on keeping it. 3. What were you thinking about putting into the base solve() implementation as diagnostics? Do you mean things like checking to make sure the bracket is good?\ No, just adding a message indicating that an unimplemented method was called. Some frameworks don't display the type of the exception to the user and rely on the message. 4. Thinking of the developers who will use this stuff, I feel like we need a way to insulate them from having to think about rootfinding strategy choice. As Al has pointed out, we are not (at least yet ;-)) in the AI business, so we can't automagically make the best choice for them; but it might be a good idea to somehow specify a default strategy. Unfortunately, the safe choice would likely be bisection. Brent's algorithm is quite safe in this respect. I'll see whether I can complete the implementation near term. Unfortunately I'll go on vacation on saturday and will be offline until 2003-06-09. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] stat package structure
Proposal: move all Univariate and Bivariate interfaces and implementations into the package named stat. IMO, this qualifies as a Long Term Plan, which is subject to lazy consensus. Are there any binding -1s to moving anything **/*Univariate*.java into stat. (UnivariateFunction.java from Brent's patch is not involved in this change). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat - New directory
tobrien 2003/05/29 12:25:47 jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/distribution - New directory
tobrien 2003/05/29 12:25:52 jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/distribution - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/special - New directory
tobrien 2003/05/29 12:28:34 jakarta-commons-sandbox/math/src/java/org/apache/commons/math/special - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18707] - [io][patch] IOUtil improvements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18707. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18707 [io][patch] IOUtil improvements [EMAIL PROTECTED] changed: What|Removed |Added Summary|[PATCH][IO] IOUtil |[io][patch] IOUtil |improvements|improvements --- Additional Comments From [EMAIL PROTECTED] 2003-05-29 19:53 --- Only because I'm picky - (trying to sift through the confusing open sandbox bugs, it's easier when the project is prefixed to the bug) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] stat package structure
+1 I think its a good starting decision for package structure. While we're at it, maybe matrix related Classes should get moved into a similar package for consistency? -M. Phil Steitz wrote: O'brien, Tim wrote: Proposal: move all Univariate and Bivariate interfaces and implementations into the package named stat. IMO, this qualifies as a Long Term Plan, which is subject to lazy consensus. Are there any binding -1s to moving anything **/*Univariate*.java into stat. (UnivariateFunction.java from Brent's patch is not involved in this change). I agree with the proposal. We will probably want to move some more stuff there as well, but this is a good start. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Optimizing Entities
A,
I think we can now get rid of the StringEscapeUtils methods:
private static String escapeEntities(String str, Entities entities) {
return entities.escape(str);
}
private static String unescapeEntities(String str, Entities entities) {
return entities.unescape(str);
}
Gary
-Original Message-
From: Alex Chaffee / Purple Technology [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 14:29
To: Jakarta Commons Developers List
Subject: Re: [lang] Optimizing Entities
Another stab, this time using a lookup table for char values 256.
Another 25-50% speedup if I'm not mistaken. This is fun!
(I haven't checked in the latest changes yet, due to pending license
issues, but if a release is near, let me know I'll check in a
releasable version.)
- A
--
Alex Chaffee mailto:[EMAIL PROTECTED]
Purple Technology - Code and Consultinghttp://www.purpletech.com/
jGuru - Java News and FAQs http://www.jguru.com/alex/
Gamelan - the Original Java site http://www.gamelan.com/
Stinky - Art and Angst http://www.stinky.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Optimizing Entities
Good catch. Yup, that's a natural Inline Method refactoring. I'll do
that before I check in.
- A
On Thu, May 29, 2003 at 04:38:20PM -0400, Gary Gregory wrote:
A,
I think we can now get rid of the StringEscapeUtils methods:
private static String escapeEntities(String str, Entities entities) {
return entities.escape(str);
}
private static String unescapeEntities(String str, Entities entities) {
return entities.unescape(str);
}
Gary
-Original Message-
From: Alex Chaffee / Purple Technology [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 14:29
To: Jakarta Commons Developers List
Subject: Re: [lang] Optimizing Entities
Another stab, this time using a lookup table for char values 256.
Another 25-50% speedup if I'm not mistaken. This is fun!
(I haven't checked in the latest changes yet, due to pending license
issues, but if a release is near, let me know I'll check in a
releasable version.)
- A
--
Alex Chaffee mailto:[EMAIL PROTECTED]
Purple Technology - Code and Consultinghttp://www.purpletech.com/
jGuru - Java News and FAQs http://www.jguru.com/alex/
Gamelan - the Original Java site http://www.gamelan.com/
Stinky - Art and Angst http://www.stinky.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alex Chaffee mailto:[EMAIL PROTECTED]
Purple Technology - Code and Consultinghttp://www.purpletech.com/
jGuru - Java News and FAQs http://www.jguru.com/alex/
Gamelan - the Original Java site http://www.gamelan.com/
Stinky - Art and Angst http://www.stinky.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16440] - [codec] Base64 does not handle whitespace correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16440 [codec] Base64 does not handle whitespace correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18874] - [codec] RefinedSoundex nit: unused local variable 'mapped'
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18874. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18874 [codec] RefinedSoundex nit: unused local variable 'mapped' [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-05-29 20:58 --- Fixed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19882] - REQ: Streaming codecs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19882. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19882 REQ: Streaming codecs [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2003-05-29 20:58 --- Will be addressed in 1.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17091] - [Codec] Add MD5 and SHA digest algorithms
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17091 [Codec] Add MD5 and SHA digest algorithms [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2003-05-29 20:59 --- 1.2 enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ClassUtils.java
ggregory2003/05/29 14:02:53
Modified:lang/src/java/org/apache/commons/lang ClassUtils.java
Log:
Make the Standard Doclet version 1.4.1 not complain WRT '.'s.
Revision ChangesPath
1.12 +3 -3
jakarta-commons/lang/src/java/org/apache/commons/lang/ClassUtils.java
Index: ClassUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/ClassUtils.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ClassUtils.java 28 May 2003 16:20:31 - 1.11
+++ ClassUtils.java 29 May 2003 21:02:53 - 1.12
@@ -67,12 +67,12 @@
public class ClassUtils {
/**
- * The package separator character: code./code
+ * The package separator character: code#x2e;/code
*/
public static final char PACKAGE_SEPARATOR_CHAR = '.';
/**
- * The package separator String: code./code
+ * The package separator String: code#x2e;/code
*/
public static final String PACKAGE_SEPARATOR =
String.valueOf(PACKAGE_SEPARATOR_CHAR);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/language RefinedSoundex.java package.html
tobrien 2003/05/29 14:14:59 Modified:codecRELEASE-NOTES.txt project.xml codec/src/java/org/apache/commons/codec package.html codec/src/java/org/apache/commons/codec/base64 package.html codec/src/java/org/apache/commons/codec/binary package.html codec/src/java/org/apache/commons/codec/language RefinedSoundex.java package.html Added: codecRELEASE-NOTES-1.1.txt Log: Moved 1.1 release notes to new file and prepared releas notes for the 1.1.1 maint rel. Added/modified documentation Revision ChangesPath 1.4 +17 -21jakarta-commons/codec/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt === RCS file: /home/cvs/jakarta-commons/codec/RELEASE-NOTES.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- RELEASE-NOTES.txt 29 Apr 2003 22:16:08 - 1.3 +++ RELEASE-NOTES.txt 29 May 2003 21:14:58 - 1.4 @@ -1,7 +1,7 @@ $Id$ Commons Codec Package - Version 1.1 + Version 1.1.1 Release Notes @@ -9,28 +9,24 @@ This document contains the release notes for this version of the Commons Codec package, and highlights changes since the previous version. Version -1.1 is the first official release of Codec. Numerous projects had been -depending on Version 1.0-dev while Codec was in the Sandbox, and backwards -compatibility has been preserved to ease the transition to this official -release. +1.1.1 contains a bug fix for the 1.1 release, and addresses an issue related +to the treat of non-Base64 characters. + NEW FEATURES: -* A newer version of the Base64 class reflecting improvements from - both the commons-httpclient and xml-rpc versions of code forked - from catalina. -* Base64 class from commons-httpclient in org.apache.commons.codec.base64 - has been retained for backwards compatibility but has been deprecated -* Soundex class from commons-util in org.apache.commons.codec -* Metaphone class from commons-util in org.apache.commons.codec -* RefinedSoundex class in org.apache.commons.codec -* Encoder/Decoder interfaces in org.apache.commons -* String and Binary specific Encoder/Decoder interfaces in - org.apache.commons -* StringEncoderComparator replaces the SoundexComparator from the - language package. +* None BUG FIXES: -* Base64 now discards whitespace characters when decoding encoded - content. +* Fix for Bug 19860: Modified Base64 to remedy non-compliance with RFC + 2045. Non-Base64 characters were not being discarded during the + decode. RFC 2045 explicitly states that all characters outside of the + base64 alphabet are to be ignored. A new function discardNonBase64 is + called prior to a decode. Note that isArrayBase64 only discards + whitespace before testing the contents of an encoded byte array. Unit + tests for Base64 were updated to reflect the changes related to + discarding non-Base64 characters. + + + 1.11 +2 -2 jakarta-commons/codec/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/codec/project.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- project.xml 22 May 2003 15:42:39 - 1.10 +++ project.xml 29 May 2003 21:14:58 - 1.11 @@ -96,13 +96,13 @@ /contributors dependencies -!--dependency +!-- dependency idjunit/id version3.8/version /dependency -- /dependencies - issueTrackingUrlhttp://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Commonsamp;component=Sandboxamp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;order=%27Importance%27/issueTrackingUrl +
Re: Q about procedure / new committer project
bad news: i'm sad to say there are currently some points that need sorting out with infrastructure and the board about the whole process of recruiting existing apache committers to the sandbox. good news: it looks like most of points have are on the way to being cleaned up. i'm not sure if the debate is finished yet but it appears that it looks as if the consensus is that requests now need to go from here to the pmc and thence to infrastructure (provided they don't get voted down). maybe howard will be able to act to as a guinea-pig (he should be used to that by now ;) - robert On Thursday, May 29, 2003, at 12:45 AM, Howard M. Lewis Ship wrote: I am already an Apache committer (Tapestry project). Powers that be: Let me have it! -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry -Original Message- From: Rodney Waldhoff [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 7:22 PM To: Jakarta Commons Developers List Subject: Re: Q about procedure / new committer project If you're already an apache committer, all you need to do is ask for karma to the sandbox, and have at it. If you're not already an apache committer, then you'll probably want to start building a community at sourceforge or elsewhere before purposing a move to commons. - Rod http://radio.weblogs.com/0122027/ On Tue, 27 May 2003 [EMAIL PROTECTED] wrote: I was just reading the charter: http://jakarta.apache.org/commons/charter.html but I'm still a bit confused about sandbox projects. I have a new code base for a project called HiveMind that I've been working on for a short time. It is a general purpose configuration and service registry with a fair number of cool ideas. Since it's very formative, and I'm the only committer so far, I don't see this as a full Jakarta project, or (for now) even a commons project, but I believe it should be commons sandbox project while it develops. Does a sandbox project require a full proposal, or merely a request? I can easily put together a full proposal. In addition, I believe I'll need karma to commons in order to commit changes. -- [EMAIL PROTECTED] Tapestry: Java Web Components http;//jakarta.apache.org - 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]
FileUpload
Title: Message
HelloI am trying to use the commons-fileupload
information, and it is giving me errors. I created an initial servlet with
nothing more than lines to detect whether the item is a field or a file. Here is
the scriptimport java.io.*;import java.util.*;import
javax.servlet.*;import java.sql.*;import
javax.servlet.http.*;import
org.apache.commons.fileupload.*;public class FileTransfer extends
HttpServlet{ String
strSQLStart = "Insert into tblPortal Files
("; String strSQLMid =
" rec_id, dateupload) values (";
String strSQLEnd = " Null,
curdate())";
String fieldnames = "";
String fieldvalues =
"";
public void doPost(HttpServletRequest req, HttpServletResponse
res)
throws ServletException,
IOException
{
res.setContentType("text/html");
PrintWriter out =
res.getWriter();
DiskFileUpload upload = new
DiskFileUpload();
//set paramaters for
files
upload.setSizeMax(100);
upload.setSizeThreshold(4096);
upload.setRepositoryPath("/tmp");
out.println("html");
out.println("headtitleMARC Research File
Upload/title/head");
out.println("body");
try
{
List items =
upload.parseRequest(req);
Iterator iter =
items.iterator();
while( iter.hasNext()
)
{
FileItem item = (FileItem)
iter.next();
if( item.isFormField()
)
{
out.println("It is a
field");
}else{
out.println("It is a
file");
}
}
}
catch (FileUploadException
fue)
{
out.println("PRE");
fue.printStackTrace(out);
out.println("/PRE");
}
out.println("/body/html");
}}It gave the following errors:type Exception
reportmessagedescription The server encountered an internal
error () that prevented it from fulfilling this
request.exceptionjavax.servlet.ServletException: Servlet
execution threw an exception at
java.lang.Throwable.fillInStackTrace(Native
Method) at
java.lang.Throwable.fillInStackTrace(Compiled
Code) at
java.lang.Throwable.(Compiled
Code) at
java.lang.Exception.(Compiled
Code) at
javax.servlet.ServletException.(Compiled
Code) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Compiled
Code) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(Compiled
Code) at
filters.ExampleFilter.doFilter(ExampleFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Compiled
Code) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(Compiled
Code) at
org.apache.catalina.core.StandardWrapperValve.invoke(Compiled
Code) at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Compiled
Code) at
org.apache.catalina.core.StandardPipeline.invoke(Compiled
Code) at
org.apache.catalina.core.ContainerBase.invoke(Compiled
Code) at
org.apache.catalina.core.StandardContextValve.invoke(Compiled
Code) at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Compiled
Code) at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Compiled
Code) at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Compiled
Code) at
org.apache.catalina.core.StandardPipeline.invoke(Compiled
Code) at
org.apache.catalina.core.ContainerBase.invoke(Compiled
Code) at
org.apache.catalina.core.StandardContext.invoke(Compiled
Code) at
org.apache.catalina.core.StandardHostValve.invoke(Compiled
Code) at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Compiled
Code) at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(Compiled
Code) at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Compiled
Code) at
org.apache.catalina.valves.ErrorReportValve.invoke(Compiled
Code) at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Compiled
Code) at
org.apache.catalina.valves.AccessLogValve.invoke(Compiled
Code) at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Compiled
Code) at
org.apache.catalina.core.StandardPipeline.invoke(Compiled
Code) at
org.apache.catalina.core.ContainerBase.invoke(Compiled
Code) at
org.apache.catalina.core.StandardEngineValve.invoke(Compiled
Code) at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Compiled
Code) at
org.apache.catalina.core.StandardPipeline.invoke(Compiled
Code) at
org.apache.catalina.core.ContainerBase.invoke(Compiled
Code) at
org.apache.coyote.tomcat4.CoyoteAdapter.service(Compiled
Code) at
org.apache.coyote.http11.Http11Processor.process(Compiled
Code) at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Compiled
Code) at
[PROPOSAL] sandbox karma for Howard M. Lewis Ship hlship@apache.org
Howard M. Lewis Ship (well known as a leading light of the recently incubated tapestry project) would like access to the commons-sandbox in order to work on a new component as outlined below in the following email: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=105416555202303w=2 i'd like to propose that we grant him karma. (i know that the debate about processes is still on going but i thought that might as well have an example to talk about ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec project.xml
tobrien 2003/05/29 14:40:39
Modified:codecproject.xml
Log:
The nasty issue tracking URL needs to escape ampersands
Revision ChangesPath
1.12 +1 -1 jakarta-commons/codec/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/codec/project.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- project.xml 29 May 2003 21:14:58 - 1.11
+++ project.xml 29 May 2003 21:40:39 - 1.12
@@ -102,7 +102,7 @@
/dependency --
/dependencies
-
issueTrackingUrlhttp://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Commonscomponent=Codecshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time/issueTrackingUrl
+
issueTrackingUrlhttp://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Commonsamp;component=Codecamp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;newqueryname=amp;order=Reuse+same+sort+as+last+time/issueTrackingUrl
repository
connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:jakarta-commons/${pom.artifactId.substring(8)}/connection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs patches.xml
rdonkin 2003/05/29 14:51:19 Modified:docs patches.html xdocspatches.xml Log: Expanded explanation for winCVS user. Submitted by Tetsuya Kitahata. Revision ChangesPath 1.32 +22 -9 jakarta-commons/docs/patches.html Index: patches.html === RCS file: /home/cvs/jakarta-commons/docs/patches.html,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- patches.html 20 May 2003 10:50:49 - 1.31 +++ patches.html 29 May 2003 21:51:19 - 1.32 @@ -327,16 +327,29 @@ Try to give your patch files meaningful names. This makes it easier for developers who need to apply a number of different patches. /p +pstrongNote:/strongbr / +If you use a href=http://www.wincvs.org/;WinCVS/a, move to +code[Admin]/code -gt; code[Command Line]/code Menu +and type: br / +pre +codecvs diff -u/codebr / +/pre +at code[Enter a cvs line command]/code input field +(code[Commandline Settings] Tab/code), +while selecting the target directories or files, in order to create +unified diffs. +/p p - strongNote:/strong/p -pIf you use a href=http://www.wincvs.org/;WinCVS/a, move to - code[Admin]/code -gt; code[Command Line]/code Menu and type codecvs diff -u/code at - code[Enter a cvs line command]/code input field (code[Commandline Settings] Tab/code), - while selecting the target directories or files, in order to create - unified diffs. /p -pIn other words, code[Alt+A]/code+code[Alt+C]/code+code[Alt+C]/code - and type codecvs diff -u/code. - /p +In other words, code[Alt+A]/code+code[Alt+C]/code+ +code[Alt+C]/code and type codecvs diff -u/code. +/p +p +Also, by adding the full path name of WinCVS-Installed directory to +path environment variables, you can use +cvs diff command on the checked-out directory +(like codecvs diff -u gt; foo.txt/code) recursively +via MS-DOS command prompt. +/p /blockquote /p /td/tr 1.4 +24 -11jakarta-commons/xdocs/patches.xml Index: patches.xml === RCS file: /home/cvs/jakarta-commons/xdocs/patches.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- patches.xml 16 Dec 2002 22:19:42 - 1.3 +++ patches.xml 29 May 2003 21:51:19 - 1.4 @@ -88,16 +88,29 @@ Try to give your patch files meaningful names. This makes it easier for developers who need to apply a number of different patches. /p - p - strongNote:/strong/p - pIf you use a href='http://www.wincvs.org/'WinCVS/a, move to - code[Admin]/code -gt; code[Command Line]/code Menu and type codecvs diff -u/code at - code[Enter a cvs line command]/code input field (code[Commandline Settings] Tab/code), - while selecting the target directories or files, in order to create - unified diffs. /p - pIn other words, code[Alt+A]/code+code[Alt+C]/code+code[Alt+C]/code - and type codecvs diff -u/code. - /p + pstrongNote:/strongbr/ +If you use a href='http://www.wincvs.org/'WinCVS/a, move to +code[Admin]/code -gt; code[Command Line]/code Menu +and type: br/ +pre +codecvs diff -u/codebr/ +/pre +at code[Enter a cvs line command]/code input field +(code[Commandline Settings] Tab/code), +while selecting the target directories or files, in order to create +unified diffs. +/p +p +In other words, code[Alt+A]/code+code[Alt+C]/code+ +code[Alt+C]/code and type quot;codecvs diff -u/codequot;. +/p +p +Also, by adding the full path name of WinCVS-Installed directory to +quot;pathquot; environment variables, you can use +quot;cvs diffquot; command on the checked-out directory +(like codecvs diff -u gt; foo.txt/code) recursively +via MS-DOS command prompt. +/p /section section name=Submitting A Patch p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec/xdocs changes.xml
tobrien 2003/05/29 14:53:42 Modified:codecproject.xml Removed: codec/xdocs changes.xml Log: Removed both the tasklist and the changes reports. Reports only make sense if you are going to use them, and the changes.xml in xdoc was not being maintained. Also, after removing the changes.xml the tasklist-plugin was producing a vdoclet error - another unused report removed. Revision ChangesPath 1.13 +2 -2 jakarta-commons/codec/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/codec/project.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- project.xml 29 May 2003 21:40:39 - 1.12 +++ project.xml 29 May 2003 21:53:42 - 1.13 @@ -131,7 +131,7 @@ reports reportmaven-changelog-plugin/report - reportmaven-changes-plugin/report +!-- reportmaven-changes-plugin/report -- reportmaven-checkstyle-plugin/report !-- reportmaven-clover-plugin/report -- reportmaven-developer-activity-plugin/report @@ -144,6 +144,6 @@ reportmaven-license-plugin/report reportmaven-linkcheck-plugin/report !-- reportmaven-statcvs-plugin/report -- - reportmaven-tasklist-plugin/report +!-- reportmaven-tasklist-plugin/report -- /reports /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/docs charter.html collections.html commons.html components.html contributors.html dbcp.html digester.html directory.html discovery.html
rdonkin 2003/05/29 14:56:42 Modified:docs charter.html collections.html commons.html components.html contributors.html dbcp.html digester.html directory.html discovery.html Log: Updated link to japanese translation. Submitted by Tetsuya Kitahata. Revision ChangesPath 1.78 +1 -1 jakarta-commons/docs/charter.html Index: charter.html === RCS file: /home/cvs/jakarta-commons/docs/charter.html,v retrieving revision 1.77 retrieving revision 1.78 diff -u -r1.77 -r1.78 --- charter.html 20 May 2003 10:50:08 - 1.77 +++ charter.html 29 May 2003 21:56:41 - 1.78 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.68 +1 -1 jakarta-commons/docs/collections.html Index: collections.html === RCS file: /home/cvs/jakarta-commons/docs/collections.html,v retrieving revision 1.67 retrieving revision 1.68 diff -u -r1.67 -r1.68 --- collections.html 20 May 2003 10:50:08 - 1.67 +++ collections.html 29 May 2003 21:56:41 - 1.68 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.82 +1 -1 jakarta-commons/docs/commons.html Index: commons.html === RCS file: /home/cvs/jakarta-commons/docs/commons.html,v retrieving revision 1.81 retrieving revision 1.82 diff -u -r1.81 -r1.82 --- commons.html 20 May 2003 10:50:08 - 1.81 +++ commons.html 29 May 2003 21:56:41 - 1.82 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.106 +1 -1 jakarta-commons/docs/components.html Index: components.html === RCS file: /home/cvs/jakarta-commons/docs/components.html,v retrieving revision 1.105 retrieving revision 1.106 diff -u -r1.105 -r1.106 --- components.html 20 May 2003 10:50:08 - 1.105 +++ components.html 29 May 2003 21:56:41 - 1.106 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.78 +1 -1 jakarta-commons/docs/contributors.html Index: contributors.html === RCS file: /home/cvs/jakarta-commons/docs/contributors.html,v retrieving revision 1.77 retrieving revision 1.78 diff -u -r1.77 -r1.78 --- contributors.html 20 May 2003 10:50:08 - 1.77 +++ contributors.html 29 May 2003 21:56:41 - 1.78 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.36 +1 -1 jakarta-commons/docs/dbcp.html Index: dbcp.html === RCS file: /home/cvs/jakarta-commons/docs/dbcp.html,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- dbcp.html 20 May 2003 10:50:08 - 1.35 +++ dbcp.html 29 May 2003 21:56:41 - 1.36 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul
cvs commit: jakarta-commons/docs versioning.html volunteering.html
rdonkin 2003/05/29 14:57:08 Modified:docs versioning.html volunteering.html Log: Updated link to japanese translation. Submitted by Tetsuya Kitahata. Revision ChangesPath 1.58 +1 -1 jakarta-commons/docs/versioning.html Index: versioning.html === RCS file: /home/cvs/jakarta-commons/docs/versioning.html,v retrieving revision 1.57 retrieving revision 1.58 diff -u -r1.57 -r1.58 --- versioning.html 20 May 2003 10:50:50 - 1.57 +++ versioning.html 29 May 2003 21:57:08 - 1.58 @@ -185,7 +185,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.34 +1 -1 jakarta-commons/docs/volunteering.html Index: volunteering.html === RCS file: /home/cvs/jakarta-commons/docs/volunteering.html,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- volunteering.html 20 May 2003 10:50:50 - 1.33 +++ volunteering.html 29 May 2003 21:57:08 - 1.34 @@ -183,7 +183,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/stylesheets project.xml
rdonkin 2003/05/29 14:57:38 Modified:docs beanutils.html el.html index.html jexl.html lang.html license.html logging.html modeler.html patches.html pool.html releases.html sandbox.html docs/releases index.html mirror.html prepare.html release.html xdocs/stylesheets project.xml Log: Updated link to japanese translation. Submitted by Tetsuya Kitahata. Revision ChangesPath 1.82 +1 -1 jakarta-commons/docs/beanutils.html Index: beanutils.html === RCS file: /home/cvs/jakarta-commons/docs/beanutils.html,v retrieving revision 1.81 retrieving revision 1.82 diff -u -r1.81 -r1.82 --- beanutils.html20 May 2003 10:50:08 - 1.81 +++ beanutils.html29 May 2003 21:57:38 - 1.82 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.9 +1 -1 jakarta-commons/docs/el.html Index: el.html === RCS file: /home/cvs/jakarta-commons/docs/el.html,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- el.html 20 May 2003 10:50:09 - 1.8 +++ el.html 29 May 2003 21:57:38 - 1.9 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.80 +1 -1 jakarta-commons/docs/index.html Index: index.html === RCS file: /home/cvs/jakarta-commons/docs/index.html,v retrieving revision 1.79 retrieving revision 1.80 diff -u -r1.79 -r1.80 --- index.html20 May 2003 10:50:31 - 1.79 +++ index.html29 May 2003 21:57:38 - 1.80 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.11 +1 -1 jakarta-commons/docs/jexl.html Index: jexl.html === RCS file: /home/cvs/jakarta-commons/docs/jexl.html,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- jexl.html 20 May 2003 10:50:31 - 1.10 +++ jexl.html 29 May 2003 21:57:38 - 1.11 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.45 +1 -1 jakarta-commons/docs/lang.html Index: lang.html === RCS file: /home/cvs/jakarta-commons/docs/lang.html,v retrieving revision 1.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- lang.html 20 May 2003 10:50:32 - 1.44 +++ lang.html 29 May 2003 21:57:38 - 1.45 @@ -181,7 +181,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia href=http://jakarta.terra-intl.com/commons/;Japanese/a /li /ul pstrongProject Docs/strong/p 1.74 +1 -1 jakarta-commons/docs/license.html Index: license.html === RCS file: /home/cvs/jakarta-commons/docs/license.html,v retrieving revision 1.73 retrieving revision 1.74 diff -u -r1.73 -r1.74 --- license.html 20 May 2003 10:50:32 - 1.73 +++ license.html 29 May 2003 21:57:38 - 1.74 @@ -182,7 +182,7 @@ /ul pstrongTranslations (Web)/strong/p ul -lia href=http://www.terra-intl.com/jakarta/commons/;Japanese/a +lia
Re: [PATCH][SITE] change of translation url and creation of unified diff howto
committed. many thanks. - robert On Thursday, May 29, 2003, at 07:13 PM, Tetsuya Kitahata wrote: Hello, I made a patch for changing 1. xdocs/patches.xml 2. xdocs/stylesheets/project.xml 1 is for the new guide of the creation of unified diff using WinCVS (This was once applied to by my submission, but I noticed something to be added). 2 is for the change of the url of the translation site (Japanese) from http://www.terra-intl.com/jakarta/commons/ to http://jakarta.terra-intl.com/commons/ This patch attached to this e-mail, zipped, contains -- commons_site.txt Please apply this. Sincerely, -- Tetsuya Kitahata [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/language Metaphone.java RefinedSoundex.java Soundex.java
tobrien 2003/05/29 16:03:29
Modified:codeccheckstyle.properties project.properties
codec/src/java/org/apache/commons/codec/base64 Base64.java
codec/src/java/org/apache/commons/codec/binary Base64.java
Hex.java
codec/src/java/org/apache/commons/codec/language
Metaphone.java RefinedSoundex.java Soundex.java
Log:
Fixed a number of checkstyle problems - from around 270 checkstyle issues to 16
Revision ChangesPath
1.2 +15 -10jakarta-commons/codec/checkstyle.properties
Index: checkstyle.properties
===
RCS file: /home/cvs/jakarta-commons/codec/checkstyle.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- checkstyle.properties 25 Apr 2003 17:50:55 - 1.1
+++ checkstyle.properties 29 May 2003 23:03:28 - 1.2
@@ -1,14 +1,19 @@
-#checkstyle.header.file=LICENSE.txt
+checkstyle.header.file=LICENSE.txt
# 2-5 = CVS Header in Commons license, 10 = copyright date, 32 = product name
-checkstyle.header.ignoreline=2,3,4,5,10,32
+#checkstyle.header.ignoreline=2,3,4,5,10,32
-checkstyle.ignore.maxlinelen=2
+# Ignore operator wrap, this has the effect of allowing
+# operators to appear at both the eol and the nl. This
+# setting should be eol, but checkstyle had problems
+# parsing this property when set to eol. ignore
+# was selected as a fallback.
+checkstyle.wrap.operator = ignore
+
+# Ignore padding around parenthese, this allows for both
+# foo(a,b), and foo( a, b ).
+checkstyle.paren.pad = ignore
+
+# One should not be instantiating a java.lang.Boolean
+checkstyle.illegal.instantiations = java.lang.Boolean
-checkstyle.excludes=**/parser/*
-checkstyle.lcurly.type=eol
-checkstyle.lcurly.method=nlow
-checkstyle.lcurly.other=eol
-checkstyle.rcurly=alone
-checkstyle.javadoc.scope=nothing
-checkstyle.allow.protected=true
1.2 +0 -1 jakarta-commons/codec/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons/codec/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties25 Apr 2003 17:50:55 - 1.1
+++ project.properties29 May 2003 23:03:28 - 1.2
@@ -3,7 +3,6 @@
##
maven.checkstyle.properties=${basedir}/checkstyle.properties
-maven.checkstyle.excludes=**/parser/*
maven.test.failure = false
maven.junit.fork=true
maven.linkcheck.enable=true
1.2 +95 -39
jakarta-commons/codec/src/java/org/apache/commons/codec/base64/Base64.java
Index: Base64.java
===
RCS file:
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/base64/Base64.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Base64.java 25 Apr 2003 17:50:56 - 1.1
+++ Base64.java 29 May 2003 23:03:28 - 1.2
@@ -84,17 +84,56 @@
public final class Base64 {
protected static final String DEFAULT_CHAR_ENCODING = ISO-8859-1;
-private static final int BASELENGTH = 255;
-private static final int LOOKUPLENGTH = 64;
-private static final int TWENTYFOURBITGROUP = 24;
-private static final int EIGHTBIT = 8;
-private static final int SIXTEENBIT = 16;
-private static final int SIXBIT = 6;
-private static final int FOURBYTE = 4;
-private static final int SIGN = -128;
-private static final byte PAD = (byte) '=';
-private static final byte[] EMPTY_BYTE_ARRAY = new byte[0];
+
+/**
+ * The bsae length
+ */
+static final int BASELENGTH = 255;
+
+/**
+ * Lookup length
+ */
+static final int LOOKUPLENGTH = 64;
+
+/**
+ * Used to calculate the number of bits in a byte.
+ */
+static final int EIGHTBIT = 8;
+
+/**
+ * Used when encoding something which has fewer than 24 bits
+ */
+static final int SIXTEENBIT = 16;
+
+/**
+ * Constant used to determine how many bits data contains
+ */
+static final int TWENTYFOURBITGROUP = 24;
+
+/**
+ * Used to get the number of Quadruples
+ */
+static final int FOURBYTE = 4;
+
+/**
+ * Used to test the sign of a byte
+ */
+static final int SIGN = -128;
+
+/**
+ * Byte used to pad output
+ */
+static final byte PAD = (byte) '=';
+
+// Create arrays to hold the base64 characters and a
+// lookup for base64 chars
private static byte[] base64Alphabet = new byte[BASELENGTH];
+
+private static final byte[]
[discovery] jdk1.2.2 and websphere
I seem to be running into trouble with discovery on an AS400 running jdk 1.2.2 and webspere 3.5.6. We are trying to deploy an Axis based web service which runs fine in WSAD (websphere 4.x) and Tomcat 4.1.x. It seems that class implementations are not being found even though they are in the classpath. We verified this by manually loading classes in a JSP and by changing how the LogFactory in axis which normally uses discovery, was loaded and hard coded the return value and it worked. It then went on to another class loading issue. Any suggestions?? At the moment I'm trying to go through axis code and hard code class instantiations, but that doesn't seem like a good solution. Thanks, Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math checkstyle.properties
tobrien 2003/05/29 16:25:00 Modified:math checkstyle.properties Log: Checkstyle should check that each source file include a license Revision ChangesPath 1.2 +6 -1 jakarta-commons-sandbox/math/checkstyle.properties Index: checkstyle.properties === RCS file: /home/cvs/jakarta-commons-sandbox/math/checkstyle.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- checkstyle.properties 21 May 2003 15:10:51 - 1.1 +++ checkstyle.properties 29 May 2003 23:25:00 - 1.2 @@ -1,5 +1,10 @@ # commons math customization of default Checkstyle behavior +# Verify that EVERY source file has the appropriate license +checkstyle.header.file=LICENSE.txt +# 2-5 = CVS Header in Commons license, 10 = copyright date, 32 = product name +#checkstyle.header.ignoreline=2,3,4,5,10,32 + # Ignore operator wrap, this has the effect of allowing # operators to appear at both the eol and the nl. This # setting should be eol, but checkstyle had problems @@ -7,7 +12,7 @@ # was selected as a fallback. checkstyle.wrap.operator = ignore -# Ignore padding around parethese, this allows for both +# Ignore padding around parenthese, this allows for both # foo(a,b), and foo( a, b ). checkstyle.paren.pad = ignore - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math BeanListUnivariateImplTest.java BivariateRegressionTest.java ListUnivariateImplTest.java StoreUnivariateImplTest.java UnivariateImplTest.java
tobrien 2003/05/29 16:25:12 Removed: math/src/test/org/apache/commons/math BeanListUnivariateImplTest.java BivariateRegressionTest.java ListUnivariateImplTest.java StoreUnivariateImplTest.java UnivariateImplTest.java Log: Removed old Univariate tests - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math project.properties project.xml
tobrien 2003/05/29 16:26:24
Modified:math project.properties project.xml
Log:
linkcheck report was throwing 404s for every URL, I've removed it until someone can
generate a meaningful report
Revision ChangesPath
1.2 +1 -1 jakarta-commons-sandbox/math/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons-sandbox/math/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties21 May 2003 15:10:51 - 1.1
+++ project.properties29 May 2003 23:26:24 - 1.2
@@ -5,7 +5,7 @@
maven.checkstyle.properties=${bsaedir}/checkstyle.properties
maven.test.failure = false
maven.junit.fork=true
-maven.linkcheck.enable=true
+#maven.linkcheck.enable=true
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
1.12 +1 -1 jakarta-commons-sandbox/math/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/math/project.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- project.xml 29 May 2003 19:41:31 - 1.11
+++ project.xml 29 May 2003 23:26:24 - 1.12
@@ -114,7 +114,7 @@
reportmaven-junit-report-plugin/report
reportmaven-jxr-plugin/report
!-- reportmaven-license-plugin/report --
- reportmaven-linkcheck-plugin/report
+!-- reportmaven-linkcheck-plugin/report --
!-- reportmaven-statcvs-plugin/report --
reportmaven-tasklist-plugin/report
/reports
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math project.xml
tobrien 2003/05/29 16:30:48 Modified:math project.xml Log: Removed tasklist report, until this has content, no reason for the added distraction Revision ChangesPath 1.13 +1 -1 jakarta-commons-sandbox/math/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/math/project.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- project.xml 29 May 2003 23:26:24 - 1.12 +++ project.xml 29 May 2003 23:30:48 - 1.13 @@ -116,7 +116,7 @@ !-- reportmaven-license-plugin/report -- !-- reportmaven-linkcheck-plugin/report -- !-- reportmaven-statcvs-plugin/report -- - reportmaven-tasklist-plugin/report +!-- reportmaven-tasklist-plugin/report -- /reports /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] sandbox karma for Howard M. Lewis Ship hlship@apache.org
+1 -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au robert burrell donkin [EMAIL PROTECTED] wrote on 30/05/2003 07:27:29 AM: Howard M. Lewis Ship (well known as a leading light of the recently incubated tapestry project) would like access to the commons-sandbox in order to work on a new component as outlined below in the following email: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=105416555202303w=2 i'd like to propose that we grant him karma. (i know that the debate about processes is still on going but i thought that might as well have an example to talk about ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec build.xml
ggregory2003/05/29 17:42:16
Modified:codecbuild.xml
Log:
Create Javadoc class and package usage pages (assumes Javadoc 1.2+).
Revision ChangesPath
1.4 +101 -175 jakarta-commons/codec/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/codec/build.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- build.xml 30 Apr 2003 13:35:14 - 1.3
+++ build.xml 30 May 2003 00:42:16 - 1.4
@@ -1,179 +1,105 @@
project name=Codec default=compile basedir=.
-
-
-!--
+!--
Codec component of the Jakarta Commons Subproject
$Id$
--
-
-
-!-- == Initialize Properties = --
-
- property file=${user.home}/${component.name}.build.properties /
- property file=${user.home}/build.properties /
- property file=${basedir}/build.properties /
- property file=${basedir}/default.properties /
-
-!-- == Construct compile classpath === --
-
- path id=compile.classpath
-pathelement location=${build.home}/classes/
- /path
-
-!-- == Construct unit test classpath = --
-
- path id=test.classpath
-pathelement location=${build.home}/classes/
-pathelement location=${build.home}/tests/
-pathelement location=${junit.jar}/
- /path
-
-!-- == Executable Targets --
-
- target name=init
- description=Initialize and evaluate conditionals
-echo message= ${component.name} ${component.version} /
-filter token=name value=${component.name}/
-filter token=package value=${component.package}/
-filter token=version value=${component.version}/
- /target
-
-
- target name=prepare depends=init
- description=Prepare build directory
-mkdir dir=${build.home}/
-mkdir dir=${build.home}/classes/
-mkdir dir=${build.home}/conf/
-mkdir dir=${build.home}/tests/
-mkdir dir=${build.home}/test-reports/
- /target
-
-
- target name=static depends=prepare
- description=Copy static files to build directory
-tstamp/
-copy todir=${build.home}/conf filtering=on
- fileset dir=${conf.home} includes=*.MF/
-/copy
- /target
-
-
- target name=compile depends=static
- description=Compile shareable components
-javac srcdir=${source.home}
- destdir=${build.home}/classes
- debug=${compile.debug}
- deprecation=${compile.deprecation}
- optimize=${compile.optimize}
- classpath refid=compile.classpath/
-/javac
-copytodir=${build.home}/classes filtering=on
- fileset dir=${source.home} excludes=**/*.java/
-/copy
- /target
-
-
- target name=clean
- description=Clean build and distribution directories
-deletedir=${build.home}/
-deletedir=${dist.home}/
- /target
-
-
- target name=all depends=clean,compile
- description=Clean and compile all components/
-
-
- target name=javadoc depends=compile
- description=Create component Javadoc documentation
-mkdir dir=${dist.home}/
-mkdir dir=${dist.home}/docs/
-mkdir dir=${dist.home}/docs/api/
-javadoc sourcepath=${source.home}
-destdir=${dist.home}/docs/api
- packagenames=org.apache.commons.*
- author=true
-private=true
-version=true
- doctitle=lt;h1gt;${component.title}lt;/h1gt;
-windowtitle=${component.title} (Version ${component.version})
- bottom=Copyright (c) 2003 - Apache Software Foundation
- classpath refid=compile.classpath/
-/javadoc
- /target
-
-
- target name=dist depends=compile,javadoc
- description=Create binary distribution
-mkdir dir=${dist.home}/
-copy file=../LICENSE
- todir=${dist.home}/
-copy file=${basedir}/RELEASE-NOTES.txt
- todir=${dist.home}/
-antcall target=jar/
- /target
-
-
- target name=jar depends=compile
- description=Create jar
-mkdir dir=${dist.home}/
-mkdir dir=${build.home}/classes/META-INF/
-copy file=../LICENSE
- tofile=${build.home}/classes/META-INF/LICENSE.txt/
-jarjarfile=${dist.home}/${final.name}.jar
-basedir=${build.home}/classes
- manifest=${build.home}/conf/MANIFEST.MF/
- /target
-
-
- target name=install-jar depends=jar
- description=-- Installs jar file in ${lib.repo}
-copy todir=${lib.repo} filtering=no
- fileset dir=${dist.home}
-include
cvs commit: jakarta-commons/codec build.xml
ggregory2003/05/29 17:50:47
Modified:codecbuild.xml
Log:
Javadoc: Use the copyright symbol entity.
Revision ChangesPath
1.5 +3 -3 jakarta-commons/codec/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/codec/build.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.xml 30 May 2003 00:42:16 - 1.4
+++ build.xml 30 May 2003 00:50:47 - 1.5
@@ -2,7 +2,7 @@
!--
Codec component of the Jakarta Commons Subproject
$Id$
---
+--
!-- == Initialize Properties = --
property file=${user.home}/${component.name}.build.properties/
property file=${user.home}/build.properties/
@@ -55,7 +55,7 @@
mkdir dir=${dist.home}/
mkdir dir=${dist.home}/docs/
mkdir dir=${dist.home}/docs/api/
-javadoc sourcepath=${source.home} destdir=${dist.home}/docs/api
packagenames=org.apache.commons.* author=true private=true version=true
doctitle=lt;h1gt;${component.title}lt;/h1gt; windowtitle=${component.title}
(Version ${component.version}) bottom=Copyright (c) 2003 - Apache Software
Foundation use=true
+javadoc sourcepath=${source.home} destdir=${dist.home}/docs/api
packagenames=org.apache.commons.* author=true private=true version=true
doctitle=lt;h1gt;${component.title}lt;/h1gt; windowtitle=${component.title}
(Version ${component.version}) bottom=Copyright amp;copy; 2003 - Apache Software
Foundation use=true
classpath refid=compile.classpath/
/javadoc
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
ggregory2003/05/29 18:00:24
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Javadoc.
Revision ChangesPath
1.45 +10 -9
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- StringUtils.java 16 Apr 2003 04:37:33 - 1.44
+++ StringUtils.java 30 May 2003 01:00:24 - 1.45
@@ -75,6 +75,7 @@
* @author a href=mailto:[EMAIL PROTECTED]Alexander Day Chaffee/a
* @author a href=mailto:[EMAIL PROTECTED]Henning P. Schmiedehausen/a
* @author Arun Mammen Thomas
+ * @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
* @since 1.0
* @version $Id$
*/
@@ -130,7 +131,7 @@
* @see java.lang.String#trim()
* @param str the String to check
* @return the trimmed text (never codenull/code)
- * @deprecated use the clearer named trimToEmpty(String)
+ * @deprecated Use the clearer named [EMAIL PROTECTED] #trimToEmpty(String)}.
*/
public static String clean(String str) {
return (str == null ? : str.trim());
@@ -887,7 +888,7 @@
*
* Note that this behavior has changed from 1.0. It
* now more closely matches Perl chomp. For the previous behavior,
- * use slice(String,String).
+ * use [EMAIL PROTECTED] #slice(String,String)}.
*
* @param str string to chomp from
* @param separator separator string
@@ -911,7 +912,7 @@
* @param str String to chomp from
* @return String without chomped ending
* @throws NullPointerException if str is codenull/code
- * @deprecated use chomp(String) instead
+ * @deprecated Use [EMAIL PROTECTED] #chomp(String)} instead.
*/
public static String chompLast(String str) {
return chompLast(str, \n);
@@ -924,7 +925,7 @@
* @param sep String to chomp
* @return String without chomped ending
* @throws NullPointerException if str or sep is codenull/code
- * @deprecated use chomp(String,String) instead
+ * @deprecated Use [EMAIL PROTECTED] #chomp(String,String)} instead.
*/
public static String chompLast(String str, String sep) {
if (str.length() == 0) {
@@ -947,7 +948,7 @@
* @param sep String to chomp
* @return String chomped
* @throws NullPointerException if str or sep is codenull/code
- * @deprecated use sliceRemainder(String,String) instead
+ * @deprecated Use [EMAIL PROTECTED] #sliceRemainder(String,String)} instead.
*/
public static String getChomp(String str, String sep) {
int idx = str.lastIndexOf(sep);
@@ -968,7 +969,7 @@
* @param sep String to chomp
* @return String without chomped beginning
* @throws NullPointerException if str or sep is codenull/code
- * @deprecated use sliceFirstRemainder(String,String) instead
+ * @deprecated Use [EMAIL PROTECTED] #sliceFirstRemainder(String,String)}
instead.
*/
public static String prechomp(String str, String sep) {
int idx = str.indexOf(sep);
@@ -987,7 +988,7 @@
* @param sep String to chomp
* @return String prechomped
* @throws NullPointerException if str or sep is codenull/code
- * @deprecated use sliceFirst(String) instead
+ * @deprecated Use [EMAIL PROTECTED] #sliceFirst(String,String)} instead.
*/
public static String getPrechomp(String str, String sep) {
int idx = str.indexOf(sep);
@@ -1036,7 +1037,7 @@
* @param str String to chop a newline from
* @return String without newline
* @throws NullPointerException if str is codenull/code
- * @deprecated use chomp(String) instead
+ * @deprecated Use [EMAIL PROTECTED] #chomp(String)} instead.
*/
public static String chopNewline(String str) {
int lastIdx = str.length() - 1;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang SystemUtils.java
ggregory2003/05/29 18:12:26 Modified:lang/src/java/org/apache/commons/lang SystemUtils.java Log: Javadoc. Revision ChangesPath 1.13 +77 -41 jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java Index: SystemUtils.java === RCS file: /home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- SystemUtils.java 24 May 2003 14:34:14 - 1.12 +++ SystemUtils.java 30 May 2003 01:12:26 - 1.13 @@ -84,41 +84,45 @@ //--- /** * The codefile.encoding/code System Property. - * File encoding, such as Cp1252. - * First in JDK version 1.2. - * p - * Defaults to codenull/code if the runtime does not have - * security access to read this property or property not specified. + * pFile encoding, such as codeCp1252/code./p + * + * pDefaults to codenull/code if the runtime does not have + * security access to read this property or property not specified./p + * + * @since Java version 1.2. */ public static final String FILE_ENCODING = getSystemProperty(file.encoding); /** * The codefile.separator/code System Property. * File separator (/ on UNIX). - * First in JDK version 1.1. * p * Defaults to codenull/code if the runtime does not have * security access to read this property or property not specified. + * + * @since Java version 1.1. */ public static final String FILE_SEPARATOR = getSystemProperty(file.separator); /** * The codejava.class.path/code System Property. * Java class path. - * First in JDK version 1.1. * p * Defaults to codenull/code if the runtime does not have * security access to read this property or property not specified. + * + * @since Java version 1.1. */ public static final String JAVA_CLASS_PATH = getSystemProperty(java.class.path); /** * The codejava.class.version/code System Property. * Java class format version number. - * First in JDK version 1.1. * p * Defaults to codenull/code if the runtime does not have * security access to read this property or property not specified. + * + * @since Java version 1.1. */ public static final String JAVA_CLASS_VERSION = getSystemProperty(java.class.version); @@ -129,287 +133,318 @@ * p * Defaults to codenull/code if the runtime does not have * security access to read this property or property not specified. + * + * @since Java version 1.2. Not used in Sun versions after 1.2. */ public static final String JAVA_COMPILER = getSystemProperty(java.compiler); /** * The codejava.ext.dirs/code System Property. * Path of extension directory or directories. - * First in JDK version 1.3. * p * Defaults to codenull/code if the runtime does not have * security access to read this property or property not specified. + * + * @since Java 1.3 */ public static final String JAVA_EXT_DIRS = getSystemProperty(java.ext.dirs); /** * The codejava.home/code System Property. * Java installation directory. - * First in JDK version 1.1. * p * Defaults to codenull/code if the runtime does not have * security access to read this property or property not specified. + * + * @since Java 1.1 */ public static final String JAVA_HOME = getSystemProperty(java.home); /** * The codejava.io.tmpdir/code System Property. * Default temp file path. - * First in JDK version 1.2. * p * Defaults to codenull/code if the runtime does not have * security access to read this property or property not specified. + * + * @since Java 1.2 */ public static final String JAVA_IO_TMPDIR = getSystemProperty(java.io.tmpdir); /** * The codejava.library.path/code System Property. * List of paths to search when loading libraries. - * First in JDK version 1.2. * p * Defaults to codenull/code if the runtime does not have * security access to read this property or property not specified. + * + * @since Java 1.2 */ public static final String JAVA_LIBRARY_PATH = getSystemProperty(java.library.path); /** * The codejava.runtime.name/code System Property. * Java Runtime Environment name. - * First in JDK version 1.3. * p *
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang SystemUtils.java
ggregory2003/05/29 18:15:54
Modified:lang/src/java/org/apache/commons/lang SystemUtils.java
Log:
Sorted members (this also give us the Javadoc 'Field Details' section in
alphabetical order).
Revision ChangesPath
1.14 +251 -251
jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java
Index: SystemUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- SystemUtils.java 30 May 2003 01:12:26 - 1.13
+++ SystemUtils.java 30 May 2003 01:15:53 - 1.14
@@ -69,17 +69,6 @@
* @version $Id$
*/
public class SystemUtils {
-
-/**
- * pSystemUtils instances should NOT be constructed in standard
- * programming. Instead, the class should be used as
- * codeSystemUtils.FILE_SEPARATOR/code./p
- *
- * pThis constructor is public to permit tools that require a JavaBean
- * instance to operate./p
- */
-public SystemUtils() {
-}
//---
/**
@@ -104,6 +93,164 @@
*/
public static final String FILE_SEPARATOR = getSystemProperty(file.separator);
+//---
+/**
+ * Is codetrue/code if this is Java version 1.1 (also 1.1.x versions).
+ * p
+ * The field will return false if codeJAVA_VERSION/code is
codenull/code.
+ */
+public static final boolean IS_JAVA_1_1 = getJavaVersionMatches(1.1);
+
+/**
+ * Is codetrue/code if this is Java version 1.2 (also 1.2.x versions).
+ * p
+ * The field will return false if codeJAVA_VERSION/code is
codenull/code.
+ */
+public static final boolean IS_JAVA_1_2 = getJavaVersionMatches(1.2);
+
+/**
+ * Is codetrue/code if this is Java version 1.3 (also 1.3.x versions).
+ * p
+ * The field will return false if codeJAVA_VERSION/code is
codenull/code.
+ */
+public static final boolean IS_JAVA_1_3 = getJavaVersionMatches(1.3);
+
+/**
+ * Is codetrue/code if this is Java version 1.4 (also 1.4.x versions).
+ * p
+ * The field will return false if codeJAVA_VERSION/code is
codenull/code.
+ */
+public static final boolean IS_JAVA_1_4 = getJavaVersionMatches(1.4);
+
+/**
+ * Is codetrue/code if this is Java version 1.5 (also 1.5.x versions).
+ * p
+ * The field will return false if codeJAVA_VERSION/code is
codenull/code.
+ */
+public static final boolean IS_JAVA_1_5 = getJavaVersionMatches(1.5);
+
+/**
+ * Is codetrue/code if this is AIX.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_AIX = getOSMatches(AIX);
+
+/**
+ * Is codetrue/code if this is HP-UX.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_HP_UX = getOSMatches(HP-UX);
+
+/**
+ * Is codetrue/code if this is Irix.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_IRIX = getOSMatches(Irix);
+
+/**
+ * Is codetrue/code if this is Linux.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_LINUX = getOSMatches(Linux) ||
getOSMatches(LINUX);
+// Windows XP returns 'Windows 2000' just for fun...
+
+/**
+ * Is codetrue/code if this is Mac.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_MAC = getOSMatches(Mac);
+
+/**
+ * Is codetrue/code if this is Mac.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_MAC_OSX = getOSMatches(Mac OS X);
+
+/**
+ * Is codetrue/code if this is Mac.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_OS2 = getOSMatches(OS/2);
+
+/**
+ * Is codetrue/code if this is Solaris.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_SOLARIS = getOSMatches(Solaris);
+
+/**
+ * Is codetrue/code if this is SunOS.
+ * p
+ * The field will return false if codeOS_NAME/code is codenull/code.
+ */
+public static final boolean IS_OS_SUN_OS = getOSMatches(SunOS);
+
+
cvs commit: jakarta-commons-sandbox/jrcs/doc .cvsignore index.html
juanco 2003/05/29 18:45:17
Modified:jrcs build.xml
jrcs/doc index.html
Added: jrcs/doc .cvsignore
Log:
updated web page to reflect recent enhancements
Revision ChangesPath
1.10 +8 -3 jakarta-commons-sandbox/jrcs/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/jrcs/build.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- build.xml 5 May 2003 21:49:28 - 1.9
+++ build.xml 30 May 2003 01:45:17 - 1.10
@@ -122,9 +122,10 @@
property name=java.dir value=${src.dir}/java /
property name=tests.dir value=${src.dir}/test /
property name=lib.dir value=${basedir}/lib /
- property name=dist.dir value=${basedir}/dist /
+ property name=doc.dir value=${basedir}/doc /
+ property name=javadoc value=${doc.dir}/api /
+ property name=dist.dir value=${doc.dir}/dist /
property name=classes value=${basedir}/classes /
- property name=javadoc value=${basedir}/doc/api /
property name=test.classes value=${basedir}/test-classes /
property name=javacc.lib.dir value=${javacc.home}/bin/lib /
@@ -338,5 +339,9 @@
/target
target name=dist depends=compact.dist,full.dist /
+
+ target name=changelog
+ cvschangelog destfile=changelog.xml /
+ /target
/project
1.2 +169 -301 jakarta-commons-sandbox/jrcs/doc/index.html
Index: index.html
===
RCS file: /home/cvs/jakarta-commons-sandbox/jrcs/doc/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html26 May 2003 18:11:30 - 1.1
+++ index.html30 May 2003 01:45:17 - 1.2
@@ -1,302 +1,170 @@
html
- head
-meta name=generator content=Microsoft FrontPage 5.0
-meta name=generator content=Microsoft FrontPage 5.0
-title
- JRCS - A RCS Archive Parser in Java
-/title
-link rel=stylesheet type=text/css href=default.css
- /head
- body
-!--#include file=../software/navbar.html --
-!--#include file=../juanca/navbar.html --
-hr
-h1
- JRCS
-/h1
-h2
- RCS/CVS Archive Manipulation and a Differencing Engine in Java
-/h2
-p
- a href=../jrcs/JRCS/a is a library for parsing and
- manipulation of RCS archive files like the ones produced by RCS
- (Revision Control System) and by CVS (Concurrent Versioning
- System).
-/p
-p
- The home of JRCS is at a href=
- http://www.suigeneris.org/jrcs/;
- http://www.suigeneris.org/jrcs//a.
-/p
-h2Copyright/h2
-p
- On April 2002 I donated the JRCS library to the Apache
- Software Foundation under request of Jason van Zyl. JRCS will now
- be part of the a href=http://jakarta.apache.org/commons;
- Commons/a project at Jakarta/Apache.
-/p
-p
- JRCS is distributed under the
- a href=http://www.apache.org/licenses/LICENSE;Apache Software License
(ASL)/a./p
-h2
- Diff in Java
-/h2
-p
- The library includes a differencing engine that uses a a simple,
- yet fast and effective differencing algorithm that I developed.
- The diff engine can be used by itself to compare the contents of
- any two arrays, whatever their contents (yes, you can compare
- strings, objects, and anything else).
-/p
-h2
- Download
-/h2
-p
- The Jakarta project at Apache has not published JRCS yet, but you
- can get a copy of the new, improved version of JRCS from their
- CVS repository.
-/p
-p
- You can also get copy of the Jakarta distribution of JRCS from
- here:
-/p
-ul
- li
-The a href=dist/jrcs-full-0.1.6.tar.gzfull/a (~330K)
-distribution includes everything you need to use the library,
-including the third party libraries a href=
-http://jakarta.apache.org/oro/;ORO/a, and a href=
-http://www.junit.org;JUnit/a. Precompiled jar files are
-also included. a href=dist/jrcs-full-0.1.6.tar.gz
-[download]/a
- /li
- li
-The a href=dist/jrcs-0.1.6.tar.gzcompact/a (~200K)
-distribution includes everything above except the third party
-libraries, which you can get from their home sites as explained
-below. a href=dist/jrcs-0.1.6.tar.gz[download]/a
- /li
-/ul
-h2Installation/h2
-pUncompress the distribution file to the directory of your choice. The
-precompiled jars can be found under the ./lib directory./p
-h2
- Documentation
-/h2
-p
- The JRCS documentation
DO NOT REPLY [Bug 20345] New: - Directory names starting with numbers parsed improperly with NTFTPEntryParser
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20345. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20345 Directory names starting with numbers parsed improperly with NTFTPEntryParser Summary: Directory names starting with numbers parsed improperly with NTFTPEntryParser Product: Commons Version: 1.0 Final Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Net AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When connecting to a Microsoft FTP Service using MS-DOS directory listings if the directory starts with a number the directory name is parsed incorrectly when using the following: NTFTPEntryParser parser = new NTFTPEntryParser(); FTPFile[] FTPFiles = ftp.listFiles(parser); For example if the directory name is 2003-05-27 the FTPFile[i].getName() returns -05-27. The issue is with the regexp in NTFTPEntryParser. For a quick fix I just slightly modified the 8th group from ([0-9]+)?\\s* to ([0-9]+)?\\s\\s* so the final regexp is as follows: private static final String REGEX = ((?:0[1-9])|(?:1[0-2]))- + ((?:0[1-9])|(?:[1-2]\\d)|(?:3[0-1]))- + (\\d\\d)\\s* + ((?:0[1-9])|(?:1[012])): + ([0-5]\\d)\\s* + ([AP])M\\s* + (DIR)?\\s* + ([0-9]+)?\\s\\s* + (\\S.*); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] sandbox karma for Howard M. Lewis Shiphlship@apache.org
+1, but I'm not really sure if this is a binding vote. Assume, I'm voting as Commons committer *only*. I'm a little confused, my understanding of the current system is: Any Jakarta Committer can simply ask for karma to the sandbox. Someone like Craig usually just makes the appropriate changes to the avail file (or so I assume), and the deal is done. So, Tapestry just navigated the Incubator, and is now a part of Jakarta. Howard is a Jakarta committer, and all he has to do is ask. That's straightforward, no PMC vote, no Commons Committer vote needed. I believe that someone just needs to give him karma - that would be in line with past practices. The confusing part comes in when someone who is not a Jakarta Committer wants access to the commons-sandbox. I think people just wanted non-Jakarta committers to have the approval of the Jakarta PMC before being granted karma. I'm not batting for that side per se, but the PMC maintains an oversight role for new committers (i.e. requests for new accounts come from the PMC) - the opposition in this case just wants the PMC to have some oversight when a non-Jakarta committer requests access. Does that make any sense? In Howard's case, he's a Tapestry committer - I don't see the need for a vote. (which includes a lot of Ant, DB, James, Maven committers On Thu, 2003-05-29 at 18:57, [EMAIL PROTECTED] wrote: +1 -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au robert burrell donkin [EMAIL PROTECTED] wrote on 30/05/2003 07:27:29 AM: Howard M. Lewis Ship (well known as a leading light of the recently incubated tapestry project) would like access to the commons-sandbox in order to work on a new component as outlined below in the following email: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=105416555202303w=2 i'd like to propose that we grant him karma. (i know that the debate about processes is still on going but i thought that might as well have an example to talk about ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jrcs/doc index.html
juanco 2003/05/29 21:03:58 Modified:jrcs/doc index.html Log: fixed links to downloadables Revision ChangesPath 1.3 +354 -168 jakarta-commons-sandbox/jrcs/doc/index.html Index: index.html === RCS file: /home/cvs/jakarta-commons-sandbox/jrcs/doc/index.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- index.html30 May 2003 01:45:17 - 1.2 +++ index.html30 May 2003 04:03:56 - 1.3 @@ -1,170 +1,356 @@ html - -head -meta http-equiv=Content-Language content=en-us -meta name=generator content=Microsoft FrontPage 5.0 -meta name=ProgId content=FrontPage.Editor.Document -meta name=generator content=Microsoft FrontPage 5.0 -titleJRCS - A RCS Archive Parser in Java/title -link rel=stylesheet type=text/css href=default.css -/head - -body - -!--#include file=../software/navbar.html -- -!--#include file=../juanca/navbar.html --hr -h1JRCS /h1 -h2RCS/CVS Archive Manipulation and a Differencing Engine in Java /h2 -pa href=../jrcs/JRCS/a is a library for parsing and manipulation of RCS -archive files like the ones produced by RCS (Revision Control System) and by CVS -(Concurrent Versioning System). /p -pThe home of JRCS is at a href=http://www.suigeneris.org/jrcs/; -http://www.suigeneris.org/jrcs//a. /p -h2Copyright/h2 -pOn April 2002 I donated the JRCS library to the Apache Software Foundation -under request of Jason van Zyl. JRCS will now be part of the -a href=http://jakarta.apache.org/commons;Commons/a project at -Jakarta/Apache. /p -pJRCS is distributed under the -a href=http://www.apache.org/licenses/LICENSE;Apache Software License (ASL)/a./p -h2Diff in Java /h2 -pThe library includes a framework for pluggable differencing engines. -Currently, two algorithms are implemented:/p -ul - liA simple, fast, memory conscious, but suboptimal algorithm by me./li - liThe a href=http://www.cs.arizona.edu/people/gene/PAPERS/diff.ps;Eugene - Myers/a algorithm that produces optimal results./li -/ul -pThe diff engine can be used by itself to compare the contents of any two -arrays, whatever the underlying type./p -h2Download /h2 -pThe Jakarta project at Apache has not published JRCS yet, but you can get a -copy of the new, improved version of JRCS from their CVS repository. /p -pYou can also get copy of the Jakarta distribution of JRCS from here: /p -ul - liThe a href=dist/jrcs-full-0.1.6.tar.gzfull/a (~330K) distribution - includes everything you need to use the library, including the third party - libraries a href=http://jakarta.apache.org/oro/;ORO/a, and - a href=http://www.junit.org;JUnit/a. Precompiled jar files are also - included. a href=dist/jrcs-full-0.1.6.tar.gz[download]/a /li - liThe a href=dist/jrcs-0.1.6.tar.gzcompact/a (~200K) distribution - includes everything above except the third party libraries, which you can get - from their home sites as explained below. a href=dist/jrcs-0.1.6.tar.gz - [download]/a /li -/ul -h2Installation/h2 -pUncompress the distribution file to the directory of your choice. The -precompiled jars can be found under the ./lib directory./p -h2Documentation /h2 -pThe JRCS documentation consists of the API documentation generated by JavaDoc. -There's a a href=doc/api/local copy/a of the documentation accessible from -this site. /p -pIn the lack of a user manual, I recommend you examine the test suite classes -as found in the code./tests/code directory in the distribution. /p -h2Third party stuff used/required by JRCS /h2 -h3JUnit /h3 -pThe library tests are written for the JUnit Testing Framework. For -distributions and documentation of JUnit see a href=http://www.junit.org/; -http://www.junit.org//a. /p -h3ORO Regexp /h3 -pThe Jakarta ORO regexp library is used for RCS keyword management. You can -get a copy of ORO from a href=http://jakarta.apache.org/oro/; -http://jakarta.apache.org/oro//a. A copy of ORO regexp is included in the full -distribution of this library. /p -pThe a href=http://jakarta.apache.org/oro;ORO/a regexp package replaced -GNU Regexp in the new version of JRCS. /p -h3Ant /h3 -pJakarta Ant is used for building the JRCS library. Ant is the Jakarta -project's build tool. You can get a copy of Ant from -a href=http://jakarta.apache.org/ant/;http://jakarta.apache.org/ant//a. /p -pYou'll need to also download the optional Ant tasks if you'll be running -JUnit or JavaCC (more info on JavaCC below). /p -h3JavaCC /h3 -pThe RCS parser is constructed using the -a href=http://www.webgain.com/products/java_cc/;JavaCC/a compiler compiler. -You can get a copy of a href=http://www.webgain.com/products/java_cc/;JavaCC/a -from a href=http://www.webgain.com/products/java_cc/;
[fileupload] [proposal] lib property in build.xml
Hi all, I am working on packaging fileupload to Debian. Because of some requierments in Debian, I have to specify the CLASSPATH my self (or tell to ant where it is). But I do not have any lib directory, so ant craches. I've been obliged to comment the additionnal classpath information in the javac task. My proposal is to change the reference to the lib directory to a reference to a property so I can override it from my ant call. Thanks for your time, -- Arnaud Vandyck, STE fi, ULg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - commons-jxpath
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-05-30/commons-jxpath.html
Buildfile: build.xml
check_available:
init:
[echo] jxpath 20030530
[echo] junit.jar = /home/rubys/jakarta/dist/junit/junit.jar
[echo] jaxp.jaxp.jar =
/home/rubys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar
[echo] jaxp.xslt.jar =
/home/rubys/jakarta/xml-xalan/java/build/xalan-unbundled.jar
[echo] servlet.jar = ${servlet.jar}
[echo] commons-beanutils.jar = ${commons-beanutils.jar}
[echo] commons-collections.jar = ${commons-collections.jar}
[echo] commons-logging.jar = ${commons-logging.jar}
check.junit:
check.jaxp.jaxp:
check.jaxp.xslt:
check.servlet:
prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/jxpath/target
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/jxpath/target/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/jxpath/target/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/jxpath/target/tests
static:
[copy] Copying 1 file to /home/rubys/jakarta/jakarta-commons/jxpath/target/conf
[copy] Replacing: @name@ - jxpath
[copy] Replacing: @version@ - 20030530
compile:
[javac] Compiling 153 source files to
/home/rubys/jakarta/jakarta-commons/jxpath/target/classes
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNamespaceIterator.java:110:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] Element parent = element.getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:511:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((Element) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:514:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((Text) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:517:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((CDATA) node).getParent();
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:520:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((ProcessingInstruction) node).getParent();
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:523:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((Comment) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:667:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] Element parent = ((Element) node).getParent();
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:692:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] parent = ((Text) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:695:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] parent = ((CDATA) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:715:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] Element parent = ((ProcessingInstruction) node).getParent();
[javac
DO NOT REPLY [Bug 20354] New: - [telnet] unable to register option hamdlers if option 39
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20354. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20354 [telnet] unable to register option hamdlers if option 39 Summary: [telnet] unable to register option hamdlers if option 39 Product: Commons Version: 1.0 Final Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Net AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the TelnetOption class the following costants are declared public static final int MAX_OPTION_VALUE = 255; public static int NEW_ENVIRONMENT_VARIABLES = 39; private static int __LAST_OPTION = NEW_ENVIRONMENT_VARIABLES; Setting __LAST_OPTION = NEW_ENVIRONMENT_VARIABLES prevents any registration of option handlers if option code is 39(a InvalidTelnetOptionException is rised with error Invalid Option Code). A workaround is changing the LAST_OPTION declaration to private static int __LAST_OPTION = MAX_OPTION_VALUE; but this only partially fix the problem because the getOption() method, which converts option code to name, will fail if the table size and content are not updated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java can leak...
I think the reality here is that the only way to reliably track down the problem is to actually profile the original application that is seeing the problem. There's really not a lot of point in me profiling HttpClient separately because I've not seen any problem with memory leaks so they're not likely to suddenly turn up in profiling. The particular way HttpClient is being used is likely what's bringing out the leak whether the leak is caused by HttpClient code or not. Jan, if you could do some profiling work on your application to identify at least (a) that it is that particular app and not something else on the machine (pretty easy) (b) what types of objects are hanging around and (c) what's still got a reference on them, that would really help track down the problem. The profiling that we've done on our app doesn't show any indication of a problem with HttpClient but the way we use HttpClient is extremely different. Regards, Adrian Sutton. On Friday, May 30, 2003, at 08:49 AM, Wilcox, Mark wrote: Jan, Good point. With Java you don't have to remember as much about silly things like malloc and free in C/C++ which led to all sorts of problems. However, you do have to worry about GC, object creation and holding on to objects for too long. Something like HPJMeter may help in analyzing the problem: http://www.hp.com/products1/unix/java/developers/hpjmeter.html Mark -Original Message- From: Jan Gonsalves [mailto:[EMAIL PROTECTED] Sent: Thu 5/29/2003 6:09 PM To: Commons HttpClient Project Cc: Subject: Java can leak... Oleg, I understand what you mean my mem alloc, but Java can leak, it's a proven fact. Anytime ROOT has a reference to something it makes it unable to GC, however, if you loose your reference and ROOT still has it's, that's a memory leak. ROOT will never GC that memory. Ask youself this, if Memory leaks were impossible in JAVA, how can programs such as JProfiler or OptimizIt sell? Jan Oleg Kalnichevski wrote: Jan, HttpClient is a pure Java application and as such does not manage memory allocation directly. I suggest that you check if there are any known issues with the jvm you are using. Upgrading to HttpClient beta-1 would not hurt, anyways. Oleg On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote: Does anyone know of any memory issues with opening a connection and continuely re-using it, only closing it when a socket timeout happens? I'm currently using ALPHA 3. I have to fake out a browser and navigate through a website to extract information because they don't offer a straight DB connection. I re-use this connection the whole time, never closing it, only recycling it, unless I get a socket timeout, ConnectionException, or HTTPRecoverableException. Our Production server has 4GB of ram. Last night we ran and the system went down to 4MB free, 4! I'm just wondering if I'm leaking due to HTTP Client. I've gone over my stuff and it looks relatively solid, I'm wondering now if I'm using HttpClient incorrectly. Does Beta 1 help with any memory issues? Jan Gonsalves - 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: Java can leak...
My impression of your first email was that the server had used up the 4GB of memory. Are you saying it was HttpClient? If so, you must have run the JVM and specified the max heap size to something like -Xmx4GB. If that's the case then this is probably something you don't want to do. Once Java gets over the minimum heap size, specified by -Xms, it will continue to expand all the way up to the max, even if it doesn't need to. Once the JVM allocates memory to the heap it never releases it. Is this what's happening? Mike On Thursday, May 29, 2003, at 06:09 PM, Jan Gonsalves wrote: Oleg, I understand what you mean my mem alloc, but Java can leak, it's a proven fact. Anytime ROOT has a reference to something it makes it unable to GC, however, if you loose your reference and ROOT still has it's, that's a memory leak. ROOT will never GC that memory. Ask youself this, if Memory leaks were impossible in JAVA, how can programs such as JProfiler or OptimizIt sell? Jan Oleg Kalnichevski wrote: Jan, HttpClient is a pure Java application and as such does not manage memory allocation directly. I suggest that you check if there are any known issues with the jvm you are using. Upgrading to HttpClient beta-1 would not hurt, anyways. Oleg On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote: Does anyone know of any memory issues with opening a connection and continuely re-using it, only closing it when a socket timeout happens? I'm currently using ALPHA 3. I have to fake out a browser and navigate through a website to extract information because they don't offer a straight DB connection. I re-use this connection the whole time, never closing it, only recycling it, unless I get a socket timeout, ConnectionException, or HTTPRecoverableException. Our Production server has 4GB of ram. Last night we ran and the system went down to 4MB free, 4! I'm just wondering if I'm leaking due to HTTP Client. I've gone over my stuff and it looks relatively solid, I'm wondering now if I'm using HttpClient incorrectly. Does Beta 1 help with any memory issues? Jan Gonsalves - 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: Java can leak...
We need to do more investigation on our side for sure, I just wanted to know if anyone had noticed memory leaks over long recycled connections. The JVM my app runs in alots 768Mb as the max, but I work in conjunction with serveral apps. I'm the only app using HttpClient. When I run and I really get going processing large chunks of data memory usage for the system really takes a hit. My personal memory footprint based off qps for linux says I max out at about 380mb. If I loose a reference to an object ROOT has, does that count against my memory usage or does that consume memory but no under a particular JVM? My personal belief is that my app does things a new way in our system and I'm putting stress on other objects in the system that aren't normally accustomed to it and they are having difficulty. Anyone know of a good, user friendly (read inexperienced to memory profilling) application? Jan Michael Becke wrote: My impression of your first email was that the server had used up the 4GB of memory. Are you saying it was HttpClient? If so, you must have run the JVM and specified the max heap size to something like -Xmx4GB. If that's the case then this is probably something you don't want to do. Once Java gets over the minimum heap size, specified by -Xms, it will continue to expand all the way up to the max, even if it doesn't need to. Once the JVM allocates memory to the heap it never releases it. Is this what's happening? Mike On Thursday, May 29, 2003, at 06:09 PM, Jan Gonsalves wrote: Oleg, I understand what you mean my mem alloc, but Java can leak, it's a proven fact. Anytime ROOT has a reference to something it makes it unable to GC, however, if you loose your reference and ROOT still has it's, that's a memory leak. ROOT will never GC that memory. Ask youself this, if Memory leaks were impossible in JAVA, how can programs such as JProfiler or OptimizIt sell? Jan Oleg Kalnichevski wrote: Jan, HttpClient is a pure Java application and as such does not manage memory allocation directly. I suggest that you check if there are any known issues with the jvm you are using. Upgrading to HttpClient beta-1 would not hurt, anyways. Oleg On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote: Does anyone know of any memory issues with opening a connection and continuely re-using it, only closing it when a socket timeout happens? I'm currently using ALPHA 3. I have to fake out a browser and navigate through a website to extract information because they don't offer a straight DB connection. I re-use this connection the whole time, never closing it, only recycling it, unless I get a socket timeout, ConnectionException, or HTTPRecoverableException. Our Production server has 4GB of ram. Last night we ran and the system went down to 4MB free, 4! I'm just wondering if I'm leaking due to HTTP Client. I've gone over my stuff and it looks relatively solid, I'm wondering now if I'm using HttpClient incorrectly. Does Beta 1 help with any memory issues? Jan Gonsalves - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: BETA-1 is officially out
go for it -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Michael Becke [EMAIL PROTECTED] wrote on 30/05/2003 12:24:31 PM: Yes, I have it if you would like. Should I upload it to cvs.apache.org and make it readable? Mike On Thursday, May 29, 2003, at 10:17 PM, [EMAIL PROTECTED] wrote: Will hopefully get to this today. Have downloaded jdk 1.2.2 to build the dist., but if you guys have one ready to go, please email it to me. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Michael Becke [EMAIL PROTECTED] wrote on 29/05/2003 10:35:58 PM: If you could also push the distribution to http://jakarta.apache.org/builds/jakarta-commons/release/commons- httpclient/v2.0/ that would be good. The newly published site now references this directory for downloading Beta 1. Thanks for your help dIon. Mike On Thursday, May 29, 2003, at 02:55 AM, [EMAIL PROTECTED] wrote: Unless Jeff comes back into the fold in the short term, I'll happily help here. I'll start by checking out the tagged code and doing a maven site:deploy. Let me know if there are problems with this -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - Forwarded by dIon Gillard/Multitask Consulting/AU on 29/05/2003 04:52 PM - Michael Becke [EMAIL PROTECTED] wrote on 29/05/2003 11:13:40 AM: dIon, Any assistance that you could lend would be greatly appreciated. Pretty much everything that we can take care of has been done. We've tagged the release, tested the code, updated the site docs, and written an announcement. I think all that's left to be done is run maven to generate the new site and distribution, upload the new files, add the news item, and mail a notice to the usual mailing lists. The code has been tagged as HTTPCLIENT_2_0_BETA1. The announcement is below (note that one link still needs to be added). Jeff wrote release procedures for the last release if you would like to take a look at them (http://jakarta.apache.org/commons/httpclient/releases.html). Please let us know if you have any questions. Thank you, Mike release announcement - The Commons team is pleased to announce the first feature complete Beta 1 release of Commons HttpClient 2.0 from the Apache Software Foundation. Commons HttpClient is an Open Source implementation of the Hyper-Text Transfer Protocol(HTTP), one of the most widely used communication protocols underpinning the World Wide Web. This release contains a number of bug fixes and feature enhancements. For more details please see the release notes(LINK HERE). Source and binary distributions are available from the main Jakarta site http://jakarta.apache.org/builds/jakarta-commons/release/commons- httpclient/v2.0/. Please see the HttpClient http://jakarta.apache.org/commons/httpclient/ web site for more information. end of release announcement - On Wednesday, May 28, 2003, at 07:59 PM, [EMAIL PROTECTED] wrote: Oleg, I probably have permissions on the jakarta site and file directories too...Let me know if I can help. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Kalnichevski, Oleg [EMAIL PROTECTED] wrote on 29/05/2003 01:29:07 AM: Folks Beta-1 has been tagged on the CVS trunk two days ago and is officially out. The problem is that we are unable to deploy the official build without Jeff Jandalf, our project lead, as only he has necessary access permissions for the official Jakarta file repository web site. You can still obtain beta-1 snapshot from the CVS directly by running the following command: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co -r HTTPCLIENT_2_0_BETA1 jakarta-commons/httpclient Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: 2.0-beta1 files have been uploaded
Does anyone else have access to jakarta-site2? I do, but I'd rather take the input from the team for the release details. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au [EMAIL PROTECTED] wrote on 30/05/2003 02:07:42 PM: Done. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - 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: Re: Help on client authentication
Sorry for the delay. Typically in an SSL transaction the client
wants to authenticate the server (validating server certificates).
However in the case of mutual client authentication the server
also authenticates the client (using client certificates) in
addition to the client authenticating the server . Checkout
http://java.sun.com/j2se/1.4.1/docs/guide/security/jsse/JSSERefGuide.html
and
http://java.sun.com/j2se/1.4.1/docs/guide/security/jsse/samples/sockets/client/SSLSocketClientWithClientAuth.java
for more info on this.
My problem relates to a SocketException when I run a custom ssl
socket factory with client authentication.
In a previous release of http client, the HttpClient class had a
setSSLSocketFactory method. So we used to be able to create a
custom SSLSocketFactory that supported client Authentication and
set it to be used with an instance HttpClient class. Something
like-
HttpClient hc = new HttpClient();
try
{
SSLContext ctx;
KeyManagerFactory kmf;
KeyStore ks;
char[] passphrase = passphrase.toCharArray();
ctx = SSLContext.getInstance(TLS);
kmf = KeyManagerFactory.getInstance(SunX509);
ks = KeyStore.getInstance(JKS);
ks.load(new FileInputStream(testkeystore),
passphrase);
kmf.init(ks, passphrase);
ctx.init(kmf.getKeyManagers(), null, null);
SSLSocketFactory factory = ctx.getSocketFactory();
hc.setSSLSocketFactory(factory);
}
catch (Exception e)
{
throw new IOException(e.getMessage());
}
Then use get and PostMethod...
In HttpClient 2.0 beta1, I tried to create a
CustomSocketFactory on similar lines to
EasySSLProtocolSocketFactory example provided at
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/
Something like..
class MyFactory implements SecureProtocolSocketFactory
{
private javax.net.ssl.SSLSocketFactory factory;
MyFactory()
{
mFactory = getFactoryWithClientAuth();
}
private static SSLSocketFactory
getFactoryWithClientAuth()
{
...//same way as in Jsse example
}
public Socket createSocket(Socket socket,String host,
int port, boolean autoClose)
throws IOException,UnknownHostException
{
return mFactory.createSocket( socket, host,
port,
autoClose);
}
// implement the rest of createSocket Methods similarly as
above
.
}
I then used to post stuff.
PostMethod post = new PostMethod(postServerUrl);
post.setRequestBody(Test http client);
post.setRequestHeader(Content-type, text/plain);
Protocol strictHttps = new Protocol( https, new MyFactory(),
443);
HttpClient client = new HttpClient();
HostConfiguration hostc = new HostConfiguration();
hostc.setHost(ServerUrl,443,strictHttps);
client.executeMethod(hostc,post);
When I ran the second example against 2.0 Beta1, the protocol
interactions in the out seem to be correct,
I saw all the SSL handshake stuff work correctly...
*** ClientHello, v3.1
*** ServerHello, v3.1
*** Certificate chain
*** CertificateRequest
*** ServerHelloDone
*** ClientKeyExchange
*** CertificateVerify
*** Finished, v3.1
except just after the last stage when its about to the actual
post I get
*** Finished, v3.1
verify_data: { 98, 86, 46, 20, 159, 191, 251, 102, 9, 201, 95,
201 }
***
[write] MD5 and SHA1 hashes: len = 16
: 14 00 00 0C 62 56 2E 14 9F BF FB 66 09 C9 5F C9
bV.f.._.
Plaintext before ENCRYPTION: len = 32
: 14 00 00 0C 62 56 2E 14 9F BF FB 66 09 C9 5F C9
bV.f.._.
0010: A2 FE 98 4F 4D E1 1B AD 0D 74 DD 5A 44 54 E9 3D
...OMt.ZDT.=
main, WRITE: SSL v3.1 Handshake, length = 32
2003/05/30 01:02:59:124 EDT [TRACE] HttpConnection - -enter
HttpConnection.close()
2003/05/30 01:02:59:124 EDT [TRACE] HttpConnection - -enter
HttpConnection.closeSockedAndStreams()
main, SEND SSL v3.1 ALERT: warning, description = close_notify
Plaintext before ENCRYPTION: len = 18
: 01 00 AB 04 44 A2 B3 5D A4 89 16 62 F8 11 47 D6
D..]...b..G.
0010: A6 E4 ..
main, WRITE: SSL v3.1 Alert, length = 18
2003/05/30 01:02:59:124 EDT [TRACE] HttpConnection - -enter
HttpConnection.close()
2003/05/30 01:02:59:124 EDT [TRACE] HttpConnection - -enter
HttpConnection.closeSockedAndStreams()
java.net.SocketException: Software caused connection abort:
JVM_recv in socket input stream read
at java.net.SocketInputStream.socketRead0(Native
Method)
at
java.net.SocketInputStream.read(SocketInputStream.java:116)
at
com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA6275)
at
com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at
RE: Java can leak...
Jan, Let me elaborate. No doubt one can still do silly things in Java that may lead to severe memory problems. However, the point I was trying to make is that Java applications do not 'leak' memory in a way non-GC applications do. One can easily starve a java application of heap memory if object allocation de-allocation strategy is flawed. However, no java application should ever consume memory above the limit specified with -Xmx option, unless there is a bug in JVM. I guess you should try narrowing down the problem somewhat. At the moment all we can do is to speculate. If you absolutely positive that the problem is somehow triggered by HttpClient, please let us know some more details on your application's execution environment: OS version, JVM version, application server or servlet engine used, and so on. Oleg -Original Message- From: Jan Gonsalves [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 00:09 To: Commons HttpClient Project Subject: Java can leak... Oleg, I understand what you mean my mem alloc, but Java can leak, it's a proven fact. Anytime ROOT has a reference to something it makes it unable to GC, however, if you loose your reference and ROOT still has it's, that's a memory leak. ROOT will never GC that memory. Ask youself this, if Memory leaks were impossible in JAVA, how can programs such as JProfiler or OptimizIt sell? Jan Oleg Kalnichevski wrote: Jan, HttpClient is a pure Java application and as such does not manage memory allocation directly. I suggest that you check if there are any known issues with the jvm you are using. Upgrading to HttpClient beta-1 would not hurt, anyways. Oleg On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote: Does anyone know of any memory issues with opening a connection and continuely re-using it, only closing it when a socket timeout happens? I'm currently using ALPHA 3. I have to fake out a browser and navigate through a website to extract information because they don't offer a straight DB connection. I re-use this connection the whole time, never closing it, only recycling it, unless I get a socket timeout, ConnectionException, or HTTPRecoverableException. Our Production server has 4GB of ram. Last night we ran and the system went down to 4MB free, 4! I'm just wondering if I'm leaking due to HTTP Client. I've gone over my stuff and it looks relatively solid, I'm wondering now if I'm using HttpClient incorrectly. Does Beta 1 help with any memory issues? Jan Gonsalves - 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: 2.0-beta1 files have been uploaded
Awesome. Thanks for the help dIon. I'm not sure about site2. How could one determine this? Mike On Friday, May 30, 2003, at 12:17 AM, [EMAIL PROTECTED] wrote: Does anyone else have access to jakarta-site2? I do, but I'd rather take the input from the team for the release details. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au [EMAIL PROTECTED] wrote on 30/05/2003 02:07:42 PM: Done. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - 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]
