[
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.
Improve the handling of temporary deploy dir
--------------------------------------------
Key: JBIDE-8961
URL:
https://issues.jboss.org/browse/JBIDE-8961
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS
Affects Versions: 3.3.0.M1
Environment: eclipse.buildId=M20110210-1200
java.version=1.6.0_24
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=fr_FR
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product
org.eclipse.epp.package.jee.product
Reporter: Fred Bricon
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.M2
On linux, having an web project under /home/<username>/workspace/webproject, you
can not deploy it to /opt/deployfolder (assuming the rights are corrects), since, during
the publish operation, the as plugin tries to rename a temporary file from one filesystem
to another.
{noformat}
Publishing failed
Error renaming /home/fbricon/Dev/test/temp/tmp1839894723052933744.MF to
/opt/deploy/web.war/META-INF/MANIFEST.MF
Error renaming /home/fbricon/Dev/test/temp/tmp6164338251434277972.jar to
/opt/deploy/web.war/WEB-INF/lib/utility.jar
{noformat}
The workaround is to define a temp folder on the same fs as the final deploy directory.
However, the average user will have no clue about how to fix it. There should be a sanity
check upon Deploy Only server creation and/or error displayed on the server configuration,
if deployment would fail upon invalid configuration. Providing a Quick fix might be
useful, or not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira