exist-open — Open discussion

Re: [Exist-open] Ignore processing instructions in indexing

[Stefan D. <du...@bb...>]

Hi Dannes,

here is the index configuration:

https://gist.github.com/StefanDumont/0ab72c24e069f2231ac28bf8cff0b90e

Everything works fine exept that obviously text in an Oxygen Processing 
Instruction is indexed and found by ft:query(). Checking again the 
problem, I also found out, that the problem occurs only, when I use a 
wildcard in ft:query() (with XML syntax). When I search for the specific 
word ("Natural" vs "Natur*") there is no search result (i.e. correct 
behaviour).

Thanks

Stefan

Am 15.05.2022 um 18:29 schrieb Dannes Wessels:
> Hi,
> 
> Please could you share your index configuration?
> 
> Cheers
> 
> Dannes
> 
>> On 11 May 2022, at 20:36, Stefan Dumont <du...@bb...> wrote:
>>
>> Hi all,
>>
>> since we're using Oxygen XML Author for editing our TEI-XML, the editors also use the possibility to comment (temporarily) the edited text. Oxygen stores these comments as XML Processing Instructions (PI) in the TEI-XML. Of course, we don't want to show them. But by indexing text with the lucene index these PIs are also indexed and therefore will be find by ft:query(). Is there a way to ignore them for indexing like other elements? I didn't find a way ...
>>
>> Thanks for hints & kind regards
>>
>> Stefan
>>
>> -- 
>> Berlin-Brandenburgische Akademie der Wissenschaften
>> TELOTA - Digital Humanities
>> Jägerstraße 22/23
>> 10117 Berlin
>>
>> Tel.: 030 / 20 370 -492
>> du...@bb...
>> http://www.bbaw.de/die-akademie/mitarbeiter/dumont
>> http://www.bbaw.de/telota
>>
>>
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open

-- 
Berlin-Brandenburgische Akademie der Wissenschaften
TELOTA - Digital Humanities
Jägerstraße 22/23
10117 Berlin

Tel.: 030 / 20 370 -492
du...@bb...
http://www.bbaw.de/die-akademie/mitarbeiter/dumont
http://www.bbaw.de/telota

Re: [Exist-open] Ignore processing instructions in indexing

[Dannes W. <di...@ex...>]

Hi,

Please could you share your index configuration?

Cheers

Dannes

> On 11 May 2022, at 20:36, Stefan Dumont <du...@bb...> wrote:
> 
> Hi all,
> 
> since we're using Oxygen XML Author for editing our TEI-XML, the editors also use the possibility to comment (temporarily) the edited text. Oxygen stores these comments as XML Processing Instructions (PI) in the TEI-XML. Of course, we don't want to show them. But by indexing text with the lucene index these PIs are also indexed and therefore will be find by ft:query(). Is there a way to ignore them for indexing like other elements? I didn't find a way ...
> 
> Thanks for hints & kind regards
> 
> Stefan
> 
> -- 
> Berlin-Brandenburgische Akademie der Wissenschaften
> TELOTA - Digital Humanities
> Jägerstraße 22/23
> 10117 Berlin
> 
> Tel.: 030 / 20 370 -492
> du...@bb...
> http://www.bbaw.de/die-akademie/mitarbeiter/dumont
> http://www.bbaw.de/telota
> 
> 
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] Java Admin Client - Credentials from file system?

[Florian S. <ml-...@fl...>]

Hi Michael,

great, thanks a lot!

Kind Regards
Florian

Am 12.05.22 um 20:56 schrieb Michael Joyce:
> Hi Florian,
> 
> Here’s an example of how I do it:
> 
> https://gist.github.com/ubermichael/beff98fc0b939788c908ac75b149d35c
> 
> We have one .properties file for each eXistDB instance. The example defaults to using localhost, but using other hosts is quite easy: `ant -Dhost=foo fetch` will download all of the data from the host defined in foo.properties.
> 
> For your question, the store-reports ant target is probably the closest to what you’re trying to do.
> 
> Michael
> 

Re: [Exist-open] Java Admin Client - Credentials from file system?

[Michael J. <ube...@gm...>]

Hi Florian,

Here’s an example of how I do it:

https://gist.github.com/ubermichael/beff98fc0b939788c908ac75b149d35c

We have one .properties file for each eXistDB instance. The example defaults to using localhost, but using other hosts is quite easy: `ant -Dhost=foo fetch` will download all of the data from the host defined in foo.properties.

For your question, the store-reports ant target is probably the closest to what you’re trying to do.

Michael 


