We have typically seen this on live deployments where it is likely to be hit by multiple requests concurrently after startup, but I think it has also been seen in a few environments where it would have been hit with a single request after startup.
Are you suggesting that the problem might be a race condition in the component compilation, so having multiple requests hitting a page at the same time may be more likely to trigger the problem? I can try including requests from many threads in my attempts to reliably reproduce the behavior. Doug > -----Original Message----- > From: Josh Canfield [mailto:[email protected]] > Sent: Tuesday, January 04, 2011 11:11 PM > To: Tapestry development > Subject: Re: [T5.1] Sporadic 'CannotCompileException', perhaps due to > varying order of 'ComponentClassTransformWorker' contributions > > 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.runt > ime.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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
