jwebunit-development — Concerns current development ongoing in JWebUnit.

[Jwebunit-development] [ jwebunit-Bugs-981906 ] clickbutton bug

[SourceForge.net <no...@so...>]

Bugs item #981906, was opened at 2004-06-29 14:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=981906&group_id=61302

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Saleh matani (matani)
Assigned to: Nobody/Anonymous (nobody)
Summary: clickbutton bug

Initial Comment:
the new Version of httpUnit include a bugfix witch use to 
be also fixed bei jWebUnit , i am talking here about 
clickbutton or assertbuttonpresent , this methods are 
implemented to search a button in a form tag , (form) , 
after the HTML 4.0 there is a new tag names <BUTTON> 
and it dose not need forms but with jwebunit and the 
current Release of http Unit there is no way to test 
buttons that are not in <form> tag , the bugfix ist 
allready checked in in the cvs Repository from httpUnit , 
thats mean , if you check out the httpunit and generate 
your jar file then you can work with buttons outer a form 
tag , but you need to make some changes in the 
jwebunit httpUnitDialog.java!
the changes are:


  //!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  // bugfix by Saleh Matani
  //!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

  /**
   * @return the forms count in response
   */
  public int getFormCount()
  {
    try
    {
      int i = resp.getForms().length;
      return i;
    }
    catch (SAXException e)
    {
      e.printStackTrace();
    }
    return 0;
  }

  /**
   * Return the HttpUnit Button with a given id.
   *
   * @param buttonId
   */
  public Button getHtmlElementButton(String buttonId)
  {
    try
    {
      Button button = (Button) resp.getElementWithID
(buttonId);
      return button;
    }
    catch (SAXException e)
    {
      return null;
    }
  }

  public Button getFormButton(String buttonId)
  {
    int formCount = getFormCount();
    for (int i = 0; i < formCount; i++)
      if (getForm(i).getButtonWithID(buttonId) != null)
        return getForm(i).getButtonWithID(buttonId);
    return null;
  }

  public Button getButton(String buttonId)
  {
    Button button;
    button = getHtmlElementButton(buttonId);
    if (button != null)
      return button;
    button = getFormButton(buttonId);
    if (button != null)
      return button;
    return null;
  }

  // end bugfix by Saleh Matani !!!!!!!!!!!!!!!!!!!!!!!!!!!! 
  //for Developer! , Please check this code to cvs


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=981906&group_id=61302

[Jwebunit-development] [ jwebunit-Bugs-693598 ] setLocale has no effect

[SourceForge.net <no...@so...>]

Bugs item #693598, was opened at 2003-02-26 07:22
Message generated for change (Settings changed) made by jimweaver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=693598&group_id=61302

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Markus (sorcerer13)
>Assigned to: Nobody/Anonymous (nobody)
Summary: setLocale has no effect

Initial Comment:
Setting a new locale using setLocale() in WebTester has 
no effect. getLocale() returns the locale set with 
setLocale(), but the locale "en_US" is sent to the server.

Here is the code:
public void setUp()
{
  System.out.println ("old locale: " + getTestContext
().getLocale ());
  getTestContext().setLocale (Locale.GERMAN);
  getTestContext().setBaseUrl(BASE_URL);
		
  System.out.println ("new locale: " + getTestContext
().getLocale ());
}



----------------------------------------------------------------------

Comment By: Jim Weaver (prospero2000us)
Date: 2003-09-22 14:26

Message:
Logged In: YES 
user_id=597548

This method was originally added to compare property file
values against html results.  It should also pass to
httpunit as the browser locale.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=693598&group_id=61302

[Jwebunit-development] [ jwebunit-Bugs-974065 ] Change to HttpUnitDialog behaviour

[SourceForge.net <no...@so...>]

Bugs item #974065, was opened at 2004-06-16 12:21
Message generated for change (Comment added) made by jimweaver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=974065&group_id=61302

Category: None
Group: Release 1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Read (mattread)
Assigned to: Nobody/Anonymous (nobody)
Summary: Change to HttpUnitDialog behaviour

Initial Comment:
I used to be able to do something like this:

HttpUnitDialog hud = new HttpUnitDialog(getBaseUrl(), 
getTestContext() );
hud.clickLink("somelinkId");

And then manipulate the HttpUnitDialog in order to 
simulate multiple people navigating the website. This no 
longer seems to work. The page that I'd navigated to 
prior to calling this code gets modified. Is this a bug or 
intentional behaviour?



----------------------------------------------------------------------

>Comment By: Jim Weaver (jimweaver)
Date: 2004-06-28 18:33

Message:
Logged In: YES 
user_id=619947

Can you post a small testcase that doesn't work anymore, and
include the code for getBaseUrl and getTestContext?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=974065&group_id=61302

[Jwebunit-development] [ jwebunit-Bugs-707758 ] html page gets replaced with linked script

[SourceForge.net <no...@so...>]

Bugs item #707758, was opened at 2003-03-21 16:16
Message generated for change (Settings changed) made by jimweaver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=707758&group_id=61302

Category: None
Group: Release 1.2
>Status: Closed
>Resolution: Out of Date
Priority: 8
Submitted By: Leo Parker (xanaguy)
Assigned to: Nobody/Anonymous (nobody)
Summary: html page gets replaced with linked script

Initial Comment:
sample.html:
<html>
        <script src="script.js"></script>
        <title>The Title</title>
</html>

MyWebTestCase.java:
    public void test1() {
        beginAt("/sample.html");

        assertTitleEquals("The Title");
        assertTextPresent("The Title"); // fails
    }
  
The offending change happens at:
        wc.addClientListener(new WebClientListener() {
            public void requestSent(WebClient webClient, 
WebRequest webRequest) {
            }

            public void responseReceived(WebClient 
webClient, WebResponse webResponse) {
                resp = webResponse;  // <=- here!!!
                form = null;
            }
        });
