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 Tapestry instruments. I had previously
done this a few times before a later release of Javassist fixed the
problem ... or so I thought.
You may also do ok by getting the value from the parameter into a
local variable outside the try ... finally block. try ... finally
support is a late addition to Javassist and is perhaps buggy.
On Feb 11, 2008 9:58 AM, Adriaan Joubert <[EMAIL PROTECTED]> wrote:
> 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 this it runs
> through. I've spent several hours trying to produce a small test case (the
> actual site includes a 500k line internal library), and, even though it
> looks very similar it runs through fine. I'll continue trying to produce a
> test case, but in the meantime is there anything I can do to identify the
> cause?
>
> Thanks,
>
> Adriaan
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