> On May 11, 2022, at 12:01 PM, Florian Schmitt <mai...@fl...> wrote:
> 
> Hi Michael,
> 
> thanks a lot, that sounds very interesting! I didn't use ant yet, but i'll give it a try. An example would be great and highly appreciated!
> 
> In the meanwhile, i've tested using curl with HTTP PUT. This seems to work nicely for smaller files, but i encounter problems with bigger XML resources. Thus, ant may be a better solution.
> 
> Florian
> 
> Am 11.05.2022 um 19:13 schrieb Michael Joyce:
>> Hello Florian,
>> This isn’t quite an answer to your question, but may be of some help.
>> We use an ant build.xml file to handle large imports, following the documentation in http://exist-db.org/exist/apps/doc/ant-tasks . That ant script reads a properties file with the credentials and other information.
>> I can provide an example for you, if you’d like.
>> Michael

Re: [Exist-open] Java Admin Client - Credentials from file system?

[Joe W. <jo...@gm...>]

See also the node-exist project, at https://github.com/eXist-db/node-exist.
In particular, Juri's https://github.com/eXist-db/node-exist/pull/202 added
a nice command-line method for uploading documents to eXist.

On Wed, May 11, 2022 at 3:06 PM <ml-...@fl...>
wrote:

> Hi Michael,
>
> thanks a lot, that sounds very interesting! I didn't use ant yet, but
> i'll give it a try. An example would be great and highly appreciated!
>
> In the meanwhile, i've tested using curl with HTTP PUT. This seems to
> work nicely for smaller files, but i encounter problems with bigger XML
> resources. Thus, ant may be a better solution.
>
> Florian
>
> Am 11.05.2022 um 19:13 schrieb Michael Joyce:
> > Hello Florian,
> >
> > This isn’t quite an answer to your question, but may be of some help.
> >
> > We use an ant build.xml file to handle large imports, following the
> documentation in http://exist-db.org/exist/apps/doc/ant-tasks . That ant
> script reads a properties file with the credentials and other information.
> >
> > I can provide an example for you, if you’d like.
> >
> > Michael
> >
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] Java Admin Client - Credentials from file system?

[<ml-...@fl...>]

Hi Michael,

thanks a lot, that sounds very interesting! I didn't use ant yet, but 
i'll give it a try. An example would be great and highly appreciated!

In the meanwhile, i've tested using curl with HTTP PUT. This seems to 
work nicely for smaller files, but i encounter problems with bigger XML 
resources. Thus, ant may be a better solution.

Florian

Am 11.05.2022 um 19:13 schrieb Michael Joyce:
> Hello Florian,
> 
> This isn’t quite an answer to your question, but may be of some help.
> 
> We use an ant build.xml file to handle large imports, following the documentation in http://exist-db.org/exist/apps/doc/ant-tasks . That ant script reads a properties file with the credentials and other information.
> 
> I can provide an example for you, if you’d like.
> 
> Michael
> 

Re: [Exist-open] Java Admin Client - Credentials from file system?

[Florian S. <mai...@fl...>]

Hi Michael,

thanks a lot, that sounds very interesting! I didn't use ant yet, but 
i'll give it a try. An example would be great and highly appreciated!

In the meanwhile, i've tested using curl with HTTP PUT. This seems to 
work nicely for smaller files, but i encounter problems with bigger XML 
resources. Thus, ant may be a better solution.

Florian

Am 11.05.2022 um 19:13 schrieb Michael Joyce:
> Hello Florian,
> 
> This isn’t quite an answer to your question, but may be of some help.
> 
> We use an ant build.xml file to handle large imports, following the documentation in http://exist-db.org/exist/apps/doc/ant-tasks . That ant script reads a properties file with the credentials and other information.
> 
> I can provide an example for you, if you’d like.
> 
> Michael
> 

[Exist-open] Ignore processing instructions in indexing

[Stefan D. <du...@bb...>]

Hi all,

since we're using Oxygen XML Author for editing our TEI-XML, the editors 
also use the possibility to comment (temporarily) the edited text. 
Oxygen stores these comments as XML Processing Instructions (PI) in the 
TEI-XML. Of course, we don't want to show them. But by indexing text 
with the lucene index these PIs are also indexed and therefore will be 
find by ft:query(). Is there a way to ignore them for indexing like 
other elements? I didn't find a way ...

Thanks for hints & kind regards

Stefan

-- 
Berlin-Brandenburgische Akademie der Wissenschaften
TELOTA - Digital Humanities
Jägerstraße 22/23
10117 Berlin

Tel.: 030 / 20 370 -492
du...@bb...
http://www.bbaw.de/die-akademie/mitarbeiter/dumont
http://www.bbaw.de/telota

Re: [Exist-open] Java Admin Client - Credentials from file system?

[Michael J. <ube...@gm...>]

Hello Florian,

This isn’t quite an answer to your question, but may be of some help.

