18 January 2026:
Sahi Pro is an enterprise grade test automation platform which can automate web, mobile, API, windows and java based applications and SAP.
This forum is now archived and is in read-only mode. Please continue discussions on our improved new Sahi Pro Community forum.
Sahi Pro is an enterprise grade test automation platform which can automate web, mobile, API, windows and java based applications and SAP.
How to configure ErraiBus to be testable by sahi?
hoija
Members
Hi!
I'm successfully testing our Icefaces application with Twist and sahi.
Right now we are looking into using Errai, a "... a GWT-based framework for building rich web applications using next-generation web technologies. Built on-top of ErraiBus, ..." https://docs.jboss.org/author/pages/viewpage.action?pageId=5833083
instead of Icefaces.
There is a prototype of our application build with the new framework, but sahi does not seem to recognize when the page is loaded.
I already set xhr.wait_ready_states=2,3 like statet at http://sahi.co.in/w/trouble-shooting-sahi but sahi still keeps on waiting.
When setting xhr.wait_ready_states=0 or =4 sahi recognizes the site to be loaded but runs through the test steps without any waiting anywhere.
Setting the ErraiBus to use the SimpleDispatcher with DefaultBlockingServlet helps as sahi now sees the page is loaded and waits as expected (with no explicitly set xhr.wait_ready_states), but only when tried with a simple Thread.sleep for sahi to wait for, not for more complex scenarios.
The problem seems to be with the configuration of the ErraiBus (https://docs.jboss.org/author/display/ERRAI/Messaging+Overview).
There is a SimpleDispatcher and a AsyncDispatcher to choose from and 7 possible servlet implementations to use, for example the DefaultBlockingServlet or the StandardAsyncServlet.
Does anybody know which combination should be testable with sahi as part of our ongoing investigation regarding our new implementation? I really would like to keep sahi for our testing.
Google does not say much about the combination sahi/Errai ( http://www.jboss.org/errai )
Thank you.
Firefox 19.0
sahi as packaged with Twist 2.5.0.12867-30f094d0c90ec2
Windows 7 professional 64 bit
I'm successfully testing our Icefaces application with Twist and sahi.
Right now we are looking into using Errai, a "... a GWT-based framework for building rich web applications using next-generation web technologies. Built on-top of ErraiBus, ..." https://docs.jboss.org/author/pages/viewpage.action?pageId=5833083
instead of Icefaces.
There is a prototype of our application build with the new framework, but sahi does not seem to recognize when the page is loaded.
I already set xhr.wait_ready_states=2,3 like statet at http://sahi.co.in/w/trouble-shooting-sahi but sahi still keeps on waiting.
When setting xhr.wait_ready_states=0 or =4 sahi recognizes the site to be loaded but runs through the test steps without any waiting anywhere.
Setting the ErraiBus to use the SimpleDispatcher with DefaultBlockingServlet helps as sahi now sees the page is loaded and waits as expected (with no explicitly set xhr.wait_ready_states), but only when tried with a simple Thread.sleep for sahi to wait for, not for more complex scenarios.
The problem seems to be with the configuration of the ErraiBus (https://docs.jboss.org/author/display/ERRAI/Messaging+Overview).
There is a SimpleDispatcher and a AsyncDispatcher to choose from and 7 possible servlet implementations to use, for example the DefaultBlockingServlet or the StandardAsyncServlet.
Does anybody know which combination should be testable with sahi as part of our ongoing investigation regarding our new implementation? I really would like to keep sahi for our testing.
Google does not say much about the combination sahi/Errai ( http://www.jboss.org/errai )
Thank you.
Firefox 19.0
sahi as packaged with Twist 2.5.0.12867-30f094d0c90ec2
Windows 7 professional 64 bit
Best Answer
-
Hi!
I found my solution: when using ErraiBus you have to start the jboss server with -Dorg.jboss.errai.bus.do_long_poll=false to make your application testable. Then sahi runs perfectly fine and "sees" when to wait and when to go further.
Without this option - at least in our case - it took 20 - 40 seconds in beetween each step, sometimes it felt even longer.
No need to set xhr.wait_ready_states on sahi's side.
Probably this is helpful for others, too.
Thank you