<lfryc> since there are race conditions when requesting the page immediatelly after initial page load
<lfryc> browser requests HTML, then it loads favicon.ico, images, scripts, css, etc.
<lfryc> that's the time when we expect AJAX request, but request for those evil resources come
<lfryc> so it's time to define smart filters which decides what request to enrich
<aslak> client multi threads the resource request ?
<lfryc> but it can't be written generally enough, since you can't simply map request URL to content-type or so
<lfryc> yeah, browsers usually loads up to 5 resources at time
<lfryc> it is not issue with htmlunit (that's why unit tests pass just fine)
<lfryc> but real browsers have cause issues
<aslak> lfryc, you can't look at the accept header ?
<lfryc> aslak: it's not silver-bullet
<lfryc> browser may not need to send that header
<aslak> true
<lfryc> I think we have two options:
<lfryc> 1) smart heuristics
<lfryc> 2) framework-dependent filters
<aslak> you have control over the proxy, so you should be able to sync up at that level how ever you want it
<lfryc> you mean I can force client to send accept-header?
<aslak> lfryc, hehe no, as in race conditions i mean
<lfryc> race condition - I mean, request fighting in what will be enriched
<aslak> lfryc, you could in theory throttle the request
<aslak> aa ok
<aslak> there should be multiple types of filters.. accept headers, url pattern etc
<lfryc> hmm but browsers usually sents correct accept-headers for images/icons/etc.
<lfryc> for resource types they know what to expect
<aslak> depending on the use case, not all will work. if browsers don't sent accept headers, that filter migh tbe more useful in a REST request
<lfryc> yes, we could provide multiple types of filters
<lfryc> thinkinga bout framework-specific and smart ones
<lfryc> user may decide which to use for given use case
<aslak> yea
<lfryc> use the most appropriate one for the use case
<lfryc> and choose/configure default one in arquillian.xml
<aslak> i think you can provide in warp core http based filters

• jharting has quit (Quit: Leaving.)
  <aslak> i guess that would be, request content, url and headers
• alesj has quit (Quit: Leaving.)
  <lfryc> that's going to be huge
  <lfryc> and then framework specific filters, which can be easier to use
  <aslak> where does arq.xml come in?
• rmannibucau has quit (Remote host closed the connection)
• ge0ffrey has quit (Ping timeout: 240 seconds)
  <lfryc> configure defaults
  <lfryc> like, I want to use JSF filter with FacesServlet mapping on /xyz
  <aslak> default what? fitler ?
  <lfryc> yep
  <lfryc> when no filter specified, default can be used
  <aslak> arn't filters on a .execute() level ?
  <lfryc> yep, they are
  <lfryc> oh, no, they are on the proxy level
