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.
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.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jan 26, 2010
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.
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.
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.
Joined: Jan 26, 2010
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.
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?
Joined: Jan 26, 2010
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.