Re: [hibernate-dev] Hibernate Commons project

2017-02-08 Thread Emmanuel Bernard 

> On 7 Feb 2017, at 12:03, Guillaume Smet  wrote:
> 
> Hi,
> 
> On Mon, Feb 6, 2017 at 4:21 PM, Emmanuel Bernard  > wrote:
> On the license, I think ASL 2.0 is the best for such project.
> 
> As we discussed it in Lisbon, we might "copy" (using Maven) sources from an 
> internal utility project to the NoORM projects, as we want to avoid 
> dependency hell with different versions of the utilities. In this case, they 
> might be included in the source jar. Thus, I think the best is to dual 
> license everything from the start.
> 
> I'll go do that.

For your info, having ASL licensed files side by side LGPL code is fine. Just 
make sure that each ASL file retains their copyright and license headers. The 
Apache Software Foundation has stricter rules for its projects consuming other 
licenses than what the license text says. But dual licensing works.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [HV/HSEARCH] Free form

2017-02-08 Thread Emmanuel Bernard 

> On 7 Feb 2017, at 11:17, Gunnar Morling  wrote:
> 
> Emmanuel,
> 
> In your PoC, how would a complete tree-like structure be traversed?
> It's not clear to me, who is driving StructureTraverser, i.e. which
> component will call processSubstructureInContainer() et al. when
> traversing an entire tree.

The metadata you have about which entity and property is indexed will drive the 
traversal. In case of HV, the metadata about which entity / property is 
constrained will.
The metadata is a separate model because:
1.  some structures like JSON have no real model
2. we still need additional information like @Field, @Valid etc as part of our 
metadata to drive navigation
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap

2017-02-08 Thread Emmanuel Bernard 
Sounds good to me.
> On 7 Feb 2017, at 11:53, Gunnar Morling  wrote:
> 
> So the issue is a more general one than I thought.
> 
> We'll run into the same situation, too, when there is an error in BV's
> validation.xml or any constraint mapping file (e.g. a reference to a
> non-existent MessageInterpolator). That error will currently be
> suppressed with validation-mode auto.
> 
> I'm wondering whether in BV 2.0 we should define a new sub-type of
> ValidationException: NoProviderFoundException which is raised by
> javax.validation.Validation in case no BV provider is found.
> 
> Then JPA/ORM could specifically ignore this exception in
> validation-mode auto but let all other exceptions bubble up, letting
> the user know early on about any issues they have with their
> validation provider or its config.
> 
> Thoughts?
> 
> 
> 
> 
> 2017-02-06 15:53 GMT+01:00 Emmanuel Bernard :
>> +1 to fail fast with the explicit error in that case.
>> 
>>> On 1 Feb 2017, at 11:33, Gunnar Morling  wrote:
>>> 
>>> Hi,
>>> 
>>> JPA defines for validation mode "auto" that bean validation must occur
>>> if a BV provider is present and that no validation shall occur
>>> otherwise.
>>> 
>>> What should happen though if a BV provider such as HV is present but
>>> it fails to bootstrap? In case of HV this happens if no expression
>>> language implementation can be found.
>>> 
>>> Currently, the user has a very hard time to find out about this, as
>>> this exception essentially is suppressed (for mode "callback" the
>>> exception is raised).
>>> 
>>> Should we raise a specific exception in HV if it cannot be
>>> bootstrapped? In ORM, we could handle that one specifically and raise
>>> it also if for validation mode "auto" (would have to happen
>>> reflectively, though, as to avoid a hard dependency).
>>> 
>>> I can do this change but first wanted to make sure that this is inline
>>> with what you all think should be done.
>>> 
>>> Thanks,
>>> 
>>> --Gunnar
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Issue with unidirectional one-to-many association with a join column that references a column that is not the primary key

2017-02-08 Thread Marcello Romano 
Hi,

A one-to-many association is causing Hibernate to
throw the following exception when loading an entity via
Session.get(domainClass, identifier), under the following conditions:

1. the association collection is annotated with @Fetch(FetchMode.JOIN)
2. the association's join column is referencing a non-primary key of the
owning entity
3. the association's join column value is referencing a non-existing record
of the associated table (the "many" side).

