[jboss-user] [JBoss Tools] - Re: error in hot deployement 'Error renaming..'

[Rob Stryker]

Rob Stryker [http://community.jboss.org/people/rob.stryker%40jboss.com] created the discussion

"Re: error in hot deployement 'Error renaming..'"

To view the discussion, visit: http://community.jboss.org/message/573404#573404

--------------------------------------------------------------
It seems as if you're using a mix of maven commands and wtp publishing. When you click the 'publish' icon inside the servers view, this will do what is called an "Incremental Publish". This means it will only publish whatever files have changed in the workspace since the last publish event. If you right-click on your module in the servers view, however, you can click "FULL PUBLISH" to republish the entire module.

So, if you do a full publish, you wil note all resources should now be synchronized and all files should have been deployed. All files should have a timestamp of t at that point. If you then wait 1 minute, modify a java file, save it, and use the publish icon or incremental publish buttons, you will note in the deploy folder that *ONLY* your .class file has changed its timestamp, and all other resources have the previous timestamp.

If you then go to the deploy folder and delete all files for this deployment, return to your eclipse workspace, modify a file or two, and click publish again (incremental), you will see that *only* the two changed files have been published. This is in fact a user-error. If the user manually deletes a publish folder and its contents outside of eclipse, there is no way for the tooling to know or expect this. This includes if the user uses some other tool such as maven which may have deleted the module's deploy folder as well. In these cases, the tooling will again try to simply do an incremental publish of only the changed files.

I'll need to look into your first problem, with the error renaming, but it seems like either there was a file lock (which would be a jboss-as problem) or the destination folder did not exist. I really don't think the folder not existing is a problem, however, because for our local copy handler, we have the following code:

     if (!safeRename(tempFile, file, 10))

with safeRename doing the following:
         File dir = to.getParentFile();
         if (dir != null && !dir.exists())
                dir.mkdirs();

So if this *is* the problem, that hte folder does not exist, it is a problem with your filesystems permissions, such that jbosstools cannot create these directories without the OS complaining. If that's the case, there doesn't seem to be much I can do. The javadoc for java.io.File.mkdirs() is the following:

/**
     * Creates the directory named by this abstract pathname, including any
     * necessary but nonexistent parent directories.  Note that if this
     * operation fails it may have succeeded in creating some of the necessary
     * parent directories.
     *
     * @return  <code>true</code> if and only if the directory was created,
     *          along with all necessary parent directories; <code>false</code>
     *          otherwise

The best I can do here is capture the return value and try to return a slightly more relevant error message, but really the java.io.File api does not tell me WHY the mkdirs failed, or why the renameTo failed... so really there's nothing I can change the error message to to make it more clear than it already is. All *I* can know is that the rename / mkdirs failed... but the API does not allow me to know why.

Hopefully the first half of this post gives you some hint as to what is going on in your current situation, but for the mkdirs / renameto error, there's not much more I can do aside from ask you to look into permissions in the folders.
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/573404#573404]

Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2128]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20101129/e832bb30/attachment.html