JDBC DataSourceElement fails with remote testing

[asfimport]

Joerg Holle (Bug 38748):
Test plans using a "JDBC Connection Configuration" element will not start
with remote testing!

The error message of the remote server is:
java.lang.NullPointerException
at org.apache.jmeter.protocol.jdbc.config.DataSourceElement.testStarted
(DataSourceElement.java:91)
at org.apache.jmeter.protocol.jdbc.config.DataSourceElement.testStarted
(DataSourceElement.java:109)
at
org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart
(StandardJMeterEngine.java:201)
at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngin
e.java:315)
at java.lang.Thread.run(Unknown Source)

This has nothing to do with wrong classpath or such. Having a look at the
source code of DataSourceElement it seems that the transient property "started"
is causing the problem. [http://www.devx.com/tips/Tip/13726]
To verify that I removed the "transient" keyword in my environment, compiled,
re-started - and my testplan started remotely (i.e. no NullPointerException).

Since I have no idea about the internal logic of JMeter and there are even more
transient properties in the mentioned class, I suggest to have a look at the
class as a whole. But again: making property "started" non-transient worked for
me.

BTW
This behaviour has been mentioned already by Benny Rogiers on the jmeter-user
mailing list, but has been ignored there:
http://www.mail-archive.com/jmeter-user@jakarta.apache.org/msg10071.html
[Just to ensure you guys that this is no local problem with my environment ;-)]

Severity: normal
OS: All

[asfimport]

Sebb (migrated from Bugzilla):
Thanks for the report - I'll fix this shortly.
[I seem to have missed the posting; I don't remember it.]

[asfimport]

Sebb (migrated from Bugzilla):
I've fixed it in a slightly different way - by adding a readResolve() method
to emulate what the constructor does.

Seems to me that this is a bit safer than relying on the correct value being
passed across.

As far as I can tell, all the other transient fields are set up when running
the test.

[asfimport]

Joerg Holle (migrated from Bugzilla):
(In reply to comment 2)

I've fixed it in a slightly different way - by adding a readResolve() method
to emulate what the constructor does.
Seems to me that this is a bit safer than relying on the correct value being
passed across.
As far as I can tell, all the other transient fields are set up when running
the test.

Sounds like the correct way to handle this.

BTW: Does the current status NEEDINFO indicate that this fix will not be used
yet (e.g. in the next release)?

[asfimport]

Sebb (migrated from Bugzilla):
The fix will be in the next release, 2.1.2.

NEEDINFO means that we are awaiting information from the person who created
the bug. In this case, we need to know if the current nightly build fixes the
problem or not.