Yes, we do contribute several class transform workers. We had similar problems with those trying to access methods that had not yet been added to the component class until we added explicit order constraints, which lead to my initial guess that the problem may be because not all the class transform workers added by 'TapestryModel' had such constraints and that there may be variations in the order, perhaps depending on where module classes doing the contribution appear in the class path. However, after looking into the classes in more detail, I don't think that could explain the error where '_$resources' is not found by 'ComponentWorker', because (If I understand the code correctly) that is set up in the 'InternalClassTransformationImpl' constructor, so it should always be available.
Doug > -----Original Message----- > From: Howard Lewis Ship [mailto:[email protected]] > Sent: Wednesday, January 05, 2011 3:53 PM > To: Tapestry development > Subject: Re: [T5.1] Sporadic 'CannotCompileException', perhaps due to > varying order of 'ComponentClassTransformWorker' contributions > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
