solr related test failures

2016-12-01 Thread Julian Reschke 
Can somebody with solr-related know how please have a look at these? See 
.


Best regards, Julian


Failed

org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexHookIT.testPropertyAddition
Failing for the past 1 build (Since Failed#1311 )
Took 1.2 sec.
Error Message

expected:<[bar]> but was:<[]>

Stacktrace

junit.framework.AssertionFailedError: expected:<[bar]> but was:<[]>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:86)
	at 
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexHookIT.testPropertyAddition(SolrIndexHookIT.java:102)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
	at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
	at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
	at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)

at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

[Oak origin/1.2] Apache Jackrabbit Oak matrix - Build # 1311 - Still Failing

2016-12-01 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1311)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1311/ to view 
the results.

Changes:
[tomekr] OAK-5193: Version tree may become inconsistent after removing a version

 

Test results:
2 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexHookIT.testPropertyAddition

Error Message:
expected:<[bar]> but was:<[]>

Stack Trace:
junit.framework.AssertionFailedError: expected:<[bar]> but was:<[]>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:86)
at 
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexHookIT.testPropertyAddition(SolrIndexHookIT.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)


FAILED:  
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexHookIT.testPropertyAddition

Error Message:
expected:<[bar]> but was:<[]>

Stack Trace:
junit.framework.AssertionFailedError: expected:<[bar]> but was:<[]>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:86)
at 
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexHookIT.testPropertyAddition(SolrIndexHookIT.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at

Re: guava ByteStreams.equal()

2016-12-01 Thread Alex Parvulescu 
Hi,

It's not a bad idea, I see we use this method only in 2 places [0] and [1],
and this change would not even need to have the guava version updated on
oak as far as I see it.
It would be good if you could create an issue and attach a patch for review.

best,
alex


[0]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/memory/AbstractBlob.java#L68
[1]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-upgrade/src/test/java/org/apache/jackrabbit/oak/upgrade/blob/LengthCachingDataStoreTest.java#L109



On Thu, Dec 1, 2016 at 2:26 PM, Torgeir Veimo 
wrote:

> The method
>
> ByteStreams.equal(InputSupplier, InputSupplier)
>
> is deprecated in guava 17 and removed in guava 18. Would it be an idea to
> replace the call to it by using the
>
> ByteSource.contentEquals(ByteSource)
>
> as suggested in guava 17?
>
> This would make it easier to deploy in a non-ogsi environment when using
> guava 18.0+.
> --
> -Tor
>

Re: Oak 1.5.15 release plan

2016-12-01 Thread Angela Schreiber 
Hi Manfred

I don't see how you can 'keep it' for the LDAP case. Please create
new Improvement ticket, such that we can look for a proper solution.

What you actually wanted to do but which IMO got never explicitly
mentioned due to mixing implementation details with the generic
sync-stuff:

"Ability to resolve principal name from ExternalIdentityRef without IDP
roundtrip"

IMO such an improvement would make sense for all cases not just for the
LDAP
integration. But I want to have that done properly and without hacks
and relying on implementation details of one particular impl for the
generic 
code base.

Based on the experience we made here, I think it would make sense, to
get more reviews and feedback on changes for the mentioned modules.
Specially when API extensions are involved that are really cumbersome
to fix later on. In general I think this is a very good practise and
it may help spotting issues early in the cycle.

Kind regards
Angela


On 01/12/16 13:46, "Manfred Baedke"  wrote:

>Hi Davide, Angela,
>
>Note that this is not an issue with oak-auth-ldap, but rather with
>oak-auth-external.
>
>The ExternalIdentity implementation used by oak-auth-ldap uses the DN as
>both the id and the principal name, so it's working fine. Other
>implementations of the external auth mechanism may run into problems
>(btw: are other implementations known?).
>
>I'm going to revert the change now, but since the performance
>improvement was striking on customer site, I'd like to keep it for the
>LDAP case. Anyone feel free to give suggestions on the most elegant way
>to do this.
>
>Best regards,
>Manfred
>
>On 12/1/2016 12:52 PM, Angela Schreiber wrote:
>> Hi Davide
>>
>> IMO the fix for OAK-5200 is straight forward:
>>
>> 1. revert changes made to DynamicSyncContext: it's here where the bug
>>was
>> introduced.
>> that should be doable today.
>>
>> 2. have a quick discussion on oak-dev on how to deal with the new,
>> exported class ExternalGroupRef
>> which was introduced (and was already backported): this one would
>>not
>> be used any
>> more after 1) but removing it again would (afaik) lead to a major
>> version bump.
>> i want to get more opinions on that, because i am not aware that we
>>had
>> the problem
>> before (or missed/don't remember how we dealt with it).
>> if we see that it's not doable or too cumbersome reverting this
>>class,
>> we may decide
>> to leave it... we might find it useful later on or end up
>>deprecating
>> it for 1.8.
>> but i want to have a conscious decision here and some broader
>>agreement
>> from the team.
>>
>> - if we leave it -> changes in auth-ldap code base don't need to be
>> reverted
>> - if we revert it -> changes in auth-ldap also would need to be
>>reverted
>>
>> Hope that helps
>> Angela
>>
>> PS: as far as the original improvement is concerned that was the
>>intention
>> of OAK-4930
>> (but which is not obvious from the subject, which is not correct), we
>>need
>> to have a new
>> Improvement ticket, where we can discuss the options... I want that kind
>> of improvements
>> to be properly tracked in jira (and ultimately in the documentation and
>> benchmarked) such
>> that everyone can understand why a given change was made... i had a hard
>> time yesterday to
>> understand what was the actual aim of OAK-4930 and it was just by
>> coincidence that I hours
>> later spotted the issue... just because I could not understand how I
>>could
>> have mixed up
>> ID and principal  name in the original code (and which turned out wasn't
>> the case).
>> 
>>
>> On 01/12/16 12:15, "Davide Giannella"  wrote:
>>
>>> Hello team,
>>>
>>> I'm planning to cut Oak 1.5.15 on Monday 5th December.
>>>
>>> If there are any objections please let me know. Otherwise I will
>>> re-schedule any non-resolved issue for the next iteration.
>>>
>>> Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
>>> really a blocker for 1.5.15? Or is it rather for 1.6? If it's for
>>>1.5.15
>>> how long for the fix to get done?
>>>
>>> Thanks
>>> Davide
>>>
>>>
>

guava ByteStreams.equal()

2016-12-01 Thread Torgeir Veimo 
The method

ByteStreams.equal(InputSupplier, InputSupplier)

is deprecated in guava 17 and removed in guava 18. Would it be an idea to
replace the call to it by using the

ByteSource.contentEquals(ByteSource)

as suggested in guava 17?

This would make it easier to deploy in a non-ogsi environment when using
guava 18.0+.
-- 
-Tor

Re: Oak 1.5.15 release plan

2016-12-01 Thread Manfred Baedke 

Hi Davide, Angela,

Note that this is not an issue with oak-auth-ldap, but rather with 
oak-auth-external.


The ExternalIdentity implementation used by oak-auth-ldap uses the DN as 
both the id and the principal name, so it's working fine. Other 
implementations of the external auth mechanism may run into problems 
(btw: are other implementations known?).


I'm going to revert the change now, but since the performance 
improvement was striking on customer site, I'd like to keep it for the 
LDAP case. Anyone feel free to give suggestions on the most elegant way 
to do this.


Best regards,
Manfred

On 12/1/2016 12:52 PM, Angela Schreiber wrote:

Hi Davide

IMO the fix for OAK-5200 is straight forward:

1. revert changes made to DynamicSyncContext: it's here where the bug was
introduced.
that should be doable today.

2. have a quick discussion on oak-dev on how to deal with the new,
exported class ExternalGroupRef
which was introduced (and was already backported): this one would not
be used any
more after 1) but removing it again would (afaik) lead to a major
version bump.
i want to get more opinions on that, because i am not aware that we had
the problem
before (or missed/don't remember how we dealt with it).
if we see that it's not doable or too cumbersome reverting this class,
we may decide
to leave it... we might find it useful later on or end up deprecating
it for 1.8.
but i want to have a conscious decision here and some broader agreement
from the team.

- if we leave it -> changes in auth-ldap code base don't need to be
reverted
- if we revert it -> changes in auth-ldap also would need to be reverted

Hope that helps
Angela

PS: as far as the original improvement is concerned that was the intention
of OAK-4930
(but which is not obvious from the subject, which is not correct), we need
to have a new
Improvement ticket, where we can discuss the options... I want that kind
of improvements
to be properly tracked in jira (and ultimately in the documentation and
benchmarked) such
that everyone can understand why a given change was made... i had a hard
time yesterday to
understand what was the actual aim of OAK-4930 and it was just by
coincidence that I hours
later spotted the issue... just because I could not understand how I could
have mixed up
ID and principal  name in the original code (and which turned out wasn't
the case).



On 01/12/16 12:15, "Davide Giannella"  wrote:


Hello team,

I'm planning to cut Oak 1.5.15 on Monday 5th December.

If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved issue for the next iteration.

Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
how long for the fix to get done?

Thanks
Davide

Re: Oak 1.5.15 release plan

2016-12-01 Thread Angela Schreiber 
Hi Davide

IMO the fix for OAK-5200 is straight forward:

1. revert changes made to DynamicSyncContext: it's here where the bug was
introduced.
   that should be doable today.

2. have a quick discussion on oak-dev on how to deal with the new,
exported class ExternalGroupRef
   which was introduced (and was already backported): this one would not
be used any
   more after 1) but removing it again would (afaik) lead to a major
