JGit commit objects are a recursive data structure; they have links to
their parent commits. Serializing a JGit commit will try to recursively
serialize all reachable ancestors as faras they have been loaded. If
that ancestor chain is too long, a StackOverflowError is thrown during
Wicket's page serialization if a page has a reference to sucha JGit
commit.
Fixed by making sure that pages o not contain references to JGit
commits. Use the (existing) wrapper object RepositoryCommit instead.
* RepositoryCommit has a transient reference to the JGit commit and
reads the commit from the repository upon de-serialization.
* RefModel is a similar case (JGit tags/branches may also have links
to the commits they point to). Solved a bit differently by making it
a pure data object by transferring the interesting data from the JGit
object in the constructor.
* Change DataViews instantiated with RevCommit to use RepositoryCommit
instead.
* Change inner anonymous DataViews to ensure they do not have a
synthesized field referencing the "allRefs" map. Such a synthesized
field would also get serialized, and then serialize JGit commits
again.
Finally, remove non-transient logger instances in Wicket classes. Those
might lead to NotSerializableException.
These StackOverflowErrors have been reported in several places since
2014:
projects / gitblit.git / commit