You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2026/04/04 14:48:00 UTC
[jira] [Commented] (TAP5-2821) ReloadSpec fails occasionally on CI
[ https://issues.apache.org/jira/browse/TAP5-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071050#comment-18071050 ]
ASF subversion and git services commented on TAP5-2821:
-------------------------------------------------------
Commit 0d18da2e0abfea9db636a32a8f2df07c210d950a in tapestry-5's branch refs/heads/javax from Ben Weidig
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=0d18da2e0 ]
TAP5-2821: ReloadSpec write bytecode first, touch after
> ReloadSpec fails occasionally on CI
> -----------------------------------
>
> Key: TAP5-2821
> URL: https://issues.apache.org/jira/browse/TAP5-2821
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-ioc
> Affects Versions: 5.10.0
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Major
>
> The ReloadSpec.groovy Spock tests fail the {{reload a proxy object}} test occasionally on CI.
> Two issues were found as possible culprits in the Groovy test:
> * touch() is called before createImplementationClass. The touch() ensures the lastModified is after the current one. However, writing the bytes after the touch might reset the time, and now it depends on the FS granularity.
> * touch() uses Thread.sleep(...) with XOR (^) resulting in non-linear increatings times
> Changing the order of operations (first writing the bytes, then touching) seems to fix the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)