9 Replies Latest reply on Oct 11, 2010 7:48 PM by Stan Silvert

    rich:fileUpload (JSFUNIT-190 progress?)

    Tim Evers Master

      Hey Stan,


      Out of curiosity have you made any progress on testing rich:fileUpload components yet?

      I went to write a test (which failed) only to find out you had written one almost exactly the same (which you commented out due to it failing ).

      The only line I couldn't understand was after your click on the upload button (well, div to be exact but you know what I mean).




      Where does the value 2174 come from?


      Anyways apart from that. Do you have any idea why the test fails? Is it because the onchange event doesn't fire on the <input type="file"> thus the javascript that causes the file to upload doesn't find anything? I haven't spent a *lot* of time trying to find out where the problem lies. Was hoping you might have narrowed it down a little.


      PS link to the JIRA


        • 1. Re: rich:fileUpload (JSFUNIT-190 progress?)
          Stan Silvert Master

          Hi Tim,


          First of all, thanks for all your help with Marti.  I really appreciate it and I'm sure Marti does too.


          I haven't looked at JSFUNIT-190 in ages so I took a quick look just now to see if maybe we got lucky and this was fixed by HtmlUnit 2.8.  I didn't have any luck.  Unfortunately, I can't spend lots of time on it.  2174 is the size of the uploaded file.  So that's what I'm checking on the client side to see if it worked.


          I'm sure this is just something wrong with the way I'm using HtmlUnit.


          Hope that helps,



          • 2. Re: rich:fileUpload (JSFUNIT-190 progress?)
            marti marti Newbie

            Hi guys.

            Stan do you see any possibility that working with rich:fileUpload component become available in near future?



            • 3. Re: rich:fileUpload (JSFUNIT-190 progress?)
              Tim Evers Master

              Stan in his previous post said that he can't spend a lot of time on this so the chances of it being fixed soon is probably pretty low.


              But, I'll take another look at it this morning and see if I can get something to happen. No promises however as the problem may not exist in the JSFUnit code so we'll see how I go.

              • 4. Re: rich:fileUpload (JSFUNIT-190 progress?)
                Tim Evers Master

                OK, so I'm pretty sure now that the problem is in htmlunit or some other underlying library.


                What I've done so far is this.



                public void testUpload() { //Line 1
                    HtmlFileInput file = (HtmlFileInput) client.getElement("fileUpload:file"); //Line 2
                    file.setValueAttribute("D:/temp/html.txt"); //Line 3
                    file.fireEvent("change"); //Line 4
                    try { //Line 5
                        client.click("fileUpload:upload1"); //Line 6
                    } catch (IOException e) { //Line 7
                        throw new IllegalStateException(e); //Line 8
                    } //Line 9
                } //Line 10


                Using this code I am getting the expected actions up to and including  line 4. The row containing the file I set in line 3 is in the table of selected files.


                However, line 6 does not execute in the expected fashion. The resulting page from the click action is a completely blank html page. The server side upload listener does *NOT* get executed. I'm pretty sure this is going to be outside of my ability to even work out where the problem is, but I'll step through the code and see if I can find what's going on.


                Stan how do you normally work out where the break down is happening?

                • 5. Re: rich:fileUpload (JSFUNIT-190 progress?)
                  Tim Evers Master

                  OK, I did a bit more investigation and I think I'm at the point now where I may not be able to do much more without your help Stan.


                  I've found something that I think is a bit strange (maybe it's not but...you'll be able to tell me ).


                  I turned on a bit of logging to see what goes on during my test.

                  I'll attach the log files.


                  What is concerning me is this.


                  In the first line of the b4UploadButtonClick.txt you will see a session get created. (Normal behaviour of course) (Log line provided by a listener we have detecting new sessions)


                  Then on line 33 of afterUploadButtonClicked.txt you will see that session get destroyed. BUT, the javascript thread (I'm assuming it is the thread for the actual uploading maybe?) is still running? Because on line 168 there is an AJAXREQUEST which looks very much like it belongs to the file upload process. But this is never going to work because the session was destroyed back in line 33.


                  Does this make any sense to you?

                  • 6. Re: rich:fileUpload (JSFUNIT-190 progress?)
                    Stan Silvert Master

                    I can't imagine why a session would be destroyed at that point.  What would be calling HttpSession.invalidate()?  The upload listener maybe?


                    The way I deal with this kind of issue is to first debug as far as I can.  Then I try to write a test in plain HtmlUnit showing that HtmlUnit is not behaving the same way as the browser.  I take that sample code and open a bug report against HtmlUnit.  The HtmlUnit team is very good about fixing a problem if you give them some sample code they can run.



                    • 7. Re: rich:fileUpload (JSFUNIT-190 progress?)
                      Tim Evers Master

                      OK, well the chances of me being able to write that test any time soon is pretty low. I've spent way too long on this problem and I'm getting behind in my own work.


                      I guess I could put a break point inside my listener for when the session is destroyed and see if the stack gives me any hints as to why it is getting destroyed. However, I honestly think that it is being destroyed by the test finishing.


                      I just went and added a tear down method and sure enough, the tear down is being called then the session gets destroyed. The session.invalidate is being called by the JSFUnitServletRedirector in the doPost(request, response) method. It calls cleanUp (same class) which does the session cleanup stuff.


                      So, my guess is that control is returning from httpunit back to JSFUnit before the ajax file upload has been completed or even started for that matter by the looks. The thread running the javascript is not blocking the main thread (or so it seems).


                      How I can write a simple test for this though is a pretty tough one. Do they care if we use richfaces etc in the test?


                      Maybe if you attach a test that you wrote for them once before I can modify it to show this problem?

                      I guess the problem is though that I still haven't proven who's code is wrong. But, I can't really see how it could be JSFUnit's fault.

                      • 8. Re: rich:fileUpload (JSFUNIT-190 progress?)
                        marti marti Newbie

                        hey Tim.

                        Thanks for all these progresses.

                        as a matter of fact I have the same senario. (or at least close to yours)

                        My test ends before uploading exeption throws. I  mean I get what I have in tearDown() method and then suddenly error was thrown.


                        this is very similar to the case that I was calling page.refresh() to get the ajax changes (client becomes synched with ajax fired action) .

                        • 9. Re: rich:fileUpload (JSFUNIT-190 progress?)
                          Stan Silvert Master

                          How I can write a simple test for this though is a pretty tough one. Do they care if we use richfaces etc in the test?


                          Maybe if you attach a test that you wrote for them once before I can modify it to show this problem?


                          This bug includes the SVN link for a project that I use to create HtmlUnit/RichFaces tests that demonstrate HtmlUnit problems.



                          I've done several of them in that project.  The code is ugly, but it should get you started.