We are seeing a problem where an application is sporadically deployed in a state where Tapestry components will not compile. When this happens, if the application is subsequently redeployed (without any changes to the code), everything works fine. This is a fairly rare occurrence, and we have not yet found a way to reproduce this in a test environment, but I'd like to see if anyone else has encountered something similar or has any ideas as a possible cause.
For any given deployment for which there are compilation problems, the exact stack trace depends on the page that is hit, but it typically involves a 'javassist.CannotCompileException' exception thrown (indirectly) from 'ComponentClassTransformerImpl.transformComponentClass'. A few example errors are: javassist.CannotCompileException: [source error] afterRender(org.apache.tapestry5.MarkupWriter,org.apache.tapestry5.runtime.Event) not found in org.apache.tapestry5.corelib.base.AbstractTextField (thrown from RenderPhaseMethodWorker.transform(RenderPhaseMethodWorker.java:156)) javassist.CannotCompileException: [source error] no such class: _$resources (thrown from ComponentWorker.transform(ComponentWorker.java:83)) The common symptom seems to be that some method or field required by a component class transform worker was not added by a previous worker in the chain. Because this problem goes away if the application is redeployed, it seems to be the case that the order of component class transform workers may vary between deployments. Looking at 'TapestryModule.contributeComponentClassTransformWorker', many of the workers are contributed without explicit ordering constraints, so I'm thinking that there are some orderings of the workers that satisfy all the specified constraints but don't build the component class in the correct order, and these invalid orderings may occasionally be used. Does this seem reasonable? Is there any reason not to specify an explicit ordering for all component class transform workers contributed by 'TapestryModule'? We are seeing this problem in Tapestry 5.1.0.5. One reason we may be seeing this more than others is that we are contributing many custom component class transform workers, which may(?) be introducing more variability in the ordering of the workers. Doug --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