We use an ant build.xml file to handle large imports, following the documentation in http://exist-db.org/exist/apps/doc/ant-tasks . That ant script reads a properties file with the credentials and other information.

I can provide an example for you, if you’d like.

Michael

> On May 9, 2022, at 3:13 AM, Florian Schmitt <ml-...@fl...> wrote:
> 
> Hi all,
> 
> is there a different way to provide authentication credentials to the Java Admin Client other than the command line parameters, e.g. read the user credentials from the file system? My use case is writing a bash script to import some resources into eXist using the Java Admin Client. Currently, the only way to authenticate seems to be using the command line parameters -u and -P, providing the db user credentials in clear text in the bash script. This is quite ugly. Other tools, e.g. cUrl, allow for using .netrc files with appropriate access rights. Is something similar available fot the command line client? What's the best practice for this use case?
> 
> Thanks in advance!
> Florian
> 
> 
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

[Exist-open] Java Admin Client - Credentials from file system?

[Florian S. <ml-...@fl...>]

Hi all,

is there a different way to provide authentication credentials to the 
Java Admin Client other than the command line parameters, e.g. read 
the user credentials from the file system? My use case is writing a 
bash script to import some resources into eXist using the Java Admin 
Client. Currently, the only way to authenticate seems to be using the 
command line parameters -u and -P, providing the db user credentials 
in clear text in the bash script. This is quite ugly. Other tools, 
e.g. cUrl, allow for using .netrc files with appropriate access 
rights. Is something similar available fot the command line client? 
What's the best practice for this use case?

Thanks in advance!
Florian

[Exist-open] Java Admin Client - Credentials from file system?

[Florian S. <mai...@fl...>]

Hi all,

is there a different way to provide authentication credentials to the 
Java Admin Client other than the command line parameters, e.g. read 
the user credentials from the file system? My use case is writing a 
bash script to import some resources into eXist using the Java Admin 
Client. Currently, the only way to authenticate seems to be using the 
command line parameters -u and -P, providing the db user credentials 
in clear text in the bash script. This is quite ugly. Other tools, 
e.g. cUrl, allow for using .netrc files with appropriate access 
rights. Is something similar available fot the command line client? 
What's the best practice for this use case?

Thanks in advance!
Florian

Re: [Exist-open] eXist on AWS

[Nick S. <nsi...@nu...>]

We also have eXist-db running on EC2. No issues.

Nick

On 5/2/22 6:43 AM, Roy Walter via Exist-open wrote:
> Hi Alfredo,
>
> We have eXist running on Lightsail and EC2. No issues.
>
> Regards,
> Roy
> On 2 May 2022, 12:43 +0100, Alfredo Cosco <alf...@gm...>, 
> wrote:
>> Hello,
>> has anyone experienced installing exist-db on AWS?
>> Works well?
>> Can there be processes that start off by grinding costs?
>> Any info is appreciated.
>> Thanks,
>> Alfredo
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

-- 
Nick Sincaglia
President/Founder
NueMeta, LLC
Digital Media & Technology
Phone: +1-630-303-7035
nsi...@nu...  
http://www.nuemeta.com
Skype: nsincaglia

Re: [Exist-open] eXist on AWS

[Roy W. <gar...@ya...>]

Hi Alfredo,

We have eXist running on Lightsail and EC2. No issues.

Regards,
Roy
On 2 May 2022, 12:43 +0100, Alfredo Cosco <alf...@gm...>, wrote:
> Hello,
> has anyone experienced installing exist-db on AWS?
> Works well?
> Can there be processes that start off by grinding costs?
> Any info is appreciated.
> Thanks,
> Alfredo
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

[Exist-open] eXist on AWS

[Alfredo C. <alf...@gm...>]

Hello,
has anyone experienced installing exist-db on AWS?
Works well?
Can there be processes that start off by grinding costs?
Any info is appreciated.
Thanks,
Alfredo

Re: [Exist-open] file:directory-list() super slow

[Joe W. <jo...@gm...>]

Hey Len,

There have been changes to the code involving the directory-list function
after 5.2.0 that were included in 5.3.0:


https://github.com/eXist-db/exist/commits/develop/extensions/modules/file/src/main/java/org/exist/xquery/modules/file/DirectoryList.java

I don't suppose you know how to use git bisect? You could use this tool to
find out which of the commits are associated with the performance
regression.

Joe

On Fri, Apr 29, 2022 at 8:05 PM Len Schultz <le...@wi...> wrote:

