You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sebb (JIRA)" <ji...@apache.org> on 2011/02/22 02:58:38 UTC
[jira] Created: (NET-359) CopyStreamAdapter unconditionally resets
the CopyStreamEvent source and is inefficient
CopyStreamAdapter unconditionally resets the CopyStreamEvent source and is inefficient
--------------------------------------------------------------------------------------
Key: NET-359
URL: https://issues.apache.org/jira/browse/NET-359
Project: Commons Net
Issue Type: Bug
Reporter: Sebb
The CopyStreamAdapter.bytesTransferred(CopyStreamEvent event) method unpacks the event in order to pass the parameters to bytesTransferred(long, int, long) method which creates a new event and propagates it to the listeners.
This means that the original event source is lost, and there is an unnecessary event creation.
It seems wrong for the bytesTransferred(long, int, long) method to create a CopyStreamEvent - the interface Javadoc specifically says that the bytesTransferred(long, int, long) method was added to avoid the need to create the event.
It would make more sense if the adapter handled the methods independently, i.e. if the caller provides an event, pass that on, otherwise pass on the individual parameters to the listeners.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-359) CopyStreamAdapter unconditionally resets
the CopyStreamEvent source and is inefficient
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb resolved NET-359.
----------------------
Resolution: Fixed
> CopyStreamAdapter unconditionally resets the CopyStreamEvent source and is inefficient
> --------------------------------------------------------------------------------------
>
> Key: NET-359
> URL: https://issues.apache.org/jira/browse/NET-359
> Project: Commons Net
> Issue Type: Bug
> Reporter: Sebb
>
> The CopyStreamAdapter.bytesTransferred(CopyStreamEvent event) method unpacks the event in order to pass the parameters to bytesTransferred(long, int, long) method which creates a new event and propagates it to the listeners.
> This means that the original event source is lost, and there is an unnecessary event creation.
> It seems wrong for the bytesTransferred(long, int, long) method to create a CopyStreamEvent - the interface Javadoc specifically says that the bytesTransferred(long, int, long) method was added to avoid the need to create the event.
> It would make more sense if the adapter handled the methods independently, i.e. if the caller provides an event, pass that on, otherwise pass on the individual parameters to the listeners.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-359) CopyStreamAdapter unconditionally resets
the CopyStreamEvent source and is inefficient
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb updated NET-359:
---------------------
Fix Version/s: 3.0
> CopyStreamAdapter unconditionally resets the CopyStreamEvent source and is inefficient
> --------------------------------------------------------------------------------------
>
> Key: NET-359
> URL: https://issues.apache.org/jira/browse/NET-359
> Project: Commons Net
> Issue Type: Bug
> Reporter: Sebb
> Fix For: 3.0
>
>
> The CopyStreamAdapter.bytesTransferred(CopyStreamEvent event) method unpacks the event in order to pass the parameters to bytesTransferred(long, int, long) method which creates a new event and propagates it to the listeners.
> This means that the original event source is lost, and there is an unnecessary event creation.
> It seems wrong for the bytesTransferred(long, int, long) method to create a CopyStreamEvent - the interface Javadoc specifically says that the bytesTransferred(long, int, long) method was added to avoid the need to create the event.
> It would make more sense if the adapter handled the methods independently, i.e. if the caller provides an event, pass that on, otherwise pass on the individual parameters to the listeners.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira