[JBoss JIRA] (JBIDE-21107) SeamEARTest.testEarProject fails
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21107?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-21107.
---------------------------------
Java EE build in master is blue, so closing.
> SeamEARTest.testEarProject fails
> --------------------------------
>
> Key: JBIDE-21107
> URL: https://issues.jboss.org/browse/JBIDE-21107
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: seam2
> Affects Versions: 4.3.0.Final
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.0.Alpha1
>
>
> The check for component "org.jboss.seam.core.interpolator" has been failing every now and then for years, though the case works ok in studio. It remains a challenge to understand what is going wrong with the build in this particular case, but since Seam is not supported any more, we should better just exclude the check.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBDS-3953) JBoss Studio Developer crash at startup on Fedora 24
by Donato Marrazzo (JIRA)
Donato Marrazzo created JBDS-3953:
-------------------------------------
Summary: JBoss Studio Developer crash at startup on Fedora 24
Key: JBDS-3953
URL: https://issues.jboss.org/browse/JBDS-3953
Project: Red Hat JBoss Developer Studio (devstudio)
Issue Type: Bug
Affects Versions: 9.1.0.GA
Environment: Fedora 24
openjdk full version "1.8.0_92-b14"
Reporter: Donato Marrazzo
Priority: Blocker
Attachments: hs_err_pid12689.log
After installation, as I launch JBS, it just display the eclipse workbench for few second that it crash.
Despite the console message, no core dump is generated.
This is the cmd line output:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [bundleresource://1072.fwk923366543:1/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [bundleresource://1072.fwk923366543:2/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
14:09:55.604 [Worker-2] DEBUG o.e.m.c.i.p.r.ProjectRegistryRefreshJob - Queued refresh request: [/RemoteSystemsTempFiles/pom.xml]
openjdk version "1.8.0_92"
OpenJDK Runtime Environment (build 1.8.0_92-b14)
OpenJDK 64-Bit Server VM (build 25.92-b14, mixed mode)
14:09:57.115 [Worker-14] DEBUG o.e.a.i.i.DefaultLocalRepositoryProvider - Using manager EnhancedLocalRepositoryManager with priority 10.0 for /home/donato/.m2/repository
14:09:57.142 [Worker-14] DEBUG o.e.a.i.i.DefaultLocalRepositoryProvider - Using manager EnhancedLocalRepositoryManager with priority 10.0 for /home/donato/.m2/repository
14:09:57.143 [Worker-14] DEBUG o.e.m.c.i.p.r.ProjectRegistryManager - Refreshing: [L/RemoteSystemsTempFiles/pom.xml]
14:09:57.156 [Worker-14] DEBUG o.e.m.c.i.p.r.ProjectRegistryManager - Refreshed: [L/RemoteSystemsTempFiles/pom.xml]
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f521a6d7bfe, pid=12689, tid=0x00007f52cf5a3700
#
# JRE version: OpenJDK Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
# Java VM: OpenJDK 64-Bit Server VM (25.92-b14 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libjavascriptcoregtk-3.0.so.0+0x4d4bfe] JSC::VM::throwException(JSC::ExecState*, JSC::JSValue)+0x236e
#
# Core dump written. Default location: /home/donato/core or core.12689
#
# An error report file with more information is saved as:
# /home/donato/hs_err_pid12689.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21213) Create a credentialing framework
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21213?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-21213.
---------------------------------
This is clearly done. Closing.
> Create a credentialing framework
> --------------------------------
>
> Key: JBIDE-21213
> URL: https://issues.jboss.org/browse/JBIDE-21213
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: common/jst/core
> Affects Versions: 4.3.0.Final
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.0.Alpha1
>
>
> There should be a unified framework for storing credentials to various domains. As of now, download runtimes (in astools) requires redhat or jboss credentials, and I've heard that others are also storing the credentials for some of those domains as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21877) Connection wizard: Make error message shown in OpenShift Explorer for outdated token more user friendly
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21877?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-21877:
------------------------------------
I can reproduce this behaviour.
What I have done:
1) CLI oc login
2) CLI oc whoami -t -> retrieve the token
3) Devstudio update the connection to use this token and oauth
3) cli oc logout
4) relaunch Devstudio
5) expand in Openshift explorer the connection and I got a dialog with the token cleared
!screenshot-1.png!
> 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-21877) Connection wizard: Make error message shown in OpenShift Explorer for outdated token more user friendly
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21877?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-21877:
-------------------------------
Attachment: screenshot-1.png
> 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-22603) Sometimes multiple OpenShift watch managers are periodically created and finished
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22603?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-22603:
----------------------------------
Priority: Critical (was: Major)
> Sometimes multiple OpenShift watch managers are periodically created and finished
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-22603
> URL: https://issues.jboss.org/browse/JBIDE-22603
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Marián Labuda
> Priority: Critical
> Labels: explorer, openshift_v3
> Attachments: watchers.png
>
>
> Sometimes when I am working with OpenShift toolings, there are created multiple OpenShift Watch Managers which are getting finished, disappearing from Progress view and another new ones are created and this repeats nonstop. Sometimes there are 2-3 running, sometimes even more. I am working with openshift-dev user, where is visible default project (still, until patch in upstream get effect) and my own project with application created from eap 6.4 basic s2i template.
> !watchers.png!
> It would not be a problem but I have a hunch it is the problem breaking automatic update of OpenShift explorer view to reflect current state and existence of resources on OpenShift server. E.g. under a service there is build table visible all the time and no application pod is shown, even build is finished and there is an application pod running on OpenShift. Another example when it is not working is when I am scaling application up/down - it does not reflect real amount of application pods.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22609) Provided wrong credentials, CDK server adapter says "started" even though it is not.
by Radim Hopp (JIRA)
Radim Hopp created JBIDE-22609:
----------------------------------
Summary: Provided wrong credentials, CDK server adapter says "started" even though it is not.
Key: JBIDE-22609
URL: https://issues.jboss.org/browse/JBIDE-22609
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdk
Affects Versions: 4.4.0.Final
Environment: Devstudio 10.0.0.GA (B33), CDK 2.1.RC4, Windows 10
Reporter: Radim Hopp
Priority: Critical
When CDK startup fails when it is provided wrong credentials (it fails on vagrant-registration), CDK server adapter sets its state to "started" and OS3 connection is created (even though OS3 is not running in vagrant) with some weird IP (10.0.2.15). Also error pops up saying "The CDK VM is up and running, but OpenShift is unreachable at url https://10.0.2.15:8443/healthz/ready". I really don't know where this IP comes from. I was able to reproduce it on Fedora using libvirt box and the IP was something like (192.168.x.x)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22305) automate process for fetching latest target platform mirrors
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22305?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-22305:
----------------------------------------
Sprint: devex #115 May 2016, devex #116 June 2016 (was: devex #115 May 2016)
> automate process for fetching latest target platform mirrors
> ------------------------------------------------------------
>
> Key: JBIDE-22305
> URL: https://issues.jboss.org/browse/JBIDE-22305
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform, updatesite, upstream
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: releasework
> Fix For: 4.4.1.Alpha1
>
> Attachments: git.diff.txt
>
>
> Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names.
> Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace.
> Thus for webtools we might simply define:
> webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do...
> and we'd end up with:
> http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8....
> * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr
> 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p...
> 2. when all children are done, a downstream job can runs TP update & validation against new .target files
> * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf...
> * parse that into a list of URLs
> * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files
> * run p2diff between old/new URLs in .target to generate list of changes and verify new site contains all the same IUs
> * resulting edited .target files will remain in the workspace, and we can then run
> * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u...
> * when done if success:
> * ideally, generate a PR and attach link in email to jbosstools-dev@
> * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR
> * email should includes boilerplate text to send mail to list announcing new change for review
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBDS-3605) Rebranding to developers.redhat.com
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3605?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3605:
-----------------------------
Target Release: (was: )
> Rebranding to developers.redhat.com
> -----------------------------------
>
> Key: JBDS-3605
> URL: https://issues.jboss.org/browse/JBDS-3605
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Epic
> Components: installer, p2-product
> Reporter: Max Rydahl Andersen
> Assignee: Catherine Robson
> Priority: Blocker
> Fix For: 10.0.0.Alpha1
>
> Attachments: about-jbds10.png, Additional_RHDS_Branding.zip, edit-eap-icon-in-ds10-installer.png, gettingstarted.png, gs_nav.png, header-jbds10-installer.png, icns.zip, jbds_uninstall.ico, jbeap_edit_wiz.png, jbeap_new_wiz.png, new-eap-icon-in-ds10-installer.png, RedHatDevelopersStudio_SplashScreen.zip, RedHatDeveloperStudio-Branding_Final_2016-03-16.pdf, RedHatDeveloperStudio_BrandingDeliverables.zip, RevisedIcons.zip, splash-jbds10.png
>
>
> Developer Studio, Central and any related installers, website content etc. is requested to be rebranded under http://developers.redhat.com.
> The visual name will change but for JBDS 9.1 we will not change things that risk breaking functionallity (i.e. changing the binary from jbds to rhds will potentially break update path, ini and p2 update mechanisms)
> Thus changing about screen, splash screens etc. are the target - more deeper rebranding will be done in future and on a case-by-base basis if at all necessary.
>
> This jira will be the epic where we add related issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBDS-3605) Rebranding to developers.redhat.com
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3605?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-3605:
--------------------------------------
Sprint: devex #113 April 2016, devex #115 May 2016, devex #116 June 2016 (was: devex #113 April 2016, devex #115 May 2016)
> Rebranding to developers.redhat.com
> -----------------------------------
>
> Key: JBDS-3605
> URL: https://issues.jboss.org/browse/JBDS-3605
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Epic
> Components: installer, p2-product
> Reporter: Max Rydahl Andersen
> Assignee: Catherine Robson
> Priority: Blocker
> Fix For: 10.0.0.Alpha1
>
> Attachments: about-jbds10.png, Additional_RHDS_Branding.zip, edit-eap-icon-in-ds10-installer.png, gettingstarted.png, gs_nav.png, header-jbds10-installer.png, icns.zip, jbds_uninstall.ico, jbeap_edit_wiz.png, jbeap_new_wiz.png, new-eap-icon-in-ds10-installer.png, RedHatDevelopersStudio_SplashScreen.zip, RedHatDeveloperStudio-Branding_Final_2016-03-16.pdf, RedHatDeveloperStudio_BrandingDeliverables.zip, RevisedIcons.zip, splash-jbds10.png
>
>
> Developer Studio, Central and any related installers, website content etc. is requested to be rebranded under http://developers.redhat.com.
> The visual name will change but for JBDS 9.1 we will not change things that risk breaking functionallity (i.e. changing the binary from jbds to rhds will potentially break update path, ini and p2 update mechanisms)
> Thus changing about screen, splash screens etc. are the target - more deeper rebranding will be done in future and on a case-by-base basis if at all necessary.
>
> This jira will be the epic where we add related issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months