Is there any reason that I should not be able to define the same <component>, referenced by difference classes (and hence tables)?

My example is a simple telephone number (e.g. TelephoneNumber.java)... I have institutions with a telephone number and individuals with telephone numbers. I would like to define one component, yet have it logically part of both tables (i.e. institutions and individuals). The only way I can see to map this is to duplicate the <component> definition for both parent classes, even though the java class is the same.

the java class is the same but the mapped column aren't? so you need to declare it twice no?

A component is not a persistent entity in Hibernate nomenclature - ie. it doesn't have any identity on its own but exists only in relation with its parent.

I believe components should rather be seen as complex types that need several columns to be persisted.

In your example, you defined the <telephone> type which is used by two different persistent entities. Both declare properties of this type. Therefore, you have to specify for each persistent entity how you will map the properties (possibly with different column names).

I had thought of <component>'s slightly differently - expecting them to be reuseable within different classes. Because I am generating base java classes and the DDL from the hbm file, mapping of component columns into two tables is of no concern to me (it is done auto-magically by the tools). All I wanted to end up with is a single java class representing a telephone number (providing business logic for rating etc.), no matter how many entities used it. Currently (and it is a very small issue to me), I need to cut and paste the same component definition into every containing class.

I do recognise the issues of mapping different columns etc., in existing databases. I had not considered this before.

- Steven.