[JBoss JIRA] (JBIDE-21877) Connection wizard: Make error message shown in OpenShift Explorer for outdated token more user friendly
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21877?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-21877:
-----------------------------------------------
[~adietish], my point was to suggest to the contributors of epp.mpc project to fix the bug in their code. I admit that I would did better to approach them. But, miraculously, it happened without my efforts. This NPE is fixed within the same issue (Bugzilla id=487975) on May 18th by additional commit
https://github.com/eclipse/epp.mpc/commit/071fc6a4dfd5cfdc2958a97ba5f171c...
Yes, we are not authorized to view this Bugzilla issue (is it an open source?!). But we can see commits mirrored by github user creckord whom I assume to be a committer for the project.
So, the part of this issue related to this NPE can be marked as upstream and fixed upstream with the Bugzilla id=487975.
All this leaves open the task 'How to make error message etc more user friendly' when the cause is some failure of a third party code that meddled into the OpenShift request. Can we assume that the problem is an outdated token by catching a NPE, or array out of index, or whatever else thrown by some buggy third party code?
> Connection wizard: Make error message shown in OpenShift Explorer for outdated token more user friendly
> -------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-21877
> URL: https://issues.jboss.org/browse/JBIDE-21877
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Labels: connection_wizard, openshift_v3
> Fix For: 4.4.x
>
> Attachments: screenshot-1.png
>
>
> When I am trying to connect to OpenShift connection with outdated token stored in secure storage, an error tree item is shown in OpenShift Explorer under the connection. Erro tree item is "java.lang.NullPointerException", but it could be something more user friendly such as "Expired credentials" or the one we are already using in other scenarious - You must obtain an API token by .... Following stack trace is in error log
> {code}
> There was an error retrieving children in the OpenShift explorer
> java.lang.NullPointerException
> at org.eclipse.epp.internal.mpc.core.util.ProxyHelper$ProxyAuthenticator.getPasswordAuthentication(ProxyHelper.java:124)
> at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
> at org.apache.http.impl.client.SystemDefaultCredentialsProvider.getSystemCreds(SystemDefaultCredentialsProvider.java:92)
> at org.apache.http.impl.client.SystemDefaultCredentialsProvider.getCredentials(SystemDefaultCredentialsProvider.java:113)
> at com.openshift.internal.restclient.authorization.OpenShiftCredentialsProvider.getCredentials(OpenShiftCredentialsProvider.java:69)
> at org.apache.http.impl.client.AuthenticationStrategyImpl.select(AuthenticationStrategyImpl.java:184)
> at org.apache.http.impl.client.TargetAuthenticationStrategy.select(TargetAuthenticationStrategy.java:43)
> at org.apache.http.impl.auth.HttpAuthenticator.handleAuthChallenge(HttpAuthenticator.java:154)
> at org.apache.http.impl.execchain.MainClientExec.needAuthentication(MainClientExec.java:557)
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:275)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:134)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContext(AuthorizationClient.java:99)
> at com.openshift.internal.restclient.DefaultClient.getContext(DefaultClient.java:504)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:236)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.core.connection.Connection.retryList(Connection.java:445)
> at org.jboss.tools.openshift.core.connection.Connection.getResources(Connection.java:389)
> at org.jboss.tools.openshift.core.connection.Connection.getResources(Connection.java:376)
> at org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectCache.getProjectsFor(OpenShiftProjectCache.java:59)
> at org.jboss.tools.openshift.internal.ui.explorer.OpenShiftExplorerContentProvider.getChildrenFor(OpenShiftExplorerContentProvider.java:93)
> at org.jboss.tools.openshift.internal.common.ui.explorer.BaseExplorerContentProvider$1.run(BaseExplorerContentProvider.java:167)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22225) Debugging for node.js applications on Openshift
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22225?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-22225:
-------------------------------------
[~fbricon], [~adietish] guys I was able to debug nodejs app running on openshift instance. I have recorded a short video which explains how to do it - https://vimeo.com/171596853
Several remarks:
- Live edit functionality is not working (once the file is changed / rsync is performed - previous connection used for debugging is terminated)
- In order to debug project's files in JSDT editor V8 Source Mapping shoud be tuned properly (prefix = deployment dir)
Could you please recommend how debug on openshift functionality should be implemented? Should it be debug shortcut "Debug on openshift" available on the app in Openshift explorer or smth. else? Also do you happen to know if it is possible to connect to the application by IP address + port combo instead of route url (for now I can debug only using port forwarding, it would be great to connect to remote directly ) ?
> Debugging for node.js applications on Openshift
> -----------------------------------------------
>
> Key: JBIDE-22225
> URL: https://issues.jboss.org/browse/JBIDE-22225
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: javascript, openshift
> Reporter: Gorkem Ercan
> Assignee: Ilya Buziuk
> Labels: debugging, openshift_v3
> Fix For: 4.4.x
>
>
> We should be able to start and connect the new debugger to a node.js application running on Openshift.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-19081) Use simpler Surefire include/exclude pattern in parent pom
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19081?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-19081:
-------------------------------------
This issue prevents foundation core tests from being run in CLI builds: JBIDE-22449
> Use simpler Surefire include/exclude pattern in parent pom
> ----------------------------------------------------------
>
> Key: JBIDE-19081
> URL: https://issues.jboss.org/browse/JBIDE-19081
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
> Priority: Minor
> Fix For: 4.4.x
>
>
> 1. In JBDS9, use these new default patterns for Surefire to define which test classes to run/exclude:
> {code}
> include = *Test*, *Test, *TestCase
> exclude = *Abstract*
> {code}
> 2. If that causes test failures because running incorrectly named
> abstract stuff, they can refactor, add their own root pom overrides, use
> a TestSuite, or use @Ignore in test classes.
> 3. If the count of tests run suddenly DROPS because the pattern isn't
> running the correct # of tests, they can add their own root pom
> overrides, or use a TestSuite.
> Ref: http://lists.jboss.org/pipermail/jbosstools-dev/2015-January/009688.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22449) Better parse qualifiers for versions
by Ondrej Dockal (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22449?page=com.atlassian.jira.plugi... ]
Ondrej Dockal commented on JBIDE-22449:
---------------------------------------
I took a look at it, as well. There is org.jboss.tools.foundation.core.test.FoundationAllTests suite called in pom file which includes only two test classes and nothing else, even that there are more classes to test, I would also blame test pattern in recursive pom view:
<include>**/AllTests.class</include>
<include>**/*AllTests*.class</include>
<include>**/*AllBotTests*.class</include>
<include>**/*TestSuite*.class</include>
I reopen this jira, what to do next is up to you.
> Better parse qualifiers for versions
> ------------------------------------
>
> Key: JBIDE-22449
> URL: https://issues.jboss.org/browse/JBIDE-22449
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: common/jst/core
> Affects Versions: 4.4.0.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Fix For: 4.4.0.Final
>
>
> Currently, in ide-config.properties, if no 1.2.3.GA-123456-23455 version is found, we fall back to 1.2.3.GA.
> We need to be able to have a more fined-grained fallback on qualifiers:
> .dev-115-maxisstupid-v12323 then
> .dev-115-maxisstupid then
> .dev-115 then
> .dev-115 then
> .dev
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22449) Better parse qualifiers for versions
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22449?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-22449:
-------------------------------------
The default test pattern needing to be changed JBIDE-19081
> Better parse qualifiers for versions
> ------------------------------------
>
> Key: JBIDE-22449
> URL: https://issues.jboss.org/browse/JBIDE-22449
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: common/jst/core
> Affects Versions: 4.4.0.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Fix For: 4.4.0.Final
>
>
> Currently, in ide-config.properties, if no 1.2.3.GA-123456-23455 version is found, we fall back to 1.2.3.GA.
> We need to be able to have a more fined-grained fallback on qualifiers:
> .dev-115-maxisstupid-v12323 then
> .dev-115-maxisstupid then
> .dev-115 then
> .dev-115 then
> .dev
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22449) Better parse qualifiers for versions
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22449?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-22449:
-------------------------------------
Damn it, I'm pretty sure this is because of that f*ing TestSuite class pattern that exclude all Tests by default
> Better parse qualifiers for versions
> ------------------------------------
>
> Key: JBIDE-22449
> URL: https://issues.jboss.org/browse/JBIDE-22449
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: common/jst/core
> Affects Versions: 4.4.0.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Fix For: 4.4.0.Final
>
>
> Currently, in ide-config.properties, if no 1.2.3.GA-123456-23455 version is found, we fall back to 1.2.3.GA.
> We need to be able to have a more fined-grained fallback on qualifiers:
> .dev-115-maxisstupid-v12323 then
> .dev-115-maxisstupid then
> .dev-115 then
> .dev-115 then
> .dev
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBTIS-732) Create a test for the new Fuse project creation wizard
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-732?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky commented on JBTIS-732:
-----------------------------------------
Verification job has failed :(
Error Message
Timeout after: 300 s.: console contains '(CamelContext: camelContext-044d8159-9950-43c0-b0a7-aa8d8b9c63ee) started'
[ERROR] Error executing Maven.
[ERROR] The specified user settings file does not exist: /home/jbossqa/workspace/jbtis43x.verification.job/tests/org.jboss.tools.fuse.ui.bot.test/target/work/data/camel-spring/resources/config/settings.xml
Stacktrace
org.jboss.reddeer.common.exception.WaitTimeoutExpiredException: Timeout after: 300 s.: console contains '(CamelContext: camelContext-044d8159-9950-43c0-b0a7-aa8d8b9c63ee) started'
[ERROR] Error executing Maven.
[ERROR] The specified user settings file does not exist: /home/jbossqa/workspace/jbtis43x.verification.job/tests/org.jboss.tools.fuse.ui.bot.test/target/work/data/camel-spring/resources/config/settings.xml
at org.jboss.reddeer.common.wait.AbstractWait.timeoutExceeded(AbstractWait.java:173)
at org.jboss.reddeer.common.wait.AbstractWait.wait(AbstractWait.java:126)
at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:91)
at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:61)
at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:46)
at org.jboss.reddeer.common.wait.WaitUntil.<init>(WaitUntil.java:37)
at org.jboss.tools.fuse.reddeer.projectexplorer.CamelProject.runCamelContextWithoutTests(CamelProject.java:128)
at org.jboss.tools.fuse.ui.bot.test.ProjectLocalRunTest.testRunProjectWithoutTests(ProjectLocalRunTest.java:141)
> Create a test for the new Fuse project creation wizard
> ------------------------------------------------------
>
> Key: JBTIS-732
> URL: https://issues.jboss.org/browse/JBTIS-732
> Project: JBoss Tools Integration Stack
> Issue Type: Task
> Components: Fuse IDE, QE
> Affects Versions: 4.3.0.Final
> Reporter: Andrej Podhradsky
> Assignee: Tomáš Sedmík
> Priority: Critical
> Fix For: 4.3.1.Final
>
>
> There is a completely new wizard for creating a Fuse project, Please create the appropriated test.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21059) Server Adapter does not connect in debug mode on WF in a Docker container
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21059?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-21059:
---------------------------------------
Hello [~rob.stryker],
First, you'll need to build an image of WildFly that has support for remote debugging. Here's what you should put in a {{Dockerfile}}:
{code}
FROM jboss/wildfly:10.0.0.Final
MAINTAINER Rob
# # expose debug and mgmt ports
EXPOSE 8787
EXPOSE 9990
# start WildFly in standalone/debug mode and allow management from host
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-c", "standalone.xml", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0" , "--debug"]
{code}
Then buid you image using the following command:
{code}
docker build -t rob/wildfly-debug:10.0.0.Final .
{code}
And finally you can run the image
{code}
docker run --name wildfly-debug -p 8787:8787 -p 8080 rob/wildfly-debug:10.0.0.Final
{code}
Then you'll have a container named {{wildfly-debug}} running on your Docker VM, and from there you can connect a remote debugger on port {{<docker_vm_IP_address>:8787}}
> Server Adapter does not connect in debug mode on WF in a Docker container
> --------------------------------------------------------------------------
>
> Key: JBIDE-21059
> URL: https://issues.jboss.org/browse/JBIDE-21059
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.0.Final
> Reporter: Xavier Coulon
> Assignee: Rob Stryker
> Fix For: 4.4.1.S116
>
>
> I have a WF 9.0.2.Final in a Docker container, started with the debug flag in the command line :
> {code}
> CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-c", "standalone.xml", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0" , "--debug"]
> {code}
> I can connect to this server from the server adapter in Run mode but not in debug mode: the Debug view remains empty and the breakpoints are not hit.
> On the other side, I can connect using the plain Java remote debugger (in the launchers) and the same breakpoints are hit.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22622) Opening the Web Console in the embedded browser (by default) results in error
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22622?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-22622:
------------------------------------
Yes, at least if external=Chrome
> Opening the Web Console in the embedded browser (by default) results in error
> -----------------------------------------------------------------------------
>
> Key: JBIDE-22622
> URL: https://issues.jboss.org/browse/JBIDE-22622
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.S116
> Reporter: Fred Bricon
> Priority: Critical
> Attachments: 2016-06-21 at 10-05-24.mp4
>
>
> The Web Console opens using whatever browser is set in Eclipse (internal by default). When using the default browser, after logging in, there's an error message stating "Server connection interrupted". This error occurs on OSX and Linux at least.
> I think the web console should be opened in the external browser in all cases.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months