jwebunit-users — For questions and problems when using JWebUnit.

Re: [JWebUnit-users] clickElementByXPath failing

[Parham, C. <cp...@bi...>]

Hi Julien,

Thank you for replying.

I have attached the asXML dump of the page after Thread.sleep(10000) to account for AJAX activity. 

When I open the dumped content in Chrome and enter the following into the JavaScript console, the "tr" I'm trying to click is found: 
$x("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']")

Looking forward to your perspective.

Clint

-----Original Message-----
From: Julien HENRY [mailto:he...@ya...] 
Sent: Friday, August 17, 2012 3:25 AM
To: Usage problems for JWebUnit
Subject: Re: [JWebUnit-users] clickElementByXPath failing

Hi,

I've just tested to locate a tr element by id using the same xpath expression and it is working fine. Are you not encountering timing issue? If you are using AJAX to update the page there could be different results depending on execution speed.

Concerning diference between getPageSource and asXml Jevon is right: getPageSource returns the original source returned by the server while asXml is a dump of the current state of the DOM.

Could you please send us the result of asXml() when your test failed?

Regards,

Julien


----- Mail original -----
> De : "Parham, Clinton" <cp...@bi...>
> À : Usage problems for JWebUnit <jwe...@li...>
> Cc : 
> Envoyé le : Vendredi 17 août 2012 4h57
> Objet : Re: [JWebUnit-users] clickElementByXPath failing
> 
> When executing getElementsByXPath("//tr") I get back 88 matches.
> 
> But it gets more interesting:
> 
> The following (from my original clickElementByXPath) returns zero matches:
> getElementsByXPath("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']");
> 
> But this returns what I'm looking for (only changed "tr" to 
> "*"):
> getElementsByXPath("//*[@id='genTabViewId:genTabFrm:availableGroups:source::0']");
> 
> This is what the debugger returns when Inspecting the return value of the above 
> statement - you can see it is a "tr":
> [IElement[name=tr wrapped=HtmlTableRow[<tr 
> class="rich-picklist-source-row" 
> id="genTabViewId:genTabFrm:availableGroups:source::0">]]]
> 
> I would expect consistent results when calling both of these getElementsByXPath 
> methods. What's going on?
> 
> Thanks.
> 
> -----Original Message-----
> From: jevon [mailto:je...@je...] 
> Sent: Thursday, August 16, 2012 8:56 PM
> To: Usage problems for JWebUnit
> Subject: Re: [JWebUnit-users] clickElementByXPath failing
> 
> Hi,
> 
> I can't look at the JWebUnit source right now, but it sounds like
> getPageSource() just dumps out the original source of the page, i.e.
> without Javascript DOM modifications, whereas page.asXml() dumps the
> runtime content of the page itself, i.e. after Javascript/AJAX has
> modified the page. Or perhaps the source page does not validate, thus
> some of the elements are lost.
> 
> What happens if you execute getElementsByXPath("//tr")?
> 
> Cheers
> Jevon
> 
> On Fri, Aug 17, 2012 at 8:47 AM, Parham, Clinton <cp...@bi...> 
> wrote:
>>  Hello,
>> 
>>  We're using JWebUnit 3 to test a JSF web application that uses JBoss 
> RichFaces AJAX enabled components.
>> 
>>  At one point in the test, a call to 
> clickElementByXPath("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']") 
> is made but it fails with this:
>> 
>>  java.lang.AssertionError: Unable to locate element with xpath 
> "//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']"
>>          at org.junit.Assert.fail(Assert.java:91)
>>          at org.junit.Assert.assertTrue(Assert.java:43)
>>          at 
> net.sourceforge.jwebunit.junit.WebTester.assertElementPresentByXPath(WebTester.java:2109)
>>          at 
> net.sourceforge.jwebunit.junit.WebTester.clickElementByXPath(WebTester.java:2673)
>>          at 
> com.xyz.util.EnrollmentUtil.setGeneralTabFields(EnrollmentUtiljava:165)
>>          ...
>> 
>>  Just before making the clickElementByXPath call, we execute 
> Thread.sleep(5000) to account for AJAX activity and then we dump the page 
> content two ways to see what's going on:
>>  [1] FileUtils.writeStringToFile(new File(filename), getPageSource());
>>  and
>>  [2] HtmlUnitTestingEngineImpl engine = (HtmlUnitTestingEngineImpl) 
> getTestingEngine();
>>  HtmlPage page = ((HtmlPage) engine.getCurrentWindow().getEnclosedPage());
>>  FileUtils.writeStringToFile(new File(filename), page.asXml());
>> 
>>  The dumps are different which is quite surprising. When viewing the file 
> generated by method [1] in Chrome, the "tr" element is not present. 
> But it is present when viewing the file generated by method [2].
>> 
>>  What is happening?
>> 
>> 
>>  The contents contained herein may contain confidential information. If you 
> are not the intended recipient, you are hereby notified that any disclosure, 
> copying, distribution, printing or action taken on the contents is strictly 
> prohibited. If you have received this email in error, please notify the sender 
> immediately and delete this message.
>> 
>> 
> ------------------------------------------------------------------------------
>>  Live Security Virtual Conference
>>  Exclusive live event will cover all the ways today's security and
>>  threat landscape has changed and how IT managers can respond. Discussions
>>  will include endpoint security, mobile security and the latest in malware
>>  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>  _______________________________________________
>>  JWebUnit-users mailing list
>>  JWe...@li...
>>  https://lists.sourceforge.net/lists/listinfo/jwebunit-users
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
> 

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
JWebUnit-users mailing list
JWe...@li...
https://lists.sourceforge.net/lists/listinfo/jwebunit-users

Re: [JWebUnit-users] clickElementByXPath failing

[Julien H. <he...@ya...>]

Hi,

I've just tested to locate a tr element by id using the same xpath expression and it is working fine. Are you not encountering timing issue? If you are using AJAX to update the page there could be different results depending on execution speed.

Concerning diference between getPageSource and asXml Jevon is right: getPageSource returns the original source returned by the server while asXml is a dump of the current state of the DOM.

Could you please send us the result of asXml() when your test failed?

Regards,

Julien


----- Mail original -----
> De : "Parham, Clinton" <cp...@bi...>
> À : Usage problems for JWebUnit <jwe...@li...>
> Cc : 
> Envoyé le : Vendredi 17 août 2012 4h57
> Objet : Re: [JWebUnit-users] clickElementByXPath failing
> 
> When executing getElementsByXPath("//tr") I get back 88 matches.
> 
> But it gets more interesting:
> 
> The following (from my original clickElementByXPath) returns zero matches:
> getElementsByXPath("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']");
> 
> But this returns what I'm looking for (only changed "tr" to 
> "*"):
> getElementsByXPath("//*[@id='genTabViewId:genTabFrm:availableGroups:source::0']");
> 
> This is what the debugger returns when Inspecting the return value of the above 
> statement - you can see it is a "tr":
> [IElement[name=tr wrapped=HtmlTableRow[<tr 
> class="rich-picklist-source-row" 
> id="genTabViewId:genTabFrm:availableGroups:source::0">]]]
> 
> I would expect consistent results when calling both of these getElementsByXPath 
> methods. What's going on?
> 
> Thanks.
> 
> -----Original Message-----
> From: jevon [mailto:je...@je...] 
> Sent: Thursday, August 16, 2012 8:56 PM
> To: Usage problems for JWebUnit
> Subject: Re: [JWebUnit-users] clickElementByXPath failing
> 
> Hi,
> 
> I can't look at the JWebUnit source right now, but it sounds like
> getPageSource() just dumps out the original source of the page, i.e.
> without Javascript DOM modifications, whereas page.asXml() dumps the
> runtime content of the page itself, i.e. after Javascript/AJAX has
> modified the page. Or perhaps the source page does not validate, thus
> some of the elements are lost.
> 
> What happens if you execute getElementsByXPath("//tr")?
> 
> Cheers
> Jevon
> 
> On Fri, Aug 17, 2012 at 8:47 AM, Parham, Clinton <cp...@bi...> 
> wrote:
>>  Hello,
>> 
>>  We're using JWebUnit 3 to test a JSF web application that uses JBoss 
> RichFaces AJAX enabled components.
>> 
>>  At one point in the test, a call to 
> clickElementByXPath("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']") 
> is made but it fails with this:
>> 
>>  java.lang.AssertionError: Unable to locate element with xpath 
> "//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']"
>>          at org.junit.Assert.fail(Assert.java:91)
>>          at org.junit.Assert.assertTrue(Assert.java:43)
>>          at 
> net.sourceforge.jwebunit.junit.WebTester.assertElementPresentByXPath(WebTester.java:2109)
>>          at 
> net.sourceforge.jwebunit.junit.WebTester.clickElementByXPath(WebTester.java:2673)
>>          at 
> com.xyz.util.EnrollmentUtil.setGeneralTabFields(EnrollmentUtiljava:165)
>>          ...
>> 
>>  Just before making the clickElementByXPath call, we execute 
> Thread.sleep(5000) to account for AJAX activity and then we dump the page 
> content two ways to see what's going on:
>>  [1] FileUtils.writeStringToFile(new File(filename), getPageSource());
>>  and
>>  [2] HtmlUnitTestingEngineImpl engine = (HtmlUnitTestingEngineImpl) 
> getTestingEngine();
>>  HtmlPage page = ((HtmlPage) engine.getCurrentWindow().getEnclosedPage());
>>  FileUtils.writeStringToFile(new File(filename), page.asXml());
>> 
>>  The dumps are different which is quite surprising. When viewing the file 
> generated by method [1] in Chrome, the "tr" element is not present. 
> But it is present when viewing the file generated by method [2].
>> 
>>  What is happening?
>> 
>> 
>>  The contents contained herein may contain confidential information. If you 
> are not the intended recipient, you are hereby notified that any disclosure, 
> copying, distribution, printing or action taken on the contents is strictly 
> prohibited. If you have received this email in error, please notify the sender 
> immediately and delete this message.
>> 
>> 
> ------------------------------------------------------------------------------
>>  Live Security Virtual Conference
>>  Exclusive live event will cover all the ways today's security and
>>  threat landscape has changed and how IT managers can respond. Discussions
>>  will include endpoint security, mobile security and the latest in malware
>>  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>  _______________________________________________
>>  JWebUnit-users mailing list
>>  JWe...@li...
>>  https://lists.sourceforge.net/lists/listinfo/jwebunit-users
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
> 

