RE: Any news about Bug #3465 assigned to Mike Schachter?
Hello Hans, That bug's been around for a long time. The reason it remains there is because I've never been able to verify it; but I've seen the problem with the java.io.File.delete() method in the past with other projects. Have you verified that the bug exists in your application? -Original Message- From: Hans-Joachim Matheus [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 11:11 AM To: [EMAIL PROTECTED] Subject: Any news about Bug #3465 assigned to Mike Schachter? Hi, I wonder if there is any news about this bug? Maybe this has something to do with the path and the permission to delete a file? I wonder why first the ServletContext attribute javax.servlet.context.tempdir is used and if this is null then the Servlet Init Parameter tempDir is used and not vice versa. In Tomcat 3 the javax.servlet.context.tempdir is the dir where jasper compiles the jsps (i.e. the worker dir). Does this mean that struts has no permission to delete files in there? If I have a WebApp with many file uploads this is very bad because of an ever growing temp dir. Thanks for your hints... Hans-Joachim Matheus -- mailto:[EMAIL PROTECTED] \ in-integrierte informationssysteme GmbH \ Am Seerhein 8 Tel +49 (0)7531/8145-0 \ D-78467 Konstanz Fax -81 \ http://www.in-gmbh.de \ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Struts 1.1 Beta 1 Release Plan
-- Vote: Struts 1.1b1 Release Plan [x] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
goats
File upload is complete for 1.1 beta, +1 for anything that involves people downloading it and breaking stuff ;)
RE: The missing release plan
definately 2. i've been having a terrible time with multipart stuff, i'll still be working on it throughout the day. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 1:18 AM To: Struts Developers List Subject: The missing release plan Through informal discussion, we decided to go to Struts 1.1 Beta 1 on March 4th, which is today. However, I've realised that I dropped the ball, and did not produce a release plan, to be voted on by the committers. So the question is, how should I best recover? Here are a couple of options: 1) Continue with a Beta 1 release in the next day or so, regardless of a vote on the release plan, but depending on when the crucial fixes are checked in. 2) Post a release plan ASAP, and await a go vote before proceeding with the Beta 1 release. Other suggestions are welcome. Committers, please let me know what you would like me to do in this respect. -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: The missing release plan
It doesn't look like I'm going to get this multipart stuff done by today. The reason it's been taking so long (5 days and running now) is because I rewrote the portion of multipart that does all the parsing. I did that because it was the source of a few of the more critical file upload bugs, plus it was difficult to unit test MultipartIterator, which shouldn't have the parsing logic in it anyway. But the rewrite took forever; my intentions were to make a swanky efficient multipart stream parser and I basically failed to do so. So I rewrote it again this morning with less complex code and it seems to do better unit-test wise, but it's going to take a little more to get some files to work with browsers for some obscure reason. Fixing that should last me to around the time I have to go to class, and then the rest of the bug fixing and added documentation will take the rest of the night. I'm sorry for delaying the release schedule, i'm trying to make it worth everyone's while. -Original Message- From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 8:46 AM To: 'Struts Developers List' Subject: RE: The missing release plan definately 2. i've been having a terrible time with multipart stuff, i'll still be working on it throughout the day. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 1:18 AM To: Struts Developers List Subject: The missing release plan Through informal discussion, we decided to go to Struts 1.1 Beta 1 on March 4th, which is today. However, I've realised that I dropped the ball, and did not produce a release plan, to be voted on by the committers. So the question is, how should I best recover? Here are a couple of options: 1) Continue with a Beta 1 release in the next day or so, regardless of a vote on the release plan, but depending on when the crucial fixes are checked in. 2) Post a release plan ASAP, and await a go vote before proceeding with the Beta 1 release. Other suggestions are welcome. Committers, please let me know what you would like me to do in this respect. -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Request for March 5 Beta
Hi, Over the weekend I've been making some big changes to multipart and I need until tonight to fully test and document fixes. I'd really like this stuff to be in 1.1 beta. Would it be possible to wait until tomorrow to release 1.1 beta? I think the changes will definately benefit people using file upload and I'd have them all in by late tonight.
RE: MessageResources
The message resources work has been moved to Commons, for exactly this reason. It's currently in the sandbox under 'resources'. The problem at the moment seems to be that it's not at the top of anyone's list to work on (and that includes me, I'm afraid), so not a lot has happened for a while. same here with me unfortunately, i do plan to get to it though. i don't really think there's much left to actually do. If you have the time and inclination, feel free to take a look at what's there and propose additions and/or changes (on the commons-dev list). If you can post patches, I'll see what I can do about applying them. there's a page or so of documentation you get after building the project, that's hopefully enough to you started Dimitri. Everything should be usable, and as MessageResources hasn't changed forever (at least in that project), it should be the most stable Resources implementation, and you should be able to use it just like you would use the MessageResources class in Struts. It can be standalone or within the Resources Framework. -- Martin Cooper - Original Message - From: Dimitri Valdin [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, February 19, 2002 3:52 AM Subject: MessageResources It would be nice to have MessageResources(Factory) and PropertyMessageResources(Factory) to be packaged within some standalone jar file and not within struts. The classes can be useful not only for web, but also for ejb application as well. But if some wants to let ejb classes to use this features, then it is necessary to include struts.jar into system classpath of ejb container. This would mean, that common-xxx stuff should also be included into the system classpath. And path to web resources as well. This is a typical problem of different class loaders for ejb and web applications. Of course it occurs only in case web and ejb container is the same process. Please correct me if I am wrong. Just another point. Is it really necessary for abstract MessageResourcesFactory to know about concrete implementation: protected static String factoryClass = org.apache.struts.util.PropertyMessageResourcesFactory; It might be possible to set this value in ActionServlet, in case the factory parameter was not specified. Dmitri Valdin -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Date for 1.1 beta release
then i guess i better get my ass in gear ;) -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 4:43 PM To: Struts Developers List Subject: Re: Date for 1.1 beta release On Wed, 20 Feb 2002, SCHACHTER,MICHAEL (HP-NewJersey,ex2) wrote: Date: Wed, 20 Feb 2002 16:08:50 -0500 From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: Date for 1.1 beta release Hey, Sorry I haven't been really reading any emails pertaining to this subject... but when is the planned release time for 1.1 beta? Ted proposed March 4, which seems feasible from my perspective. If it's kinda soon (2-3 weeks) I'll make time to finish off commons-resources and outstanding file upload stuff ASAP. Apologies for my lack of participation in all this. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Adapting the O'Reilly servlet classes for Struts upload
Our customer had decided this may be worth to him, so at this point I'm exploring, trying to draw an estimate on how much time either option would take (XP style, see below). Either fix the bugs in the existing Struts upload module, or adapt O'Reilly's. How much time do you think it would take you? Here's estimates for the existing bugs: Bug #2017 Text entered in forms using multi-part/formdata cannot be utf8 To fix this, configuration parameters representing encoding need to be added to the config file and/or the character encoding needs to be detected in the request and passed to MultipartIterator. Special care needs to then be taken inside of MultipartIterator when handling text form elements. Maybe half a day's worth of work. Bug #5101 org.apache.struts.upload.MultipartIterator This is probably a few lines of code. An hour tops. Bug #5274 OutOfMemoryError when uploading big files --- This is important to fix, bad coding on my part. I need to get rid of all the calls to (byte[] readLine()) in MultipartIterator and replace them them with (int readLine(byte[], int, int)). There used to be a problem with the latter method dropping bytes, it needs to be verified that that problem doesn't pop back up. I have a test case or two to verify that it doesn't pop up though, so it shouldn't be too bad. A few hours. Bug #2757 file upload problem: MultipartIterator: invalid multipart request data, doesn't start with boundary --- The basic idea is that when you try to do a forward after a multipart request, the content type doesn't change and it still thinks it's a multipart request. I haven't really looked into it; it may be deeper than that, so I won't try to estimate. Bug #3465 FormFile.destroy() doesn't work for temporary files - As with my comment on the report, the problem lies in the java.io.File.delete() method, which seems to not work all the time on windows. I'm not too sure this is something that can be fixed. Bug #4170 MaxLengthExceeded doesn't stop file upload I need to not use Exceptions for stuff like that, because it's a pretty crappy and non-working way to do things. A few hours should be all thats need to fix this, and will result in a different method to use to validate uploads. Bug #5822 byte lost every 4096 bytes after a 0A --- If this bug exists in 1.0.1 like it says, then I'm baffled. This might take a while to fix. Talking architecture, I never understood how I could handle the MaxLengthExceededException raised when someone attempts to upload a file bigger than the maximum size. See http://marc.theaimsgroup.com/?l=struts-userm=100682691032695 Is this something that sould be entered in the bug database, as feature request maybe? How can this be solved? This is bug #4170. This can be solved by not throwing exceptions when the max length is exceeded. Maybe a flag could be set somewhere either in MultipartIterator, the MultipartRequestHandler, or somewhere else that can accessed in the validate() method (or whatever's being used to validate these days..). Aside from not working, Exceptions have been said to suck up performance and are a bad way to do things, in my opinion. Although I'm not sure how much time I have, I'll be sure to make time to fix the critical stuff (2017, 5274, 4170, 5822), and to discuss fixes over email on the problems at hand. - mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Adapting the O'Reilly servlet classes for Struts upload
Renaud, My company is using Struts pretty extensively, the upload module in particular, and we've come across some pretty serious bugs that have prompted an internal discussion about its deficiencies. ;) I found a post to struts-dev where Mike wishes he had the time to replace the existing upload code with O'Reilly's implementation -- or at least this is my understanding, correct me if I'm wrong. Hmm. I think I was trying to make an implementation of struts upload that used the O'Rielly upload package. Replacing the existing upload code isn't really necessary, but fixing some bugs in the existing package is. As my company has a business interest in getting the upload module working perfectly, they may be willing to do the work and donate it to the Struts project. But first I'd like to hear from you what the current status of the Struts upload is like; is it in your opinion stable and production quality? Is integrating the O'Reilly upload stuff in Struts a good idea? A quick link to the list of bugs for File Upload: http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSI GNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1em ail2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=change din=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutscomponen t=File+Uploadshort_desc=short_desc_type=allwordssubstrlong_desc=long_des c_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeyword s=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype =doitorder=%27Importance%27 There are 10 outstanding issues for file upload in Struts, some minor, some not so minor. I'm almost at the point where I can devote some time to addressing these issues, and maybe even do a partial re-write of the MultipartIterator class if necessary. It would definately be worth your time, if you're willing to work on it, to address these bugs. I'll be a bit more vigilant about email and help out as much as I can. To start you really want to look at the DiskMultipartRequestHandler and MultipartIterator class, thats where all the trouble starts. There's a few ways it could be improved, and in further emails I'd be happy about going into detail. The overall architecture of file upload is not too bad in my opinion, and doesn't need changing. Just the implementation. I bet there might be some performance issues too, which I think I'm much more capable of handling now than when I first wrote it. So, how about we do this extreme programming style, where we figure out what needs to be done to get stuff running as optimally as possible through email, break up the things into small tasks, and take on the tasks one by one. I'd be more than happy to make the struts upload work as well as possible, it's been bothering me for a while and I haven't had time. Thank you for your answers, --Renaud Thank you for helping, Mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Release Struts 1.0.1-rc1 as Struts 1.0.1
-- Vote: Release Struts 1.0.1-rc1 as Struts 1.0.1 [ ] +1 I am in favor of the release, and will help support it [x] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: TODO List: XmlMessageResources volunteer
Hi Mihai, Please check out the resources sub-folder of the jakarta-commons-sandbox project. I haven't been able to work on it, but there's an implementation of XmlMessageResources there that should (hopefully, eventually) make it into the jakarta-commons package. -Original Message- From: mihai iancu [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 08, 2001 10:48 PM To: [EMAIL PROTECTED] Subject: TODO List: XmlMessageResources volunteer Hi all, I have been using for a while in production environment a slightly modified version of struts.jar (now v 1.0), and developed code using the struts framework. The biggest challenge was/is to manage the property file that contains key-value pairs for the messages, since a large number of developers are using it. I am working on an xml implementation of MessageResources that is using ResourceBundle and a custom xml parser. The resources (and corresponding xml master files) are split in three categories: language, error/exception and url. The parser is designed to load files referenced in any other xml files referenced by using an include-file tag. Each software module is using its own set of xml files that are included in the master xml files. This implementation is compatible with the current struts implementation (by using a waterfall search for the value of the key in the LanguageClass_locale, ErrorClass_locale or UrlClass_locale resource class; with a consistent naming convention for the key, the message can be pinpointed in the correct implementation class...). Comments, suggestions, death threats :) ? Cheers, Mihai Iancu Sr. Software Developer -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: i think i screwed up cvs...
Would it work if I did a cvs rtag -d STRUTS_1_0_1 jakarta-struts? I got that from here: http://www.cvshome.org/docs/manual/cvs_4.html#SEC51 I'm really sorry about all this, I thought I wasn't connected to cvs.apache.org when I did it. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 21, 2001 2:58 AM To: Struts Developers List Subject: Re: i think i screwed up cvs... Ack ... I don't know of any undo commands for this (hope somebody else does). Of course, it is the -b part of the command that is the problem here. If it can't be undone, life can still go on ... just tag the right files with STRUTS_1_0_1_RELEASE or something, and post a comment to STRUTS-DEV on what the real tag is (for posterity). Craig On Tue, 20 Nov 2001, SCHACHTER,MICHAEL (HP-NewJersey,ex2) wrote: Date: Tue, 20 Nov 2001 20:57:29 -0800 From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: i think i screwed up cvs... Hey, I did a cvs rtag -b -r STRUTS_1_0 STRUTS_1_0_1 jakarta-struts, thinking it would create a local copy of STRUTS_1_0_1 stuff on my machine and I created another branch on the CVS repository called STRUTS_1_0_1... is there a way to get rid of that branch, base it off of STRUTS_1_0_BRANCH instead, or something else to un-screwup cvs? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/upload BufferedMultipartInputStream.java MultipartIterator.java
Ted,
Unless someone else (Martin?) improved it, the problem that I think
you're talking about wasn't addressed. Are you referring to this bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4170
The following bugs were addressed:
#3828, problem with equals() method (possibly because of file text
containing PGP signature)
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3828
#4427, where bytes can be lost when using the readLine(byte[],int,int).
this fix no longer affects the actual multipart form handling in struts,
just anyone using the MultipartIterator class on it's own.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4427
#4701, report a premature closing of the input stream, instead of
leaving it up to a NullPointerException
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4701
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 21, 2001 6:50 AM
To: Struts Developers List
Subject: Re: cvs commit:
jakarta-struts/src/share/org/apache/struts/upload
BufferedMultipartInputStream.java MultipartIterator.java
So, in the release notes (nightly and 1.0.1) we're saying
liImproved error-handling on out of bounds conditions/li
Does that cover well-enough what we're doing here?
[EMAIL PROTECTED] wrote:
mschachter01/11/20 21:04:36
Modified:src/share/org/apache/struts/upload Tag: STRUTS_1_0_BRANCH
BufferedMultipartInputStream.java
MultipartIterator.java
Log:
- fix #3828, equals() method problem (ported from main branch)
Submitted By: Curt Hagenlocher
- fix #4427, lost bytes on read(byte[],int,int) (need to port to main
branch)
Submitted By: Mike Goutrie
- fix #4701, premature end of input stream not reported (need to port
to main branch)
Submitted By: Roland Huss
Revision ChangesPath
No revision
No revision
1.3.2.4 +40 -40
jakarta-struts/src/share/org/apache/struts/upload/BufferedMultipartInputStre
am.java
Index: BufferedMultipartInputStream.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/BufferedMultipar
tInputStream.java,v
retrieving revision 1.3.2.3
retrieving revision 1.3.2.4
diff -u -r1.3.2.3 -r1.3.2.4
--- BufferedMultipartInputStream.java 2001/10/05 20:26:09 1.3.2.3
+++ BufferedMultipartInputStream.java 2001/11/21 05:04:36 1.3.2.4
@@ -10,60 +10,60 @@
* readLine() method.
*/
public class BufferedMultipartInputStream extends InputStream {
-
+
/**
* The underlying InputStream used by this class
*/
protected InputStream inputStream;
-
+
/**
* The byte array used to hold buffered data
*/
protected byte[] buffer;
-
+
/**
* The current offset we're at in the buffer's byte array
*/
protected int bufferOffset = 0;
-
+
/**
* The size of the byte array buffer
*/
protected int bufferSize = 8192;
-
+
/**
* The number of bytes read from the underlying InputStream that
are
* in the buffer
*/
protected int bufferLength = 0;
-
+
/**
* The total number of bytes read so far
*/
protected int totalLength = 0;
-
+
/**
* The content length of the multipart data
*/
protected long contentLength;
-
+
/**
* The maximum allowed size for the multipart data, or -1 for an
unlimited
* maximum file length
*/
protected long maxSize = -1;
-
+
/**
* Whether or not bytes up to the Content-Length have been read
*/
protected boolean contentLengthMet = false;
-
+
/**
* Whether or not bytes up to the maximum length have been read
*/
protected boolean maxLengthMet = false;
-
-
+
+
/**
* Public constructor for this class, just wraps the InputStream
* given
@@ -81,14 +81,14 @@
this.bufferSize = bufferSize;
this.contentLength = contentLength;
this.maxSize = maxSize;
-
+
if (maxSize contentLength) {
throw new MaxLengthExceededException(maxSize);
}
buffer = new byte[bufferSize];
fill();
}
-
+
/**
* This method returns the number of available bytes left to read
* in the buffer before it has to be refilled
@@ -96,50 +96,50 @@
public int available() {
return bufferLength - bufferOffset;
}
-
+
/**
* This method attempts to close the underlying InputStream
*/
public void close() throws IOException {
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/uploadBufferedMultipartInputStream.java MultipartIterator.java
liFixed lost byte problem in
BufferedMultipartInputStream.readLine(byte[],int,int),
ArrayIndexOutOfBoundsException situations in MultipartIterator.equals(...),
and
better reporting for premature closing of input streams while reading
multipart requests./li
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 21, 2001 11:13 AM
To: Struts Developers List
Subject: Re: cvs commit:
jakarta-struts/src/share/org/apache/struts/uploadBufferedMultipartInputS
tream.java MultipartIterator.java
Can you boil this down for an entry to the release notes?
SCHACHTER,MICHAEL (HP-NewJersey,ex2) wrote:
Ted,
Unless someone else (Martin?) improved it, the problem that I think
you're talking about wasn't addressed. Are you referring to this bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4170
The following bugs were addressed:
#3828, problem with equals() method (possibly because of file text
containing PGP signature)
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3828
#4427, where bytes can be lost when using the readLine(byte[],int,int).
this fix no longer affects the actual multipart form handling in struts,
just anyone using the MultipartIterator class on it's own.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4427
#4701, report a premature closing of the input stream, instead of
leaving it up to a NullPointerException
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4701
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 21, 2001 6:50 AM
To: Struts Developers List
Subject: Re: cvs commit:
jakarta-struts/src/share/org/apache/struts/upload
BufferedMultipartInputStream.java MultipartIterator.java
So, in the release notes (nightly and 1.0.1) we're saying
liImproved error-handling on out of bounds conditions/li
Does that cover well-enough what we're doing here?
[EMAIL PROTECTED] wrote:
mschachter01/11/20 21:04:36
Modified:src/share/org/apache/struts/upload Tag: STRUTS_1_0_BRANCH
BufferedMultipartInputStream.java
MultipartIterator.java
Log:
- fix #3828, equals() method problem (ported from main branch)
Submitted By: Curt Hagenlocher
- fix #4427, lost bytes on read(byte[],int,int) (need to port to main
branch)
Submitted By: Mike Goutrie
- fix #4701, premature end of input stream not reported (need to port
to main branch)
Submitted By: Roland Huss
Revision ChangesPath
No revision
No revision
1.3.2.4 +40 -40
jakarta-struts/src/share/org/apache/struts/upload/BufferedMultipartInputStre
am.java
Index: BufferedMultipartInputStream.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/BufferedMultipar
tInputStream.java,v
retrieving revision 1.3.2.3
retrieving revision 1.3.2.4
diff -u -r1.3.2.3 -r1.3.2.4
--- BufferedMultipartInputStream.java 2001/10/05 20:26:09 1.3.2.3
+++ BufferedMultipartInputStream.java 2001/11/21 05:04:36 1.3.2.4
@@ -10,60 +10,60 @@
* readLine() method.
*/
public class BufferedMultipartInputStream extends InputStream {
-
+
/**
* The underlying InputStream used by this class
*/
protected InputStream inputStream;
-
+
/**
* The byte array used to hold buffered data
*/
protected byte[] buffer;
-
+
/**
* The current offset we're at in the buffer's byte array
*/
protected int bufferOffset = 0;
-
+
/**
* The size of the byte array buffer
*/
protected int bufferSize = 8192;
-
+
/**
* The number of bytes read from the underlying InputStream that
are
* in the buffer
*/
protected int bufferLength = 0;
-
+
/**
* The total number of bytes read so far
*/
protected int totalLength = 0;
-
+
/**
* The content length of the multipart data
*/
protected long contentLength;
-
+
/**
* The maximum allowed size for the multipart data, or -1 for an
unlimited
* maximum file length
*/
protected long maxSize = -1;
-
+
/**
* Whether or not bytes up to the Content-Length have been read
*/
protected boolean contentLengthMet = false;
-
+
/**
* Whether or not bytes up to the maximum length have been read
*/
protected boolean maxLengthMet = false;
-
-
+
+
/**
* Public constructor for this class, just wraps the InputStream
* given
CVS Tag for 1.0.1?
Hey, What's the proper CVS tag to use for fixes for the 1.0.1 release? Is it STRUTS_1_0 or STRUTS_1_0_BRANCH, or something else? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
i think i screwed up cvs...
Hey, I did a cvs rtag -b -r STRUTS_1_0 STRUTS_1_0_1 jakarta-struts, thinking it would create a local copy of STRUTS_1_0_1 stuff on my machine and I created another branch on the CVS repository called STRUTS_1_0_1... is there a way to get rid of that branch, base it off of STRUTS_1_0_BRANCH instead, or something else to un-screwup cvs? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: i think i screwed up cvs...
I'm a bit confused now... Was the STRUTS_1_0_1 branch put in recently and I just thought I put it there? Did I actually do anything? And if I didn't, I just committed multipart changes to STRUTS_1_0_BRANCH, should I now re-commit them to the STRUTS_1_0_1 branch? Am I just going crazy? Sorry for any potential confusion/trouble I've caused. -Original Message- From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) Sent: Tuesday, November 20, 2001 11:57 PM To: '[EMAIL PROTECTED]' Subject: i think i screwed up cvs... Hey, I did a cvs rtag -b -r STRUTS_1_0 STRUTS_1_0_1 jakarta-struts, thinking it would create a local copy of STRUTS_1_0_1 stuff on my machine and I created another branch on the CVS repository called STRUTS_1_0_1... is there a way to get rid of that branch, base it off of STRUTS_1_0_BRANCH instead, or something else to un-screwup cvs? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] XMLMessageResources
Martin, In the jakarta-commons-sandbox, there's a folder called resources containing Struts MessageResources and some other classes that I was working on, but had to put off for a while. It seemed before that MessageResources were being factored out of Struts and into jakarta-commons, and if this is still the case (Craig?), I can free up some time now to finish off the remaining code and maybe go 1.0 with it, along with your XmlMessageResources class. Do you have committer access to the sandbox? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 11, 2001 2:08 AM To: [EMAIL PROTECTED] Subject: [PROPOSAL] XMLMessageResources The Struts 1.1 TODO list contains the following item: XmlMessageResources. Implementation of MessageResources and MessageResourcesFactory that loads message keys and strings from one or more XML resources or files. I have an implementation of this which I would like to contribute to Struts. The implementation is a drop-in replacement for the existing PropertyMessageResources. In fact, it is derived from it, and so shares the same file naming scheme for locale-specific messages. Here's a simple example of what an XML message file would look like: -- begin example -- ?xml version=1.0 encoding=ISO-8859-1? messages message key=validation.username.requiredYou must enter a username/message message key=validation.password.requiredYou must enter a password/message message key=validation.password.matchConfirmation password does not match/message /messages -- end example -- The first line of the example provides a hint as to why I did not attempt to incorporate messages for more than one locale into a single XML file. Messages for different locales may well be specified using different character encodings. In addition, maintaining the messages from each locale in a different XML file avoids loading locales unnecessarily. To use this implementation, all that is required is to specify the 'factory' init-param in your web.xml file, and to make sure that the 'application' init-param refers to an XML resource. What do people think about incorporating this into the Struts 1.1 code base? -- Martin Cooper
Re: File Upload - \n inserts in DiskMultipartl
Buenos Dias Mark, There's been a few issues with multipart form handling, but I won't be able to work on this stuff until middle to late next week. This one in particular has been reported to bugzilla and will be taken care of, thank you. -Original Message- From: Mark Takacs [mailto:[EMAIL PROTECTED]] Sent: Friday, August 03, 2001 7:43 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: File Upload - \n inserts in DiskMultiPart We ran into this bug when using Struts uploads on a Microsoft Excel spreadsheet that we are trying to run a conversion utility (xlHtml) on. The Excel conversion was failing when done via upload, but not when done via commmand line. After some sleuthing, it looks like struts is clobbering the last char of the web.xml bufferSize with a \n char. I added some details to an existing bug covering this problem. -tak -- http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2503 Using struts to handle uploaded files, if the files contain lines 4k (or the file is binary), the file data gets \n characters inserted at the 4k boundaries of the long lines. /--- Additional Comments From Tak mailto:[EMAIL PROTECTED] 2001-08-03 16:33 ---/ This seems very clear-cut. At least the error, in any case. I'm looking at the 1.0 final codebase. The 4096 limit comes directly from the (default) value in web.xml init-param param-namebufferSize/param-name param-value4096/param-value /init-param Uploading a (binary) file and doing a cmp results in the following: cmp -l /tmp/strts27203.tmp ~/myBinaryFileTest.xls Byte# Oct Oct 4097 12 57 8194 12 144 12291 12 142 16388 12 145 20485 12 156 24582 12 147 28679 12 55 71584 12 0 This sez that every 4096 bytes, a linefeed (Octal 12) is being inserted instead of the various original data (last column) upload.DiskMultipartRequestHandler.java seems like a good place to start. It pulls the value (4096) out of the config file and (?) cuts up the input into bufferSize'd chunks which are stored in a Hashtable. Whatever is writing that hashtable back to disk is replacing the last char of each hashtable value with a \n and writing the file out. Or maybe the First char of the next block? I'm hoping that bumping the config file value of bufferSize is an acceptable workaround for now...
RE: Bug
Mason,
Would you mind sending me a copy of the file/s that were
corrupted? I'm having trouble corrupting the files that
I have, whether it be a .zip or .xls
-Original Message-
From: Mason Blackwood [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 28, 2001 9:33 AM
To: [EMAIL PROTECTED]
Subject: Bug
Hi,
The Bug Reporting System dosn't seem to be working so hope you don't mind me
logging it this way.
There appears to be a bug in the File Upload fucntionality of Struts 1.0
Final Release.
After uploading a file and doing a binary compare of the original file and
the one uploaded, the files are different. Some characters in the uploaded
file have been replaced with a newline ('\n') character.
From the code, I deduced that the problem was due to the fact that
MultipartIterator::createLocalFile was calling
inputStream.readLine(lineBuffer, 0, MAX_LINE_SIZE) and assuming that a
newline character was always found. This is not the case if you have filled
your buffer to MAX_LINE_SIZE without finding a newline. Because of this
assumption, a newline character was always being added. However, this didn't
explain why the original character was being replaced by a newline. That
problem lies in BufferedMultipartInputStream::readLine, because if no
newline character is found it reads one extra character from the stream and
does nothing with it.
I've made the changes which fix this problem and tested it briefly. I have
included the original function followed by the modified one below for your
approval.
Original:
public int readLine(byte[] b, int offset, int length) throws IOException
{
int count = 0;
int read = read();
if (read == -1) {
return -1;
}
while ((read != -1) (count length)) {
if (read == '\n')
break;
b[offset] = (byte) read;
count++;
offset++;
read = read();
}
return count;
}
Modified:
public int readLine(byte[] b, int offset, int length) throws IOException
{
int count = 0;
int read = read();
if (read == -1) {
return -1;
}
while ((read != -1) (count length)) {
if (read == '\n')
break;
b[offset] = (byte) read;
count++;
offset++;
if (count length)
read = read();
}
return count;
}
Original:
protected File createLocalFile() throws IOException {
File tempFile = File.createTempFile(strts, null, new
File(tempDir));
BufferedOutputStream fos = new BufferedOutputStream(new
FileOutputStream(tempFile), diskBufferSize);
byte[] lineBuffer = new byte[MAX_LINE_SIZE];
int bytesRead = inputStream.readLine(lineBuffer, 0, MAX_LINE_SIZE);
boolean cutCarriage = false;
boolean cutNewline = false;
try {
while ((bytesRead != -1) (!equals(lineBuffer, 0,
boundaryBytes.length,
boundaryBytes))) {
if (cutCarriage) {
fos.write('\r');
}
if (cutNewline) {
fos.write('\n');
}
cutCarriage = false;
if (bytesRead 0) {
if (lineBuffer[bytesRead-1] == '\r') {
bytesRead--;
cutCarriage = true;
}
}
cutNewline = true;
fos.write(lineBuffer, 0, bytesRead);
bytesRead = inputStream.readLine(lineBuffer, 0,
MAX_LINE_SIZE);
}
}
catch (IOException ioe) {
fos.close();
tempFile.delete();
throw ioe;
}
fos.flush();
fos.close();
return tempFile;
}
Modifed:
protected File createLocalFile() throws IOException {
File tempFile = File.createTempFile(strts, null, new
File(tempDir));
BufferedOutputStream fos = new BufferedOutputStream(new
FileOutputStream(tempFile), diskBufferSize);
byte[] lineBuffer = new byte[MAX_LINE_SIZE];
int bytesRead = inputStream.readLine(lineBuffer, 0, MAX_LINE_SIZE);
boolean cutCarriage = false;
boolean cutNewline = false;
try {
while ((bytesRead != -1) (!equals(lineBuffer, 0,
boundaryBytes.length, boundaryBytes))) {
if (cutCarriage) {
fos.write('\r');
cutCarriage = false;
}
if (cutNewline) {
fos.write('\n');
cutNewline = false;
}
if (bytesRead 0) {
if (lineBuffer[bytesRead - 1] == '\r') {
cutCarriage = true;
RE: [VOTE] Two New Committers
+1,+1 -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 24, 2001 6:55 AM To: [EMAIL PROTECTED] Subject: [VOTE] Two New Committers I would like to propose the following individuals for Committer status on the Struts project: Oleg V Alexeev David Winterfeldt The have both contributed significant new extensions to the Struts community, and as Committers they can help integrate these extensions with the nightly distributions. With Cedric's Components, this would make three new elements that we could start testing with the nightly distributions. Of course, we are just beginning the next development cycle, so all new contributions can be seen as developments-in-progress again. But it would be easier to work with these contributions if they were part of the nightly distribution, rather than separate downloads. Votes please? -Ted.
RE: WhoWeAre
Ted, If you could add this for me I'd appreciate it: --- Mike Schachter I'm currently a student of computer science at Drexel University in Philadelphia, PA. I've been working at HP Middleware, formerly Bluestone Software for 3 years programming in Java and recently J2EE technologies. I'm a full time worker from September until April and a student and part time worker from April until August. In my spare time I've been known to run monkey-knife fights in a shady south philly warehouse. Err... I mean... nothing. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 8:33 AM To: [EMAIL PROTECTED] Subject: WhoWeAre I'm going to slip a WhoWeAre page to the documentation later today, listing the contributors and Committers. This would go over the WhoWeAre text that is in the root folder of the distribution. Craig and I have longish bios there. If any other Committers would like to send me theirs, I'll include them in the update. Source Code Contributors Arun M. Thomas Chris Audley Craig R. McClanahan David Geary Don Clasen Florent Carpentier Jeff Hutchison Jimmy Larsson Luis Arias Marius Barduta Mike Schachter Niall Pemberton Ralph Schaer Rob Leland Sean Kelly Ted Husted User Guide Contributors --- Chris Assenza Craig R. McClanahan David Geary dIon Gillard Eric Wu John Rousseau Larry McCay Martin Cooper Matthias Kerkhoff Mike Schachter Robert Hayden Stanley Santiago Ted Husted Wong Kok Kai Active Committers - Craig R. McClanahan ([EMAIL PROTECTED]) David Geary ([EMAIL PROTECTED]) Michael Schachter ([EMAIL PROTECTED]) Ted Husted ([EMAIL PROTECTED]) Rob Leland ([EMAIL PROTECTED]) Vincent Massol ([EMAIL PROTECTED]) Cedric Dumoulin ([EMAIL PROTECTED]) Martin Cooper ([EMAIL PROTECTED]) Emeritus Committers --- + Luis Arias + Pierre Delilse More About Us ... -- Craig and Ted hyperbole / -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
jakarta.apache.org and ssh
I sent this to the jakarta-general list, but I figured I'd send it here too... jakarta.apache.org keeps refusing my password when I ssh to it, anyone else know of this problem? Craig?
RE: Struts 1.0 Release Planning
+1, timing is nothing as long as it's stable -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 5:13 PM To: [EMAIL PROTECTED] Subject: Struts 1.0 Release Planning I *really* wanted to have a 1.0 final release in time for JavaOne. But the recent events on the Apache server (a cracker got in), plus the fact that rebuilding things took Bugzilla down for a while, has made that basically impossible :-(. Instead, what I would like to propose is to cut a Beta 3 release this weekend, and give people a week to pound on it. The target date for a 1.0 final release would be June 15 (a week after JavaOne). Does that sound like a satisfactory plan to everyone? Craig
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
Hal, I'm a little confused, being as I've never seen the components code. First, the request is only wrapped for multipart forms. Second, by the time processForward() is called, it is passed the original request, and not the wrapped one. What am I missing? -Original Message- From: Deadman, Hal [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 5:21 PM To: [EMAIL PROTECTED] Cc: 'Cedric Dumoulin' Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java What's the plan regarding forwarding the orignal request instead of the wrapped request? Form submissions don't work in the current Struts build, at least not on Weblogic 6.0. If ActionServlet is changed to unwrap the request before fowarding, Cedric Dumoulin will need to change his Components code because he has to copy the processForward() method in his class that inherits from ActionServlet. But then his components framework will only work with the latest struts builds Error from weblogic when it tries to dispatch to target using wrapped request: java.lang.ClassCastException: org.apache.struts.upload.MultipartRequestWrapper at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImp l.java:112) at s1.struts.component.ActionComponentServlet.processForward(ActionComponentSer vlet.java:198) at s1.struts.component.ActionComponentServlet.processValidate(ActionComponentSe rvlet.java:158) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1553) at com.tallan.odtos.web.servlet.AppActionServlet.process Hal -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 7:28 PM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java On Fri, 11 May 2001, Martin Cooper wrote: At 03:44 PM 5/11/01, Craig R. McClanahan wrote: On 11 May 2001 [EMAIL PROTECTED] wrote: mschachter01/05/11 15:33:38 Modified:src/share/org/apache/struts/action Action.java ActionServlet.java src/share/org/apache/struts/upload DiskMultipartRequestHandler.java src/share/org/apache/struts/util RequestUtils.java Added: src/share/org/apache/struts/upload MultipartRequestWrapper.java Log: - Added the MultipartRequestWrapper class, which is a class that implements HttpServletRequest and wraps a normal request. All normal HttpServletRequest methods will be called to the underlying request, except for methods involving parameters, which were over-ridden to provide a transparent way of accessing multipart elements. The version of the HttpServletRequest is Servlet 2.2, however the new methods from Servlet 2.3 are also included in this class with empty implementations so that Struts will build against the servlet 2.2 and 2.3 jars One thing to remember in 2.2 is that you cannot pass your wrapped request object to a RequestDispatcher.forward() or RequestDispatcher.include() call. In Tomcat 3.x, for example, you'd get a ClassCastException error if you tried to use this in an RD call. You mean if I have an Action that is invoked via POST with a file upload, and I try to forward from there using mapping.findForward(nextAction), where the forward has redirect=false, this will fail? This would be very bad - in every case where we have a file upload, we subsequently forward to another action. As long as you forward the *original* request object (and not the wrapper), you're fine. I'm fighting some security fires on Tomcat so I haven't had time to look deeply into what Michael is changing, but wanted to raise the flag in case some assumptions about this were being made incorrectly. Craig -- Martin Cooper Craig
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
Martin, You mean if I have an Action that is invoked via POST with a file upload, and I try to forward from there using mapping.findForward(nextAction), where the forward has redirect=false, this will fail? No, right after the ActionForward is returned and right before ActionServlet processes it, I convert the wrapped request back to the original one, to avoid the problem stated in Craigs earlier mails.
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
Hal,
It was my understanding that since isCancelled is a protected method in the
Action class,
that it was the Action developer's job to call the method.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Doesn't the Struts framework need to call this new method somewhere? The
application code can't call the isCancelled method because the Action class
code will never be called. If Struts ActionServlet calls the form validate
when a user clicked cancel, the validation will likely fail and the user
will be presented with the input form again. Clicking cancel needs to bypass
the call to the form validate method. If that is done then the new
isCancelled method may be used in the perform method.
Hal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:11 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action
Action.java ActionForm.java
mschachter01/05/11 10:11:06
Modified:doc todo-1.1.xml
src/share/org/apache/struts/action Action.java
ActionForm.java
Log:
- Add an isCancelled() method to the Action class that takes a
MultipartRequestHandler as an argument. This should address
issues with the html:cancel tag, as long as the new isCancelled
method is called on for multipart forms.
- Add myself to the EJB Design Pattern TODO
Revision ChangesPath
1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
Index: todo-1.1.xml
===
RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- todo-1.1.xml2001/04/12 16:00:42 1.2
+++ todo-1.1.xml2001/05/11 17:10:47 1.3
@@ -159,6 +159,9 @@
assigned
a href=mailto:[EMAIL PROTECTED];Nic Hobbs/a
/assigned
+ assigned
+a href=mailto:[EMAIL PROTECTED];Mike Schachter/a
+ /assigned
/task
task name=HTML No-Cache Support
1.20 +27 -4
jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Action.java 2001/02/23 21:13:09 1.19
+++ Action.java 2001/05/11 17:10:55 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $
- * $Revision: 1.19 $
- * $Date: 2001/02/23 21:13:09 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $
+ * $Revision: 1.20 $
+ * $Date: 2001/05/11 17:10:55 $
*
*
*
@@ -67,6 +67,7 @@
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Locale;
+import java.util.Hashtable;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
@@ -75,6 +76,7 @@
import javax.servlet.http.HttpSession;
import org.apache.struts.taglib.html.Constants;
import org.apache.struts.util.MessageResources;
+import org.apache.struts.upload.MultipartRequestHandler;
/**
@@ -106,7 +108,7 @@
* by this Action.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.19 $ $Date: 2001/02/23 21:13:09 $
+ * @version $Revision: 1.20 $ $Date: 2001/05/11 17:10:55 $
*/
public class Action {
@@ -466,6 +468,27 @@
return
((request.getParameter(Constants.CANCEL_PROPERTY) != null) ||
(request.getParameter(Constants.CANCEL_PROPERTY_X) != null));
+}
+
+/**
+ * Returns codetrue/code if the current multipart
form's cancel button was
+ * pressed. This method will check if the cancel
button generated by
+ * strongCancelTag/strong was pressed by the user in the
+ * current request. If true, validation performed by an
+ * strongActionForm/strong validate() method will have been
+ * skipped by the controller servlet. A
MultipartRequestHandler instance
+ * can be obtained from a multipart form by calling
+ * {@link ActionForm#getMultipartRequestHandler()
ActionForm.getMultipartRequestHandler()}.
+ *
+ * @param request The servlet request we are processing
+ * @see org.apache.struts.taglib.CancelTag
+ * @see
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
Is this an acceptable resolution to this problem for everybody? If so, I'll
go ahead and fix the token problem in the Action class, be creating new
isTokenValid() method that takes an HttpServletRequest and a
MultipartRequestHandler
as arguments, when using it for multipart forms. The other token methods
don't
need to be changed, as they only deal with retrieiving session information.
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:29 PM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Hal,
It was my understanding that since isCancelled is a protected method in the
Action class,
that it was the Action developer's job to call the method.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Doesn't the Struts framework need to call this new method somewhere? The
application code can't call the isCancelled method because the Action class
code will never be called. If Struts ActionServlet calls the form validate
when a user clicked cancel, the validation will likely fail and the user
will be presented with the input form again. Clicking cancel needs to bypass
the call to the form validate method. If that is done then the new
isCancelled method may be used in the perform method.
Hal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:11 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action
Action.java ActionForm.java
mschachter01/05/11 10:11:06
Modified:doc todo-1.1.xml
src/share/org/apache/struts/action Action.java
ActionForm.java
Log:
- Add an isCancelled() method to the Action class that takes a
MultipartRequestHandler as an argument. This should address
issues with the html:cancel tag, as long as the new isCancelled
method is called on for multipart forms.
- Add myself to the EJB Design Pattern TODO
Revision ChangesPath
1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
Index: todo-1.1.xml
===
RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- todo-1.1.xml2001/04/12 16:00:42 1.2
+++ todo-1.1.xml2001/05/11 17:10:47 1.3
@@ -159,6 +159,9 @@
assigned
a href=mailto:[EMAIL PROTECTED];Nic Hobbs/a
/assigned
+ assigned
+a href=mailto:[EMAIL PROTECTED];Mike Schachter/a
+ /assigned
/task
task name=HTML No-Cache Support
1.20 +27 -4
jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Action.java 2001/02/23 21:13:09 1.19
+++ Action.java 2001/05/11 17:10:55 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $
- * $Revision: 1.19 $
- * $Date: 2001/02/23 21:13:09 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $
+ * $Revision: 1.20 $
+ * $Date: 2001/05/11 17:10:55 $
*
*
*
@@ -67,6 +67,7 @@
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Locale;
+import java.util.Hashtable;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
@@ -75,6 +76,7 @@
import javax.servlet.http.HttpSession;
import org.apache.struts.taglib.html.Constants;
import org.apache.struts.util.MessageResources;
+import org.apache.struts.upload.MultipartRequestHandler;
/**
@@ -106,7 +108,7 @@
* by this Action.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.19 $ $Date: 2001/02/23 21:13:09 $
+ * @version $Revision: 1.20 $ $Date: 2001/05/11 17:10:55 $
*/
public class Action {
@@ -466,6 +468,27 @@
return
((request.getParameter(Constants.CANCEL_PROPERTY) != null) ||
(request.getParameter(Constants.CANCEL_PROPERTY_X) != null));
+}
+
+/**
+ * Returns codetrue/code if the current multipart
form's cancel button
RE-2: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
On second thought, I'm going to toy around with putting the request parameters directly into the request from MultipartRequestHandler instead of using MultipartRequestHandler itself to store attributes. If I can get it to work this will solve all the problems without adding any new methods to anything, or changing anything. -Original Message- From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) Sent: Friday, May 11, 2001 2:08 PM To: '[EMAIL PROTECTED]' Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java Is this an acceptable resolution to this problem for everybody? If so, I'll go ahead and fix the token problem in the Action class, be creating new isTokenValid() method that takes an HttpServletRequest and a MultipartRequestHandler as arguments, when using it for multipart forms. The other token methods don't need to be changed, as they only deal with retrieiving session information. -Original Message- From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 1:29 PM To: '[EMAIL PROTECTED]' Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java Hal, It was my understanding that since isCancelled is a protected method in the Action class, that it was the Action developer's job to call the method. -Original Message- From: Deadman, Hal [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 1:24 PM To: [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java Doesn't the Struts framework need to call this new method somewhere? The application code can't call the isCancelled method because the Action class code will never be called. If Struts ActionServlet calls the form validate when a user clicked cancel, the validation will likely fail and the user will be presented with the input form again. Clicking cancel needs to bypass the call to the form validate method. If that is done then the new isCancelled method may be used in the perform method. Hal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 1:11 PM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java mschachter01/05/11 10:11:06 Modified:doc todo-1.1.xml src/share/org/apache/struts/action Action.java ActionForm.java Log: - Add an isCancelled() method to the Action class that takes a MultipartRequestHandler as an argument. This should address issues with the html:cancel tag, as long as the new isCancelled method is called on for multipart forms. - Add myself to the EJB Design Pattern TODO Revision ChangesPath 1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml Index: todo-1.1.xml === RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- todo-1.1.xml2001/04/12 16:00:42 1.2 +++ todo-1.1.xml2001/05/11 17:10:47 1.3 @@ -159,6 +159,9 @@ assigned a href=mailto:[EMAIL PROTECTED];Nic Hobbs/a /assigned + assigned +a href=mailto:[EMAIL PROTECTED];Mike Schachter/a + /assigned /task task name=HTML No-Cache Support 1.20 +27 -4 jakarta-struts/src/share/org/apache/struts/action/Action.java Index: Action.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac tion.java,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- Action.java 2001/02/23 21:13:09 1.19 +++ Action.java 2001/05/11 17:10:55 1.20 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $ - * $Revision: 1.19 $ - * $Date: 2001/02/23 21:13:09 $ + * $Header: /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $ + * $Revision: 1.20 $ + * $Date: 2001/05/11 17:10:55 $ * * * @@ -67,6 +67,7 @@ import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import java.util.Locale; +import java.util.Hashtable; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; @@ -75,6 +76,7 @@ import javax.servlet.http.HttpSession; import org.apache.struts.taglib.html.Constants; import org.apache.struts.util.MessageResources; +import
RE: RE-2: cvs commit: jakarta-struts/src/share/org/apache/struts/acti on Action.java ActionForm.java
What I'm doing is creating a MultipartRequestWrapper class, very similar to
what
HttpServletRequestWrapper does in the Servlet 2.3 API, and setting the
request to
that wrapper instead. That way, I can handle the getParameter() method
calls on the
request myself for multipart requests, and set parameters at will. Once
Struts requires
that Servlet 2.3 is used, I'll extend the HttpServletRequestWrapper instead
of implementing
the HttpServletRequest interface.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 3:39 PM
To: [EMAIL PROTECTED]
Subject: RE: RE-2: cvs commit:
jakarta-struts/src/share/org/apache/struts/acti on Action.java
ActionForm.java
I thought of that too but I don't know how to add parameters to the request.
Maybe you could use request.setAttribute and store the multi-part request
String parameters as attributes in the requet object. Then code that looks
for parameters could be changed to a method that looks for parameters or
attributes. I don't know if that would help matters much.
I use something similar in my application so that I can have an action that
is accessed from a link or from another action. In one case the paramters
are passed on the url and in the other case parameters are passed as request
attributes. The receiving action calls a method that checks for one and then
the other, using the first one it finds.
protected String findStringParameter(HttpServletRequest request, String
key)
{
String value = request.getParameter(key);
if (value == null)
{
value = (String) request.getAttribute(key);
}
return value;
}
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 2:19 PM
To: '[EMAIL PROTECTED]'
Subject: RE-2: cvs commit:
jakarta-struts/src/share/org/apache/struts/acti on Action.java
ActionForm.java
On second thought, I'm going to toy around with putting the request
parameters
directly into the request from MultipartRequestHandler
instead of using
MultipartRequestHandler itself to store attributes. If I can
get it to work
this will solve all
the problems without adding any new methods to anything, or changing
anything.
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
Sent: Friday, May 11, 2001 2:08 PM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Is this an acceptable resolution to this problem for
everybody? If so, I'll
go ahead and fix the token problem in the Action class, be
creating new
isTokenValid() method that takes an HttpServletRequest and a
MultipartRequestHandler
as arguments, when using it for multipart forms. The other
token methods
don't
need to be changed, as they only deal with retrieiving
session information.
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:29 PM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Hal,
It was my understanding that since isCancelled is a protected
method in the
Action class,
that it was the Action developer's job to call the method.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Doesn't the Struts framework need to call this new method
somewhere? The
application code can't call the isCancelled method because
the Action class
code will never be called. If Struts ActionServlet calls the
form validate
when a user clicked cancel, the validation will likely fail
and the user
will be presented with the input form again. Clicking cancel
needs to bypass
the call to the form validate method. If that is done then the new
isCancelled method may be used in the perform method.
Hal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:11 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-struts/src/share/org/apache/struts/action
Action.java ActionForm.java
mschachter01/05/11 10:11:06
Modified:doc todo-1.1.xml
src/share/org/apache/struts/action Action.java
ActionForm.java
Log:
- Add an isCancelled() method to the Action class that takes a
MultipartRequestHandler as an argument. This should address
issues with the html:cancel tag, as long as the new isCancelled
method is called on for multipart forms.
- Add myself to the EJB Design Pattern TODO
Revision ChangesPath
1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
Index: todo-1.1.xml
RE: Need some help.......
Jiten, The Bluestone Struts Trailmap will be updated soon, right now it's a little out of sync with the nightly builds. -Original Message- From: Jiten Mohanty [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 8:50 PM To: [EMAIL PROTECTED] Subject: Need some help... Hi all I am trying to set-up the logon programme which is available on 'bluestone' site(Trail Map-6) and run on weblogic.But i am getting an error which is mentioned below. Parsing of JSP File '/logon.jsp' failed: /logon.jsp(2): Error in using tag library uri='/WEB-INF/struts-form.tld' prefix='form': The Tag class 'org.apache.struts.taglib.html.ImageTag' has no setter method corresponding to TLD declared attribute 'path', (JSP 1.1 spec, 5.4.1) probably occurred due to an error in /logon.jsp line 2: %@ taglib uri=/WEB-INF/struts-form.tld prefix=form % Can somebody help me out. Thanks Jiten Software Engineer ip|SEAL Inc. Colorado
EJB Design Patterns
Is anyone currently working on this? I'd like to help out.
RE: building struts
Rob, That seems like a JAXP problem to me. Make sure you don't have parser.jar in your classpath, and no other application uses jaxp.jar from JAXP 1.0 -Original Message- From: Rob Leland To: [EMAIL PROTECTED] Sent: 2/22/01 3:50 PM Subject: building struts Ok: I am trying to build struts Feb 22 using: ant 1.3-b3, options.jar (1.3 b3); jaxp 1.1 I haven't been sucessfull yet. Which version of ant are you using to build struts. Have you tried gump ? BUILD FAILED java.lang.SecurityException: sealing violation at java.net.URLClassLoader.defineClass(URLClassLoader.java:234) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:117 ) at org.apache.tools.ant.ProjectHelper.getParserFactory(ProjectHelper.java:7 06) at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:105) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:8 5) at org.apache.tools.ant.Main.runBuild(Main.java:403) at org.apache.tools.ant.Main.main(Main.java:149)
RE: [VOTE] Struts 1.0-beta-1 Release Plan
+1 -Original Message- From: Craig R. McClanahan To: [EMAIL PROTECTED] Sent: 2/20/01 1:18 AM Subject: [VOTE] Struts 1.0-beta-1 Release Plan Now that the TODO list for 1.0 (and the bug reports in Bugzilla) are dwindling away, it's time for a 1.0-beta-1 release of Struts! I just checked in an initial draft of a release plan that talks about what will happen, and the criteria for release. Please take a moment to review this document: http://jakarta.apache.org/struts/release-plan-1.0b1.html and vote on your acceptance of this plan. Release plans must pass by a majority vote of committers on the project, but all other interested parties are welcome to cast their votes (and/or make comments or suggestions on the plan) as well. Craig McClanahan
i18n and Resources
Hi, I'm attempting to develop a fuller form of internationalization for Struts, which includes retrieving content from more than something such as a ResourceBundle. The basic idea is that you have a Resource, which is an interface that represents anything that has internationalized content. It has a method that looks basically like this: public byte[] getData(String key, Locale locale, TimeZone timeZone); Of course, time zone is optional, it would depend on the implementation whether or not to use it. You would define these resources in some xml file, like so: resource type="org.apache.struts.i18n.FileSystemResource" name="STATIC_CONTENT" property name="fileBase"/usr/local/content/static/property /resource resource type="org.apache.struts.i18n.DatabaseResource" name="DB_CONTENT" !-- possibly specify a bunch of database related properties such as username and password, or tie it into data sources specified in struts-config.xml. There would also be something specified to where exactly in the data source to pull the content from, this is way up in the air right now -- /resource Then, you would use a taglib inside of your jsp page to retrieve the content: %@ page langauge="java" % %@ taglib uri="/WEB-INF/struts-i18n.tld" prefix="i18n" % h3This is static internationalized content:/h3 i18n:resource key="my.content" name="STATIC_CONTENT" / h3This is internationalized content pulled from a database:/h3 i18n:resource key="my.article" name="DB_CONTENT" / Taking this further, you could create a resource implementation that plugs into some kind of commercial content managment system, and so on. Is there any interest in something like this? I'm currently in the process of developing this idea, and I'd like as much input as possible, not only with this, but with internationalization in general. I attached the Resources class, just to illustrate a bit. Resource.java Resource.java
RE: File uploads (including patches)
Jimmy, Thanks for the patches, I'll spend today fixing file uploads up using your code. -Original Message- From: Jimmy Larsson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 14, 2001 3:52 AM To: [EMAIL PROTECTED] Subject: File uploads (including "patches") Hi all! I think struts is a wonderful thing and I have been using it for the last few weeks. I very pleased with it, except for the file uploading parts. In our application we've been using file uploads via forms which we have implemented our selves, but now we want to move to struts and then we need the uploads working. These are the issues I've found with the uploading: 1. If you upload a file with a content-type (extension) that the browser does not know, the first "line" of the file gets truncated. 2. When decoding the multipart request the whole file is stored in memory as an byte array. You cant have this since users uploding files can fill up your memory. 3. When reading files in your action you can only read the files as a bytearray in memory. You cant have this for the same reason as in 2, also file-io in Java is intended to use streams. I've attached sources for the upload package that fix these issues. Because I didn't want to break compability with things using the reading of byte-arrays, I have not removed the "getFileData()" method from the FormFile interface. I think this really should be done to prevent users from using this dangerous method. If it's ok with you guys I could put some more time into the code and remove this method, there is also some cleaning up which I have not done. /Regards, Jimmy Larsson __ Jimmy Larsson, Lecando AB, http://www.lecando.com e-mail: [EMAIL PROTECTED] Tel: +46 (0)8 - 634 94 00, +46 (0)70 - 462 19 11
RE: Breaking Interface (was:Re: cvs commit: jakarta-struts/web/upload/WEB-INF/classes/org/apache/struts/example/upload UploadAction.java)
I'd rather not "not break it", as it's an important change. On average,
I'm usually pretty concerned about not breaking backwards compatibility.
But this is only for people who have their own implementation of
org.apache.struts.upload.FormFile, which I would assume are few and far
between. It's also a very small change to someone's implementation to
support this.
I'll change it (probably by putting the method just in the implementation
and making people cast their FormFile instances into DiskFile's to use it)
if there is anybody out there that requests it.
-Original Message-
From: Rob Leland
To: [EMAIL PROTECTED]
Sent: 2/14/01 5:00 PM
Subject: Breaking Interface (was:Re: cvs commit:
jakarta-struts/web/upload/WEB-INF/classes/org/apache/struts/example/upload
UploadAction.java)
This commit will break any code that implements the
org.apache.struts.upload.FormFile interface, because a new method was
added.
Is there a way to not break this for people ?
One of the things Struts/Craig has always stressed
is good backward compatability ?
[EMAIL PROTECTED] wrote:
mschachter01/02/14 13:43:10
Modified:src/share/org/apache/struts/upload DiskFile.java
DiskMultipartRequestHandler.java FormFile.java
MultipartElement.java MultipartIterator.java
web/upload/WEB-INF/classes/org/apache/struts/example/upload
UploadAction.java
Added: src/share/org/apache/struts/upload
MultipartValueStream.java
Log:
Made changes to classes in upload package to address problems with
storing
files in memory. This commit will break any code that implements
the
org.apache.struts.upload.FormFile interface, because a new method
was
added. Changed MultipartIterator to use the new MultipartValueStream
class
from Jimmy Larsson for
going through multipart elements. This will fix a bug with null
content types
for files. Also updated the upload example to use the new
recommended method
for retrieving file content.
Submitted By: Jimmy Larsson
Revision ChangesPath
1.2 +14 -5
jakarta-struts/src/share/org/apache/struts/upload/DiskFile.java
Index: DiskFile.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/DiskFile.jav
a,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DiskFile.java 2000/11/09 20:08:56 1.1
+++ DiskFile.java 2001/02/14 21:43:05 1.2
@@ -1,6 +1,7 @@
package org.apache.struts.upload;
import java.io.File;
+import java.io.InputStream;
import java.io.IOException;
import java.io.FileInputStream;
import java.io.ByteArrayOutputStream;
@@ -26,10 +27,8 @@
/**
* The name of the file
*/
-protected String fileName;
+protected String fileName;
-
-
public DiskFile(String filePath) {
this.filePath = filePath;
}
@@ -39,6 +38,9 @@
* array form. Tries to read the entire file (using a byte
array
* the size of getFileSize()) at once, in one call to
FileInputStream.read(byte[]).
* For buffered reading, see {@link #getFileData(int)
getFileData(int)}.
+ * Note that this method can be dangerous, and that the size of
a file
+ * can cause an OutOfMemoryError quite easily. You should use
+ * {@link #getInputStream() getInputStream} and do your own
thing.
*
* @exception ServletException If the temp file no longer
exists, or if there is
*some sort of IOException
@@ -56,6 +58,9 @@
/**
* Attempts to read a file n bytes at a time, n being equal to
"bufferSize".
+ * Note that this method can be dangerous, and that the size of
a file
+ * can cause an OutOfMemoryError quite easily. You should use
+ * {@link #getInputStream() getInputStream} and do your own
thing.
*
* @param bufferSize The size in bytes that are read from the
file at a time
* @exception FileNotFoundException If the temp file no longer
exists
@@ -150,7 +155,11 @@
public int getFileSize() {
return fileSize;
}
-
-
+/**
+ * Returns a FileInputStream to the file
+ */
+public InputStream getInputStream() throws
FileNotFoundException, IOException {
+return new FileInputStream(filePath);
+}
}
1.7 +55 -97
jakarta-struts/src/share/org/apache/struts/upload/DiskMultipartRequestHa
ndler.java
Index: DiskMultipartRequestHandler.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/DiskMultipar
tRequestHandler.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
---
RE: Xalan Prerequisite for Build from Source
JAXP 1.1 comes with xalan 2.0 as a reference implementation for TraX, the set of JAXP interfaces for doing XSLT transformations. Being as this is an important addition, and the XSL functionality I'd like to add to Struts for 1.1 is based on it, I'd hope that Struts 1.1 won't be based on JAXP 1.0 -Original Message- From: Dan Connelly To: [EMAIL PROTECTED] Sent: 2/8/01 10:25 AM Subject: Xalan Prerequisite for Build from Source Its a bit of a gotcha here on the Struts installation page, concerning the prerequisites for building from the (latest) source distribution: * Xalan XSLT Processor - If you are building Struts from the source distribution, you must download and install version 1_2_D01 (or later) of the Xalan http://xml.apache.org/xalan XSLT processor (which also includes the Xerces XML parser). This processor is used to convert the Struts documentation from its internal XML-based format into the HTML that is presented in the Struts documentation application.[My red.] So, OK. Xalan version_1_2_D02 does work, and it is later than version_1_2_D01. But Xalan version_2_0_D07 does not work. I guess I was a bit foolish assuming that Xalan-Java 2.x is a later release of Xalan-Java 1.x. Yes, major number Revs are allowed to break backwards compatibility, so its entirely new and not strictly a later release of Xalan. But, it looks like Xalan-Java 1.x is now EOLed. All the action is on Xalan-Java 2.x. So having a dependency on an orphaned release is not too cool. I take it that the dependencies here are Struts = Ant (optional.jar) = Xalan. Which means (roughly) that if Ant (optional.jar) gets upgraded, then the Struts build.xml may need to be upgraded (??). At that point, the developers building Struts from source may need to upgrade both Ant and Xalan.Could this impact us as early as Struts 1.1, or can we just continue to use Ant 1.2 and Xalan-Java 1.x forever ?? Just asking.
