[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-8961: -------------------------------------------- Changed the description since this is not just limited to deploy only server. Rob - this issue keeps popping up - and it makes us and users fail constantly. We should detect/warn against this or consider falling back to do a raw copy + warning if this is failing. Then it will be slower, but at least work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Andre Dietisheim commented on JBIDE-8961: ----------------------------------------- the concerned code is here: PublishCopyUtil#LocalCopyCallback#moveTempFile btw. why is this class called LocalCopyCallback (this is no callback in any way, this is a delegate)? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-8961 at 5/28/11 6:43 AM: ------------------------------------------------------------------ the concerned code is here: PublishCopyUtil#LocalCopyCallback#moveTempFile btw. why is this class called LocalCopyCallback (this is no callback in any way, this is a delegate)? Calling the outer class *Util but not providing static methods but instance methods makes it hard to understand its purpose. was (Author: adietish): the concerned code is here: PublishCopyUtil#LocalCopyCallback#moveTempFile btw. why is this class called LocalCopyCallback (this is no callback in any way, this is a delegate)? Furthermore having a util class that gets instantiated is odd and makes it hard to understand the code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-8961 at 5/29/11 8:43 AM: ------------------------------------------------------------------ the concerned code is here: PublishCopyUtil#LocalCopyCallback#moveTempFile btw. why is this class called LocalCopyCallback (this is no callback in any way, this is a delegate)? Calling the outer class *Util but providing a stateful class and not a stateless collection for static methods makes it hard to understand its purpose. was (Author: adietish): the concerned code is here: PublishCopyUtil#LocalCopyCallback#moveTempFile btw. why is this class called LocalCopyCallback (this is no callback in any way, this is a delegate)? Calling the outer class *Util but not providing static methods but instance methods makes it hard to understand its purpose. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Rob Stryker commented on JBIDE-8961: ------------------------------------ First, is this replicatable under any JBoss server, or only under deploy-only server? From what I can tell, this is only replicatable under deploy-only server. The only time this is replicated for regular servers is when the user SPECIFICALLY changes the temp deploy folder to a value on another OS. In all cases, whether it be metadata or server-relative, the deploy and temp-deploy folders for regular JBoss servers *ARE* on the same filesystem. The only time this is not the case is when users select "Custom" for the location, and then specifically put the deploy folder and temp deploy folder on separate OS's, in which case it is a USER error. Unfortunately there is no java API that I am aware of to discover if two paths are on the same filesystem. Detecting a renameTo failure and changing the behaviour is almost 100% out of the question. It would render the entire concept of the temporary deploy folder irrelevant, thus confusing users. Also it would require huge changes in logic that could potentially break large portions of functionality. I'd appreciate it if issues with class names, method names, or workflow, be given their own bugs, and to not intermingle the issues, as that makes solving the problem very confusing. It also makes it difficult to know when the issue should be closed, if 10 different comments bring up 10 only slightly related issues. So let's try to keep the chatter to a minimum, and put non-intuitive class names and method names, etc, in their own issues. So, I'd love to hear *concrete* suggestions on this issue. I consider this a configuration error. Whether it is the user's fault or our fault is yet to be determined, but, in all cases, I do not agree with falling back to any other behavior. If the situation is broken, we error and the user fixes it. Upon creation of a new temporary deploy-only server, and typing in a deploy-folder location such as "/opt/jboss", the server's default temporary-deploy location is, in fact, still "/home/rob/apps/eclipse/workspaces/runtime-New_configuration2/.metadata/.plugins/org.jboss.ide.eclipse.as.core/Deploy_Only/tempDeploy". In the user's issue, the failing temporary folder seems to be "/home/fbricon/Dev/test/temp", which indicates the user MANUALLY changed the temporary location from a metadata location to his home directory. This is the very definition of user-error. Sanity check on deploy-only server creation seems most logical with the least impact on the security and workflow of the codebase. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Andre Dietisheim commented on JBIDE-8961: ----------------------------------------- my comments were clearly marked as "btw". We all know that the code needs major overhaul and putting all those "issues" to separate issues would just be a killer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Rob Stryker updated JBIDE-8961: ------------------------------- Attachment: JBIDE-8961.png Made a commit to fix the usecase as described by fred. Other similar use cases are still being investigated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Rob Stryker commented on JBIDE-8961: ------------------------------------ So you want an error marker added *in addition* to the rename error that pops up? Isn't that a bit too much? Ideally an error marker would not go on a project, as that's kinda nonsensical... There's nothing wrong with the project, but with the server. Also, not every IModule is guaranteed an IResource (some may represent out of workspace entities), etc. But markers can only go on IResource objects, and an IServer is not an IResource, nor does it necessarily have an IResource backing it. I made another adjustment to the actual error status object, so now the dialog that pops up with the error says the following: PublishRenameFailure=Error renaming {0} to {1}. \n\nThis may be caused by your server's temporary deploy directory being on a different filesystem than the final destination.\n\nYou may adjust these settings in the server editor. Also, lets not forget this error ALSO will appear in the server log view, and, furthermore, it will appear in the error log if the user's settings designate it to. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-8961: -------------------------------------------- Didn't get that it was showing up in a dialog since until now errors just got hidden - so that's great. way better than before. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8961?page=com.atlassian.jira.plugin... ] Martin Malina closed JBIDE-8961. -------------------------------- Verified both scenarios (deploy-only server creation and the error message in the case of JBoss AS) in JBT 3.3.0.M2 (jbosstools-3.3_stable_branch.aggregate-Update-2011-06-24_07-36-50-H7.zip). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira