wicket-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Long (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WICKET-4600) Remove IResourceStream.close()
Date Mon, 18 Jun 2012 10:57:42 GMT

    [ https://issues.apache.org/jira/browse/WICKET-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13395808#comment-13395808
] 

Jesse Long commented on WICKET-4600:
------------------------------------

Also, if IResourceStream.close() releases resources created with the IResourceStream, then
IResourceStream object are not re-usable - after the first close() call, they will no longer
hold the information required to use them correctly.
                
> Remove IResourceStream.close()
> ------------------------------
>
>                 Key: WICKET-4600
>                 URL: https://issues.apache.org/jira/browse/WICKET-4600
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 6.0.0-beta2
>            Reporter: Jesse Long
>
> The IResourceStream.close() method is designed to allow the IResourceStream implementations
to destroy data over and above the InputStream.
> If it was just the InputStream, we would not need the method, we could just call close()
on the InputStream.
> The problem is, almost none of the wicket code correctly calls IResourceStream.close().
Often, IResourceStream.getInputStream() is called, often the InputStream is then closed, but
IResourceStream.close() is not called.
> Also, it is not clear at which point IResourceStream.close() needs to be called. Possibly
only after an InputStream is created, in which case, why does InputStream.close() not suffice?
Otherwise, we should call IResourceStream.close() every time we use it - this very certainly
does not happen.
> I propose to remove this method to save wicket the effort. I really doubt there is much
real need to clean anything up in the close() method. IResourceStream implementation should
retain enough information  to create an InputStream, and create an InputStream method in the
getInputStream() method, and close any no-longer needed resources in the getInputStream()
method. Consumers of the IResourceStream can just close the InputStream and be done with it.
> Here is some discussion about some of the dodgey uses of IResourceStream.close in wicket
ATM:
> AbstractMarkupParser calls IResourceInputStream.getInputStream(), but never calls IResourceStream.close().
> ContextRelativeResource call IResourceStream.getInputStream(), but never calls IResourceStream.close().
> ResourceStreamResource calls close() on the IResourceResponse returned from internalGetResourceStream().
However, it is possible that a new IResourceStream is dynamically created each time internalGetResourceStream
is called, in which case ResourceStreamResponse closes the incorrect IResourceStream. Live
would be easier if it only had to close the InputStream.
> MessageDigestResourceVersion calls IResourceStream.getInputStream(), but never calls
IResourceStream.close().
> ConcatBundleResource calls IResourceStream.getInputStream(), but never calls IResourceStream.close().
(ConcatBundleResource also does stupid things with ByteArrayInputStream btw).
> XSLTResourceStream calls (in its constructor) IResourceStream.getInputStream() but never
calls IResourceStream.close(). XSLTResourceStream and its ZipDirectoryResourceStream friend
really want to be deleted.
> Also, there are many many usages of IResourceStream where close() is not called, but
getInputStream() is not called either.
> Wont mind working on a patch, after some direction from wicket devs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message