In our schema we have the following structure:
Authorization
optional toMany to AuthorizationDef
All of our entity classes are generated using a templating system and actually realized with a pair of classes. We auto-generate an XXXGen class which is extended by the real XXX class, so for example we have AuthorizationGen extended by Authorization. The Gen class is annotated with @MappedSuperclass, the User class is annotated with @Entity.
In the case of AuthorizationDef there are again AuthorizationDefGen, annotated as @MappedSuperclass and AuthorizationDef, which is in this case is also annotated with @MappedSuperclass since it an abstract super class for 3 other classes, ProductAuthDef, GroupAuthDef and FeatureAuthDef which are all annotated as @Entity. All of these use the same XXXGen/XXX pairing with the (for example) ProductAuthDefGen annotated as @MappedSuperclass and the ProductAuthDef class annotated as @Entity.
This organization works fine in our applications. I was trying a simple test using the skeleton created by the jpacontainer maven archetype and restricting the processing to just the User entity and when the AutoCrudViews methods instances a new BasicCrudView passing the Authorization class as the entity the invocation of JPAContainerFactory.make(EntityClass, persistenceUnit) throws a fault:
java.lang.IllegalArgumentException: The class …jpa.main.AuthorizationDef is nether an entity nor embeddable
That is correct, it is not an entity nor is it annotated as @Embeddable, it is a @MappedSuperclass.
Is this expected behavior of the JPAContainer and if so how can I work with our admittedly slightly complex hierarchies of entities and super classes ?
If more detail is required, please let me know.
Thanks,
Joel
