Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 18 Jan 2015 20:19:34 +0000 (UTC)
From: "L (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12768312.1421597549000.112506.1421612374504@Atlassian.JIRA>
In-Reply-To: <JIRA.12768312.1421597549000@Atlassian.JIRA>
References: <JIRA.12768312.1421597549000@Atlassian.JIRA>
 <JIRA.12768312.1421597549690@arcas>
Subject: [jira] [Comment Edited] (VFS-558)
 java.lang.UnsupportedOperationException in FtpFileObject
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

L edited comment on VFS-558 at 1/18/15 8:18 PM:
------------------------------------------------

Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow.

Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject.
My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it.
My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there.
Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get false positives.


was (Author: klv_m72):
Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow.

Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject.
My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it.
My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there.
Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive 

> java.lang.UnsupportedOperationException in FtpFileObject
> --------------------------------------------------------
>
>                 Key: VFS-558
>                 URL: https://issues.apache.org/jira/browse/VFS-558
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: L
>
> I am getting the following exception in my code:
> java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345)
> 	at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271)
> 	at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240)
> 	at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931)
> 	at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577)
> 	at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866)
> 	at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241)
> 	at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184)
> ...
> I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked.
> I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem:
> FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType());
> Must it not be destFile.getType()?
> But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)