Hello Markus,
I am a little confused here. There was already a discussion about this behaviour and I believe the conclusion was to allow users to reference non-entity inheritance heirarchy members in their object model. TopLink would persist the state from the parent Entity object. (discussion thread had subject : "How to prevent stack overflow" and was in reference to gf bug 939).
Contrary to the comments in the bug there is nothing the specification that prevents this behaviour and the specification even covers this case in section 2.1.9.3
If we are not validating EntityManager and Query apis then that needs to be added but this bug is not a validation issue.
--Gordon
-----Original Message-----
From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of Markus Fuchs
Sent: Monday, September 25, 2006 8:08 PM
To: persistence_at_glassfish.dev.java.net
Subject: Fix for issue 1021
Hi TopLink team,
I'm trying to fix issue 1021: VALIDATION: Disallow persisting non-entity subclasses
Can I assume that there's a one-to-one relationship btw. entity classes
and descriptors? I.e. is the follow statement true:
Class is annotated as @Entity <=> There's a ClassDescriptor for that class.
Based on this assumption, the attached change throws a RuntimeException in
AbstractSession.getDescriptor(Class theClass), if the descriptor for a class
is not found. Adding it there will also change TopLink behavior for the
non-JPA case. The exception message must still be localized, of course.
Is there any reason, why TopLink returns the superclass descriptor, if no
descriptor for the a class can be found?
Another place to add this validation would be in EntityManagerImpl,
similar to how em.contains() is called for some JPA operations. But
that would not cover the cases were the operation is cascaded to an
instance, as the internal operation is called directly and not through
the EM interface.
I tested the validation by trying to persist a non-entity class or a
mapped superclass instance.
What do you think?
Thanks!
-- markus.