[JBoss JIRA] (JBIDE-25700) Server adapter: hot deploy of Spring Boot errors with permission issues when rsyncing local->pod (OS Online and CDK)
by Andre Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-25700?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25700:
------------------------------------------
[~jkopriva] [~odockal] I think that you verified this but just didn't close it. Correct?
> Server adapter: hot deploy of Spring Boot errors with permission issues when rsyncing local->pod (OS Online and CDK)
> --------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-25700
> URL: https://issues.jboss.org/browse/JBIDE-25700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.2.Final
> Reporter: Aurélien Pupier
> Assignee: Andre Dietisheim
> Priority: Major
> Labels: server_adapter, springboot, upstream
> Fix For: 4.9.0.AM1
>
> Attachments: permission-error-rsync-fc26.png, server-adapter-rebublish-state.png
>
>
> neither with open.paas.redhat.com
> so only when using the CDK.
> it seems to be due to the fact that the user in the pod are not the same.
> Jeff said:
> {quote}
> For SpringBoot deployments, the application file is called a fat jar and it placed in the /deployments folder (images are upstream fabric8/s2i-java or imagestream redhat-openjdk18-openshift). In order to get live update the file is then unzipped to the /deployments folder leaded to new sub folders BOOT-INF and META-INF
> The user permissions on those folders are the following:
> /deployments: writable by user jboss and group root
> /deployments/BOOT-INF: writable by user jboss readable only by group root
> /deployments/META-INF: writable by user jboss readable only by group root
> The rsync process with create some sub folders under /deployments/BOOT-INF. The problem that we have is that the user that is assigned for the rsync operation (or when you open a terminal in the OpenShift console) is not jboss (as opposed to Minishift/CDK) and thus we have permissions errors during the rsync operation.
> {quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (JBIDE-26160) Server Adapter: erroneously stays in [Debugging] when you kill the pod
by Andre Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26160?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-26160:
-------------------------------------
Description:
steps:
# EXEC: create an application (via ex. nodejs-mongo-persistent template), import the project and create a server adapter for it
# ASSERT: server adapter is created
# EXEC: start the server adapter in Debugging
# ASSERT: sever adapter is in *[Debugging, Synchronized]* state
# ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is started
# EXEC: in Explorer: select the pod for your service and pick "Delete"
# ASSERT: pod gets deleted and recreated
# ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is stopped
Result:
The server adapter still says that is is *[Debugging, Synchronized]*, but debugging is not working any more. Debugging doesn't work any more because the port forwarding was stopped. To have it running again you need to restart the port forwarding for the new pod.
Expected result:
Server adapter should get out of debugging and back into normal run mode *[Started, Synchronized]*.
was:
steps:
# EXEC: create an application (via ex. nodejs-mongo-persistent template), import the project and create a server adapter for it
# ASSERT: server adapter is created
# EXEC: start the server adapter in Debugging
# ASSERT: sever adapter is in *[Debugging, Synchronized]* state
# ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is started
# EXEC: in Explorer: select the pod for your service and pick "Delete"
# ASSERT: pod gets deleted and recreated
# ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is stopped
Result:
The server adapter still says that is is *[Debugging, Synchronized]*, but debugging is not working any more. Debugging doesn't work any more because the port forwarding was stopped. To have it running again you need to restart the server adapter into debug, which will re-create a new pod in debug-mode.
Expected result:
Server adapter should get out of debugging and back into normal run mode *[Started, Synchronized]*.
> Server Adapter: erroneously stays in [Debugging] when you kill the pod
> ----------------------------------------------------------------------
>
> Key: JBIDE-26160
> URL: https://issues.jboss.org/browse/JBIDE-26160
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.6.0.AM3
> Reporter: Andre Dietisheim
> Assignee: Dmitrii Bocharov
> Priority: Major
> Labels: server_adapter
> Fix For: 4.9.0.Final
>
>
> steps:
> # EXEC: create an application (via ex. nodejs-mongo-persistent template), import the project and create a server adapter for it
> # ASSERT: server adapter is created
> # EXEC: start the server adapter in Debugging
> # ASSERT: sever adapter is in *[Debugging, Synchronized]* state
> # ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is started
> # EXEC: in Explorer: select the pod for your service and pick "Delete"
> # ASSERT: pod gets deleted and recreated
> # ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is stopped
> Result:
> The server adapter still says that is is *[Debugging, Synchronized]*, but debugging is not working any more. Debugging doesn't work any more because the port forwarding was stopped. To have it running again you need to restart the port forwarding for the new pod.
> Expected result:
> Server adapter should get out of debugging and back into normal run mode *[Started, Synchronized]*.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (JBIDE-26160) Server Adapter: erroneously stays in [Debugging] when you kill the pod
by Andre Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26160?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-26160:
-------------------------------------
Description:
steps:
# EXEC: create an application (via ex. nodejs-mongo-persistent template), import the project and create a server adapter for it
# ASSERT: server adapter is created
# EXEC: start the server adapter in Debugging
# ASSERT: sever adapter is in *[Debugging, Synchronized]* state
# ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is started
# EXEC: in Explorer: select the pod for your service and pick "Delete"
# ASSERT: pod gets deleted and recreated
# ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is stopped
Result:
The server adapter still says that is is *[Debugging, Synchronized]*, but debugging is not working any more. Debugging doesn't work any more because the port forwarding was stopped. To have it running again you need to restart the server adapter into debug, which will re-create a new pod in debug-mode.
Expected result:
Server adapter should get out of debugging and back into normal run mode *[Started, Synchronized]*.
was:
steps:
# EXEC: create an application (via ex. nodejs-mongo-persistent template), import the project and create a server adapter for it
# ASSERT: server adapter is created
# EXEC: start the server adapter in Debugging
# ASSERT: sever adapter is in *[Debugging, Synchronized]* state
# ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is started
# EXEC: in Explorer: select the pod for your service and pick "Delete"
# ASSERT: pod gets deleted and recreated
# ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is stopped
Result:
The server adapter still says that is is *[Debugging, Synchronized]*, but debugging is not working any more. The new pod is not running in debug (dev-) mode any more. To have it running again you need to restart the server adapter into debug, which will re-create a new pod in debug-mode.
Expected result:
Server adapter should get out of debugging and back into normal run mode *[Started, Synchronized]*.
> Server Adapter: erroneously stays in [Debugging] when you kill the pod
> ----------------------------------------------------------------------
>
> Key: JBIDE-26160
> URL: https://issues.jboss.org/browse/JBIDE-26160
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.6.0.AM3
> Reporter: Andre Dietisheim
> Assignee: Dmitrii Bocharov
> Priority: Major
> Labels: server_adapter
> Fix For: 4.9.0.Final
>
>
> steps:
> # EXEC: create an application (via ex. nodejs-mongo-persistent template), import the project and create a server adapter for it
> # ASSERT: server adapter is created
> # EXEC: start the server adapter in Debugging
> # ASSERT: sever adapter is in *[Debugging, Synchronized]* state
> # ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is started
> # EXEC: in Explorer: select the pod for your service and pick "Delete"
> # ASSERT: pod gets deleted and recreated
> # ASSERT: select pod and pick "Port Forwarding..." and it states that the forwarding is stopped
> Result:
> The server adapter still says that is is *[Debugging, Synchronized]*, but debugging is not working any more. Debugging doesn't work any more because the port forwarding was stopped. To have it running again you need to restart the server adapter into debug, which will re-create a new pod in debug-mode.
> Expected result:
> Server adapter should get out of debugging and back into normal run mode *[Started, Synchronized]*.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ERT-676) [GTK3] Clean up functions that don't need to be dynamic [EBZ#539571]
by Friendly Jira Robot (Jira)
Friendly Jira Robot created ERT-676:
---------------------------------------
Summary: [GTK3] Clean up functions that don't need to be dynamic [EBZ#539571]
Key: ERT-676
URL: https://issues.jboss.org/browse/ERT-676
Project: Eclipse Release Train
Issue Type: Task
Components: Platform
Reporter: Friendly Jira Robot
Some functions are dynamic because they didn't exist on GTK2, or other reasons. Having too many dynamic functions makes it really difficult to find deprecated ones -- let's clean these up.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (JBDS-4731) Missing datatools.enablement features since 12.0
by Nick Boldt (Jira)
[ https://issues.jboss.org/browse/JBDS-4731?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-4731 at 10/2/18 2:39 PM:
-----------------------------------------------------------
In devstudio 11: 73 IUs with "org.eclipse.datatools.enablement" in their name
In devstudio 12: 4
In devstudio 12.9: 4
So this change happened between 11.3 and 12.0, or between Oxygen and Photon. Could be caused by feature reorg/re-nesting in DTP.
Anyway, here's a PR for the next release -- too late for 12.9.
https://github.com/jbdevstudio/jbdevstudio-product/pull/498/files
was (Author: nickboldt):
In devstudio 11: 73 IUs with "org.eclipse.datatools.enablement" in their name
In devstudio 12: 4
In devstudio 12.9: 4
So this change happened between 11.3 and 12.0, or between Oxygen and Photon. Could be caused by feature reorg/re-nesting in DTP.
Anywah here's a PR for the next release -- too late for 12.9.
https://github.com/jbdevstudio/jbdevstudio-product/pull/498/files
> Missing datatools.enablement features since 12.0
> ------------------------------------------------
>
> Key: JBDS-4731
> URL: https://issues.jboss.org/browse/JBDS-4731
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 12.0.0.GA
> Reporter: Jeff MAURY
> Assignee: Nick Boldt
> Priority: Major
> Fix For: 12.10.0.AM1
>
> Attachments: 12.9.0.GA.png, 2018-09.png
>
>
> As reported on StackOverflow, it is not possible to create third parties JBDC drivers since 12.0.0.GA. Some org.eclipse.datatools.enablement features are misssing. See the captures for the list
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (JBIDE-26408) Server adapter: start into debugging fails for nodejs template application
by Andre Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26408?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-26408:
-------------------------------------
Description:
steps:
# ASSERT: have cdk 3.6.0
# EXEC: create an application based on the *nodejs-mongo-persistent* template, have the application imported to the workspace and the server adapter created for it
# EXEC: start the server adapter
# ASSERT: server adapter is *[Started, Synchronized]*
# EXEC: Restart the adapter into debugging
Result:
You very quickly (the timeout seems very short) get an error dialog telling you that the debugger could not connect.
!screenshot-1.png!
The debugger is therefore stopped, debugging wont work.
!screenshot-2.png!
Trying to restart it reproduces the error that we already have.
In the Eclipse log you'll find the following:
{code}
java.io.IOException: Timed out waiting for handshake
at org.eclipse.wst.jsdt.chromium.internal.v8native.JavascriptVmImpl.newIOException(JavascriptVmImpl.java:114)
at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attachImpl(StandaloneVmImpl.java:134)
at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attach(StandaloneVmImpl.java:79)
at org.eclipse.wst.jsdt.chromium.debug.core.model.JavascriptVmEmbedderFactory$4$1.attach(JavascriptVmEmbedderFactory.java:207)
at org.eclipse.wst.jsdt.chromium.debug.core.model.DebugTargetImpl.attach(DebugTargetImpl.java:74)
at org.eclipse.wst.jsdt.chromium.debug.ui.launcher.LaunchTypeBase.launch(LaunchTypeBase.java:101)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:859)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:717)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1026)
at org.eclipse.debug.internal.ui.DebugUIPlugin$2.run(DebugUIPlugin.java:1240)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
Caused by: java.util.concurrent.TimeoutException
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attachImpl(StandaloneVmImpl.java:127)
... 9 more
{code}
was:
steps:
# ASSERT: have cdk 3.6.0
# EXEC: create an application based on the *nodejs-mongo-persistent* template, have the application imported to the workspace and the server adapter created for it
# EXEC: start the server adapter
# ASSERT: server adapter is *[Started, Synchronized]*
# EXEC: Restart the adapter into debugging
Result:
You very quickly (the timeout seems very short) get an error dialog telling you that the debugger could not connect.
!screenshot-1.png!
The debugger is therefore stopped. Trying to restart it reproduces the error that we already have.
!screenshot-2.png!
In the Eclipse log you'll find the following:
{code}
java.io.IOException: Timed out waiting for handshake
at org.eclipse.wst.jsdt.chromium.internal.v8native.JavascriptVmImpl.newIOException(JavascriptVmImpl.java:114)
at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attachImpl(StandaloneVmImpl.java:134)
at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attach(StandaloneVmImpl.java:79)
at org.eclipse.wst.jsdt.chromium.debug.core.model.JavascriptVmEmbedderFactory$4$1.attach(JavascriptVmEmbedderFactory.java:207)
at org.eclipse.wst.jsdt.chromium.debug.core.model.DebugTargetImpl.attach(DebugTargetImpl.java:74)
at org.eclipse.wst.jsdt.chromium.debug.ui.launcher.LaunchTypeBase.launch(LaunchTypeBase.java:101)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:859)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:717)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1026)
at org.eclipse.debug.internal.ui.DebugUIPlugin$2.run(DebugUIPlugin.java:1240)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
Caused by: java.util.concurrent.TimeoutException
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attachImpl(StandaloneVmImpl.java:127)
... 9 more
{code}
> Server adapter: start into debugging fails for nodejs template application
> --------------------------------------------------------------------------
>
> Key: JBIDE-26408
> URL: https://issues.jboss.org/browse/JBIDE-26408
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.9.0.Final
> Environment: cdk-3.6.0
> Reporter: Andre Dietisheim
> Priority: Major
> Labels: node, server_adapter
> Fix For: 4.10.0.AM1
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> steps:
> # ASSERT: have cdk 3.6.0
> # EXEC: create an application based on the *nodejs-mongo-persistent* template, have the application imported to the workspace and the server adapter created for it
> # EXEC: start the server adapter
> # ASSERT: server adapter is *[Started, Synchronized]*
> # EXEC: Restart the adapter into debugging
> Result:
> You very quickly (the timeout seems very short) get an error dialog telling you that the debugger could not connect.
> !screenshot-1.png!
> The debugger is therefore stopped, debugging wont work.
> !screenshot-2.png!
> Trying to restart it reproduces the error that we already have.
> In the Eclipse log you'll find the following:
> {code}
> java.io.IOException: Timed out waiting for handshake
> at org.eclipse.wst.jsdt.chromium.internal.v8native.JavascriptVmImpl.newIOException(JavascriptVmImpl.java:114)
> at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attachImpl(StandaloneVmImpl.java:134)
> at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attach(StandaloneVmImpl.java:79)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.JavascriptVmEmbedderFactory$4$1.attach(JavascriptVmEmbedderFactory.java:207)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.DebugTargetImpl.attach(DebugTargetImpl.java:74)
> at org.eclipse.wst.jsdt.chromium.debug.ui.launcher.LaunchTypeBase.launch(LaunchTypeBase.java:101)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:859)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:717)
> at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1026)
> at org.eclipse.debug.internal.ui.DebugUIPlugin$2.run(DebugUIPlugin.java:1240)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attachImpl(StandaloneVmImpl.java:127)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months