[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=13034062#comment-13034062 ] 

Darryl Miles edited comment on JBIDE-18862 at 1/21/15 7:41 AM:
---------------------------------------------------------------

If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.

Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete.  It is normal for the AS to not notice the *.dodeploy yet.

If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down.  Since it should not be performing any file change operations in the deployment/ directory until the *.isdeploying marker has been  removed by the AS.  File changes can be made in Stopped and Started states, but not in Stopping and Starting states.

There is no notion of Full Publish or Incremental Publish by the AS.  This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform AS state changes.

So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation.  It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started".  It will note that Eclipse is already started and take no action.  It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state.  Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.

Please stop thinking about "Full Publish" and "Incremental Publish" this is implementation detail and a problem for Eclipse to manage.  A previous Full Publish action that was not terminally completed, is not yet over!  So until the AS does the deploy the Full Publish is still in progress.  If Eclipse happens to be able to get in an extra Incremental Publish (as eclipse wants to call it) then great.  But that original Full Publish is not yet compelted at the time, so it is still an outstanding action on the AS.


was (Author: dlmiles):
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.

Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete.  It is normal for the AS to not notice the *.dodeploy yet.

If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down.  Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been  removed by the AS.  File changes can be made in Stopped and Started states, but not in Stopping and Starting states.

There is no notion of Full Publish or Incremental Publish by the AS.  This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform AS state changes.

So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation.  It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started".  It will note that Eclipse is already started and take no action.  It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state.  Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.

Please stop thinking about "Full Publish" and "Incremental Publish" this is implementation detail and a problem for Eclipse to manage.  A previous Full Publish action that was not terminally completed, is not yet over!  So until the AS does the deploy the Full Publish is still in progress.  If Eclipse happens to be able to get in an extra Incremental Publish (as eclipse wants to call it) then great.  But that original Full Publish is not yet compelted at the time, so it is still an outstanding action on the AS.

> 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)