> Hello,
>
> file:directory-list(’/slowdir’,’*.*') has been super slow.  ‘/slowdir’ is
> a small directory on my workstation’s flash drive.  This directory does
> contain some symbolic links to large directories on the large external disk
> drives, so it does appear to be traversing down the directory tree.  Every
> time I run it, my large external drives are thrashing.  That explains why
> it’s slow.
>
>
> https://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/file
>  states:
>
> List all files, including their file size and modification time, found in *or
> below* a directory, $directory. Files are located in the server's file
> system, using filename patterns, $pattern. File pattern matching is based
> on code from Apache's Ant, thus following the same conventions. For
> example: '*.xml' matches any file ending with .xml *in the current
> directory*, - '**/*.xml' matches files in any directory *below the
> specified directory*. This method is only available to the DBA role.
>
>
> So my $pattern is only matching the current directory, but exist-db is
> still scanning all subdirectories.  Any ideas of how I can avoid it
> scanning subdirectories?
>
> I’m running exist-db 5.3.  I swear this was fast with 5.2, so maybe
> something changed in the code where it now always scans subdirectories?
> But my subdirectories have gotten much larger over time, so maybe that’s
> the difference.
>
> --len
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

[Exist-open] file:directory-list() super slow

[Len S. <le...@wi...>]

Hello,

file:directory-list(’/slowdir’,’*.*') has been super slow.  ‘/slowdir’ is a small directory on my workstation’s flash drive.  This directory does contain some symbolic links to large directories on the large external disk drives, so it does appear to be traversing down the directory tree.  Every time I run it, my large external drives are thrashing.  That explains why it’s slow.

https://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/file states:

List all files, including their file size and modification time, found in or below a directory, $directory. Files are located in the server's file system, using filename patterns, $pattern. File pattern matching is based on code from Apache's Ant, thus following the same conventions. For example: '*.xml' matches any file ending with .xml in the current directory, - '**/*.xml' matches files in any directory below the specified directory. This method is only available to the DBA role.

So my $pattern is only matching the current directory, but exist-db is still scanning all subdirectories.  Any ideas of how I can avoid it scanning subdirectories?

I’m running exist-db 5.3.  I swear this was fast with 5.2, so maybe something changed in the code where it now always scans subdirectories?  But my subdirectories have gotten much larger over time, so maybe that’s the difference.

--len

Re: [Exist-open] Debugging XSL containing xmldb:exist:/// with oXygen

[Len S. <le...@wi...>]

We are close.

If I rewrite the XSL to:

  <xsl:variable name=“file" select="doc('oxygen:/eXist-db%20localhost$eXist-db%20localhost/db/file.xml')"/>

Then it does successfully load the file.  But the catalog step still results in an error, as it doesn’t appear to be changing the URL:

System ID: oxygen:/eXist-db localhost$eXist-db localhost/db/test.xsl
Severity: fatal
Description: Exception thrown by URIResolver: Malformed URL xmldb:exist:///db/file.xml(base oxygen:/eXist-db%20localhost$eXist-db%20localhost/db/test.xsl): unknown protocol: xmldb
Start location: 12:41
Length: 1

Note, this is the same error that was generated before doing the catalog step.

I tried changing the catalog.xml to this, and this did work:

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<rewriteURI uriStartString="xmldb:exist:///db/" rewritePrefix="oxygen:/eXist-db%20localhost$eXist-db%20localhost/db/"/>
</catalog>

So delegateURI did not work, but rewriteURI did work.

Thanks for the pointers!

--len

On Apr 1, 2022, at 12:14 AM, Radu Coravu via Exist-open <exi...@li...<mailto:exi...@li...>> wrote:


Hi Len,

This may not work, but here it goes:

Open in Oxygen XML Editor an XML file from the Exist repository (I assume you have configured the Exist repository as a datasource connection in Oxygen).

Right click on the opened XML file's tab and choose "Copy Location", then paste it in a text editor, the pasted URL should look like this:

oxygen:/..../db/path/to/file.xml
Then you can create somewhere on disk a "catalog.xml" file having the content something like:


<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
    <delegateURI uriStartString="xmldb:exist:///db/" catalog="oxygen:/..../db/"/>
</catalog>
And in the Oxygen Preferences->"XML Catalogs" page add a reference to this new "catalog.xml" file.


The main idea is that the Saxon XSLT processor resolves doc() paths through the XML catalog "uri" mappings to the corresponding Oxygen repository URL and is thus able to retrieve the XML file to access it.

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 4/1/22 05:59, Len Schultz wrote:
I have an XSL stylesheet which accesses files in eXist, e.g.:

<xsl:variable name=“file" select="doc('xmldb:exist:///db/file.xml')"/>

This runs well when live, but when I debug the XSL code via oXygen, it cannot access the file in existdb.  I can work around it not getting the data from the database, but I can’t work around it failing and not executing the rest of my XSL code.  What are some methods you all use to debug XSL code that has lines like this via oXygen?  The only workaround I found is to comment out that line so I can debug the rest of the code, but I’d love something more graceful.

--len





_______________________________________________
Exist-open mailing list
Exi...@li...<mailto:Exi...@li...>
https://lists.sourceforge.net/lists/listinfo/exist-open


_______________________________________________
Exist-open mailing list
Exi...@li...<mailto:Exi...@li...>
https://lists.sourceforge.net/lists/listinfo/exist-open

[Exist-open] How to backup User Manager's created Users and Groups?

[Alessandro <ca...@tu...>]

Hi all,
I hope this is not a too silly newbie question, but how could I backup the created Users and Groups in User Manager app, so that I do not need to re-create them each time I make a new exist-db installation?
Many thanks
Alex
-- 
 Inviato con Tutanota, la mailbox sicura e senza pubblicità. 

[Exist-open] Exist 4.7.1 corrupts its database

[<sep...@fu...>]

We have eXists 4.7.1 running in master-slave mode in windows environment. For a reason unknown to us it sometimes corrupts itself, and goes into inconsistent state. Inconsistent is replicated to slave as well. To us our only mitigation is to completely recover from backups whole database. This happens from time to time.

Steps done before crash:

  1.  User checks the record for modifications
  2.  User modifies the record
  3.  User saves the record.
  4.  In DB we can see that saving is started. There is lot of warnings for 'document not locked for write !' in DB, assumption is that this refers the copied reford files.
  5.  However, the saved record and it's elements are replicated to slave. Interestingly, the owner in slave files seems to be SYSTEM instead of admin
  6.  Something goes wrong in master - after that the RCP calls start to throw indefinete loop errors (see copy-paste at the end)
  7.  This indefinete looping seems to cause db to go inconsistent state.

Is there any hint's what is going on and how to prevent this from happening?

eXists log where errors start to happen:
2022-02-01 14:42:53,800 [qtp807053698-292480] INFO  (ReplicationTrigger.java [afterCreateCollection]:228) - Create collection '/db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761'
2022-02-01 14:42:53,821 [qtp807053698-292480] INFO  (ReplicationTrigger.java [afterCreateCollection]:228) - Create collection '/db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS'
2022-02-01 14:42:53,913 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,017 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,020 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,036 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,040 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,044 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,122 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,132 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,134 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,143 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,147 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,149 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,848 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,977 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:54,999 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,002 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,018 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,028 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,036 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,118 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,131 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,151 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,165 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,333 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,384 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,395 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,402 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,520 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,732 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,761 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:55,765 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,444 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,449 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,484 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,490 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,493 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,500 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,535 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,539 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,704 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,711 [qtp807053698-292480] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,712 [qtp807053698-292480] INFO  (ReplicationTrigger.java [afterCopyCollection]:291) - Copy collection from '/db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1639466517762/TOSELEMENTS' to '/db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS'
2022-02-01 14:42:56,751 [qtp807053698-292426] WARN  (DocumentImpl.java [write]:466) - document not locked for write !
2022-02-01 14:42:56,751 [qtp807053698-292426] INFO  (ReplicationTrigger.java [afterCopyDocument]:148) - Copy document from '/db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1639466517762/tos.xml' to '/db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/tos.xml'
2022-02-01 14:42:56,809 [qtp807053698-292531] ERROR (NativeBroker.java [openCollection]:914) - The collection received from the cache is not the requested: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS; received: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761
2022-02-01 14:42:56,812 [qtp807053698-292426] ERROR (NativeBroker.java [openCollection]:914) - The collection received from the cache is not the requested: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS; received: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761
2022-02-01 14:42:56,812 [qtp807053698-292426] WARN  (TransactionManager.java [close]:389) - Transaction was not committed or aborted, auto aborting!
2022-02-01 14:42:56,820 [qtp807053698-292531] ERROR (NativeBroker.java [openCollection]:914) - The collection received from the cache is not the requested: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS; received: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761
2022-02-01 14:42:56,821 [qtp807053698-292531] ERROR (NativeBroker.java [openCollection]:914) - The collection received from the cache is not the requested: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS; received: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761
2022-02-01 14:42:56,821 [qtp807053698-292531] ERROR (NativeBroker.java [openCollection]:914) - The collection received from the cache is not the requested: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS; received: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761
2022-02-01 14:42:56,822 [qtp807053698-292531] ERROR (NativeBroker.java [openCollection]:914) - The collection received from the cache is not the requested: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS; received: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761
2022-02-01 14:42:56,822 [qtp807053698-292531] ERROR (NativeBroker.java [openCollection]:914) - The collection received from the cache is not the requested: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761/TOSELEMENTS; received: /db/TOSAPP/TOS3/1.2.246.10.22886666/CODE/INTERNAL/PUBLISHED/1643719373761

The stack trace:
2022-02-01 14:42:53,484 [qtp807053698-292426] INFO  (RpcConnection.java [doQuery]:257) - query took 0ms.
2022-02-01 14:42:53,534 [qtp807053698-292211] INFO  (RpcConnection.java [doQuery]:257) - query took 0ms.
2022-02-01 14:42:53,566 [qtp807053698-292508] INFO  (RpcConnection.java [doQuery]:257) - query took 0ms.
2022-02-01 14:42:53,583 [qtp807053698-292480] INFO  (RpcConnection.java [doQuery]:257) - query took 0ms.
2022-02-01 14:42:53,756 [qtp807053698-292531] INFO  (RpcConnection.java [doQuery]:257) - query took 0ms.
2022-02-01 14:42:53,811 [qtp807053698-292480] INFO  (RpcConnection.java [doQuery]:257) - query took 12ms.
2022-02-01 14:42:56,714 [qtp807053698-292480] INFO  (RpcConnection.java [doQuery]:257) - query took 2894ms.
2022-02-01 14:42:56,755 [qtp807053698-292426] INFO  (RpcConnection.java [doQuery]:257) - query took 11ms.
2022-02-01 14:42:58,022 [qtp807053698-292531] ERROR (XmlRpcErrorLogger.java [log]:36) - Failed to invoke method queryPT in class org.exist.xmlrpc.RpcConnection: null
org.apache.xmlrpc.common.XmlRpcInvocationException: Failed to invoke method queryPT in class org.exist.xmlrpc.RpcConnection: null
                             at org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.invoke(ReflectiveXmlRpcHandler.java:129) ~[xmlrpc-server-3.1.3.jar:3.1.3]
                             at org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.execute(ReflectiveXmlRpcHandler.java:106) ~[xmlrpc-server-3.1.3.jar:3.1.3]
                             at org.apache.xmlrpc.server.XmlRpcServerWorker.execute(XmlRpcServerWorker.java:46) ~[xmlrpc-server-3.1.3.jar:3.1.3]
                             at org.apache.xmlrpc.server.XmlRpcServer.execute(XmlRpcServer.java:86) ~[xmlrpc-server-3.1.3.jar:3.1.3]
                             at org.apache.xmlrpc.server.XmlRpcStreamServer.execute(XmlRpcStreamServer.java:200) [xmlrpc-server-3.1.3.jar:3.1.3]
                             at org.apache.xmlrpc.webserver.XmlRpcServletServer.execute(XmlRpcServletServer.java:112) [xmlrpc-server-3.1.3.jar:3.1.3]
                             at org.apache.xmlrpc.webserver.XmlRpcServlet.doPost(XmlRpcServlet.java:196) [xmlrpc-server-3.1.3.jar:3.1.3]
                             at org.exist.xmlrpc.RpcServlet.doPost(RpcServlet.java:99) [exist.jar:4.7.1]
                             at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [servlet-api-3.1.jar:3.1.0]
                             at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [servlet-api-3.1.jar:3.1.0]
                             at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:867) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:566) [jetty-security-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:168) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:78) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.exist.http.urlrewrite.Forward.doRewrite(Forward.java:51) [exist-optional.jar:4.7.1]
                             at org.exist.http.urlrewrite.XQueryURLRewrite.service(XQueryURLRewrite.java:206) [exist-optional.jar:4.7.1]
                             at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [servlet-api-3.1.jar:3.1.0]
                             at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:859) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) [jetty-security-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.Server.handle(Server.java:502) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
                             at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
Caused by: java.lang.StackOverflowError
                             at java.lang.ThreadLocal$ThreadLocalMap.getEntry(ThreadLocal.java:419) ~[?:1.8.0_201]
                             at java.lang.ThreadLocal$ThreadLocalMap.access$000(ThreadLocal.java:298) ~[?:1.8.0_201]
                             at java.lang.ThreadLocal.get(ThreadLocal.java:163) ~[?:1.8.0_201]
                             at org.apache.logging.log4j.core.config.AppenderControl.isRecursiveCall(AppenderControl.java:104) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.core.config.AppenderControl.shouldSkip(AppenderControl.java:88) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:81) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:448) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:433) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:403) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146) ~[log4j-core-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2170) ~[log4j-api-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2125) ~[log4j-api-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2108) ~[log4j-api-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2002) ~[log4j-api-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1974) ~[log4j-api-2.11.0.jar:2.11.0]
                             at org.apache.logging.log4j.spi.AbstractLogger.error(AbstractLogger.java:731) ~[log4j-api-2.11.0.jar:2.11.0]
                             at org.exist.storage.NativeBroker.openCollection(NativeBroker.java:914) ~[exist.jar:4.7.1]
                             at org.exist.storage.NativeBroker.openCollection(NativeBroker.java:771) ~[exist.jar:4.7.1]
                             at org.exist.storage.NativeBroker.removeCollection(NativeBroker.java:1392) ~[exist.jar:4.7.1]
                             at org.exist.storage.NativeBroker.removeCollection(NativeBroker.java:1394) ~[exist.jar:4.7.1]   .... //This line repeats recursively to the end

