Announcement Announcement Module
Collapse
No announcement yet.
Issue with CheckBox? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Issue with CheckBox?

    Hi

    I have a class with a Boolean attribute:

    Code:
    public class Test {
       private Boolean val;
    ... get and set
    }
    I put this attribute on a form as usual:
    Code:
    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).

    Code:
    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

  • #3
    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

    Comment


    • #4
      Error Log...

      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
      Code:
      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:

      Code:
      [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)

      Comment


      • #5
        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

        Comment


        • #6
          Jira created

          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

          Comment


          • #7
            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

            Comment


            • #8
              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

              Comment


              • #9
                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.

                Comment


                • #10
                  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

                  Comment


                  • #11
                    right on..

                    Larry,

                    You've hit the nail right on the head, as usual.

                    My issue is that the current "reporting (or lack of)" mechanism is called also when events are fired, so in effect, it becomes the main mechanism for errors... When the model changes, I may call the server and fetch some other stuff, so it is far beyond the "type conversion" issues...

                    So, as far as your options are, I'd say:
                    - option 1, definitely should be changed, NPE or required are two totally different things...
                    - option 2, yes, I'd say that the conversion errors are "different" and may not require login.

                    As for the best mechanism to do that, whether enforcing a specific exception or not... there are as usual pro and cons.

                    If we don't, we would have to put some "guesswork" in DefaultFormModel to catch the basic conversion exceptions throwns (IllegalArgument? InvalidFormat? etc).

                    If we add a specific exception, should it be runtime or not? If not, do people create a lot of conversion/binder code? it may be a pain if suddenly their code breaks because of a new exception requirement. However in my mind, this is typically where you would want an exception as you want to catch it and treat it differently from other issues like NPE and other bugs...

                    my 0.02 comments...

                    But option 1 and 2, quickly please... ;-)

                    I'm going to upgrade to the latest code now but I'm willing to spend a bit of time on this, so we could come up with something nice...

                    Best regards

                    Benoit

                    Comment


                    • #12
                      Nor am I recommending that we do so.

                      What does seem at issue is that the current implementation is hiding or masking development bugs. If we have a clean contract with the type conversion/value settnig code, then it might be easier to find the bug. If, for example, we only allowed the use of specific exceptions to indicate a conversion failure, then we could catch just those exceptions. Any other runtime exception would then percolate up to whatever global handler is installed.

                      Just some food for thought.

                      Larry.

                      Originally posted by [email protected]
                      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

                      Comment


                      • #13
                        I agree with Larry, I think that a conversion-specific exception is the way to go... The question shall this contract be enforced or not (ie RuntimeException or not...)

                        May be this conversation should be carried on the dev list?

                        Benoit

                        Comment

                        Working...
                        X