It might be possible. I haven't done a thorough look through the code though.
On Wed, Jan 5, 2011 at 2:56 PM, Doug Hauge <[email protected]> wrote: > 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] > >