Re: [JWebUnit-users] clickElementByXPath failing

[Parham, C. <cp...@bi...>]

When executing getElementsByXPath("//tr") I get back 88 matches.

But it gets more interesting:

The following (from my original clickElementByXPath) returns zero matches:
getElementsByXPath("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']");

But this returns what I'm looking for (only changed "tr" to "*"):
getElementsByXPath("//*[@id='genTabViewId:genTabFrm:availableGroups:source::0']");

This is what the debugger returns when Inspecting the return value of the above statement - you can see it is a "tr":
[IElement[name=tr wrapped=HtmlTableRow[<tr class="rich-picklist-source-row" id="genTabViewId:genTabFrm:availableGroups:source::0">]]]

I would expect consistent results when calling both of these getElementsByXPath methods. What's going on?

Thanks.

-----Original Message-----
From: jevon [mailto:je...@je...] 
Sent: Thursday, August 16, 2012 8:56 PM
To: Usage problems for JWebUnit
Subject: Re: [JWebUnit-users] clickElementByXPath failing

Hi,

I can't look at the JWebUnit source right now, but it sounds like
getPageSource() just dumps out the original source of the page, i.e.
without Javascript DOM modifications, whereas page.asXml() dumps the
runtime content of the page itself, i.e. after Javascript/AJAX has
modified the page. Or perhaps the source page does not validate, thus
some of the elements are lost.

What happens if you execute getElementsByXPath("//tr")?

Cheers
Jevon

On Fri, Aug 17, 2012 at 8:47 AM, Parham, Clinton <cp...@bi...> wrote:
> Hello,
>
> We're using JWebUnit 3 to test a JSF web application that uses JBoss RichFaces AJAX enabled components.
>
> At one point in the test, a call to clickElementByXPath("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']") is made but it fails with this:
>
> java.lang.AssertionError: Unable to locate element with xpath "//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']"
>         at org.junit.Assert.fail(Assert.java:91)
>         at org.junit.Assert.assertTrue(Assert.java:43)
>         at net.sourceforge.jwebunit.junit.WebTester.assertElementPresentByXPath(WebTester.java:2109)
>         at net.sourceforge.jwebunit.junit.WebTester.clickElementByXPath(WebTester.java:2673)
>         at com.xyz.util.EnrollmentUtil.setGeneralTabFields(EnrollmentUtiljava:165)
>         ...
>
> Just before making the clickElementByXPath call, we execute Thread.sleep(5000) to account for AJAX activity and then we dump the page content two ways to see what's going on:
> [1] FileUtils.writeStringToFile(new File(filename), getPageSource());
> and
> [2] HtmlUnitTestingEngineImpl engine = (HtmlUnitTestingEngineImpl) getTestingEngine();
> HtmlPage page = ((HtmlPage) engine.getCurrentWindow().getEnclosedPage());
> FileUtils.writeStringToFile(new File(filename), page.asXml());
>
> The dumps are different which is quite surprising. When viewing the file generated by method [1] in Chrome, the "tr" element is not present. But it is present when viewing the file generated by method [2].
>
> What is happening?
>
>
> The contents contained herein may contain confidential information. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or action taken on the contents is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete this message.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
JWebUnit-users mailing list
JWe...@li...
https://lists.sourceforge.net/lists/listinfo/jwebunit-users

Re: [JWebUnit-users] clickElementByXPath failing

[jevon <je...@je...>]

Hi,

I can't look at the JWebUnit source right now, but it sounds like
getPageSource() just dumps out the original source of the page, i.e.
without Javascript DOM modifications, whereas page.asXml() dumps the
runtime content of the page itself, i.e. after Javascript/AJAX has
modified the page. Or perhaps the source page does not validate, thus
some of the elements are lost.

What happens if you execute getElementsByXPath("//tr")?

Cheers
Jevon

On Fri, Aug 17, 2012 at 8:47 AM, Parham, Clinton <cp...@bi...> wrote:
> Hello,
>
> We're using JWebUnit 3 to test a JSF web application that uses JBoss RichFaces AJAX enabled components.
>
> At one point in the test, a call to clickElementByXPath("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']") is made but it fails with this:
>
> java.lang.AssertionError: Unable to locate element with xpath "//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']"
>         at org.junit.Assert.fail(Assert.java:91)
>         at org.junit.Assert.assertTrue(Assert.java:43)
>         at net.sourceforge.jwebunit.junit.WebTester.assertElementPresentByXPath(WebTester.java:2109)
>         at net.sourceforge.jwebunit.junit.WebTester.clickElementByXPath(WebTester.java:2673)
>         at com.xyz.util.EnrollmentUtil.setGeneralTabFields(EnrollmentUtiljava:165)
>         ...
>
> Just before making the clickElementByXPath call, we execute Thread.sleep(5000) to account for AJAX activity and then we dump the page content two ways to see what's going on:
> [1] FileUtils.writeStringToFile(new File(filename), getPageSource());
> and
> [2] HtmlUnitTestingEngineImpl engine = (HtmlUnitTestingEngineImpl) getTestingEngine();
> HtmlPage page = ((HtmlPage) engine.getCurrentWindow().getEnclosedPage());
> FileUtils.writeStringToFile(new File(filename), page.asXml());
>
> The dumps are different which is quite surprising. When viewing the file generated by method [1] in Chrome, the "tr" element is not present. But it is present when viewing the file generated by method [2].
>
> What is happening?
>
>
> The contents contained herein may contain confidential information. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or action taken on the contents is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete this message.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users

[JWebUnit-users] clickElementByXPath failing

[Parham, C. <cp...@bi...>]

Hello,

We're using JWebUnit 3 to test a JSF web application that uses JBoss RichFaces AJAX enabled components.

At one point in the test, a call to clickElementByXPath("//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']") is made but it fails with this:

java.lang.AssertionError: Unable to locate element with xpath "//tr[@id='genTabViewId:genTabFrm:availableGroups:source::0']"
        at org.junit.Assert.fail(Assert.java:91)
        at org.junit.Assert.assertTrue(Assert.java:43)
        at net.sourceforge.jwebunit.junit.WebTester.assertElementPresentByXPath(WebTester.java:2109)
        at net.sourceforge.jwebunit.junit.WebTester.clickElementByXPath(WebTester.java:2673)
        at com.xyz.util.EnrollmentUtil.setGeneralTabFields(EnrollmentUtil.java:165)
        ...

Just before making the clickElementByXPath call, we execute Thread.sleep(5000) to account for AJAX activity and then we dump the page content two ways to see what's going on:
[1] FileUtils.writeStringToFile(new File(filename), getPageSource());
and
[2] HtmlUnitTestingEngineImpl engine = (HtmlUnitTestingEngineImpl) getTestingEngine();
HtmlPage page = ((HtmlPage) engine.getCurrentWindow().getEnclosedPage());
FileUtils.writeStringToFile(new File(filename), page.asXml());

The dumps are different which is quite surprising. When viewing the file generated by method [1] in Chrome, the "tr" element is not present. But it is present when viewing the file generated by method [2].

What is happening?


