[testng-dev] Eclipse TestNG and Counterclockwise (Clojure Plugin) conflict

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[testng-dev] Eclipse TestNG and Counterclockwise (Clojure Plugin) conflict

Laurent PETIT
Hello,

Please let me introduce me to you: my name's Laurent Petit, I'm the lead developer of Counterclockwise, an Eclipse plugin for the Clojure language.

It has been reported to me that Counterclockwise and the TestNG Eclipse plugin don't work well together, especially with the following scenario:

- have TestNG latest stable and Counterclockwise latest stable ( http://ccw.cgrand.net/updatesite/ ) both installed
- create a leiningen project with all the default
- ensure that the TestNG plugin is active (e.g. go to its Preference page)
- start an interactive console for the leiningen project (project > Run as > Clojure application)

One would expect that after the startup time of the underlying JVM launched for the interactive console, a "REPL Viewpart" is opened, displayed, and gets the focus.
Instead, Eclipse hangs forever, stuck in the UI Thread, while the workspace's .metadata/.log file receives a new error message of this kind approx. every 5 seconds:

!ENTRY org.testng.eclipse 4 4 2012-10-18 19:00:34.044
!MESSAGE Error
!STACK 0
java.net.SocketTimeoutException: Accept timed out
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
        at java.net.ServerSocket.implAccept(ServerSocket.java:462)
        at java.net.ServerSocket.accept(ServerSocket.java:430)
        at org.testng.remote.strprotocol.BaseMessageSender.initReceiver(BaseMessageSender.java:128)
        at org.testng.eclipse.ui.TestRunnerViewPart.startTestRunListening(TestRunnerViewPart.java:402)
        at org.testng.eclipse.TestNGPlugin.connectTestRunner(TestNGPlugin.java:215)
        at org.testng.eclipse.TestNGPlugin$2.run(TestNGPlugin.java:203)
        at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
        at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
        at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
        at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
        at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1438)


That's the only visible companion side effect of the undesirable "hang" behavior.

Since you're the maintainer of the TestNG plugin, I hope you can give me some hints (an explanation?) of what's happening on TestNG's side.

Launching a Clojure Application means that a launch configuration of type "Clojure", which is really just a glorified Java launch configuration with a custom "Main Tab" is started.

Thanks in advance for your insights,


-- 
Laurent Petit

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

[testng-dev] Re: Eclipse TestNG and Counterclockwise (Clojure Plugin) conflict

Laurent PETIT
Hello again,

So I have followed the testng-eclipse classes with the help of the
StackTrace, and 2 things seem odd to me. Please correct me if I'm
wrong.

First thought: the initialization, with this potential behavior,
should probably not occur within the UI Thread, but rather be
dedicated to a background job (with or without visual feedback for the
user, as you would expect).

Second, it seems that whenever the launched configuration has a PORT
or not, you consider that it is an acceptable TestNG target. This is
odd. Look:
- this code seems to rely on catching an exception to determine if the
launch is related to TestNG or not:
https://github.com/cbeust/testng-eclipse/blob/master/src/main/org/testng/eclipse/TestNGPlugin.java#L178
- so I would expect that if the TestNG PORT does not exist on the
launch configuration, then an exception is launched from the call to
ConfigurationHelper.getPort(port), but that's not the case, if an
exception is launched, then the port 0 is returned:
https://github.com/cbeust/testng-eclipse/blob/master/src/main/org/testng/eclipse/ui/util/ConfigurationHelper.java#L182

So you're not relying on the lack of PORT (and not on lack of
PROJECT_NAME, of course) to determine if it's a TestNG launch
candidate.
The only discriminator which remains is the notion of subName:
https://github.com/cbeust/testng-eclipse/blob/master/src/main/org/testng/eclipse/TestNGPlugin.java#L182

which is defined here:
https://github.com/cbeust/testng-eclipse/blob/master/src/main/org/testng/eclipse/ui/util/ConfigurationHelper.java#L191

but this will not fail, since ILaunch.getAttribute() just returns null
in case of a missing key:
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fdebug%2Fcore%2FILaunch.html

My current understanding is that this is a problem on the TestNG
plugin site. I would have preferred the contrary, since it would then
imply that the solution is within my hands, and my own plugin's
lifecycle :).

Sadly, I don't see any easy workaround for Counterclockwise users, set
apart to remove TestNG plugin or be sure not to have it started before
launching an interactive console.

... which made me think ... if this is not related to
Counterclockwise, then this is probably happening to an Eclipse
install without Counterclockwise installed at all .. let's see:

