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

[Rob Stryker (JIRA)]

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

Rob Stryker commented on JBIDE-18862:
-------------------------------------

When a server is stopped, we just publish, and add a .dodeploy marker, so everything's safe. 

When the server is running, there should never be a .dodeploy there that doesn't belong there, and I don't believe there ever is one. When you first start the server, publishes are done *before* the server starts. So if there was a .dodeploy there when the server was stopped that didn't belong there, and you then start the server, it publishes and adds a dodeploy and the .dodeploy actually does belong there. 

The only way you should end up with a .dodeploy that doesn't belong there is:
  1) If a user added one via cmd line by himself
  2) If two publish jobs are running at the same time in eclipse, which shouldn't happen
  3) If a full publish finishes, adds a dodeploy, and an incremental publish occurs after. The .dodeploy belongs there and should not be removed during the incremental publish. 

As I mentioned above:

To do this properly, I would need to verify the incremental publish is not pre-empting a full publish / .dodeploy marker, and then re-add the .dodeploy marker after the incremental publish... but this would complicate things quite a bit. Furthermore, if there was a stale .dodeploy there that wasn't supposed to be there, I'd probably assume I was pre-empting an actual full deployment, and re-add the marker when I wasn't supposed to. 

So basically, I cannot simply wipe all .dodeploy markers before a publish, because its possible an incremental deployment is running directly after a full publish (but before the server has started to pick up the deployment). Incremental deployments do not add new .dodeploy markers, so the effect is I'd end up deleting a valid .dodeploy when doing an incremental update, and then no .dodeploy would be added after it.  


If we simply wiped .dodeploy all the time before each publish, the following would be a bug:

1) A full publish happens, adding a .dodeploy
2) An incremental publish wipes the .dodeploy, so server never starts to deploy
3) The incremental publish changes a few files
4) The incremental publish does NOT add a new .dodeploy 
5) The deployment is never picked up by the server. 

The only workaround for this would be to have incremental publish add .dodeploy markers also, which would effectively make all incremental publishes into full module restarts, which would be a significant performance problem and remove the benefit of incremental publish. 

Can you come up with a valid workflow where a .dodeploy is present when it doesn't belong there? As far as I can tell, there's no way for this to happen unless the user does it themselves, in which case we should not be wiping it. 

> 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: Bug
>          Components: server
>         Environment: Windiws7 64bit, JDK 8u25
>            Reporter: Darryl Miles
>            Assignee: Rob Stryker
>             Fix For: 4.2.3.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.11#6341)