The contents contained herein may contain confidential information. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or action taken on the contents is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete this message.

Re: [JWebUnit-users] jwebunit cannot run servlet?

[Julien H. <he...@ya...>]

Hi,

HtmlUnit (and as a result JWebUnit) doesn't download images by default (this is a headless browser). You can try solutions proposed here: 

http://stackoverflow.com/questions/2244272/how-can-i-tell-htmlunits-webclient-to-download-images-and-css


Or simply try
URL url = new URL(baseUrl + "AuthImage.do");
url.getContent();


Regards,

Julien
>________________________________
> De : 李麒慶 <e4...@gm...>
>À : jwe...@li... 
>Envoyé le : Samedi 4 août 2012 5h22
>Objet : [JWebUnit-users] jwebunit cannot run servlet?
> 
>
> I am try to test a page for Registration
>Here is some part of the registration.jsp code:
>
>
><label><span class="text" style="font-size:24px;"><img border=0 src="AuthImage.do" alt=""/></span></label></td>
>
>
>AuthImage.do is the java source code ,it generates Verification code and return an image to the registration.jsp, user then 
>types the number for what they see in the image.
>
>
>However, when I use JWebunit to test, it seems not automatically run AuthImage.do to generate image.
>Is JWebunit doesn't support this unless we use such like (<form name="registerform" action=" AuthImage .do" method="post">)?
>But the AuthImage.do needs load before user submit the form,so is there any solution for this?
>
>
>Thank you for your advice.
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and 
>threat landscape has changed and how IT managers can respond. Discussions 
>will include endpoint security, mobile security and the latest in malware 
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>JWebUnit-users mailing list
>JWe...@li...
>https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>
>
>

[JWebUnit-users] jwebunit cannot run servlet?

[李麒慶 <e4...@gm...>]

 I am try to test a page for Registration
Here is some part of the registration.jsp code:

<label><span class="text" style="font-size:24px;"><img border=0
src="AuthImage.do" alt=""/></span></label></td>

AuthImage.do is the java source code ,it generates Verification code and
return an image to the registration.jsp, user then
types the number for what they see in the image.

However, when I use JWebunit to test, it seems not automatically
run AuthImage.do to generate image.
Is JWebunit doesn't support this unless we use such like (<form
name="registerform" action=" AuthImage .do" method="post">)?
But the AuthImage.do needs load before user submit the form,so is there any
solution for this?

Thank you for your advice.

Re: [JWebUnit-users] Is this project still active?

[Julien H. <he...@ya...>]

Hi,

HtmlUnit engine is mature and only require a new release when
 a bug is found (test case + patch are welcome) or when there is a new 
release of HtmlUnit (in fact it is not required as long as HtmlUnit API 
do not change as users can override HtmlUnit dependency).

Selenium
 engine is not completed. I did my best to implement JWebUnit interface 
with Selenium. The purpose is to allow people to use JWebUnit API but 
switch from HtmlUnit to Selenium in order to take advantage of real 
browser testing. AFAIR there was 80% of tests passing. Remaining 20% are
 complicated/impossible to implement without breaking JWebUnit API. The 
reason is that JWebUnit exposes some functionalities that are tighly 
coupled with HtmlUnit. For example, here are some topics that are not 
working :
  - support of JavaScript alerts/confirm/prompt
  - support of advanced request/response interactions (getting HTTP status code, changing headers/cookies, redirect, ...)


Selenium
 1 was a direct concurrent of JWebUnit (a simple API to deal with test 
automation). 2 years ago if you had asked me I would have said JWebUnit 
would slowly die in favor of Selenium.

Selenium 2/WebDriver is 
advertised as a low level common API to drive Web Browsers [1]. IMHO 
Selenium 2/WebDriver is at the same level/purpose than the 
ITestingEngine. That's why I now think JWebUnit is still a valuable tool
 to add advanced functionalities/glue on top of Selenium 2 API.


Regards,

Julien

[1] http://code.google.com/p/selenium/wiki/FrequentlyAskedQuestions#Q:_What_does_it_mean_to_be_%22developer_focused%22?


----- Mail original -----
> De : Tim Pizey <ti...@pa...>
> À : Usage problems for JWebUnit <jwe...@li...>
> Cc : 
> Envoyé le : Mardi 3 juillet 2012 10h31
> Objet : Re: [JWebUnit-users] Is this project still active?
> 
> On 2 July 2012 18:40, Tony Anecito wrote:
>> 
>>  Hi,
>> 
>>  I am looking into using JWebUnit for projects at work but I noticed it 
> looks like there has not been activity for nearly a year either in development 
> or mail list postings. So is it still active and if so what is the status of the 
> selenium addon and are there some frameworks code wise to add data driven or 
> keyword driven capability?
>> 
>>  Thanks,
>>  -Tony
> 
> Hi Tony,
> 
> The project is working fine for me. Any question is immediately responded to.
> I have seen one bug reported by a used, fixed and a new release made.
> So yes there is little activity but the developers still take pride in
> a good tool.
> I think it is a finished project: it does what it says.
> 
> cheers
> Tim
> 
> 
> --
> Tim Pizey
> http://pizey.net/~timp
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
> 

Re: [JWebUnit-users] Is this project still active?

[Tim P. <ti...@pa...>]

On 2 July 2012 18:40, Tony Anecito wrote:
>
> Hi,
>
> I am looking into using JWebUnit for projects at work but I noticed it looks like there has not been activity for nearly a year either in development or mail list postings. So is it still active and if so what is the status of the selenium addon and are there some frameworks code wise to add data driven or keyword driven capability?
>
> Thanks,
> -Tony

Hi Tony,

The project is working fine for me. Any question is immediately responded to.
I have seen one bug reported by a used, fixed and a new release made.
So yes there is little activity but the developers still take pride in
a good tool.
I think it is a finished project: it does what it says.

cheers
Tim


--
Tim Pizey
http://pizey.net/~timp

Re: [JWebUnit-users] Is this project still active?

[jevon <je...@je...>]

Hi Tony,

The project is still maintained (recently updated to JUnit 4, for example)
but if you would like to submit some contributions they would be most
welcome!

I think most of the focus for JWebUnit has been on the HtmlUnit interface,
I don't have any experience with Selenium so maybe one of the other
maintainers can give you some pointers... what do you mean by data-driven
or keyword-driven capabilities?

Cheers
Jevon

On Tue, Jul 3, 2012 at 5:40 AM, Tony Anecito <ada...@ya...> wrote:

> Hi,
>
> I am looking into using JWebUnit for projects at work but I noticed it
> looks like there has not been activity for nearly a year either in
> development or mail list postings. So is it still active and if so what is
> the status of the selenium addon and are there some frameworks code wise to
> add data driven or keyword driven capability?
>
> Thanks,
> -Tony
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>
>

[JWebUnit-users] Is this project still active?

[Tony A. <ada...@ya...>]

Hi,
 
I am looking into using JWebUnit for projects at work but I noticed it looks like there has not been activity for nearly a year either in development or mail list postings. So is it still active and if so what is the status of the selenium addon and are there some frameworks code wise to add data driven or keyword driven capability?

Thanks,
-Tony

Re: [JWebUnit-users] Need help for LoginFailureTestCase scenario.

[Jevon W. <je...@je...>]

Hi Harsha,

Please reply to the JWebUnit users list.

We can't help you any further without more information. What were the
results of your debugging? Were the text fields being set? Did the
page content change at all when submitting the form? Perhaps this will
help you resolve the problem.

Cheers
Jevon

