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) AbstractFileObject ctor accepts FileName as a parameter, but actually requires AbstractFileName
Date Sat, 27 Nov 2010 09:32:13 GMT

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


Mime
View raw message