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 2010/11/10 19:31:13 UTC
[jira] Created: (VFS-337) AbstractFileName ctor accepts FileName as
a parameter, but actually requires AbstractFileName
AbstractFileName ctor accepts FileName as a parameter, but actually requires AbstractFileName
---------------------------------------------------------------------------------------------
Key: VFS-337
URL: https://issues.apache.org/jira/browse/VFS-337
Project: Commons VFS
Issue Type: Bug
Affects Versions: 1.0
Reporter: Sebb
The AbstractFileName constructor accepts FileName as a parameter, but actually requires an AbstractFileName.
Anything else will generate a ClassCastException.
The reason for the cast is to allow access to the package-protected method void AbstractFileName#setType(FileType type)
Many of the AbstractFileName methods rely on being able to invoke the setType method, so perhaps the parameter should be changed accordingly?
This will change the API and require changes to subclasses.
I'll add Javadoc to document the restriction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (VFS-337) AbstractFileObject ctor accepts FileName
as a parameter, but actually requires AbstractFileName
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb updated VFS-337:
---------------------
Description:
The AbstractFileObject constructor accepts FileName as a parameter, but actually requires an AbstractFileName.
Anything else will generate a ClassCastException.
The reason for the cast is to allow access to the package-protected method void AbstractFileName#setType(FileType type)
Many of the AbstractFileObject methods rely on being able to invoke the setType method, so perhaps the parameter should be changed accordingly?
This will change the API and require changes to subclasses.
I'll add Javadoc to document the restriction.
was:
The AbstractFileName constructor accepts FileName as a parameter, but actually requires an AbstractFileName.
Anything else will generate a ClassCastException.
The reason for the cast is to allow access to the package-protected method void AbstractFileName#setType(FileType type)
Many of the AbstractFileName methods rely on being able to invoke the setType method, so perhaps the parameter should be changed accordingly?
This will change the API and require changes to subclasses.
I'll add Javadoc to document the restriction.
Summary: AbstractFileObject ctor accepts FileName as a parameter, but actually requires AbstractFileName (was: AbstractFileName ctor accepts FileName as a parameter, but actually requires AbstractFileName)
> AbstractFileObject ctor accepts FileName as a parameter, but actually requires AbstractFileName
> -----------------------------------------------------------------------------------------------
>
> Key: VFS-337
> URL: https://issues.apache.org/jira/browse/VFS-337
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Sebb
>
> The AbstractFileObject constructor accepts FileName as a parameter, but actually requires an AbstractFileName.
> Anything else will generate a ClassCastException.
> The reason for the cast is to allow access to the package-protected method void AbstractFileName#setType(FileType type)
> Many of the AbstractFileObject methods rely on being able to invoke the setType method, so perhaps the parameter should be changed accordingly?
> This will change the API and require changes to subclasses.
> I'll add Javadoc to document the restriction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (VFS-337) AbstractFileName ctor accepts FileName
as a parameter, but actually requires AbstractFileName
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb reopened VFS-337:
----------------------
Sorry, don't know what happened there - you're right, wrong class. Reopening with new details
> AbstractFileName ctor accepts FileName as a parameter, but actually requires AbstractFileName
> ---------------------------------------------------------------------------------------------
>
> Key: VFS-337
> URL: https://issues.apache.org/jira/browse/VFS-337
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Sebb
>
> The AbstractFileName constructor accepts FileName as a parameter, but actually requires an AbstractFileName.
> Anything else will generate a ClassCastException.
> The reason for the cast is to allow access to the package-protected method void AbstractFileName#setType(FileType type)
> Many of the AbstractFileName methods rely on being able to invoke the setType method, so perhaps the parameter should be changed accordingly?
> This will change the API and require changes to subclasses.
> I'll add Javadoc to document the restriction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-337) AbstractFileObject ctor accepts FileName
as a parameter, but actually requires AbstractFileName
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ralph Goers resolved VFS-337.
-----------------------------
Resolution: Fixed
Fix Version/s: 2.0
AbstractFileObject and classes that extend it now take an AbstractFileName instead of a FileName. This also applies to the FileSystem and FileProvider.
> AbstractFileObject ctor accepts FileName as a parameter, but actually requires AbstractFileName
> -----------------------------------------------------------------------------------------------
>
> Key: VFS-337
> URL: https://issues.apache.org/jira/browse/VFS-337
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Sebb
> Fix For: 2.0
>
>
> The AbstractFileObject constructor accepts FileName as a parameter, but actually requires an AbstractFileName.
> Anything else will generate a ClassCastException.
> The reason for the cast is to allow access to the package-protected method void AbstractFileName#setType(FileType type)
> Many of the AbstractFileObject methods rely on being able to invoke the setType method, so perhaps the parameter should be changed accordingly?
> This will change the API and require changes to subclasses.
> I'll add Javadoc to document the restriction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-337) AbstractFileName ctor accepts FileName
as a parameter, but actually requires AbstractFileName
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ralph Goers resolved VFS-337.
-----------------------------
Resolution: Invalid
I suspect this issue was meant to refer to AbstractFileObject instead of AbstractFileName. AbstractFileName does not accept a FileName in the constructor while AbstractFileObject does. setType in AbstractFileName is only called from one place - setFiletype in AbstractFileObject while setFileType and injectType are called from many places.
> AbstractFileName ctor accepts FileName as a parameter, but actually requires AbstractFileName
> ---------------------------------------------------------------------------------------------
>
> Key: VFS-337
> URL: https://issues.apache.org/jira/browse/VFS-337
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Sebb
>
> The AbstractFileName constructor accepts FileName as a parameter, but actually requires an AbstractFileName.
> Anything else will generate a ClassCastException.
> The reason for the cast is to allow access to the package-protected method void AbstractFileName#setType(FileType type)
> Many of the AbstractFileName methods rely on being able to invoke the setType method, so perhaps the parameter should be changed accordingly?
> This will change the API and require changes to subclasses.
> I'll add Javadoc to document the restriction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.