[RESULT] New committer - Stephen Kestle
Stephen Kestle has been voted in as a new committer for Jakarta: +1 Stephen Colebourne Henri Yandell Joerg Schaible Simon Kitching Niall Pemberton Martin van dem Bemt Phil Steitz Oliver Heger Oliver Zeigermann Rahul Akolkar Stephen K, please see http://www.apache.org/dev/new-committers-guide.html for what happens next. In particular for the CLA you must sign. Contact me off-list with any questions. Stephen Stephen Colebourne wrote: Stephen has spent a considerable amount of effort in discussions and chivying in the commons area, particularly on commons-collections. In another life he has been heavily involved in one of the existing generics ports of collections - http://collections.sf.net. [ ] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
Stephen Colebourne wrote: [X] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (FILEUPLOAD-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated FILEUPLOAD-130: --- Attachment: FILEUPLOAD-130.patch Please validate this alternate proposal, which is based on your last patch, but smaller. > Add ability to get any header from the FileItem and FileItemStream interfaces > - > > Key: FILEUPLOAD-130 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Michael Macaluso >Priority: Minor > Attachments: FILEUPLOAD-130.patch, FileUpload-130_1.patch, > FileUpload-130_2.patch > > > The FileItem and FileItemStream interfaces should have a way to return back > any header that was encountered during the header parsing for an "Item". > Currently, from the FileItemStatus you can only get information from the 2 > pre-defined headers "Content-Type" and "Content-Disposition" (Sort-of because > the header can not be accessed raw). Other than the interface changes > (including the change to pass them along in the FileItemFactory interface), > it appears that all changes can be made within the FileUploadBase.java file. > FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create > the FileItemStreamImpl on lines 877 and 887 do not include the headers map. > Further, the parseRequest method uses the FileItemStream interface to build > the FileItem, so you should always have the headers in question. > The reason for this request is that we have an application that is sending > per-part headers (not precluded by the specs as far as we know of) to provide > more information than name and content-type and using the FileUpload project > means that we can no longer find out those header values. > [Also, not completely sure, but I believe FileUploadBase.createItem(Map, > boolean) on line 480 is not referenced anymore in this project.] -- 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: r521874 - in /jakarta/commons/proper/pool/trunk/xdocs: changes.xml issue-tracking.xml
Author: niallp Date: Fri Mar 23 12:13:26 2007 New Revision: 521874 URL: http://svn.apache.org/viewvc?view=rev&rev=521874 Log: Just adding missing subversion properties - no actual changes - may create alot of noise Modified: jakarta/commons/proper/pool/trunk/xdocs/changes.xml (props changed) jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml (contents, props changed) Propchange: jakarta/commons/proper/pool/trunk/xdocs/changes.xml -- svn:keywords = Date Author Id Revision HeadURL Modified: jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml?view=diff&rev=521874&r1=521873&r2=521874 == --- jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml (original) +++ jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml Fri Mar 23 12:13:26 2007 @@ -1,70 +1,70 @@ - - - - - -Issue tracking -Commons Documentation Team - - - - - - -Commons Pool uses http://issues.apache.org/jira/";>ASF JIRA for tracking issues. -See the http://issues.apache.org/jira/browse/POOL";>Pool JIRA project page. - - -To use JIRA you may need to http://issues.apache.org/jira/secure/Signup!default.jspa";>create an account - (if you have previously created/updated Commons issues using Bugzilla an account will have been automatically - created and you can use the http://issues.apache.org/jira/secure/ForgotPassword!default.jspa";>Forgot Password - page to get a new password). - - -If you would like to report a bug, or raise an enhancement request with -Commons Pool please do the following: - -http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310488&sorter/field=issuekey&sorter/order=DESC&status=1&status=4";>Search existing open bugs. -If you find your issue listed then please add a comment with your details. -http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/";>Search the mailing list archive. -You may find your issue or idea has already been discussed. -Decide if your issue is a bug or an enhancement. -Submit either a http://issues.apache.org/jira/secure/CreateIssueDetails!init.jspa?pid=12310488&issuetype=1&priority=4&assignee=-1";>bug report - or http://issues.apache.org/jira/secure/CreateIssueDetails!init.jspa?pid=12310488&issuetype=4&priority=4&assignee=-1";>enhancement request. - - - -Please also remember these points: - - the more information you provide, the better we can help you - test cases are vital, particularly for any proposed enhancements - the developers of Commons Pool are all unpaid volunteers - - - -You may also find these links useful: - - http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310488&sorter/field=issuekey&sorter/order=DESC&status=1&status=4";>All Open Pool bugs - http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310488&sorter/field=issuekey&sorter/order=DESC&status=5&status=6";>All Resolved Pool bugs - http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310488&sorter/field=issuekey&sorter/order=DESC";>All Pool bugs - - - - - - + + + + + +Issue tracking +Commons Documentation Team + + + + + + +Commons Pool uses http://issues.apache.org/jira/";>ASF JIRA for tracking issues. +See the http://issues.apache.org/jira/browse/POOL";>Pool JIRA project page. + + +To use JIRA you may need to http://issues.apache.org/jira/secure/Signup!default.jspa";>create an account + (if you have previously created/updated Commons issues using Bugzilla an account will have been automatically + created and you can use the http://issues.apache.org/jira/secure/ForgotPassword!default.jspa";>Forgot Password + page to get a new password). + + +If you would like to report a bug, or raise an enhancement request with +Commons Pool please do the following: + +http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310488&sorter/field=issuekey&sorter/order=DESC&status=1&status=4";>Search existing open bugs. +If you find your issue listed then please add a comment with your details. +http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/";>Search the mailing list archive. +You may find your issue or idea has already been discussed. +Decide if your issue is a bug or an enhancement. +Submit either a http://issues.apache.org/jira/secure/Create
[jira] Resolved: (POOL-96) Make "Issue tracking" page of commons-pool website point to JIRA instead of Bugzilla
[ https://issues.apache.org/jira/browse/POOL-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved POOL-96. - Resolution: Fixed Fixed thanks for pointing this out > Make "Issue tracking" page of commons-pool website point to JIRA instead of > Bugzilla > > > Key: POOL-96 > URL: https://issues.apache.org/jira/browse/POOL-96 > Project: Commons Pool > Issue Type: Bug >Reporter: Christoph Grothaus >Priority: Minor > > The "Issue tracking" page of the commons-pool website > http://jakarta.apache.org/commons/pool/issue-tracking.html points to > Bugzilla. Make it point to JIRA. -- 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: r521872 - /jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml
Author: niallp Date: Fri Mar 23 12:08:18 2007 New Revision: 521872 URL: http://svn.apache.org/viewvc?view=rev&rev=521872 Log: Update Pool issue-tracking page to point to Jira instead of Bugzilla Modified: jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml Modified: jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml?view=diff&rev=521872&r1=521871&r2=521872 == --- jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml (original) +++ jakarta/commons/proper/pool/trunk/xdocs/issue-tracking.xml Fri Mar 23 12:08:18 2007 @@ -1,64 +1,70 @@ - - - - - -Issue tracking -Commons Documentation Team - - - - - - -Commons Pool uses http://issues.apache.org/bugzilla/";>ASF Bugzilla for tracking issues. -To use Bugzilla you may need to http://issues.apache.org/bugzilla/createaccount.cgi";>create an account. - - -If you would like to report a bug, or raise an enhancement request with -Commons Pool please do the following: - -http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&product=Commons&component=Pool";>Search existing open bugs. -If you find your issue listed then please add a comment with your details. -http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/";>Search the mailing list archive. -You may find your issue or idea has already been discussed. -http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons&component=Pool&version=1.1%20Final&short_desc=%5Bpool%5D%20%22Your%20subject%20heading%20here%22&comment=Please%20provide%20details%20here.%20Its%20best%20to%20submit%20patches%20that%20alter%0D%0Aexisting%20file%20content%20in%20%22unified%20diff%22%20format.%20%0D%0A%0D%0ASubmissions%20that%20provide%20new%20files%20can%20be%20supplied%20as%20direct%20file%0D%0Aattachments%20or%20archives%20in%20zip%20or%20tar.gz%20format.%20Please%20be%20kind%20%0D%0Aenough%20to%20identify%20the%20format%20of%20the%20attached%20archive%20as%20Bugzilla%0D%0Atends%20to%20strip%20these%20characterstics%20by%20removing%20the%20files%20extension.";>Submit a bug report or enhancement request. -Please prefix all new issues with [pool] in the summary line. - - - - -Please also remember these points: - - the more information you provide, the better we can help you - test cases are vital, particularly for any proposed enhancements - the developers of Commons Pool are all unpaid volunteers - - - -You may also find these links useful: - - http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&product=Commons&component=Pool";>All Open Pool bugs - http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&product=Commons&component=Pool";>All Closed Pool bugs - http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&product=Commons&component=Pool";>All Pool bugs - - - - - - + + + + + +Issue tracking +Commons Documentation Team + + + + + + +Commons Pool uses http://issues.apache.org/jira/";>ASF JIRA for tracking issues. +See the http://issues.apache.org/jira/browse/POOL";>Pool JIRA project page. + + +To use JIRA you may need to http://issues.apache.org/jira/secure/Signup!default.jspa";>create an account + (if you have previously created/updated Commons issues using Bugzilla an account will have been automatically + created and you can use the http://issues.apache.org/jira/secure/ForgotPassword!default.jspa";>Forgot Password + page to get a new password). + + +If you would like to report a bug, or raise an enhancement request with +Commons Pool please do the following: + +http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310488&sorter/field=issuekey&sorter/order=DESC&status=1&status=4";>Search existing open bugs. +If you find your issue listed then please add a comment with your details. +http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/";>Search the mailing list archive. +You may find your issue or idea has already been discussed. +Decide if your issue is a bug or an enhancement. +Submit either a http://issues.apache.org/jira/secure/CreateIssueDetails!init.jspa?pid=12310488&
[logging] JCL in SLF4J flavour - a demo for discussion
Hello, I have seen the recent discussions on JCL 2.0.0 and a version without autodiscovery. Someone stated to stop any further development (with good reasons behind) but I am thinking different. Please have a look at the (working) code: https://issues.apache.org/jira/browse/LOGGING-112 It has a static binding, some improvements in the logfactories (recognizes native implementations). API and implementations are cleanly separated, the 1.1.x diagnostic function is still used. What are your thoughts? Is this a possible direction? Is it worth to put more time and energy into this? Regards Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LOGGING-112) [logging] Commons Logging in SLF4J flavour
[ https://issues.apache.org/jira/browse/LOGGING-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Unckel updated LOGGING-112: - Attachment: jcl-2.0.0.zip The complete project including POMs and sources. Use mvn clean install to build files or mvn eclipse:eclipse to create project files for eclipse. > [logging] Commons Logging in SLF4J flavour > -- > > Key: LOGGING-112 > URL: https://issues.apache.org/jira/browse/LOGGING-112 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Systems supporting JRE version 1.3 and above. >Reporter: Boris Unckel > Fix For: 2.0 > > Attachments: jcl-2.0.0.zip > > > There were some related discussions on the dev mailing list about a possible > JCL 2.0.0. > I have created a first draft version of JCL in SLF4J (http://www.slf4j.org/) > flavour. > It is based on Maven 2 and a clean separation of API and implementations, > without any fallback for an implementation > in runtime. It still consists of the same Log Wrappers as 1.1.x with one jar > each. > The source lacks on documentation and the JUnits are not ported yet. > This code is intended to show that an improved implementation has worth in > discussing and use. > It has been tested with Apache Tomcat 5.5.23 and JDK 6.0 on Windows Vista. > Please send your comments to the mailing list and not in the JIRA. -- 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: (LOGGING-112) [logging] Commons Logging in SLF4J flavour
[logging] Commons Logging in SLF4J flavour -- Key: LOGGING-112 URL: https://issues.apache.org/jira/browse/LOGGING-112 Project: Commons Logging Issue Type: Improvement Affects Versions: 2.0 Environment: Systems supporting JRE version 1.3 and above. Reporter: Boris Unckel Fix For: 2.0 There were some related discussions on the dev mailing list about a possible JCL 2.0.0. I have created a first draft version of JCL in SLF4J (http://www.slf4j.org/) flavour. It is based on Maven 2 and a clean separation of API and implementations, without any fallback for an implementation in runtime. It still consists of the same Log Wrappers as 1.1.x with one jar each. The source lacks on documentation and the JUnits are not ported yet. This code is intended to show that an improved implementation has worth in discussing and use. It has been tested with Apache Tomcat 5.5.23 and JDK 6.0 on Windows Vista. Please send your comments to the mailing list and not in the JIRA. -- 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: svn commit: r520602 - in /jakarta/commons/proper/transaction/trunk: ./ lib/
On 3/20/07, Joerg Heinicke <[EMAIL PROTECTED]> wrote: > Author: joerg > Date: Tue Mar 20 14:15:48 2007 > New Revision: 520602 > > URL: http://svn.apache.org/viewvc?view=rev&rev=520602 > Log: > replace the geronimo spec jars compiled by me at least with the now officially > released ones > (this is only a temporary solution as long as we don't have an Ant build > fetching the jars itself) Somebody offered some time ago to help with converting the Ant build fetching the jars itself or even did it on another Jakarta Commons project. Is he or she still willing to help? ;) What's the best way to do it in Ant? Can't remember if I did or not - anyway I've added a download target to the ant build http://svn.apache.org/viewvc?view=rev&revision=521856 Niall Regards Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r521856 - /jakarta/commons/proper/transaction/trunk/build.xml
Author: niallp Date: Fri Mar 23 11:43:29 2007 New Revision: 521856 URL: http://svn.apache.org/viewvc?view=rev&rev=521856 Log: Add a target to download transaction's dependencies Modified: jakarta/commons/proper/transaction/trunk/build.xml Modified: jakarta/commons/proper/transaction/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diff&rev=521856&r1=521855&r2=521856 == --- jakarta/commons/proper/transaction/trunk/build.xml (original) +++ jakarta/commons/proper/transaction/trunk/build.xml Fri Mar 23 11:43:29 2007 @@ -61,6 +61,7 @@ Set the properties for the build area === --> + http://mirrors.ibiblio.org/pub/mirrors/maven2"/> @@ -515,4 +516,40 @@ - \ No newline at end of file + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DIGESTER-112) Additional (XML) rules that allow a Digester to be used for updating an existing object structure.
Additional (XML) rules that allow a Digester to be used for updating an existing object structure. -- Key: DIGESTER-112 URL: https://issues.apache.org/jira/browse/DIGESTER-112 Project: Commons Digester Issue Type: Improvement Affects Versions: 1.7 Reporter: Mirko Reinhardt Priority: Minor Digester is really great to build new Object structures from xml file definitions. But it isn't (yet) really helpful in case one wants to update an existing Object structure with data provided in an xml file. Currently we have a project with a 2-phase configuration. We implemented a generic API, which is configured in the first phase using an internal xml file to become a "real application", which can be delivered to an end user. In the second phase the end user should now be able to reconfigure certain properties of the application in order to adapt it to their needs. In particular, it would be nice, if I could just push the base Object of our configuration (created in the first phase) onto the stack of a Digester and then let it parse the user-configuration file using some rules to re-set the Object's properties with values from the file. What I miss most for that purpose is some "retrieve-object-rule". This rule should work like the combination of a "call-method-rule" and a "create-object-rule" in a way that - it is fired at the begin() of the tag - it calls a configurable method on some object on the Digester's stack (with all those nice features of a call-method-rule, like target-offset, variable amount and kind of parameter, etc) - it should then push the result object of this method call onto the Digester's stack - and (of course) it should pop the object from the Digester's stack at the end() of the tag I have implemented such a rule, which does enough for me to use it, basically "inspired" by the code of the call-method-rule. But I think it's hardly worth being contributed (yet). Especially I didn't manage the dynamic parameters part, since the rule fires on begin(), so a simple combination with the "call-param-rule" isn't possible. Of cource it would be nice to have this new rule also available in xml-rules files. Another feature I miss is, that the "set-property-rule" isn't capable of setting a known static property (configured directly in the rule) to a value taken from an attribute (or the body) of an xml tag. -should set the property called "text" to the value "content" -should set the property called "text" to the value of the attribute "content" I know, I could use a "call-method-rule" here, but it would be a nice shortcut :) I feel like those extensions could be useful to others, too. Maybe you could include them in some future release. With best regards Mirko -- 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] Updated: (FILEUPLOAD-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Macaluso updated FILEUPLOAD-130: Attachment: FileUpload-130_2.patch Here is another version that reduces the changes. It adds an interface called FileItemHeadersSupport and a class Headers. The FileItemHeadersSupport interface adds an ability to get and set the headers on the instance. The class Headers is a utility class that helps in the nasty casting that is required when using the FileItemHeadersSupport interface. The only two classes modified are DiskFileItem and FileUploadBase. The implementations of FileItem and FileItemStream within this package (i.e., DiskFileItem and FileItemStreamImpl) implement this interface. Since you really can not implement your own FileItemStream, that side is covered. If one implements a custom FileItem implementation and does not inherit from DiskFileItem, then all they must do is implement the FileItemHeadersSupport interface and the headers will be available. Docs will be done after we agree on the final approach. > Add ability to get any header from the FileItem and FileItemStream interfaces > - > > Key: FILEUPLOAD-130 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Michael Macaluso >Priority: Minor > Attachments: FileUpload-130_1.patch, FileUpload-130_2.patch > > > The FileItem and FileItemStream interfaces should have a way to return back > any header that was encountered during the header parsing for an "Item". > Currently, from the FileItemStatus you can only get information from the 2 > pre-defined headers "Content-Type" and "Content-Disposition" (Sort-of because > the header can not be accessed raw). Other than the interface changes > (including the change to pass them along in the FileItemFactory interface), > it appears that all changes can be made within the FileUploadBase.java file. > FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create > the FileItemStreamImpl on lines 877 and 887 do not include the headers map. > Further, the parseRequest method uses the FileItemStream interface to build > the FileItem, so you should always have the headers in question. > The reason for this request is that we have an application that is sending > per-part headers (not precluded by the specs as far as we know of) to provide > more information than name and content-type and using the FileUpload project > means that we can no longer find out those header values. > [Also, not completely sure, but I believe FileUploadBase.createItem(Map, > boolean) on line 480 is not referenced anymore in this project.] -- 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: (FILEUPLOAD-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483591 ] Michael Macaluso commented on FILEUPLOAD-130: - Great comments. I was a little concerned when doing these changes that it was a tad too extensive. I will redesign this to reduce the changes and then re-submit the patch. Not sure if it will be today, but it will be within the next couple. > Add ability to get any header from the FileItem and FileItemStream interfaces > - > > Key: FILEUPLOAD-130 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Michael Macaluso >Priority: Minor > Attachments: FileUpload-130_1.patch > > > The FileItem and FileItemStream interfaces should have a way to return back > any header that was encountered during the header parsing for an "Item". > Currently, from the FileItemStatus you can only get information from the 2 > pre-defined headers "Content-Type" and "Content-Disposition" (Sort-of because > the header can not be accessed raw). Other than the interface changes > (including the change to pass them along in the FileItemFactory interface), > it appears that all changes can be made within the FileUploadBase.java file. > FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create > the FileItemStreamImpl on lines 877 and 887 do not include the headers map. > Further, the parseRequest method uses the FileItemStream interface to build > the FileItem, so you should always have the headers in question. > The reason for this request is that we have an application that is sending > per-part headers (not precluded by the specs as far as we know of) to provide > more information than name and content-type and using the FileUpload project > means that we can no longer find out those header values. > [Also, not completely sure, but I believe FileUploadBase.createItem(Map, > boolean) on line 480 is not referenced anymore in this project.] -- 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]
[nightly build] betwixt failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070323/betwixt.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-113) NullPointerException during getting InputStream from SftpFileObject
[ https://issues.apache.org/jira/browse/VFS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483506 ] Tim Rademacher commented on VFS-113: Hi, I experienced some errors while testing the new functionality: org.apache.commons.vfs.FileSystemException: Could not copy "sftp://[EMAIL PROTECTED]/blabla.txt" to "sftp://[EMAIL PROTECTED]/archive/blabla.txt". at org.apache.commons.vfs.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:919) at org.apache.commons.vfs.provider.AbstractFileObject.moveTo(AbstractFileObject.java:981) at de.inka.service.file.InkaFileSystemConnection.move(InkaFileSystemConnection.java:463) ... 11 more Caused by: org.apache.commons.vfs.FileSystemException: Could not close the input stream for file "sftp://[EMAIL PROTECTED]/data_santiago/zdm/java_jobs/dvoimport/test/PositionenInka3_1015.asc". at org.apache.commons.vfs.provider.DefaultFileContent$FileContentInputStream.close(DefaultFileContent.java:525) at org.apache.commons.vfs.FileUtil.writeContent(FileUtil.java:87) at org.apache.commons.vfs.FileUtil.copyContent(FileUtil.java:103) at org.apache.commons.vfs.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:910) ... 13 more Caused by: java.io.IOException: error at com.jcraft.jsch.ChannelSftp$2.close(ChannelSftp.java:1178) at java.io.BufferedInputStream.close(Unknown Source) at org.apache.commons.vfs.util.MonitorInputStream.close(MonitorInputStream.java:115) at java.io.BufferedInputStream.close(Unknown Source) at org.apache.commons.vfs.util.MonitorInputStream.close(MonitorInputStream.java:115) at org.apache.commons.vfs.provider.DefaultFileContent$FileContentInputStream.close(DefaultFileContent.java:521) ... 16 more or java.lang.NullPointerException at com.jcraft.jsch.ChannelSftp.fill(ChannelSftp.java:2153) at com.jcraft.jsch.ChannelSftp.header(ChannelSftp.java:2179) at com.jcraft.jsch.ChannelSftp.access$7(ChannelSftp.java:2177) at com.jcraft.jsch.ChannelSftp$2.read(ChannelSftp.java:1100) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.apache.commons.vfs.util.MonitorInputStream.read(MonitorInputStream.java:88) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.apache.commons.vfs.util.MonitorInputStream.read(MonitorInputStream.java:88) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(Unknown Source) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(Unknown Source) at sun.nio.cs.StreamDecoder.read(Unknown Source) at java.io.InputStreamReader.read(Unknown Source) at com.Ostermiller.util.CSVLexer.zzRefill(CSVLexer.java:605) at com.Ostermiller.util.CSVLexer.getNextToken(CSVLexer.java:789) at com.Ostermiller.util.CSVParser.getLine(CSVParser.java:335) at com.Ostermiller.util.LabeledCSVParser.setLabels(LabeledCSVParser.java:245) at com.Ostermiller.util.LabeledCSVParser.getLine(LabeledCSVParser.java:211) at de.inka.dvo.dao.FileImport.importFile(FileImport.java:199) at de.inka.dvo.ExportController.doOnNewFile(ExportController.java:345) at de.inka.dvo.dao.FileObserver.processForward(FileObserver.java:112) at de.inka.dvo.dao.FileObserver.processForward(FileObserver.java:1) at de.inka.util.observer.InkaObserver.update(InkaObserver.java:171) at de.inka.util.observer.InkaObservable.notifyObservers(InkaObservable.java:483) at de.inka.service.file.observer.FileObservable.processMessage(FileObservable.java:295) at de.inka.service.file.observer.FileObservable.processMessage(FileObservable.java:1) at de.inka.util.observer.InkaObservable$WorkerRunnable.run(InkaObservable.java:121) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) What I think is, that one thread opens the connection and returns the input stream to anywhere. While the input stream is processed, another thread does anything else with sftp. It gets the same SftpChannel from the FileSystem, opens it (again?) and closes it, when it's finished. Then the first thread seems to get the error. I also got sometimes an InputStreamClosed Exception, which seems to support my theory. I have to look further... Regards Tim > NullPointerException during getting InputStream from SftpFileObject > --- > > Key: VFS-113 > URL: https://issues.apache.org/jira/browse/VFS-113 > Project: Commons VFS > Issue
