1:49 p.m.
This helped me get further, except for test failures with
@DatasourceDefinition or ds*.xml. If we scan application classes for
@DatasourceDefinition, that will load the application classes before JPA
has registered its class transformer. We are better off not supporting
class transformers with (deployment oriented) datasource definitions (at
least not until we have a way to coordinate starting them in the same
phase as JPA).
Another way might be to change the persistence provider initialization
into two parts. If the provider implements an extension, instead of
calling PersistenceProvider.createContainerEntityManagerFactory(), we
would call
PersistenceProvider.prepareForCreationOfContainerEntityManagerFactory()
which registers the class transformer. In a later deployment phase, we
would call
PersistenceProvider.finishCreationOfContainerEntityManagerFactory() to
complete the creation of the EntityManagerFactory. We are allowed to
add extensions like this (I would also suggest the same change to JPA EG
for a future specification revision). This would require a separate SPI
extension jar (perhaps under the jboss-jpa project or a new jpa project).
On 07/02/2012 05:26 PM, Stuart Douglas wrote:
I think you will need to create a phase especially for this, that just runs the data
source install processors, and the JPA install processors. This will however negatively
affect deployment performance, as deployment will then be blocked on JPA starting. This is
the only way I can see to do this properly.
You would need to register a NEXT_PHASE_DEPS entry on the JPA service, although this
would only be needed if the JPA impl actually registered a class transformer.
Stuart
On 03/07/2012, at 1:51 AM, Scott Marlow wrote:
> I need to start the JPA persistence unit service
> (javax.persistence.EntityManagerFactory), before the deployments classes
> have been read. Currently, POST_MODULE_INJECTION_ANNOTATION and other
> DUPs can read application classes before the persistence unit service is
> started.
>
> I tried changing the JPA related DUPs to start as early as possible but
> that doesn't help since the JPA persistence unit service doesn't
> actually start until the INSTALL phase (well after the
> POST_MODULE_INJECTION_ANNOTATION has already read application classes).
>
> If we were to create the javax.persistence.EntityManagerFactory during
> an early PHASE (probably in a "first time access" phase after the module
> is defined), we would also need the datasource to be available early (to
> handle certain cases that require it (e.g. creating database tables or
> checking JDBC DatabaseMetaData.)
>
> Is there a way to get early (equivalent to PHASE.POST_MODULE time)
> access to a datasource?
> https://github.com/scottmarlow/jboss-as/tree/AS7-4996_class_transformer_p...
> contains some hacks that I started and the current JPA datasource access
> code is at
>
https://github.com/scottmarlow/jboss-as/blob/AS7-4996_class_transformer_p...
>
> AS7-4996 is the jira for this change and contains an IRC transcript from
> a conversation last fall about getting JPA class transformers to work.
> The changes that we made last fall, worked for the simple test case but
> not all applications.
>
> Scott
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev