[JBoss JIRA] (JBIDE-21744) cdk-created docker connection can have wrong name if you have multiple cdk server adapters
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21744?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-21744:
--------------------------------
Fix Version/s: 4.4.1.AM3
(was: 4.4.x)
> cdk-created docker connection can have wrong name if you have multiple cdk server adapters
> ------------------------------------------------------------------------------------------
>
> Key: JBIDE-21744
> URL: https://issues.jboss.org/browse/JBIDE-21744
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.1.AM3
>
>
> I noticed that if I have two cdk server adapters, start the first one, stop it, start the second, then docker explorer will only show a connection of the first server name, not the second.
> This is probably because the connection will stay there after the first server start and on second server start, the tooling only checks if the docker host url matches. If it does, it will just reuse it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22474) jboss.org.schema tasks
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22474?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-22474.
---------------------------------
Fix Version/s: 4.4.1.AM3
Resolution: Done
This seems to be fixed now. The three builds are as follows:
1) Updates the github repo periodically based on any changes to remote server from other contributers we don't control
2) A PR builder that verifies the PR can be pushed without conflict and doesn't conflict with upstream changes
3) a job responding to changes in the github repository and syncing the folder back up via rsync
> jboss.org.schema tasks
> ----------------------
>
> Key: JBIDE-22474
> URL: https://issues.jboss.org/browse/JBIDE-22474
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, server, upstream
> Affects Versions: 4.4.0.Alpha2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.1.AM3
>
>
> Since workflow is still being figured out, please see http://etherpad.corp.redhat.com/jboss-org-schema for more details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBDS-3987) CoreException below RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call (thrown in RepositoryStatusHelper.wrap)
by Marcel Bruch (JIRA)
[ https://issues.jboss.org/browse/JBDS-3987?page=com.atlassian.jira.plugin.... ]
Marcel Bruch commented on JBDS-3987:
------------------------------------
FWIW, we can add an *Ignored Status Pattern* to AERI which can filter such errors. ATM we ignore all kind of logged java.net.* exceptions. See [1] for details. We can match any triple of logging bundle, exception type and exception message. Each segment allows wildcards (*). Let me know if we should investigate this further.
[1] https://redhat.ctrlflow.com/reviewers/#!/administration/submissions
> CoreException below RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call (thrown in RepositoryStatusHelper.wrap)
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-3987
> URL: https://issues.jboss.org/browse/JBDS-3987
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: central-update
> Affects Versions: 9.1.0.GA
> Reporter: Automated Error Reporting Bot
> Assignee: Nick Boldt
> Fix For: 9.1.0.GA
>
> Attachments: Screen Shot 2016-08-08 at 9.51.05 AM.png
>
>
> The following problem was reported via the automated error reporting:
> Message: Cannot download bundle at https://devstudio.redhat.com/9.0/stable/updates/discovery.earlyaccess/9.1...: null
> {noformat}
> org.eclipse.core.runtime.CoreException:
> at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryStatusHelper.wrap(RepositoryStatusHelper.java:177)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.checkException(FileReader.java:504)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:435)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.readInto(FileReader.java:358)
> at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:101)
> at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(null:-2)
> at sun.reflect.NativeMethodAccessorImpl.invoke(null:-1)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(null:-1)
> at java.lang.reflect.Method.invoke(null:-1)
> at org.eclipse.mylyn.internal.discovery.core.util.P2TransportService.download(P2TransportService.java:84)
> at org.eclipse.mylyn.internal.discovery.core.util.WebUtil.download(WebUtil.java:157)
> at org.eclipse.mylyn.internal.discovery.core.util.WebUtil.download(WebUtil.java:66)
> at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteExternalBundleDiscoveryStrategy.java:223)
> at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteExternalBundleDiscoveryStrategy.java:1)
> at java.util.concurrent.FutureTask.run(null:-1)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(null:-1)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(null:-1)
> at java.lang.Thread.run(null:-1)
> {noformat}
> Bundles:
> | org.eclipse.equinox.p2.transport.ecf | 1.1.100.v20150521-1342 | 1.1.200.v20160606-1311 |
> | org.eclipse.mylyn.discovery.core | 3.7.1.v20120425-0100 | 3.20.2.v20160630-1640 |
> | org.eclipse.oomph.p2.core | 1.1.0.v20150610-1534 | 1.4.0.v20160606-0856 |
> | org.jboss.tools.discovery.core | 1.0.1.Final-v20160401-1059-B103 | 1.1.0.Final-v20160613-2000-B8 |
> Operating Systems:
> | Linux | 3.0.101 | 4.6.3.fc24 |
> | MacOSX | 10.11.4 | 10.11.4 |
> | Windows | 6.1.0 | 10.0.0 |
> The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/5718e82fe4b0cd449c...] for the latest data.
> Thank you for your assistance.
> Your friendly error-reports-inbox.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22911) Exception below RenameMethodParticipant$RenameMethodSearcher.outOfSynch (thrown in Thread.getStackTrace)
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22911?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich edited comment on JBIDE-22911 at 8/9/16 2:27 PM:
-----------------------------------------------------------------------
The logged error is the expected result as of JBIDE-13695.
I cannot understand why the behaviour of the rename searcher is implemented differently for JSF method than for other JBoss Tools components:
CDI, EL, Seam: Adds a warning.
JSF: Logs an error.
The implementation of outOfSync reporting method:
{code}
@Override
protected void outOfSynch(IResource resource){
//status.addWarning(NLS.bind(JsfUIMessages.RENAME_METHOD_PARTICIPANT_OUT_OF_SYNC_PROJECT, project.getFullPath().toString()));
Exception exception= new Exception(NLS.bind(JsfUIMessages.RENAME_METHOD_PARTICIPANT_OUT_OF_SYNC_PROJECT, resource.getFullPath().toString()));
exception.setStackTrace(Thread.currentThread().getStackTrace());
JsfUiPlugin.getDefault().logError(exception);
}
{code}
Note the commented line, it would add a warning as in other JBoss Tools components. Then why is logging preferred that looks like an error on the part of JBoss Tools when the matter is just a state of the project. User, seeing errors in log usually reports them as bugs of the product rather then takes them as a clue for fixing bugs in his application.
Changes in JBIDE-13695 replace in ELRenameProcessor (jsf), SeamRenameProcessor and CDIRenameProcessor status.addFatalError by status.addWarning, but in RenameMethodParticipant, the same change is commented and logging is added. Why? Could there be some specific reason for it?
[~akazakov], can we here add a warning (uncomment the first line), as everywhere else, instead of logging an error?
was (Author: scabanovich):
The logged error is the expected result as of JBIDE-13695.
I cannot understand why the behaviour of the rename searcher is implemented differently for JSF method than for other JBoss Tools components:
CDI, EL, Seam: Adds a warning.
JSF: Logs an error.
The implementation of outOfSync reporting method:
{code}
@Override
protected void outOfSynch(IResource resource){
//status.addWarning(NLS.bind(JsfUIMessages.RENAME_METHOD_PARTICIPANT_OUT_OF_SYNC_PROJECT, project.getFullPath().toString()));
Exception exception= new Exception(NLS.bind(JsfUIMessages.RENAME_METHOD_PARTICIPANT_OUT_OF_SYNC_PROJECT, resource.getFullPath().toString()));
exception.setStackTrace(Thread.currentThread().getStackTrace());
JsfUiPlugin.getDefault().logError(exception);
}
{code}
Note the commented line, it would add a warning as in other JBoss Tools components. Then why is logging preferred that looks like an error on the part of JBoss Tools when the matter is just a state of the project. User, seeing errors in log usually reports them as bugs of the product rather then takes them as a clue for fixing bugs in his application. [~akazakov], can we here add a warning (uncomment the first line) instead of logging an error?
> Exception below RenameMethodParticipant$RenameMethodSearcher.outOfSynch (thrown in Thread.getStackTrace)
> --------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-22911
> URL: https://issues.jboss.org/browse/JBIDE-22911
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.3.1.Final
> Reporter: Automated Error Reporting Bot
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.x
>
>
> The following problem was reported via the automated error reporting:
> Message: HIDDEN
> {noformat}
> java.lang.Exception: HIDDEN
> at java.lang.Thread.getStackTrace(null:-1)
> at org.jboss.tools.jsf.ui.el.refactoring.RenameMethodParticipant$RenameMethodSearcher.outOfSynch(RenameMethodParticipant.java:145)
> at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.scanProject(RefactorSearcher.java:148)
> at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.scanProject(RefactorSearcher.java:108)
> at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.findELReferences(RefactorSearcher.java:166)
> at org.jboss.tools.jsf.ui.el.refactoring.RenameMethodParticipant.checkConditions(RenameMethodParticipant.java:58)
> at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:257)
> at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:162)
> at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:80)
> at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
> at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:729)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241)
> at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5409)
> at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
> {noformat}
> Bundles:
> | org.eclipse.core.resources | 3.10.1.v20150725-1910 | 3.11.0.v20160503-1608 |
> | org.eclipse.jdt.core | 3.11.0.xx-201604081629-e45 | 3.12.0.v20160516-2131 |
> | org.eclipse.jdt.ui | 3.11.2.v20151123-1510 | 3.12.0.v20160525-1829 |
> | org.eclipse.jface | 3.11.1.v20160128-1644 | 3.12.0.v20160518-1929 |
> | org.eclipse.ltk.core.refactoring | 3.6.201.v20150819-1034 | 3.7.0.v20160419-0705 |
> | org.eclipse.ltk.ui.refactoring | 3.7.200.v20140625-1835 | 3.7.200.v20140625-1835 |
> | org.jboss.tools.jsf.ui | 3.7.1.Final-v20160330-2256-B84 | 3.8.0.Final-v20160610-0126-B1 |
> | org.jboss.tools.jst.web.kb | 3.7.1.Final-v20160331-0256-B96 | 3.8.0.Final-v20160609-2146-B2 |
> Operating Systems:
> | Linux | 3.19.0 | 4.2.0 |
> | MacOSX | 10.11.4 | 10.11.4 |
> | Windows | 6.1.0 | 10.0.0 |
> The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/5730baa5e4b0ba8b6a...] for the latest data.
> Thank you for your assistance.
> Your friendly error-reports-inbox.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22911) Exception below RenameMethodParticipant$RenameMethodSearcher.outOfSynch (thrown in Thread.getStackTrace)
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22911?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-22911:
-----------------------------------------------
The logged error is the expected result as of JBIDE-13695.
I cannot understand why the behaviour of the rename searcher is implemented differently for JSF method than for other JBoss Tools components:
CDI, EL, Seam: Adds a warning.
JSF: Logs an error.
The implementation of outOfSync reporting method:
{code}
@Override
protected void outOfSynch(IResource resource){
//status.addWarning(NLS.bind(JsfUIMessages.RENAME_METHOD_PARTICIPANT_OUT_OF_SYNC_PROJECT, project.getFullPath().toString()));
Exception exception= new Exception(NLS.bind(JsfUIMessages.RENAME_METHOD_PARTICIPANT_OUT_OF_SYNC_PROJECT, resource.getFullPath().toString()));
exception.setStackTrace(Thread.currentThread().getStackTrace());
JsfUiPlugin.getDefault().logError(exception);
}
{code}
Note the commented line, it would add a warning as in other JBoss Tools components. Then why is logging preferred that looks like an error on the part of JBoss Tools when the matter is just a state of the project. User, seeing errors in log usually reports them as bugs of the product rather then takes them as a clue for fixing bugs in his application. [~akazakov], can we here add a warning (uncomment the first line) instead of logging an error?
> Exception below RenameMethodParticipant$RenameMethodSearcher.outOfSynch (thrown in Thread.getStackTrace)
> --------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-22911
> URL: https://issues.jboss.org/browse/JBIDE-22911
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.3.1.Final
> Reporter: Automated Error Reporting Bot
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.x
>
>
> The following problem was reported via the automated error reporting:
> Message: HIDDEN
> {noformat}
> java.lang.Exception: HIDDEN
> at java.lang.Thread.getStackTrace(null:-1)
> at org.jboss.tools.jsf.ui.el.refactoring.RenameMethodParticipant$RenameMethodSearcher.outOfSynch(RenameMethodParticipant.java:145)
> at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.scanProject(RefactorSearcher.java:148)
> at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.scanProject(RefactorSearcher.java:108)
> at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.findELReferences(RefactorSearcher.java:166)
> at org.jboss.tools.jsf.ui.el.refactoring.RenameMethodParticipant.checkConditions(RenameMethodParticipant.java:58)
> at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:257)
> at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:162)
> at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:80)
> at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
> at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:729)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241)
> at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5409)
> at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
> {noformat}
> Bundles:
> | org.eclipse.core.resources | 3.10.1.v20150725-1910 | 3.11.0.v20160503-1608 |
> | org.eclipse.jdt.core | 3.11.0.xx-201604081629-e45 | 3.12.0.v20160516-2131 |
> | org.eclipse.jdt.ui | 3.11.2.v20151123-1510 | 3.12.0.v20160525-1829 |
> | org.eclipse.jface | 3.11.1.v20160128-1644 | 3.12.0.v20160518-1929 |
> | org.eclipse.ltk.core.refactoring | 3.6.201.v20150819-1034 | 3.7.0.v20160419-0705 |
> | org.eclipse.ltk.ui.refactoring | 3.7.200.v20140625-1835 | 3.7.200.v20140625-1835 |
> | org.jboss.tools.jsf.ui | 3.7.1.Final-v20160330-2256-B84 | 3.8.0.Final-v20160610-0126-B1 |
> | org.jboss.tools.jst.web.kb | 3.7.1.Final-v20160331-0256-B96 | 3.8.0.Final-v20160609-2146-B2 |
> Operating Systems:
> | Linux | 3.19.0 | 4.2.0 |
> | MacOSX | 10.11.4 | 10.11.4 |
> | Windows | 6.1.0 | 10.0.0 |
> The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/5730baa5e4b0ba8b6a...] for the latest data.
> Thank you for your assistance.
> Your friendly error-reports-inbox.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBDS-3987) CoreException below RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call (thrown in RepositoryStatusHelper.wrap)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3987?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3987:
----------------------------------
[~fbricon] We could consider trapping this error and just notifying the user that they're offline or firewall/proxy/vpn-blocked:
{code}
at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteExternalBundleDiscoveryStrategy.java:223)
at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteExternalBundleDiscoveryStrategy.java:1)
{code}
Then it wouldn't flow up the chain to AERI and clog the pipes with duplicate "your hovercraft is full of eels / your inter-tubes are blocked" errors.
> CoreException below RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call (thrown in RepositoryStatusHelper.wrap)
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-3987
> URL: https://issues.jboss.org/browse/JBDS-3987
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: central-update
> Affects Versions: 9.1.0.GA
> Reporter: Automated Error Reporting Bot
> Assignee: Nick Boldt
> Fix For: 9.1.0.GA
>
> Attachments: Screen Shot 2016-08-08 at 9.51.05 AM.png
>
>
> The following problem was reported via the automated error reporting:
> Message: Cannot download bundle at https://devstudio.redhat.com/9.0/stable/updates/discovery.earlyaccess/9.1...: null
> {noformat}
> org.eclipse.core.runtime.CoreException:
> at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryStatusHelper.wrap(RepositoryStatusHelper.java:177)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.checkException(FileReader.java:504)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:435)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.readInto(FileReader.java:358)
> at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:101)
> at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(null:-2)
> at sun.reflect.NativeMethodAccessorImpl.invoke(null:-1)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(null:-1)
> at java.lang.reflect.Method.invoke(null:-1)
> at org.eclipse.mylyn.internal.discovery.core.util.P2TransportService.download(P2TransportService.java:84)
> at org.eclipse.mylyn.internal.discovery.core.util.WebUtil.download(WebUtil.java:157)
> at org.eclipse.mylyn.internal.discovery.core.util.WebUtil.download(WebUtil.java:66)
> at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteExternalBundleDiscoveryStrategy.java:223)
> at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteExternalBundleDiscoveryStrategy.java:1)
> at java.util.concurrent.FutureTask.run(null:-1)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(null:-1)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(null:-1)
> at java.lang.Thread.run(null:-1)
> {noformat}
> Bundles:
> | org.eclipse.equinox.p2.transport.ecf | 1.1.100.v20150521-1342 | 1.1.200.v20160606-1311 |
> | org.eclipse.mylyn.discovery.core | 3.7.1.v20120425-0100 | 3.20.2.v20160630-1640 |
> | org.eclipse.oomph.p2.core | 1.1.0.v20150610-1534 | 1.4.0.v20160606-0856 |
> | org.jboss.tools.discovery.core | 1.0.1.Final-v20160401-1059-B103 | 1.1.0.Final-v20160613-2000-B8 |
> Operating Systems:
> | Linux | 3.0.101 | 4.6.3.fc24 |
> | MacOSX | 10.11.4 | 10.11.4 |
> | Windows | 6.1.0 | 10.0.0 |
> The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/5718e82fe4b0cd449c...] for the latest data.
> Thank you for your assistance.
> Your friendly error-reports-inbox.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22913) Server Adapter: Publish does not work
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22913?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-22913:
------------------------------------
Looking at build B5730 (http://www.qa.jboss.com/binaries/devstudio/10.0/snapshots/builds/devstudi...), I noticed org.jboss.tools.openshift.client version is 3.3.0.v20160726-1305 which does not look good for me. [~nickboldt] can you check ?
> Server Adapter: Publish does not work
> -------------------------------------
>
> Key: JBIDE-22913
> URL: https://issues.jboss.org/browse/JBIDE-22913
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Priority: Blocker
> Labels: openshift_v3, server_adapter_wizard
>
> When I create a new OpenShift 3 server adapter with already running application pod, I get following error in error dialog and initial publish does not work. Autopublish does not work at all and also manual triggering of publishment throws same error.
> {code}
> Could not sync /home/mlabuda/workspaces/0804/.metadata/.plugins/org.jboss.ide.eclipse.as.core/projectname000@eap-app/deploy to all pods running the service eap-app
> OpenShiftBinaryCapability process exited: WARNING: rsync command not found in path. Please use your package manager to install it.
> Ignoring the following flags because they only apply to rsync: --exclude, --no-perms
> tar: ROOT.war/META-INF/MANIFEST.MF: Cannot open: Not a directory
> tar: ROOT.war/META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink/pom.properties: Cannot open: Not a directory
> tar: ROOT.war/META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink/pom.xml: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/beans.xml: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/META-INF/persistence.xml: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/import.sql: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/org/jboss/as/quickstarts/kitchensink/controller/MemberController.class: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/org/jboss/as/quickstarts/kitchensink/data/MemberListProducer.class: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/org/jboss/as/quickstarts/kitchensink/data/MemberRepository.class: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/org/jboss/as/quickstarts/kitchensink/model/Member.class: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/org/jboss/as/quickstarts/kitchensink/rest/JaxRsActivator.class: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/org/jboss/as/quickstarts/kitchensink/rest/MemberResourceRESTService.class: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/org/jboss/as/quickstarts/kitchensink/service/MemberRegistration.class: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/classes/org/jboss/as/quickstarts/kitchensink/util/Resources.class: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/faces-config.xml: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/kitchensink-quickstart-ds.xml: Cannot open: Not a directory
> tar: ROOT.war/WEB-INF/templates/default.xhtml: Cannot open: Not a directory
> tar: ROOT.war/index.html: Cannot open: Not a directory
> tar: ROOT.war/index.xhtml: Cannot open: Not a directory
> tar: ROOT.war/resources/css/screen.css: Cannot open: Not a directory
> tar: ROOT.war/resources/gfx/asidebkg.png: Cannot open: Not a directory
> tar: ROOT.war/resources/gfx/banner.png: Cannot open: Not a directory
> tar: ROOT.war/resources/gfx/bkg-blkheader.png: Cannot open: Not a directory
> tar: ROOT.war/resources/gfx/headerbkg.png: Cannot open: Not a directory
> tar: ROOT.war/resources/gfx/rhjb_eap_logo.png: Cannot open: Not a directory
> tar: Exiting with failure status due to previous errors
> error: error extracting tar at destination directory: error executing remote command: Error executing command in container: Error executing in Docker Container: 2
> {code}
> I have installed rsync rsync-3.1.2-2.fc24.x86_64. I tried oc binary 1.2.0. and also 1.2.1. Issue describes not found rsync on PATH, although it is present there.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months