> I've opened an issue for it
http://issues.apache.org/jira/browse/WICKET-730
Getting back to the original issue ...
As I understand it, the complaint comes from this behavior:
* Close the streams which has been opened when getting the InputStream
* using [EMAIL PROTECTED] #getInputStream()}
Good. Makes the review easier ;-), and you've only the one to remove.
I've opened an issue for it http://issues.apache.org/jira/browse/WICKET-730
Eelco
Eelco Hillenius wrote:
> > Not only should you not need to add a finalizer, but most importantly,
> > review your codebase and *remove* all finalizers.
> It's the only one in there.
Good. Makes the review easier ;-), and you've only the one to remove.
--- Noel
Not only should you not need to add a finalizer, but most importantly,
review your codebase and *remove* all finalizers.
It's the only one in there.
Eelco
Eelco Hillenius wrote:
> Johan Compagner wrote:
> > and if i remember correctly, back then it looked if the FileUpload
project
> > was really in suspend stage.
> > there wasn't much happening on it, so i am talking abou the time we
added it
> > to the core of wicket
> Yeah, that's one of the reas
> Anyway, Al, what's your take on this?
Do I have to have one? ;-)
I've fixed the bug I was having, haven't had time to compare the two
divergent branches since, sorry.
I meant Noel's remarks, specifically:
"So you do have an old version of the FileCleaner, albeit prior to
enhancements that h
Eelco Hillenius wrote:
On 7/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
and if i remember correctly, back then it looked if the FileUpload
project
was really in suspend stage.
there wasn't much happening on it, so i am talking abou the time we
added it
to the core of wicket
Yeah, that'
On 7/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
and if i remember correctly, back then it looked if the FileUpload project
was really in suspend stage.
there wasn't much happening on it, so i am talking abou the time we added it
to the core of wicket
Yeah, that's one of the reasons why we
and if i remember correctly, back then it looked if the FileUpload project
was really in suspend stage.
there wasn't much happening on it, so i am talking abou the time we added it
to the core of wicket
johan
On 7/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> I understand "we just took wh
I understand "we just took what little pieces we needed instead of adding a
dependency on the entire thing", but what is meant by "the code grew in a
different direction due to various reasons"?
We started using commons-io as just a dependency, but after a while we
needed some tweaks to better l
]
Sent: Thursday, July 05, 2007 12:58
To: wicket-dev@incubator.apache.org
Subject: Re: FileUploadField closing input streams behind my back
> For that matter, why aren't you using Commons? The very problem (file
> uploading) you are dickering with is precisely one that we addressed in
For that matter, why aren't you using Commons? The very problem (file
uploading) you are dickering with is precisely one that we addressed in
Commons years ago. The core code is in Commons I/O:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/ap
ache/commons/io/
We ha
On 7/5/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
a/org/apache/commons/fileupload/
Sorry if this comes across as being snarky, but rewriting the wheel is bad
enough; getting it wrong is worse.
--- Noel
actually if you take a look you will see that our upload code does come fro
> Do we really need to go around and aggressively clean up these
> InputStreams? Can't we do that in a finalize() method somewhere?
NO!! NEVER use finalize(), especially not server-side.
If you need to automatically cleanup resources when they are unused, without
having to call explicit clea
Igor Vaynberg wrote:
On 7/4/07, Al Maw <[EMAIL PROTECTED]> wrote:
Do we really need to go around and aggressively clean up these
InputStreams? Can't we do that in a finalize() method somewhere?
yes we do, because users dont do it themselves :) we can also add something
like
protected boolea
On 7/4/07, Al Maw <[EMAIL PROTECTED]> wrote:
Do we really need to go around and aggressively clean up these
InputStreams? Can't we do that in a finalize() method somewhere?
yes we do, because users dont do it themselves :) we can also add something
like
protected boolean closeStreamOnDetach(
16 matches
Mail list logo