Re: [Exist-open] Debugging XSL containing xmldb:exist:/// with oXygen

[Radu C. <rad...@sy...>]

Hi Len,

This may not work, but here it goes:

Open in Oxygen XML Editor an XML file from the Exist repository (I 
assume you have configured the Exist repository as a datasource 
connection in Oxygen).

Right click on the opened XML file's tab and choose "Copy Location", 
then paste it in a text editor, the pasted URL should look like this:

> oxygen:/..../db/path/to/file.xml
Then you can create somewhere on disk a "catalog.xml" file having the 
content something like:

> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
>     <delegateURI uriStartString="xmldb:exist:///db/" 
> catalog="oxygen:/..../db/"/>
> </catalog>
And in the Oxygen Preferences->"XML Catalogs" page add a reference to 
this new "catalog.xml" file.

The main idea is that the Saxon XSLT processor resolves doc() paths 
through the XML catalog "uri" mappings to the corresponding Oxygen 
repository URL and is thus able to retrieve the XML file to access it.

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 4/1/22 05:59, Len Schultz wrote:
> I have an XSL stylesheet which accesses files in eXist, e.g.:
>
> <xsl:variable name=“file" select="doc('xmldb:exist:///db/file.xml')"/>
>
> This runs well when live, but when I debug the XSL code via oXygen, it 
> cannot access the file in existdb.  I can work around it not getting 
> the data from the database, but I can’t work around it failing and not 
> executing the rest of my XSL code.  What are some methods you all use 
> to debug XSL code that has lines like this via oXygen?  The only 
> workaround I found is to comment out that line so I can debug the rest 
> of the code, but I’d love something more graceful.
>
> --len
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