[HttpUnitDialog.java:83], but I suspect the problem is 
somewhere else.  (It might even be in 
httpunit.HTMLPage.parse() in the inner class there.  

I'm using jWebUnit 1.1.1 (modula the patch I sent in 
yesterday) and HttpUnit 1.5.2, although HttpUnit 1.5 
does the same thing.

Here's the stack trace when the offending substitution is 
made:
Thread [main] (Suspended)
	net.sourceforge.jwebunit.HttpUnitDialog$1.res
ponseReceived(com.meterware.httpunit.WebClient, 
com.meterware.httpunit.WebResponse) line: 83
	com.meterware.httpunit.WebConversation
(com.meterware.httpunit.WebClient).tellListeners
(com.meterware.httpunit.WebResponse) line: 432
	com.meterware.httpunit.WebWindow.getRes
ource(com.meterware.httpunit.WebRequest) line: 162
	com.meterware.httpunit.HTMLPage.getInclud
edScript(java.lang.String) line: 108
	com.meterware.httpunit.HTMLPage$1.getIncl
udedScript(java.lang.String) line: 274
	com.meterware.httpunit.parsing.DOMParser.
getIncludedScript(java.lang.String) line: 165
	com.meterware.httpunit.parsing.ScriptFilter.st
artElement(org.apache.xerces.xni.QName, 
org.apache.xerces.xni.XMLAttributes, 
org.apache.xerces.xni.Augmentations) line: 86
	org.cyberneko.html.HTMLTagBalancer.startEl
ement(org.apache.xerces.xni.QName, 
org.apache.xerces.xni.XMLAttributes, 
org.apache.xerces.xni.Augmentations) line: not available
	org.cyberneko.html.HTMLScanner$ContentS
canner.scanStartElement(boolean[]) line: not available
	org.cyberneko.html.HTMLScanner$ContentS
canner.scan(boolean) line: not available
	org.cyberneko.html.HTMLScanner.scanDocu
ment(boolean) line: not available
	org.cyberneko.html.HTMLConfiguration.parse
(boolean) line: not available
	org.cyberneko.html.HTMLConfiguration.parse
(org.apache.xerces.xni.parser.XMLInputSource) line: not 
available
	com.meterware.httpunit.parsing.DOMParser
(org.apache.xerces.parsers.XMLParser).parse
(org.apache.xerces.xni.parser.XMLInputSource) line: not 
available
	com.meterware.httpunit.parsing.DOMParser
(org.apache.xerces.parsers.DOMParser).parse
(org.xml.sax.InputSource) line: not available
	com.meterware.httpunit.parsing.NekoHTMLP
arser.parse(java.net.URL, java.lang.String, 
com.meterware.httpunit.parsing.DocumentAdapter) line: 
55
	com.meterware.httpunit.HTMLPage.parse
(java.lang.String, java.net.URL) line: 272
	com.meterware.httpunit.HttpWebResponse
(com.meterware.httpunit.WebResponse).getReceivedPa
ge() line: 945
	com.meterware.httpunit.HttpWebResponse
(com.meterware.httpunit.WebResponse).getTitle() line: 
88
	net.sourceforge.jwebunit.HttpUnitDialog.getR
esponsePageTitle() line: 121
	net.sourceforge.jwebunit.WebTester.assertTitl
eEquals(java.lang.String) line: 94
	ScriptTestCase
(net.sourceforge.jwebunit.WebTestCase).assertTitleEqua
ls(java.lang.String) line: 52
	ScriptTestCase.test1() line: 23
	sun.reflect.NativeMethodAccessorImpl.invoke
0(java.lang.reflect.Method, java.lang.Object, 
java.lang.Object[]) line: not available [native method]
	sun.reflect.NativeMethodAccessorImpl.invoke
(java.lang.Object, java.lang.Object[]) line: 39
	sun.reflect.DelegatingMethodAccessorImpl.in
voke(java.lang.Object, java.lang.Object[]) line: 25
	java.lang.reflect.Method.invoke
(java.lang.Object, java.lang.Object[]) line: 324
	ScriptTestCase
(junit.framework.TestCase).runTest() line: 154
	ScriptTestCase
(junit.framework.TestCase).runBare() line: 127
	junit.framework.TestResult$1.protect() line: 
106
	junit.framework.TestResult.runProtected
(junit.framework.Test, junit.framework.Protectable) line: 
124
	junit.framework.TestResult.run
(junit.framework.TestCase) line: 109
	ScriptTestCase
(junit.framework.TestCase).run
(junit.framework.TestResult) line: 118
	junit.framework.TestSuite.runTest
(junit.framework.Test, junit.framework.TestResult) line: 
208
	junit.framework.TestSuite.run
(junit.framework.TestResult) line: 203
	org.eclipse.jdt.internal.junit.runner.RemoteTe
stRunner.runTests(java.lang.String[]) line: 329
	org.eclipse.jdt.internal.junit.runner.RemoteTe
stRunner.run() line: 218
	org.eclipse.jdt.internal.junit.runner.RemoteTe
stRunner.main(java.lang.String[]) line: 151


----------------------------------------------------------------------

Comment By: Vivek Venugopalan (vivekv)
Date: 2004-06-16 21:20

Message:
Logged In: YES 
user_id=131737

I added a test case to try this out and found that this worked 
fine with 1.2. I will commit the changed Test Case. 

----------------------------------------------------------------------

Comment By: Jim Weaver (jimweaver)
Date: 2004-06-11 12:32

Message:
Logged In: YES 
user_id=619947

This has been a fun one.

Post 1.2 release someone needs to revisit this issue and see
if we still have problems.  I will not that, if I remember
correctly, the listener was added so that is a javascript
function ends up changing the response, that can be tested.
 The listener method in HttpUnitDialog now doea a
webclient.getCurrentPage.  This problem may now be fixed -
just needs to be verified with a unit test.

----------------------------------------------------------------------