- ensure TestNG is active
- create a raw java project
- launch the project

But this does not show the same behaviour, there's no problem
there ... so there's probably a flaw in my analysis ... ?

On 19 oct, 21:46, Laurent PETIT <[hidden email]> wrote:

> Hello,
>
> Please let me introduce me to you: my name's Laurent Petit, I'm the lead
> developer of Counterclockwise, an Eclipse plugin for the Clojure language.
>
> It has been reported to me that Counterclockwise and the TestNG Eclipse
> plugin don't work well together, especially with the following scenario:
>
> - have TestNG latest stable and Counterclockwise latest stable (http://ccw.cgrand.net/updatesite/) both installed
> - create a leiningen project with all the default
> - ensure that the TestNG plugin is active (e.g. go to its Preference page)
> - start an interactive console for the leiningen project (project > Run as
>
> > Clojure application)
>
> One would expect that after the startup time of the underlying JVM launched
> for the interactive console, a "REPL Viewpart" is opened, displayed, and
> gets the focus.
> Instead, Eclipse hangs forever, stuck in the UI Thread, while the
> workspace's .metadata/.log file receives a new error message of this kind
> approx. every 5 seconds:
>
> !ENTRY org.testng.eclipse 4 4 2012-10-18 19:00:34.044
> !MESSAGE Error
> !STACK 0
> java.net.SocketTimeoutException: Accept timed out
>         at java.net.PlainSocketImpl.socketAccept(Native Method)
>         at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
>         at java.net.ServerSocket.implAccept(ServerSocket.java:462)
>         at java.net.ServerSocket.accept(ServerSocket.java:430)
>         at
> org.testng.remote.strprotocol.BaseMessageSender.initReceiver(BaseMessageSen der.java:128)
>         at
> org.testng.eclipse.ui.TestRunnerViewPart.startTestRunListening(TestRunnerVi ewPart.java:402)
>         at
> org.testng.eclipse.TestNGPlugin.connectTestRunner(TestNGPlugin.java:215)
>         at org.testng.eclipse.TestNGPlugin$2.run(TestNGPlugin.java:203)
>         at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
>         at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135 )
>         at
> org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
>         at
> org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
>         at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRend eringEngine.java:1022)
>         at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332 )
>         at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRender ingEngine.java:916)
>         at
> org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench .java:86)
>         at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
>         at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332 )
>         at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
>         at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
>         at
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication .java:124)
>         at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java :196)
>         at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication (EclipseAppLauncher.java:110)
>         at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseA ppLauncher.java:79)
>         at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353 )
>         at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180 )
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
>         at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
>         at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
>
> That's the only visible companion side effect of the undesirable "hang"
> behavior.
>
> Since you're the maintainer of the TestNG plugin, I hope you can give me
> some hints (an explanation?) of what's happening on TestNG's side.
>
> Launching a Clojure Application means that a launch configuration of type
> "Clojure", which is really just a glorified Java launch configuration with
> a custom "Main Tab" is started.
>
> Thanks in advance for your insights,
>
> --
> Laurent Petit

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.

Reply | Threaded
Open this post in threaded view
|

Re: [testng-dev] Re: Eclipse TestNG and Counterclockwise (Clojure Plugin) conflict

Laurent PETIT
Understood: seems like we both had the same idea of transferring the JDT project name from the launch configuration to the launch instance.

In both our cases, I guess it serves to easily trace back from the launch to the corresponding project (if any).
In your case, it only seems that it serves as a flag to determine whether the launch is "instrumented" by TestNG ; and it appears that it is not necessarily the case.

The fix on my side may prove easy: I'll stop using the JDT project name key to store the project name in the launch. I can imagine that other projects have the same approach as us to use the JDT key to store the project name in the launch, so I encourage you to also namespace it correctly as I'll do for Counterclockwise.

HTH,

-- 
Laurent

2012/10/19 Laurent Petit <[hidden email]>
Hello again,

So I have followed the testng-eclipse classes with the help of the
StackTrace, and 2 things seem odd to me. Please correct me if I'm
wrong.

First thought: the initialization, with this potential behavior,
should probably not occur within the UI Thread, but rather be
dedicated to a background job (with or without visual feedback for the
user, as you would expect).

