20828Re: FitNesse parsing limit?
- Jul 17 6:32 AM
First, thank you so much for your responses. I appreciate that this work is all done by volunteers and tracking down issues of this sort is onerous.
What I have concluded from the directly (and indirectly) referenced issues is that we are bumping up against the 999,999 (~1Mb) character limit that the current SliM implementation imposes. There are actually at least 5 separate GitHub issues devoted to this problem (115, 183, 198, 223, 319). While none of them mention the specific error message I’m seeing, this may be because the reporters are primarily encountering the limit on the response instead of the request. These issues all include substantive discussions, with some defending and some challenging the need for tables larger than 1Mb. Let me add my voice to the defense.
I think, in some ways, FitNesse is a victim of it’s own success. It is a brilliant architecture and has gained many adherents. As a result, users around the world are employing FitNesse in wonderful ways that no one could have entirely anticipated. In our case, we have unambiguously proven that by leveraging scenario tables in a tiered approach, we can achieve high levels of reuse, greatly decreasing the time required to create and maintain complex insurance system testing suites as we go from sprint to sprint and client to client.
This 1Mb limit is now stopping us dead in our tracks because, in our case, it’s not about splitting large decision tables, it’s about the underlying scenario table hierarchy.
Where this issue stands
Arnout (raboof) created a fork (https://github.com/raboof/fitnesse/commit/0bbd3c4646e32c2891210aaa18234646a22dfd01) on 7/25/12 that allow for responses larger than 1Mb.
319 (https://github.com/unclebob/fitnesse/issues/319) remains open with the last comment on 9/17/13.
Given the immediacy of the issue for us, I’d like to start by verifying that surmounting the 1Mb limit would indeed resolve our issue. Thus, I would like to try raboof’s patch (above), but it looks like it only addresses the response, not the request (it modifies ListDeserializer.deserialize but not ListSerializer.serialize). Of course my knowledge of FitNesse/SliM is next to nothing, so I may be wrong. Also, I’m concerned that we might be using FitNesse features that aren’t present in the mid-2012 release from which the patch was forked, so I’d like to apply raboof’s changes (fortunately they are pretty minimal) to the current release (v20140630). I need to end up with a revised fitnesse-standalone.jar. Let me confess that I’m not Git/GitHub savvy, as we work in a Subversion environment. Would it be possible for someone to confirm that the raboof patch addresses both the request and response and either create the jar for us or else point me in the right direction (we are an eclipse/java shop)?
My sincere appreciation for your help.
- << Previous post in topic Next post in topic >>