Comment By: Jim Weaver (prospero2000us)
Date: 2003-09-22 12:00

Message:
Logged In: YES 
user_id=597548

Hoping to resolve this for next release.  It may be that the
listener was needed to update the response when javascript
is triggered that changes the response....

Jimbo

----------------------------------------------------------------------

Comment By: Peter Held (bianchi)
Date: 2003-09-15 16:24

Message:
Logged In: YES 
user_id=867127

OK, I'm an idiot.  Turns out that my junit.textui.TestRunner 
problem was a missing 'js.jar' reference in my CLASSPATH. 
Sorry folks.

----------------------------------------------------------------------

Comment By: Peter Held (bianchi)
Date: 2003-09-15 12:08

Message:
Logged In: YES 
user_id=867127

Hi there.  I'm not a Java expert yet, but I thought I'd mention 
some strange behavior I saw which was related to this.  I 
have also had problems with the linked script issue.  However, 
when I run my JWebUnit tests through the Eclipse JUnit 
plugin, they work fine.  I have no idea what the difference is 
between Eclipse running the tests and the command-line 
junit.textui.TestRunner doing it.

Also, a little feedback on the latest fix suggested by 
xanaguy.  I tried commenting out the wc.addClientListener() 
code in HttpUnitDialog.initWebConversation(), and found that 
the form element assertions stopped working.  This occured 
when running the tests with junit.textui.TestRunner as well as 
Eclipse.
 

----------------------------------------------------------------------

Comment By: Stefan Wasilewski (smw)
Date: 2003-07-07 12:09

Message:
Logged In: YES 
user_id=18328

Ok, so xanaguy's patch breaks HttpUnitDialog.submit(String
buttonName) because it's relying on the clientListener. 
Obviously, this is the wrong behavior, so here's the full fix.

First of all, in httpunit 1.5.3, Webform.submit(SubmitButton
button) is public, so we upgrade to that version.  Then, we
change 

            getForm().getSubmitButton(buttonName).click();
to
            resp =
getForm().submit(getSubmitButton(buttonName));

in HttpUnitDialog.submit(String buttonName).


Then we do as xanaguy says, and remove the
wc.addClientListener() from
HttpUnitDialog.initWebConversation().



----------------------------------------------------------------------

Comment By: Christian Hargraves (engrean)
Date: 2003-07-04 09:27

Message:
Logged In: YES 
user_id=60860

I just posted that this worked for me. Let me correct
myself. This corrected that problem and just as the others
stated is did cause another problem. The new problem is that
I can no longer use the submit(nameOrId) function. The
strange thing is it doesn't error out, it just doesn't
sumbit the form. Therefore I had to use the submit() method
without the name in it.

----------------------------------------------------------------------

Comment By: Christian Hargraves (engrean)
Date: 2003-07-03 19:20

Message:
Logged In: YES 
user_id=60860

This also solved my problem for bug  #752078!



----------------------------------------------------------------------

Comment By: Leo Parker (xanaguy)
Date: 2003-05-16 12:41

Message:
Logged In: YES 
user_id=565814

What other problem did this patch cause?  Clearly the line I 
removed shouldn't be there.  If something else is relying on it, 
then it's got other problems.  What that line is doing is 
making it so that any time ANYTHING makes an HTTP 
request through HttpUnit it stores the received file as the 
HTML file to be processed.  That's not how it should work.  
Anytime code gets a new HTML file to work on it should 
store it manually, not through the HttpUnit callback.

----------------------------------------------------------------------

Comment By: Jim Weaver (prospero2000us)
Date: 2003-05-16 00:13

Message:
Logged In: YES 
user_id=597548

Very belated response,

Yes, this has been a running problem.  We made the same fix
you ended up making on one of our projects, but it caused a
problem for another project, so I have to spend some time
settling this one once and for all.  bumping the priority.

jim

----------------------------------------------------------------------

Comment By: Leo Parker (xanaguy)
Date: 2003-03-21 17:24

Message:
Logged In: YES 
user_id=565814

Apologies for the running dialog here.  That last comment 
wasn't quite right -- it is important to clear the form variable 
when the response comes back.  Otherwise it gets 
inappropriately cached between pages.  So...

I think you can fix this issue by commenting out line 83 of 
HttpUnitDialog.java:
     resp = webResponse;

----------------------------------------------------------------------

Comment By: Leo Parker (xanaguy)
Date: 2003-03-21 17:14

Message:
Logged In: YES 
user_id=565814

Looking at this a bit more, I think the problem comes from 
HttpUnitDialog.initWebConversation() where it calls 
wc.addClientListener() -- this makes it so that anytime 
HttpUnit fetches a file, it replaces our response.  Why is this 
here?  I commented it out, and now my problem is solved.  I 
don't seem to have broken anything else, but I presume the 
person who put that in there did so for SOME reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=707758&group_id=61302

[Jwebunit-development] [ jwebunit-Bugs-981534 ] Javascript onchange bug

[SourceForge.net <no...@so...>]

Bugs item #981534, was opened at 2004-06-28 15:27
Message generated for change (Comment added) made by jimweaver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=981534&group_id=61302

Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 7
Submitted By: Jim Weaver (jimweaver)
Assigned to: Jim Weaver (jimweaver)
Summary: Javascript onchange bug

Initial Comment:
OK, I dunno if this was introduced with the new
versions of httpunit etc., or not but we have a problem
when an onchange event ends up changing the response
(via form submission or setting window.location). 
HttpUnitDialog ends up with the old response, not the
new one.

The problem is demonstrated in a test in the
JavaScriptEventsTest, which I have named such that it
won't run from AllTests:
notestOnChangeOnFormElementChangesWindowLocation()

This sort of thing used to work, I'm pretty sure. 
Probably we have a change in HttpUnit that is
clobbering us.

