I work on a project that is using Tapestry 3. We're currently working
on version 4 of this product, and in this release we have upgraded to
version 3.0.4 of Tapestry. In every version of our product we have
done some amount of load testing as part of our quality assurance
process.
In this release, we've started seeing this sort of exception a lot
during load (and occasionally in our functional) testing.
Tapestry exception
java.lang.Throwable: Unable to define class
org.apache.tapestry.link.PageLink$Enhance_32: org/apache/tapestry/
link/PageLink$Enhance_32 (Repetitive method name/signature)
at
org.apache.tapestry.enhance.EnhancedClassLoader.defineClass
(EnhancedClassLoader.java:55)
at
org.apache.tapestry.enhance.javassist.EnhancedClass.createEnhancedSubcla
ss(EnhancedClass.java:133)
at
org.apache.tapestry.enhance.ComponentClassFactory.createEnhancedSubclass
(ComponentClassFactory.java:336)
at
org.apache.tapestry.enhance.DefaultComponentClassEnhancer.constructCompo
nentClass(DefaultComponentClassEnhancer.java:139)
at
org.apache.tapestry.enhance.DefaultComponentClassEnhancer.getEnhancedCla
ss(DefaultComponentClassEnhancer.java:94)
at
org.apache.tapestry.pageload.PageLoader.instantiateComponent
(PageLoader.java:603)
This doesn't always seem to happen on the same page, and it isn't
always the same component that throws the exception. (Here it is
PageLink, I've also seen Any and Body throw this).
I've been scratching my head on this for a while, trying to figure
out why we hadn't seen this in previous releases... Then I remembered
we switch to 3.0.4, and I decided to look into the differences.
I found something in the DefaultComponentClassEnhancer which has
changed, and I'd be interested in hearing if anybody believes this
could cause my problem.
Specifically the method getEnhancedClass has changed from the
following in 3.0.3
public Class getEnhancedClass(IComponentSpecification specification,
String className)
{
Class result = getCachedClass(specification);
if (result == null)
{
synchronized(this)
{
result = getCachedClass(specification);
if (result == null)
{
result = constructComponentClass(specification,
className);
storeCachedClass(specification, result);
}
}
}
return result;
}
to this in 3.0.4
public Class getEnhancedClass(IComponentSpecification specification,
String className)
{
synchronized(specification)
{
Class result = getCachedClass(specification);
if (result == null)
{
result = constructComponentClass(specification,
className);
storeCachedClass(specification, result);
}
return result;
}
}
Now, my understanding of the tapestry internals has plenty of holes
in it, so I don't know if this can be related to my problem or not,
but the circumstances are such that it feels like a likely candidate.
To try to test this theory myself, I have created a custom
ComponentClassEnhancer implementation which basically reverts back to
the 3.0.3 synchronization style - however, I haven't had an
opportunity to get it into a load test environment yet. I should be
able to do this sometime early this week.
I'd love to hear from any developers who feel they can verify that
this is my problem, or debunk it totally. :)
Thanks much,
Jeff Poetker
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