version bump.
   i want to get more opinions on that, because i am not aware that we had
the problem 
   before (or missed/don't remember how we dealt with it).
   if we see that it's not doable or too cumbersome reverting this class,
we may decide
   to leave it... we might find it useful later on or end up deprecating
it for 1.8.
   but i want to have a conscious decision here and some broader agreement
from the team.

   - if we leave it -> changes in auth-ldap code base don't need to be
reverted
   - if we revert it -> changes in auth-ldap also would need to be reverted

Hope that helps
Angela

PS: as far as the original improvement is concerned that was the intention
of OAK-4930
(but which is not obvious from the subject, which is not correct), we need
to have a new 
Improvement ticket, where we can discuss the options... I want that kind
of improvements
to be properly tracked in jira (and ultimately in the documentation and
benchmarked) such 
that everyone can understand why a given change was made... i had a hard
time yesterday to 
understand what was the actual aim of OAK-4930 and it was just by
coincidence that I hours
later spotted the issue... just because I could not understand how I could
have mixed up 
ID and principal  name in the original code (and which turned out wasn't
the case).
   

On 01/12/16 12:15, "Davide Giannella"  wrote:

>Hello team,
>
>I'm planning to cut Oak 1.5.15 on Monday 5th December.
>
>If there are any objections please let me know. Otherwise I will
>re-schedule any non-resolved issue for the next iteration.
>
>Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
>really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
>how long for the fix to get done?
>
>Thanks
>Davide
>
>

Re: svn commit: r1772167 - /jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryShapeTool.java

2016-12-01 Thread Davide Giannella 
On 01/12/2016 11:04, Francesco Mari wrote:
> Would it make sense to make this part of oak-run instead?
+1

Davide

Oak 1.5.15 release plan

2016-12-01 Thread Davide Giannella 
Hello team,

I'm planning to cut Oak 1.5.15 on Monday 5th December.

If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved issue for the next iteration.

Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
how long for the fix to get done?

Thanks
Davide

[X-POST] Oak 1.6 and JR 2.14 release plan

2016-12-01 Thread Davide Giannella 
Hello everyone,

as Jackrabbit and Oak are tightly related it makes sense to think out a
joint roadmap.

A year is approaching since we released Oak 1.4 and with the team we
spoke about possible dates for the releases.

Here's the proposal. Dates are tentative as we always aim for quality
rather than date and may slip here and there according to the situation.

5th Dec
  - Release Oak 1.5.15
  - Commit slow down and risk control starting on Oak and Jackrabbit

9th Jan:
  - Branch and release Jackrabbit 2.14.0
  - Consequently update Oak to such version

16th Jan:
  - Release Oak 1.5.18
  - It should include JR 2.14.0+

30th Jan
  - Branch and release Oak 1.6.0
  - Bi-Weekly unstable cut temporary suspended while we focus on
stabilisation.
  - Oak 1.8, 1.7.x development cycle commence

Cheers
Davide

Re: svn commit: r1772167 - /jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryShapeTool.java

2016-12-01 Thread Francesco Mari 
Would it make sense to make this part of oak-run instead?

2016-12-01 11:59 GMT+01:00  :
> Author: thomasm
> Date: Thu Dec  1 10:59:55 2016
> New Revision: 1772167
>
> URL: http://svn.apache.org/viewvc?rev=1772167=rev
> Log:
> OAK-1884 Query: log file analyzer tool
>
> Added:
> 
> jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryShapeTool.java
>
> Added: 
> jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryShapeTool.java
> URL: 
> http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryShapeTool.java?rev=1772167=auto
> ==
> --- 
> jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryShapeTool.java
>  (added)
> +++ 
> jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryShapeTool.java
>  Thu Dec  1 10:59:55 2016
> @@ -0,0 +1,92 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.jackrabbit.oak.query;
> +
> +import java.io.BufferedReader;
> +import java.io.File;
> +import java.io.FileReader;
> +import java.io.IOException;
> +import java.io.LineNumberReader;
> +import java.util.TreeSet;
> +
> +/**
> + * A tool that converts a list of queries to parameterized queries. This for
> + * example allows to extract unique queries.
> + */
> +public class QueryShapeTool {
> +
> +public static void main(String... args) throws IOException {
> +process(new File(args[0]));
> +}
> +
> +public static void process(File file) throws IOException {
> +processFile(file);
> +}
> +
> +private static void processFile(File file) throws IOException {
> +if (file.isDirectory()) {
> +for (File f : file.listFiles()) {
> +processFile(f);
> +}
> +return;
> +}
> +System.out.println("File " + file);
> +LineNumberReader r = new LineNumberReader(new BufferedReader(
> +new FileReader(file)));
> +try {
> +process(r);
> +} finally {
> +r.close();
> +}
> +System.out.println();
> +}
> +
> +private static void process(LineNumberReader reader) throws IOException {
> +TreeSet sortedUnique = new  TreeSet();
> +while (true) {
> +String line = reader.readLine();
> +if (line == null) {
> +break;
> +}
> +sortedUnique.add(shape(line));
> +}
> +for (String s : sortedUnique) {
> +System.out.println(s);
> +}
> +}
> +
> +private static String shape(String query) {
> +String result = query;
> +// replace double quoted string literals with "$s"
> +result = result.replaceAll("\"[^\"]*\"", "\\$s");
> +// replace single quoted string literals with "$s"
> +result = result.replaceAll("'[^\']*\'", "\\$s");
> +// replace repeated "$s" with a single one (due to escape characters 
> in string literals)
> +result = result.replaceAll("(\\$s)+", "\\$s");
> +
> +// xpath: replace "//" with "/ /" so we can more easily stop there
> +result = result.replaceAll("//", "/ /");
> +// xpath: replace "/element(" with "/ element" for the same reason
> +result = result.replaceAll("/element\\(", "/ element\\(");
> +// xpath: replace "/text(" with "/ text" for the same reason
> +result = result.replaceAll("/text\\(", "/ text\\(");
> +// xpath: replace a path at the beginning of the query with $path
> +result = result.replaceAll("/jcr:root(/([^ /]*))*[ /]", 
> "/jcr:root/\\$path/");
> +return result;
> +}
> +
> +}
> \ No newline at end of file
>
>