[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [pde-dev] Profiling PDE Junit Plugin Tests
|
Scott,
Our JUnit suites explicitly call addTest
/ addTestSuite in their constructors instead of relying on pattern matching
of Test*. Maybe your code does the same and they're getting invoked
2x because the tests / suites are prefixed by Test. Just a guess...
a little quality time with the debugger should ferret out the cause. :-)
-- Dan
-------------------------------------------------------------
co-author "The Java Developer's
Guide to Eclipse", 2nd edition (preview at http://www.jdg2e.com)
pde-dev-request@xxxxxxxxxxx
Sent by: pde-dev-admin@xxxxxxxxxxx
02/04/2005 12:00 PM
|
Please respond to
pde-dev |
|
|
To
| pde-dev@xxxxxxxxxxx
|
|
cc
|
|
|
Subject
| pde-dev digest, Vol 1 #235
- 2 msgs |
|
----- Message from Scott
Gelb <SGelb@xxxxxxxxxxxxxx> on Thu, 3 Feb 2005 13:23:58 -0600 -----
|
To:
| pde-dev@xxxxxxxxxxx
|
|
Subject:
| RE: [pde-dev] Profiling PDE Junit Plugin Tests |
Dan,
Thank you very much...this information
helped a GREAT deal.
Out-of-curiousity, have you ever
tried to run all JUnit plug-in tests within a plug-in by right-clicking
on the plugin in Eclipse's Package Explorer and selecting the "Run
JUnit Plug-in Test" option? The reason why I initally needed to profile
my tests was due to excessive memory usage when I was testing using this
method. However, it seems like Eclipse does some funky things when trying
to run a bunch of JUnit PDE test suites at a time. I was seeing almost
TWICE the number of tests that actually existed in the JUnit pane (I just
joined this project, so at first, the larger number didn't trigger an alarm
with me) and many of the tests were being run multiple times. The order
that the tests were run also seemed a bit wacky, as it LOOKED like the
test runner was starting top down (from a Package Explorer point-of-view).
However, I set a breakpoint in the setUp() of one of the last tests, which
was hit almost instantly in the beginning of the test run. Immediately
following this event, tests that were situated at the top of the plug-in/package
hierarchy were executed. So, to summarize, tests were being run multiple
times and out-of-order. Has anyone else seen this behavior? Very wacky...(btw,
all our JUnit PDE tests have the suite() method defined, as there are oneTimeSetup
and oneTimeTearDown methods that need to be called for each test class).
Thanks again for the info, though,
I'm definitely well on my way into profiling land now. :)
Scott
From: pde-dev-admin@xxxxxxxxxxx [mailto:pde-dev-admin@xxxxxxxxxxx]
On Behalf Of Dan Kehn
Sent: Wednesday, February 02, 2005 3:32 PM
To: pde-dev@xxxxxxxxxxx
Subject: Re: [pde-dev] Profiling PDE Junit Plugin Tests
Your question is really appropriate for the newsgroups, but I can offer
some suggestions. I've had good success with YourKit Java Profiler
under Eclipse, whether running standalone or with the PDE. The setup is
straightforward -- copy their DLL (yjpagent.dll) to your JRE's bin directory,
specify -Xrunyjpagent as vmargs in the launch configuration / command line,
and it communicates with the YK user interface.
I've also used JProbe in the PDE, but that's a little more challenging
since JProbe wants to launch the profilee as a child process, and the PDE
by default makes the same assumption. Making them both happy involved
launching my application using the PDE to establish its runtime configuration
area, exiting the runtime instance, then having JProbe relaunch Eclipse
using the same parameters / setup area as the PDE would. The "trick"
is finding what options the PDE uses to get the runtime instance going.
Well, no magic there -- launch your application in the PDE and in
the Debug view, select "Properties" on the process to see the
equivalent command line options you would need to launch it under JProbe
(or any other profiler which launches the application as a child process).
One small caveat I noted was that JProbe doesn't handle quoted paths
correctly in its sessions settings (*.jpl), although I have an old copy
and it may have since been corrected (v5.0.1).
Hope this helps...
-- Dan
----- Message from Scott Gelb <SGelb@xxxxxxxxxxxxxx> on Tue, 1 Feb
2005 16:37:45 -0600 -----
|
To:
| pde-dev@xxxxxxxxxxx
|
|
Subject:
| [pde-dev] Profiling PDE Junit Plugin Tests |
Greetings,
I'm new to Eclipse PDE development, so please bare with me...
I've been having some difficulty using a few of the profilers out
there to investigate some memory issues in a few of my junit tests. These
tests require the pde and thus they run as junit plugin tests via the Eclipse
environment. If I try to use the Eclipse profiler, I get the same error/exception
that I receive when trying to run a pde test as a normal junit test:
org.eclipse.core.internal.runtime.AssertionFailedException:
assertion failed: The application has not been initialized.
at org.eclipse.core.internal.runtime.Assert.isTrue(Assert.java:101)
at org.eclipse.core.internal.runtime.InternalPlatform.assertInitialized(InternalPlatform.java:191)
at org.eclipse.core.internal.runtime.InternalPlatform.getPluginRegistry(InternalPlatform.java:410)
at org.eclipse.core.runtime.Platform.getPluginRegistry(Platform.java:321)
at com.metamatrix.core.util.SmartPdeTestSuite.<init>(SmartPdeTestSuite.java:24)
at com.metamatrix.modeler.core.PdeTestAutomatedTestUtil.suite(PdeTestAutomatedTestUtil.java:73)
at com.metamatrix.modeler.core.PdeTestAutomatedTestUtil.main(PdeTestAutomatedTestUtil.java:40)
Exception in thread "main"
What type of strategy do people
use when profiling junit tests that require the pde? Is there a way to
bootstrap a profiling tool to the jvm that the pde initializes? Again,
I apologize for my naiveté, but I'm nearing my wits' end on figuring out
a good way to accomplish this goal.
Thanks,
Scott
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/pde-dev
----- Message from Cherie Wong <cgwong@xxxxxxxxxx> on Thu, 3 Feb
2005 15:13:04 -0500 -----
|
To:
| pde-dev@xxxxxxxxxxx
|
|
Subject:
| Re: [pde-dev] Win32RefreshProvider |
Hi Jason,
It sounds like you copied the extension as-is from the developer guide
which isn't what you want. That particular extension is for the
org.eclipse.core.resources.win32 fragment.
Try to set the class attribute to a class of yours that extends
RefreshProvider. Recall, this class is responsible for installing a monitor
on a specific resource and its resource subtree if it is a project or
folder. The monitor must implement IRefreshMonitor.
The "PDE Does Plug-ins" article
(http://eclipse.org/articles/Article-PDE-does-plugins/PDE-intro.html) does
a better job of explaining extensions if you're just getting started.
For future reference, the newsgroups might strike your fancy too. ;-)
(http://eclipse.org/newsgroups/index.html)
Yours,
Cherie G. Wong
Software Developer, The Eclipse Project
Jason Chan
<jc.eagle@gmail.c
om>
To
Sent by:
pde-dev@xxxxxxxxxxx
pde-dev-admin@ecl
cc
ipse.org
Subject
[pde-dev]
Win32RefreshProvider
02/01/2005 04:52
PM
Please respond to
pde-dev
Hi,
I tried to use the default behavior of
org.eclipse.core.internal.resources.refresh.win32.Win32RefreshProvider.
I added the extension point which I copied from platform plugin
developer guide. I thought the extension point will register the
Win32RefreshProvider to monitor the external files and refresh the
workspace properly, but I didn't get it working. Do I need to
programmatically link the Win32RefreshProvider to my workspace?
Please help if you know how to get Win32RefreshProvider working.
Thanks,
-Jason
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/pde-dev
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/pde-dev
