You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Doug Hauge <do...@lithium.com> on 2011/01/05 04:25:13 UTC
[T5.1] Sporadic 'CannotCompileException', perhaps due to varying
order of 'ComponentClassTransformWorker' contributions
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: [T5.1] Sporadic 'CannotCompileException', perhaps due to
varying order of 'ComponentClassTransformWorker' contributions
Posted by Doug Hauge <do...@lithium.com>.
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:hlship@gmail.com]
> 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
> <jo...@gmail.com>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 <do...@lithium.com>
> 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:joshcanfield@gmail.com]
> > > > 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
> <do...@lithium.com>
> > > > 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: dev-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > > >
> > > > >
> > >
> > > -------------------------------------------------------------------
> --
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [T5.1] Sporadic 'CannotCompileException', perhaps due to varying
order of 'ComponentClassTransformWorker' contributions
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <jo...@gmail.com>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 <do...@lithium.com> 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:joshcanfield@gmail.com]
> > > 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 <do...@lithium.com>
> > > 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: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
--
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
Re: [T5.1] Sporadic 'CannotCompileException', perhaps due to varying
order of 'ComponentClassTransformWorker' contributions
Posted by Josh Canfield <jo...@gmail.com>.
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 <do...@lithium.com> 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:joshcanfield@gmail.com]
> > 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 <do...@lithium.com>
> > 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: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
RE: [T5.1] Sporadic 'CannotCompileException', perhaps due to
varying order of 'ComponentClassTransformWorker' contributions
Posted by Doug Hauge <do...@lithium.com>.
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:joshcanfield@gmail.com]
> 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 <do...@lithium.com>
> 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [T5.1] Sporadic 'CannotCompileException', perhaps due to varying
order of 'ComponentClassTransformWorker' contributions
Posted by Josh Canfield <jo...@gmail.com>.
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 <do...@lithium.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: [T5.1] Sporadic 'CannotCompileException', perhaps due to
varying order of 'ComponentClassTransformWorker' contributions
Posted by billapepper <ni...@ifactory.com>.
Hey Douglas,
Have you every figured this out, we seem to be having this same issue... it
is a little early to tell, but it seems to have become more prominent after
upgrading from 5.1.0.4 to 5.1.0.8...
It is actually critical for me to figure this out, so please share your
solution if you have found one!
--
View this message in context: http://tapestry.1045711.n5.nabble.com/T5-1-Sporadic-CannotCompileException-perhaps-due-to-varying-order-of-ComponentClassTransformWorker-cs-tp3328197p5717067.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org