Re: Changing the groupId for commons-io
I've given up having any clue. If I'm the RM for IO whatever and the changed groupId becomes a blocker, then I'll roll it back. Otherwise sure why not. Hen On 3/13/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, would anyone mind if I change the groupId of commons-io to org.apache.commons? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - 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]
[jira] Resolved: (IO-116) Replace static FileCleaner methods
[ https://issues.apache.org/jira/browse/IO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved IO-116. Resolution: Fixed Applied. Henri, I did not pick up your suggestion to put the test case into FileCleaner itself. It seems to be to unusual to me and personally I do prefer a clean separation between test and tested code. If anyone starts this style elsewhere, I am ready to change that later. > Replace static FileCleaner methods > -- > > Key: IO-116 > URL: https://issues.apache.org/jira/browse/IO-116 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.3.1 >Reporter: Jochen Wiedmann >Priority: Critical > Fix For: 1.4 > > Attachments: commons-io-filecleaningtracker.patch, > commons-io-filecleaningtracker.patch > > > The attached patch aims to finally resolve the problems, which are named in > IO-99, FILEUPLOAD-120, and FILEUPLOAD-125. > I choosed a conservative strategy: Basically I copied the FileCleaner class > to an instantiable class FileCleaningTracker with instance methods. The > static FileCleaner methods are now implemented by a static instance of > FileCleaningTracker. (The name FileCleaningTracker is, of course, > questionable. > The FileCleaningTestCase was also created by simply copying FileCleaner to > FileCleaningTestCase. FileCleanerTestCase is now similarly implemented as a > subclass of FileCleanerTestCase which uses the static instance of FileCleaner > rather than a dynamically created instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changing the groupId for commons-io
Hi, would anyone mind if I change the groupId of commons-io to org.apache.commons? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r518041 - in /jakarta/commons/proper/io/trunk: ./ src/changes/ src/java/org/apache/commons/io/ src/test/org/apache/commons/io/ xdocs/
Author: jochen
Date: Tue Mar 13 23:50:03 2007
New Revision: 518041
URL: http://svn.apache.org/viewvc?view=rev&rev=518041
Log:
Created the FileCleaningTracker, basically a non-static
version of the FileCleaner, which can be controlled by
the user.
PR: IO-116
Added:
jakarta/commons/proper/io/trunk/src/changes/
jakarta/commons/proper/io/trunk/src/changes/changes.xml
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaningTracker.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileCleaningTrackerTestCase.java
jakarta/commons/proper/io/trunk/xdocs/upgradeto1_4.xml
Modified:
jakarta/commons/proper/io/trunk/ (props changed)
jakarta/commons/proper/io/trunk/pom.xml
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileCleanerTestCase.java
Propchange: jakarta/commons/proper/io/trunk/
--
--- svn:ignore (original)
+++ svn:ignore Tue Mar 13 23:50:03 2007
@@ -9,3 +9,4 @@
.checkstyle
bin
*.log
+.settings
Modified: jakarta/commons/proper/io/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/pom.xml?view=diff&rev=518041&r1=518040&r2=518041
==
--- jakarta/commons/proper/io/trunk/pom.xml (original)
+++ jakarta/commons/proper/io/trunk/pom.xml Tue Mar 13 23:50:03 2007
@@ -131,7 +131,11 @@
Java Developer
-
+
+ Jochen Wiedmann
+ jochen
+ [EMAIL PROTECTED]
+
@@ -220,4 +224,23 @@
+
+
+
+org.apache.maven.plugins
+maven-changes-plugin
+
+ %URL%/../%ISSUE%
+
+
+
+
+ changes-report
+ jira-report
+
+
+
+
+
+
Added: jakarta/commons/proper/io/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/changes/changes.xml?view=auto&rev=518041
==
--- jakarta/commons/proper/io/trunk/src/changes/changes.xml (added)
+++ jakarta/commons/proper/io/trunk/src/changes/changes.xml Tue Mar 13 23:50:03
2007
@@ -0,0 +1,50 @@
+
+
+
+
+
+
+
+Release Notes
+
+
+
+
+
+Created the FileCleaningTracker, basically a non-static
+version of the FileCleaner, which can be controlled by
+the user.
+
+
+
+
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java?view=diff&rev=518041&r1=518040&r2=518041
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
Tue Mar 13 23:50:03 2007
@@ -17,10 +17,6 @@
package org.apache.commons.io;
import java.io.File;
-import java.lang.ref.PhantomReference;
-import java.lang.ref.ReferenceQueue;
-import java.util.Collection;
-import java.util.Vector;
/**
* Keeps track of files awaiting deletion, and deletes them when an associated
@@ -39,25 +35,13 @@
* @author Noel Bergman
* @author Martin Cooper
* @version $Id$
+ * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker}
*/
public class FileCleaner {
-
-/**
- * Queue of Tracker instances being watched.
- */
-static ReferenceQueue /* Tracker */ q = new ReferenceQueue();
/**
- * Collection of Tracker instances in existence.
+ * The instance to use for the deprecated, static methods.
*/
-static Collection /* Tracker */ trackers = new Vector(); // synchronized
-/**
- * Whether to terminate the thread when the tracking is complete.
- */
-static volatile boolean exitWhenFinished = false;
-/**
- * The thread that will clean up registered files.
- */
-static Thread reaper;
+static final FileCleaningTracker theInstance = new FileCleaningTracker();
//---
/**
@@ -68,9 +52,10 @@
* @param file the file to be tracked, not null
* @param marker the marker object used to track the file, not null
* @throws NullPointerException if the file is null
+ * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(File,
Object)}.
*/
public static void track(File file, Object marker) {
-track(file, marker, (FileDeleteStrategy) null);
+theInstance.track(file, marker);
}
/**
@@ -82,12 +67,10 @@
* @param marker the marker object used to track the file, not null
* @pa
[jira] Updated: (EMAIL-65) MIME layout generated by HtmlEmail causes trouble
[
https://issues.apache.org/jira/browse/EMAIL-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Morten Hattesen updated EMAIL-65:
-
Description:
Previous bugs (e.g. http://issues.apache.org/jira/browse/EMAIL-50 ) raised
against commons-email version 1.0 have complained about Outlook not being able
to properly display multipart emails generated by HtmlEmail. While this issue
is resolved as of rev 510708, I believe there a several issues regarding MIME
layout, that still cause trouble to email clients.
In the current codebase, a multipart email containing: plaintext part, html
part, inline images and attachments, is constructed (to the best of my
knowledge) with a MIME layout like this:
Generated by HtmlEmail. Contains parts: plaintext, html, embedded inline img,
attach
PART#, MIME_TYPE, (COMMENTS)
1 multipart/related
1.1 multipart/alternative
1.1.1 text/plain (the plaintext content)
1.1.2 text/html (the html content with cid: references to embedded images)
1.2+ */* (attachment)
1.3+ image/* (embedded image, referenced by 1.1.2)
("+" above indicates that multiple (1..n) parts may be included)
The above structure may cause email clients to display embedded images as
attachments, even though they are semantically part of the text/html content.
Furthermore, the current codebase (as documented in the HtmlEmail.setMsg()
JavaDoc) synthesizes a html part by ... wrapping the plaintext part,
thus generating a bloated (double size) message, for no apparent reason. In my
opinion, HtmlEmail should degrade to the mime layout of Email, if no html part
is available.
Proposed MIME layout
--
To the best of my knowledge, a multipart email containing: plaintext part, html
part, inline images and attachments, should be constructed like so:
PART#, MIME_TYPE, (COMMENTS)
1. multipart/mixed
1.1 multipart/related
1.1.1 multipart/alternative
1.1.1.1 text/plain (the plaintext content)
1.1.1.2 text/html (the HTML content with cid: references to embedded images)
1.1.2+ image/* (embedded image, referenced by 1.1.1.2)
1.2+ */* (attachment)
The following simplifications of the above structure may be applied:
a. If no embedded images are included, items 1.1.2+ and 1.1 are removed.
b. if no text/html part is included, items 1.1.1.2 and 1.1.1 are removed
c. if no attachments are included, items 1.2+ and 1 are removed
Incidentially, this MIME layout is used by GMail, which is an indication that
it is the "proper" way.
I seriously believe that this issue should be investigated and resolved, if at
all possible, as part of version 1.1.
I may be able to supply a patch to HtmlEmail.java in the April/May 2007
timeframe, but I am not prepared to put any body parts on the block on that one
;-)
I welcome any comments!
Morten Hattesen
References:
See http://en.wikipedia.org/wiki/MIME for additional information and references
was:
Previous bugs (e.g. http://issues.apache.org/jira/browse/EMAIL-50 ) raised
against commons-email version 1.0 have complained about Outlook not being able
to properly display multipart emails generated by HtmlEmail. While this issue
is resolved as of rev 510708, I believe there a several issues regarding MIME
layout, that still cause trouble to email clients.
In the current codebase, a multipart email containing: plaintext part, html
part, inline images and attachments, is constructed (to the best of my
knowledge) with a MIME layout like this:
PART#, MIME_TYPE, (COMMENTS)
1 multipart/alternative
1.1 text/plain (the plaintext content)
1.2 text/html (the html content with cid: references to embedded images)
2+ image/* (embedded image, referenced by 1.2)
3+ */* (attachment)
("+" above indicates that multiple (1..n) parts may be included)
The above structure may cause email clients to display embedded images as
attachments, even though they are semantically part of the text/html content.
Furthermore, the current codebase (as documented in the HtmlEmail.setMsg()
JavaDoc) synthesizes a html part by ... wrapping the plaintext part,
thus generating a bloated (double size) message, for no apparent reason. In my
opinion, HtmlEmail should degrade to the mime layout of Email, if no html part
is available.
Proposed MIME layout
To the best of my knowledge, a multipart email containing: plaintext part, html
part, inline images and attachments, should be constructed like so:
PART#, MIME_TYPE, (COMMENTS)
1. multipart/mixed
1.1 multipart/related
1.1.1 multipart/alternative
1.1.1.1 text/plain (the plaintext content)
1.1.1.2 text/html (the HTML content with cid: references to embedded images)
1.1.2+ image/* (embedded image, referenced by 1.1.1.2)
1.2+ */* (attachment)
The following simplifications of the above structure may be applied:
a. If no embedded images are included, items 1.1.2+ and 1.1 are removed.
b. if no text/html part is included, items 1.1.1.2 and 1.1
Re: [logging] 1.1.1 release?
On 13/03/07, Henri Yandell <[EMAIL PROTECTED]> wrote: On 3/12/07, Julius Davies <[EMAIL PROTECTED]> wrote: > Hi, > > I've had the same problem. I *cannot* get 1.2 running on linux anymore. > > I hate to say it but the only way I can get 1.2 going these days > is by installing it on Windows. Installs really nicely, to tell the > truth. Yup. I hear you can patch your glibc on Linux, but I went with Windows for 1.2. Except I decided to be clever and install all versions on there and that screwed things up for some reason (1.6 was being too smart). Seems to work now though, so I can wince and do a build on Windows. The install process puts a copy of java.exe (and javaw.exe) in windows\system32 which can appear earlier in the classpath than your desired Java directory ... == I find it useful to define variables for each of the installed Javas(eg): JAVA142_HOME=C:\j2sdk1.4.2_13 JAVA150_HOME=C:\jdk1.5.0_11 JAVA160_HOME=C:\jdk1.6.0 I can then define JAVA_HOME as one of those, and add JAVA_HOME\bin to the path. I've got some JAVAxxx.CMD files that I use in DOS boxes to set the appropriate version - you're welcome to a copy, just let me know. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-65) MIME layout generated by HtmlEmail causes trouble
[
https://issues.apache.org/jira/browse/EMAIL-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480565
]
Morten Hattesen commented on EMAIL-65:
--
After a careful review of the current codebase (HtmlEmail.java rev 511673,
MultiPartEmail.java rev 517714), I have discovered, that the MIME layout
generated is not quite as described in my previous posting.
In many circumstances both HtmlEmail and MultiPartEmail generates MIME
structures that do not conform to MIME recommendations.
Below, I have listed the MIME structures generated, as well as how I believe
they should have been.
Example 1:
Generated by HtmlEmail. Contains parts: plaintext
PART#, MIME_TYPE, (COMMENTS)
1 multipart/related (WRONG!)
1.1 text/plain (the plaintext content)
Should have been:
PART#, MIME_TYPE, (COMMENTS)
1 text/plain (the plaintext content)
Example 2:
Generated by HtmlEmail. Contains parts: plaintext, html
PART#, MIME_TYPE, (COMMENTS)
1 multipart/related (WRONG!)
1.1 text/plain (the plaintext content)
1.2 text/html (the html content)
Should have been:
PART#, MIME_TYPE, (COMMENTS)
1 multipart/alternative
1.1 text/plain (the plaintext content)
1.2 text/html (the html content)
Example 3:
Generated by HtmlEmail. Contains parts: plaintext, html, embedded inline img,
attach
PART#, MIME_TYPE, (COMMENTS)
1 multipart/related
1.1 multipart/alternative
1.1.1 text/plain (the plaintext content)
1.1.2 text/html (the html content with cid: references to embedded images)
1.2+ */* (attachment)
1.3+ image/* (embedded image, referenced by 1.1.2)
should have been:
PART#, MIME_TYPE, (COMMENTS)
1. multipart/mixed
1.1 multipart/related
1.1.1 multipart/alternative
1.1.1.1 text/plain (the plaintext content)
1.1.1.2 text/html (the HTML content with cid: references to embedded images)
1.1.2+ image/* (embedded image, referenced by 1.1.1.2)
1.2+ */* (attachment)
Example 4:
Generated by MultiPartEmail. Contains parts: plaintext
MultiPartEmail: plaintext
PART#, MIME_TYPE, (COMMENTS)
1 multipart/mixed (WRONG!)
1.1 text/plain (the plaintext content)
should have been:
PART#, MIME_TYPE, (COMMENTS)
1 text/plain (the plaintext content)
Example 5:
Generated by MultiPartEmail. Contains parts: plaintext, attach
PART#, MIME_TYPE, (COMMENTS)
1 multipart/mixed
1.1 text/plain (the plaintext content)
1.2+ */* (attachment)
This one is well-structured!
Conclusion:
With regards to the automatically generated text/html part, based on the
text/plain part, I concede that this is part of the API contract (specified in
JavaDoc of HtmlEmail.setMsg(String) ), although I still believe that generating
redundant data is silly.
It is fairly easy to show email clients choking on the above MIME structures,
one example being embedded images being displayed as attachments by virtually
any clients.
I agree that the current codebase is an improvement on version 1.0, but I think
making the 1.1 release at this stage with MIME structures that violates even
the most basic MIME recommendations (see examples above) would be wrong.
One alternative possibility would be planning a version 1.2 with a (thoroughly
tested) restructuring of the MIME generation.
> MIME layout generated by HtmlEmail causes trouble
> -
>
> Key: EMAIL-65
> URL: https://issues.apache.org/jira/browse/EMAIL-65
> Project: Commons Email
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Morten Hattesen
> Fix For: 1.1
>
>
> Previous bugs (e.g. http://issues.apache.org/jira/browse/EMAIL-50 ) raised
> against commons-email version 1.0 have complained about Outlook not being
> able to properly display multipart emails generated by HtmlEmail. While this
> issue is resolved as of rev 510708, I believe there a several issues
> regarding MIME layout, that still cause trouble to email clients.
> In the current codebase, a multipart email containing: plaintext part, html
> part, inline images and attachments, is constructed (to the best of my
> knowledge) with a MIME layout like this:
> PART#, MIME_TYPE, (COMMENTS)
> 1 multipart/alternative
> 1.1 text/plain (the plaintext content)
> 1.2 text/html (the html content with cid: references to embedded images)
> 2+ image/* (embedded image, referenced by 1.2)
> 3+ */* (attachment)
> ("+" above indicates that multiple (1..n) parts may be included)
> The above structure may cause email clients to display embedded images as
> attachments, even though they are semantically part of the text/html content.
> Furthermore, the current codebase (as documented in the HtmlEmail.setMsg()
> JavaDoc) synthesizes a html part by ... wrapping the plaintext
> part, thus generating a bloated (double size) message, for no apparent
> reason. In my opinion, HtmlEmail should degrade to the mime layout of Email,
> if no html part is available.
> Propose
[jira] Commented: (IO-116) Replace static FileCleaner methods
[ https://issues.apache.org/jira/browse/IO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480566 ] Henri Yandell commented on IO-116: -- Some minor comments (they always occur after you say +1 for some reason): * Javadoc on FileCleaningTestCase refers to FileCleaner. * Given that FileCleaner is static, why not implement FileCleaningTestCase inside FileCleaner? ie) deprecate the static methods and add non-static methods etc. I know that BeanUtils didn't do this, so I'm guessing there's some kind of reason for that. > Replace static FileCleaner methods > -- > > Key: IO-116 > URL: https://issues.apache.org/jira/browse/IO-116 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.3.1 >Reporter: Jochen Wiedmann >Priority: Critical > Fix For: 1.4 > > Attachments: commons-io-filecleaningtracker.patch, > commons-io-filecleaningtracker.patch > > > The attached patch aims to finally resolve the problems, which are named in > IO-99, FILEUPLOAD-120, and FILEUPLOAD-125. > I choosed a conservative strategy: Basically I copied the FileCleaner class > to an instantiable class FileCleaningTracker with instance methods. The > static FileCleaner methods are now implemented by a static instance of > FileCleaningTracker. (The name FileCleaningTracker is, of course, > questionable. > The FileCleaningTestCase was also created by simply copying FileCleaner to > FileCleaningTestCase. FileCleanerTestCase is now similarly implemented as a > subclass of FileCleanerTestCase which uses the static instance of FileCleaner > rather than a dynamically created instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-116) Replace static FileCleaner methods
[ https://issues.apache.org/jira/browse/IO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480563 ] Henri Yandell commented on IO-116: -- As the patch doesn't apply cleanly for me - +1 on applying it (you have karma after all). > Replace static FileCleaner methods > -- > > Key: IO-116 > URL: https://issues.apache.org/jira/browse/IO-116 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.3.1 >Reporter: Jochen Wiedmann >Priority: Critical > Fix For: 1.4 > > Attachments: commons-io-filecleaningtracker.patch, > commons-io-filecleaningtracker.patch > > > The attached patch aims to finally resolve the problems, which are named in > IO-99, FILEUPLOAD-120, and FILEUPLOAD-125. > I choosed a conservative strategy: Basically I copied the FileCleaner class > to an instantiable class FileCleaningTracker with instance methods. The > static FileCleaner methods are now implemented by a static instance of > FileCleaningTracker. (The name FileCleaningTracker is, of course, > questionable. > The FileCleaningTestCase was also created by simply copying FileCleaner to > FileCleaningTestCase. FileCleanerTestCase is now similarly implemented as a > subclass of FileCleanerTestCase which uses the static instance of FileCleaner > rather than a dynamically created instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nag: IO-116
On 3/13/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: On 3/13/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > Is the patch out of date? Should not be, there are no changes in commons-io since then. I have created a new patch. Yep, tis weird. Oh well. The general strategy of moving the static code out into an instance makes sense to me so +1 on applying the patch. Holger's thoughts on not having Threads in the libraries are interesting, but I think this is a step that would happen regardless. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-116) Replace static FileCleaner methods
[ https://issues.apache.org/jira/browse/IO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated IO-116: --- Attachment: commons-io-filecleaningtracker.patch Same patch, next attempt > Replace static FileCleaner methods > -- > > Key: IO-116 > URL: https://issues.apache.org/jira/browse/IO-116 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.3.1 >Reporter: Jochen Wiedmann >Priority: Critical > Fix For: 1.4 > > Attachments: commons-io-filecleaningtracker.patch, > commons-io-filecleaningtracker.patch > > > The attached patch aims to finally resolve the problems, which are named in > IO-99, FILEUPLOAD-120, and FILEUPLOAD-125. > I choosed a conservative strategy: Basically I copied the FileCleaner class > to an instantiable class FileCleaningTracker with instance methods. The > static FileCleaner methods are now implemented by a static instance of > FileCleaningTracker. (The name FileCleaningTracker is, of course, > questionable. > The FileCleaningTestCase was also created by simply copying FileCleaner to > FileCleaningTestCase. FileCleanerTestCase is now similarly implemented as a > subclass of FileCleanerTestCase which uses the static instance of FileCleaner > rather than a dynamically created instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nag: IO-116
On 3/13/07, Henri Yandell <[EMAIL PROTECTED]> wrote: Is the patch out of date? Should not be, there are no changes in commons-io since then. I have created a new patch. Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nag: IO-116
Not a good start :( patch -p0 < commons-io-filecleaningtracker.patch (Stripping trailing CRs from patch.) patching file xdocs/upgradeto1_4.xml (Stripping trailing CRs from patch.) patching file src/test/org/apache/commons/io/FileCleanerTestCase.java (Stripping trailing CRs from patch.) patching file src/test/org/apache/commons/io/FileCleaningTrackerTestCase.java (Stripping trailing CRs from patch.) patching file src/java/org/apache/commons/io/FileCleaner.java Hunk #2 FAILED at 35. 1 out of 7 hunks FAILED -- saving rejects to file src/java/org/apache/commons/io/FileCleaner.java.rej (Stripping trailing CRs from patch.) patching file src/java/org/apache/commons/io/FileCleaningTracker.java Is the patch out of date? (Meeting to do for the next hour, but will dig into things a bit further later; though I'd report back immediately though in case you have time to check that). Hen On 3/13/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, may I ask for a review and possible application of IO-116? I would like to make commons-fileupload to depend on it as soon as possible. Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - 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]
[jira] Closed: (BEANUTILS-168) [beanutils] copyProperties(List, List) does not work - pls warn about this
[ https://issues.apache.org/jira/browse/BEANUTILS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed BEANUTILS-168. --- Resolution: Fixed Note added to Javadoc. svn ci -m "Adding note to Javadoc that copyProperties is for copying properties and not for copying the contents of arrays or Lists. I pondered adding that functionality, but there's already some weird Map->Bean functionality in place and I felt it would just confuse things as I would have had to somewhat fix that to allow for Map->Map copying. " src/java/org/apache/commons/beanutils/PropertyUtilsBean.java Sendingsrc/java/org/apache/commons/beanutils/PropertyUtilsBean.java Transmitting file data . Committed revision 517894. > [beanutils] copyProperties(List, List) does not work - pls warn about this > -- > > Key: BEANUTILS-168 > URL: https://issues.apache.org/jira/browse/BEANUTILS-168 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils > Environment: Operating System: All > Platform: PC >Reporter: Ralf Hauser >Priority: Minor > Fix For: 1.8.0 > > > my application tries to copy a list. > List workerList = new ArrayList(); > BeanUtils.copyProperties(workerList, msg.getAllRecip()); > the size of the ArrayList allRecip in my msg object is 6. > After the copy, the size of the workerList remains 0. > Sure, > workerList.addAll(msg.getAllRecip()); > works as an alternative, but wouldn't it be appropriate to warn the user of > copyProperties ? > Might be related to COM-343 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r517894 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java
Author: bayard Date: Tue Mar 13 14:56:35 2007 New Revision: 517894 URL: http://svn.apache.org/viewvc?view=rev&rev=517894 Log: Adding note to Javadoc that copyProperties is for copying properties and not for copying the contents of arrays or Lists. I pondered adding that functionality, but there's already some weird Map->Bean functionality in place and I felt it would just confuse things as I would have had to somewhat fix that to allow for Map->Map copying. Modified: jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java Modified: jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=diff&rev=517894&r1=517893&r2=517894 == --- jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java (original) +++ jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java Tue Mar 13 14:56:35 2007 @@ -207,6 +207,9 @@ * bean.Note that this method is intended to perform * a "shallow copy" of the properties and so complex properties * (for example, nested ones) will not be copied. + * + * Note, that this method will not copy a List to a List, or an Object[] + * to an Object[]. It's specifically for copying JavaBean properties. * * @param dest Destination bean whose properties are modified * @param orig Origin bean whose properties are retrieved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nag: IO-116
Hi, may I ask for a review and possible application of IO-116? I would like to make commons-fileupload to depend on it as soon as possible. Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r517885 - in /jakarta/commons/proper/httpclient/trunk/xdocs: downloads.xml news.xml status.xml
Author: olegk Date: Tue Mar 13 14:39:52 2007 New Revision: 517885 URL: http://svn.apache.org/viewvc?view=rev&rev=517885 Log: Changes for 3.1-rc1 release Modified: jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml jakarta/commons/proper/httpclient/trunk/xdocs/news.xml jakarta/commons/proper/httpclient/trunk/xdocs/status.xml Modified: jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml?view=diff&rev=517885&r1=517884&r2=517885 == --- jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml (original) +++ jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml Tue Mar 13 14:39:52 2007 @@ -14,7 +14,7 @@ The following releases are avilable for download: - CURRENT - 3.1-beta1 - 30 October 2006 - + CURRENT - 3.1-rc1 - 16 March 2007 - http://jakarta.apache.org/site/downloads/downloads_commons-httpclient.cgi";>Download - http://www.apache.org/dist/jakarta/commons/httpclient/RELEASE-NOTES.txt"; >Release notes @@ -46,12 +46,12 @@ If you are using Maven for your project, you can create a dependency in your project.xml with one of the following: -3.1-beta1 +3.1-rc1 Modified: jakarta/commons/proper/httpclient/trunk/xdocs/news.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/xdocs/news.xml?view=diff&rev=517885&r1=517884&r2=517885 == --- jakarta/commons/proper/httpclient/trunk/xdocs/news.xml (original) +++ jakarta/commons/proper/httpclient/trunk/xdocs/news.xml Tue Mar 13 14:39:52 2007 @@ -10,6 +10,13 @@ + + + HttpClient 3.1-rc1 has been released. This version fixes a number of issues + found since 3.1-beta1. This release is expected to be the last one before + HttpClient 3.1 goes final. + + HttpClient 3.1-beta1 has been released. This version finalizes the RFC 2965 cookie Modified: jakarta/commons/proper/httpclient/trunk/xdocs/status.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/xdocs/status.xml?view=diff&rev=517885&r1=517884&r2=517885 == --- jakarta/commons/proper/httpclient/trunk/xdocs/status.xml (original) +++ jakarta/commons/proper/httpclient/trunk/xdocs/status.xml Tue Mar 13 14:39:52 2007 @@ -18,10 +18,8 @@ Cookie2 or port sensitive cookies) and a number of improvements to the HTTP connection management. HttpClient 3.1 is backward compatible with HttpClient 3.0 - -Bug reports targeted for the next release can be found - http://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12311032";>here. - +HttpClient 3.1 is likely to be the last non-bug fixing release of the + HttpClient 3.x code line - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.1.1 release?
On 3/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: The "previous build style" was very manual. The old ant files do build a valid JCL jar, but were *not* used as-is to generate previous official releases. One issue is that the java.util.logging adapters must of course be compiled with java1.4 or later, but other code needs to be compiled using 1.2 (or at least tested with that version). So bits of the code were compiled with different java versions and the results stitched together by hand; I believe Robert Donkin documented this somewhere. I do remember it was a scary process. The maven-2 build stuff is all done and verified. All that is needed is some way of testing the final > > binary output under java 1.2, and I think this is a much saner way to tackle a release. Which tests need to be run under 1.2? All of them? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-244) Proposal to support generic multi-key maps with keys of different types
[
https://issues.apache.org/jira/browse/COLLECTIONS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480553
]
Stephen Kestle commented on COLLECTIONS-244:
1st: Been there, done that. Ok - do you really want to type
QuaternaryKeyMap myMap =
QuaternaryKeyMap.decorate(new HashMap>());
You can make one method classes too.
If you want to have symmetric types, by all means, it looks to me like it's a
bit of a time saver. But when you're getting into complex keys, you want to
have a class represent that.
Also, have a look at [COLLECTIONS-242], as an EquatorMap implementation would
allow you to just give your domain objects as keys, without having to strip
information out of them:
multiMap.put(person.firstName(), person.secondName(), personRelatedData);
becomes
new EquatorMap(new NameEquator()).put(person, personRelatedData)
> Proposal to support generic multi-key maps with keys of different types
> ---
>
> Key: COLLECTIONS-244
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-244
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
>Affects Versions: Generics
>Reporter: Michael Heuer
>Priority: Minor
> Attachments: multi-map.tar.gz
>
>
> MultiKeyMap as designed can only accept keys of the same type, if made to
> support generics, i.e.
> MultiKeyMap,Integer> map = ...;
> map.put("foo", "bar", 10);
> // not possible
> //MultiKeyMap,Double> map = ...;
> Attached is a proposal that may support multi-key maps with keys of different
> types. I do not believe varying numbers of typed keys can be supported in a
> single interface, thus this proposal includes
> BinaryKey
> BinaryKeyMap extends Map,V>
> TertiaryKey
> TertiaryKeyMap extends Map,V>
> QuaternaryKey
> QuaternaryKeyMap extends Map,V>
> To prevent unnecessary object creation, I also propose to support
> MapIterator-style iterators:
> BinaryKeyMapIterator extends Iterator
> TertiaryKeyMapIterator extends Iterator
> QuaternaryKeyMapIterator extends Iterator
> Current multi-map MapIterator support is implemented as Iterator but I
> find that Iterator makes more sense here. It is not possible to support
> MapIterator without object creation, e.g.
> MapIterator,V> must create BinaryKey objects for each call
> to next().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction ; notifying collections
With regards to my -1: rather than rename getInstance methods, I would prefer to remove them and solely rely upon utility methods such as PredicateUtils#truePredicate. I'm potentially fine with that, except I don't want it to be in PredicateUtils - call it Predicates instead. PredicateUtils should be for providing predicate utilities, not instantiating objects. On the other side, perhaps PredicateUtils.and(Predicate, Predicate) is a utility that happens to instantiate an object. (Can we rename these methods to make them more concise and read better? For goodness sake: PredicateUtils.andPredicate? We know it's a predicate already - even with a static import, we know they're two predicates and it returns a predicate. I like code sentences - my brain immediately knows what's going on without translation). TruePredicate really has no place in a Utils class, and I don't think anything else should really instantiate it. It's a better pattern to have it have it's own static constructor method. While not standard, I believe this is better general programming practice than using constructors, as they provide better flexibility long term. If you were to create your own Predicates and have static constructor factories, where would you put the static method? At the moment, I figure the class is the best place. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r517853 - /jakarta/commons/proper/math/trunk/xdocs/changes.xml
Author: luc Date: Tue Mar 13 13:26:49 2007 New Revision: 517853 URL: http://svn.apache.org/viewvc?view=rev&rev=517853 Log: announced Mantissa packages inclusion Modified: jakarta/commons/proper/math/trunk/xdocs/changes.xml Modified: jakarta/commons/proper/math/trunk/xdocs/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/changes.xml?view=diff&rev=517853&r1=517852&r2=517853 == --- jakarta/commons/proper/math/trunk/xdocs/changes.xml (original) +++ jakarta/commons/proper/math/trunk/xdocs/changes.xml Tue Mar 13 13:26:49 2007 @@ -40,6 +40,10 @@ + +Added the estimation optimization, geometry and ode package from the +Mantissa library. + Made ComplexFormat format double values with a provided NumberFormat instance instead of using the real part format for all values. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r517842 - in /jakarta/commons/proper/math/trunk/xdocs: navigation.xml userguide/index.xml userguide/overview.xml
Author: luc Date: Tue Mar 13 13:04:22 2007 New Revision: 517842 URL: http://svn.apache.org/viewvc?view=rev&rev=517842 Log: linked new sections to the rest of the user guide Modified: jakarta/commons/proper/math/trunk/xdocs/navigation.xml jakarta/commons/proper/math/trunk/xdocs/userguide/index.xml jakarta/commons/proper/math/trunk/xdocs/userguide/overview.xml Modified: jakarta/commons/proper/math/trunk/xdocs/navigation.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/navigation.xml?view=diff&rev=517842&r1=517841&r2=517842 == --- jakarta/commons/proper/math/trunk/xdocs/navigation.xml (original) +++ jakarta/commons/proper/math/trunk/xdocs/navigation.xml Tue Mar 13 13:04:22 2007 @@ -56,7 +56,12 @@ - + + + + + + &commons; Modified: jakarta/commons/proper/math/trunk/xdocs/userguide/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/userguide/index.xml?view=diff&rev=517842&r1=517841&r2=517842 == --- jakarta/commons/proper/math/trunk/xdocs/userguide/index.xml (original) +++ jakarta/commons/proper/math/trunk/xdocs/userguide/index.xml Tue Mar 13 13:04:22 2007 @@ -99,6 +99,32 @@ 9.2 Fraction Numbers 9.3 Fraction Formatting and Parsing +10. Transform methods +11. Geometry + +11.1 Overview +11.2 Vectors +11.3 Rotations + +12. Parametric Estimation + +12.1 Overview +12.2 Models +12.3 Parameters +12.4 Measurements +12.5 Solvers + +13. Optimization + +13.1 Overview +13.2 Direct Methods + +14. Ordinary Differential Equations Integration + +14.1 Overview +14.2 ODE Problems +14.3 Integrators + Modified: jakarta/commons/proper/math/trunk/xdocs/userguide/overview.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/userguide/overview.xml?view=diff&rev=517842&r1=517841&r2=517842 == --- jakarta/commons/proper/math/trunk/xdocs/userguide/overview.xml (original) +++ jakarta/commons/proper/math/trunk/xdocs/userguide/overview.xml Tue Mar 13 13:04:22 2007 @@ -45,13 +45,16 @@ Computing means, variances and other summary statistics for a list of numbers Fitting a line to a set of data points using linear regression +Finding a smooth curve that passes through a collection of points (interpolation) +Fitting a parametric model to a set of measurements using least-squares methods Solving equations involving real-valued functions (i.e. root-finding) -Performing statistical significance tests Solving systems of linear equations +Solving Ordinary Differential Equations +Minimizing multi-dimensional functions Generating random numbers with more restrictions (e.g distribution, range) than what is possible using the JDK Generating random samples and/or datasets that are "like" the data in an input file -Finding a smooth curve that passes through a collection of points (interpolation) +Performing statistical significance tests Miscellaneous mathematical functions such as factorials, binomial coefficients and "special functions" (e.g. gamma, beta functions) @@ -68,7 +71,7 @@ -Commons Math is divided into nine subpackages, based on functionality provided. +Commons Math is divided into fourteen subpackages, based on functionality provided. org.apache.commons.math.stat - statistics, statistical tests org.apache.commons.math.analysis - rootfinding and interpolation @@ -79,6 +82,11 @@ org.apache.commons.math.complex - complex numbers org.apache.commons.math.distribution - probability distributions org.apache.commons.math.fraction - rational numbers + org.apache.commons.math.transform - transform methods (Fast Fourier) + org.apache.commons.math.geometry - 3D geometry (vectors and rotations) + org.apache.commons.math.estimation - parametric estimation problems + org.apache.commons.math.optimization - multi-dimensional functions minimization
svn commit: r517840 - /jakarta/commons/proper/math/trunk/xdocs/userguide/ode.xml
Author: luc Date: Tue Mar 13 13:03:40 2007 New Revision: 517840 URL: http://svn.apache.org/viewvc?view=rev&rev=517840 Log: added a section for the ODE package in the user guide Added: jakarta/commons/proper/math/trunk/xdocs/userguide/ode.xml (with props) Added: jakarta/commons/proper/math/trunk/xdocs/userguide/ode.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/userguide/ode.xml?view=auto&rev=517840 == --- jakarta/commons/proper/math/trunk/xdocs/userguide/ode.xml (added) +++ jakarta/commons/proper/math/trunk/xdocs/userguide/ode.xml Tue Mar 13 13:03:40 2007 @@ -0,0 +1,161 @@ + + + + + + + + + +The Commons Math User Guide - Ordinary Differential Equations Integration + + + + + + + The ode package provides classes to solve Ordinary Differential Equations problems. + + + This package solves Initial Value Problems of the form y'=f(t,y) with t0 + and y(t0)=y0 known. The provided integrators compute an estimate + of y(t) from t=t0 to t=t1. + + + All integrators provide dense output. This means that besides computing the state vector + at discrete times, they also provide a cheap mean to get the state between the time steps. + They do so through classes extending the + StepInterpolator + abstract class, which are made available to the user at the end of each step. + + + All integrators handle multiple switching functions. This means that the integrator can be + driven by discrete events (occurring when the signs of user-supplied + switching functions + change). The steps are shortened as needed to ensure the events occur at step boundaries (even + if the integrator is a fixed-step integrator). When the events are triggered, integration can + be stopped (this is called a G-stop facility), the state vector can be changed, or integration + can simply go on. The latter case is useful to handle discontinuities in the differential + equations gracefully and get accurate dense output even close to the discontinuity. The events + are detected when the functions signs are different at the beginning and end of the current step, + or at several equidistant points inside the step if its length becomes larger than the maximal + checking interval specified for the given switching function. This time interval should be set + appropriately to avoid missing some switching function sign changes (it is possible to set it + to Double.POSITIVE_INFINITY if the sign changes cannot be missed). + + + The user should describe his problem in his own classes which should implement the + FirstOrderDifferentialEquations + interface. Then he should pass it to the integrator he prefers among all the classes that implement + the FirstOrderIntegrator + interface. + + + The solution of the integration problem is provided by two means. The first one is aimed towards + simple use: the state vector at the end of the integration process is copied in the y array of the + FirstOrderIntegrator.integrate method. The second one should be used when more in-depth + information is needed throughout the integration process. The user can register an object implementing + the StepHandler interface or a + StepNormalizer object wrapping + a user-specified object implementing the + FixedStepHandler interface + into the integrator before calling the FirstOrderIntegrator.integrate method. The user object + will be called appropriately during the integration process, allowing the user to process intermediate + results. The default step handler does nothing. + + + ContinuousOutputModel + is a special-purpose step handler that is able to store all steps and to provide transparent access to + any intermediate result once the integration is over. An important feature of this class is that it + implements the Serializable interface. This means that a complete continuous model of the + integrated function througout the integration range can be serialized and reused later (if stored into + a persistent medium like a filesystem or a database) or elsewhere (if sent to another application). + Only the result of the integration is stored, there is no reference to the integrated problem by itself. + + + Other default implementations of the StepHandler + interface are available for general needs + (DummyStepHandler, + StepNormalizer) and custom + imp
svn commit: r517839 - /jakarta/commons/proper/math/trunk/xdocs/userguide/optimization.xml
Author: luc Date: Tue Mar 13 13:03:21 2007 New Revision: 517839 URL: http://svn.apache.org/viewvc?view=rev&rev=517839 Log: added a section for the optimization package in the user guide Added: jakarta/commons/proper/math/trunk/xdocs/userguide/optimization.xml (with props) Added: jakarta/commons/proper/math/trunk/xdocs/userguide/optimization.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/userguide/optimization.xml?view=auto&rev=517839 == --- jakarta/commons/proper/math/trunk/xdocs/userguide/optimization.xml (added) +++ jakarta/commons/proper/math/trunk/xdocs/userguide/optimization.xml Tue Mar 13 13:03:21 2007 @@ -0,0 +1,88 @@ + + + + + + + + + +The Commons Math User Guide - Optimization + + + + + + + The optimization package provides simplex-based direct search optimization algorithms. + + + The aim of this package is similar to the aim of the estimation package, but the + algorithms are entirely differents as: + + + they do not need the partial derivatives of the measurements + with respect to the free parameters + + + they do not rely on residuals-based quadratic cost functions but + handle any cost functions, including non-continuous ones! + + + + + + Direct search methods only use cost function values, they don't + need derivatives and don't either try to compute approximation of + the derivatives. According to a 1996 paper by Margaret H. Wright + (http://cm.bell-labs.com/cm/cs/doc/96/4-02.ps.gz";>Direct + Search Methods: Once Scorned, Now Respectable), they are used + when either the computation of the derivative is impossible (noisy + functions, unpredictable dicontinuities) or difficult (complexity, + computation cost). In the first cases, rather than an optimum, a + not too bad point is desired. In the latter cases, an + optimum is desired but cannot be reasonably found. In all cases + direct search methods can be useful. + + + Simplex-based direct search methods are based on comparison of + the cost function values at the vertices of a simplex (which is a + set of n+1 points in dimension n) that is updated by the algorithms + steps. + + + The instances can be built either in single-start or in + multi-start mode. Multi-start is a traditional way to try to avoid + beeing trapped in a local minimum and miss the global minimum of a + function. It can also be used to verify the convergence of an + algorithm. In multi-start mode, the minimizesmethod + returns the best minimum found after all starts, and the etMinima + method can be used to retrieve all minima from all starts (including the one + already provided by the minimizes method). + + + The package provides two solvers. The first one is the classical + + Nelder-Mead method. The second one is Virginia Torczon's + + multi-directional method. + + + + + Propchange: jakarta/commons/proper/math/trunk/xdocs/userguide/optimization.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r517838 - /jakarta/commons/proper/math/trunk/xdocs/userguide/estimation.xml
Author: luc Date: Tue Mar 13 13:02:56 2007 New Revision: 517838 URL: http://svn.apache.org/viewvc?view=rev&rev=517838 Log: added a section for the estimation package in the user guide Added: jakarta/commons/proper/math/trunk/xdocs/userguide/estimation.xml (with props) Added: jakarta/commons/proper/math/trunk/xdocs/userguide/estimation.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/userguide/estimation.xml?view=auto&rev=517838 == --- jakarta/commons/proper/math/trunk/xdocs/userguide/estimation.xml (added) +++ jakarta/commons/proper/math/trunk/xdocs/userguide/estimation.xml Tue Mar 13 13:02:56 2007 @@ -0,0 +1,111 @@ + + + + + + + + + +The Commons Math User Guide - Parametric Estimation + + + + + + +The estimation package provides classes to fit some non-linear model +to available observations depending on it. These problems are commonly +called estimation problems. + + +The estimation problems considered here are parametric problems where +a user-provided model depends on initially unknown scalar parameters and +several measurements made on values that depend on the model are available. +As examples, one can consider the center and radius of a circle given +points approximately lying on a ring, or a satellite orbit given range, +range-rate and angular measurements from various ground stations. + + +One important class of estimation problems is weighted least squares problems. +They basically consist in finding the values for some parameters pk +such that a cost function J = ∑(wi ri2) +is minimized. The various ri terms represent the deviation +ri = mesi - modi between the measurements and +the parameterized models. The wi factors are the measurements weights, +they are often chosen either all equal to 1.0 or proportional to the inverse of +the variance of the measurement type. The solver adjusts the values of the +estimated parameters pk which are not bound (i.e. the free parameters). +It does not touch the parameters which have been put in a bound state by the user. + + + The aim of this package is similar to the aim of the optimization package, but the + algorithms are entirely differents as: + + + they need the partial derivatives of the measurements + with respect to the free parameters + + + they are residuals based instead of generic cost functions based + + + + + +The +org.apache.commons.math.estimation.EstimationProblem interface is a very +simple container packing together parameters and measurements. + + + +The +org.apache.commons.math.estimation.EstimatedParameter class to represent each +estimated parameter. The parameters are set up with a guessed value which will be +adjusted by the solver until a best fit is achieved. It is possible to change which +parameters are modified and which are preserved thanks to a bound property. Such +settings are often needed by expert users to handle contingency cases with very +low observability. + + + + +The user extends the +org.apache.commons.math.estimation.WeightedMeasurement abstract class to define its +own measurements. Each measurement types should have its own implementing class, for +example in the satellite example above , the user should define three classes, one +for range measurements, one for range-rates measurements and one for angular measurements. +Each measurement would correspond to an instance of the appropriate class, set up with +the date, a reference to the ground station, the weight and the measured value. + + + + +The package provides two common +org.apache.commons.math.estimation.Estimator implementations to solve weighted +least squares problems. The first one is based on the +Gauss-Newton method. +The second one is based on the +Levenberg-Marquardt +method. The first one is best suited when a good approximation of the parameters is known while the second one +is more robust and can handle starting points far from the solution. + + + + + Propchange: jakarta/commons/proper/math/trunk/xdocs/userguide/estimation.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PR
svn commit: r517837 - /jakarta/commons/proper/math/trunk/xdocs/userguide/geometry.xml
Author: luc Date: Tue Mar 13 13:02:28 2007 New Revision: 517837 URL: http://svn.apache.org/viewvc?view=rev&rev=517837 Log: added a section for the geometry package in the user guide Added: jakarta/commons/proper/math/trunk/xdocs/userguide/geometry.xml (with props) Added: jakarta/commons/proper/math/trunk/xdocs/userguide/geometry.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/userguide/geometry.xml?view=auto&rev=517837 == --- jakarta/commons/proper/math/trunk/xdocs/userguide/geometry.xml (added) +++ jakarta/commons/proper/math/trunk/xdocs/userguide/geometry.xml Tue Mar 13 13:02:28 2007 @@ -0,0 +1,136 @@ + + + + + + + + + +The Commons Math User Guide - Geometry + + + + + + + The geometry package provides classes useful for many physical simulations + in the real 3D space, namely vectors and rotations. + + + + + + org.apache.commons.math.geometry.Vector3D provides a simple vector + type. One important feature is that instances of this class are guaranteed + to be immutable, this greatly simplifies modelization of dynamical systems + with changing states: once a vector has been computed, a reference to it + is known to preserve its state as long as the reference itself is preserved. + + + Numerous constructors are available to create vectors. In addition to the + straightforward cartesian coordinates constructor, a constructor using + azimuthal coodinates can build normalized vectors and linear constructors + from one, two, three or four base vectors are also available. Constants have + been defined for the most commons vectors (plus and minus canonical axes and + null vector). + + + The generic vectorial space operations are available including dot product, + normalization, orthogonal vector finding and angular separation computation + which have a specific meaning in 3D. The 3D geometry specific cross product + is of course also implemented. + + + + + + org.apache.commons.math.geometry.Rotation represents 3D rotations. + Rotation instances are also immutable objects, as Vector3D instances. + + + Rotations can be represented by several different mathematical + entities (matrices, axe and angle, Cardan or Euler angles, + quaternions). This class presents an higher level abstraction, more + user-oriented and hiding this implementation details. Well, for the + curious, we use quaternions for the internal representation. The user + can build a rotation from any of these representations, and any of + these representations can be retrieved from a Rotation + instance (see the various constructors and getters). In addition, a + rotation can also be built implicitely from a set of vectors and their + image. + + + This implies that this class can be used to convert from one + representation to another one. For example, converting a rotation + matrix into a set of Cardan angles can be done using the + following single line of code: + +double[] angles = new Rotation(matrix, 1.0e-10).getAngles(RotationOrder.XYZ); + + Focus is oriented on what a rotation do rather than on its + underlying representation. Once it has been built, and regardless of + its internal representation, a rotation is an operator which + basically transforms three dimensional vectors into other three + dimensional vectors. Depending on the application, the meaning of + these vectors may vary as well as the semantics of the rotation. + + + For example in an spacecraft attitude simulation tool, users will + often consider the vectors are fixed (say the Earth direction for + example) and the rotation transforms the coordinates coordinates of + this vector in inertial frame into the coordinates of the same vector + in satellite frame. In this case, the rotation implicitely defines the + relation between the two frames (we have fixed vectors and moving frame). + Another example could be a telescope control application, where the + rotation would transform the sighting direction at rest into the desired + observing direction when the telescope is pointed towards an object of + interest. In this case the rotation transforms the direction at rest in + a topocentric frame into the sighting direction in the same topocentric + frame (we have moving vectors in fixed
svn commit: r517836 - /jakarta/commons/proper/math/trunk/xdocs/userguide/transform.xml
Author: luc Date: Tue Mar 13 13:01:41 2007 New Revision: 517836 URL: http://svn.apache.org/viewvc?view=rev&rev=517836 Log: added a section on transform methods in the user guide Added: jakarta/commons/proper/math/trunk/xdocs/userguide/transform.xml (with props) Added: jakarta/commons/proper/math/trunk/xdocs/userguide/transform.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/userguide/transform.xml?view=auto&rev=517836 == --- jakarta/commons/proper/math/trunk/xdocs/userguide/transform.xml (added) +++ jakarta/commons/proper/math/trunk/xdocs/userguide/transform.xml Tue Mar 13 13:01:41 2007 @@ -0,0 +1,41 @@ + + + + + + + + + +The Commons Math User Guide - Transform methods + + + + + + This package provides a few transformers for signal analysis. All transformers + provide both direct and inverse transforms. + + FastFourierTransformer (produces Complex results) + FastCosineTransformer (produces real results) + FastSineTransformer (produces real results) + + + + + Propchange: jakarta/commons/proper/math/trunk/xdocs/userguide/transform.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-244) Proposal to support generic multi-key maps with keys of different types
[
https://issues.apache.org/jira/browse/COLLECTIONS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Heuer updated COLLECTIONS-244:
--
Attachment: multi-map.tar.gz
> Proposal to support generic multi-key maps with keys of different types
> ---
>
> Key: COLLECTIONS-244
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-244
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
>Affects Versions: Generics
>Reporter: Michael Heuer
>Priority: Minor
> Attachments: multi-map.tar.gz
>
>
> MultiKeyMap as designed can only accept keys of the same type, if made to
> support generics, i.e.
> MultiKeyMap,Integer> map = ...;
> map.put("foo", "bar", 10);
> // not possible
> //MultiKeyMap,Double> map = ...;
> Attached is a proposal that may support multi-key maps with keys of different
> types. I do not believe varying numbers of typed keys can be supported in a
> single interface, thus this proposal includes
> BinaryKey
> BinaryKeyMap extends Map,V>
> TertiaryKey
> TertiaryKeyMap extends Map,V>
> QuaternaryKey
> QuaternaryKeyMap extends Map,V>
> To prevent unnecessary object creation, I also propose to support
> MapIterator-style iterators:
> BinaryKeyMapIterator extends Iterator
> TertiaryKeyMapIterator extends Iterator
> QuaternaryKeyMapIterator extends Iterator
> Current multi-map MapIterator support is implemented as Iterator but I
> find that Iterator makes more sense here. It is not possible to support
> MapIterator without object creation, e.g.
> MapIterator,V> must create BinaryKey objects for each call
> to next().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-244) Proposal to support generic multi-key maps with keys of different types
Proposal to support generic multi-key maps with keys of different types
---
Key: COLLECTIONS-244
URL: https://issues.apache.org/jira/browse/COLLECTIONS-244
Project: Commons Collections
Issue Type: Improvement
Components: Map
Affects Versions: Generics
Reporter: Michael Heuer
Priority: Minor
Attachments: multi-map.tar.gz
MultiKeyMap as designed can only accept keys of the same type, if made to
support generics, i.e.
MultiKeyMap,Integer> map = ...;
map.put("foo", "bar", 10);
// not possible
//MultiKeyMap,Double> map = ...;
Attached is a proposal that may support multi-key maps with keys of different
types. I do not believe varying numbers of typed keys can be supported in a
single interface, thus this proposal includes
BinaryKey
BinaryKeyMap extends Map,V>
TertiaryKey
TertiaryKeyMap extends Map,V>
QuaternaryKey
QuaternaryKeyMap extends Map,V>
To prevent unnecessary object creation, I also propose to support
MapIterator-style iterators:
BinaryKeyMapIterator extends Iterator
TertiaryKeyMapIterator extends Iterator
QuaternaryKeyMapIterator extends Iterator
Current multi-map MapIterator support is implemented as Iterator but I find
that Iterator makes more sense here. It is not possible to support
MapIterator without object creation, e.g. MapIterator,V>
must create BinaryKey objects for each call to next().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-65) MIME layout generated by HtmlEmail causes trouble
[
https://issues.apache.org/jira/browse/EMAIL-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480523
]
Ben Speakmon commented on EMAIL-65:
---
I like the MIME structure you propose.
I'm not aware of any popular email client that handles the current structure
incorrectly, and without a clear breakage the amount of testing required to
prove this change seems onerous. If you can show me a test case for one, I'd be
happy to work with you to figure out what's going on; otherwise, in the
interest of getting the important 1.1 fixes out the door ASAP, I view this as
more of an enhancement request. (Disclaimer: I'm not a committer and only a
committer's opinion is binding on release issues.)
Creating an HTML part (when none is explicitly specified) is expected behavior.
If you want plaintext only or plaintext with attachments, I'd say you should
use SimpleEmail or MultiPartEmail directly. Changing this would mean changing
the API contract, and I don't think that's something we should do for this
release. (See previous disclaimer.)
> MIME layout generated by HtmlEmail causes trouble
> -
>
> Key: EMAIL-65
> URL: https://issues.apache.org/jira/browse/EMAIL-65
> Project: Commons Email
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Morten Hattesen
> Fix For: 1.1
>
>
> Previous bugs (e.g. http://issues.apache.org/jira/browse/EMAIL-50 ) raised
> against commons-email version 1.0 have complained about Outlook not being
> able to properly display multipart emails generated by HtmlEmail. While this
> issue is resolved as of rev 510708, I believe there a several issues
> regarding MIME layout, that still cause trouble to email clients.
> In the current codebase, a multipart email containing: plaintext part, html
> part, inline images and attachments, is constructed (to the best of my
> knowledge) with a MIME layout like this:
> PART#, MIME_TYPE, (COMMENTS)
> 1 multipart/alternative
> 1.1 text/plain (the plaintext content)
> 1.2 text/html (the html content with cid: references to embedded images)
> 2+ image/* (embedded image, referenced by 1.2)
> 3+ */* (attachment)
> ("+" above indicates that multiple (1..n) parts may be included)
> The above structure may cause email clients to display embedded images as
> attachments, even though they are semantically part of the text/html content.
> Furthermore, the current codebase (as documented in the HtmlEmail.setMsg()
> JavaDoc) synthesizes a html part by ... wrapping the plaintext
> part, thus generating a bloated (double size) message, for no apparent
> reason. In my opinion, HtmlEmail should degrade to the mime layout of Email,
> if no html part is available.
> Proposed MIME layout
>
> To the best of my knowledge, a multipart email containing: plaintext part,
> html part, inline images and attachments, should be constructed like so:
> PART#, MIME_TYPE, (COMMENTS)
> 1. multipart/mixed
> 1.1 multipart/related
> 1.1.1 multipart/alternative
> 1.1.1.1 text/plain (the plaintext content)
> 1.1.1.2 text/html (the HTML content with cid: references to embedded images)
> 1.1.2+ image/* (embedded image, referenced by 1.1.1.2)
> 1.2+ */* (attachment)
> The following simplifications of the above structure may be applied:
> a. If no embedded images are included, items 1.1.2+ and 1.1 are removed.
> b. if no text/html part is included, items 1.1.1.2 and 1.1.1 are removed
> c. if no attachments are included, items 1.2+ and 1 are removed
> Incidentially, this MIME layout is used by GMail, which is an indication that
> it is the "proper" way.
> I seriously believe that this issue should be investigated and resolved, if
> at all possible, as part of version 1.1.
> I may be able to supply a patch to HtmlEmail.java in the April/May 2007
> timeframe, but I am not prepared to put any body parts on the block on that
> one ;-)
> I welcome any comments!
> Morten Hattesen
> References:
> See http://en.wikipedia.org/wiki/MIME for additional information and
> references
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction ; notifying collections
Bryce, I've been in a similar position for the past year or so. It's
only now that my employer is properly moving into JSE5. I believe we've
previously agreed that backwards compatibility with JSE4 is not a major
aim of genericising Commons Collections, hence why we're on an entirely
different Subversion branch.
IMHO what we need to do now is agree upon an agenda for the
Collections-Java5 SVN branch based on this thread's discussion, and vote
upon it.
01. Removing all deprecated classes and methods. (I'm +1)
02. Removing (*not* deprecating) methods specifically related to type
safety pre-JSE5, e.g. MapUtils#getDouble. (+1)
03. Renaming usage of the Singleton design pattern to help usage of
static imports, e.g. TruePredicate#getInstance. (-1)
04. Porting generics into the Commons Collections codebase. (-1)
With regards to my -1: rather than rename getInstance methods, I would
prefer to remove them and solely rely upon utility methods such as
PredicateUtils#truePredicate.
At what point do we think we'll have a consensus?
Steve.
---
Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/
Bryce L Nordgren wrote:
Stephen Kestle <[EMAIL PROTECTED]> wrote on 03/12/2007
09:15:11 PM:
Bryce L Nordgren wrote:
Are you going to still produce binary releases which are compatible
with
1.4, even though they won't be able to compile the new source releases?
Or
are you going to use some sort of code stripper thingy which gets rid
of
generics for backwards source compatibility?
No, not as far as the conversation is going.
Bear in mind that SDKs <=1.4
inspired this library due to perceived shortcomings in the reference
implementations of the collection framework interfaces. It seems
counterintuitive to make SDKs >= 1.5 the only platform on which this
can
compile. But as long as the binaries stay backwards-compatible, that's
OK.
Why bother? The current collections serve very well for <=1.4. The
major pain is coming from 1.5 users having to suppress warnings all over
the place if they want to use commons-collections.
I understand that the binary break will limit the backwards
compatibility, but if you're needing to develop for 1.4 and 1.5, use 1.4
libs. As far as I see, most people leap to Java 5 rather than tip
toeing.
First, let me understand the proposal. Is a 1.4 compatible version of
commons-collections going to continue to be supported simultaneously with
the 1.5+ "reboot"? Your answer above indicates "no".
If the answer is in fact "no", you answered your own question ("Why
bother?") with "if you're needing to develop for 1.4 and 1.5, use 1.4
libs." You raised a very good reason to bother. However, if the answer is
"yes", I can go away happy and stop bothering everyone with large codebase
maintenance issues.
My perspective may not be common. The GeoTools project has been under
development for years. It is modular and has many many separate
developers, some of whom have moved onto greener pastures. The "official"
policy is that we develop for Java 5 now. Yet there is a sizable code base
developed during the time of 1.4. Although we have our Java 5 advocates,
there is no one with the budget of time or money to pull the entire code
base forward simultaneously. So if it happens at all, it must happen by
means of "tip toeing". Veteran, well-tested code may eventually be phased
out, but realistically we're talking years. We may see Java 1.8 before the
last of 1.4 is phased out. We just don't have the developer power to
factor in the latest compiler toys every two years (and deal with the new
bugs introduced by the process), no matter how shiny the new toys are.
Ergo, we need access to quality 1.4 libraries for the foreseeable future.
Bryce
-
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: [collections] VOTE: Collections-java5 direction ; notifying collections
Stephen Kestle <[EMAIL PROTECTED]> wrote on 03/12/2007
09:15:11 PM:
> Bryce L Nordgren wrote:
> > Are you going to still produce binary releases which are compatible
with
> > 1.4, even though they won't be able to compile the new source releases?
Or
> > are you going to use some sort of code stripper thingy which gets rid
of
> > generics for backwards source compatibility?
> No, not as far as the conversation is going.
> > Bear in mind that SDKs <=1.4
> > inspired this library due to perceived shortcomings in the reference
> > implementations of the collection framework interfaces. It seems
> > counterintuitive to make SDKs >= 1.5 the only platform on which this
can
> > compile. But as long as the binaries stay backwards-compatible, that's
OK.
> >
> Why bother? The current collections serve very well for <=1.4. The
> major pain is coming from 1.5 users having to suppress warnings all over
> the place if they want to use commons-collections.
> I understand that the binary break will limit the backwards
> compatibility, but if you're needing to develop for 1.4 and 1.5, use 1.4
> libs. As far as I see, most people leap to Java 5 rather than tip
toeing.
First, let me understand the proposal. Is a 1.4 compatible version of
commons-collections going to continue to be supported simultaneously with
the 1.5+ "reboot"? Your answer above indicates "no".
If the answer is in fact "no", you answered your own question ("Why
bother?") with "if you're needing to develop for 1.4 and 1.5, use 1.4
libs." You raised a very good reason to bother. However, if the answer is
"yes", I can go away happy and stop bothering everyone with large codebase
maintenance issues.
My perspective may not be common. The GeoTools project has been under
development for years. It is modular and has many many separate
developers, some of whom have moved onto greener pastures. The "official"
policy is that we develop for Java 5 now. Yet there is a sizable code base
developed during the time of 1.4. Although we have our Java 5 advocates,
there is no one with the budget of time or money to pull the entire code
base forward simultaneously. So if it happens at all, it must happen by
means of "tip toeing". Veteran, well-tested code may eventually be phased
out, but realistically we're talking years. We may see Java 1.8 before the
last of 1.4 is phased out. We just don't have the developer power to
factor in the latest compiler toys every two years (and deal with the new
bugs introduced by the process), no matter how shiny the new toys are.
Ergo, we need access to quality 1.4 libraries for the foreseeable future.
Bryce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 86 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 23 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-13032007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128) [ju
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 86 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 23 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-13032007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128) [ju
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 86 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 86 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-13032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at
svn commit: r517705 - in /jakarta/commons/proper/httpclient/trunk: build.xml project.xml release_notes.txt src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java
Author: olegk
Date: Tue Mar 13 07:27:03 2007
New Revision: 517705
URL: http://svn.apache.org/viewvc?view=rev&rev=517705
Log:
Changes for 3.1-rc1 release
Modified:
jakarta/commons/proper/httpclient/trunk/build.xml
jakarta/commons/proper/httpclient/trunk/project.xml
jakarta/commons/proper/httpclient/trunk/release_notes.txt
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java
Modified: jakarta/commons/proper/httpclient/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/build.xml?view=diff&rev=517705&r1=517704&r2=517705
==
--- jakarta/commons/proper/httpclient/trunk/build.xml (original)
+++ jakarta/commons/proper/httpclient/trunk/build.xml Tue Mar 13 07:27:03 2007
@@ -38,7 +38,7 @@
-
+
Modified: jakarta/commons/proper/httpclient/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/project.xml?view=diff&rev=517705&r1=517704&r2=517705
==
--- jakarta/commons/proper/httpclient/trunk/project.xml (original)
+++ jakarta/commons/proper/httpclient/trunk/project.xml Tue Mar 13 07:27:03 2007
@@ -7,7 +7,7 @@
commons-httpclient
jakarta-commons-httpclient
2001
- 3.1-beta1
+ 3.1-rc1
org.apache.commons.httpclient
@@ -33,6 +33,11 @@
http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk
+
+ 3.1-rc1
+ 3.1-rc1
+ HTTPCLIENT_3_1_RC1
+
3.1-beta1
3.1-beta1
Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/release_notes.txt?view=diff&rev=517705&r1=517704&r2=517705
==
--- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original)
+++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Tue Mar 13
07:27:03 2007
@@ -1,4 +1,13 @@
-Changes since Release 3.1 Beta 1:
+Release 3.1 RC 1
+---
+New features:
+---
+
+(1) HTTP state management
+
+ * RFC 2965 cookie specification support
+
+---
* [HTTPCLIENT-641] - Resource Leakage when loading keystore in
AuthSSLProtocolSocketFactory.
Contributed by Hanson Char
@@ -31,38 +40,11 @@
* [HTTPCLIENT-610] - Added for convenience
HttpMethodBase.getResponseBodyAsString(int)
Contributed by Ortwin Glueck
-
-Release 3.1 Beta 1
-Changes since Release 3.1 Alpha 1:
-
-* [HTTPCLIENT-598] - Fixed ContentLengthInputStream#available()
- Contributed by Igor Lubashev
-
-* [HTTPCLIENT-597] - Improved handling of idle connections in the
multithreaded HTTP connection
- manager.
- Contributed by Michael Becke
-
-* [HTTPCLIENT-593] - Fixed problem with #equals() and #hashCode() methods in
subclasses of
- DefaultProtocolSocketFactory and SSLProtocolSocketFactory
- Contributed by Chris Audley
-
-* [HTTPCLIENT-594] - HttpMethodBase#aborted variable was declared transient
instead of volatile
- by mistake.
- Contributed by Oleg Kalnichevski
-
-Release 3.1 Alpha 1
-New features:
-
-(1) HTTP state management
-
- * RFC 2965 cookie specification support
-
---
API changes since 3.0
-
+
+Class added:
+ public org.apache.commons.httpclient.HttpContentTooLargeException extends
org.apache.commons.httpclient.HttpException
Class added:
public org.apache.commons.httpclient.InvalidRedirectLocationException
extends org.apache.commons.httpclient.RedirectException
Class added:
@@ -92,27 +74,60 @@
new:
deprecated: public ConnectMethod();
-Class changed: org.apache.commons.httpclient.HttpMethodBase
+Class changed: org.apache.commons.httpclient.ContentLengthInputStream
Methods added:
-protected void
processCookieHeaders(org.apache.commons.httpclient.cookie.CookieSpec,
org.apache.commons.httpclient.Header[],
org.apache.commons.httpclient.HttpState,
org.apache.commons.httpclient.HttpConnection);
+public int available() throws java.io.IOException;
-Class changed: org.apache.commons.httpclient.HttpState
+Class changed: org.apache.commons.httpclient.HttpHost
Method changed:
old:
-public void clearCookies();
+public java.lang.Object clone();
new:
-public synchronized void clearCookies();
+public java.lang.Object clone() throws
java.lang.CloneNotSupportedException;
-Class changed: org.apache.commons.httpclient.HttpURL
+Class changed: org.apache.commons.httpclient.HttpMethodBase
Methods added:
-protected void setURI();
+public byte[] getResponseBody(int) throws java.io.IOException;
+
[jira] Updated: (COLLECTIONS-243) generic versions of some more classes
[ https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edwin Tellman updated COLLECTIONS-243: -- Description: I added generics to some more classes and fixed some compilation problems. The generic version of Transformer required the input and output types to be identical. This seemed to me to reduce the usefulness of transformed collections, as transforming one type into another seems like it would be a fairly common operation. I'm not sure how to fix this, however, as it also doesn't seem feasible to have a generic TransformedCollection with different input and output types that implements Collection. Anyway, this patch de-generifies TransformedCollection, which also fixes some compilation problems. Please disregard this change if you disagree and have a better solution. The modified collection classes are: Bags: PredicatedSortedBag, AbstractBagDecorator, SynchronizedBag, UnmodifiableSortedBag, SynchronizedSortedBag, PredicatedBag Lists: PredicatedList, SynchronizedList Sets: PredicatedSortedSet, SynchronizedSortedSet, PredicatedSet, UnmodifiableSortedSet, SynchronizedSet Miscellaneous: PredicatedBuffer was: I added generics to some more classes and fixed some compilation problems. The generic version of Transformer required the input and output types to be identical. This seemed to me to reduce the usefulness of transformed collections, as transforming one type into another seems like it would be a fairly common operation. I'm not sure how to fix this, however, as it also doesn't seem feasible to have a generic TransformedCollection with different input and output types that implements Collection. Anyway, this patch de-generifies TransformedCollection, which also fixes some compilation problems. Please disregard this change if you disagree and have a better solution. I updated the description to list the changed collection classes, as suggested. > generic versions of some more classes > - > > Key: COLLECTIONS-243 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-243 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: Generics > Environment: OS X >Reporter: Edwin Tellman >Priority: Minor > Fix For: Generics > > Attachments: collections_06_03_11.patch > > > I added generics to some more classes and fixed some compilation problems. > The generic version of Transformer required the input and output types to be > identical. This seemed to me to reduce the usefulness of transformed > collections, as transforming one type into another seems like it would be a > fairly common operation. I'm not sure how to fix this, however, as it also > doesn't seem feasible to have a generic TransformedCollection with different > input and output types that implements Collection. Anyway, this patch > de-generifies TransformedCollection, which also fixes some compilation > problems. Please disregard this change if you disagree and have a better > solution. > The modified collection classes are: > Bags: PredicatedSortedBag, AbstractBagDecorator, SynchronizedBag, > UnmodifiableSortedBag, SynchronizedSortedBag, PredicatedBag > Lists: PredicatedList, SynchronizedList > Sets: PredicatedSortedSet, SynchronizedSortedSet, PredicatedSet, > UnmodifiableSortedSet, SynchronizedSet > Miscellaneous: PredicatedBuffer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r517699 - in /jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl: HostConfigurationWithHostFactory.java HttpHostFactory.java
Author: olegk
Date: Tue Mar 13 06:55:56 2007
New Revision: 517699
URL: http://svn.apache.org/viewvc?view=rev&rev=517699
Log:
HTTPCLIENT-640: HostConfiguration that gets its Host from a factory.
This is useful for integrating a specialized Protocol or SocketFactory; for
example, a SecureSocketFactory that authenticates via SSL. Use
HttpClient.setHostConfiguration to install a HostConfigurationWithHostFactory
that contains the specialized HostFactory, Protocol or SocketFactory
Contributed by John Kristian
Added:
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java
(with props)
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HttpHostFactory.java
(with props)
Added:
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java?view=auto&rev=517699
==
---
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java
(added)
+++
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java
Tue Mar 13 06:55:56 2007
@@ -0,0 +1,60 @@
+package org.apache.commons.httpclient.contrib.ssl;
+
+import org.apache.commons.httpclient.HostConfiguration;
+import org.apache.commons.httpclient.HttpURL;
+import org.apache.commons.httpclient.protocol.Protocol;
+
+/**
+ * A kind of HostConfiguration that gets its Host from a factory. This is
useful
+ * for integrating a specialized Protocol or SocketFactory; for example, a
+ * SecureSocketFactory that authenticates via SSL. Use
+ * HttpClient.setHostConfiguration to install a
HostConfigurationWithHostFactory
+ * that contains the specialized HostFactory, Protocol or SocketFactory.
+ *
+ * An alternative is to use Protocol.registerProtocol to register a specialized
+ * Protocol. But that has drawbacks: it makes it hard to integrate modules
(e.g.
+ * web applications in a servlet container) with different strategies, because
+ * they share the specialized Protocol (Protocol.PROTOCOLS is static). And it
+ * can't support different Protocols for different hosts or ports (since the
+ * host and port aren't parameters to Protocol.getProtocol).
+ *
+ * @author John Kristian
+ */
+class HostConfigurationWithHostFactory extends HostConfiguration
+{
+public HostConfigurationWithHostFactory(HttpHostFactory factory)
+{
+this.factory = factory;
+}
+
+private HostConfigurationWithHostFactory(HostConfigurationWithHostFactory
that)
+{
+super(that);
+this.factory = that.factory;
+}
+
+private final HttpHostFactory factory;
+
+public Object clone()
+{
+return new HostConfigurationWithHostFactory(this);
+}
+
+private static final String DEFAULT_SCHEME = new
String(HttpURL.DEFAULT_SCHEME);
+
+public void setHost(String host)
+{
+setHost(host, Protocol.getProtocol(DEFAULT_SCHEME).getDefaultPort());
+}
+
+public void setHost(final String host, int port)
+{
+setHost(host, port, DEFAULT_SCHEME);
+}
+
+public synchronized void setHost(String host, int port, String scheme)
+{
+setHost(factory.getHost(this, scheme, host, port));
+}
+
+}
Propchange:
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java
--
svn:keywords = Date Author Id Revision HeadURL
Propchange:
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java
--
svn:mime-type = text/plain
Added:
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HttpHostFactory.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HttpHostFactory.java?view=auto&rev=517699
==
---
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HttpHostFactory.java
(added)
+++
jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HttpHostFactory.java
Tue Mar 13 06:55:56 2007
@@ -0,0 +1,58 @@
+package org.apache.commons.httpclient.contrib.ssl;
+
+import org.apache.commons.httpclient.HostConfiguration;
+import org.apache.commons.httpclient.HttpHost;
+im
[jira] Created: (EMAIL-65) MIME layout generated by HtmlEmail causes trouble
MIME layout generated by HtmlEmail causes trouble
-
Key: EMAIL-65
URL: https://issues.apache.org/jira/browse/EMAIL-65
Project: Commons Email
Issue Type: Bug
Affects Versions: 1.0
Reporter: Morten Hattesen
Fix For: 1.1
Previous bugs (e.g. http://issues.apache.org/jira/browse/EMAIL-50 ) raised
against commons-email version 1.0 have complained about Outlook not being able
to properly display multipart emails generated by HtmlEmail. While this issue
is resolved as of rev 510708, I believe there a several issues regarding MIME
layout, that still cause trouble to email clients.
In the current codebase, a multipart email containing: plaintext part, html
part, inline images and attachments, is constructed (to the best of my
knowledge) with a MIME layout like this:
PART#, MIME_TYPE, (COMMENTS)
1 multipart/alternative
1.1 text/plain (the plaintext content)
1.2 text/html (the html content with cid: references to embedded images)
2+ image/* (embedded image, referenced by 1.2)
3+ */* (attachment)
("+" above indicates that multiple (1..n) parts may be included)
The above structure may cause email clients to display embedded images as
attachments, even though they are semantically part of the text/html content.
Furthermore, the current codebase (as documented in the HtmlEmail.setMsg()
JavaDoc) synthesizes a html part by ... wrapping the plaintext part,
thus generating a bloated (double size) message, for no apparent reason. In my
opinion, HtmlEmail should degrade to the mime layout of Email, if no html part
is available.
Proposed MIME layout
To the best of my knowledge, a multipart email containing: plaintext part, html
part, inline images and attachments, should be constructed like so:
PART#, MIME_TYPE, (COMMENTS)
1. multipart/mixed
1.1 multipart/related
1.1.1 multipart/alternative
1.1.1.1 text/plain (the plaintext content)
1.1.1.2 text/html (the HTML content with cid: references to embedded images)
1.1.2+ image/* (embedded image, referenced by 1.1.1.2)
1.2+ */* (attachment)
The following simplifications of the above structure may be applied:
a. If no embedded images are included, items 1.1.2+ and 1.1 are removed.
b. if no text/html part is included, items 1.1.1.2 and 1.1.1 are removed
c. if no attachments are included, items 1.2+ and 1 are removed
Incidentially, this MIME layout is used by GMail, which is an indication that
it is the "proper" way.
I seriously believe that this issue should be investigated and resolved, if at
all possible, as part of version 1.1.
I may be able to supply a patch to HtmlEmail.java in the April/May 2007
timeframe, but I am not prepared to put any body parts on the block on that one
;-)
I welcome any comments!
Morten Hattesen
References:
See http://en.wikipedia.org/wiki/MIME for additional information and references
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-270) findPropertyDescriptor method with a class argument
findPropertyDescriptor method with a class argument
---
Key: BEANUTILS-270
URL: https://issues.apache.org/jira/browse/BEANUTILS-270
Project: Commons BeanUtils
Issue Type: Wish
Components: Bean / Property Utils
Affects Versions: 1.7.0
Reporter: Matthias Wuttke
Priority: Minor
I would like to suggest to add a findPropertyDescriptor variant that takes a
class instead of a bean as an argument. This is useful for situations where I
want to deal with abstract classes and their properties as I cannot
instantiate them to use findPropertyDescriptor(Object, String)
public PropertyDescriptor findPropertyDescriptor(Class clazz, String
propertyName) {
PropertyDescriptor[] descriptors =
PropertyUtils.getPropertyDescriptors(clazz);
for (int i = 0; i < descriptors.length; i++)
if (propertyName.equals(descriptors[i].getName()))
return (descriptors[i]);
return null;
}
Best regards,
Matthias
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
