I have this tables structure (i can't change it):

Apl
---
apl_id pk
name
usr

rol
---
apl_id fk,pk
rol_id pk

entity
------
apl_id fk,pk
en_id pk

rol_entity
----------
apl_id fk,pk
en_id fk,pk
rol_id fk,pk

I defined this mappings :

<class name="xxx.Apl" table="APL">
<id name="id" type="integer">
<column name="APL_ID"/>
...
</id>
...
</class>

<class name="xxx.Rol" table="ROL">
<composite-id name="id">
<key-property name="rolid">
<column name="ROL_ID"/>
</key-property>
<key-many-to-one name="apl">
<column name="APL_ID"/>
</key-many-to-one>
</composite-id>
<set name="entities"
table="ROL_ENTITY"
lazy="true"
cascade="all-delete-orphan">
<key>
<column name="ROL_ID"/>
<column name="APL_ID"/>
</key>
<many-to-many class="xxx.Entity">
<column name="APL_ID"/>
<column name="EN_ID"/>
</many-to-many>
</set>
...
</class>
<class name="xxx.Entity" table="ENTITY">
<composite-id name="id">
<key-property name="enid">
<column name="EN_ID"/>
</key-property>
<key-many-to-one name="aplid">
<column name="APL_ID"/>
</key-many-to-one>
</composite-id>
...
</class>

When i build the session factory, i obtain this error :

INFO: building session factory
net.sf.hibernate.MappingException: Repeated column in mapping for collection: ar.com.arcor.esecurity.beans.Entidad.roles column: APL_ID
at net.sf.hibernate.collection.AbstractCollectionPersister.checkColumnDuplication(AbstractCollectionPersister.java:666)
at net.sf.hibernate.collection.AbstractCollectionPersister.<init>(AbstractCollectionPersister.java:163)
at net.sf.hibernate.collection.BasicCollectionPersister.<init>(BasicCollectionPersister.java:35)
...

APL_ID is in both a key-many-to-one and a many-to-many.

yes, this is ok, because APL_ID is key in the table ROL, and APL_ID is a foreign key to Application . And the relation between ENTITY and ROL is with APL_ID and ENT_ID (is a many-to-many relation) ...

OK for the data model, but not for hibernate: http://forum.hibernate.org/viewtopic.php?t=925446

so ? any idea ?

Well, I haven't posted this to JIRA as a feature request because of Gavin's initial response. However, you're the third poster besides myself who has travelled close to this idea, so I think I'll submit it.

The trouble is really that this is not -at-all- easy to implement and would require complete redesign of Type hierarchy.

OK. :)

3.0? :P