Yep a lot of this is from the same discussion. Like I said, I did not
want to steal Scott's thunder on this point. Scott is returning from
vacation tomorrow, so I am sure he will respond on this soon.
Unfortunately I leave for vacation tonight so I just wanted to raise my
concern with regard to this proposal specifically.
On Sun 29 Jul 2012 06:57:55 PM CDT, Craig Ringer wrote:
> 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