Note that after triggering the onchange, you can check
dialog.webClient.getCurrentPage() from your test and it
will return the proper response that the onchange
directed us to.  But, HttpUnitDialog's response object
is wrong - and that is what the assertions drive off of.  

The client listener does get alerted by httpunit from
the onchange, but the new response at that point is on
the response parameter passed into the client listener
- not on webclilent.getCurrentPage().  We used to use
the response parameter ages ago, but the listner was
getting called when javascript resources loaded, and
that caused the response to unexpectedly be the
contents of a javascript file ;-).

Fun, fun, fun

----------------------------------------------------------------------

>Comment By: Jim Weaver (jimweaver)
Date: 2004-06-28 18:22

Message:
Logged In: YES 
user_id=619947

OK fixed - setting a form parameter will no refresh the
response to the current page if the current page changed as
a result of setting the parameter in httpunit.  That takes
into account change of location by onchange of input element
without breaking the frame support.

Unit test in place for this now in JavaScriptEventsTest.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=981534&group_id=61302

[Jwebunit-development] [ jwebunit-Bugs-972992 ] Memory Leak

[SourceForge.net <no...@so...>]

Bugs item #972992, was opened at 2004-06-15 07:49
Message generated for change (Comment added) made by dashorst
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=972992&group_id=61302

Category: None
Group: Release 1.3
Status: Open
Resolution: Fixed
Priority: 7
Submitted By: Budi Boentaran (budib)
Assigned to: Vivek Venugopalan (vivekv)
Summary: Memory Leak

Initial Comment:
Hi,

We have one test Suite that holds all the test cases. 
When running the test Suite, we realize that the 
memory usage is keep increasing. 

To solve the problem, we implement tearDown in 
WebTestCase to set the WebTester instance to null, 
thus allowing the gc to reclaim the memory.

public class WebTestCase extends TestCase {
    protected WebTester tester;
    /**
     * Implement tearDown method to clear unused 
memory
     */
    protected void tearDown() throws Exception {
    	//Set the reference to null
    	//to allow the GC to clear the memory
    	tester = null;
    }    


----------------------------------------------------------------------

>Comment By: Martijn Dashorst (dashorst)
Date: 2004-06-29 00:36

Message:
Logged In: YES 
user_id=695103

see the development mailinglist for more information on the
discussion of this 'bug'.


----------------------------------------------------------------------

Comment By: Martijn Dashorst (dashorst)
Date: 2004-06-28 22:36

Message:
Logged In: YES 
user_id=695103

The problem with this fix is that you 'force' a subclasser
of WebTestCase to call super.tearDown(). This is *not* a
normal JUnit practice.

I'll look into the junit framework for a more elegant solution.


----------------------------------------------------------------------

Comment By: Vivek Venugopalan (vivekv)
Date: 2004-06-17 19:52

Message:
Logged In: YES 
user_id=131737

OK you convinced me :)  I will make the change and commit 
to CVS.

----------------------------------------------------------------------

Comment By: Budi Boentaran (budib)
Date: 2004-06-17 04:52

Message:
Logged In: YES 
user_id=1063581

Hi,

Yes it helps. By setting it to null, the GC can reclaim back the 
memory when each test case is finished. It will not force the 
GC to do garbage collection immediately, but just allowing it 
to claim back the memory when needed.

Previously the GC will not be able to reclaim the memory until 
the whole test suite is finishes. For our case, our test suite 
contains more than 1000 test cases, thus the JVM is running 
out of memory after running few hundred test cases.


----------------------------------------------------------------------

Comment By: Vivek Venugopalan (vivekv)
Date: 2004-06-17 04:26

Message:
Logged In: YES 
user_id=131737

Did this help?  Typically even if we set the memory to null, 
this is just a hint to the GC to force garbage collection.  In 
any case, was the leak somewhere else?  This change is 
simple and possibly has no side effects but I want to make 
sure that the leak is in jWebUnit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=972992&group_id=61302

[Jwebunit-development] Bug 972992 - Memory leak

[Martijn D. <ma...@da...>]

Dear all,

With respect to the submitted bug with ID 972992, of which a detailed 
account can be found at:
http://sourceforge.net/tracker/index.php?func=detail&aid=972992&group_id=61302&atid=497982

This most likely is not a jWebUnit memory leak, as we can see it. Since 
the WebTester instance is created at construction time, and it *is* an 
instance variable, it will be marked for gc at the end of the life of 
the WebTestCase.

Normally this is not an issue. However, my and Jim's assertion is that 
Budi Boentaran runs the tests from within ant. The ant taskrunner first 
creates all testcase instances for each test it runs. Then it runs the 
test (calling setUp before, and tearDown afterwards). Only after all 
tests have been run, the tests will be cleaned up.

The only way I see to solve this problem is by *NOT* overriding 
TestCase.tearDown(), but to override TestCase.runBare(). The problem 
with overriding TestCase.tearDown() and TestCase.setUp() is that the 
clients of jWebUnit *have* to call super.setUp() and super.tearDown(). 
In my opinion this is not good, as it breaks encapsulation.

Overriding TestCase.runBare() allows us to move the allocation of 
WebTester prior to the call to setUp(), and to clean up after the 
tearDown() has been called:

    public void runBare() throws Throwable {
        try {
            tester = new WebTester();
            super.runBare();
        } finally {
            tester = null;
        }
    }

This *does* open us to a vulnerability: if the internals of junit, or 
the ant-task, or some other plugin of some IDE doesn't use the runBare() 
method but its own method of setting up/tearing down a test, then we are 
in trouble. Also, some other genius (ahum) could have overridden the 
runBare method, and then our solution won't be called, if the 
super.runBare isn't called.
I *do* think the risk is minimal, since most IDE's/plugin's will call 
TestCase.run() as this does some tricky stuff regarding exception handling.

The last solution I would consider is: don't subclass 
junit.framework.TestCase, but subclass junit.framework.Assert, implement 
junit.framework.Test, and delegate all calls to Test.* to an TestCase 
instance. However, this is a rather big refactoring. It should not break 
anything.

