Is it possible to extend the (often auto-generated) persistence classes defined in the hbm.xml file to add custom business logic? What is the recommended technique for doing this?

It's pretty much as you just described. You'll want the hand written classes to extend the generated ones, otherwise you get problems when it comes time to regenerate. Typically, you do stuff like this ...

public String getAddressFormatted(){
return this.address + ", " + this.state.getCode() ;
}

You might get into trouble if you have the handwritten class extend the generated class because what hibernate hands you after an operation is the generated object and not the handwritten object.
You could do it the other way (Have the generated one extend the handwritten one) by using the meta attribute in ur hbm.xml
refer to
http://www.hibernate.org/hib_docs/refer ... guide-s2-2
for more information on extending from a handwritten class.

"FROM ChildOfGenerated" will return a list of all "Generated"s .

Hmmm... I'm not too thrilled about the idea of generated classes subclassing from my business objects. For one thing it seems like you'd run into circular dependency classloader issues, no? (Assuming the generated classes & business object classes live in different jars.)

For now I'm just "wrapping" my generated classes with my business classes, basically using aggregation rather than inheritance. This is less than ideal though because often I'd like to access methods on the generated classes directly.

This is such a common problem that I'm sure somebody has come up with a clever solution, but so far I haven't heard it.

living in different jars is not a problem and there is no cycles in the code.

just use the generated-class meta attribute to control it.

It must be better to implement business logic outside data model:

public String getAddressFormatted(MyData data){
return data.address + ", " + data.state.getCode() ;
}

This kind of business logic needs some context like Locale,User, some not persistent data or additional data access method calls.

Locale usually applies to the label of a property, "address" (english) vs. "adresse" (deutsche) . The value of the property, "123 A St. Anchorage Alaska, USA", is going to appear the same for Americans as it does for Germans.

baliukas - see the toString() methods for classes in org.hibernate.auction for my thoughts ... this saves a JSP author a lot of JSTL/EL lines of code.

Nobody here is saying it is OK to put methods like isQualifiedForLoan() or givePromotionTo() inside of Person. And if that's what the original poster had in mind, then yes, listen to baliukas.

This issue is typical in my practice, I use method overloading and request scope instance to solve it:



Ceparation of concerns is usefull for parsing or data access too.