• DavideD has quit (Ping timeout: 245 seconds)
  <aslak> ok, so basically via arq.xml you can say that only ever enrich jsf requests in this suite, what ever i might be calling
  <lfryc> which is on client-side
  <lfryc> but evaluated after client action
  <aslak> lfryc, sure, but i mean you don't need global filters. the individual .execute methods would define them
  <aslak> (not saying you can't have global)
  <lfryc> yes, but main use case for Warp is verifying request pages
  <aslak> eh, to rephrase.. a Filter is active from .execute start til end
  <lfryc> not resources
  <lfryc> so global might be handy
  <lfryc> but still you can define per Warp execution
• #jbosstesting :End of Channel Ban List
  <aslak> and it work now based on just selecting the first request within the execute block
  <lfryc> yep
  <lfryc> first come, first served
  <aslak> so unless you wanted to enrich resources, you could really just split up the requests in two executes
  <lfryc> yep
• qmx is now known as qmx|away
  <aslak> HTTP filters should work with Resources and AJax request, by either headers or url
  <aslak> a JSF filter would basically be a URL filter no?
  <lfryc> yes, it will be URL pattern filter
  <aslak> yea
  <aslak> what was the issue ?
  <aslak>
  <aslak> known how to filter?
  <aslak> or the browser doing multi threaded requests that potentially create multiple enriched requests ?
  <lfryc> know what reuqest to filter
  <lfryc> know what to filter because browser may request pages/resources in parallel
  <aslak> does the parallel matter ?
  <lfryc> it matters, because without filtering, you can't choose what request to enrich/verify
  <lfryc> so you can either enrich first or enrich all
• ge0ffrey (~ge0ffrey@174.195-241-81.adsl-dyn.isp.belgacom.be) has joined #jbosstesting
• ge0ffrey has quit (Changing host)
• ge0ffrey (~ge0ffrey@redhat/jboss/ge0ffrey) has joined #jbosstesting
• balunasj is now known as balunasj|lunch
  <lfryc> when enriching all requests, you can always wait for response and then decide on the content-type basis
  <lfryc> but considering each such Warp-enriched request can have side-effects
  <lfryc> ...it's very fragile solution then
  <lfryc> thus we need to filter requests
  <lfryc> and enriched only right-ones
  <lfryc> we could also check if there are no parallel requests which would match defined filter
  <lfryc> and if so, report a issue
  <lfryc> DefineExactFiltersDudeException: hey man, in certain conditions, there might be more requests triggered by given client action
  <aslak> we can't handle two enriched requests at once ?
  <lfryc> we can
  <lfryc> yeah, we can
  <aslak> it would be useful
  <lfryc> then it should be declared explicitly I think..
  <lfryc> do you have some use case in mind?
  <lfryc> I consider that anti-pattern
  <aslak> some kind of server side resource processing
  <lfryc> that should be two separated tests then
  <aslak> mm.. that could be..
  <aslak> the html generate two child request for 'images'. you want to verify that the image alg work server side
  <lfryc> or you could define two various filters in one Warp execution
  <aslak> RF.url(".*jpg')
  <lfryc> yeah, then you need to use URL pattern and hard-code the image name
  <lfryc> for first/second image
• maeste has quit (Quit: Ex-Chat)
• sacdroid (~sachin@65.202.239.135) has left #jbosstesting
• pilhuhn is now known as pil-dinner
  <aslak> lfryc, if you can use the same ServerAssertion object.. not sure why you have to define the enrichment twice
• PeteRoyle has quit (Ping timeout: 255 seconds)
  <lfryc> the outcome will be two ServerAssertions
  <lfryc> from two responses
  <lfryc> since Warp is now resource-oriented
  <lfryc> sorry, request-oriented
  <aslak> lfryc, let's say for what ever reason, i want to assert that a log entry in the database is entered when i generate a resource. i do .execute wit hfilter /*generated/*jpg', in the ServerAssertion object i inject the PersistenceContext and the HttpRequest and check that the correct log line is there. for all images in that request
• sannegrinovero has quit (Quit: Leaving)
  <lfryc> right, that's valid use case
  <aslak> warp could even optionally return a 'status' object, telling me how many filters were executed, which requests where enriched etc
  <lfryc> right now, we return the clone of ServerAssertion provided
  <lfryc> but we could actually write properties of the bean back to the original
  <lfryc> and return the status
  <lfryc> (instead of assertion bean)
  <aslak> could do similar to jpa, getSingleResult or getList
• ldimaggi has quit (Ping timeout: 264 seconds)
  <aslak> if you know you will only have one ServerAssertion hit/enrichment, you can use getSingleResult, if you have a pattern that match multiple, use getList() which will contain all matches
  <aslak> not cloning the ServerAssertion would get tricky in the multiple hit case
• maschmid has quit (Quit: Ex-Chat)
  <lfryc> yep
  <lfryc> WarpStatus verifies(ServerAssertion);
• Notify: mhicks is online (irc.freenode.net).
• kpiwko has quit (Ping timeout: 260 seconds)
• PeteRoyle (~PeteRoyle@203-4-173-70.perm.iinet.net.au) has joined #jbosstesting
  <aslak> WarpStatus status = Warp.execute(ClientAction).filters(RF...).verify(ServerAssertion)
  <aslak> status.getAssertion|getAssertions|getFilterMatches
• ppitonak has quit (Quit: Konversation terminated!)
  <aslak> hmm.. would we need multiple ServerAssertions based on filters
• jean (~jean@203.117.19.120) has joined #jbosstesting
• jean has quit (K-Lined)
  <aslak> .execute(CA).group().filters(".jsf").verify(SA_1).group(...).filters(".jpg").verify(SA_2)