On 07/05/2019 13:51, Sergey Mikhno wrote:
Hi Emmanuel,
Could you please give me some feedback on my questions.
1. Why do we have a ClassNotFounfException
DeepTrimCachingNormalizingComparator when starting our ApacheDS server
with AM25 Release jar.
Sorry, was busy on something else. Will have a look at your issue tonite.
Le mar. 7 mai 2019 à 13:51, Sergey Mikhno a
écrit :
> Hi Emmanuel,
>
> Could you please give me some feedback on my questions.
>
> 1. Why do we have a ClassNotFounfException DeepTr
> imCachingNormalizingComparator when
Hi Emmanuel,
Could you please give me some feedback on my questions.
1. Why do we have a ClassNotFounfException DeepTr
imCachingNormalizingComparator when starting our ApacheDS server with AM25
Release jar. (
Hi Emmanuel,
I wanted to inform you what are the results of our testing.
1. Starting the Release AM25 throws an Exception (ClassNotFounfException
DeepTrimCachingNormalizingComparator)
2. AM25-SNAPSHOT starts normally but we cannot use uniqueMember index,
because the query brings empty result.
3.
Hi Emmanuel,
We built the trunk today and the results are as follows: UniqueMember query
without index has become faster, the same query with the index gives empty
result back.
Is it possible that our index definition is wrong?
We are defining the index in Apache Directory Studio.
The Comparator
Hi Emmanuel,
I can see now that you have already fixed the problem.
We have M24 running now, how can I use your fix in our environment?
Or otherwise how can I build the latest snapshot to be able to verify it?
Best regards
Sergey Mikhno
Software Developer
Galexis AG
On Tue, Apr 30, 2019 at
I have created a JIRA ticket for this issue:
https://issues.apache.org/jira/browse/DIRAPI-340
Incidentally, I also have a fix that I'm going to test and apply asap.
(the fix is pretty straightforward)
On 30/04/2019 16:29, Sergey Mikhno wrote:
Thank you again,
Is it possible to get a fix
Thank you again,
Is it possible to get a fix for this issue, how should we go about it?
It would be great to be able to test a bugfix in our environment.
Best Regards
Sergey
On Tue, Apr 30, 2019 at 4:24 PM Emmanuel Lécharny
wrote:
> Ok, this a clear bug. The UniqueMemberComparator.compare()
Ok, this a clear bug. The UniqueMemberComparator.compare() method is
badly implemented, and returns either 0 or -1, which means we can't
browse the index, as we never get a +1 (ie, provided uniqueMember is
superior to the stored one).
I'll get that fixed.
On 30/04/2019 15:59, Emmanuel
Hi Emmanuel,
Thank you very much for your quick response,
Please let me know if you need more information.
Best regards
Sergey Mikhno
Software Developer
Galexis AG
On Tue, Apr 30, 2019 at 3:59 PM Emmanuel Lécharny
wrote:
> Hi Sergey,
>
>
> I can positively confirm that there is a problem.
Hi Sergey,
I can positively confirm that there is a problem. I'm able to reproduce
the issue you are facing in a unit test.
I'm currently debugging the server, and hope to come with a quick answer
(and hopefully a fix).
On 30/04/2019 11:33, Sergey Mikhno wrote:
Dear Emmanuel,
I spent
Hi Emmanuel,
Today I tried to use GroupOfNames and member field for group membership and
created an index for "member", that index looks to be working properly.
Could you please tell me if there is still a bug with the uniqueMember
Index? If there is no bug how can I create such an index and keep
Hi Emmanuel,
Thank you for your answer,
Yes we are using 2.0.0-M24 now, the bug is only an example of our problem.
Bit the behavior described is very similar to what we have now in 2.0.0-M24
I have also tried to repair the Apacheds using apacheds.sh repair, but it
didn’t help.
Thank you again
Hi,
The bug was in 2.0.0-M7, which is nearly 7 years old... have you tried with
a newer version ?
Le jeu. 25 avr. 2019 à 17:45, Sergey Mikhno a
écrit :
> Dear Users,
>
> I have a specific question about uniqueMember AT.
>
> We have a hierarchy of groups and permissions with several group
14 matches
Mail list logo