[Exist-open] Debugging XSL containing xmldb:exist:/// with oXygen

[Len S. <le...@wi...>]

I have an XSL stylesheet which accesses files in eXist, e.g.:

<xsl:variable name=“file" select="doc('xmldb:exist:///db/file.xml')"/>

This runs well when live, but when I debug the XSL code via oXygen, it cannot access the file in existdb.  I can work around it not getting the data from the database, but I can’t work around it failing and not executing the rest of my XSL code.  What are some methods you all use to debug XSL code that has lines like this via oXygen?  The only workaround I found is to comment out that line so I can debug the rest of the code, but I’d love something more graceful.

--len

[Exist-open] How do I add the path to a pem file in HttpClient?

[Loren C. <lor...@gm...>]

I have a client that is utilizing internal certificates.  I want to be placing a HTTP call to resources within the client organization through hc:send-request, but I need to attach a PEM to the SSL context.

I am currently getting ERROR PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certificate to requested target.

Is there a place for me to store the PEM file for the http-client to utilize or is there a header that I can utilize to add it?


For my localhost:
eXist-db version 6.0.0
Java 11.0.7
Mac OS 11.6.4

Thank you!

Re: [Exist-open] eXist redundancy

[Joe W. <jo...@gm...>]

Hi Sava,

The eXist-db Messaging-Replication extension provides that facility. See
https://github.com/eXist-db/messaging-replication/wiki.

