Let us take an example from an application, which mimics mine.
Imagine the following context:
An application, which consists of multiple jars, is started. In each and every jars, there are entities, all valid. Four of those jars form an utility within the application: an editor (A), a skeleton for a feature of the editor (B), two implementations of the skeleton (B' and B''). Implementations can coexist and are presented as features in the editor.
Data model of A references classes from B, which in turn are of type of implementations B' and/or B''. When A saves its data model, instances of B'/B'' are saved too, just as any other entities needed by the implementations, but not part of B.
The ideal in a component based application is that there are the least relations within each other. Unfortunatly, this is a SE application, thus no mechanism except a PU xml declaring all classes can be used. Now, anyone wanting to implement B as a B''' module is blocked, as it will need to inform creator of A in order to see A add all B''' entities to the PU, add a dependency with a certain version of A, once he knows it. In the meantime, other implementors too have asked for addition, and life is a hell to anyone implementing B, to A's creator, or the user which constantly needs to update A when he changes any B implementor, for very obscure reasons.
Moreover, PU can not be updated at runtime. Programmer of A would have to be able to write the persistence.xml somewhere it can be used by JPA, but that can not be ensured, which makes any attemps to load a new B implementation module a direct way to a failure. User is forced to restart the application. Why? Because developers decided to use the official persistence mechanism and this mechanism is not adapted to evolving applications.
Declaring all jars within the application could have been a way, but unfortunatly, we can not ensure that the persistence will be able to see them. In netbeans, for example, due to modularity mechanisms, it would not. (contrarly to what i first thought)
All this is not fantasy, it is happening. We are all pushed to use platforms to develop applications, let it be netbeans/eclipse/jsr296/..., which all make pluggable runtime modularity an easy -if not transparent- feature. Less and less people will create their own framework for their applications. Big companies with teams for each modules will enter that problem. Even smaller ones will. Sooner or later, all will have to manage a common PU.
Now, let us take the current declaration mechanism. When a PU is loaded, jars are scanned/list of class is read and entities found are added to a list. When time to persist comes, class instance type are compared to the list and if not in the list, they get rejected and persistence fails. Why does the manager avoids testing for entity validity once before making everything fail is a mystery to me. What would it change anyway?
The only 'valid' reason (i mean feature-based reason) i see for not declaring classes in PU is to forbid them to be used in persistence. I do not understand the reason for anyone to forbid persistence of their data, but you might have an explanation, or the real reason if i missed the point.
A direct solution i see to solve my case is to step out of the spec and modify the sources of an EntityManager impl to make a last check/addition to list right before failing. I really do not want to get there.
Real solution i see is changing spec to make the declaration of classes optionnal and defer validation to runtime. Changing spec to make support of ORM.xml a mandatory feature for SE might even not be a valid solution in all cases, which i believe would be even less valid in current context.
As you can imagine, i do not see a bright future for JPA on SE. Please tell me i am wrong, not because i challenge you to, but because i hope to be wrong. JPA is a great thing, we need it.
[Message sent by forum member 'pepe' (pepe)]
http://forums.java.net/jive/thread.jspa?messageID=205088