thanks! here is what i have found out so far... it is actually
happening on restore state of a loop within a form. it appears that the
encoder now uses the type coercer. did it use that before? i thought
it used serialization as the default. anyway, when decoding the object,
it fails because it does find JDO->String. but, it does not have
String->JDO. now, i am just curious if that is a change between 5.0.1.8
and 5.1.0.5? if so, i have a lot of new coercers to write.
thanks so much for your advise!
tom
Howard Lewis Ship wrote:
Actually TypeCoercer includes an explain() method that is useful for
getting it to explain what set of coercions will be used.
On Wed, May 27, 2009 at 2:17 PM, Tom Zurkan
<tzur...@citizensportsinc.com> wrote:
more info.. this is apparently coming from a form submit... and it was
going...
String->Long->Id.... but, it is failing going from String (which is the id
(i.e. long)) to a JDO.
Thiago H. de Paula Figueiredo wrote:
Em Wed, 27 May 2009 17:34:15 -0300, Tom Zurkan
<tzur...@citizensportsinc.com> escreveu:
basically, a jdoid...
I can't recall any changes in the type coercing logic from 5.0.18 to
5.1.0.5.
You can try to figure out what's happening debugging the
TypeCoercer.coerce() method.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