Caused by: org.hibernate.property.access.spi.PropertyAccessException: Error
accessing field [protected java.lang.Long ...] by reflection for persistent
property [...] : 1GBE4E1E04
at
org.hibernate.property.access.spi.GetterFieldImpl.get(GetterFieldImpl.java:43)
at
org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValue(AbstractComponentTuplizer.java:58)
at org.hibernate.type.ComponentType.getPropertyValue(ComponentType.java:419)
at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:242)
at
org.hibernate.engine.spi.CollectionKey.generateHashCode(CollectionKey.java:64)
at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:58)
at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:43)
at
org.hibernate.engine.loading.internal.CollectionLoadContext.getLoadingCollection(CollectionLoadContext.java:95)
at
org.hibernate.loader.plan.exec.process.internal.CollectionReferenceInitializerImpl.finishUpRow(CollectionReferenceInitializerImpl.java:105)
at
org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:121)
at
org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:239)
at
org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:122)
at
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:122)
at
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86)
at
org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:167)
at
org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3967)
at
org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:508)
at
org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:478)
at
org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219)
at
org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278)
at
org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121)
at
org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89)
at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129)
at org.hibernate.internal.SessionImpl.access$2600(SessionImpl.java:164)
at
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2696)
at org.hibernate.internal.SessionImpl.get(SessionImpl.java:975)
...
Caused by: java.lang.IllegalArgumentException: Can not set ... to
java.lang.String
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
at
sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:55)
at
sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36)
at java.lang.reflect.Field.get(Field.java:379)
at
org.hibernate.property.access.spi.GetterFieldImpl.get(GetterFieldImpl.java:39)
... 44 more


The problem is that when initializing the collection, Hibernate is not able
to retrieve the association key value in
CollectionReferenceInitializerImpl.finishUpRow and will fall back to use
the entity owner's primary key instead, causing the
IllegalArgumentException.

We have noticed that there is a related open issue:
https://hibernate.atlassian.net/browse/HHH-9370

We have worked around this issue by changing the way optionalKey is
retrieved in CollectionReferenceInitializerImpl.finishUpRow,
foreignKeyPropertyName );

ResultSetProcessingContext.EntityReferenceProcessingState ownerState =
context.getOwnerProcessingState( (Fetch) collectionReference );
Serializable optionalKey =
collectionReference.getCollectionPersister().getCollectionType().getKeyOfOwner(ownerState.getEntityInstance(),
context.getSession());


Although this seems to work for us, we would like to collaborate to have
this fixed upstream, if you believe this is actually caused by a bug and
not by using Hibernate associations in the wrong way.

Thanks,
Marcello
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Issue with unidirectional one-to-many association with a join column that references a column that is not the primary key

2017-02-08 Thread Vlad Mihalcea 
Hi,

You can send us a Pull Request on GitHub with a test case that replicates
it, so we can discuss and integrate it.

Vlad

On Wed, Feb 8, 2017 at 10:11 PM, Marcello Romano 
wrote:

