Issue with CheckBox?

[benoitx]

Hi

I have a class with a Boolean attribute:

public class Test {
   private Boolean val;
... get and set
}

I put this attribute on a form as usual:

formBuilder.add("val");

And it displays correctly using a checkbox.

However, if I was to change the value of the field val in the model, the check box does NOT seem to change (although the value in the model does change).

getFormModel().getValueModel("val").setValue(true);

or 

getFormModel().getValueModel("val").setValue(Boolean.TRUE);

Has anyone seen this??? If not, I may create a small test and log it via JIRA...

Thanks

Benoit

[jh@schaubroeck.be]

Have you stepped through debug to see if events are correctly fired and handled? This seems very basic stuff, so if it indeed fails, please do create an issue and a junit test.

If I find the time, I'll try it out.

Regards,
Jan

[benoitx]

Hi Jan

I've created a basic test... but it works! So I'm trying to get closer to what I have (validation rules + more complex events). I suspect may be an exception being thrown but there is no LOG of any... I remember wondering why logging an exception does not seem to be using log.error in Spring RC...

Benoit

[benoitx]

Hi Jan,

Well my suspicion was correct, there was an NPE in my code. This raises again my question as of why wasn't this logged as an error? I have noticed that during events or binding, Spring RC has a tendency of sweeping some exceptions under the carpet...

Either they are not logged or one needs to specify DEBUG level in log4j to see the exception in the log. IMHO this is not good, exceptions should be logged when the level is set higher to say ERROR, one would not want to run a Spring RC with full DEBUG level...

Obviously, I may be doing something wrong, so I think it would be interesting to specify the 'best practice' for error log and exception handling. Is there anything on the Wiki about this? How come the NPE is not handled by the exception handler? Should I add catch "everywhere"? (that is a rhetorical question...)

log4j.properties

log4j.rootCategory=DEBUG,Console,Default

log4j.category.net.objectlab=DEBUG
log4j.category.org=INFO

So I expect DEBUG (and higher) from my code and INFO (or higher) from org... ie Spring. Anyone who has tried to run with DEBUG level knows why it should not be done in a production environment... the amount of data is just... huge!

If I run with log4j.category.org=DEBUG, I can see the exception.

The NPE is caught by DefaultFormModel on line 286 and the logger.debug is called. IMHO it should call logger.error.

It then calls raiseBindingError but as far as the user can see, it may simply put a little red cross on the checkbox (which displays "required" like a validation... despite the fact that there are NO validation rule for that field!)

As a developer what should I do?
Do I need to override the raiseBindingError? Is there a way to log the exception as an error?

Could the DefaultFormModel log the exception as an error? or at least a warning?

Many thanks

Benoit

I enclose the stacktrace for ref:

