Interesting... The 5.2 code has changed significantly for class transformation and the RenderPhaseMethodWorker is very different.
It looks like there could be a hole in the 5.1.0.5 code where the generated class might try to reference a method in the super class that doesn't exist, but it'd require more time than I have available to prove it. Are you deploying into a running server where you're possibly getting hit with multiple requests concurrently during startup? Or are you seeing this with a single request? Josh On Tue, Jan 4, 2011 at 7:25 PM, Doug Hauge <[email protected]> wrote: > 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] > >
