[jbosstools-issues] [JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically

[Darryl Miles (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026902#comment-13026902 ] 

Darryl Miles edited comment on JBIDE-18862 at 12/10/14 6:59 PM:
----------------------------------------------------------------

To go back to Rob's race concern:

> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish

Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.

Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.

{{pre}}
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
   Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
   while test -f $FILENAME && $loop < 10
   do
      sleep  0.25 seconds
      $loop++
   done
   Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
  # re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point

## do publish stuff

if eclipse_module_is_set_to_start
then
   touch $FILENAME
fi
{{pre}}


was (Author: dlmiles):
To go back to Rob's race concern:

> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish

Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.

Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.

{{
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
   Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
   while test -f $FILENAME && $loop < 10
   do
      sleep  0.25 seconds
      $loop++
   done
   Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
  # re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point

## do publish stuff

if eclipse_module_is_set_to_start
then
   touch $FILENAME
fi
}}

> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
>                 Key: JBIDE-18862
>                 URL: https://issues.jboss.org/browse/JBIDE-18862
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: server
>         Environment: Windiws7 64bit, JDK 8u25
>            Reporter: Darryl Miles
>            Priority: Minor
>             Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)