[DEBUG,53377,DefaultFormModel,AWT-EventQueue-0] Exception occurred setting value
java.lang.NullPointerException
        at net.objectlab.gui.forms.XXXForm.handleXXXChange(XXXXForm.java:104)
        at net.objectlab.gui.forms.XXXXGeneralForm$4.propertyChange(XXXForm.java:77)
        at org.springframework.binding.value.support.AbstractValueModel.fireValueChangeEvent(AbstractValueModel.java:172)
        at org.springframework.binding.value.support.AbstractValueModel.fireValueChange(AbstractValueModel.java:144)
        at org.springframework.binding.value.support.ValueHolder.setValue(ValueHolder.java:60)
        at org.springframework.binding.value.support.AbstractValueModel.setValueSilently(AbstractValueModel.java:54)
        at org.springframework.binding.form.support.FormModelMediatingValueModel.setValueSilently(FormModelMediatingValueModel.java:69)
        at org.springframework.binding.value.support.AbstractValueModelWrapper.setValueSilently(AbstractValueModelWrapper.java:41)
        at org.springframework.binding.form.support.DefaultFormModel$ValidatingFormValueModel.setValueSilently(DefaultFormModel.java:283)
        at org.springframework.binding.value.support.AbstractValueModelWrapper.setValue(AbstractValueModelWrapper.java:37)
        at net.objectlab.gui.forms.YYYYForm.handleNewRelationship(YYYYForm.java:347)
        at net.objectlab.gui.forms.AbstractWithLogicForm.fetchZZZZ(AbstractWithLogicForm.java:408)
        at net.objectlab.gui.forms.YYYYForm$1.propertyChange(YYYYForm.java:63)
        at org.springframework.binding.value.support.AbstractValueModel.fireValueChangeEvent(AbstractValueModel.java:172)
        at org.springframework.binding.value.support.AbstractValueModel.fireValueChange(AbstractValueModel.java:144)
        at org.springframework.binding.value.support.ValueHolder.setValue(ValueHolder.java:60)
        at org.springframework.binding.value.support.AbstractValueModel.setValueSilently(AbstractValueModel.java:54)
        at org.springframework.binding.form.support.FormModelMediatingValueModel.setValueSilently(FormModelMediatingValueModel.java:69)
        at org.springframework.binding.value.support.AbstractValueModelWrapper.setValueSilently(AbstractValueModelWrapper.java:41)
        at org.springframework.binding.form.support.DefaultFormModel$ValidatingFormValueModel.setValueSilently(DefaultFormModel.java:283)
        at org.springframework.binding.value.support.AbstractValueModelWrapper.setValue(AbstractValueModelWrapper.java:37)
        at org.springframework.richclient.form.binding.swing.ComboBoxBinding$BoundComboBoxModel.setSelectedItem(ComboBoxBinding.java:155)
        at org.springframework.richclient.form.binding.swing.ComboBoxBinding.updateSelectableItems(ComboBoxBinding.java:94)
        at org.springframework.richclient.form.binding.swing.ComboBoxBinding$SelectableItemsChangeHandler.propertyChange(ComboBoxBinding.java:174)
        at org.springframework.binding.value.support.AbstractValueModel.fireValueChangeEvent(AbstractValueModel.java:172)
        at org.springframework.binding.value.support.AbstractValueModel.fireValueChange(AbstractValueModel.java:144)
        at org.springframework.binding.value.support.ValueHolder.setValue(ValueHolder.java:60)
        at net.objectlab.gui.forms.AbstractWithLogicForm.tryFetchRelationship(AbstractWithLogicForm.java:384)
        at net.objectlab.gui.forms.WWWWForm$1.propertyChange(WWWWForm.java:63)
        at org.springframework.binding.value.support.AbstractValueModel.fireValueChangeEvent(AbstractValueModel.java:172)
        at org.springframework.binding.value.support.AbstractValueModel.fireValueChange(AbstractValueModel.java:144)
        at org.springframework.binding.value.support.ValueHolder.setValue(ValueHolder.java:60)
        at org.springframework.binding.value.support.AbstractValueModel.setValueSilently(AbstractValueModel.java:54)
        at org.springframework.binding.form.support.FormModelMediatingValueModel.setValueSilently(FormModelMediatingValueModel.java:69)
        at org.springframework.binding.value.support.AbstractValueModelWrapper.setValueSilently(AbstractValueModelWrapper.java:41)
        at org.springframework.binding.form.support.DefaultFormModel$ValidatingFormValueModel.setValueSilently(DefaultFormModel.java:283)
        at org.springframework.richclient.form.binding.support.CustomBinding.controlValueChanged(CustomBinding.java:47)
        at net.objectlab.gui.binder.StringSelectionFieldBinding.access$100(StringSelectionFieldBinding.java:32)
        at net.objectlab.gui.binder.StringSelectionFieldBinding$1.propertyChange(StringSelectionFieldBinding.java:47)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:333)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:341)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:270)
        at java.awt.Component.firePropertyChange(Component.java:7159)
        at net.objectlab.gui.components.StringSelectionField.setValue(StringSelectionField.java:146)
        at net.objectlab.gui.components.ZZZSelectionField.setSelection(ZZZSelectionField.java:93)
        at net.objectlab.gui.components.ZZZSelectionField.validateCode(ZZZSelectionField.java:84)
        at net.objectlab.gui.components.StringSelectionField$2.focusLost(StringSelectionField.java:102)
        at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:172)
        at java.awt.Component.processFocusEvent(Component.java:5380)
        at java.awt.Component.processEvent(Component.java:5244)
        at java.awt.Container.processEvent(Container.java:1966)
        at java.awt.Component.dispatchEventImpl(Component.java:3955)
        at java.awt.Container.dispatchEventImpl(Container.java:2024)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1810)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:836)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:526)
        at java.awt.Component.dispatchEventImpl(Component.java:3841)
        at java.awt.Container.dispatchEventImpl(Container.java:2024)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

