On 07/30/2012 05:16 AM, Steve Ebersole wrote:
> I have a concern about the API here. Specifically:
>
> public void generateSchema(PersistenceUnitInfo info, Map map)
> public void generateSchema(String persistenceUnitName, Map properties)
>
> The concern is that we will potentially be parsing the mapping
> information twice per deployment: once to comply with the "generate
> schema" call and then again to build the EMF. Unless providers stash
> away the "parsed" information in a static context, which is rather
> dubious IMHO. Yes, this works in the case when the caller only wants
> the schema generation to happen.
>
> [snip]
>
> I really do understand the desire to avoid API changes. But I also
> know that sometimes they do need to change. I think this is a good
> example of that. The initial bootstrapping API was never designed
> with this new feature in mind (how could it have been). In fact, in
> the EE case this 2-step process makes sense even without considering
> this new feature.
If bootstrap API changes are being considered, there was some talk over
at javaee-spec about other concerns with the JPA provider SPI that may
be worth looking into.
I quote Jason T. Greene on jsr342-experts:
> We really need a complete SPI to do integration correctly. Such an SPI
> would require:
>
> 1. A proper resource abstraction - No reliance on JarURLconnection and
> bad assumptions that a URL can be easily converted to java.io.File.
> 2. Annotation metadata abstraction - Containers have the ability to
> optimize annotation searching without using bloated/slow classloading
> and reflection.
> 3. Reflection metadata abstraction - Allow a container to actually
> cache and share Field/Method objects
> 4. Resource registration mechanisms - Interoping with CDI, EE
> Injection & Naming
> 5. Cross framework integration (mechanism to register interceptors or
> access other hooks in other plugable frameworks)
> 6. Full lifecycle - so that containers with support suspend/resume of
> deployment work, cleanup is properly done and so on.
> 7. Modularity, or at least some abstraction to ensure class loading is
> compatible with the container (no framework provided classloaders,
> reasonable usage of dependencies etc). Also no more assumptions that
> framework classes and deployment classes are on the same Classloader.
> 8. Contracts for Thread Local usage, thread creation/pooling.
>
> To use one example where integration goes wrong, look at the JPA
> contract. Since some providers use instrumentation, the SPI attempts
> to enable it, but without any of the previously listed items. The net
> effect is that a container has to execute classloading *twice* for
> every deployment that uses JPA. It has to load every class so it can
> analyze annotations, and then throw away the Classloader so that it
> can create a fresh one with instrumented versions of the classes.
--
Craig Ringer