[jboss-as7-dev] Setting JPA ClassTranformer and how can a service be started before any DUPs start scanning deployment classes?
Scott Marlow
smarlow at redhat.com
Sun Jul 8 09:46:14 EDT 2012
On 07/05/2012 06:23 PM, Stuart Douglas wrote:
>
> On 06/07/2012, at 4:49 AM, Scott Marlow wrote:
>
>> 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).
I was able to pass the ds*.xml test. For the @DataSourceDefinition
test, I'm not sure that we should move the handling processors to run in
an earlier phase.
DataSourceDefinitionAnnotationParser already runs early enough (PARSE
phase) but doesn't become active until the
EEModuleClassDescription.getBindingConfigurations() are processed later
(I think by ComponentInstallProcessor during the INSTALL phase).
I could avoid using class transformation when @DataSourceDefinitions are
used or move ComponentInstallProcessor to run in an earlier phase (in
addition to running during INSTALL time). Running
ComponentInstallProcessor earlier might need to bring other processors
to an earlier phase also.
Might be better to not mix class transformation and
@DataSourceDefinitions at this time.
>>
>
> We use Jandex for annotation scanning. No class loading is required.
Good point. So, most annotation scanning with jandex is fine. For JPA,
we can use the temp classloader (since we are accessing the app
classloader also currently in Hibernate integration code). I think
there are other processors that do use the APP classloader but my
current patch has JPA running before them.
>
> Stuart
>
>> 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_part2
>>>> 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_part2/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L318
>>>>
>>>> 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>>
>
More information about the jboss-as7-dev
mailing list