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

Darryl Miles commented on JBIDE-18862:
--------------------------------------

I've never said the problem is easy to solve.  :)

My own view has always been (since last 7+ years) have a very efficient remotable API.  So efficient that is can work in local mode too without any noticeable performance difference.   This might mean the AS has code to provide a file/dir manifest of the deployment location, with filenames/fileLength/lastModifiedTimestamp/hashChecksum.  The IDE would push delta changes only.  The AS would positively acknowledge actions that are going on.  The Eclipse IDE would maintain one long running socket connection to the server.

You can push file changes down the socket (and have the AS buffer them) even if the AS can not update the files in the deployment area yet because something conflicting is starting/stopping.

Since the AS is in control of all file changes to the deployment area itself, it could maintain the current view, transactional updates to that fileset view, and because it was aware of what has changed it can optimize the functions on the AS about what it needs to do to refresh/restart sub-deployments.  It also doesn't have to maintain a 1:1 file-system view to logical deployment view, in the case that a file or directory can not be deleted (due to file locking), it could just re-allocate/re-direct the logical deployment view to some temporary location.

Even a clean and full publish might still push delta changes, because the AS doesn't have to remove files (it has previously been sent), if it has a hash match for a JAR it has been previous sent it can simply re-use the data.  The IDE pushes a complete file-set view to the AS (with filelength/file-content-hashes), the AS comes back with information about which resources it has hits for, providing a unique reference.  The IDE can selectively decide which items to push and which items to let the AS resolve from its cache.

I've never bought the argument that we must optimize for local, the issue is that remote is too in-efficient to use for local.

> 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.11#6341)