[jbosstools-issues] [JBoss JIRA] (JBIDE-15357) Unexpected state of deployed project when project is deleted

Rob Stryker (JIRA) jira-events at lists.jboss.org
Wed Oct 30 07:41:01 EDT 2013


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

Rob Stryker edited comment on JBIDE-15357 at 10/30/13 7:39 AM:
---------------------------------------------------------------

This comment has been edited**

Eclipse/WTP:

The JavaEEServerRefRefactorParticipant  is in charge of removing the module from the server and initiating the publish operation. It should be publishing with dummy DeletedModule representations of the module that is in the process of being deleted, NOT the original. This is not currently happening.  See also wtp classes:  ProjectRefactoringListener, ProjectRefactorOperation.java 

JBT:

Below are the various situations to be tested, and what their results are:
  1) Close project + publish -> DeletedModule, and we ignore it
  2) Close project + manual rm from server + publish ->  DeletedModule, and we unpublish it
  3) Delete project (not auto-remove fr. server) + publish -> DeletedModule, and we ignore it
  4) Delete project (not auto-remove fr. server),  then remove+publish -> DeletedModule, and we unpublish it
  5) Delete project (w. auto-remove fr. server + auto-publish) -> (incorrect) RealModule, and we unpublish it


For ASTools, situation 5 is the danger situation, and it is found to be safe after recent commits and tests.  A related bug was found where our calculation of DeletedModule was incorrect. 


Affect on openshift:

1)  openshift already throws coreexception if magic project is unaccessible (or deleted), so no change or error here
2)  binary subprojects:  
    a) openshift will currently delete any 'removed' module output file in magic project, regardless of whether it is real or DeletedModule
    b) openshift will currently "publish" any module that is not to be removed, regardless of whether it is a real module, DeletedModule,or incorrect non-DeletedModule that is missing. The effect of this is that magicProject/deployments/webProj.war  will turn into an empty war file. 

So, openshift is already broken in this regard, and the change in ASTools will have NO effect on it. OpenShift is currently broken in that openshift tools will overwrite the binary file (output.war) with an empty one during a publish of a non-removed-from-server project that is either closed or missing from the workspace.  The user still has the opportunity to click "NO" in the "Do you want to commit" dialog, and so this bug is not critical, and is also not a regression, as it already currently exists. 

What this means is that OpenShift needs to adjust to not publish any DeletedModule except when being 'removed from server'.

The alternative is to make no commits on our side,  recognize that a user must initiate a publish event manually after deleting the project to make the deployment go away. I do not vote for this solution currently. 

Finally, the class heirarchy of openshift really needs to stop inheriting stuff from ASTools, because the server structures are quite different. Hopefully, future refactors will make this easier. 
                
      was (Author: rob.stryker):
    Eclipse/WTP:

The JavaEEServerRefRefactorParticipant  is in charge of removing the module from the server and initiating the publish operation. It should be publishing with dummy DeletedModule representations of the module that is in the process of being deleted, NOT the original. This is not currently happening.  See also wtp classes:  ProjectRefactoringListener, ProjectRefactorOperation.java 

JBT:

Below are the various situations to be tested, and what their results are:
  1) Close project + publish -> DeletedModule, and we ignore it
  2) Close project + manual rm from server + publish ->  DeletedModule, and we unpublish it
  3) Delete project (not auto-remove fr. server) + publish -> DeletedModule, and we ignore it
  4) Delete project (not auto-remove fr. server),  then remove+publish -> DeletedModule, and we unpublish it
  5) Delete project (w. auto-remove fr. server + auto-publish) -> (incorrect) RealModule, and we unpublish it


For ASTools, situation 5 is the danger situation, and it is found to be safe after recent commits and tests.  A related bug was found where our calculation of DeletedModule was incorrect. 


Affect on openshift:

1)  openshift already throws coreexception if magic project is unaccessible (or deleted), so no change or error here
2)  binary subprojects:  
    a) openshift will currently delete any 'removed' module output file in magic project, regardless of whether it is real or DeletedModule
    b) openshift will currently "publish" any module that is not to be removed, regardless of whether it is a real module, DeletedModule,or incorrect non-DeletedModule that is missing. The effect of this is that {magicProject}/deployments/webProj.war  will turn into an empty war file. 

So, openshift is already broken in this regard, and the change in ASTools will only affect it in that openshift will overwrite the binary file with an empty one during the delete operation directly instead of the 2nd publish. The user still has the opportunity to click "NO" in the "Do you want to commit" dialog, and so this bug is not critical. 

What this means is that OpenShift needs to adjust to not publish any DeletedModule NOT being removed, or any inaccessible project which is still 'deployed to' the server. 


The alternative is to make no commits on our side,  recognize that a user must initiate a publish event manually after deleting the project to make the deployment go away. I do not vote for this solution currently. 

Finally, the class heirarchy of openshift really needs to stop inheriting stuff from ASTools, because the server structures are quite different. Hopefully, future refactors will make this easier. 
                  
> Unexpected state of deployed project when project is deleted
> ------------------------------------------------------------
>
>                 Key: JBIDE-15357
>                 URL: https://issues.jboss.org/browse/JBIDE-15357
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 4.1.0.Final
>         Environment: JBDS 7.0.0.GA, L64
>            Reporter: Jiri Peterka
>            Assignee: Rob Stryker
>              Labels: respin-b
>             Fix For: 4.1.1.Beta1
>
>
> When project is deployed in IDE and then removed expected behavior would expect project would be undeployed. When I've tried that everything seemed as undeployed (I mean Server view) but project is still deployed. This is not user expected behavior IMO.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jbosstools-issues mailing list