Second, it seems that whenever the launched configuration has a PORT
or not, you consider that it is an acceptable TestNG target. This is
odd. Look:
- this code seems to rely on catching an exception to determine if the
launch is related to TestNG or not:
https://github.com/cbeust/testng-eclipse/blob/master/src/main/org/testng/eclipse/TestNGPlugin.java#L178
- so I would expect that if the TestNG PORT does not exist on the
launch configuration, then an exception is launched from the call to
ConfigurationHelper.getPort(port), but that's not the case, if an
exception is launched, then the port 0 is returned:
https://github.com/cbeust/testng-eclipse/blob/master/src/main/org/testng/eclipse/ui/util/ConfigurationHelper.java#L182

So you're not relying on the lack of PORT (and not on lack of
PROJECT_NAME, of course) to determine if it's a TestNG launch
candidate.
The only discriminator which remains is the notion of subName:
https://github.com/cbeust/testng-eclipse/blob/master/src/main/org/testng/eclipse/TestNGPlugin.java#L182

which is defined here:
https://github.com/cbeust/testng-eclipse/blob/master/src/main/org/testng/eclipse/ui/util/ConfigurationHelper.java#L191

but this will not fail, since ILaunch.getAttribute() just returns null
in case of a missing key:
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fdebug%2Fcore%2FILaunch.html

My current understanding is that this is a problem on the TestNG
plugin site. I would have preferred the contrary, since it would then
imply that the solution is within my hands, and my own plugin's
lifecycle :).

Sadly, I don't see any easy workaround for Counterclockwise users, set
apart to remove TestNG plugin or be sure not to have it started before
launching an interactive console.

... which made me think ... if this is not related to
Counterclockwise, then this is probably happening to an Eclipse
install without Counterclockwise installed at all .. let's see:

- ensure TestNG is active
- create a raw java project
- launch the project

But this does not show the same behaviour, there's no problem
there ... so there's probably a flaw in my analysis ... ?

On 19 oct, 21:46, Laurent PETIT <[hidden email]> wrote:
> Hello,
>
> Please let me introduce me to you: my name's Laurent Petit, I'm the lead
> developer of Counterclockwise, an Eclipse plugin for the Clojure language.
>
> It has been reported to me that Counterclockwise and the TestNG Eclipse
> plugin don't work well together, especially with the following scenario:
>
> - have TestNG latest stable and Counterclockwise latest stable (http://ccw.cgrand.net/updatesite/) both installed
> - create a leiningen project with all the default
> - ensure that the TestNG plugin is active (e.g. go to its Preference page)
> - start an interactive console for the leiningen project (project > Run as
>
> > Clojure application)
>
> One would expect that after the startup time of the underlying JVM launched
> for the interactive console, a "REPL Viewpart" is opened, displayed, and
> gets the focus.
> Instead, Eclipse hangs forever, stuck in the UI Thread, while the
> workspace's .metadata/.log file receives a new error message of this kind
> approx. every 5 seconds:
>
> !ENTRY org.testng.eclipse 4 4 2012-10-18 19:00:34.044
> !MESSAGE Error
> !STACK 0
> java.net.SocketTimeoutException: Accept timed out
>         at java.net.PlainSocketImpl.socketAccept(Native Method)
>         at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
>         at java.net.ServerSocket.implAccept(ServerSocket.java:462)
>         at java.net.ServerSocket.accept(ServerSocket.java:430)
>         at
> org.testng.remote.strprotocol.BaseMessageSender.initReceiver(BaseMessageSen der.java:128)
>         at
> org.testng.eclipse.ui.TestRunnerViewPart.startTestRunListening(TestRunnerVi ewPart.java:402)
>         at
> org.testng.eclipse.TestNGPlugin.connectTestRunner(TestNGPlugin.java:215)
>         at org.testng.eclipse.TestNGPlugin$2.run(TestNGPlugin.java:203)
>         at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
>         at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135 )
>         at
> org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
>         at
> org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
>         at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRend eringEngine.java:1022)
>         at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332 )
>         at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRender ingEngine.java:916)
>         at
> org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench .java:86)
>         at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
>         at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332 )
>         at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
>         at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
>         at
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication .java:124)
>         at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java :196)
>         at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication (EclipseAppLauncher.java:110)
>         at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseA ppLauncher.java:79)
>         at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353 )
>         at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180 )
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
>         at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
>         at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
>
> That's the only visible companion side effect of the undesirable "hang"
> behavior.
>
> Since you're the maintainer of the TestNG plugin, I hope you can give me
> some hints (an explanation?) of what's happening on TestNG's side.
>
> Launching a Clojure Application means that a launch configuration of type
> "Clojure", which is really just a glorified Java launch configuration with
> a custom "Main Tab" is started.
>
> Thanks in advance for your insights,
>
> --
> Laurent Petit

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.


--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.