[JBoss JIRA] (JBIDE-16950) Very frequently, webapps are being undeployed right after being deployed
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16950?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-16950:
-------------------------------------
If we don't add the deployment scanners, then deployments to other custom folders won't be picked up at all. I definitely need more details here.
Is it adding a duplicate scanner? What is the value of this duplicate scanner?
As far as I know, we purposely do NOT add an additional scanner for the already-default deployments folder (standalone/deployments). In fact, we remove this one from the list before adding the other scanners.
> Very frequently, webapps are being undeployed right after being deployed
> ------------------------------------------------------------------------
>
> Key: JBIDE-16950
> URL: https://issues.jboss.org/browse/JBIDE-16950
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Beta1
> Environment: Win 7-64, JDK 7, AS 7.1.1, WildFly 8.0.0
> Reporter: Fred Bricon
> Assignee: Rob Stryker
> Priority: Blocker
> Labels: respin-b
> Fix For: 4.2.0.Beta1
>
>
> I'm experiencing this issue where, after doing a full publishing, the deployed webapp is being undeployed right after being deployed.
> See http://screencast.com/t/JmwA0TlBrDWX
> The most reliable way (even though it's not 10% of the time) to reproduce the issue is to deploy a webapp to AS 7.1.1 or WF8, then remove it from the server, deploy it back. That's when the problem occurs :
> {noformat}
> 14:13:45,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "dontundeployme.war" (runtime-name: "dontundeployme.war")
> 14:13:45,485 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: /dontundeployme
> 14:13:45,683 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "dontundeployme.war" (runtime-name : "dontundeployme.war")
> 14:13:50,708 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017535: Unregistered web context: /dontundeployme
> 14:13:50,730 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment dontundeployme.war (runtime-name: dontundeployme.war) in 23ms
> 14:13:50,999 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018558: Undeployed "dontundeployme.war" (runtime-name: "dontundeployme.war")
> 14:13:56,004 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015003: Found dontundeployme.war in deployment directory. To trigger deployment create a file called dontundeployme.war.dodeploy
> {noformat}
> Also, pretty quite frequently, deployment just fails (but I haven't been able to figure out a decisive pattern yet) as the server thinks deployments are duplicates (see screencast)
--
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
[JBoss JIRA] (JBIDE-16876) New Application wizard: page#1 needs fields disabled based on user actions
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16876?page=com.atlassian.jira.plugi... ]
Michelle Murray commented on JBIDE-16876:
-----------------------------------------
I original proposed the split in the description section but can see Max's point that users shouldn't have to make a connection etc. and know about OpenShift Explorer view to be able to import an OpenShift app.
So how about the following:
* Under Start from scratch, click OpenShift Application - see wizard first page with choice to import or create new OpenShift app [1]
* In OpenShift Explorer view, right-click app and click Import Application - see wizard second page [2]
* In Servers view, right-click server adapter for app and click OpenShift > Import Application - see wizard second page
[1] Text shown on mouse hover over OpenShift Application needs changing to mention that can use to import OpenShift app to workspace and not just create a new OpenShift application.
[2] Import Application menu items currently open wizard on first page
> New Application wizard: page#1 needs fields disabled based on user actions
> --------------------------------------------------------------------------
>
> Key: JBIDE-16876
> URL: https://issues.jboss.org/browse/JBIDE-16876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.0.Beta1
> Reporter: Michelle Murray
> Assignee: Andre Dietisheim
> Labels: application_wizard
> Fix For: 4.2.0.Beta2
>
> Attachments: create-new-application.png, import-existing-application.png, out-3.ogv
>
>
> In the New OpenShift Application wizard, user has two choices 1) use existing app or 2) create new app.
> * If user clicks 'Use my existing OpenShift application', then list of cartridges should be disabled. I was able to give name of app to import and then select cartridge which was meaningless as app was imported with original cartridge (as expected) and not the new one I had selected.
> * If user clicks 'Create a new OpenShift application', the field for app name and browse button should be disabled.
> But this also raises the question for me as to why these two choices are shared on the same wizard page. I wonder if it would be cleaner to separate them.
> * So when in OpenShift Explorer view a user right-clicks an application and clicks 'Import Application' they would just see the wizard starting from the page 'Set up project for new OpenShift Application'. They've already decided they want to import so offering fields about creating a new OpenShift app isn't useful.
> * Similarly, when a user selects 'New > Application' then they don't need to be offered the information about using an existing OpenShift application. To me as a user, the action 'New > Application' makes me thing that I am creating a new OpenShift Application so having fields about using an existing OpenShift app is confusing.
--
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
[JBoss JIRA] (JBIDE-16876) New Application wizard: page#1 needs fields disabled based on user actions
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16876?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-16876:
---------------------------------------
I know it. But this is related to splitting up current first wizard page, as is mentioned in JIRA description - maybe I should be more descriptive what I am replying to/talking about. With choice of exclusive radio button I agree. I just wanted to say that splitting it up would be step back.
According to those 3 steps how to import application - yes, it would affect all of them - so (in that minor UI improvement) wizard would start on the second wizard page (question is - do we want this - such behaviour?
> New Application wizard: page#1 needs fields disabled based on user actions
> --------------------------------------------------------------------------
>
> Key: JBIDE-16876
> URL: https://issues.jboss.org/browse/JBIDE-16876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.0.Beta1
> Reporter: Michelle Murray
> Assignee: Andre Dietisheim
> Labels: application_wizard
> Fix For: 4.2.0.Beta2
>
> Attachments: create-new-application.png, import-existing-application.png, out-3.ogv
>
>
> In the New OpenShift Application wizard, user has two choices 1) use existing app or 2) create new app.
> * If user clicks 'Use my existing OpenShift application', then list of cartridges should be disabled. I was able to give name of app to import and then select cartridge which was meaningless as app was imported with original cartridge (as expected) and not the new one I had selected.
> * If user clicks 'Create a new OpenShift application', the field for app name and browse button should be disabled.
> But this also raises the question for me as to why these two choices are shared on the same wizard page. I wonder if it would be cleaner to separate them.
> * So when in OpenShift Explorer view a user right-clicks an application and clicks 'Import Application' they would just see the wizard starting from the page 'Set up project for new OpenShift Application'. They've already decided they want to import so offering fields about creating a new OpenShift app isn't useful.
> * Similarly, when a user selects 'New > Application' then they don't need to be offered the information about using an existing OpenShift application. To me as a user, the action 'New > Application' makes me thing that I am creating a new OpenShift Application so having fields about using an existing OpenShift app is confusing.
--
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
[JBoss JIRA] (JBIDE-16960) with GPE feature removed from JBT 4.40.0.Beta2-SNAPSHOT targetplatform, JBT agg site won't build
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16960?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16960:
----------------------------------------
If we remove the JBT feature requiring those GPE feature, why are GPE feature re-added to TP? https://github.com/jbosstools/jbosstools-target-platforms/pull/49
> with GPE feature removed from JBT 4.40.0.Beta2-SNAPSHOT targetplatform, JBT agg site won't build
> ------------------------------------------------------------------------------------------------
>
> Key: JBIDE-16960
> URL: https://issues.jboss.org/browse/JBIDE-16960
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: target-platform, upstream
> Affects Versions: 4.2.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.2.0.Beta2
>
>
> I removed the deprecated GPE feature [1] because it can't be installed onto Luna (JBIDE-16910).
> [1] https://github.com/jbosstools/jbosstools-target-platforms/pull/48/files#d...
> So now we get this:
> {code:title=http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.site_master/8748/console}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.jboss.tools.site.core raw:4.2.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):4.2.0-SNAPSHOT
> [ERROR] Missing requirement: org.jboss.tools.gwt.core 1.1.0.Final-v20130205-2223-B78 requires 'bundle com.google.gdt.eclipse.suite 3.0.1' but it could not be found
> [ERROR] Cannot satisfy dependency: org.jboss.tools.gwt.feature.feature.group 1.1.0.Final-v20130205-2223-B78 depends on: org.jboss.tools.gwt.core [1.1.0.Final-v20130205-2223-B78]
> [ERROR] Cannot satisfy dependency: org.jboss.tools.site.core raw:4.2.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):4.2.0-SNAPSHOT depends on: org.jboss.tools.gwt.feature.feature.group 0.0.0
> [ERROR]
> [ERROR] Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.jboss.tools.gwt.core 1.1.0.Final-v20130205-2223-B78 to bundle com.google.gwt.eclipse.core 0.0.0.; Unable to satisfy dependency from org.jboss.tools.gwt.core 1.1.0.Final-v20130205-2223-B78 to bundle com.google.gdt.eclipse.suite 3.0.1.; Unable to satisfy dependency from org.jboss.tools.maven.gwt 1.6.0.Beta2-v20140321-0445-B465 to bundle com.google.gwt.eclipse.core 2.5.0.; Unable to satisfy dependency from org.jboss.tools.maven.gwt 1.6.0.Beta2-v20140321-0445-B465 to bundle com.google.gwt.eclipse.oophm 3.0.0.; No solution found because the problem is unsatisfiable.] -> [Help 1]{code}
> At the moment, only com.google.gwt.eclipse.sdkbundle_2.5.1 is present in the Beta2-SNAPSHOT target platform [2]. In the previous TP [3], we had more:
> {code:title=http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Beta1/REPO/plugins/}
> com.google.appengine.*
> com.google.gdt.eclipse.*
> com.google.gwt.eclipse.core_3.4.2.v201310081834-rel-r43.jar
> com.google.gwt.eclipse.oophm_3.4.2.v201310081834-rel-r43.jar
> com.google.gwt.eclipse.sdkbundle_2.5.1.jar
> {code}
> [2] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.4...
> [3] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.4...
> ----
> *QUESTIONS*:
> Does the *org.jboss.tools.gwt.feature* need to remain in the JBT update site?
> Or... should I add the com.google.gwt.eclipse.core plugin back into the JBoss Tools 4.40.0.Beta2-SNAPSHOT target platform [2]?
--
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
[JBoss JIRA] (TOOLSDOC-484) Update LiveReload screen caps for EAP 6.2
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-484?page=com.atlassian.jira.plug... ]
Michelle Murray updated TOOLSDOC-484:
-------------------------------------
Sprint: 2014/S5 (31-Mar > 13-Apr)
> Update LiveReload screen caps for EAP 6.2
> -----------------------------------------
>
> Key: TOOLSDOC-484
> URL: https://issues.jboss.org/browse/TOOLSDOC-484
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: User Guide - LiveReload Tools
> Affects Versions: 4.2.0.Beta1
> Reporter: Michelle Murray
> Assignee: Suz Dorfield
> Fix For: 4.2.0.Beta1
>
> Original Estimate: 45 minutes
> Remaining Estimate: 45 minutes
>
> Writer task: Create new screen caps for LiveReload Tools figs with EAP 6.2:
> * Figure 5.5. Show In→Web Browser via LiveReload Server Menu Option
> * Figure 5.7. Show In→Web Browser on External Device Menu Option
> * Figure 5.10. Show In→BrowserSim Menu Option
--
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
[JBoss JIRA] (TOOLSDOC-484) Update LiveReload screen caps for EAP 6.2
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-484?page=com.atlassian.jira.plug... ]
Michelle Murray updated TOOLSDOC-484:
-------------------------------------
Assignee: Suz Dorfield (was: Michelle Murray)
> Update LiveReload screen caps for EAP 6.2
> -----------------------------------------
>
> Key: TOOLSDOC-484
> URL: https://issues.jboss.org/browse/TOOLSDOC-484
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: User Guide - LiveReload Tools
> Affects Versions: 4.2.0.Beta1
> Reporter: Michelle Murray
> Assignee: Suz Dorfield
> Fix For: 4.2.0.Beta1
>
> Original Estimate: 45 minutes
> Remaining Estimate: 45 minutes
>
> Writer task: Create new screen caps for LiveReload Tools figs with EAP 6.2:
> * Figure 5.5. Show In→Web Browser via LiveReload Server Menu Option
> * Figure 5.7. Show In→Web Browser on External Device Menu Option
> * Figure 5.10. Show In→BrowserSim Menu Option
--
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
[JBoss JIRA] (TOOLSDOC-484) Update LiveReload screen caps for EAP 6.2
by Michelle Murray (JIRA)
Michelle Murray created TOOLSDOC-484:
----------------------------------------
Summary: Update LiveReload screen caps for EAP 6.2
Key: TOOLSDOC-484
URL: https://issues.jboss.org/browse/TOOLSDOC-484
Project: Documentation for JBoss Tools and Developer Studio
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: User Guide - LiveReload Tools
Affects Versions: 4.2.0.Beta1
Reporter: Michelle Murray
Assignee: Michelle Murray
Fix For: 4.2.0.Beta1
Writer task: Create new screen caps for LiveReload Tools figs with EAP 6.2:
* Figure 5.5. Show In→Web Browser via LiveReload Server Menu Option
* Figure 5.7. Show In→Web Browser on External Device Menu Option
* Figure 5.10. Show In→BrowserSim Menu Option
--
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