On Thu, Mar 15, 2012 at 8:04 PM, Harsha Puttaswamy
<har...@is...> wrote:
> Hi there,
>
>
>
> I appreciate your reply in short period of time,
>
>
>
> Yes I tried debugging with the specified method.
>
> No, I am not using AJAX for login. I am using .xhtml
>
>
>
> Thanks and Regards,
>
>
>
> Harsha Puttaswamy
>
> From: sou...@gm... [mailto:sou...@gm...] On Behalf Of
> Jevon Wright
> Sent: Thursday, March 15, 2012 1:39 AM
> To: Harsha Puttaswamy
> Cc: jwe...@li...
> Subject: Re: Need help for LoginFailureTestCase scenario.
>
>
>
> Hi Harsha,
>
> Have you tried debugging the page by using methods such as getPageSource()?
>
> Are you using AJAX for login? You might need to set the
> NicelyResynchronizingAjaxController.
>
>
> Cheers
>
>
>
> On Thu, Mar 15, 2012 at 3:08 AM, Harsha Puttaswamy
> <har...@is...> wrote:
>
> Hi,
>
>
>
> I am using JWebUnit for a week now. I have struck in writing test case
> responsible to find out login fail.
>
> For this I want to track the “Login failed” message displayed on the web
> page.
>
>
>
> Problem : I am calling login action in my login.xhtml page. Seam security
> renders messages by org.jboss.security.identity class.
>
> ---------------------------------------------------
>
> Code:
>
> package com.isoty.mnpJUnit.action;
>
>
>
> import net.sourceforge.jwebunit.junit.WebTester;
>
>
>
> import org.junit.AfterClass;
>
> import org.junit.Before;
>
> import org.junit.Test;
>
>
>
> public class JWebUnitTestTest{
>
>
>
>       WebTester tester;
>
>
>
>       @Before
>
>       public void setUp(){
>
>
>
>             tester = new WebTester();
>
>             tester.setBaseUrl("http://localhost:8080/mnpJUnit"); //Setting
> up the base url where the home page is rendered
>
>       }
>
> @Test
>
>     public void testLoginFailureTest() {
>
>
>
>         tester.beginAt("/login.seam");                //Begin the operation
> on                             http://localhost:8080/mnpJUnit/login.seam
>
>         tester.assertTitleEquals("mnpJUnit");   // we should be on the login
> page, but the page name we have given as mnpJUnit
>
>
>
>         // fill out the form
>
>         tester.assertLinkNotPresent("Logout");  // we should not be logged
> in
>
>         tester.assertFormPresent("loginForm");  //The form name
>
>         tester.assertFormElementPresent("loginForm:username");
>
>         tester.assertFormElementPresent("loginForm:password");
>
>         tester.setTextField("loginForm:username", "xyz");
>
>         tester.setTextField("loginForm:password", "1234");
>
>         tester.submit();
>
>         tester.assertMatch("Login failed"); //Here, at this point the test
> is failing. Since the message is rendered by calling action class, it is not
> able to track this failed message from current page.
>
>
>
> }
>
> ---------------------------------------------
>
> Log:
>
>
>
> java.lang.AssertionError: Expected rexexp not matched in response: [Login
> failed]
>
>             at org.junit.Assert.fail(Assert.java:93)
>
>             at
> net.sourceforge.jwebunit.junit.WebTester.assertMatch(WebTester.java:520)
>
>             at
> com.isoty.mnpJUnit.action.JWebUnitTestTest.tearDown(JWebUnitTestTest.java:63)
>
>             at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>             at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>
>             at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
>
>             at java.lang.reflect.Method.invoke(Unknown Source)
>
>             at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>
>             at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>
>             at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>
>             at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
>
>             at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>
>             at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
>
>             at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>
>             at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>
>             at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>
>             at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>
>             at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>
>
>
>
>
>
>
> Thanks and Regards,
>
> Harsha Puttaswamy
>
>
>
> iSoty Software Services Pvt Ltd.
>
> #Incubation Center 3, SJCE-STEP.
> JSS Technical Institutions, SJCE Campus.
> Mysore, KARNATAKA, INDIA.
> PIN -570006
>
>
>
>

Re: [JWebUnit-users] script is not executing when required

[dao <dao...@gm...>]

you mean 'is NOT supported by..'?

On Mon, Oct 31, 2011 at 9:56 AM, Julien HENRY <he...@ya...> wrote:

> Hi Dao,
>
> I don't think SVG is supported by HTMLUnit. See [1].
>
> Regards,
>
> Julien
>
>
> [1]
> http://sourceforge.net/tracker/index.php?func=detail&aid=3313921&group_id=47038&atid=448266
>
>
>
>
> >________________________________
> >De : dao <dao...@gm...>
> >À : jwe...@li...
> >Envoyé le : Dimanche 30 Octobre 2011 8h10
> >Objet : [JWebUnit-users] script is not executing when required
> >
> >
> >hello,
> >
> >
> >I am new in jwebunit, I am faced to a strange behavior. I have a script
> like this:
> >
> >
> ><object type="image/svg+xml" data="mySvg.svg" id="svgFigure"
> style="display:inline;"></object>
> >><script>
> >>//once the SVG is loaded, we create the SVG analysis
> >>$(window).load(function () {
> >>        var a = document.getElementById("svgFigure");
> >>        var svgDoc = a.contentDocument; //get the inner DOM of alpha.svg
> >>        //access the svg dom tree. In my browser, svgDoc is not null.
> With jwebunit, it is null.
> >>    });</script>
> >>
> >
> >In my browser, svgDoc is not null. With jwebunit, it is null. It seems
> that the function the function is called before the svg object is loaded.
> >
> >
> >How can I handle it?
> >
> >
> >here is my test code snippet:
> >public class DashboardTest extends FunctionalTest {
> >>private WebTester w;
> >>@Before
> >>    public void prepare() {
> >>w = new WebTester();
> >>Fixtures.deleteDatabase();
> >>Fixtures.loadModels("initEmpty.yaml");
> >>        w.setBaseUrl("http://localhost:9000/";);
> >>    }
> >>
> >>
> >>@Test
> >>public void addDashboard() {
> >>    //log as user
> >>    w.beginAt("login");
> >>    if (w.getTestingEngine() instanceof HtmlUnitTestingEngineImpl)
> >>    {
> >>    //((HtmlUnitTestingEngineImpl)
> w.getTestingEngine()).getWebClient().setThrowExceptionOnScriptError(false);
> >>       //((HtmlUnitTestingEngineImpl)
> w.getTestingEngine()).getWebClient().setAjaxController(new
> NicelyResynchronizingAjaxController());
> >>    }
> >>
> >>
> >>    //check the AC list is fetch OK.
> >>    w.setTextField("username", "dao...@gm...");
> >>    w.setTextField("password", "xxx");
> >>    w.clickButton("signin");
> >>    w.clickLink("dashboardList");
> >>    w.clickLink("newDashboard");
> >>    w.assertTitleEquals("flightwatching - edit dashboard");
> >>}
> >
> >
> >--
> >Dao Hodac
> >
>
> >------------------------------------------------------------------------------
> >Get your Android app more play: Bring it to the BlackBerry PlayBook
> >in minutes. BlackBerry App World™ now supports Android™ Apps
> >for the BlackBerry&reg; PlayBook™. Discover just how easy and simple
> >it is! http://p.sf.net/sfu/android-dev2dev
> >
> >_______________________________________________
> >JWebUnit-users mailing list
> >JWe...@li...
> >https://lists.sourceforge.net/lists/listinfo/jwebunit-users
> >
> >
> >
>
>
> ------------------------------------------------------------------------------
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World&#153; now supports Android&#153; Apps
> for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>



-- 
Dao Hodac

Re: [JWebUnit-users] script is not executing when required

[Julien H. <he...@ya...>]

Hi Dao,

I don't think SVG is supported by HTMLUnit. See [1].

Regards,

Julien


[1] http://sourceforge.net/tracker/index.php?func=detail&aid=3313921&group_id=47038&atid=448266




