[JBoss JIRA] (JBIDE-26324) Port forwarding failed for JBoss Tools 4.6.0.Final
by Junqi Zhao (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26324?page=com.atlassian.jira.plugi... ]
Junqi Zhao updated JBIDE-26324:
-------------------------------
Description:
Port forwarding failed for JBoss Tools 4.6.0.Final
error is in the followings, the failed reason is flag "-p" is deprecated
An internal error occurred during: "Starting port forwarding...".
OpenShiftBinaryCapability process exited: Error: unknown shorthand flag: 'p' in -p
Usage:
oc port-forward TYPE/NAME [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]
Examples:
# Listens on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
oc port-forward mypod 5000 6000
# Listens on port 8888 locally, forwarding to 5000 in the pod
oc port-forward mypod 8888:5000
# Listens on a random port locally, forwarding to 5000 in the pod
oc port-forward mypod :5000
# Listens on a random port locally, forwarding to 5000 in the pod
oc port-forward mypod 0:5000
Options:
--pod-running-timeout=1m0s: The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running
Use "oc options" for a list of global command-line options (applies to all commands).
was:
Port forwarding failed for JBoss Tools 4.6.0.Final
error is in the followings, flag "-p" is deprecated
An internal error occurred during: "Starting port forwarding...".
OpenShiftBinaryCapability process exited: Error: unknown shorthand flag: 'p' in -p
Usage:
oc port-forward TYPE/NAME [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]
Examples:
# Listens on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
oc port-forward mypod 5000 6000
# Listens on port 8888 locally, forwarding to 5000 in the pod
oc port-forward mypod 8888:5000
# Listens on a random port locally, forwarding to 5000 in the pod
oc port-forward mypod :5000
# Listens on a random port locally, forwarding to 5000 in the pod
oc port-forward mypod 0:5000
Options:
--pod-running-timeout=1m0s: The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running
Use "oc options" for a list of global command-line options (applies to all commands).
> Port forwarding failed for JBoss Tools 4.6.0.Final
> --------------------------------------------------
>
> Key: JBIDE-26324
> URL: https://issues.jboss.org/browse/JBIDE-26324
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.6.0.Final
> Environment: JBoss Tools 4.6.0.Final
> $ oc version
> oc v3.11.0-0.24.0
> kubernetes v1.11.0+d4cacc0
> features: Basic-Auth GSSAPI Kerberos SPNEGO
> Reporter: Junqi Zhao
> Attachments: port_forward.png
>
>
> Port forwarding failed for JBoss Tools 4.6.0.Final
> error is in the followings, the failed reason is flag "-p" is deprecated
> An internal error occurred during: "Starting port forwarding...".
> OpenShiftBinaryCapability process exited: Error: unknown shorthand flag: 'p' in -p
> Usage:
> oc port-forward TYPE/NAME [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]
> Examples:
> # Listens on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
> oc port-forward mypod 5000 6000
>
> # Listens on port 8888 locally, forwarding to 5000 in the pod
> oc port-forward mypod 8888:5000
>
> # Listens on a random port locally, forwarding to 5000 in the pod
> oc port-forward mypod :5000
>
> # Listens on a random port locally, forwarding to 5000 in the pod
> oc port-forward mypod 0:5000
> Options:
> --pod-running-timeout=1m0s: The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running
> Use "oc options" for a list of global command-line options (applies to all commands).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (JBIDE-26324) Port forwarding failed for JBoss Tools 4.6.0.Final
by Junqi Zhao (JIRA)
Junqi Zhao created JBIDE-26324:
----------------------------------
Summary: Port forwarding failed for JBoss Tools 4.6.0.Final
Key: JBIDE-26324
URL: https://issues.jboss.org/browse/JBIDE-26324
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.6.0.Final
Environment: JBoss Tools 4.6.0.Final
$ oc version
oc v3.11.0-0.24.0
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO
Reporter: Junqi Zhao
Attachments: port_forward.png
Port forwarding failed for JBoss Tools 4.6.0.Final
error is in the followings, flag "-p" is deprecated
An internal error occurred during: "Starting port forwarding...".
OpenShiftBinaryCapability process exited: Error: unknown shorthand flag: 'p' in -p
Usage:
oc port-forward TYPE/NAME [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]
Examples:
# Listens on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
oc port-forward mypod 5000 6000
# Listens on port 8888 locally, forwarding to 5000 in the pod
oc port-forward mypod 8888:5000
# Listens on a random port locally, forwarding to 5000 in the pod
oc port-forward mypod :5000
# Listens on a random port locally, forwarding to 5000 in the pod
oc port-forward mypod 0:5000
Options:
--pod-running-timeout=1m0s: The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running
Use "oc options" for a list of global command-line options (applies to all commands).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ERT-664) Orca and flat review problems [EBZ#536974]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-664:
---------------------------------------
Summary: Orca and flat review problems [EBZ#536974]
Key: ERT-664
URL: https://issues.jboss.org/browse/ERT-664
Project: Eclipse Release Train
Issue Type: Task
Components: Platform
Reporter: Friendly Jira Robot
I can not read information present in the screen using flat review mode.
The problem can be reproduced in various parts such as in the
editor, in the package explorer, project explorer and etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ERT-663) Display.getClientArea() includes toolbar on Linux [EBZ#33659]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-663:
---------------------------------------
Summary: Display.getClientArea() includes toolbar on Linux [EBZ#33659]
Key: ERT-663
URL: https://issues.jboss.org/browse/ERT-663
Project: Eclipse Release Train
Issue Type: Task
Components: Platform
Reporter: Friendly Jira Robot
20030227
The client area on Linux Motif also includes the toolbar whereas on other
playforms it doesn't.
STEPS
1) Set you display to 1024 x 768
2) Execute Display.getClientArea()
3) Value us 1024,768
4) Switch to XP
5) Execute Display.getClientArea()
6) Value us 1024,738
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (JBIDE-26304) File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26304?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-26304:
-------------------------------------
Description:
JBIDE-22138 reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
While implementing it we discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
h2. Steps:
I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
# ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
# ASSERT: Initially I have
{code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
deploy-name="hello"
{code}.
# ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
# EXEC: I go project preferences > Maven and choose the "openshift" profile
# ASSERT: I see component settings being updated on disk.
{code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
deploy-name="ROOT"
{code}.
# RESULT: the configured module for my OpenShift server adapter is still called *hello*.
# ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
# EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
# RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
h2. Fix:
To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
{code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
protected void cleanAllDelegates() {
Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
while(i.hasNext()) {
i.next().clearCache();
}
+ clearModuleCache();
modulesChanged();
}
+ @Override
+ public void clearModuleCache() {
+ clearCache(null);
+ }
{code}
ps. notice the oddness in terms of API:
{code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
was:
JBIDE-22138 was reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
While implementing it was discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
h2. Steps:
I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
# ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
# ASSERT: Initially I have
{code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
deploy-name="hello"
{code}.
# ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
# EXEC: I go project preferences > Maven and choose the "openshift" profile
# ASSERT: I see component settings being updated on disk.
{code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
deploy-name="ROOT"
{code}.
# RESULT: the configured module for my OpenShift server adapter is still called *hello*.
# ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
# EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
# RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
h2. Fix:
To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
{code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
protected void cleanAllDelegates() {
Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
while(i.hasNext()) {
i.next().clearCache();
}
+ clearModuleCache();
modulesChanged();
}
+ @Override
+ public void clearModuleCache() {
+ clearCache(null);
+ }
{code}
ps. notice the oddness in terms of API:
{code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
> File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
> ----------------------------------------------------------------------
>
> Key: JBIDE-26304
> URL: https://issues.jboss.org/browse/JBIDE-26304
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.9.0.AM3
> Reporter: Andre Dietisheim
> Fix For: 4.9.0.AM3
>
>
> JBIDE-22138 reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
> While implementing it we discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
> We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
> h2. Steps:
> I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
> The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
> # ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
> # ASSERT: Initially I have
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="hello"
> {code}.
> # ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
> # EXEC: I go project preferences > Maven and choose the "openshift" profile
> # ASSERT: I see component settings being updated on disk.
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="ROOT"
> {code}.
> # RESULT: the configured module for my OpenShift server adapter is still called *hello*.
> # ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
> # EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
> # RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
> h2. Fix:
> To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
> {code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
> protected void cleanAllDelegates() {
> Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
> while(i.hasNext()) {
> i.next().clearCache();
> }
> + clearModuleCache();
> modulesChanged();
> }
> + @Override
> + public void clearModuleCache() {
> + clearCache(null);
> + }
> {code}
> ps. notice the oddness in terms of API:
> {code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (JBIDE-26304) File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26304?page=com.atlassian.jira.plugi... ]
Andre Dietisheim reassigned JBIDE-26304:
----------------------------------------
Assignee: Andre Dietisheim
> File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
> ----------------------------------------------------------------------
>
> Key: JBIDE-26304
> URL: https://issues.jboss.org/browse/JBIDE-26304
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.9.0.AM3
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.9.0.AM3
>
>
> JBIDE-22138 reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
> While implementing it we discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
> We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
> h2. Steps:
> I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
> The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
> # ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
> # ASSERT: Initially I have
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="hello"
> {code}.
> # ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
> # EXEC: I go project preferences > Maven and choose the "openshift" profile
> # ASSERT: I see component settings being updated on disk.
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="ROOT"
> {code}.
> # RESULT: the configured module for my OpenShift server adapter is still called *hello*.
> # ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
> # EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
> # RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
> h2. Fix:
> To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
> {code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
> protected void cleanAllDelegates() {
> Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
> while(i.hasNext()) {
> i.next().clearCache();
> }
> + clearModuleCache();
> modulesChanged();
> }
> + @Override
> + public void clearModuleCache() {
> + clearCache(null);
> + }
> {code}
> ps. notice the oddness in terms of API:
> {code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months