[JBoss JIRA] (JBIDE-22075) Confusing error message when trying to attach remote debugger to OS app run in debug mode
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22075?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22075:
-------------------------------------
Attachment: debug-button-toolbar.png
> Confusing error message when trying to attach remote debugger to OS app run in debug mode
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-22075
> URL: https://issues.jboss.org/browse/JBIDE-22075
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Priority: Minor
> Labels: debugging, openshift_v3
> Fix For: 4.4.3.Final
>
> Attachments: debug-button-toolbar.png, error-in-launching-remote-debugger.png, error-launching-remote-debugger.png, launch-debug-no-error.mov, remote-debugger-already-launched.png
>
>
> If you restart the server adapter in debug mode ("Restart in Debug" in the context menu to your server adapter) the remote debugger is launched automatically.
> If you're not aware of this and try to launch the remote debugger entry (that was created automatically), you will face an error telling you that it cannot connect (since there's already an instance sitting on the ports). It's not obvious to the dummy user, we should improve this error-message
> When I am trying to run remote debugging of an application on OpenShift I get following error
> !!error-in-launching-remote-debugger.png! !
> {code}
> Failed to connect to remote VM
> com.sun.jdi.connect.spi.ClosedConnectionException
> at org.eclipse.jdi.internal.connect.SocketTransportService.readHandshake(SocketTransportService.java:222)
> at org.eclipse.jdi.internal.connect.SocketTransportService.access$7(SocketTransportService.java:214)
> at org.eclipse.jdi.internal.connect.SocketTransportService$3.run(SocketTransportService.java:185)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> *Steps to reproduce:*
> ASSERT: Have an OpenShift 3 application based on eap 6 template with server adapter and project in workspace.
> EXEC: Select "Restart in Debug" in context menu of server adapter.
> ASSERT: Server adapter is in state debugging ("[Debugging, Started]").
> EXEC: Click on Debug Remote debugger to 'server adapter name' workbench tool item to start debugging.
> RESULT: Error is shown.
> EXPECTED RESULT: The error message should tell you that there already is an instance running.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-22075) Confusing error message when trying to attach remote debugger to OS app run in debug mode
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22075?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-22075:
------------------------------------------
I tried to replicate it, but couldnt. [~jrichter1] you hit the button in the toolbar, right?
!debug-button-toolbar.png|thumbnail!
> Confusing error message when trying to attach remote debugger to OS app run in debug mode
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-22075
> URL: https://issues.jboss.org/browse/JBIDE-22075
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Priority: Minor
> Labels: debugging, openshift_v3
> Fix For: 4.4.3.Final
>
> Attachments: debug-button-toolbar.png, error-in-launching-remote-debugger.png, error-launching-remote-debugger.png, launch-debug-no-error.mov, remote-debugger-already-launched.png
>
>
> If you restart the server adapter in debug mode ("Restart in Debug" in the context menu to your server adapter) the remote debugger is launched automatically.
> If you're not aware of this and try to launch the remote debugger entry (that was created automatically), you will face an error telling you that it cannot connect (since there's already an instance sitting on the ports). It's not obvious to the dummy user, we should improve this error-message
> When I am trying to run remote debugging of an application on OpenShift I get following error
> !!error-in-launching-remote-debugger.png! !
> {code}
> Failed to connect to remote VM
> com.sun.jdi.connect.spi.ClosedConnectionException
> at org.eclipse.jdi.internal.connect.SocketTransportService.readHandshake(SocketTransportService.java:222)
> at org.eclipse.jdi.internal.connect.SocketTransportService.access$7(SocketTransportService.java:214)
> at org.eclipse.jdi.internal.connect.SocketTransportService$3.run(SocketTransportService.java:185)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> *Steps to reproduce:*
> ASSERT: Have an OpenShift 3 application based on eap 6 template with server adapter and project in workspace.
> EXEC: Select "Restart in Debug" in context menu of server adapter.
> ASSERT: Server adapter is in state debugging ("[Debugging, Started]").
> EXEC: Click on Debug Remote debugger to 'server adapter name' workbench tool item to start debugging.
> RESULT: Error is shown.
> EXPECTED RESULT: The error message should tell you that there already is an instance running.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-22075) Confusing error message when trying to attach remote debugger to OS app run in debug mode
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22075?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-22075 at 2/16/17 5:26 PM:
-------------------------------------------------------------------
I tried to replicate it, but couldnt. [~jrichter1] you hit the button in the toolbar, right?
!debug-button-toolbar.png!
was (Author: adietish):
I tried to replicate it, but couldnt. [~jrichter1] you hit the button in the toolbar, right?
!debug-button-toolbar.png|thumbnail!
> Confusing error message when trying to attach remote debugger to OS app run in debug mode
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-22075
> URL: https://issues.jboss.org/browse/JBIDE-22075
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Priority: Minor
> Labels: debugging, openshift_v3
> Fix For: 4.4.3.Final
>
> Attachments: debug-button-toolbar.png, error-in-launching-remote-debugger.png, error-launching-remote-debugger.png, launch-debug-no-error.mov, remote-debugger-already-launched.png
>
>
> If you restart the server adapter in debug mode ("Restart in Debug" in the context menu to your server adapter) the remote debugger is launched automatically.
> If you're not aware of this and try to launch the remote debugger entry (that was created automatically), you will face an error telling you that it cannot connect (since there's already an instance sitting on the ports). It's not obvious to the dummy user, we should improve this error-message
> When I am trying to run remote debugging of an application on OpenShift I get following error
> !!error-in-launching-remote-debugger.png! !
> {code}
> Failed to connect to remote VM
> com.sun.jdi.connect.spi.ClosedConnectionException
> at org.eclipse.jdi.internal.connect.SocketTransportService.readHandshake(SocketTransportService.java:222)
> at org.eclipse.jdi.internal.connect.SocketTransportService.access$7(SocketTransportService.java:214)
> at org.eclipse.jdi.internal.connect.SocketTransportService$3.run(SocketTransportService.java:185)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> *Steps to reproduce:*
> ASSERT: Have an OpenShift 3 application based on eap 6 template with server adapter and project in workspace.
> EXEC: Select "Restart in Debug" in context menu of server adapter.
> ASSERT: Server adapter is in state debugging ("[Debugging, Started]").
> EXEC: Click on Debug Remote debugger to 'server adapter name' workbench tool item to start debugging.
> RESULT: Error is shown.
> EXPECTED RESULT: The error message should tell you that there already is an instance running.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-21857) Hot code replacement doesn't work on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21857?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-21857:
------------------------------------------
we didnt find a solution for this in the 4.4.3.Final timeframe. Postponing.
> Hot code replacement doesn't work on OpenShift
> ----------------------------------------------
>
> Key: JBIDE-21857
> URL: https://issues.jboss.org/browse/JBIDE-21857
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Fred Bricon
> Assignee: Andre Dietisheim
> Fix For: 4.4.4.AM1
>
> Attachments: HCRFailure.zip, code-out-of-sync.png, hot-code-replace-failed.png, jmx-connected-adapter-synchronized.png
>
>
> When enabling debug mode on an EAP server deployed on OpenShift, locally changing a class file will :
> - work sometimes when only the content of the method changed, but could fail in some other occasions with the Debugger saying the JDK is out of sync
> - will always fail if a method signature changed, the debugger saying JDK is out of sync
> Restarting the deployed module (with the .dodeploy flag) doesn't fixes the issue (as opposed to the same tweak ahen running on a local EAP server)
> This may be caused by running OpenJDK? Does it support the same level of debugging as Oracle JDK?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-21857) Hot code replacement doesn't work on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21857?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21857:
-------------------------------------
Fix Version/s: 4.4.4.AM1
(was: 4.4.3.Final)
> Hot code replacement doesn't work on OpenShift
> ----------------------------------------------
>
> Key: JBIDE-21857
> URL: https://issues.jboss.org/browse/JBIDE-21857
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Fred Bricon
> Assignee: Andre Dietisheim
> Fix For: 4.4.4.AM1
>
> Attachments: HCRFailure.zip, code-out-of-sync.png, hot-code-replace-failed.png, jmx-connected-adapter-synchronized.png
>
>
> When enabling debug mode on an EAP server deployed on OpenShift, locally changing a class file will :
> - work sometimes when only the content of the method changed, but could fail in some other occasions with the Debugger saying the JDK is out of sync
> - will always fail if a method signature changed, the debugger saying JDK is out of sync
> Restarting the deployed module (with the .dodeploy flag) doesn't fixes the issue (as opposed to the same tweak ahen running on a local EAP server)
> This may be caused by running OpenJDK? Does it support the same level of debugging as Oracle JDK?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-16225) Let the user select the version of the arquillian container adapter
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16225?page=com.atlassian.jira.plugi... ]
Snjezana Peco updated JBIDE-16225:
----------------------------------
Fix Version/s: 4.5.x
(was: 4.3.x)
> Let the user select the version of the arquillian container adapter
> ---------------------------------------------------------------------
>
> Key: JBIDE-16225
> URL: https://issues.jboss.org/browse/JBIDE-16225
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: arquillian
> Affects Versions: 4.1.1.CR1
> Reporter: Xavier Coulon
> Assignee: Snjezana Peco
> Fix For: 4.5.x
>
>
> The Arquillian wizard provides users with a list of containers (eg: JBOSS_AS_REMOTE_7.X) that can be used but it misses the version selection (eg: 7.1.1.Final, 7.2.0.Final, etc.).
> I think it's important to let the user choose the version of the 'driver' she needs to use, because it needs to match against the actual version of the container.
> for example, using org.jboss.as:jboss-as-arquillian-container-remote:7.2.0.Final against JBoss AS 7.1.1 will not work.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-17596) Cannot run test on WELD EE 1.1
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17596?page=com.atlassian.jira.plugi... ]
Snjezana Peco updated JBIDE-17596:
----------------------------------
Fix Version/s: 4.5.x
(was: 4.3.x)
> Cannot run test on WELD EE 1.1
> ------------------------------
>
> Key: JBIDE-17596
> URL: https://issues.jboss.org/browse/JBIDE-17596
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: arquillian, upstream
> Affects Versions: 4.2.0.Beta2
> Reporter: Lucia Jelinkova
> Assignee: Snjezana Peco
> Fix For: 4.5.x
>
>
> When I try to run simple test with WELD 1.1 maven profile the test fails with the following exception:
> {code}
> java.lang.NoClassDefFoundError: javax/ejb/Stateless
> at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.findEjbs(Ejbs.java:38)
> at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.createEjbDescriptors(Ejbs.java:25)
> at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:81)
> at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.<init>(TestContainer.java:228)
> at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:99)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.ClassNotFoundException: javax.ejb.Stateless
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 92 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month