>________________________________
>De : dao <dao...@gm...>
>À : jwe...@li...
>Envoyé le : Dimanche 30 Octobre 2011 8h10
>Objet : [JWebUnit-users] script is not executing when required
>
>
>hello,
>
>
>I am new in jwebunit, I am faced to a strange behavior. I have a script like this:
>
>
><object type="image/svg+xml" data="mySvg.svg" id="svgFigure" style="display:inline;"></object>
>><script>
>>//once the SVG is loaded, we create the SVG analysis
>>$(window).load(function () {
>>        var a = document.getElementById("svgFigure");
>>        var svgDoc = a.contentDocument; //get the inner DOM of alpha.svg
>>        //access the svg dom tree. In my browser, svgDoc is not null. With jwebunit, it is null.
>>    });</script>
>>
>
>In my browser, svgDoc is not null. With jwebunit, it is null. It seems that the function the function is called before the svg object is loaded.
>
>
>How can I handle it?
>
>
>here is my test code snippet:
>public class DashboardTest extends FunctionalTest {
>>private WebTester w;
>>@Before
>>    public void prepare() {
>>w = new WebTester();
>>Fixtures.deleteDatabase();
>>Fixtures.loadModels("initEmpty.yaml");
>>        w.setBaseUrl("http://localhost:9000/";);
>>    }
>>
>>
>>@Test
>>public void addDashboard() {
>>    //log as user
>>    w.beginAt("login");
>>    if (w.getTestingEngine() instanceof HtmlUnitTestingEngineImpl)
>>    {
>>    //((HtmlUnitTestingEngineImpl) w.getTestingEngine()).getWebClient().setThrowExceptionOnScriptError(false);
>>       //((HtmlUnitTestingEngineImpl) w.getTestingEngine()).getWebClient().setAjaxController(new NicelyResynchronizingAjaxController());
>>    }
>>
>>
>>    //check the AC list is fetch OK.
>>    w.setTextField("username", "dao...@gm...");
>>    w.setTextField("password", "xxx");
>>    w.clickButton("signin");
>>    w.clickLink("dashboardList");
>>    w.clickLink("newDashboard");
>>    w.assertTitleEquals("flightwatching - edit dashboard");
>>}
>
>
>-- 
>Dao Hodac
>
>------------------------------------------------------------------------------
>Get your Android app more play: Bring it to the BlackBerry PlayBook 
>in minutes. BlackBerry App World™ now supports Android™ Apps 
>for the BlackBerry&reg; PlayBook™. Discover just how easy and simple 
>it is! http://p.sf.net/sfu/android-dev2dev
>
>_______________________________________________
>JWebUnit-users mailing list
>JWe...@li...
>https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>
>
>

[JWebUnit-users] script is not executing when required

[dao <dao...@gm...>]

hello,

I am new in jwebunit, I am faced to a strange behavior. I have a script
like this:

<object type="image/svg+xml" data="mySvg.svg" id="svgFigure"
style="display:inline;"></object>
<script>

//once the SVG is loaded, we create the SVG analysis

$(window).load(function () {

        var a = document.getElementById("svgFigure");

        var svgDoc = a.contentDocument; //get the inner DOM of alpha.svg

        //access the svg dom tree. In my browser, svgDoc is not null. With
jwebunit, it is null.

    });

</script>


In my browser, svgDoc is not null. With jwebunit, it is null. It seems that
the function the function is called before the svg object is loaded.

How can I handle it?

here is my test code snippet:

public class DashboardTest extends FunctionalTest {
private WebTester w;
@Before
    public void prepare() {
w = new WebTester();
Fixtures.deleteDatabase();
Fixtures.loadModels("initEmpty.yaml");
        w.setBaseUrl("http://localhost:9000/");
    }

@Test
public void addDashboard() {
    //log as user
    w.beginAt("login");
    if (w.getTestingEngine() instanceof HtmlUnitTestingEngineImpl)
    {
    //((HtmlUnitTestingEngineImpl)
w.getTestingEngine()).getWebClient().setThrowExceptionOnScriptError(false);
       //((HtmlUnitTestingEngineImpl)
w.getTestingEngine()).getWebClient().setAjaxController(new
NicelyResynchronizingAjaxController());
    }

    //check the AC list is fetch OK.
    w.setTextField("username", "dao...@gm...");
    w.setTextField("password", "xxx");
    w.clickButton("signin");
    w.clickLink("dashboardList");
    w.clickLink("newDashboard");
    w.assertTitleEquals("flightwatching - edit dashboard");
}


-- 
Dao Hodac

Re: [JWebUnit-users] Deprecate gotoWindow(int windowID) and gotoRootWindow()

[Jason M. <jas...@gm...>]

Julien,

I don't see a problem with that as long as we keep the following method that
will allow us to get to the web client when needed.  that way we can still
have access to the various windows, and switching between them.


   - HtmlUnitTestingEngineImpl.java  -->  public WebClient getWebClient()

Thanks,
-Jason-

On Mon, Sep 19, 2011 at 9:09 AM, Julien HENRY <he...@ya...> wrote:

> Hi JWebUnit users,
>
> I would like to deprecated gotoWindow(int windowID) and gotoRootWindow().
> These 2 methods are not portable to other testing engines (like Selenium)
> before they rely on HtmlUnit specific internals. I did some search and it
> seems "window ID" and "root window" is not something that is specified in
> HTML.
>
> My guess is that it was introduced to give access to windows without name
> nor title. Is it still something we need in 2011?
>
> Please tell me if you see any valid use case for theses methods. If nobody
> has concerns, theses methods will be deprecated in next release and not
> implemented in Selenium/WebDriver backend.
>
> Regards,
>
> Julien
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry&reg; mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry&reg; DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>
>

Re: [JWebUnit-users] Deprecate gotoWindow(int windowID) and gotoRootWindow()

[Julien H. <he...@ya...>]

Sorry, I must add a precision.

gotoRootWindow() was used for 2 usages:
  - return to top level window after usage of gotoFrame (currently it only works by chance when there is only one open window)

  - return to "root window" after usage of gotoWindowXX. Here rootWindow was in fact the first window in the htmlunit internal list of window

This is the second use case I want to deprecate. So I propose to keep the method gotoRootWindow, but I will update the HtmlUnit implementation to only do the first use case (and fix it at the same time).

WDYT?

Regards

Julien


>________________________________
>De : Julien HENRY <he...@ya...>
>À : "jwe...@li..." <jwe...@li...>
>Envoyé le : Lundi 19 Septembre 2011 16h09
>Objet : [JWebUnit-users] Deprecate gotoWindow(int windowID) and gotoRootWindow()
>
>
>Hi JWebUnit users,
>
>
>I would like to deprecated gotoWindow(int windowID) and gotoRootWindow(). These 2 methods are not portable to other testing engines (like Selenium) before they rely on HtmlUnit specific internals. I did some search and it seems "window ID" and "root window" is not something that is specified in HTML.
>
>
>My guess is that it was introduced to give access to windows without name nor title. Is it still something we need in 2011?
>
>
>Please tell me if you see any valid use case for theses methods. If nobody has concerns, theses methods will be deprecated in next release and not implemented in Selenium/WebDriver backend.
>
>
>Regards,
>
>
>Julien
>------------------------------------------------------------------------------
>BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>Learn about the latest advances in developing for the 
>BlackBerry&reg; mobile platform with sessions, labs & more.
>See new tools and technologies. Register for BlackBerry&reg; DevCon today!
>http://p.sf.net/sfu/rim-devcon-copy1
>_______________________________________________
>JWebUnit-users mailing list
>JWe...@li...
>https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>
>
>

[JWebUnit-users] Deprecate gotoWindow(int windowID) and gotoRootWindow()

[Julien H. <he...@ya...>]

Hi JWebUnit users,

I would like to deprecated gotoWindow(int windowID) and gotoRootWindow(). These 2 methods are not portable to other testing engines (like Selenium) before they rely on HtmlUnit specific internals. I did some search and it seems "window ID" and "root window" is not something that is specified in HTML.

My guess is that it was introduced to give access to windows without name nor title. Is it still something we need in 2011?

Please tell me if you see any valid use case for theses methods. If nobody has concerns, theses methods will be deprecated in next release and not implemented in Selenium/WebDriver backend.

Regards,

Julien

Re: [JWebUnit-users] Issues upgrading from version 2.2 to version 3

[Jevon W. <je...@je...>]

Hi Julien,

> I would like to hear other voices here: keep or remove deprecated flag on JUnit 3 stuff?

I'd like to keep JUnit 3 support, my project still uses the JUnit 3
API extensively, but I haven't yet updated to the latest release of
JWebUnit. What work would be necessary to keep both APIs functional?

Jevon

