• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

No Form Input and NullPointerException

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, I'd like to caveat my post with the fact that I am NOT an experienced JSF developer. My group provides consulting to multiple other application teams. Sometimes those teams come to us with questions/issues in technology stacks that my group is not necessarily well versed in, anyway...

We have an application team that is migrating their application from WebSphere 6 to WebSphere 7. In the course of doing so they are migrating to servlet 2.5 and JSF 1.2. They claim that in their application they initialize all of the backing bean fields of type String to an empty String "". In their code they check for empty String as a way of determining whether or not the user entered any data into the corresponding form field. The code does NOT perform null checks.

In the WebSphere 6 version of the application, when the form fields are left blank the application handles it gracefully since the back bean fields have been initialized to an empty String.

In the WebSphere 7 version of the application, when the form fields are left blank the application fails with a NullPointerException. The application team is assuming the backing bean setter methods are being invoked with a Null argument and thus the reason for the NPEs. They feel that this behavior is a result in a change in the JSF version (or possibly in servlet/JSP version???).

They claim they have made no application changes, however I've heard that story before.

Is it possible that the change in JSF version (or servlet/JSP version) would affect the behavior such that the backing bean setter methods could be invoked with a Null argument when a form field is empty?

Please note, I don't think this is an issue of using the "required" attribute, since the fields in question are optional.

Thanks
Dave
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ask them if they'll share whatever they've been smoking.

Just as an aside, what IDE (or IDE version) they use should have zero impact on the application as far as how it runs. IDE's are for development. If you are in a shop where an IDE is required to run production, start updating the résumé, fast!

No. JSF has a set of converters that translate incoming data from a submitted form. That form is HTML, and HTML is a text format, not a binary one. So there are NO nulls on the form. The default converter for Strings is simply to set the String value, so an empty field on a form will ALWAYS set an empty String, not null. That was true in JSF 1.0 and it's still true in the latest JSF2. Any nulls coming in are someone else's fault.

Without seeing any code, I can't guess what's really going on, other than to make the standard cynical observation that users never tell you the truth, the whole truth and nothing but the truth, even when the users are developers. It's vaguely possible that there's some funny business where some objects were in request scope that should be in session scope, but that's not a behavior that's changed between 1.0 and 2.x either.
 
David Howie
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Tim for the reply...

I have since gathered additional details. At this point the issue is the fact that the application declares a selectItem tag with itemValue="" within a selectOneMenu. When the page is submitted the setter method is invoked with a Null argument. The developer added a println statement to the form setter method. I observed the developer executing the use case, and sure enough the setter method is invoked with a Null argument. Below is the JSF code in question:



BTW...WebSphere 7 is the runtime, not the IDE. There was no mention of the IDE in my original post.

Bottom line:
  • In WebSphere 6 (JSF 1.0???, Servlet 2.3), when the ALL item is selected and the page is submitted, the setter method is invoked with an empty String
  • In WebSphere 7 (JSF 1.2, Servlet 2.5), when the ALL item is selected and the page is submitted, the setter method is invoked with a Null argument


  • Unfortunately, they have over 100 occurrences of selectItem with itemValue="" throughout the application, and code within the app to test for empty String. So it would be a big effort to change all the selectItems to pass something other than an empty String.

    Any additional insight would be greatly appreciated.

    Thanks
    Dave
     
    Tim Holloway
    Saloon Keeper
    Posts: 27752
    196
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Sometimes I'm blind. You'd think as might fighting with WAS as I've been doing lately, I'd make the connection, but a depressingly large number of people posting here are helpless without their IDEs and I've developed some unfortunate reflexes when I see product names.

    Usually I code a "<f:selectItem itemValue="" itemLabel="-- Make A Selection --"/> on my lists with a "required="true" attribute on the parent. But I've been working with this stuff since about 2004 and I probably would have noticed if a fundamental behavior had changed. I do recall actually trying to use null as a selection return value once and coming to grief (it returned the string "null").

    Normally, when I encounter stuff like this, I get out my trusty IDE and put a breakpoint on the "set" method so I can do a stack backtrace and see where the offending value is really coming from. Of course, since you're paying IBM for support, you might want to ask them. Note, however, that if you track it yourself that a setter can be called more than once in a JSF lifecycle process, even when there isn't any funny business going on.
     
    David Howie
    Greenhorn
    Posts: 11
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Just an FYI...

    I threw together a very simple JSF application, one JSP and one bean (both included below). I deployed the same EAR to both WAS 6 and WAS 7. Running under WAS 6, the SimpleBean.setHlqCode method is invoked with an empty String argument when the "All" item is selected in the dropdown and the page is submitted. Running under WAS 7, the SimpleBean.setHlqCode method is invoked with a null argument when the "All" item is selected in the dropdown and the page is submitted.

    I opened a PMR with IBM.





     
    Tim Holloway
    Saloon Keeper
    Posts: 27752
    196
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Well, I can't argue with that.

    There are 2 things that I would look at more closely, though.

    First, I don't believe the "set" method would be invoked on a bean unless the property value was actually changed. I could be wrong on that, but at least that's what I expect on property change listeners, so it would make sense not to update a property with its same value. No guarantees, though - I'd have to RTFM.

    Second, and more important, the bean name in the View violates good practice. Objects should be camel-case named. Class names should start with an upper-case letter, class instance names should not. There's a potential for problems there.

    Could you supply the bean instance definition that's in faces-config.xml?
     
    David Howie
    Greenhorn
    Posts: 11
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    As previously mentioned, I'm not well versed in JSF so I'm not sure what to say regarding invocation of the setter method and property change listeners.

    In my testing, everytime I submit the page the setter method is invoked. Below is the faces config, as well as the WAS 6 and WAS 7 SystemOut logs containing the System.out.println output.



    WAS 6 SystemOut:


    WAS 7 SystemOut:
     
    Tim Holloway
    Saloon Keeper
    Posts: 27752
    196
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Just for giggles, change the scope of "SimpleBean" to session.

    Incidentally, I don't believe "*" is a proper display-name in the navigation rule, although I doubt it actually affects anything.
     
    This is my favorite tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic