I’m running a JSF-Webapplication on a GlassFish v3.1.2
If I test it locally everything works fine. Now I only change the datasource and I get some strange bevavior:
For example I have a command button which invokes some action to receive data from a database and I want to display this data in a datatable on the same page.
With my local database this works fine, but if I use the other database (which is running on a different server in the local intranet), the action is fired (I have checked this with some System.out’s) but the ajax-update of my datatable does not work. If I reload the page after clicking my ajax-button the correct data is displayed, also if I use a non-ajax-button.
I do not even know what I should look for .. any ideas?
Im using
- Primfaces 3.4.2
- JSF 2 (Mojarra)
- local Database is Oracle 10g XE
- server Database is Oracle 11g
- jdbc-driver is the latest ojdbc6.jar from oracle-website
Please let me know if you need more information.
Thanks in advance, Fant
Http-response-header: HTTP/1.1 200 OK X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2 Java/Oracle Corporation/1.7), JSF/2.0 Server: GlassFish Server Open Source Edition 3.1.2 Cache-Control: no-cache Content-Type: text/xml;charset=UTF-8 Content-Length: 5610 Date: Sat, 08 Dec 2012 02:05:08 GMT
I also tried to write a PhaseListener to give me some feedback, but this was not very helpful either. Every phase is finished succesful and after my action is performed, an response is send to the client (and the client receives the response as I can see in the Firefox-Addon)
Even the Getter-method of the List that I want to display in my dataTable is called before the htpp-response is send, so I think there is everything fine with the response itself. But the dataTable that I want to rerender is still showing the old data.
This is most likely caused by a XML syntax error. The ajax update involves the steps of retrieving the XML response from the server, parsing it and finding the to-be-updated elements in the HTML DOM tree and replacing their content with new HTML which is enclosed in the XML response. Using webbrowser’s builtin (Chrome/IE9) or 3rd party (Firebug) webdeveloper toolset you can track the HTTP traffic and inspect the HTTP response in its entirety and you can also debug JavaScript code with breakpoints. This should give you clues as to the cause of the problem.
Provided that the generated HTML code in the XML response is exactly the same (which is a fair assumption, provided that webapp’s code is not been changed when you change the datasource), then that can only be caused by a difference in the data which is obtained from the DB. Apparently the change in the datasource also involved a change in the physical database server which in turn thus provides somewhat different data.
Based on the comments on the question, the root cause turns out to be a
NULcharacter coming straight from the other DB which ended up in the XML response, causing the webbrowser’s XML parser to choke because it’s an illegal character in XML. The XML specification specifies only the following characters as valid:The
#x0(theNULcharacter) is not among them.You should have noticed a XML parsing error in the console of the webbrowser’s webdeveloper toolset.