commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jochen Wiedmann" <jochen.wiedm...@gmail.com>
Subject Re: [fileupload] RFC: Fileupload 1.3 or 2.0?
Date Tue, 03 Jul 2007 20:17:01 GMT
On 7/3/07, Stephen Colebourne <scolebourne@btopenworld.com> wrote:

> I've read the JIRA's and I don't understand why FileItem/Serializable is
> relevant. As such I'm struggling to understand this thread :-)

It's a design problem. When the DiskFileItem is instantiated, the File
isn't necessarily created yet. In other words, the DiskFileItem needs
an internal reference to the FileCleaningTracker, which is
unfortunately not Serializable. We could continue with ideas like
making the FileCleaningTracker transient, but that would violate the
contract that the library takes care of removing the temporary files.


> If there is a minor incompatible change, like making FileItem no longer
> implement Serializable, then IMO that can be a v2.0 with the same
> package name. (Minor means that it has no effect on the vast majority of
> users. In addition, deprecated methods and classes can be removed.
>
> If there are larger changes that involve design changes, especially
> changes to user code (backwards imcompatible) then that should be a v2.0
> with a different package name.
>
> If you choose the latter option, I would personally prefer to see
> [fileupload] move to Java 1.5 at the same time.

I think, what I intend would be closer to the first scenario. However,
I am open for a package name change. I am also open for a move to Java
1.5 sources, because my experiences with retrotranslator are good.


Jochen

-- 
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message