That are is pretty well synchronized; that's to say, only one thread should ever be running component class transformations ... this is by design of ClassLoader (and the Javassist ClassLoader). I'm at a loss ... are you contributing any of your own class transfom workers?
On Wed, Jan 5, 2011 at 3:26 PM, Josh Canfield <[email protected]>wrote: > 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] > > > > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