The questions are:
 * do we fix this, as it isn't a direct jWebUnit problem
 * if we fix, do we override the runBare() method?
 * fix it in another way?

Martijn

[Jwebunit-development] [ jwebunit-Bugs-972992 ] Memory Leak

[SourceForge.net <no...@so...>]

Bugs item #972992, was opened at 2004-06-15 07:49
Message generated for change (Comment added) made by dashorst
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=972992&group_id=61302

Category: None
Group: Release 1.3
>Status: Open
Resolution: Fixed
Priority: 7
Submitted By: Budi Boentaran (budib)
Assigned to: Vivek Venugopalan (vivekv)
Summary: Memory Leak

Initial Comment:
Hi,

We have one test Suite that holds all the test cases. 
When running the test Suite, we realize that the 
memory usage is keep increasing. 

To solve the problem, we implement tearDown in 
WebTestCase to set the WebTester instance to null, 
thus allowing the gc to reclaim the memory.

public class WebTestCase extends TestCase {
    protected WebTester tester;
    /**
     * Implement tearDown method to clear unused 
memory
     */
    protected void tearDown() throws Exception {
    	//Set the reference to null
    	//to allow the GC to clear the memory
    	tester = null;
    }    


----------------------------------------------------------------------

>Comment By: Martijn Dashorst (dashorst)
Date: 2004-06-28 22:36

Message:
Logged In: YES 
user_id=695103

The problem with this fix is that you 'force' a subclasser
of WebTestCase to call super.tearDown(). This is *not* a
normal JUnit practice.

I'll look into the junit framework for a more elegant solution.


----------------------------------------------------------------------

Comment By: Vivek Venugopalan (vivekv)
Date: 2004-06-17 19:52

Message:
Logged In: YES 
user_id=131737

OK you convinced me :)  I will make the change and commit 
to CVS.

----------------------------------------------------------------------

Comment By: Budi Boentaran (budib)
Date: 2004-06-17 04:52

Message:
Logged In: YES 
user_id=1063581

Hi,

Yes it helps. By setting it to null, the GC can reclaim back the 
memory when each test case is finished. It will not force the 
GC to do garbage collection immediately, but just allowing it 
to claim back the memory when needed.

Previously the GC will not be able to reclaim the memory until 
the whole test suite is finishes. For our case, our test suite 
contains more than 1000 test cases, thus the JVM is running 
out of memory after running few hundred test cases.


----------------------------------------------------------------------

Comment By: Vivek Venugopalan (vivekv)
Date: 2004-06-17 04:26

Message:
Logged In: YES 
user_id=131737

Did this help?  Typically even if we set the memory to null, 
this is just a hint to the GC to force garbage collection.  In 
any case, was the leak somewhere else?  This change is 
simple and possibly has no side effects but I want to make 
sure that the leak is in jWebUnit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=972992&group_id=61302

[Jwebunit-development] [ jwebunit-Bugs-981534 ] Javascript onchange bug

[SourceForge.net <no...@so...>]

Bugs item #981534, was opened at 2004-06-28 15:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=981534&group_id=61302

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jim Weaver (jimweaver)
Assigned to: Jim Weaver (jimweaver)
Summary: Javascript onchange bug

Initial Comment:
OK, I dunno if this was introduced with the new
versions of httpunit etc., or not but we have a problem
when an onchange event ends up changing the response
(via form submission or setting window.location). 
HttpUnitDialog ends up with the old response, not the
new one.

The problem is demonstrated in a test in the
JavaScriptEventsTest, which I have named such that it
won't run from AllTests:
notestOnChangeOnFormElementChangesWindowLocation()

This sort of thing used to work, I'm pretty sure. 
Probably we have a change in HttpUnit that is
clobbering us.

Note that after triggering the onchange, you can check
dialog.webClient.getCurrentPage() from your test and it
will return the proper response that the onchange
directed us to.  But, HttpUnitDialog's response object
is wrong - and that is what the assertions drive off of.  

The client listener does get alerted by httpunit from
the onchange, but the new response at that point is on
the response parameter passed into the client listener
- not on webclilent.getCurrentPage().  We used to use
the response parameter ages ago, but the listner was
getting called when javascript resources loaded, and
that caused the response to unexpectedly be the
contents of a javascript file ;-).

Fun, fun, fun

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=981534&group_id=61302

[Jwebunit-development] [ jwebunit-Bugs-981318 ] Not picking up trailing space in link URL

[SourceForge.net <no...@so...>]

Bugs item #981318, was opened at 2004-06-28 08:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=981318&group_id=61302

Category: None
Group: Release 1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Not picking up trailing space in link URL

Initial Comment:
Say I have a link on a web such as:

<a id="mylink" href="mylink?param=hello+">text</a>

The "+" symbol is a URL-encoded space character.

When I do clickLink("mylink"), jWebUnit is not picking
up the trailing space, and instead goes to
"mylink?param=hello"

The same occurs when you encode the space in other
ways, e.g.

"mylink?param=hello "
"mylink?param=hello%20"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=981318&group_id=61302

[Jwebunit-development] [ jwebunit-Bugs-980105 ] Cannot extend HttpUnitDialog to create custom clickLink

[SourceForge.net <no...@so...>]

Bugs item #980105, was opened at 2004-06-25 21:03
Message generated for change (Comment added) made by jacmorel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=980105&group_id=61302

