Hi,

I have the mapping like this:

<class name="eg.ProductData" table="tbProductData">
<!-- PK -->
<id name="tbProductDataID" column="tbProductDataID" type="long">
<generator class="identity"/>
</id>
<!-- local attributes -->
<property name="subject2Warranty" column="subject2Warranty" type="boolean"/>
<property name="replacementPrice" column="replacementPrice" type="big_decimal"/>
</class>

and every time I try to make a simple select like "select productData from ProductData as productData" I get following error:

1 errors occurred while listing (and calling getPathNames).
exception setting property value with CGLIB setter of eg.ProductData.?

Weird thing is that if I remove property "subject2Warranty" everything works fine.

Second weird thing is that if I do select like this: "select productdata.subject2Warranty from ProductData as productdata" it works allright. (I mean I checked setter and getter for this attribute, they're working)

kind regards
reinis.

are you sure the subject2Warranty column is not nullable in the db, and primitive in the object model?

Exactlly,

I found failure and wanted to call off my post.

Still, exception was kinda weird... Gavin, is there chance, that some exceptions will get more user friendlly with the next releas(es)?

There are couple of such strange exceptions, that one with less experience would hardly find source of.

kind regards
reinis.

We enhance the exceptions (and their corresponding messages) when we discover a "bad" exception.

So, if you can pinpoint (even suggest) what you want improved - then please do ;)

Regarding setting property exceptoin - I think that if you disable cglib optimizer you will get an even better one.....I even think this stuff is improved in the current branch.

The trouble here is that CGLIB doesn't give us much to go by....



P.S. my record on accepting patches to exception messages quickly is Very Good :)

It would be possible to throw a special exception that could tell you which index failed. There would be a small runtime penalty (equivalent to the cost of "i++" * the number of properties), but maybe it is worth it?

Chris

yes, I suppose....

The i++ is unlikely to be relevant, since we already iterated the properties at least once in loading the object.

I'll put it on the TODO list...
Chris