Joe

On Mon, Mar 21, 2022 at 6:20 PM <sju...@mr...> wrote:

> Hi All,
>
> just looking for some guidance how to setup and configure eXist in Master
> --> Slave environment.
>
> Basically, I would like to have the exact copy of the DB on separate
> hardware.
>
> It will not be used in day-to-day operations, but if the main server goes
> "kaput", we can quickly replace it with the slave system.
>
> Any hint is much appreciated.
>
> Cheers,
>
> Sava
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

[Exist-open] eXist redundancy

[<sju...@mr...>]

 

Hi All, 

just looking for some guidance how to setup and configure eXist in
Master --> Slave environment. 

Basically, I would like to have the exact copy of the DB on separate
hardware. 

It will not be used in day-to-day operations, but if the main server
goes "kaput", we can quickly replace it with the slave system. 

Any hint is much appreciated. 

Cheers, 

Sava 
  

Re: [Exist-open] Lucene search issue with existed 2.1

[Areki, A. <aa...@ri...>]

Much appreciation and thank you, Joe.
The following param works in existdb 2.1

<param name="stopwords" type="java.util.Set">

<!--<value>a</value>-->
</param>
Thanks again
ALEM
--
Alem T. Areki
Senior Web Developer – Web Services
University of Richmond
phone: 804-289-8899 | Fax: 804-289-8988

