[JBoss JIRA] (JBIDE-15357) Unexpected state of deployed project when project is deleted
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15357?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-15357:
-------------------------------------
A final thing to note is that if the server is 'stopped', no publish will be automatically initiated during the delete-project operation. This also has always been this way, as many actions are not taken throughout wtp unless the server is in started mode.
> 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
12 years, 5 months
[JBoss JIRA] (JBIDE-15357) Unexpected state of deployed project when project is deleted
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15357?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-15357:
-------------------------------------
I will be adding test cases with my next commit, so that should clear some things up.
> 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
12 years, 5 months
[JBoss JIRA] (JBIDE-15357) Unexpected state of deployed project when project is deleted
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15357?page=com.atlassian.jira.plugi... ]
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
12 years, 5 months
[JBoss JIRA] (JBIDE-15357) Unexpected state of deployed project when project is deleted
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15357?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-15357:
-------------------------------------
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
12 years, 5 months
[JBoss JIRA] (JBIDE-11602) Provide first class support for client side development
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-11602?page=com.atlassian.jira.plugi... ]
Victor Rubezhny edited comment on JBIDE-11602 at 10/30/13 6:34 AM:
-------------------------------------------------------------------
The patch is proposed for the issue [Bug 420086 - Copy text doesn't work from read-only javascript file|https://bugs.eclipse.org/bugs/show_bug.cgi?id=420086]
The issue was involved by fix for [Bug 311348 - java.lang.ClassCastException: org.eclipse.wst.jsdt.internal.ui.navigator.TypeDelegate cannot be cast to org.eclipse.wst.jsdt.internal.core.JavaElement|https://bugs.eclipse.org/b...] which disabled any text operations on JavaScript editors with read-only content. But it looks like a buggy solution there. So, the patch enables text operations for read-only source files.
On 2012.11.29 the issue is marked as RESOLVED FIXED with Target Milestone 3.6: [Bug 420086 - Copy text doesn't work from read-only javascript file|https://bugs.eclipse.org/bugs/show_bug.cgi?id=420086].
was (Author: vrubezhny):
The patch is proposed for the issue [Bug 420086 - Copy text doesn't work from read-only javascript file|https://bugs.eclipse.org/bugs/show_bug.cgi?id=420086]
The issue was involved by fix for [Bug 311348 - java.lang.ClassCastException: org.eclipse.wst.jsdt.internal.ui.navigator.TypeDelegate cannot be cast to org.eclipse.wst.jsdt.internal.core.JavaElement|https://bugs.eclipse.org/b...] which disabled any text operations on JavaScript editors with read-only content. But it looks like a buggy solution there. So, the patch enables text operations for read-only source files.
> Provide first class support for client side development
> -------------------------------------------------------
>
> Key: JBIDE-11602
> URL: https://issues.jboss.org/browse/JBIDE-11602
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: jsp/jsf/xml/html source editing
> Reporter: Sebastien Deleuze
> Assignee: Victor Rubezhny
> Priority: Critical
> Labels: jsdt, vjet
> Fix For: 4.2.x
>
> Attachments: jbosstools-add-vjet-dependencies-patch.patch, jquery-1.5.1.min.js.jpg, jquery.tagcanvas.min.js.jpg, nexj-JS-Content-Assist-On-a-JS-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-a-JS-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-1-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-1-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-2-1-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-2-1-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-2-2-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-2-2-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-a-JS-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-a-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-Any-JS-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-1-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-1-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-2-1-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-2-1-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-2-2-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-2-2-in-ticket-monster-project.jpg
>
>
> Web application development is currently moving in many projects from end to end server side technologies to HTML5 RIA developed with REST Webservices/ Webscoket on serverside + pure client side technologies GUI (Backbone.js for example).
> Eclipse has been always been quite bad in the field of advanced Javascript development. JSDT was a good start, but its development has been stopped for a few years, and in its current status, it is not really a good tool for real HTML5/JS dev. From what I know, there is no roadmap for strong move on this field in the WTP team. The only real Eclipse initiative for client side development is Orion (http://www.eclipse.org/orion/) outside of the IDE.
> The only other alternative is Aptana Studio 3, acquired last year by AppAccelerator.
> My question is : is there any plan to consider client side development as a first class citizen in JBoss Studio, even if this question apply to the whole Eclipse Ecosystem ? Other IDE like Netbeans or IntelliJ Idea have a strong support for these technologies, and my guess is this lack may be a significant blocking point in the following years.
> Thanks in advance for your feedback.
--
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
12 years, 5 months
[JBoss JIRA] (JBIDE-11602) Provide first class support for client side development
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-11602?page=com.atlassian.jira.plugi... ]
Victor Rubezhny edited comment on JBIDE-11602 at 10/30/13 6:35 AM:
-------------------------------------------------------------------
The patch is proposed for the issue [Bug 420533 - ClassCastException when getting validation participants|https://bugs.eclipse.org/bugs/show_bug.cgi?id=420533]
Patch fixes the ClassCastException by adding an additional object type check. No other changes were made because the only objects of type ValidationParticipant are acceptable here, so all other objects will be ignored.
On 2012.11.29 the issue is marked as RESOLVED FIXED with Target Milestone 3.6: [Bug 420533 - ClassCastException when getting validation participants|https://bugs.eclipse.org/bugs/show_bug.cgi?id=420533].
was (Author: vrubezhny):
The patch is proposed for the issue [Bug 420533 - ClassCastException when getting validation participants|https://bugs.eclipse.org/bugs/show_bug.cgi?id=420533]
Patch fixes the ClassCastException by adding an additional object type check. No other changes were made because the only objects of type ValidationParticipant are acceptable here, so all other objects will be ignored.
> Provide first class support for client side development
> -------------------------------------------------------
>
> Key: JBIDE-11602
> URL: https://issues.jboss.org/browse/JBIDE-11602
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: jsp/jsf/xml/html source editing
> Reporter: Sebastien Deleuze
> Assignee: Victor Rubezhny
> Priority: Critical
> Labels: jsdt, vjet
> Fix For: 4.2.x
>
> Attachments: jbosstools-add-vjet-dependencies-patch.patch, jquery-1.5.1.min.js.jpg, jquery.tagcanvas.min.js.jpg, nexj-JS-Content-Assist-On-a-JS-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-a-JS-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-1-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-1-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-2-1-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-2-1-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-2-2-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-2-2-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-a-JS-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-a-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-Any-JS-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-1-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-1-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-2-1-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-2-1-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-2-2-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-2-2-in-ticket-monster-project.jpg
>
>
> Web application development is currently moving in many projects from end to end server side technologies to HTML5 RIA developed with REST Webservices/ Webscoket on serverside + pure client side technologies GUI (Backbone.js for example).
> Eclipse has been always been quite bad in the field of advanced Javascript development. JSDT was a good start, but its development has been stopped for a few years, and in its current status, it is not really a good tool for real HTML5/JS dev. From what I know, there is no roadmap for strong move on this field in the WTP team. The only real Eclipse initiative for client side development is Orion (http://www.eclipse.org/orion/) outside of the IDE.
> The only other alternative is Aptana Studio 3, acquired last year by AppAccelerator.
> My question is : is there any plan to consider client side development as a first class citizen in JBoss Studio, even if this question apply to the whole Eclipse Ecosystem ? Other IDE like Netbeans or IntelliJ Idea have a strong support for these technologies, and my guess is this lack may be a significant blocking point in the following years.
> Thanks in advance for your feedback.
--
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
12 years, 5 months
[JBoss JIRA] (JBDS-2712) Typo in installer: Ok > OK
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBDS-2712?page=com.atlassian.jira.plugin.... ]
Martin Malina closed JBDS-2712.
-------------------------------
Verified in JBDS 7.1.0.Beta1a B470
> Typo in installer: Ok > OK
> --------------------------
>
> Key: JBDS-2712
> URL: https://issues.jboss.org/browse/JBDS-2712
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 7.0.0.GA
> Reporter: Michelle Murray
> Assignee: Denis Golovin
> Fix For: 7.1.0.Beta1
>
> Attachments: Installer_Ok1.png, Installer_Ok2.png
>
>
> In step 5 of the installer (Select Platforms and Servers), two child windows have 'Ok', which should be 'OK'.
> 1. At step 5, click Add.
> 2. Click Browse.
> 3. Select location and click *Ok*.
> 4. Click *Ok* to close the Add Location window.
> Screen captures attached.
--
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
12 years, 5 months