3:50 p.m.
Hardy,
It seems that the ValidatorFactoryBean#createConstraintValidatorFactory
is getting called too late for some reason.
http://pastebin.com/WrdD91Hr shows the call stack for
ValidatorFactoryBean#create(CreationalContext<ValidatorFactory> ctx)
which calls createConstraintValidatorFactory, which seems too late
(CdiValidatorFactoryService is shutting down).
To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
yourself), steps are:
1. Build latest ORM master branch (./gradlew clean publishToMavenLocal).
2. Build https://github.com/scottmarlow/wildfly/tree/hibernate5_july2
branch (./build.sh clean install -DskipTests=true).
3. change into wildfly/testsuite/integration/basic folder and run "mvn
clean install -Dtest=*BeanValidationCdiIntegrationTestCase*
"
To run WildFly with the debugger, cd into
wildfly/dist/target/wildfly-10.0.0.Alpha5-SNAPSHOT/bin and edit the
standalone.conf file. Uncomment the "remote socket debugger" line #57
to look something like the following:
JAVA_OPTS="$JAVA_OPTS
-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y"
Then start WildFly, via ./standalone.sh and open port 8787 with your
debugger.
Then run the test (step #3 above) and your debugger breakpoint should be
hit.
Scott
5:42 a.m.
On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
Hardy,
It seems that the ValidatorFactoryBean#createConstraintValidatorFactory is
getting called too late for some reason. http://pastebin.com/WrdD91Hr shows
the call stack for
ValidatorFactoryBean#create(CreationalContext<ValidatorFactory> ctx) which
calls createConstraintValidatorFactory, which seems too late
(CdiValidatorFactoryService is shutting down).
Did you not change some of the integration code in order to upgrade to ORM 5
within Wildfly? It is not just a version upgrade, right?
The reason I am asking is that afaik we jump through quite some hoops regarding
the Bean Validation integration to ensure that the JNDI bound Validator(Factory)
is CDI enabled and identical to the one which can be retrieved via CDI. This
is the whole LazyValidatorFactory stuff. I am not so familiar with this code,
but I am wondering whether your changes for the ORM 5 integration interfere with
the Bean Valiadtion bootstrapping. What needed to change for the ORM 5 integration?
I know that you and Sanne discussed the ability to bootstrap the PersistenceProvider
using the API as defined by JPA. Did you go in this direction?
To recreate the WildFly ORM 5 issue on WildFly (if you want to see
it
yourself), steps are:
Ok, I'll take a look at your branch.
Is this test failure the last hurdle to integrate ORM5 into Wildfly 10?
--Hardy
6:15 a.m.
On 8 July 2015 at 11:42, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
> Hardy,
>
> It seems that the ValidatorFactoryBean#createConstraintValidatorFactory is
> getting called too late for some reason. http://pastebin.com/WrdD91Hr shows
> the call stack for
> ValidatorFactoryBean#create(CreationalContext<ValidatorFactory> ctx) which
> calls createConstraintValidatorFactory, which seems too late
> (CdiValidatorFactoryService is shutting down).
Did you not change some of the integration code in order to upgrade to ORM 5
within Wildfly? It is not just a version upgrade, right?
The reason I am asking is that afaik we jump through quite some hoops regarding
the Bean Validation integration to ensure that the JNDI bound Validator(Factory)
is CDI enabled and identical to the one which can be retrieved via CDI. This
is the whole LazyValidatorFactory stuff. I am not so familiar with this code,
but I am wondering whether your changes for the ORM 5 integration interfere with
the Bean Valiadtion bootstrapping. What needed to change for the ORM 5 integration?
I know that you and Sanne discussed the ability to bootstrap the PersistenceProvider
using the API as defined by JPA. Did you go in this direction?
> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
> yourself), steps are:
Ok, I'll take a look at your branch.
Is this test failure the last hurdle to integrate ORM5 into Wildfly 10?
I have the same question, I'm confused as yesterday I heard we were
down to zero failures.
Did something else change, or are tests being run in incremental
iterations? Just wondering how confident we are about not seeing more
issues being reported tomorrow.
Sanne
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:29 a.m.
On 07/08/2015 07:15 AM, Sanne Grinovero wrote:
On 8 July 2015 at 11:42, Hardy Ferentschik
<hardy(a)hibernate.org> wrote:
> On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>> Hardy,
>>
>> It seems that the ValidatorFactoryBean#createConstraintValidatorFactory is
>> getting called too late for some reason. http://pastebin.com/WrdD91Hr shows
>> the call stack for
>> ValidatorFactoryBean#create(CreationalContext<ValidatorFactory> ctx) which
>> calls createConstraintValidatorFactory, which seems too late
>> (CdiValidatorFactoryService is shutting down).
>
> Did you not change some of the integration code in order to upgrade to ORM 5
> within Wildfly? It is not just a version upgrade, right?
>
> The reason I am asking is that afaik we jump through quite some hoops regarding
> the Bean Validation integration to ensure that the JNDI bound Validator(Factory)
> is CDI enabled and identical to the one which can be retrieved via CDI. This
> is the whole LazyValidatorFactory stuff. I am not so familiar with this code,
> but I am wondering whether your changes for the ORM 5 integration interfere with
> the Bean Valiadtion bootstrapping. What needed to change for the ORM 5 integration?
> I know that you and Sanne discussed the ability to bootstrap the PersistenceProvider
> using the API as defined by JPA. Did you go in this direction?
The ORM integration code does not interact with the Bean Validation
bootstrapping. That is done the same (by the JPA
container/deployer/subsystem) for any persistence provider that we
integrate with.
>
>> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
>> yourself), steps are:
>
> Ok, I'll take a look at your branch.
>
> Is this test failure the last hurdle to integrate ORM5 into Wildfly 10?
Yes.
I have the same question, I'm confused as yesterday I heard we were
down to zero failures.
There were certain tests that I was not running locally. I found that
the following command runs all of the WildFly tests that I really wanted
to run:
./integration-tests.sh -Dts.basic -Dmaven.test.failure.ignore=true
-DfailIfNoTests=false
I also ran the WildFly clustering tests which replicate an extended
persistence context. No failures with those.
Did something else change, or are tests being run in incremental
iterations? Just wondering how confident we are about not seeing more
issues being reported tomorrow.
I am planning on running the EE TCK tests with ORM 5 CR2 after it is
merged. There may be EE TCK test failures with ORM 5 that will need to
be addressed this summer (before end of August).
Sanne
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:16 a.m.
On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
To recreate the WildFly ORM 5 issue on WildFly (if you want to see
it
yourself), steps are:
For the record, I see the same test failures locally. I have not looked any
further regarding their cause.
@Scott, on a high level what are the changes which were required to integrate ORM 5.
Anything which you in your opinion interfere with the Bean Validation integration?
--Hardy
7:32 a.m.
On 07/08/2015 08:16 AM, Hardy Ferentschik wrote:
On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
> yourself), steps are:
For the record, I see the same test failures locally. I have not looked any
further regarding their cause.
@Scott, on a high level what are the changes which were required to integrate ORM 5.
Anything which you in your opinion interfere with the Bean Validation integration?
The same test works with the WildFly master branch, which is using ORM
4.3.x. The Bean Validation integration code is unchanged in my WildFly
branch, as is the Bean Validator. The only thing different, is the ORM
5 integration code and the ORM 5 persistence provider.
--Hardy
7:33 a.m.
Scott, could you update the Gist with the complete stack trace you got? It
seems to only contains parts of it.
2015-07-08 14:32 GMT+02:00 Scott Marlow <smarlow(a)redhat.com>:
On 07/08/2015 08:16 AM, Hardy Ferentschik wrote:
> On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
>> yourself), steps are:
>
> For the record, I see the same test failures locally. I have not looked
any
> further regarding their cause.
>
> @Scott, on a high level what are the changes which were required to
integrate ORM 5.
> Anything which you in your opinion interfere with the Bean Validation
integration?
The same test works with the WildFly master branch, which is using ORM
4.3.x. The Bean Validation integration code is unchanged in my WildFly
branch, as is the Bean Validator. The only thing different, is the ORM
5 integration code and the ORM 5 persistence provider.
>
> --Hardy
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:58 a.m.
Here are a few different call stacks:
1. http://pastebin.com/ZiZL5vEh shows the call stack when running
against the WildFly master branch (with ORM 4.3.x) and the @Inject works
(the test
org.jboss.as.test.integration.jpa.beanvalidation.cdi.CustomMinValidator.setMinimumValueProvider()
method is being called in the call stack).
2. http://pastebin.com/ApYVvUHL shows the NPE that I get on the
https://github.com/scottmarlow/wildfly/tree/hibernate5_july2 branch to
run the BeanValidationCdiIntegrationTestCase. The NPE occurs because
the
org.jboss.as.test.integration.jpa.beanvalidation.cdi.CustomMinValidator.setMinimumValueProvider()
is not called.
On 07/08/2015 08:33 AM, Gunnar Morling wrote:
Scott, could you update the Gist with the complete stack trace you
got?
It seems to only contains parts of it.
I captured the call stack http://pastebin.com/WrdD91Hr right before
stepping into the call to private method
org.hibernate.validator.internal.cdi.ValidatorFactoryBean#createConstraintValidatorFactory()
which is called from
ValidatorFactoryBean.create(CreationalContext<ValidatorFactory> ctx).
2015-07-08 14:32 GMT+02:00 Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>>:
On 07/08/2015 08:16 AM, Hardy Ferentschik wrote:
> On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>> To recreate the WildFly ORM 5 issue on WildFly (if you want to
see it
>> yourself), steps are:
>
> For the record, I see the same test failures locally. I have not
looked any
> further regarding their cause.
>
> @Scott, on a high level what are the changes which were required
to integrate ORM 5.
> Anything which you in your opinion interfere with the Bean
Validation integration?
The same test works with the WildFly master branch, which is using ORM
4.3.x. The Bean Validation integration code is unchanged in my WildFly
branch, as is the Bean Validator. The only thing different, is the ORM
5 integration code and the ORM 5 persistence provider.
>
> --Hardy
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:02 a.m.
Hi,
The same test works with the WildFly master branch, which is using
ORM
4.3.x. The Bean Validation integration code is unchanged in my WildFly
branch, as is the Bean Validator. The only thing different, is the ORM 5
integration code and the ORM 5 persistence provider.
Just fishing here, but "integration code and the ORM 5 persistence provider"
might
indicate a problem in the persistence bootstrapping.
Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
validation from the properties passed via the Persistence bootstrap. The property name
is javax.persistence.validation.factory. If there is no instance passed ORM will
bootstrap
a default factory using Validation.buildDefaultValidatorFactory(). The latter would
of course not be CDI enabled. This would explain why validation occurs, but not CDI
injection.
I would for sure put a breakpoint in there as well (and some trace/debug log would be
probably
nice to have as well to easily tell whether a factory is passed or a default one is
generated.
--Hardy
8:11 a.m.
On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
Hi,
> The same test works with the WildFly master branch, which is using ORM
> 4.3.x. The Bean Validation integration code is unchanged in my WildFly
> branch, as is the Bean Validator. The only thing different, is the ORM 5
> integration code and the ORM 5 persistence provider.
Just fishing here, but "integration code and the ORM 5 persistence provider"
might
indicate a problem in the persistence bootstrapping.
Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
validation from the properties passed via the Persistence bootstrap. The property name
is javax.persistence.validation.factory. If there is no instance passed ORM will
bootstrap
a default factory using Validation.buildDefaultValidatorFactory(). The latter would
of course not be CDI enabled. This would explain why validation occurs, but not CDI
injection.
I would for sure put a breakpoint in there as well (and some trace/debug log would be
probably
nice to have as well to easily tell whether a factory is passed or a default one is
generated.
Good suggestion, the validation factory does get passed in during the
second bootstrap phase. If we looked for it during the first JPA
bootstrap phase, we would not see it in Hibernate ORM 5. We should
check that.
--Hardy
8:32 a.m.
On Wed, Jul 08, 2015 at 09:11:55AM -0400, Scott Marlow wrote:
>Just fishing here, but "integration code and the ORM 5
persistence provider" might
>indicate a problem in the persistence bootstrapping.
>Have a look at
org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
>Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle
based
>validation from the properties passed via the Persistence bootstrap. The property
name
>is javax.persistence.validation.factory. If there is no instance passed ORM will
bootstrap
>a default factory using Validation.buildDefaultValidatorFactory(). The latter would
>of course not be CDI enabled. This would explain why validation occurs, but not CDI
injection.
>I would for sure put a breakpoint in there as well (and some trace/debug log would be
probably
>nice to have as well to easily tell whether a factory is passed or a default one is
generated.
Good suggestion, the validation factory does get passed in during the second
bootstrap phase. If we looked for it during the first JPA bootstrap phase,
we would not see it in Hibernate ORM 5. We should check that
+1
I am also confused about your debugging instructions. You are suggesting to use the
Wildfly instance
under dist/target. When I do that and have this instance running when while executing
'mvn install -Dtest=*BeanValidationCdiIntegrationTestCase*' the tests actually
pass. Apparently
in this case Arquillian is configured to run against the running Wildfly instance.
If I, however, run the tests without having a running Wildfly instance the tests keep
failing. Seems
to me that a different Wildfly instance is used. I guess I don't fully understand the
test setup
in the widlfly repo and this integration tests in particular, but obviously I want to
debug the
right thing.
--Hardy
8:41 a.m.
On 07/08/2015 09:32 AM, Hardy Ferentschik wrote:
On Wed, Jul 08, 2015 at 09:11:55AM -0400, Scott Marlow wrote:
>> Just fishing here, but "integration code and the ORM 5 persistence
provider" might
>> indicate a problem in the persistence bootstrapping.
>> Have a look at
org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
>> Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle
based
>> validation from the properties passed via the Persistence bootstrap. The property
name
>> is javax.persistence.validation.factory. If there is no instance passed ORM will
bootstrap
>> a default factory using Validation.buildDefaultValidatorFactory(). The latter
would
>> of course not be CDI enabled. This would explain why validation occurs, but not
CDI injection.
>> I would for sure put a breakpoint in there as well (and some trace/debug log
would be probably
>> nice to have as well to easily tell whether a factory is passed or a default one
is generated.
>
> Good suggestion, the validation factory does get passed in during the second
> bootstrap phase. If we looked for it during the first JPA bootstrap phase,
> we would not see it in Hibernate ORM 5. We should check that
+1
I am also confused about your debugging instructions. You are suggesting to use the
Wildfly instance
under dist/target. When I do that and have this instance running when while executing
'mvn install -Dtest=*BeanValidationCdiIntegrationTestCase*' the tests actually
pass. Apparently
in this case Arquillian is configured to run against the running Wildfly instance.
If I, however, run the tests without having a running Wildfly instance the tests keep
failing. Seems
to me that a different Wildfly instance is used. I guess I don't fully understand the
test setup
in the widlfly repo and this integration tests in particular, but obviously I want to
debug the
right thing.
I don't know why that is happening. It sounds like we have enough
information from your previous suggestion though and my last email.
I'll follow up with you on IRC next. :)
--Hardy
8:37 a.m.
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl#populate(SessionFactoryBuilder
sfBuilder, StandardServiceRegistry ssr) does pass the correct VF to
sfBuilder.applyValidatorFactory (using the ValidatorFactory passed to
the EntityManagerFactoryBuilderImpl.withValidatorFactory). However, a
bit later when we reach
org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory,
we aren't using the SessionFactoryBuilder or
EntityManagerFactoryBuilderImpl to obtain the VF. Instead, we are
looking in the persistence unit properties. This sounds wrong to me.
On 07/08/2015 09:11 AM, Scott Marlow wrote:
On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
> Hi,
>
>> The same test works with the WildFly master branch, which is using ORM
>> 4.3.x. The Bean Validation integration code is unchanged in my WildFly
>> branch, as is the Bean Validator. The only thing different, is the ORM 5
>> integration code and the ORM 5 persistence provider.
>
> Just fishing here, but "integration code and the ORM 5 persistence
provider" might
> indicate a problem in the persistence bootstrapping.
> Have a look at
org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
> Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle
based
> validation from the properties passed via the Persistence bootstrap. The property
name
> is javax.persistence.validation.factory. If there is no instance passed ORM will
bootstrap
> a default factory using Validation.buildDefaultValidatorFactory(). The latter would
> of course not be CDI enabled. This would explain why validation occurs, but not CDI
injection.
> I would for sure put a breakpoint in there as well (and some trace/debug log would be
probably
> nice to have as well to easily tell whether a factory is passed or a default one is
generated.
Good suggestion, the validation factory does get passed in during the
second bootstrap phase. If we looked for it during the first JPA
bootstrap phase, we would not see it in Hibernate ORM 5. We should
check that.
>
> --Hardy
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:28 a.m.
On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
Hi,
> The same test works with the WildFly master branch, which is using ORM
> 4.3.x. The Bean Validation integration code is unchanged in my WildFly
> branch, as is the Bean Validator. The only thing different, is the ORM 5
> integration code and the ORM 5 persistence provider.
Just fishing here, but "integration code and the ORM 5 persistence provider"
might
indicate a problem in the persistence bootstrapping.
Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
validation from the properties passed via the Persistence bootstrap. The property name
is javax.persistence.validation.factory. If there is no instance passed ORM will
bootstrap
a default factory using Validation.buildDefaultValidatorFactory(). The latter would
of course not be CDI enabled. This would explain why validation occurs, but not CDI
injection.
I would for sure put a breakpoint in there as well (and some trace/debug log would be
probably
nice to have as well to easily tell whether a factory is passed or a default one is
generated.
http://pastebin.com/4X0h1VPA is the call stack in. We are in the second
bootstrap phase, which is good. The validator factory is passed into
the integration properties but we are only checking the persistence unit
properties in ORM 5. Since we are not looking in the integration
properties for the "javax.persistence.validation.factory", we are not
seeing it. So your are right on the money, great suggestion.
I'll check next why the
EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is
also ignored.
--Hardy
8:53 a.m.
Hi,
http://pastebin.com/4X0h1VPA is the call stack in. We are in the
second
bootstrap phase, which is good. The validator factory is passed into the
integration properties but we are only checking the persistence unit
properties in ORM 5. Since we are not looking in the integration properties
for the "javax.persistence.validation.factory", we are not seeing it. So
your are right on the money, great suggestion.
I am not sure how this all maps to the different phases and properties types, but
the JPA specs says in 3.6.2 Providing the ValidatorFactory -
"In Java EE environments, a ValidatorFactory instance is made available by the Java
EE container.
The container is responsible for passing this validator factory to the persistence
provider via the
map that is passed as an argument to the createContainerEntityManagerFactory call. The
map key used by the container must be the standard property name
javax.persistence.validation.
factory"
I am not sure where the properties of this map end up during the current bootstrapping
process,
but where ever that is, that's where we have to look in TypeSafeActivator (and
potentially ask us
the question whether it is the right place).
I'll check next why the
EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is also
ignored.
Sure. Seems we have a solid lead now.
--Hardy
9:41 a.m.
Steve,
I created HHH-9905 for this, which I was able to workaround with a quick
hack (set the missing "javax.persistence.validation.factory" property in
the ConfigurationService). I was able to pass the WildFly test with the
workaround.
Steve, is that the right fix? I assigned the jira to you. Can we fix
this for the CR2 build? If we use the hack workaround, it will probably
be coded a little different (the hack worked in the debugger but there
is probably a more elegant way to code it).
Scott
On 07/08/2015 09:53 AM, Hardy Ferentschik wrote:
Hi,
> http://pastebin.com/4X0h1VPA is the call stack in. We are in the second
> bootstrap phase, which is good. The validator factory is passed into the
> integration properties but we are only checking the persistence unit
> properties in ORM 5. Since we are not looking in the integration properties
> for the "javax.persistence.validation.factory", we are not seeing it. So
> your are right on the money, great suggestion.
I am not sure how this all maps to the different phases and properties types, but
the JPA specs says in 3.6.2 Providing the ValidatorFactory -
"In Java EE environments, a ValidatorFactory instance is made available by the Java
EE container.
The container is responsible for passing this validator factory to the persistence
provider via the
map that is passed as an argument to the createContainerEntityManagerFactory call. The
map key used by the container must be the standard property name
javax.persistence.validation.
factory"
I am not sure where the properties of this map end up during the current bootstrapping
process,
but where ever that is, that's where we have to look in TypeSafeActivator (and
potentially ask us
the question whether it is the right place).
> I'll check next why the
> EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is also
> ignored.
Sure. Seems we have a solid lead now.
--Hardy
9:59 a.m.
Looks like I missed a small piece there. The intention was to have
TypeSafeActivator
pick up SessionFactoryOptions#getValidatorFactoryReference. Scott, can you
make sure SessionFactoryOptions#getValidatorFactoryReference contains the
proper ValidatorFactory reference when we get into TypeSafeActivator in WF?
On Wed, Jul 8, 2015 at 9:41 AM Scott Marlow <smarlow(a)redhat.com> wrote:
Steve,
I created HHH-9905 for this, which I was able to workaround with a quick
hack (set the missing "javax.persistence.validation.factory" property in
the ConfigurationService). I was able to pass the WildFly test with the
workaround.
Steve, is that the right fix? I assigned the jira to you. Can we fix
this for the CR2 build? If we use the hack workaround, it will probably
be coded a little different (the hack worked in the debugger but there
is probably a more elegant way to code it).
Scott
On 07/08/2015 09:53 AM, Hardy Ferentschik wrote:
> Hi,
>
>> http://pastebin.com/4X0h1VPA is the call stack in. We are in the
second
>> bootstrap phase, which is good. The validator factory is passed into
the
>> integration properties but we are only checking the persistence unit
>> properties in ORM 5. Since we are not looking in the integration
properties
>> for the "javax.persistence.validation.factory", we are not seeing it.
So
>> your are right on the money, great suggestion.
>
> I am not sure how this all maps to the different phases and properties
types, but
> the JPA specs says in 3.6.2 Providing the ValidatorFactory -
>
> "In Java EE environments, a ValidatorFactory instance is made available
by the Java EE container.
> The container is responsible for passing this validator factory to the
persistence provider via the
> map that is passed as an argument to the
createContainerEntityManagerFactory call. The
> map key used by the container must be the standard property name
javax.persistence.validation.
> factory"
>
> I am not sure where the properties of this map end up during the current
bootstrapping process,
> but where ever that is, that's where we have to look in
TypeSafeActivator (and potentially ask us
> the question whether it is the right place).
>
>> I'll check next why the
>> EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is
also
>> ignored.
>
> Sure. Seems we have a solid lead now.
>
> --Hardy
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3444
days inactive
3445
days old
16 comments
5 participants
participants (5)
-
Gunnar Morling -
Hardy Ferentschik -
Sanne Grinovero -
Scott Marlow -
Steve Ebersole