[jh@schaubroeck.be]

I agree, the logging should be at least a warning. Please create an issue in JIRA for this so it can be tracked.

When an exception is raised during a setValueSilently a bindingError is created and shown which internally reflects on a ValidationMessage. In most cases this means that there's a bug (eg somewhere in a listener), but it could be that you're relying on a NPE to show that this value can't be null (thus required, same goes for eg InvalidFormatExceptions ). So a warning seems more appropriate for this instead of an error.

Kind Regards,
Jan

[benoitx]

Hi Jan

I have created JIRA RCP-308 for it
http://opensource.atlassian.com/proj...browse/RCP-308

Once a binding Error is created, how would you handle it if you wanted to catch that error and, for instance, display it in a dialogue box?

imho, it would be great to have a page on wiki about error handling...

Dank u well,

Benoit

[jh@schaubroeck.be]

Thank you, I'll fix it.

Once a bindingError is raised, the DefaultFormModel will get its ValidationMessage and the same road as a normal ValidationMessage will be taken (no difference). Right now I see two options: make all your messages to appear elsewhere or override the raiseBindingError function in DefaultFormModel.

But in any case: have you already verified that the Exception is needed? What's the reason it's being thrown? Any use case?

There's still a lack of documentation, I know, spring-rcp is still an open-source community so if you want to contribute some docs or anything else, we do appreciate the effort.

Nice ending, just loose the l at the end and it's completely correct (->Dank u wel ;-) )

Graag gedaan,
Jan

[benoitx]

Hi Jan,

The exception, in my case, is a bug, I do not have any logic around an NPE. I just find it strange that throwing that exception seems to generate a "required" validation message... I'd expect say a dialogue to popup and say "ouch... something ain't quite right" (or anything in better english!)

I wonder how it would be possible to trigger a dialogue or an error reporting that'd be treated via log4j or dialogue boxes etc... it would be good if this kind of mechanism was injected, I'd not like to have to override god knows how many times the models in order to add my little "error reporting" mechanism... Unless there is something and I have not seen it...

I try to participate by "detecting" issues/adding a few components and a few suggestions here and there... Swing/GUI is not my main forte (but hey! it is improving thanks to Spring RCP!!!)

Ik heb Nederlands geleerd maar ik heb alles vergeten... especially after 15 years in London!

tot ziens,
Benoit

[lstreepy]

Hi guys,

As I look into this problem, I'm left wondering why the DefaultBindingErrorMessageProvider translates an NPE into a "required" validation message. Was it meant to catch the issue of nested properties where one component in the property path is null?

Anyway, Benoit, that's the reason that the error is displayed as a "required" validation in your application.

I would argue that reporting the exception as a warning may be inappropriate in the case of the InvalidFormat and IllegalArgument cases as these are typically thrown internally to signify the "type mismatch" and should be reported as such (via the binding error). However, in this case, it is not a programming error, it's logic control using exceptions, and it shouldn't be logged as a warning. Having a warning show up in your log every time a user enters data that doesn't convert properly would be rather annoying.

So, what to do?

1. Is it correct to translate an NPE into a required message?

2. Should we handle the typical type conversion exceptions in a special way and all other exceptions generate a warning log?

3. Should we get more specific about the contract with the value/type conversion code and require it to use a specific exception type and all others are reported as "other" binding errors and logged as a warning or error?

4. Something else real clever?

As usual, things are never as simple as they seem.

Larry.

P.S. Benoit, unfortunately, exception handling in type conversion code is often trickier than normal UI code. Mainly, because it typically relies on expected exceptions to indicate failures. However, most systems will report all other exceptions as an error.

[jh@schaubroeck.be]

Well, I surely wouldn't recommend overwriting DefaultFormModel for debugging purposes. Implementing error dialogs to catch development bugs isn't recommended, unless it's a catch-all case.

Maybe you should take a look at a visual component for logging like log4j in combination with Chainsaw? This way errors/warnings are more visible.

Regards,
Jan