Fwd: classloading issue when trying to add envers to as7
by Strong Liu
Begin forwarded message:
>
> Adam,
>
> can you send your test app to me?
>
> use cases:
>
> 1. envers and hibernate core in as7
> 2. envers jar in app, and hibernate core in as7
> 3. envers and hibernate core in app
>
> #1 is almost done, just need some code clean up
> (Scott, we missed services="import", that's why ClassLoaderService can't find resource in envers/META-INF/services)
14 years, 11 months
classloading issue when trying to add envers to as7
by Strong Liu
Hi there,
first of all, I have finished this task, and test pass.
but :), i have to make the following changes, i'd like to hear you guys' thoughts before i go to much away.
1. adding envers into org.hibernate module in as7, so user's app can see both hibernate and envers class
(with an separate envers module i ran into some cycle dependency issue)
2. envers throws "listeners were not registed" exception, means hibernate's IntegratorServiceImpl can't see envers class/resource
IntegratorServiceImpl is using java.util.ServiceLoader#load(Class<S> service), which internally using TCCL, (I think)
that's the reason why core can't see envers' integrator.
so, i created a custom ServiceLoader which use ClassLoaderService to find the integrator, but this doesn't work either.
since, we need org.hibernate.service.classloading.internal.ClassLoaderServiceImpl#locateResources first (META-INF/services/org.hibernate.integrator.spi.Integrator) and ClassLoaderServiceImpl using resourceClassLoader to do this.
by default, resourceClassLoader is set to applicationClassLoader in ClassLoaderServiceImpl.
then, i changed IntegratorServiceImpl to use java.util.ServiceLoader#load(Class<S> service, IntegratorServiceImpl.class.getClassLoader()
), test pass, but this of course is not the fix.
so, i changed the custom ServiceLoader to use classLoaderService to locateResources first, and using ServiceLoader.class.getClassLoader() to reload the resource again.
here are the changes:
https://github.com/stliu/hibernate-core/commit/09ce5defabea8cfb87d06c3d7b...
https://github.com/stliu/jboss-as/commit/616237755626672157fb2ae565fadb16...
thoughts?
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
14 years, 11 months
Patch for HHH-6361 / HHH-6349 : Envers loses audit information due to a Hibernate core bug
by Scheper, Erik-Berndt
Hi,
I'd like someone to review my proposed fix of HHH-6361 (https://github.com/hibernate/hibernate-core/pull/117) for the 3.6 branch.
>From a Hibernate core perspective, this may seem like a minor issue, but it is the cause of HHH-6349, where Envers forever loses the audit information when objects were added to or removed from a collection. Since there is no way to retrieve this information from the database at a later moment, this is really bad from the Envers (auditing) perspective.
The proposed fix causes both the provided testcase for HHH-6361 (the Hibernate core issue) and the testcase for HHH-6349 (the Envers issue) to pass by ensuring that after a merge() operation the snapshot value of the collection, as obtained by collectionEntry.getSnapshot(), corresponds with the database contents. This is a good thing, of course.
However, apart from the possible performance implication (though I'm not sure if there's a remedy for this), I am a bit worried about the fact that I had to fix a unit test in the Hibernate testsuite (org.hibernate.test.manytomanyassociationclass.compositeid.ManyToManyAssociationClassCompositeIdTest) to make the 3.6 build succeed. As a rule, that's a bad sign.
What happens is that after the patch this test crashes with an NPE in the hashCode() method of MembershipWithCompositeId.Id class. The reason of the NPE is that MembershipWithCompositeId now has a non-null "Id" property, with a null value of the userId and groupId properties. Even though it was easy to fix the test by overriding the deleteMembership()-method in ManyToManyAssociationClassCompositeIdTest by setting the "Id" property of MembershipWithCompositeId to null, this doesn't feel good to me.
I'd really like to see a fix for HHH-6361 without these changes in ManyToManyAssociationClassCompositeIdTest, but I couldn't find one. Any help there would be appreciated of course.
After an initial review, I'd be more than happy to provide a fix for the Hibernate 4.0.x series, which is also plagued by the same bug.
Regards,
Erik-Berndt
Disclaimer:
This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
14 years, 11 months
[Search] PurgeAll & Sharding API
by Sanne Grinovero
Hi,
I just noticed that a PurgeAll request will ask the sharding strategy
to know to which shard it should be applied, using the following
method:
getDirectoryProvidersForDeletion(Class<?> entity, Serializable id,
String idInString) {
and passing in null for the second and third arguments.
That's not broken per se as the sharding implementor can easily deal
with this, but in our IdHashShardingStrategy we don't consider this,
so we could at least improve the example.
I'm wondering why we don't use
#getDirectoryProvidersForAllShards()
likely to give more flexibility to implementors; in that case I guess
that because PurgeAll was introduced after sharding, it was not an
option to create a method
getDirectoryProvidersForPurgeAll(Class<?> entity)
shall we add this one?
Alternatively I think we should either fix the example or use the
"all" strategy.
Cheers,
Sanne
14 years, 11 months
Fwd: [HSEARCH-566] Indexing null values for an @ElementCollection
by Emmanuel Bernard
Begin forwarded message:
> From: "Davide D'Alto" <daltodavide(a)gmail.com>
> Date: 1 août 2011 14:29:57 HAEC
> To: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Subject: Re: [hibernate-dev] [HSEARCH-566] Indexing null values for an @ElementCollection
>
> >> That's great, it is much cleaner. I was leaning for the "less
> >> annotations, we can figure it out" but indeed I like the "least
> >> surprise" principle more, and this is not more verbose either. Though
> >> Davide will hate me as binding the bridge will need to be different
> >> than his current pull request :)
> No problem :)
>
> >> Davide, what do you think of this? And can you add the agreed points
> >> to the unit tests, mainly the DateBridge, resolution and NumericField
> >> tests with custom precision, and above all checking for the capability
> >> to override whatever your patch does with a custom bridge?
> As a user I wouldn't be so confused about using the @DateBridge with a collection of Date but it seems to make sense to use @IndexEmbedded.
> I think I will change the code for this scenario so that we can see the number of annotations used in this case and contunue from there.
>
> I will remove the indexing of a null collection/array as well.
>
>
> On Mon, Aug 1, 2011 at 1:04 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>
> >>> @IndexedEmbedded
> >>> @DateBridge(resolution=Resolution.DAY)
> >>> private Set<Date> views;
> >
> >>> Of course this clashes in case people want both the proposed behavior
> >>> and use a custom field bridge in parallel. But such feature is not
> >>> supported by the currently proposed syntax either
> >>
> >> That's great, it is much cleaner. I was leaning for the "less
> >> annotations, we can figure it out" but indeed I like the "least
> >> surprise" principle more, and this is not more verbose either. Though
> >> Davide will hate me as binding the bridge will need to be different
> >> than his current pull request :)
> >> Davide, what do you think of this? And can you add the agreed points
> >> to the unit tests, mainly the DateBridge, resolution and NumericField
> >> tests with custom precision, and above all checking for the capability
> >> to override whatever your patch does with a custom bridge?
> >
> > I find @IndexedEmbedded as ambiguous, besides you are adding an additional
> > annotation
> > since @ElementCollection is still there, right? Just saying there are
> > quite a few annotations.
>
> Note that @ElementCollection is the JPA annotation that might or might not be present (HSearch on Infinispan doesn't use JPA annotations).
>
> My reasoning for liking @IndexedEmbedded is that whether basic, embeddable or entity collection, it's still a collection and we still embed the information into the index.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
14 years, 11 months
[HSEARCH-566] Indexing null values for an @ElementCollection
by Sanne Grinovero
Hello,
initially we dealt with null values as by not indexing them; since we
have the "indexNullAs" option on @Field [1]
we allow to use a custom token in the index instead, so to make it
possible to search for entities having that field at null.
In case you would have a
@ElementCollection
@Field(indexNullAsl="nullToken")
String[] tags
having the value {"A","B",null}
I would expect this to be encoded in the index with three field
writes, all named "tags", and having values "A", "B", "nullToken".
But what if the array value is null by itself?
Personally I would expect it to *not* write anything, not encode the
"nullToken" which is reserved for an element being null: not having
the collection itself means in my opinion that there are no elements,
being similar as having an empty collection.
An alternative way could be to write the "nullToken" in both cases,
but I'm not liking this much as it would imply that the item will
match for a search similar to "all items having a null tag", while in
fact it had no tags at all.
I'd avoid adding more options as it would need a new annotation, or
adding options to other annotations which only apply in this case.
What do others think?
Sanne
1 - http://docs.jboss.org/hibernate/search/3.4/api/org/hibernate/search/annot...
14 years, 11 months