Please send technical questions or requests to we...@ri...<mailto:we...@ri...> and not to individuals if at all possible.

Thank you for your email!  Someone from Web Services will contact you regarding your request by the end of the next business day.

To submit technical support requests or defect reports please use the SpiderTechNet System:
https://spidertechnet.richmond.edu/TDClient/1955/Portal/Requests/ServiceCatalog?CategoryID=12767

For other Technology Questions and Issues visit: https://spidertechnet.richmond.edu/



From: Joe Wicentowski <jo...@gm...>
Date: Friday, March 18, 2022 at 3:00 PM
To: "Areki, Alem" <aa...@ri...>
Cc: "exi...@li..." <exi...@li...>
Subject: Re: [Exist-open] Lucene search issue with existed 2.1

External Email: Use caution in opening links, attachments, and buying gift cards.

Hi Alem,

The customized stopwords feature I described was added in eXist 1.4.3, so it should work in 2.1 as well. See https://github.com/eXist-db/exist/commit/744d104e8bacb17da5d54cc0d17d484601346867.

Give a close look at the @type attribute on the <param> element though in the examples added in that commit: https://github.com/eXist-db/exist/commit/744d104e8bacb17da5d54cc0d17d484601346867#diff-35d71d352dd07d7f78245dc1936346e5a2db7a1908b593eda31f4e4f427d1b8dR341-R364.

Notice that it was <param type="java.util.Set">. In contrast, in the current documentation I linked to, it's <param type="org.apache.lucene.analysis.util.CharArraySet">. So perhaps for 2.1 you should use "java.util.Set."

Joe

On Fri, Mar 18, 2022 at 10:38 AM Areki, Alem <aa...@ri...<mailto:aa...@ri...>> wrote:
Thanks, Joe.

It works with my local existdb version 4.1 but not version 2.1.

thanks

--
Alem T. Areki
Senior Web Developer – Web Services
University of Richmond
phone: 804-289-8899 | Fax: 804-289-8988

Please send technical questions or requests to we...@ri...<mailto:we...@ri...> and not to individuals if at all possible.

Thank you for your email!  Someone from Web Services will contact you regarding your request by the end of the next business day.

To submit technical support requests or defect reports please use the SpiderTechNet System:
https://spidertechnet.richmond.edu/TDClient/1955/Portal/Requests/ServiceCatalog?CategoryID=12767

For other Technology Questions and Issues visit: https://spidertechnet.richmond.edu/



From: Joe Wicentowski <jo...@gm...<mailto:jo...@gm...>>
Date: Friday, March 18, 2022 at 8:57 AM
To: "Areki, Alem" <aa...@ri...<mailto:aa...@ri...>>
Cc: "exi...@li...<mailto:exi...@li...>" <exi...@li...<mailto:exi...@li...>>
Subject: Re: [Exist-open] Lucene search issue with existed 2.1

External Email: Use caution in opening links, attachments, and buying gift cards.

Hi Alem,

The words "to" and "the" are included in Lucene's default list of stopwords. They're dropped when indexing documents and ignored when querying them. To ensure these words are indexed, you have to either customize the list of stopwords or explicitly eliminate all stopwords, adding the following <param> element to the <analyzer> element in your .xconf file:

<analyzer class="org.apache.lucene.analysis.standard.StandardAnalyzer">
    <!-- Specify stop words - or remove them entirely -->
    <param name="stopwords" type="org.apache.lucene.analysis.util.CharArraySet">
        <!--<value>the</value>-->
    </param>
</analyzer>

For the list of words treated as stopwords by default in Lucene, see https://markmail.org/message/wxmtjzbskgrj2cug. Place any stopwords you want to keep in <value> elements. By omitting any <value> elements (as shown above), the you've removed all stopwords. For the current eXist docs on configuring Lucene's stopword facility, see https://exist-db.org/exist/apps/doc/lucene#conf.

Joe

On Thu, Mar 17, 2022 at 5:59 PM Areki, Alem <aa...@ri...<mailto:aa...@ri...>> wrote:
Hi all,

I am having a problem Lucene searching with stop words in between the phrase keywords

  *   The title of the article to be searched: “Where to watch: Catch the Spiders in March Madness”
  *   A searching phrase like “March Madness” works but phrases like “Where to Watch” or “Catch the Spiders” don’t work.
  *   Searching the phrases doesn’t work has stopwords in between them.

Does anyone have any clue why I am having this issue?

Thanks
Alem
--
Alem T. Areki
Senior Web Developer – Web Services
University of Richmond

_______________________________________________
Exist-open mailing list
Exi...@li...<mailto:Exi...@li...>
https://lists.sourceforge.net/lists/listinfo/exist-open