> Hi,
>
> A one-to-many association is causing Hibernate to
> throw the following exception when loading an entity via
> Session.get(domainClass, identifier), under the following conditions:
>
> 1. the association collection is annotated with @Fetch(FetchMode.JOIN)
> 2. the association's join column is referencing a non-primary key of the
> owning entity
> 3. the association's join column value is referencing a non-existing record
> of the associated table (the "many" side).
>
> Caused by: org.hibernate.property.access.spi.PropertyAccessException:
> Error
> accessing field [protected java.lang.Long ...] by reflection for persistent
> property [...] : 1GBE4E1E04
> at
> org.hibernate.property.access.spi.GetterFieldImpl.get(
> GetterFieldImpl.java:43)
> at
> org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValue(
> AbstractComponentTuplizer.java:58)
> at org.hibernate.type.ComponentType.getPropertyValue(
> ComponentType.java:419)
> at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:242)
> at
> org.hibernate.engine.spi.CollectionKey.generateHashCode(
> CollectionKey.java:64)
> at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:58)
> at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:43)
> at
> org.hibernate.engine.loading.internal.CollectionLoadContext.
> getLoadingCollection(CollectionLoadContext.java:95)
> at
> org.hibernate.loader.plan.exec.process.internal.
> CollectionReferenceInitializerImpl.finishUpRow(
> CollectionReferenceInitializerImpl.java:105)
> at
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(
> AbstractRowReader.java:121)
> at
> org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$
> EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:239)
> at
> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.
> extractResults(ResultSetProcessorImpl.java:122)
> at
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.
> executeLoad(AbstractLoadPlanBasedLoader.java:122)
> at
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.
> executeLoad(AbstractLoadPlanBasedLoader.java:86)
> at
> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(
> AbstractLoadPlanBasedEntityLoader.java:167)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.load(
> AbstractEntityPersister.java:3967)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(
> DefaultLoadEventListener.java:508)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(
> DefaultLoadEventListener.java:478)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.load(
> DefaultLoadEventListener.java:219)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(
> DefaultLoadEventListener.java:278)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(
> DefaultLoadEventListener.java:121)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(
> DefaultLoadEventListener.java:89)
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129)
> at org.hibernate.internal.SessionImpl.access$2600(SessionImpl.java:164)
> at
> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(
> SessionImpl.java:2696)
> at org.hibernate.internal.SessionImpl.get(SessionImpl.java:975)
> ...
> Caused by: java.lang.IllegalArgumentException: Can not set ... to
> java.lang.String
> at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentExcepti
> on(UnsafeFieldAccessorImpl.java:164)
> at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentExcepti
> on(UnsafeFieldAccessorImpl.java:168)
> at
> sun.reflect.UnsafeFieldAccessorImpl.ensureObj(
> UnsafeFieldAccessorImpl.java:55)
> at
> sun.reflect.UnsafeObjectFieldAccessorImpl.get(
> UnsafeObjectFieldAccessorImpl.java:36)
> at java.lang.reflect.Field.get(Field.java:379)
> at
> org.hibernate.property.access.spi.GetterFieldImpl.get(
> GetterFieldImpl.java:39)
> ... 44 more
>
>
> The problem is that when initializing the collection, Hibernate is not able
> to retrieve the association key value in
> CollectionReferenceInitializerImpl.finishUpRow and will fall back to use
> the entity owner's primary key instead, causing the
> IllegalArgumentException.
>
> We have noticed that there is a related open issue:
> https://hibernate.atlassian.net/browse/HHH-9370
>
> We have worked around this issue by changing the way optionalKey is
> retrieved in CollectionReferenceInitializerImpl.finishUpRow,
> foreignKeyPropertyName );
>
> ResultSetProcessingContext.EntityReferenceProcessingState ownerState =
> context.getOwnerProcessingState( (Fetch) collectionReference );
> Serializable optionalKey =
> collectionReference.getCollectionPersister().getCollectionType().
> getKeyOfOwn

Re: [hibernate-dev] Issue with unidirectional one-to-many association with a join column that references a column that is not the primary key

2017-02-08 Thread Marcello Romano 
Hi Vlad,

I have created the following pull request with the test case:
https://github.com/hibernate/hibernate-orm/pull/1786

Thanks,
Marcello

On 8 February 2017 at 15:35, Vlad Mihalcea  wrote:

