In this class there is a setter called setDescription. It causes a
problem because it has too much logic in it.
I think it is a good is idea to avoid logic in getter/setters.
The setter what I am talking about isn't even a real setter, though one
would expect from the name. it is a normal method, called only just once
from the normal constructor.
So it would be better to change its name and reserve typical
setter-names for setters. I renamed it to set_Descrition, this because I
needed a setter without logic in it. I explain why I need it.
Hibernate3 does not want too much logic insetters, because, f.e., in
this case, the logic demands other properties being loaded in a special
order.
In this case setDescription comes to a point in languagesAvailable()
where originalLanguage is expected to be not null.
This is normally guaranteed, because AuthoredResource is created by
using the constructor which checks on originalLanguage not being null.
This is not the case now.
Hibernate uses the POJO constructor, which does no checks at all, and
after that it sets the properties using the setters. There is no special
order in setting the properties.
Also, another reason to follow my suggestion could be: I always advice
for traditionally programming, traditional naming schemes, traditional
places to put logic, etc. It makes code better to understand, and
self-explanatory. It would have saved me a day when this was done in
this case, I spent about one day to find out what is wrong, until I
discover that Hibernate expects a setter to be what the name indicates,
a plain simple setter, good for the POJO part of the code.
Thanks for reading
Bert