I think of it this way: your classes can implement any number of interfaces ... how is hibernatedoclet to know which one is the "class" for the hbm.xml file? hibernatedoclet would have to parse through all of the implemented interfaces and take a best guess as to which one it is ... what if more than one declares itself as a @hibernate.class ?
Your domain objects should implement java.io.Serializable as well
I took the hibernate advice and declared a Persitent ancestor for all my domain objects, but I did not declare it a @hibernate.class
Code:
package com.domain;
public class Persistent implements java.io.Serializable {
protected Long id;
/**
* @hibernate.id
*/
public void setId(Long id) {
this.id = id;
}
public Long getId() {
return this.id;
}
This allows me to control the kinds of Ids (Long, UUID, whatever) in one class. Notice the missing @hibernate.class!
For example's sake, a Person, who has a User and Employee child.
There is no actual Person, it's an abstract Ancestor. I could make it PersonImpl implements Person.
Code:
package com.domain;
/**
* @hibernate.class table="Person"
* @hibernate.discriminator
* column="type"
* type="string"
*/
public abstract class PersonImpl extends Persistent implements Person {
...
}
-----
/**
* @hibernate.subclass
*/
public class UserImpl extends PersonImpl implements Person, User {
...
}
-------
/**
* @hibernate.subclass
*/
public class EmployeeImpl extends PersonImpl implements Person, Employee {
...
}
It's sort of gross because it's an example. You can have interface Person, you can
Code:
package com.domain;
public interface Person {
getFirstName(); .... getEyeColor(); ... etc
...
}
----
package com.domain;
public interface User extends Person {
getLoginId(); ... getPassword(); ... etc.
}
----
package com.domain;
public interface Employee extends Person {
getEmployeeCode(); .... getJerkBossName(); .... etc
}
etc. Hibernatedoclet can deal with all of that.
I typed a lot of stuff here, hopefully nothing wrong. Debugging code is a lot easier than debugging text ;-)