> Hi,
>
> You can send us a Pull Request on GitHub with a test case that replicates
> it, so we can discuss and integrate it.
>
> Vlad
>
> On Wed, Feb 8, 2017 at 10:11 PM, Marcello Romano 
> wrote:
>
>> Hi,
>>
>> A one-to-many association is causing Hibernate to
>> throw the following exception when loading an entity via
>> Session.get(domainClass, identifier), under the following conditions:
>>
>> 1. the association collection is annotated with @Fetch(FetchMode.JOIN)
>> 2. the association's join column is referencing a non-primary key of the
>> owning entity
>> 3. the association's join column value is referencing a non-existing
>> record
>> of the associated table (the "many" side).
>>
>> Caused by: org.hibernate.property.access.spi.PropertyAccessException:
>> Error
>> accessing field [protected java.lang.Long ...] by reflection for
>> persistent
>> property [...] : 1GBE4E1E04
>> at
>> org.hibernate.property.access.spi.GetterFieldImpl.get(Getter
>> FieldImpl.java:43)
>> at
>> org.hibernate.tuple.component.AbstractComponentTuplizer.getP
>> ropertyValue(AbstractComponentTuplizer.java:58)
>> at org.hibernate.type.ComponentType.getPropertyValue(ComponentT
>> ype.java:419)
>> at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:242)
>> at
>> org.hibernate.engine.spi.CollectionKey.generateHashCode(Coll
>> ectionKey.java:64)
>> at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:58)
>> at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:43)
>> at
>> org.hibernate.engine.loading.internal.CollectionLoadContext.
>> getLoadingCollection(CollectionLoadContext.java:95)
>> at
>> org.hibernate.loader.plan.exec.process.internal.CollectionRe
>> ferenceInitializerImpl.finishUpRow(CollectionReferenc
>> eInitializerImpl.java:105)
>> at
>> org.hibernate.loader.plan.exec.process.internal.AbstractRowR
>> eader.readRow(AbstractRowReader.java:121)
>> at
>> org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetai
>> ls$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:239)
>> at
>> org.hibernate.loader.plan.exec.process.internal.ResultSetPro
>> cessorImpl.extractResults(ResultSetProcessorImpl.java:122)
>> at
>> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBase
>> dLoader.executeLoad(AbstractLoadPlanBasedLoader.java:122)
>> at
>> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBase
>> dLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86)
>> at
>> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntity
>> Loader.load(AbstractLoadPlanBasedEntityLoader.java:167)
>> at
>> org.hibernate.persister.entity.AbstractEntityPersister.load(
>> AbstractEntityPersister.java:3967)
>> at
>> org.hibernate.event.internal.DefaultLoadEventListener.loadFr
>> omDatasource(DefaultLoadEventListener.java:508)
>> at
>> org.hibernate.event.internal.DefaultLoadEventListener.doLoad
>> (DefaultLoadEventListener.java:478)
>> at
>> org.hibernate.event.internal.DefaultLoadEventListener.load(D
>> efaultLoadEventListener.java:219)
>> at
>> org.hibernate.event.internal.DefaultLoadEventListener.proxyO
>> rLoad(DefaultLoadEventListener.java:278)
>> at
>> org.hibernate.event.internal.DefaultLoadEventListener.doOnLo
>> ad(DefaultLoadEventListener.java:121)
>> at
>> org.hibernate.event.internal.DefaultLoadEventListener.onLoad
>> (DefaultLoadEventListener.java:89)
>> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129)
>> at org.hibernate.internal.SessionImpl.access$2600(SessionImpl.java:164)
>> at
>> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.
>> load(SessionImpl.java:2696)
>> at org.hibernate.internal.SessionImpl.get(SessionImpl.java:975)
>> ...
>> Caused by: java.lang.IllegalArgumentException: Can not set ... to
>> java.lang.String
>> at
>> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(
>> UnsafeFieldAccessorImpl.java:164)
>> at
>> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(
>> UnsafeFieldAccessorImpl.java:168)
>> at
>> sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAcc
>> essorImpl.java:55)
>> at
>> sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFi
>> eldAccessorImpl.java:36)
>> at java.lang.reflect.Field.get(Field.java:379)
>> at
>> org.hibernate.property.access.spi.GetterFieldImpl.get(Getter
>> FieldImpl.java:39)
>> ... 44 more
>>
>>
>> The problem is that when initializing the collection, Hibernate is not
>> able
>> to retrieve the association key value in
>> CollectionReferenceInitializerImpl.finishUpRow and will fall back to use
>> the entity owner's primary key instead, causing the
>> IllegalArgumentException.
>>
>> We have noticed that there is a related open issue:
>> https://hibernate.atlassian.net/browse/HHH-9370
>>
>> We have worked around this issue by changing the way optionalKey is
>> retr