Thanks for the suggestions! I've checked the javassist versions - I
initially had two different versions of 3.6. I think you are right that this
is more likely a javassist issue than a tapestry issue. I have a workaround
on our development machines (both linux and windows), but the resulting war
st
I don't know about the cause, though you if you are deploying inside
JBoss, you may be seeing a conflict on the version of Javassist.
The workarounds for these cases are to encapsulate the affected
instance variable inside its own (private) accessor methods. That
simplifies the method that Tapest
Hi Howard,
More information. The actual error is
"bad frame_type in StackMapTable"
and is thrown from javassist.bytecode.StackMapTable.stackMapFrames(int,int).
Not sure whether this helps, but it looks as if the stack is messed up.
There is a try {...} finally{..} in the code, and if I remove t
Hi,
I did some more research into this, and the root cause is a a BadBytecode
exception in line 213 in javassist.expr.FieldAccess in the method replace0,
where the error occurs in the insertGap method. It is attempting to insert a
gap of length 11, which looks innocuous enough. I got somewhat lost
I haven't been seeing this, it's new to me. What JDK and OS are you using?
Earlier versions had some issues with inner classes that were resolved.
If you could turn on debugging of generated classes it would be
useful. Enable logging for your component class name and it will be
produced at leve
