commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (VFS-337) AbstractFileName ctor accepts FileName as a parameter, but actually requires AbstractFileName
Date Thu, 25 Nov 2010 20:01:35 GMT

     [ 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.


Mime
View raw message