No, I remember having taken out that bit of code, but the reason was that it was causing JMeter fail to start when the help.html file wasn't available -- even when running the unit tests, since it happens at class load time. This made the "test" target depend on the "docs" target, which in turn means you need to have Anakia installed to build and test -- which is something I wanted to avoid: I'd like the amount of work needed by a new developer to fix a bug and test his patch kept to a minimum.

Before removing it, I tried to see it work, but it just didn't. Try it: go to a clean 1.8 install, rename the docs directory, and try to start JMeter. This is what you'll get:

java.lang.reflect.InvocationTargetException: java.lang.ExceptionInInitializerError: java.lang.NullPointerException
at org.apache.jmeter.gui.action.Help.<clinit>(Help.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:120)
at org.apache.jmeter.gui.action.ActionRouter.populateCommandMap(ActionRouter.java:185)
at org.apache.jmeter.gui.action.ActionRouter.getInstance(ActionRouter.java:220)
at org.apache.jmeter.JMeter.startGui(JMeter.java:185)
at org.apache.jmeter.JMeter.start(JMeter.java:237)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.jmeter.NewDriver.main(NewDriver.java:165)

I think this is because it's just too early to use GUI at this point.

So I thought it wasn't worth keeping around a bit of code which should never be run on a binary dist, won't work anyway, and is there just to warn you about a relatively minor problem which will show up in the log anyway.

Makes sense?

Salut,

Jordi.

Wolfram Rittmeyer wrote:
Hi Jordi,

because of the reported WIN98-bug (14618) which occured in Help.java I just
diffed this file with version 1.6. Thereby I found something which I guess
is a result of your recent separation of tasks.

Up to version 1.7 a user got notified if an error occured during the
load-process of the help. Yet you took out this fragment because it would
cause a GUI-call which should not be made from a core-class (at least I
guess that's the reason).

I think this behavious is correct since I strongly support a separation of
gui and core-functionality. Yet shouldn't there be some kind of
notification? Maybe a thrown exception which the gui-part would be
responsible for to catch it? After all that's what you would expect from a
client-class, if it cannot fulfill the requested service, isn't it? Of
course this would mean quite some work on the gui-side.

I haven't searched around wether other core-classes have similar "issues".
If so, I would recommend a enhancement-request so that these issues do not
get lost over time. Do you (or anyone else) agree?

Though I guess right now there are some more urgent things to do...

Greetings,

Wolfram


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to