On Mon, Aug 22, 2011 at 4:52 AM, Julien HENRY <he...@ya...> wrote:
> Hi Tim,
>
> See my comments inline. Anyway thanks for sharing.
>
>>________________________________
>>De : Tim Pizey <ti...@pa...>
>>À : jwe...@li...
>>Envoyé le : Samedi 20 Août 2011 1h00
>>Objet : [JWebUnit-users] Issues upgrading from version 2.2 to version 3
>>
>>Hi,
>>
>>Thanks to all the JWebUnit team, and especially to Julien for his
>>attention to every message.
>>
>>This is to record the issues I have encountered in upgrading to
>>version 3.0 from version 2.2.
>>
>>I have downloaded the source and built locally, but had to setup a
>>toolchain.xml in my .m2 directory and disable
>>header checking before mvn install would work.
>>I would prefer not to rely upon toolchain.xml as I would wish to build
>>this under Jenkins and do not wish to set a universal toolchain.
>>Can this not be moved into the pom.xml file?
>>
>
> This is not really a "usability" problem as it is only required if you plan to build JWebUnit by yourself. It is well documented [1].
> Usually I am running Maven with JDK 1.6 when JWebUnit should be compatible with JDK 1.5. In the past when I was building with JDK 1.5 and JWebUnit was supposed to be JDK 1.4 compliant, usage of String.startsWith was unnoticed, even if compiler has -target 1.4 flag. That's why I introduced toolchains that is the standard Maven way to compile with a given JDK even when Maven is started with another.
> But I agree this is really annoying to setup, make the build not portable, ... I am aware of 2 other options:
>   - use a property to specify JDK path to the compiler plugin. Same issue than toolchains you would have to set this property in your settings.xml
>   - compile with the same JDK than Maven is run with, but use animal-sniffer to detect bad API usage. This is my preferred solution but I had no time to set it up. No very high priority for me.
>
>
>>========
>>
>>The class WebTestCase has been deprecated with the message 'use JUnit
>>4' : I have no intention of using JUnit4,
>>I do not think it is an improvement on JUnit3, there are many who
>>share my view.
>>The JUnit3 project is alive and well and is not going away anytime soon.
>
>
> Could you please point me to the project page were it is alive? Just curious.
>
>
>>Please remove deprecation.
>
>
> I do not plan to remove JUnit 3 support in JWebUnit (in fact this is automatically generated so it doesn't require any effort) but on the other hand I will no more validate that it works. So this is like "use it at your own risk".
> I would like to hear other voices here: keep or remove deprecated flag on JUnit 3 stuff?
>
>
>>=========
>>
>>HtmlUnitTestingEngineImpl.gotoPage no longer returns the failing status
>>
>>    public void gotoPage(URL initialURL) throws TestingEngineResponseException {
>>        try {
>>            wc.getPage(initialURL);
>>            win = wc.getCurrentWindow();
>>            form = null;
>>        } catch (FailingHttpStatusCodeException ex) {
>>            // only throw exception if necessary
>>            if (!ignoreFailingStatusCodes) {
>>                throw new TestingEngineResponseException(
>>                        "unexpected status code ["+ex.getStatusCode()+"]
>>at URL: ["+initialURL+"]", ex);
>>            }
>>        } catch (IOException ex) {
>>            throw new RuntimeException(ex);
>>        }
>>    }
>>
>>should be
>>
>>    public void gotoPage(URL initialURL) throws TestingEngineResponseException {
>>        try {
>>            wc.getPage(initialURL);
>>            win = wc.getCurrentWindow();
>>            form = null;
>>        } catch (FailingHttpStatusCodeException ex) {
>>            // only throw exception if necessary
>>            if (!ignoreFailingStatusCodes) {
>>                throw new TestingEngineResponseException(ex.getStatusCode(),
>>                        "unexpected status code ["+ex.getStatusCode()+"]
>>at URL: ["+initialURL+"]",  ex);
>>            }
>>        } catch (IOException ex) {
>>            throw new RuntimeException(ex);
>>        }
>>    }
>>
>
> I have no dev env here to check but seems a good catch. Could you please fill an issue on sourceforge?
>
>
>>========
>>
>>assertTextPresent no longer returns text inside a noframes tag - fair
>>enough, my test changed.
>
> Probably some HtmlUnit change. Getting text in a page was notoriously unstable feature of HtmlUnit.
>
>
>>
>>========
>>
>>The following test alternately fails and succeeds when run from Eclipse:
>>
>>  private void loginAsAdministrator() {
>>    gotoPage("/Admin/" + dbName + "/Main");
>>    gotoFrame("admin_top");
>>    clickButton("login");
>>    setTextField("field_login", "_administrator_");
>>    setTextField("field_password", "FIXME");
>>    checkCheckbox("rememberme");
>>    submit("action");
>>  }
>>
>>I have not figured out what the problem is, but it looks like
>>clickButton sometimes fails to have any effect.
>>I think that this is due to a confusion between current page and current Frame.
>>
>>If I change this to
>>
>>  private void loginAsAdministrator() {
>>    gotoPage("/Admin/" + dbName + "/Top");
>>//    gotoFrame("admin_top");
>>    clickButton("login");
>>    setTextField("field_login", "_administrator_");
>>    setTextField("field_password", "FIXME");
>>    checkCheckbox("rememberme");
>>    submit("action");
>>  }
>>
>>it works.
>>In HtmlElement.click() we have the line
>>        getPage().getWebClient().setCurrentWindow(getPage().getEnclosingWindow());
>>which I think may be the problem.
>>
>>A similar problem occurs when I click the link in the following, within a frame:
>>  <font face="Arial, Helvetica">
>>    <a         href="/melatitest/Admin/admintest/tableInfo/Main"
>>        target="_top"
>>
>>        id="continue"
>>    >Done</a>
>>
>>The current page text does not change, it used to become the text of
>>the _top window.
>>
>>I hope that this feedback is useful.
>>Thanks again for a great project.
>
> I need to do some testing when time permits. If you want to help, try to produce a standalone test case that I can play.
>
>
> Thanks
>
> Julien
>
>
>>
>>yours
>>Tim Pizey
>>
>
> [1] http://jwebunit.sourceforge.net/building-maven.html
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>

Re: [JWebUnit-users] Issues upgrading from version 2.2 to version 3

[Tim P. <ti...@pa...>]

Hi Julien,

Thanks for your response.

I have raised the issue at
https://sourceforge.net/tracker/?func=detail&aid=3395872&group_id=61302&atid=497982

I hope to be able to produce a test case for the frames issue if I get time.

yours
Tim

On 21 August 2011 17:52, Julien HENRY <he...@ya...> wrote:
> Hi Tim,
>
> See my comments inline. Anyway thanks for sharing.
>
>>________________________________
>>De : Tim Pizey <ti...@pa...>
>>À : jwe...@li...
>>Envoyé le : Samedi 20 Août 2011 1h00
>>Objet : [JWebUnit-users] Issues upgrading from version 2.2 to version 3
>>
>>Hi,
>>
>>Thanks to all the JWebUnit team, and especially to Julien for his
>>attention to every message.
>>
>>This is to record the issues I have encountered in upgrading to
>>version 3.0 from version 2.2.
>>
>>I have downloaded the source and built locally, but had to setup a
>>toolchain.xml in my .m2 directory and disable
>>header checking before mvn install would work.
>>I would prefer not to rely upon toolchain.xml as I would wish to build
>>this under Jenkins and do not wish to set a universal toolchain.
>>Can this not be moved into the pom.xml file?
>>
>
> This is not really a "usability" problem as it is only required if you plan to build JWebUnit by yourself. It is well documented [1].
> Usually I am running Maven with JDK 1.6 when JWebUnit should be compatible with JDK 1.5. In the past when I was building with JDK 1.5 and JWebUnit was supposed to be JDK 1.4 compliant, usage of String.startsWith was unnoticed, even if compiler has -target 1.4 flag. That's why I introduced toolchains that is the standard Maven way to compile with a given JDK even when Maven is started with another.
> But I agree this is really annoying to setup, make the build not portable, ... I am aware of 2 other options:
>   - use a property to specify JDK path to the compiler plugin. Same issue than toolchains you would have to set this property in your settings.xml
>   - compile with the same JDK than Maven is run with, but use animal-sniffer to detect bad API usage. This is my preferred solution but I had no time to set it up. No very high priority for me.
>
>
>>========
>>
>>The class WebTestCase has been deprecated with the message 'use JUnit
>>4' : I have no intention of using JUnit4,
>>I do not think it is an improvement on JUnit3, there are many who
>>share my view.
>>The JUnit3 project is alive and well and is not going away anytime soon.
>
>
> Could you please point me to the project page were it is alive? Just curious.
>
>
>>Please remove deprecation.
>
>
> I do not plan to remove JUnit 3 support in JWebUnit (in fact this is automatically generated so it doesn't require any effort) but on the other hand I will no more validate that it works. So this is like "use it at your own risk".
> I would like to hear other voices here: keep or remove deprecated flag on JUnit 3 stuff?
>
>
>>=========
>>
>>HtmlUnitTestingEngineImpl.gotoPage no longer returns the failing status
>>
>>    public void gotoPage(URL initialURL) throws TestingEngineResponseException {
>>        try {
>>            wc.getPage(initialURL);
>>            win = wc.getCurrentWindow();
>>            form = null;
>>        } catch (FailingHttpStatusCodeException ex) {
>>            // only throw exception if necessary
>>            if (!ignoreFailingStatusCodes) {
>>                throw new TestingEngineResponseException(
>>                        "unexpected status code ["+ex.getStatusCode()+"]
>>at URL: ["+initialURL+"]", ex);
>>            }
>>        } catch (IOException ex) {
>>            throw new RuntimeException(ex);
>>        }
>>    }
>>
>>should be
>>
>>    public void gotoPage(URL initialURL) throws TestingEngineResponseException {
>>        try {
>>            wc.getPage(initialURL);
>>            win = wc.getCurrentWindow();
>>            form = null;
>>        } catch (FailingHttpStatusCodeException ex) {
>>            // only throw exception if necessary
>>            if (!ignoreFailingStatusCodes) {
>>                throw new TestingEngineResponseException(ex.getStatusCode(),
>>                        "unexpected status code ["+ex.getStatusCode()+"]
>>at URL: ["+initialURL+"]",  ex);
>>            }
>>        } catch (IOException ex) {
>>            throw new RuntimeException(ex);
>>        }
>>    }
>>
>
> I have no dev env here to check but seems a good catch. Could you please fill an issue on sourceforge?
>
>
>>========
>>
>>assertTextPresent no longer returns text inside a noframes tag - fair
>>enough, my test changed.
>
> Probably some HtmlUnit change. Getting text in a page was notoriously unstable feature of HtmlUnit.
>
>
>>
>>========
>>
>>The following test alternately fails and succeeds when run from Eclipse:
>>
>>  private void loginAsAdministrator() {
>>    gotoPage("/Admin/" + dbName + "/Main");
>>    gotoFrame("admin_top");
>>    clickButton("login");
>>    setTextField("field_login", "_administrator_");
>>    setTextField("field_password", "FIXME");
>>    checkCheckbox("rememberme");
>>    submit("action");
>>  }
>>
>>I have not figured out what the problem is, but it looks like
>>clickButton sometimes fails to have any effect.
>>I think that this is due to a confusion between current page and current Frame.
>>
>>If I change this to
>>
>>  private void loginAsAdministrator() {
>>    gotoPage("/Admin/" + dbName + "/Top");
>>//    gotoFrame("admin_top");
>>    clickButton("login");
>>    setTextField("field_login", "_administrator_");
>>    setTextField("field_password", "FIXME");
>>    checkCheckbox("rememberme");
>>    submit("action");
>>  }
>>
>>it works.
>>In HtmlElement.click() we have the line
>>        getPage().getWebClient().setCurrentWindow(getPage().getEnclosingWindow());
>>which I think may be the problem.
>>
>>A similar problem occurs when I click the link in the following, within a frame:
>>  <font face="Arial, Helvetica">
>>    <a         href="/melatitest/Admin/admintest/tableInfo/Main"
>>        target="_top"
>>
>>        id="continue"
>>    >Done</a>
>>
>>The current page text does not change, it used to become the text of
>>the _top window.
>>
>>I hope that this feedback is useful.
>>Thanks again for a great project.
>
> I need to do some testing when time permits. If you want to help, try to produce a standalone test case that I can play.
>
>
> Thanks
>
> Julien
>
>
>>
>>yours
>>Tim Pizey
>>
>
> [1] http://jwebunit.sourceforge.net/building-maven.html
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>



-- 
Tim Pizey
http://pizey.net/~timp

Re: [JWebUnit-users] Issues upgrading from version 2.2 to version 3

[Julien H. <he...@ya...>]

Hi Tim,

See my comments inline. Anyway thanks for sharing.

>________________________________
>De : Tim Pizey <ti...@pa...>
>À : jwe...@li...
>Envoyé le : Samedi 20 Août 2011 1h00
>Objet : [JWebUnit-users] Issues upgrading from version 2.2 to version 3
>
>Hi,
>
>Thanks to all the JWebUnit team, and especially to Julien for his
>attention to every message.
>
>This is to record the issues I have encountered in upgrading to
>version 3.0 from version 2.2.
>
>I have downloaded the source and built locally, but had to setup a
>toolchain.xml in my .m2 directory and disable
>header checking before mvn install would work.
>I would prefer not to rely upon toolchain.xml as I would wish to build
>this under Jenkins and do not wish to set a universal toolchain.
>Can this not be moved into the pom.xml file?
>

This is not really a "usability" problem as it is only required if you plan to build JWebUnit by yourself. It is well documented [1].
Usually I am running Maven with JDK 1.6 when JWebUnit should be compatible with JDK 1.5. In the past when I was building with JDK 1.5 and JWebUnit was supposed to be JDK 1.4 compliant, usage of String.startsWith was unnoticed, even if compiler has -target 1.4 flag. That's why I introduced toolchains that is the standard Maven way to compile with a given JDK even when Maven is started with another.
But I agree this is really annoying to setup, make the build not portable, ... I am aware of 2 other options:
  - use a property to specify JDK path to the compiler plugin. Same issue than toolchains you would have to set this property in your settings.xml
  - compile with the same JDK than Maven is run with, but use animal-sniffer to detect bad API usage. This is my preferred solution but I had no time to set it up. No very high priority for me.


>========
>
>The class WebTestCase has been deprecated with the message 'use JUnit
>4' : I have no intention of using JUnit4,
>I do not think it is an improvement on JUnit3, there are many who
>share my view.
>The JUnit3 project is alive and well and is not going away anytime soon.


Could you please point me to the project page were it is alive? Just curious.


>Please remove deprecation.


I do not plan to remove JUnit 3 support in JWebUnit (in fact this is automatically generated so it doesn't require any effort) but on the other hand I will no more validate that it works. So this is like "use it at your own risk".
I would like to hear other voices here: keep or remove deprecated flag on JUnit 3 stuff?


>=========
>
>HtmlUnitTestingEngineImpl.gotoPage no longer returns the failing status
>
>    public void gotoPage(URL initialURL) throws TestingEngineResponseException {
>        try {
>            wc.getPage(initialURL);
>            win = wc.getCurrentWindow();
>            form = null;
>        } catch (FailingHttpStatusCodeException ex) {
>            // only throw exception if necessary
>            if (!ignoreFailingStatusCodes) {
>                throw new TestingEngineResponseException(
>                        "unexpected status code ["+ex.getStatusCode()+"]
>at URL: ["+initialURL+"]", ex);
>            }
>        } catch (IOException ex) {
>            throw new RuntimeException(ex);
>        }
>    }
>
>should be
>
>    public void gotoPage(URL initialURL) throws TestingEngineResponseException {
>        try {
>            wc.getPage(initialURL);
>            win = wc.getCurrentWindow();
>            form = null;
>        } catch (FailingHttpStatusCodeException ex) {
>            // only throw exception if necessary
>            if (!ignoreFailingStatusCodes) {
>                throw new TestingEngineResponseException(ex.getStatusCode(),
>                        "unexpected status code ["+ex.getStatusCode()+"]
>at URL: ["+initialURL+"]",  ex);
>            }
>        } catch (IOException ex) {
>            throw new RuntimeException(ex);
>        }
>    }
>

I have no dev env here to check but seems a good catch. Could you please fill an issue on sourceforge?


>========
>
>assertTextPresent no longer returns text inside a noframes tag - fair
>enough, my test changed.

Probably some HtmlUnit change. Getting text in a page was notoriously unstable feature of HtmlUnit.


>
>========
>
>The following test alternately fails and succeeds when run from Eclipse:
>
>  private void loginAsAdministrator() {
>    gotoPage("/Admin/" + dbName + "/Main");
>    gotoFrame("admin_top");
>    clickButton("login");
>    setTextField("field_login", "_administrator_");
>    setTextField("field_password", "FIXME");
>    checkCheckbox("rememberme");
>    submit("action");
>  }
>
>I have not figured out what the problem is, but it looks like
>clickButton sometimes fails to have any effect.
>I think that this is due to a confusion between current page and current Frame.
>
>If I change this to
>
>  private void loginAsAdministrator() {
>    gotoPage("/Admin/" + dbName + "/Top");
>//    gotoFrame("admin_top");
>    clickButton("login");
>    setTextField("field_login", "_administrator_");
>    setTextField("field_password", "FIXME");
>    checkCheckbox("rememberme");
>    submit("action");
>  }
>
>it works.
>In HtmlElement.click() we have the line
>        getPage().getWebClient().setCurrentWindow(getPage().getEnclosingWindow());
>which I think may be the problem.
>
>A similar problem occurs when I click the link in the following, within a frame:
>  <font face="Arial, Helvetica">
>    <a         href="/melatitest/Admin/admintest/tableInfo/Main"
>        target="_top"
>
>        id="continue"
>    >Done</a>
>
>The current page text does not change, it used to become the text of
>the _top window.
>
>I hope that this feedback is useful.
>Thanks again for a great project.

I need to do some testing when time permits. If you want to help, try to produce a standalone test case that I can play.


Thanks

Julien


>
>yours
>Tim Pizey
>

[1] http://jwebunit.sourceforge.net/building-maven.html

[JWebUnit-users] Issues upgrading from version 2.2 to version 3

[Tim P. <ti...@pa...>]

Hi,

Thanks to all the JWebUnit team, and especially to Julien for his
attention to every message.

This is to record the issues I have encountered in upgrading to
version 3.0 from version 2.2.

I have downloaded the source and built locally, but had to setup a
toolchain.xml in my .m2 directory and disable
header checking before mvn install would work.
I would prefer not to rely upon toolchain.xml as I would wish to build
this under Jenkins and do not wish to set a universal toolchain.
Can this not be moved into the pom.xml file?

========

The class WebTestCase has been deprecated with the message 'use JUnit
4' : I have no intention of using JUnit4,
I do not think it is an improvement on JUnit3, there are many who
share my view.
The JUnit3 project is alive and well and is not going away anytime soon.
Please remove deprecation.

=========

HtmlUnitTestingEngineImpl.gotoPage no longer returns the failing status

    public void gotoPage(URL initialURL) throws TestingEngineResponseException {
        try {
            wc.getPage(initialURL);
            win = wc.getCurrentWindow();
            form = null;
        } catch (FailingHttpStatusCodeException ex) {
        	// only throw exception if necessary
        	if (!ignoreFailingStatusCodes) {
	            throw new TestingEngineResponseException(
	                    "unexpected status code ["+ex.getStatusCode()+"]
at URL: ["+initialURL+"]", ex);
        	}
        } catch (IOException ex) {
            throw new RuntimeException(ex);
        }
    }

should be

    public void gotoPage(URL initialURL) throws TestingEngineResponseException {
        try {
            wc.getPage(initialURL);
            win = wc.getCurrentWindow();
            form = null;
        } catch (FailingHttpStatusCodeException ex) {
        	// only throw exception if necessary
        	if (!ignoreFailingStatusCodes) {
	            throw new TestingEngineResponseException(ex.getStatusCode(),
	                    "unexpected status code ["+ex.getStatusCode()+"]
at URL: ["+initialURL+"]",  ex);
        	}
        } catch (IOException ex) {
            throw new RuntimeException(ex);
        }
    }

========

assertTextPresent no longer returns text inside a noframes tag - fair
enough, my test changed.

========

The following test alternately fails and succeeds when run from Eclipse:

  private void loginAsAdministrator() {
    gotoPage("/Admin/" + dbName + "/Main");
    gotoFrame("admin_top");
    clickButton("login");
    setTextField("field_login", "_administrator_");
    setTextField("field_password", "FIXME");
    checkCheckbox("rememberme");
    submit("action");
  }

I have not figured out what the problem is, but it looks like
clickButton sometimes fails to have any effect.
I think that this is due to a confusion between current page and current Frame.

If I change this to

  private void loginAsAdministrator() {
    gotoPage("/Admin/" + dbName + "/Top");
//    gotoFrame("admin_top");
    clickButton("login");
    setTextField("field_login", "_administrator_");
    setTextField("field_password", "FIXME");
    checkCheckbox("rememberme");
    submit("action");
  }

it works.
In HtmlElement.click() we have the line
        getPage().getWebClient().setCurrentWindow(getPage().getEnclosingWindow());
which I think may be the problem.

A similar problem occurs when I click the link in the following, within a frame:
  <font face="Arial, Helvetica">
    <a         href="/melatitest/Admin/admintest/tableInfo/Main"
        target="_top"

        id="continue"
    >Done</a>

The current page text does not change, it used to become the text of
the _top window.

I hope that this feedback is useful.
Thanks again for a great project.

yours
Tim Pizey


-- 
Tim Pizey
http://pizey.net/~timp

Re: [JWebUnit-users] JWebUnit 3.0 released

[Tim P. <ti...@pa...>]

Julien,

Thank you so much. Velocity 1.5 was a compile dependency and pulled in
commons-lang 2.1
http://melati.org/melati/dependencies.html

I have added an explicit declaration of commons-lang 2.6 and upgraded
to Velocity 17.
Looks like there are a few more dependencies to work through...

thanks again
Tim

On 19 August 2011 08:32, Julien HENRY <he...@ya...> wrote:
> Hi Tim,
> HtmlUnit is using a method (startsWithIgnoreCase) from commons-lang that was
> introduced in commons-lang 2.4. If you declare only jwebunit deps you should
> have commons-lang 2.6 in your classpath.
>
> Please check that you have not overriden the version of commons-lang to
> something under 2.4. I can't check by myself because your CVS repository is
> not accessible (at least the web interface).
> Regards,
> Julien
>
> ________________________________
> De : Tim Pizey <ti...@pa...>
> À : Julien HENRY <he...@ya...>; Usage problems for JWebUnit
> <jwe...@li...>
> Envoyé le : Vendredi 19 Août 2011 1h11
> Objet : Re: [JWebUnit-users] JWebUnit 3.0 released
>
> Hi Julien,
>
> On 18 August 2011 13:23, Julien HENRY wrote:
>> Hi all,
>>
>> JWebUnit 3.0 is released and should be already available for download on
>> Maven
>> central and Sourceforge.
>
> Congratulations, and thankyou for your rapid responses on this list.
>
> I have updated http://melati.org/ , which is built using Maven, from
> 2.2 to 3.0 and have a lot of new failures eg:
>
> java.lang.NoClassDefFoundError: Could not initialize class
> com.gargoylesoftware.htmlunit.WebClient
>         at
> net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)
>         at
> net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)
>
> also :
>
> java.lang.NoSuchMethodError:
> org.apache.commons.lang.StringUtils.startsWithIgnoreCase(Ljava/lang/String;Ljava/lang/String;)Z
>         at
> com.gargoylesoftware.htmlunit.util.URLCreator$URLCreatorStandard.toUrlUnsafeClassic(URLCreator.java:66)
>         at
> com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlUnsafe(UrlUtils.java:193)
>         at
> com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlSafe(UrlUtils.java:171)
>         at
> com.gargoylesoftware.htmlunit.WebClient.<clinit>(WebClient.java:162)
>         at
> net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)
>         at
> net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)
>
>
> I have not looked deeply into this, is this what you would expect? How
> much work will I have to do to upgrade?
>
> thanks again
> Tim
> --
> Tim Pizey
> http://pizey.net/~timp
>
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> JWebUnit-users mailing list
> JWe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>
>



-- 
Tim Pizey
http://pizey.net/~timp

Re: [JWebUnit-users] JWebUnit 3.0 released

[Julien H. <he...@ya...>]

Hi Tim,

HtmlUnit is using a method (startsWithIgnoreCase) from commons-lang that was introduced in commons-lang 2.4. If you declare only jwebunit deps you should have commons-lang 2.6 in your classpath.


Please check that you have not overriden the version of commons-lang to something under 2.4. I can't check by myself because your CVS repository is not accessible (at least the web interface).

Regards,

Julien




>________________________________
>De : Tim Pizey <ti...@pa...>
>À : Julien HENRY <he...@ya...>; Usage problems for JWebUnit <jwe...@li...>
>Envoyé le : Vendredi 19 Août 2011 1h11
>Objet : Re: [JWebUnit-users] JWebUnit 3.0 released
>
>Hi Julien,
>
>On 18 August 2011 13:23, Julien HENRY wrote:
>> Hi all,
>>
>> JWebUnit 3.0 is released and should be already available for download on
>> Maven
>> central and Sourceforge.
>
>Congratulations, and thankyou for your rapid responses on this list.
>
>I have updated http://melati.org/ , which is built using Maven, from
>2.2 to 3.0 and have a lot of new failures eg:
>
>java.lang.NoClassDefFoundError: Could not initialize class
>com.gargoylesoftware.htmlunit.WebClient
>        at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)
>        at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)
>
>also :
>
>java.lang.NoSuchMethodError:
>org.apache.commons.lang.StringUtils.startsWithIgnoreCase(Ljava/lang/String;Ljava/lang/String;)Z
>        at com.gargoylesoftware.htmlunit.util.URLCreator$URLCreatorStandard.toUrlUnsafeClassic(URLCreator.java:66)
>        at com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlUnsafe(UrlUtils.java:193)
>        at com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlSafe(UrlUtils.java:171)
>        at com.gargoylesoftware.htmlunit.WebClient.<clinit>(WebClient.java:162)
>        at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)
>        at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)
>
>
>I have not looked deeply into this, is this what you would expect? How
>much work will I have to do to upgrade?
>
>thanks again
>Tim
>-- 
>Tim Pizey
>http://pizey.net/~timp
>
>
>

Re: [JWebUnit-users] JWebUnit 3.0 released

[Tim P. <ti...@pa...>]

Hi Julien,

On 18 August 2011 13:23, Julien HENRY wrote:
> Hi all,
>
> JWebUnit 3.0 is released and should be already available for download on
> Maven
> central and Sourceforge.

Congratulations, and thankyou for your rapid responses on this list.

I have updated http://melati.org/ , which is built using Maven, from
2.2 to 3.0 and have a lot of new failures eg:

java.lang.NoClassDefFoundError: Could not initialize class
com.gargoylesoftware.htmlunit.WebClient
        at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)
        at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)

also :

java.lang.NoSuchMethodError:
org.apache.commons.lang.StringUtils.startsWithIgnoreCase(Ljava/lang/String;Ljava/lang/String;)Z
        at com.gargoylesoftware.htmlunit.util.URLCreator$URLCreatorStandard.toUrlUnsafeClassic(URLCreator.java:66)
        at com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlUnsafe(UrlUtils.java:193)
        at com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlSafe(UrlUtils.java:171)
        at com.gargoylesoftware.htmlunit.WebClient.<clinit>(WebClient.java:162)
        at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)
        at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)


I have not looked deeply into this, is this what you would expect? How
much work will I have to do to upgrade?

thanks again
Tim
-- 
Tim Pizey
http://pizey.net/~timp