I finally got to the bottom of this, turned out to be a rather complicated
problem on our end.
Thanks for all your help.
On Tue, Feb 25, 2014 at 12:44 AM, Lance Java wrote:
> Hi Travis, a few Q's
>
> 1. Have you configured the ignored paths as documented here:
>
> http://tapestry.apache.org/con
Hi Travis, a few Q's
1. Have you configured the ignored paths as documented here:
http://tapestry.apache.org/configuration#Configuration-ConfiguringIgnoredPaths
2. If so, what's your config?
3. If not, how does this work?
4. Give an example t5 url?
5. Give an example t4 / JSP url
6. Give an e
It's actually the JSP that needs to be aware of the tapestry requests.
We are injecting tapestry 5 services that have dependencies on the tapestry
5 request into the
JSP or tapestry 4 pages. Without this code it breaks.
Also we are calling cleanupThread().
I've tried storeServletRequestResponse
It's pretty hacky what you're doing. I think you'll also need to call
Registry.cleanupThread() to give Tapestry a chance to cleanup any PerThread
values that are created during your quasi half arsed Tapestry request ;)
http://tapestry.apache.org/5.3.7/apidocs/org/apache/tapestry5/ioc/Registry.html
Hmm... This could well be the source of your problem. I think you'll also
need to call ResponseGlobals. storeServletRequestResponse(...)
I'm not sure I fully understand your non-tapestry flow. Why do you need
Tapestry to be aware of the JSP requests?
I'm assuming you have contributed to the ignor
I've looked at the request/response traffic and nothing looks unusual.
In fact the JSONObject that is passed to
JSONObjectEventResultProcessor.processResultValue(JSONObject value)
looks perfectly fine.
We do have a custom filter, which enables tapestry injection in
non-tapestry 5 environments, (i.
Strange, do you have any custom request filters running? Any custom
threads?
Failing that, can you use the dev tools in your browser to inspect the
requests / response traffic? Anything strange?
