Hi,
does a mapping like the following make sense?
In a class RequestAnswer I want a collection of composite elements (RequestAnswerElements). Those are stored in another table, a join is done one the primary key of RequestAnswer.
From the DTD perspective this kind of mapping is allowed. Hibernate loads it perfectly. Is there a proposed way to handle such objects in Java (any experience with such a mapping?) How does Hibernate knows to what parent object a composite element belongs? I guess I miss something in the picture, please bring some light into the dark...

Hibernate will create a record in the request_ans_elmt table for each object you add to the set, irrespective of the element type (primitive or composite). Each one of those records will have a foreign key back to the parent record, in addition to the columns specified in the element being stored. The order that you specify the columns in the <key> element in the <set> must match the order of the columns specified in the parent entity's key.

This should work OK for you, AFAIK. You may need to drop the inverse=true, since this isn't really at the inverse side of an association. Also, try cascade=save-update if you plan to delete items from the requestAnswerElements set.

It is an awkward setup, but it will work. Remember to have RequestAnswerElement implement equals and hashCode if you want to add and remove from the set.

Thanks for the reply! it helped to find the error.
The inverse=true was the problem, it does work perfectly without it.
But i think there is a little error in your post: For cascading delete cascade=all or cascade=delete is necessary.
Thanks anyway!

Sorry.... use save-update in a situation where you have a many-to-many as the elements of a collection. You are correct about cascade for one-to-many in this case.