Category: None
Group: Release 1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacques Morel (jacmorel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot extend HttpUnitDialog to create custom clickLink

Initial Comment:
HttpUnitDialog does not allow to create custom clickLink.

I am trying to do a clickLink that can locate a link
with html body, so links like 
<a href=#"><em>A</em>dd project</a> 
can be found by their full html body (here
"<em>A</em>dd project") and be clicked on. For this I
need to locate the WebLink myself and then click it.
Unfortunately I can click the link but I cannot change
"resp" in the dialog. So for the dialog I haven't
clicked anything ;-(

So please make resp or submitRequest() protected.

----------------------------------------------------------------------

>Comment By: Jacques Morel (jacmorel)
Date: 2004-06-25 21:09

Message:
Logged In: YES 
user_id=149446

I just realize I am extending WebTester not HttpUnitDialog.
So either be able to 
1. inject a custom dialog into a custom WebTester
(constructor arg or setter) and make HttpUnitDialog.resp
settable by derived class or
2. have a public "resp" setter in the HttpUnitDialog.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=980105&group_id=61302

Re: [Jwebunit-development] Bug in assertTableRowsEqual?

[Laurent D. <ldu...@ya...>]

Laurent Duperval wrote:

> Laurent Duperval wrote:
>
>> Hi,
>>
>> I have a table with two header rows, two footer rows and two body 
>> rows. If I get the table row count via  getDialog(), it is correctly 
>> found as 6. However, if I try to check the content of the rows using 
>> assertTableRowsEquals, it fails.
>>
>
>
> For completeness sake, here is what the body rows look like:
>
> <tr>
> <td class="displayrow"> <input type="checkbox"
> name="toDelete" value=1234567890
> onchange="return handleFormInputChange(gFormData, this)"
> > </td>
> <td>display0</td>
> <td>1234567890</td>
> </tr>
>

After studying the code, I think I may have found the problem: I have 
several cells in my table that only contain input elements. When doing 
the validation, jwebunit strips the table to get a sparse table. In my 
case, that removes one column and at least one row from the original table.

For the time being, I'll need to patch the code  to add another method 
that doesn't strip empty cells. I would like to know if others have been 
bit by this before.

Thanks,

L

[Jwebunit-development] Re: What to do for 1.3?

[James E W. <JEW...@th...>]

> What are we going to do for 1.3? Which bugs are we going to squash, who
> is going to do such thing? Which features are we going to add? How are
> we going to test? How long are we going to develop the 1.3 release?
>
> In short: what is the future for jWebUnit?
>
> Martijn

Martijn,

In general, I'd say there's plenty of things to be done for a 1.3 release
(there are still outstanding bugs, patches, and feature requests).  With a
recent 1.2 release, though, we can have a couple of beers along the way.
I'd say a 1.3 release anytime within the next month or two would be
reasonable, and a considerable improvement over the previous year and a
half delay ;->.

We can try to use the Tracker more effectively than I have in the past ;-).
I noticed that Vivek put some things he completed recently in "Pending"
status.  I think that's a really useful thing to do.  Use the Tracker to
assign yourself to a bug, patch, or feature.  If it leads to a code change,
when it is integrated mark the item as Pending.  We can periodically look
at how many of these items we have in pending status to determine if we
have enough useful stuff for a release.

Having been an absentee team-member recently, I will compound my villainy
by preaching:

For bugs, try to write a test that reveals the bug.

For features, decide if it is a worthwhile feature first - which can
involve discussion of alternatives with the requester.  Post to this list
to get consensus if there is doubt.  Write tests for the feature.

For patch, decide if it should be incorporated.  If so, and they didn't
provide a test, try to write one.

I will be working on the fit integration over the next couple of weeks, so
probably will not be looking at any of the Tracker items.  After the fit
work is done, I'll try to pitch in on some smaller items.

Jimbo

RE: [Jwebunit-development] Re: Which is better ORO or Regexp

[Nick N. <Nic...@sn...>]

It would be nice to just use the 1.4 regexp package but I would not want to
force jwebunit to be 1.4 only.  So I would just use either regexp or oro.

regexp seems to be just the bare minimum, reg expression handling.  whereas
oro seems to be quite a bit more than just regexp.

take a look at the oro java docs.
http://jakarta.apache.org/oro/api/

either one is fine with me.  I have used regexp from jakarta and like any
reg exp package it takes a bit to get used to using regular expressions.....

See Ya,

Nick

> -----Original Message-----
> From: James E Weaver [mailto:JEW...@th...]
> Sent: Saturday, June 19, 2004 10:38 PM
> To: jwe...@li...
> Subject: [Jwebunit-development] Re: Which is better ORO or Regexp
> 
> 
> Hi Vivek,
> 
> Yup - I saw that request and thought it was pretty 
> reasonable.  I have used
> Oro before - have not used Regexp so cannot compare.  But, 
> doesn't JDK 1.4
> include regex?  We could use that, but it would require 1.4 jdk for
> jwebunit if we did.  Probably better to use a separate library.
> 
> Jim
> 
> 
> 
> 
> |---------+------------------------------------------------>
> |         |           Vivek Venugopalan <vi...@ya...> |
> |         |           Sent by:                             |
> |         |           jwe...@li...|
> |         |           ceforge.net                          |
> |         |                                                |
> |         |                                                |
> |         |           06/19/2004 09:23 PM                  |
> |         |                                                |
> |---------+------------------------------------------------>
>   
> >-------------------------------------------------------------
> ----------------------------------------------|
>   |                                                           
>                                                 |
>   |       To:       
jwe...@li...
> |
>   |       cc:                                                 
>                                                 |
>   |       Subject:  [Jwebunit-development] Which is better 
> ORO or Regexp                                      |
>   
> >-------------------------------------------------------------
> ----------------------------------------------|
> 
> 
> 
> 
> Folks
>   I am trying to add Regular expression support to
> JWebUnit and I need to pick a package to do that - I
> am left with a choice of ORO or Regexp from Apache.
> Any ideas on which is a better option?
> 
> Vivek
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San 
> Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority 
> Code NWMGYKND
> _______________________________________________
> Jwebunit-development mailing list
> Jwe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-development
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San 
> Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority 
> Code NWMGYKND
> _______________________________________________
> Jwebunit-development mailing list
> Jwe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-development
> 


- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

Re: [Jwebunit-development] Bug in assertTableRowsEqual?

[Laurent D. <ldu...@ya...>]

Laurent Duperval wrote:

> Hi,
>
> I have a table with two header rows, two footer rows and two body 
> rows. If I get the table row count via  getDialog(), it is correctly 
> found as 6. However, if I try to check the content of the rows using 
> assertTableRowsEquals, it fails.
>


For completeness sake, here is what the body rows look like:

<tr>
<td class="displayrow"> <input type="checkbox"
name="toDelete" value=1234567890
onchange="return handleFormInputChange(gFormData, this)"
 > </td>
<td>display0</td>
<td>1234567890</td>
</tr>

L

[Jwebunit-development] Bug in assertTableRowsEqual?

[Laurent D. <ldu...@ya...>]

Hi,

I have a table with two header rows, two footer rows and two body rows. 
If I get the table row count via  getDialog(), it is correctly found as 
6. However, if I try to check the content of the rows using 
assertTableRowsEquals, it fails.

If I start the count at less than 4, I get an error because of the 
column count. I have merged cells in my header and footer, so that's 
expected. But if I start at 4, I get an error saying that I expect 2 
rows but only one row was found. If I start the count at 5, the error 
says that I expected two rows but 0 were found. If I start at 6 or more, 
the error say I expect 2 rows but -1 row was found.

Any ideas what's happening?

I'm doing my testing like this:

        assertTableRowsEqual("contactsList", 4, new String[][] {
                {" ", "display0", "1234567890"},
                {" ", "display1", "1234567891"}
        });

Thanks,

L

[Jwebunit-development] [ jwebunit-Patches-977417 ] added some new functions to jwebunit

[SourceForge.net <no...@so...>]

Patches item #977417, was opened at 2004-06-22 14:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497984&aid=977417&group_id=61302

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kester Mielke (kmielke)
Assigned to: Nobody/Anonymous (nobody)
Summary: added some new functions to jwebunit

Initial Comment:
/**
* Assert that supplied text is present in a specific table.
*
* @param tableSummaryOrId summary or id attribute value
of table
* @param text text to search for
* @param link link to find in the row of text
*/
public void assertLinkInTable(String tableSummaryOrId,
int col, String text, String link) {...}

/**
* Navigate by selection of a link in a table.
*
* @param tableSummaryOrId
* @param text text to identify the link
* @param link text of the link
*/
public void clickLinkInTable(String tableSummaryOrId,
int col, String text, String link) {...}

/**
* Assert that a link containing a specified url is present.
*
* @param urlName
*/
public void assertLinkPresentWithUrl(String urlName) {...}

/**
* Navigate by selection of a link with a given image.
*
* @param imageFileName A suffix of the image's
filename; for example, to match
*                      <tt>"images/my_icon.png"</tt>,
you could just pass in
*                      <tt>"my_icon.png"</tt>.
*/
public void clickLinkWithUrl(String urlName) {...}

/**
* Click the button with the given value.
*
* @param buttonValue
*/
public void clickButtonWithValue(String buttonValue) {...}

/**
* Assert that a button with a given value is present.
*
* @param buttonValue
*/
public void assertButtonPresentWithValue(String
buttonValue) {...}

/**
* Switch to another Url without a link or button.
* If you use parameter within the url you should use
* URLEncoder.encode() to encode the parameter before.
*
* @param String url
*/
public void setUrl(String url) {...}

best regars
Kester 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497984&aid=977417&group_id=61302

[Jwebunit-development] small changes for jwebunit

[Kester M. <km...@pi...>]

hi all,

i added some functions we needed for our project.


i added the following functions. additional the are the related function=20
in WebTestCase.java and HttpUnitDialog.java
i will add a patch including all this stuff.

/**
 * Assert that supplied text is present in a specific table.
 *
 * @param tableSummaryOrId summary or id attribute value of table
 * @param text text to search for
 * @param link link to find in the row of text
 */
public void assertLinkInTable(String tableSummaryOrId, int col, String=20
text, String link) {...}

/**
 * Navigate by selection of a link in a table.
 *
 * @param tableSummaryOrId
 * @param text text to identify the link
 * @param link text of the link
 */
public void clickLinkInTable(String tableSummaryOrId, int col, String=20
text, String link) {...}

/**
 * Assert that a link containing a specified url is present.
 *
 * @param urlName
 */
public void assertLinkPresentWithUrl(String urlName) {...}

/**
 * Navigate by selection of a link with a given image.
 *
 * @param imageFileName A suffix of the image's filename; for example,=20
to match
 *                      <tt>"images/my_icon.png"</tt>, you could just=20
pass in
 *                      <tt>"my_icon.png"</tt>.
 */
public void clickLinkWithUrl(String urlName) {...}

/**
 * Click the button with the given value.
 *
 * @param buttonValue
 */
public void clickButtonWithValue(String buttonValue) {...}

/**
 * Assert that a button with a given value is present.
 *
 * @param buttonValue
 */
public void assertButtonPresentWithValue(String buttonValue) {...}

/**
 * Switch to another Url without a link or button.
 * If you use parameter within the url you should use
 * URLEncoder.encode() to encode the parameter before.
 *
 * @param String url
 */
public void setUrl(String url) {...}

best regars
Kester

--=20
Mit freundlichen Gr=FC=DFen
Kester

---------------------------------------------------------------
PIRONET NDH AG
Kester Mielke - Quality Assurance
Maarweg 149-161 - 50825 Cologne - Germany
Phone: +49 (0)221-770-1723 - Fax: +49 (0)221-770-1005
<mailto:km...@pi...> - <http://www.pironet-ndh.com>
---------------------------------------------------------------

[Jwebunit-development] Re: Chnages to jwebunit

[Martijn D. <ma...@da...>]

Hi Kester,

>during our project i made some chnages to jwebunit. i just
>switched to version 1.2 and added all my changes to this
>version.
>  
>
Could you repost the question to the users list, or the development 
list? This way everybody can look at your request.

As for the changes, could you describe why and what you have done? 
Perhaps create a RFE or a patch on sourceforge?

>can you have a look at my changes and hopefully add them to
>jwebunit. how to handle this?
>  
>
Just create a patch (or zip your changes) and create a patch on the 
sourceforge issue tracker. Then they are available for anyone to 
incorporate, and us to merge them into the jWebunit framework (when 
appropriate).

With regards,

Martijn

[Jwebunit-development] [ jwebunit-Bugs-974592 ] Button onclick="window.open('http://www.google.de','_self');

[SourceForge.net <no...@so...>]

Bugs item #974592, was opened at 2004-06-17 10:49
Message generated for change (Comment added) made by matani
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=974592&group_id=61302

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Saleh matani (matani)
Assigned to: Nobody/Anonymous (nobody)
Summary: Button onclick="window.open('http://www.google.de','_self');

Initial Comment:
when click this button i get 2 windows on Response , 
and currentpage set to the window with the clicked 
button!

HTML code
----------------------------------------------------
<form name="myform">
 <button type="button" id="mybutton" 
onclick="window.open('http://www.google.de','_self');" 
title="myTitel" clickMe!
 </button> 
</form>
----------------------------------------------------
Quastion!
when i use the Javascript onclick and _self as target 
window , i use to get the target window(reponse) as 
currentpage but it opens the targen in a new window! 
because of that i get 2 windows! thats mean that my 
webapplication with frames can not be tested well! until 
this BUG be fixed! , i know its not a Jwebunit BUG but it 
is a new bug of a Framework witch Jwebunit needs , i 
have tried old version of the Frameworks 
(xmlapi ,js.jar ,httpunit...) but it is the same!

i will sign this as a bug  ,mybe i can get some help witch 
libs versions to use to fix this bug

thank

Matani


----------------------------------------------------------------------

>Comment By: Saleh matani (matani)
Date: 2004-06-22 09:35

Message:
Logged In: YES 
user_id=923609

its a HttpUnit BUG.

This BUG hase been fixed by HttpUnit Developer and will be 
Avilable the next Release , for fix please download the CVS 
from httpUnit and deploy a jar File 

for more info mail me.
Matani

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=974592&group_id=61302

[Jwebunit-development] What to do for 1.3?

[Martijn D. <ma...@da...>]

What are we going to do for 1.3? Which bugs are we going to squash, who 
is going to do such thing? Which features are we going to add? How are 
we going to test? How long are we going to develop the 1.3 release?

In short: what is the future for jWebUnit?

Martijn

[Jwebunit-development] Changes to sf.net tracker options

[Martijn D. <ma...@da...>]

Hi!

I updated the trackers to send e-mail whenever a something changes on an 
issue. All updates are sent to the development lists.

This way we can all see much easier what is happening on those trackers.

Martijn

[Jwebunit-development] Re: Which is better ORO or Regexp

[James E W. <JEW...@th...>]

Hi Vivek,

Yup - I saw that request and thought it was pretty reasonable.  I have used
Oro before - have not used Regexp so cannot compare.  But, doesn't JDK 1.4
include regex?  We could use that, but it would require 1.4 jdk for
jwebunit if we did.  Probably better to use a separate library.

Jim




|---------+------------------------------------------------>
|         |           Vivek Venugopalan <vi...@ya...> |
|         |           Sent by:                             |
|         |           jwe...@li...|
|         |           ceforge.net                          |
|         |                                                |
|         |                                                |
|         |           06/19/2004 09:23 PM                  |
|         |                                                |
|---------+------------------------------------------------>
  >-----------------------------------------------------------------------------------------------------------|
  |                                                                                                           |
  |       To:       jwe...@li...                                                |
  |       cc:                                                                                                 |
  |       Subject:  [Jwebunit-development] Which is better ORO or Regexp                                      |
  >-----------------------------------------------------------------------------------------------------------|




Folks
  I am trying to add Regular expression support to
JWebUnit and I need to pick a package to do that - I
am left with a choice of ORO or Regexp from Apache.
Any ideas on which is a better option?

Vivek



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Jwebunit-development mailing list
Jwe...@li...
https://lists.sourceforge.net/lists/listinfo/jwebunit-development

[Jwebunit-development] Which is better ORO or Regexp

[Vivek V. <vi...@ya...>]

Folks
  I am trying to add Regular expression support to
JWebUnit and I need to pick a package to do that - I
am left with a choice of ORO or Regexp from Apache. 
Any ideas on which is a better option?

Vivek


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: [Jwebunit-development] RE: Problem with TestServer in debug m ode

[Martijn D. <ma...@da...>]

Nick Neuberger wrote:

>I'm all for using something else.
>
>However, I did find a workaround in debug mode.  You can't interuppt the
>beginAt methods or any gotoPage methods.
>I just put a breakpoint after these lines.
>
>Sounds like a generaic test webapp using jetty.  I'm not too familair with
>jetty.
>
>If we all agree, Is anyone interested in doing this change to jetty and a
>full webapp.  I may be able to attempt it but it may be a while before I
>make the changes.  Been very busy lately at work.
>
>I have to find something for the jacobie api and a test harness anyway.
>
>Too bad there wasn't a generic sf project that just had jetty and a generic
>test webapp that has generic tests.  This may seem like to the extreme, but
>it makes more sense like this.  Then jacobie project, jwebunit project could
>both use the same testing webapps structure.
>  
>

Like I said, I'm in the process of writing an article for the 
integration of jetty and jwebunit. On our current client project, we 
already have done the integration. If you don't need JNDI, the process 
is really simple. If you don't need JSP's, then it is really a jiffy.

I can send an example project to the list. If I finish the article 
(someday soon I hope), maybe I need to set up a seperate SF project. Or 
we could host the integration example in the jWebUnit CVS as a seperate 
subproject.

Martijn