exist-open — Open discussion

Re: [Exist-open] Lucene custom analyzer

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

Hi,

I think you need to register the jar in EXIST_HOME/etc/launcher.xml 

Cheers

Dannes


> On 4 Dec 2024, at 12:55, Irene Vagionakis <ire...@pa...bh> wrote:
> 
> 
> Hi there!
>  
> I am trying to add a custom Lucene analyzer that behaves like the WhitespaceAnalyzer concerning tokenization and (lack of) stemming, but that is also case-insensitive (basically the same of https://sourceforge.net/p/exist/mailman/message/35188378/).
>  
> I followed what suggested in the post thread above, that is writing the custom analyzer, compiling its class as JAR and saving it in $EXIST_HOME/lib/user, but it is not working. I tried also putting it in the same folder of the other Lucene JAR files, but the same.
>  
> Since both my Java/Lucene and eXist-db knowledge are quite poor, I am struggling to figure out whether the problem concerns my code or has to do with eXist-db itself. 
>  
> This is my custom analyzer code:
>  
> package org.custom;
> import org.apache.lucene.analysis.Analyzer;
> import org.apache.lucene.analysis.TokenStream;
> import org.apache.lucene.analysis.core.LowerCaseFilter;
> import org.apache.lucene.analysis.core.WhitespaceTokenizer;
> public class CaseInsensitiveWhitespaceAnalyzer extends Analyzer {
>     @Override
>     protected TokenStreamComponents createComponents(String fieldName) {
>         final WhitespaceTokenizer source = new WhitespaceTokenizer();
>         final TokenStream filter = new LowerCaseFilter(source);
>         return new TokenStreamComponents(source, filter);
>     }
> }
>  
> And this is how I reference to it in collection.xconf:
> <analyzer id="custom" class="org.custom.CaseInsensitiveWhitespaceAnalyzer"/>
>  
> I also tested the analyzer outside eXist-db with the following and it returned the expected tokens:
>  
> import org.apache.lucene.analysis.Analyzer;
> import org.apache.lucene.analysis.TokenStream;
> import org.apache.lucene.analysis.tokenattributes.CharTermAttribute;
> import org.custom.CaseInsensitiveWhitespaceAnalyzer;
> import java.io.IOException;
> import java.io.StringReader;
> public class TestAnalyzer {
>     public static void main(String[] args) throws IOException {
>         String text = "Lucene is a Simple1 123 5% _test - Yet Powerful - Java Based Search Library. I love IT!";
>         Analyzer analyzer = new CaseInsensitiveWhitespaceAnalyzer();
>         try (TokenStream tokenStream = analyzer.tokenStream("field", new StringReader(text))) {
>             CharTermAttribute charTermAttribute = tokenStream.addAttribute(CharTermAttribute.class);
>             tokenStream.reset();
>             while (tokenStream.incrementToken()) {
>                 System.out.println(charTermAttribute.toString());
>             }
>             tokenStream.end();
>         }
>     }
> }
>  
> What am I doing wrong? Any suggestions/hints will be highly appreciated :)
>  
> Thanks,
> Irene
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] Exist DB Community Changes

[Adam R. <ad...@ex...>]

Hi Eduard,

Sorry to hear that this is causing you stress. I can also sympathise with
the technical issues you have raised. I already addressed some of those in
the past in FusionDB.
If you might be interested in Elemental, or you think I might be able to
help you, please don't hesitate to get in touch with me -
ad...@ev...

Kindest regards, and best wishes, Adam.

On Fri, 6 Dec 2024 at 09:54, Eduard Drenth <ed...@fr...>
wrote:

> Dear all,
>
> For our institution this all strengthens the feeling we need to reconsider
> the use of exist-db, we already felt that need because of performance, old
> java versions and libs, long standing issues, one highly complex monolithic
> solution for both database and app development, no jakarta ee compatible
> war, no atomic transactions, poor support for multiuser editing, etc.
>
> I value Xml and exist-db a lot, don't get me wrong, but our institution
> needs to make future proof choices, and I wonder whether sticking with
> exist-db is a good choice in that respect.
>
> Regards,
> Eduard
>
>
>
> Eduard Drenth, Software Architekt
>
>
> ed...@fr...
>
>
> Doelestrjitte 8
>
> 8911 DX  Ljouwert
> (058) 213 14 14
>
> +31 62 094 34 28
> https://www.fryske-akademy.nl/
> https://frysker.nl/
> https://frisian.eu/
>
> gpg:
> https://keyserver.ubuntu.com/pks/lookup?search=eduard+drenth&fingerprint=on&op=index
> ------------------------------
> *From:* Adam Retter <ad...@ex...>
> *Sent:* Monday, November 4, 2024 11:57 PM
> *To:* Craig Berry <cra...@ma...>
> *Cc:* exi...@li... <exi...@li...>
> *Subject:* Re: [Exist-open] Exist DB Community Changes
>
> Thanks for the email Craig. Whilst I am deeply surprised and upset about
> what has happened, I am also sorry that it is effecting the eXist-db users
> such as yourself that I have worked so hard for and care about.
>
> I appreciate you crunching and highlighting the numbers. For those who
> appreciate stats, a couple more for you:
>
> 1. As you say commits aren't everything. I also produced the last 22
> consecutive releases of eXist-db.
> Since 2017, of the 52 releases, I produced 75% of them. I did this unpaid.
> My company Evolved Binary also at its own expense maintains a lot of the
> technical infrastructure that is required to produce and publish releases
> of eXist-db.
> See - https://github.com/eXist-db/exist/releases
>
> 2. From your list of contributors. 8 of the other named people
> contributing to eXist-db were directed by me and paid for solely by my
> company Evolved Binary. There is also 1 more who was partially funded by my
> company. Removing me from the eXist-db project will also remove those other
> contributors too.
>
> 3. I undertook a 1 year solo project from 2017 to 2018 to fix locking and
> data corruption issues. It's not perfect still, but it was much improved.
> That code base is was what became eXist-db 5.
>
> https://evolvedbinary.com/technical-reports/exist-db/locking-and-cache-improvements/locking-and-cache-improvements-20180205.pdf
>
> https://evolvedbinary.com/technical-reports/exist-db/asymmetrical-locking/asymmetrical-locking-20180205.pdf
>
> 4. I migrated eXist-db through 3 major versions of Java. To Java 6, then
> Java 8, and then again later to Java 17. I did this unpaid.
>
> 5. I migrated eXist-db's code base from SourceForge (and Subversion) to
> GitHub (and Git), which is why we have a comprehensive and intact source
> history and can still see who has done what and when. I did this unpaid.
> Speaking of which, you can also download CSV files from the graphs of
> contributors on GitHub going back to 2003 here -
> https://github.com/eXist-db/exist/graphs/contributors. GitHub's own
> graphs are quite revealing!
> Out of sheer personal curiosity, I crunched some data myself. Considering
> only the top four contributors (as I didn't have time to crunch all the
> data available), I produced a little graph from the CSV data (attached).
> One could perhaps make the argument hat I have been the core contributor
> and maintainer of eXist-db since about 2015.
>
> Regards the future of eXist-db, I have some plans. Feel free to reach out
> to me - ad...@ev....
>
>
> [image: Screenshot 2024-11-04 at 23.48.08.png]
>
> On Mon, 4 Nov 2024 at 09:59, Craig Berry via Exist-open <
> exi...@li...> wrote:
>
> As someone who has had cordial and helpful interactions with both Adam and
> with some of the eXist Solutions folks for several years, this state of
> affairs really saddens me.  As someone who maintains a project that depends
> on eXist, it also really concerns me about the future of eXist.
>
> I've had the somewhat vague impression that Adam has done the lion's share
> of the work to maintain eXist for quite some time, and I wanted to make
> that impression less vague, so I did some digging.  The git logs below show
> that in the current develop branch the number of non-merge commits in the
> last five years totals 3115, or 2261 after weeding out dependabot commits.
> That's followed by a list showing the number of non-merge commits per
> committer in descending order by commit count.
>
> With 1266 commits, Adam produced 56% of all the human-produced commits in
> that period, 4.5 times as many as the next most-prolific human contributor.
> I realize commit counts are somewhat of a rough-and-ready placeholder for
> contribution and they surely overstate some things and understate others.
> One of the things they understate is producing releases, and it seems like
> Adam has done most of those in recent years too.
>
> I want to emphasize that I really appreciate the work of *all* the
> contributors, and I'm merely pointing out that the already somewhat anemic
> pace of eXist development appears to have taken a very serious blow given
> that its one really prolific contributor is being locked out. Is there a
> plan to address this?  Should folks be looking for an alternative to eXist?
>
> % git describe
> eXist-6.2.0-1595-ge8b4798931
> % git log --no-merges --pretty=format:"%an" --since=2019-11-01 | wc -l
>     3115
> % git log --no-merges --pretty=format:"%an" --since=2019-11-01 \
> | perl -ne 'chomp; $au{$_}++; END {for my $x (sort { $au{$b} <=> $au{$a} }
> keys %au ) {print qq/$au{$x}\t$x\n/}};'
> 1266    Adam Retter
> 638     dependabot[bot]
> 277     Dannes Wessels
> 253     Juri Leino
> 216     dependabot-preview[bot]
> 152     Alan Paxton
> 69      Patrick Reinhart
> 54      Christopher McGeorge
> 27      Joe Wicentowski
> 26      mamroure
> 19      marmoure
> 17      Radek Hubner
> 17      duncdrum
> 17      Gabriele Tomassetti
> 16      Wolfgang Meier
> 12      Adrian Hamm
> 10      Duncan Paterson
> 9       Lars Windauer
> 6       Stanislav Jordanov
> 5       Nico Verwer
> 1       Stefan Hynek
> 1       markhall82
> 1       lujie
> 1       Otmar Humbel
> 1       stephan makowski
> 1       naveen
> 1       hoijui
> 1       ch...@ev...
> 1       Alberto Simões
> 1       Steven
>
>
> > On Nov 2, 2024, at 6:11 AM, Adam Retter <ad...@ex...> wrote:
> >
> >
> > For those that are interested in hearing the truth, please feel free to
> contact me directly. Or if you wish you can read the public responses from
> myself, and other eXist-db users and XML experts in the #community channel
> of the eXist-db Slack Workspace - https://exist-db.slack.com/
> >
> >
> >
> > On Wed, 30 Oct 2024 at 16:31, Duncan Paterson <dun...@gm...>
> wrote:
> > In an abstract for his presentation at the upcoming Declarative
> Amsterdam conference, Adam Retter announced his decision to fork eXist-db
> and launch a competing project. This action is commonplace in open source.
> However, in justifying his decision, Adam maligned the eXist community and
> project - in a strikingly unprofessional manner.
> >
> > On October 7 and 14, 2024 during the weekly Community Call, eXist-db’s
> core developers and active community members discussed this matter and
> unanimously concluded that we no longer have the necessary trust in Adam to
> speak or act in the best interests of the eXist community. We have
> therefore revoked his status as a core developer and his administrative
> privileges from the eXist-db GitHub organization and related community
> resources. We regret having to take these measures. But we believe that
> they are vital to restoring the collegial and welcoming atmosphere that
> marked the eXist-db community since its founding by Wolfgang Meier in 2001.
> We thank Adam for all of his work on eXist-db and wish him well with his
> new project.
> >
> >
> > == Signatories ==
> >
> > Dannes Wessels,
> > Duncan Paterson,
> > Joseph Wicentowski,
> > Joern Turner,
> > Juri Leino,
> > Lars Windauer,
> > Magdalena Turska,
> > Olaf Schreck,
> > Patrick Reinhart,
> > Wolfgang Meier, (founder eXist-db)
> > _______________________________________________
> > Exist-open mailing list
> > Exi...@li...
> > https://lists.sourceforge.net/lists/listinfo/exist-open
> >
> >
> > --
> > Adam Retter
> >
> > eXist Core Developer
> > { United Kingdom }
> > ad...@ex...
> > _______________________________________________
> > Exist-open mailing list
> > Exi...@li...
> > https://lists.sourceforge.net/lists/listinfo/exist-open
>
> ________________________________________
> Craig A. Berry
>
> "... getting out of a sonnet is much more
>  difficult than getting in."
>                  Brad Leithauser
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
>
>
> --
> Adam Retter
>
> eXist Core Developer
> { United Kingdom }
> ad...@ex...
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>


-- 
Adam Retter

eXist Core Developer
{ United Kingdom }
ad...@ex...

Re: [Exist-open] Exist DB Community Changes

[Eduard D. <ed...@fr...>]

Dear all,

For our institution this all strengthens the feeling we need to reconsider the use of exist-db, we already felt that need because of performance, old java versions and libs, long standing issues, one highly complex monolithic solution for both database and app development, no jakarta ee compatible war, no atomic transactions, poor support for multiuser editing, etc.

I value Xml and exist-db a lot, don't get me wrong, but our institution needs to make future proof choices, and I wonder whether sticking with exist-db is a good choice in that respect.

Regards,
Eduard




Eduard Drenth, Software Architekt


ed...@fr...


Doelestrjitte 8

8911 DX  Ljouwert

(058) 213 14 14

+31 62 094 34 28

https://www.fryske-akademy.nl/
https://frysker.nl/
https://frisian.eu/
[cid:8bc42473-0b2f-46ae-9cf4-53515937ae62]

gpg: https://keyserver.ubuntu.com/pks/lookup?search=eduard+drenth&fingerprint=on&op=index

________________________________
From: Adam Retter <ad...@ex...>
Sent: Monday, November 4, 2024 11:57 PM
To: Craig Berry <cra...@ma...>
Cc: exi...@li... <exi...@li...>
Subject: Re: [Exist-open] Exist DB Community Changes

Thanks for the email Craig. Whilst I am deeply surprised and upset about what has happened, I am also sorry that it is effecting the eXist-db users such as yourself that I have worked so hard for and care about.

I appreciate you crunching and highlighting the numbers. For those who appreciate stats, a couple more for you:

1. As you say commits aren't everything. I also produced the last 22 consecutive releases of eXist-db.
Since 2017, of the 52 releases, I produced 75% of them. I did this unpaid.
My company Evolved Binary also at its own expense maintains a lot of the technical infrastructure that is required to produce and publish releases of eXist-db.
See - https://github.com/eXist-db/exist/releases

2. From your list of contributors. 8 of the other named people contributing to eXist-db were directed by me and paid for solely by my company Evolved Binary. There is also 1 more who was partially funded by my company. Removing me from the eXist-db project will also remove those other contributors too.

3. I undertook a 1 year solo project from 2017 to 2018 to fix locking and data corruption issues. It's not perfect still, but it was much improved.
That code base is was what became eXist-db 5.
https://evolvedbinary.com/technical-reports/exist-db/locking-and-cache-improvements/locking-and-cache-improvements-20180205.pdf
https://evolvedbinary.com/technical-reports/exist-db/asymmetrical-locking/asymmetrical-locking-20180205.pdf

4. I migrated eXist-db through 3 major versions of Java. To Java 6, then Java 8, and then again later to Java 17. I did this unpaid.

5. I migrated eXist-db's code base from SourceForge (and Subversion) to GitHub (and Git), which is why we have a comprehensive and intact source history and can still see who has done what and when. I did this unpaid. Speaking of which, you can also download CSV files from the graphs of contributors on GitHub going back to 2003 here - https://github.com/eXist-db/exist/graphs/contributors. GitHub's own graphs are quite revealing!
Out of sheer personal curiosity, I crunched some data myself. Considering only the top four contributors (as I didn't have time to crunch all the data available), I produced a little graph from the CSV data (attached). One could perhaps make the argument hat I have been the core contributor and maintainer of eXist-db since about 2015.

Regards the future of eXist-db, I have some plans. Feel free to reach out to me - ad...@ev...<mailto:ad...@ev...>.


[Screenshot 2024-11-04 at 23.48.08.png]

On Mon, 4 Nov 2024 at 09:59, Craig Berry via Exist-open <exi...@li...<mailto:exi...@li...>> wrote:
As someone who has had cordial and helpful interactions with both Adam and with some of the eXist Solutions folks for several years, this state of affairs really saddens me.  As someone who maintains a project that depends on eXist, it also really concerns me about the future of eXist.

I've had the somewhat vague impression that Adam has done the lion's share of the work to maintain eXist for quite some time, and I wanted to make that impression less vague, so I did some digging.  The git logs below show that in the current develop branch the number of non-merge commits in the last five years totals 3115, or 2261 after weeding out dependabot commits. That's followed by a list showing the number of non-merge commits per committer in descending order by commit count.

With 1266 commits, Adam produced 56% of all the human-produced commits in that period, 4.5 times as many as the next most-prolific human contributor. I realize commit counts are somewhat of a rough-and-ready placeholder for contribution and they surely overstate some things and understate others.  One of the things they understate is producing releases, and it seems like Adam has done most of those in recent years too.

I want to emphasize that I really appreciate the work of *all* the contributors, and I'm merely pointing out that the already somewhat anemic pace of eXist development appears to have taken a very serious blow given that its one really prolific contributor is being locked out. Is there a plan to address this?  Should folks be looking for an alternative to eXist?

% git describe
eXist-6.2.0-1595-ge8b4798931
% git log --no-merges --pretty=format:"%an" --since=2019-11-01 | wc -l
    3115
% git log --no-merges --pretty=format:"%an" --since=2019-11-01 \
| perl -ne 'chomp; $au{$_}++; END {for my $x (sort { $au{$b} <=> $au{$a} } keys %au ) {print qq/$au{$x}\t$x\n/}};'
1266    Adam Retter
638     dependabot[bot]
277     Dannes Wessels
253     Juri Leino
216     dependabot-preview[bot]
152     Alan Paxton
69      Patrick Reinhart
54      Christopher McGeorge
27      Joe Wicentowski
26      mamroure
19      marmoure
17      Radek Hubner
17      duncdrum
17      Gabriele Tomassetti
16      Wolfgang Meier
12      Adrian Hamm
10      Duncan Paterson
9       Lars Windauer
6       Stanislav Jordanov
5       Nico Verwer
1       Stefan Hynek
1       markhall82
1       lujie
1       Otmar Humbel
1       stephan makowski
1       naveen
1       hoijui
1       ch...@ev...<mailto:ch...@ev...>
1       Alberto Simões
1       Steven


> On Nov 2, 2024, at 6:11 AM, Adam Retter <ad...@ex...<mailto:ad...@ex...>> wrote:
>
>
> For those that are interested in hearing the truth, please feel free to contact me directly. Or if you wish you can read the public responses from myself, and other eXist-db users and XML experts in the #community channel of the eXist-db Slack Workspace - https://exist-db.slack.com/
>
>
>
> On Wed, 30 Oct 2024 at 16:31, Duncan Paterson <dun...@gm...<mailto:dun...@gm...>> wrote:
> In an abstract for his presentation at the upcoming Declarative Amsterdam conference, Adam Retter announced his decision to fork eXist-db and launch a competing project. This action is commonplace in open source. However, in justifying his decision, Adam maligned the eXist community and project - in a strikingly unprofessional manner.
>
> On October 7 and 14, 2024 during the weekly Community Call, eXist-db’s core developers and active community members discussed this matter and unanimously concluded that we no longer have the necessary trust in Adam to speak or act in the best interests of the eXist community. We have therefore revoked his status as a core developer and his administrative privileges from the eXist-db GitHub organization and related community resources. We regret having to take these measures. But we believe that they are vital to restoring the collegial and welcoming atmosphere that marked the eXist-db community since its founding by Wolfgang Meier in 2001. We thank Adam for all of his work on eXist-db and wish him well with his new project.
>
>
> == Signatories ==
>
> Dannes Wessels,
> Duncan Paterson,
> Joseph Wicentowski,
> Joern Turner,
> Juri Leino,
> Lars Windauer,
> Magdalena Turska,
> Olaf Schreck,
> Patrick Reinhart,
> Wolfgang Meier, (founder eXist-db)
> _______________________________________________
> Exist-open mailing list
> Exi...@li...<mailto:Exi...@li...>
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
>
> --
> Adam Retter
>
> eXist Core Developer
> { United Kingdom }
> ad...@ex...<mailto:ad...@ex...>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...<mailto:Exi...@li...>
> https://lists.sourceforge.net/lists/listinfo/exist-open

________________________________________
Craig A. Berry

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser



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


--
Adam Retter

eXist Core Developer
{ United Kingdom }
ad...@ex...<mailto:ad...@ex...>

[Exist-open] Lucene custom analyzer

[Irene V. <ire...@pa...>]

Hi there!

I am trying to add a custom Lucene analyzer that behaves like the WhitespaceAnalyzer concerning tokenization and (lack of) stemming, but that is also case-insensitive (basically the same of https://sourceforge.net/p/exist/mailman/message/35188378/).

I followed what suggested in the post thread above, that is writing the custom analyzer, compiling its class as JAR and saving it in $EXIST_HOME/lib/user, but it is not working. I tried also putting it in the same folder of the other Lucene JAR files, but the same.

Since both my Java/Lucene and eXist-db knowledge are quite poor, I am struggling to figure out whether the problem concerns my code or has to do with eXist-db itself.

This is my custom analyzer code:

package org.custom;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.analysis.TokenStream;
import org.apache.lucene.analysis.core.LowerCaseFilter;
import org.apache.lucene.analysis.core.WhitespaceTokenizer;
public class CaseInsensitiveWhitespaceAnalyzer extends Analyzer {
    @Override
    protected TokenStreamComponents createComponents(String fieldName) {
        final WhitespaceTokenizer source = new WhitespaceTokenizer();
        final TokenStream filter = new LowerCaseFilter(source);
        return new TokenStreamComponents(source, filter);
    }
}

And this is how I reference to it in collection.xconf:
<analyzer id="custom" class="org.custom.CaseInsensitiveWhitespaceAnalyzer"/>

I also tested the analyzer outside eXist-db with the following and it returned the expected tokens:

import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.analysis.TokenStream;
import org.apache.lucene.analysis.tokenattributes.CharTermAttribute;
import org.custom.CaseInsensitiveWhitespaceAnalyzer;
import java.io.IOException;
import java.io.StringReader;
public class TestAnalyzer {
    public static void main(String[] args) throws IOException {
        String text = "Lucene is a Simple1 123 5% _test - Yet Powerful - Java Based Search Library. I love IT!";
        Analyzer analyzer = new CaseInsensitiveWhitespaceAnalyzer();
        try (TokenStream tokenStream = analyzer.tokenStream("field", new StringReader(text))) {
            CharTermAttribute charTermAttribute = tokenStream.addAttribute(CharTermAttribute.class);
            tokenStream.reset();
            while (tokenStream.incrementToken()) {
                System.out.println(charTermAttribute.toString());
            }
            tokenStream.end();
        }
    }
}

What am I doing wrong? Any suggestions/hints will be highly appreciated :)

Thanks,
Irene

Re: [Exist-open] Help with file upload please.

[Tony C. <t.c...@su...>]

Thanks Joe and Jean-Paul
As you’d expect things are now working exactly as I’d hoped.
Tony


From: Joe Wicentowski <jo...@gm...>
Sent: 02 December 2024 17:16
To: Corless, Tony (Comp Sci & Elec Eng) <t.c...@su...>
Cc: exi...@li...
Subject: Re: [Exist-open] Help with file upload please.

Hi Tony,

Instead of the request:get-parameter function, use request:get-uploaded-file-data. See:

  https://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/request#get-uploaded-file-data.1

Joe

On Mon, Dec 2, 2024 at 4:20 AM Tony Corless via Exist-open <exi...@li...<mailto:exi...@li...>> wrote:
Hello all,

I am getting something slightly wrong and I’m not sure what. This is still new to me, so likely I am making a silly error.
I want to provide users with a form that allows them to upload PDF files from their PC to the database. The form will also have information about the PDF, which is working as expected.

For a test I have two XQueries one to post the data and the other to save it:

xquery version "3.1";
declare option exist:serialize "method=html media-type=text/html indent=no";
<html><body>
    <p>file upload test</p>
    <form method="post" enctype="multipart/form-data" action="./storeFile.xql">
    <input type="file" id="myFile" name="posted"/>
    <input type="submit"/>
</form>
</body></html>


and

xquery version "3.1";
declare option exist:serialize "method=html media-type=text/html indent=no";
declare variable $received := request:get-parameter("posted",());
let $filePath :="/db/apps/scratch/data/files"
let $fileName := "test.pdf"
return
    <html><body>Received {($filePath, $fileName, xmldb:store-as-binary($filePath, $fileName, $received))}</body></html>

The result is that I get a file test.pdf in the target directory but it displays only as blank pages. The same file uploaded through the admin client displays correctly.
(I get the same result with a side range of PDF files. If I change to store a JPG then I get a blank image from the XQuery route and the expected image using the admin client.)

I feel that I am missing something that is obvious and trivial to those who know what they are doing!

Any input welcome.
Tony

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

Re: [Exist-open] Help with file upload please.

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

Hi Tony,

Instead of the request:get-parameter function,
use request:get-uploaded-file-data. See:


https://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/request#get-uploaded-file-data.1

Joe

On Mon, Dec 2, 2024 at 4:20 AM Tony Corless via Exist-open <
exi...@li...> wrote:

> Hello all,
>
>
>
> I am getting something slightly wrong and I’m not sure what. This is still
> new to me, so likely I am making a silly error.
>
> I want to provide users with a form that allows them to upload PDF files
> from their PC to the database. The form will also have information about
> the PDF, which is working as expected.
>
>
>
> For a test I have two XQueries one to post the data and the other to save
> it:
>
>
>
> xquery version "3.1";
>
> declare option exist:serialize "method=html media-type=text/html
> indent=no";
>
> <html><body>
>
>     <p>file upload test</p>
>
>     <form method="post" enctype="multipart/form-data"
> action="./storeFile.xql">
>
>     <input type="file" id="myFile" name="posted"/>
>
>     <input type="submit"/>
>
> </form>
>
> </body></html>
>
>
>
>
>
> and
>
>
>
> xquery version "3.1";
>
> declare option exist:serialize "method=html media-type=text/html
> indent=no";
>
> declare variable $received := request:get-parameter("posted",());
>
> let $filePath :="/db/apps/scratch/data/files"
>
> let $fileName := "test.pdf"
>
> return
>
>     <html><body>Received {($filePath, $fileName,
> xmldb:store-as-binary($filePath, $fileName, $received))}</body></html>
>
>
>
> The result is that I get a file test.pdf in the target directory but it
> displays only as blank pages. The same file uploaded through the admin
> client displays correctly.
>
> (I get the same result with a side range of PDF files. If I change to
> store a JPG then I get a blank image from the XQuery route and the expected
> image using the admin client.)
>
>
>
> I feel that I am missing something that is obvious and trivial to those
> who know what they are doing!
>
>
>
> Any input welcome.
>
> Tony
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] Help with file upload please.

[Jean-Paul R. <re...@gm...>]

Dear Tony,

It seems you are trying to access the uploaded file (jpg, pdf, etc) via
request:get-parameter()....but the file is not a parameter to the request.

You need to use request:get-uploaded-file-data() within the context of
multipart/form-data. This function takes the name from the file you
uploaded, *not from an input*. This is accessed with
request:get-uploaded-file-name()

See
https://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/request&location=java:org.exist.xquery.functions.request.RequestModule

JPR

On Mon, Dec 2, 2024 at 10:20 AM Tony Corless via Exist-open <
exi...@li...> wrote:

> Hello all,
>
>
>
> I am getting something slightly wrong and I’m not sure what. This is still
> new to me, so likely I am making a silly error.
>
> I want to provide users with a form that allows them to upload PDF files
> from their PC to the database. The form will also have information about
> the PDF, which is working as expected.
>
>
>
> For a test I have two XQueries one to post the data and the other to save
> it:
>
>
>
> xquery version "3.1";
>
> declare option exist:serialize "method=html media-type=text/html
> indent=no";
>
> <html><body>
>
>     <p>file upload test</p>
>
>     <form method="post" enctype="multipart/form-data"
> action="./storeFile.xql">
>
>     <input type="file" id="myFile" name="posted"/>
>
>     <input type="submit"/>
>
> </form>
>
> </body></html>
>
>
>
>
>
> and
>
>
>
> xquery version "3.1";
>
> declare option exist:serialize "method=html media-type=text/html
> indent=no";
>
> declare variable $received := request:get-parameter("posted",());
>
> let $filePath :="/db/apps/scratch/data/files"
>
> let $fileName := "test.pdf"
>
> return
>
>     <html><body>Received {($filePath, $fileName,
> xmldb:store-as-binary($filePath, $fileName, $received))}</body></html>
>
>
>
> The result is that I get a file test.pdf in the target directory but it
> displays only as blank pages. The same file uploaded through the admin
> client displays correctly.
>
> (I get the same result with a side range of PDF files. If I change to
> store a JPG then I get a blank image from the XQuery route and the expected
> image using the admin client.)
>
>
>
> I feel that I am missing something that is obvious and trivial to those
> who know what they are doing!
>
>
>
> Any input welcome.
>
> Tony
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

[Exist-open] Help with file upload please.

[Tony C. <t.c...@su...>]

Hello all,

I am getting something slightly wrong and I'm not sure what. This is still new to me, so likely I am making a silly error.
I want to provide users with a form that allows them to upload PDF files from their PC to the database. The form will also have information about the PDF, which is working as expected.

For a test I have two XQueries one to post the data and the other to save it:

xquery version "3.1";
declare option exist:serialize "method=html media-type=text/html indent=no";
<html><body>
    <p>file upload test</p>
    <form method="post" enctype="multipart/form-data" action="./storeFile.xql">
    <input type="file" id="myFile" name="posted"/>
    <input type="submit"/>
</form>
</body></html>


and

xquery version "3.1";
declare option exist:serialize "method=html media-type=text/html indent=no";
declare variable $received := request:get-parameter("posted",());
let $filePath :="/db/apps/scratch/data/files"
let $fileName := "test.pdf"
return
    <html><body>Received {($filePath, $fileName, xmldb:store-as-binary($filePath, $fileName, $received))}</body></html>

The result is that I get a file test.pdf in the target directory but it displays only as blank pages. The same file uploaded through the admin client displays correctly.
(I get the same result with a side range of PDF files. If I change to store a JPG then I get a blank image from the XQuery route and the expected image using the admin client.)

I feel that I am missing something that is obvious and trivial to those who know what they are doing!

Any input welcome.
Tony

Re: [Exist-open] Exist DB Community Changes

[Adam R. <ad...@ex...>]

Thanks for the email Craig. Whilst I am deeply surprised and upset about
what has happened, I am also sorry that it is effecting the eXist-db users
such as yourself that I have worked so hard for and care about.

I appreciate you crunching and highlighting the numbers. For those who
appreciate stats, a couple more for you:

1. As you say commits aren't everything. I also produced the last 22
consecutive releases of eXist-db.
Since 2017, of the 52 releases, I produced 75% of them. I did this unpaid.
My company Evolved Binary also at its own expense maintains a lot of the
technical infrastructure that is required to produce and publish releases
of eXist-db.
See - https://github.com/eXist-db/exist/releases

2. From your list of contributors. 8 of the other named people contributing
to eXist-db were directed by me and paid for solely by my company Evolved
Binary. There is also 1 more who was partially funded by my company.
Removing me from the eXist-db project will also remove those other
contributors too.

3. I undertook a 1 year solo project from 2017 to 2018 to fix locking and
data corruption issues. It's not perfect still, but it was much improved.
That code base is was what became eXist-db 5.
https://evolvedbinary.com/technical-reports/exist-db/locking-and-cache-improvements/locking-and-cache-improvements-20180205.pdf
https://evolvedbinary.com/technical-reports/exist-db/asymmetrical-locking/asymmetrical-locking-20180205.pdf

4. I migrated eXist-db through 3 major versions of Java. To Java 6, then
Java 8, and then again later to Java 17. I did this unpaid.

5. I migrated eXist-db's code base from SourceForge (and Subversion) to
GitHub (and Git), which is why we have a comprehensive and intact source
history and can still see who has done what and when. I did this unpaid.
Speaking of which, you can also download CSV files from the graphs of
contributors on GitHub going back to 2003 here -
https://github.com/eXist-db/exist/graphs/contributors. GitHub's own graphs
are quite revealing!
Out of sheer personal curiosity, I crunched some data myself. Considering
only the top four contributors (as I didn't have time to crunch all the
data available), I produced a little graph from the CSV data (attached).
One could perhaps make the argument hat I have been the core contributor
and maintainer of eXist-db since about 2015.

Regards the future of eXist-db, I have some plans. Feel free to reach out
to me - ad...@ev....


[image: Screenshot 2024-11-04 at 23.48.08.png]

On Mon, 4 Nov 2024 at 09:59, Craig Berry via Exist-open <
exi...@li...> wrote:

> As someone who has had cordial and helpful interactions with both Adam and
> with some of the eXist Solutions folks for several years, this state of
> affairs really saddens me.  As someone who maintains a project that depends
> on eXist, it also really concerns me about the future of eXist.
>
> I've had the somewhat vague impression that Adam has done the lion's share
> of the work to maintain eXist for quite some time, and I wanted to make
> that impression less vague, so I did some digging.  The git logs below show
> that in the current develop branch the number of non-merge commits in the
> last five years totals 3115, or 2261 after weeding out dependabot commits.
> That's followed by a list showing the number of non-merge commits per
> committer in descending order by commit count.
>
> With 1266 commits, Adam produced 56% of all the human-produced commits in
> that period, 4.5 times as many as the next most-prolific human contributor.
> I realize commit counts are somewhat of a rough-and-ready placeholder for
> contribution and they surely overstate some things and understate others.
> One of the things they understate is producing releases, and it seems like
> Adam has done most of those in recent years too.
>
> I want to emphasize that I really appreciate the work of *all* the
> contributors, and I'm merely pointing out that the already somewhat anemic
> pace of eXist development appears to have taken a very serious blow given
> that its one really prolific contributor is being locked out. Is there a
> plan to address this?  Should folks be looking for an alternative to eXist?
>
> % git describe
> eXist-6.2.0-1595-ge8b4798931
> % git log --no-merges --pretty=format:"%an" --since=2019-11-01 | wc -l
>     3115
> % git log --no-merges --pretty=format:"%an" --since=2019-11-01 \
> | perl -ne 'chomp; $au{$_}++; END {for my $x (sort { $au{$b} <=> $au{$a} }
> keys %au ) {print qq/$au{$x}\t$x\n/}};'
> 1266    Adam Retter
> 638     dependabot[bot]
> 277     Dannes Wessels
> 253     Juri Leino
> 216     dependabot-preview[bot]
> 152     Alan Paxton
> 69      Patrick Reinhart
> 54      Christopher McGeorge
> 27      Joe Wicentowski
> 26      mamroure
> 19      marmoure
> 17      Radek Hubner
> 17      duncdrum
> 17      Gabriele Tomassetti
> 16      Wolfgang Meier
> 12      Adrian Hamm
> 10      Duncan Paterson
> 9       Lars Windauer
> 6       Stanislav Jordanov
> 5       Nico Verwer
> 1       Stefan Hynek
> 1       markhall82
> 1       lujie
> 1       Otmar Humbel
> 1       stephan makowski
> 1       naveen
> 1       hoijui
> 1       ch...@ev...
> 1       Alberto Simões
> 1       Steven
>
>
> > On Nov 2, 2024, at 6:11 AM, Adam Retter <ad...@ex...> wrote:
> >
> >
> > For those that are interested in hearing the truth, please feel free to
> contact me directly. Or if you wish you can read the public responses from
> myself, and other eXist-db users and XML experts in the #community channel
> of the eXist-db Slack Workspace - https://exist-db.slack.com/
> >
> >
> >
> > On Wed, 30 Oct 2024 at 16:31, Duncan Paterson <dun...@gm...>
> wrote:
> > In an abstract for his presentation at the upcoming Declarative
> Amsterdam conference, Adam Retter announced his decision to fork eXist-db
> and launch a competing project. This action is commonplace in open source.
> However, in justifying his decision, Adam maligned the eXist community and
> project - in a strikingly unprofessional manner.
> >
> > On October 7 and 14, 2024 during the weekly Community Call, eXist-db’s
> core developers and active community members discussed this matter and
> unanimously concluded that we no longer have the necessary trust in Adam to
> speak or act in the best interests of the eXist community. We have
> therefore revoked his status as a core developer and his administrative
> privileges from the eXist-db GitHub organization and related community
> resources. We regret having to take these measures. But we believe that
> they are vital to restoring the collegial and welcoming atmosphere that
> marked the eXist-db community since its founding by Wolfgang Meier in 2001.
> We thank Adam for all of his work on eXist-db and wish him well with his
> new project.
> >
> >
> > == Signatories ==
> >
> > Dannes Wessels,
> > Duncan Paterson,
> > Joseph Wicentowski,
> > Joern Turner,
> > Juri Leino,
> > Lars Windauer,
> > Magdalena Turska,
> > Olaf Schreck,
> > Patrick Reinhart,
> > Wolfgang Meier, (founder eXist-db)
> > _______________________________________________
> > Exist-open mailing list
> > Exi...@li...
> > https://lists.sourceforge.net/lists/listinfo/exist-open
> >
> >
> > --
> > Adam Retter
> >
> > eXist Core Developer
> > { United Kingdom }
> > ad...@ex...
> > _______________________________________________
> > Exist-open mailing list
> > Exi...@li...
> > https://lists.sourceforge.net/lists/listinfo/exist-open
>
> ________________________________________
> Craig A. Berry
>
> "... getting out of a sonnet is much more
>  difficult than getting in."
>                  Brad Leithauser
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>


-- 
Adam Retter

eXist Core Developer
{ United Kingdom }
ad...@ex...

Re: [Exist-open] Exist DB Community Changes

[Craig B. <cra...@ma...>]

As someone who has had cordial and helpful interactions with both Adam and with some of the eXist Solutions folks for several years, this state of affairs really saddens me.  As someone who maintains a project that depends on eXist, it also really concerns me about the future of eXist.

I've had the somewhat vague impression that Adam has done the lion's share of the work to maintain eXist for quite some time, and I wanted to make that impression less vague, so I did some digging.  The git logs below show that in the current develop branch the number of non-merge commits in the last five years totals 3115, or 2261 after weeding out dependabot commits. That's followed by a list showing the number of non-merge commits per committer in descending order by commit count.

With 1266 commits, Adam produced 56% of all the human-produced commits in that period, 4.5 times as many as the next most-prolific human contributor. I realize commit counts are somewhat of a rough-and-ready placeholder for contribution and they surely overstate some things and understate others.  One of the things they understate is producing releases, and it seems like Adam has done most of those in recent years too.

I want to emphasize that I really appreciate the work of *all* the contributors, and I'm merely pointing out that the already somewhat anemic pace of eXist development appears to have taken a very serious blow given that its one really prolific contributor is being locked out. Is there a plan to address this?  Should folks be looking for an alternative to eXist?

% git describe
eXist-6.2.0-1595-ge8b4798931
% git log --no-merges --pretty=format:"%an" --since=2019-11-01 | wc -l
    3115
% git log --no-merges --pretty=format:"%an" --since=2019-11-01 \
| perl -ne 'chomp; $au{$_}++; END {for my $x (sort { $au{$b} <=> $au{$a} } keys %au ) {print qq/$au{$x}\t$x\n/}};'
1266	Adam Retter
638	dependabot[bot]
277	Dannes Wessels
253	Juri Leino
216	dependabot-preview[bot]
152	Alan Paxton
69	Patrick Reinhart
54	Christopher McGeorge
27	Joe Wicentowski
26	mamroure
19	marmoure
17	Radek Hubner
17	duncdrum
17	Gabriele Tomassetti
16	Wolfgang Meier
12	Adrian Hamm
10	Duncan Paterson
9	Lars Windauer
6	Stanislav Jordanov
5	Nico Verwer
1	Stefan Hynek
1	markhall82
1	lujie
1	Otmar Humbel
1	stephan makowski
1	naveen
1	hoijui
1	ch...@ev...
1	Alberto Simões
1	Steven


> On Nov 2, 2024, at 6:11 AM, Adam Retter <ad...@ex...> wrote:
> 
> 
> For those that are interested in hearing the truth, please feel free to contact me directly. Or if you wish you can read the public responses from myself, and other eXist-db users and XML experts in the #community channel of the eXist-db Slack Workspace - https://exist-db.slack.com/
> 
> 
> 
> On Wed, 30 Oct 2024 at 16:31, Duncan Paterson <dun...@gm...> wrote:
> In an abstract for his presentation at the upcoming Declarative Amsterdam conference, Adam Retter announced his decision to fork eXist-db and launch a competing project. This action is commonplace in open source. However, in justifying his decision, Adam maligned the eXist community and project - in a strikingly unprofessional manner. 
> 
> On October 7 and 14, 2024 during the weekly Community Call, eXist-db’s core developers and active community members discussed this matter and unanimously concluded that we no longer have the necessary trust in Adam to speak or act in the best interests of the eXist community. We have therefore revoked his status as a core developer and his administrative privileges from the eXist-db GitHub organization and related community resources. We regret having to take these measures. But we believe that they are vital to restoring the collegial and welcoming atmosphere that marked the eXist-db community since its founding by Wolfgang Meier in 2001. We thank Adam for all of his work on eXist-db and wish him well with his new project.
> 
> 
> == Signatories == 
> 
> Dannes Wessels, 
> Duncan Paterson,
> Joseph Wicentowski,
> Joern Turner,
> Juri Leino, 
> Lars Windauer,
> Magdalena Turska,
> Olaf Schreck,
> Patrick Reinhart,
> Wolfgang Meier, (founder eXist-db)
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
> 
> 
> -- 
> Adam Retter
> 
> eXist Core Developer
> { United Kingdom }
> ad...@ex...
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

________________________________________
Craig A. Berry

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Re: [Exist-open] Exist DB Community Changes

[Adam R. <ad...@ex...>]

For those that are interested in hearing the truth, please feel free to
contact me directly. Or if you wish you can read the public responses from
myself, and other eXist-db users and XML experts in the #community channel
of the eXist-db Slack Workspace - https://exist-db.slack.com/



On Wed, 30 Oct 2024 at 16:31, Duncan Paterson <dun...@gm...> wrote:

> In an abstract for his presentation at the upcoming Declarative Amsterdam
> conference, Adam Retter announced his decision to fork eXist-db and launch
> a competing project. This action is commonplace in open source. However, in
> justifying his decision, Adam maligned the eXist community and project - in
> a strikingly unprofessional manner.
>
> On October 7 and 14, 2024 during the weekly Community Call, eXist-db’s
> core developers and active community members discussed this matter and
> unanimously concluded that we no longer have the necessary trust in Adam to
> speak or act in the best interests of the eXist community. We have
> therefore revoked his status as a core developer and his administrative
> privileges from the eXist-db GitHub organization and related community
> resources. We regret having to take these measures. But we believe that
> they are vital to restoring the collegial and welcoming atmosphere that
> marked the eXist-db community since its founding by Wolfgang Meier in 2001.
> We thank Adam for all of his work on eXist-db and wish him well with his
> new project.
>
>
> == Signatories ==
>
> Dannes Wessels,
>
> Duncan Paterson,
>
> Joseph Wicentowski,
>
> Joern Turner,
>
> Juri Leino,
>
> Lars Windauer,
>
> Magdalena Turska,
>
> Olaf Schreck,
>
> Patrick Reinhart,
>
> Wolfgang Meier, (founder eXist-db)
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>


-- 
Adam Retter

eXist Core Developer
{ United Kingdom }
ad...@ex...

Re: [Exist-open] Migrating a web app from an old version of eXist

[Michael P. <mic...@gm...>]

Hi Tino,

since 6.3 is not binary compatible with 4.1 (see
https://exist-db.org/exist/apps/doc/incompatibilities), you need to follow
https://exist-db.org/exist/apps/doc/upgrading.xml#non-binary-compatible-upgrades
.

(But please be aware that I'm neither an eXist-db core developer nor an
active community member.)

All best,
Michael

Am Mi., 30. Okt. 2024 um 18:06 Uhr schrieb Dai, Tino W <td...@lo...>:

> Hi,
>
>
>
>      I have a web app that I have been asked to bring up to 6.3.0.
> Currently, the web app is running on 4.1 and is a set of files directories
> located in /usr/local/eXist/webapp. Can I just migrate this over to 6.3.0
> as is or do I need to package it up into a .xar file?
>
>
>
> Thanks,
>
> Tino
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] Migrating a web app from an old version of eXist

[Adam R. <ad...@ex...>]

You don't need to package it into a car, although that wouldn't hurt.
However in more modern versions of eXist-db, all content, including XQuery
files, need to get stored inside the database itself

On Wed, 30 Oct 2024, 18:07 Dai, Tino W, <td...@lo...> wrote:

> Hi,
>
>
>
>      I have a web app that I have been asked to bring up to 6.3.0.
> Currently, the web app is running on 4.1 and is a set of files directories
> located in /usr/local/eXist/webapp. Can I just migrate this over to 6.3.0
> as is or do I need to package it up into a .xar file?
>
>
>
> Thanks,
>
> Tino
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

[Exist-open] Application/New Application doesn't exist in 6.3.0 eXide

[Dai, T. W <td...@lo...>]

Hi,

    It seems that the documentation is wrong: https://exist-db.org/exist/apps/doc/development-starter. There is no Application/New Application drop down in the eXide application. It seems that the New Application was removed back in 3.x according to this post

https://stackoverflow.com/questions/70184724/create-new-web-app-in-exist-db-5-3-0-and-import-old-from-4-3-1

Is there a way to remove that section from the site?

-Tino

[Exist-open] Migrating a web app from an old version of eXist

[Dai, T. W <td...@lo...>]

Hi,

     I have a web app that I have been asked to bring up to 6.3.0. Currently, the web app is running on 4.1 and is a set of files directories located in /usr/local/eXist/webapp. Can I just migrate this over to 6.3.0 as is or do I need to package it up into a .xar file?

Thanks,
Tino

[Exist-open] Exist DB Community Changes

[Duncan P. <dun...@gm...>]

In an abstract for his presentation at the upcoming Declarative Amsterdam
conference, Adam Retter announced his decision to fork eXist-db and launch
a competing project. This action is commonplace in open source. However, in
justifying his decision, Adam maligned the eXist community and project - in
a strikingly unprofessional manner.

On October 7 and 14, 2024 during the weekly Community Call, eXist-db’s core
developers and active community members discussed this matter and
unanimously concluded that we no longer have the necessary trust in Adam to
speak or act in the best interests of the eXist community. We have
therefore revoked his status as a core developer and his administrative
privileges from the eXist-db GitHub organization and related community
resources. We regret having to take these measures. But we believe that
they are vital to restoring the collegial and welcoming atmosphere that
marked the eXist-db community since its founding by Wolfgang Meier in 2001.
We thank Adam for all of his work on eXist-db and wish him well with his
new project.


== Signatories ==

Dannes Wessels,

Duncan Paterson,

Joseph Wicentowski,

Joern Turner,

Juri Leino,

Lars Windauer,

Magdalena Turska,

Olaf Schreck,

Patrick Reinhart,

Wolfgang Meier, (founder eXist-db)

Re: [Exist-open] [ANN] Release of eXist-db 4.11.2, 5.5.2, and 6.3.0

[Adam R. <ad...@ex...>]

Hi Nick,

Yes, sorry about that. The eXist-db blog has been broken for what feels
like forever, which means things get scrambled when new articles are
created. I am afraid that I have no control over that. I think I saw in
Slack that Joe Wickentowski kindly offered to fix that.

Thanks, Adam.

On Sun, 27 Oct 2024 at 01:01, Nick Sincaglia <nsi...@nu...> wrote:

> I just wanted to make you aware that the eXist-db 6.2.0 releases notes
> do not appear to be published yet.
>
> https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb630
>
> Nick
>
> On 10/26/24 9:08 AM, Craig Berry via Exist-open wrote:
> >> On Oct 26, 2024, at 6:21 AM, Adam Retter <ad...@ex...> wrote:
> >>
> >> We are very happy to announce releases of eXist-db 4, 5, and 6.
> >>
> >> eXist-db 4.11.2 and 5.5.2 are minor releases that fix just a few small
> bugs - see:
> >> * https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb4112
> >> * https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb552
> >>
> >> eXist-db 6.3.0 is a feature release and update, and as such should be
> 100% API and storage compatible with eXist-db 6.2.0. The full release notes
> are available at:
> https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb630
> > Thanks to Adam and everyone else involved for all of those fixes and
> improvements.
> >
> > For anyone on macOS Sequoia (like I am since yesterday), it's now a bit
> harder to open an application that isn't notarized.  You have to attempt to
> open the app once, dismiss the dialog, go into Privacy and Security in
> settings, scroll down to where it says '"eXist-db" was blocked to protect
> your Mac' and click "Open Anyway."  You can no longer right-click or
> control-click to get around lack of notarization.
> >
> > Note that the app *is* signed, just apparently not notarized by Apple.
> You can check the signature with:
> >
> > % codesign -dv --verbose=4 /Applications/eXist-db.app
> >
> > ________________________________________
> > Craig A. Berry
> >
> > "... getting out of a sonnet is much more
> >   difficult than getting in."
> >                   Brad Leithauser
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>


-- 
Adam Retter

eXist Core Developer
{ United Kingdom }
ad...@ex...

Re: [Exist-open] [ANN] Release of eXist-db 4.11.2, 5.5.2, and 6.3.0

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

I just wanted to make you aware that the eXist-db 6.2.0 releases notes 
do not appear to be published yet.

https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb630

Nick

On 10/26/24 9:08 AM, Craig Berry via Exist-open wrote:
>> On Oct 26, 2024, at 6:21 AM, Adam Retter <ad...@ex...> wrote:
>>
>> We are very happy to announce releases of eXist-db 4, 5, and 6.
>>
>> eXist-db 4.11.2 and 5.5.2 are minor releases that fix just a few small bugs - see:
>> * https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb4112
>> * https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb552
>>
>> eXist-db 6.3.0 is a feature release and update, and as such should be 100% API and storage compatible with eXist-db 6.2.0. The full release notes are available at: https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb630
> Thanks to Adam and everyone else involved for all of those fixes and improvements.
>
> For anyone on macOS Sequoia (like I am since yesterday), it's now a bit harder to open an application that isn't notarized.  You have to attempt to open the app once, dismiss the dialog, go into Privacy and Security in settings, scroll down to where it says '"eXist-db" was blocked to protect your Mac' and click "Open Anyway."  You can no longer right-click or control-click to get around lack of notarization.
>
> Note that the app *is* signed, just apparently not notarized by Apple.  You can check the signature with:
>
> % codesign -dv --verbose=4 /Applications/eXist-db.app
>
> ________________________________________
> Craig A. Berry
>
> "... getting out of a sonnet is much more
>   difficult than getting in."
>                   Brad Leithauser
>
>
>
> _______________________________________________
> 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] [ANN] Release of eXist-db 4.11.2, 5.5.2, and 6.3.0

[Craig B. <cra...@ma...>]

> On Oct 26, 2024, at 6:21 AM, Adam Retter <ad...@ex...> wrote:
> 
> We are very happy to announce releases of eXist-db 4, 5, and 6.
> 
> eXist-db 4.11.2 and 5.5.2 are minor releases that fix just a few small bugs - see:
> * https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb4112
> * https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb552
> 
> eXist-db 6.3.0 is a feature release and update, and as such should be 100% API and storage compatible with eXist-db 6.2.0. The full release notes are available at: https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb630

Thanks to Adam and everyone else involved for all of those fixes and improvements.   

For anyone on macOS Sequoia (like I am since yesterday), it's now a bit harder to open an application that isn't notarized.  You have to attempt to open the app once, dismiss the dialog, go into Privacy and Security in settings, scroll down to where it says '"eXist-db" was blocked to protect your Mac' and click "Open Anyway."  You can no longer right-click or control-click to get around lack of notarization.

Note that the app *is* signed, just apparently not notarized by Apple.  You can check the signature with:

% codesign -dv --verbose=4 /Applications/eXist-db.app

________________________________________
Craig A. Berry

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

[Exist-open] [ANN] Release of eXist-db 4.11.2, 5.5.2, and 6.3.0

[Adam R. <ad...@ex...>]

We are very happy to announce releases of eXist-db 4, 5, and 6.

eXist-db 4.11.2 and 5.5.2 are minor releases that fix just a few small bugs
- see:
* https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb4112
* https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb552

eXist-db 6.3.0 is a feature release and update, and as such should be 100%
API and storage compatible with eXist-db 6.2.0. The full release notes are
available at: https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb630

*Features*

   - Add mail:get-mail-session#2 with authentication
   https://github.com/eXist-db/exist/pull/4801
   - Improve JMX output https://github.com/eXist-db/exist/pull/4964
   - Add support in `cache:create()` for 'expireAfterWrite' in `$config`
   https://github.com/eXist-db/exist/pull/4975
   - Allow the user to override the JDWP Suspend at Docker build time
   https://github.com/eXist-db/exist/pull/5008
   - Parameterise the XML-RPC parse method with the Media Type
   https://github.com/eXist-db/exist/pull/5070
   - New exist:time XQuery Pragma
   https://github.com/eXist-db/exist/pull/5077
   - Optimise Path Expressions that are visited by the
   BasicExpressionVisitor https://github.com/eXist-db/exist/pull/5083
   - Refactor to highlight materialization query execution model
   https://github.com/eXist-db/exist/pull/5080
   - Add Schema for EXPath Packaging System
   https://github.com/eXist-db/exist/pull/5113
   - Backport build scripts https://github.com/eXist-db/exist/pull/5091
   - Adds ContentFilePool and companion tests
   https://github.com/eXist-db/exist/pull/5217
   - Adds in memory cache for RPC query results
   https://github.com/eXist-db/exist/pull/5191
   - Switch CI from Temurin to Liberica
   https://github.com/eXist-db/exist/pull/5466
   - Allow setting the namespace on the result of sql:execute
   https://github.com/eXist-db/exist/pull/5186


*Bugfixes*

   - Fix an issue where XQuery Trigger state may leak
   https://github.com/eXist-db/exist/pull/5481
   - XQSuite assertXPath annotation: Support default element namespace
   https://github.com/eXist-db/exist/pull/4818
   - add missing dependency to copy-maven-plugin
   https://github.com/eXist-db/exist/pull/4858
   - tails of subsequences off by one
   https://github.com/eXist-db/exist/pull/4851
   - Ensure that EXPath packages installed in $EXIST_HOME/data/expathrepo
   are filesystem portable https://github.com/eXist-db/exist/pull/4913
   - Fix version number in `develop-6.x.x` branch
   https://github.com/eXist-db/exist/pull/4961
   - Fix missing fn:transform global parameters
   https://github.com/eXist-db/exist/pull/4893
   - Restore compatibility with Java language level 8
   https://github.com/eXist-db/exist/pull/4974
   - InputStream#available() should not be used to determine if there is
   data available https://github.com/eXist-db/exist/pull/4978
   - Fixes to fn:replace, fn:tokenize, and fn:analyze-string
   https://github.com/eXist-db/exist/pull/4865
   - cardinality of CastExpression#toFunction
   https://github.com/eXist-db/exist/pull/4976
   - Correct function signatures that return empty sequences
   https://github.com/eXist-db/exist/pull/4981
   - Log exception if the response is already committed
   https://github.com/eXist-db/exist/pull/4993
   - Correct the XDM type for the Sequence holding a representation of a
   Java Stack Trace when an error occurs
   https://github.com/eXist-db/exist/pull/4994
   - Fix an issue with XQuery transient imports within EXPath Package
   https://github.com/eXist-db/exist/pull/5012
   - Fix the use of Debian Stretch repositories in the Docker builds
   https://github.com/eXist-db/exist/pull/5005
   - Fix a bug in Node Path equality
   https://github.com/eXist-db/exist/pull/5046
   - Fix an NPE in exist:time pragma
   https://github.com/eXist-db/exist/pull/5081
   - Handle IllegalStateException in file:directory-list#2
   https://github.com/eXist-db/exist/pull/5093
   - Named Function References can have Postfix Expressions
   https://github.com/eXist-db/exist/pull/5115
   - Remove sonar no longer supporting Java 8
   https://github.com/eXist-db/exist/pull/5218
   - Repair 6.x.x build for macOs
   https://github.com/eXist-db/exist/pull/5385
   - Address vulnerabilities as indicated by OWASP/NVD.
   https://github.com/eXist-db/exist/pull/5387
   - Fix flaky storage test timing
   https://github.com/eXist-db/exist/pull/5492
   - Fix CI Windows stream corruption
   https://github.com/eXist-db/exist/pull/5513
   - Fix errors on update operations
   https://github.com/eXist-db/exist/pull/5296


*Updated Libraries*

   - Update to appbundler-1.2.0 https://github.com/eXist-db/exist/pull/4781
   - Use newer copy-maven-plugin which does not have CVE issues with its
   dependencies https://github.com/eXist-db/exist/pull/4960
   - Bump org.codehaus.izpack:izpack-maven-plugin from 5.1.3 to 5.2.0
   https://github.com/eXist-db/exist/pull/5029
   - Bump jetty from 9.4.50.v20221201 to 9.4.54.v20240208
   https://github.com/eXist-db/exist/pull/5369
   - Bump jackson-core from 2.13.4 to 2.15.2
   https://github.com/eXist-db/exist/pull/5367
   - Upgrade all build related maven plugins
   https://github.com/eXist-db/exist/pull/5386
   - Make sure the latest jdom(1) jar is used
   https://github.com/eXist-db/exist/pull/5394


*Backwards Compatibility*
eXist-db 6.3.0 is binary compatible with previous eXist-db 6.x.x
versions Regardless, before upgrading to this version of eXist-db, it is
strongly recommended to perform a full backup and restore. Users who are
upgrading should always consult the Upgrading Guide https://exist-db.org/
exist/apps/doc/upgrading.xml in the documentation.

Thanks, Adam.


--
Adam Retter

eXist Core Developer
{ United Kingdom }
ad...@ex...

[Exist-open] Declarative Amsterdam 2024 reminder

[Erik S. <er...@xa...>]

Reminder: In two weeks, November 7 and 8,  the Declarative Amsterdam 2024 conference will be held.

This year's  <https://declarative.amsterdam/program> program contains a variety of technical and non-technical topics, such as:
Affix grammars, Answer Set Programming, banking, custom elements, ixml, JSONiq, linked data, music, Petal, RumbleDB, StratML, Syntax highlighting, TEI, XForms, XProc, XSLT, XJSLT, XSL-FO.

Some names: presentations and tutorials by Bahloul, von Criegern & Retter; Boot; Buzatu & Fourny; Ellensburg; Firsov, Graham; Groeneveld; Hetzner; Holman; Loughlin & Fourny; Meertens; Pemberton; Sanchez Rodriguez; Siegel; Verwer & Lamers.

Register now at:  <https://declarative.amsterdam/registration> https://declarative.amsterdam/registration. 

We hope to see you there, either in person or virtually!

Best wishes,
The Declarative Amsterdam Conference Committee.

 

[Exist-open] storeResouce is too slow with remote interface

[<pra...@gm...>]

Dear community, can you help?
> 
> eXistDB 6.2.0
> 
> Saving to a locally running database via the remote interface is several orders of magnitude slower compared to using an embedded database. I can't figure out where the problem lies, or how to store the data more efficiently.
> 
> I need to store about 100,000 records. When saving via the remote interface, the speed is around 100 records per second. However, when using the embedded database, the speed is about 9,000 records per second.
> 
> What am I doing wrong, or how can I improve this?
> 
> Below is a code example.
> 
> 
> 
> remote uri: xmldb:exist://localhost:8080/exist/xmlrpc
> embeded uri: xmldb:exist://
> 
> In both cases the db is running on the same machine. db configuration file is attached.
> 
> private void createRandomTestData(String prefix, int records) throws Exception {
>     final Random random = new Random();
>     final HashMap<String, String> data = new HashMap<>();
> 
>     for (int i = 0; i < records; i++) {
>         double latitude = MIN_LAT + (MAX_LAT - MIN_LAT) * random.nextDouble();
>         double longitude = MIN_LON + (MAX_LON - MIN_LON) * random.nextDouble();
> 
>         String randomId = UUID.randomUUID().toString();
>         String randomName = generateRandomString(random, 30);
>         String randomValue = generateRandomString(random, 10);
> 
>         String resourceId = prefix + "/" + randomId;
>         String xml = String.format(
>                 """
>                         <entity>
>                             <name>%s</name>
>                             <value>%s</value>
>                             <pos>%.8f %.8f</pos>
>                         </entity>""",
>                 randomName, randomValue, latitude, longitude
>         );
>         data.put(resourceId, xml);
>     }
>     xmlDbService.saveEntity(data);
> }
> 
> public void saveEntity(@NonNull HashMap<String, String> resources) throws Exception {
>     var sortedResources = new TreeMap<>(resources);
> 
>     Collection col = null;
>     String currentCollectionUri = null;
>     long start = System.currentTimeMillis();
> 
>     int i = 0;
>     int c = 0;
>     try {
>         for (var entry : sortedResources.entrySet()) {
>             String resourceId = entry.getKey();
>             String xmlData = entry.getValue();
> 
>             var param = splitResourceId(resourceId);
>             String collectionUri = param[0];
>             String resourceName = param[1];
> 
>             if (col == null || !collectionUri.equals(currentCollectionUri)) {
>                 if (col != null) {
>                     col.close();
>                 }
>                 col = getOrCreateCollection(collectionUri);
>                 col.setProperty("indent", "no");
>                 currentCollectionUri = collectionUri;
>             }
> 
>             i++;
>             if (i % 1000 == 0) {
>                 long executionTime = System.currentTimeMillis() - start;
>                 log.info("Inserted: {}, rate {} / sec", i, c * 1000L / executionTime);
>                 start = System.currentTimeMillis();
>                 c = 0;
>             }
>             XMLResource res = (XMLResource) col.createResource(resourceName, XMLResource.RESOURCE_TYPE);
>             res.setContent(xmlData);
>             col.storeResource(res);
>             c++;
>             log.trace("Resource saved: {} in collection: {}", resourceName, currentCollectionUri);
>         }
>     } finally {
>         if (col != null) {
>             col.close();
>         }
>     }
> }
> 
> <dependency>
>     <groupId>org.exist-db</groupId>
>     <artifactId>exist-core</artifactId>
>     <version>6.2.0</version>
> </dependency>
> 
> <dependency>
>     <groupId>net.sf.xmldb-org</groupId>
>     <artifactId>xmldb-api</artifactId>
>     <version>1.7.0</version>
> </dependency>
> Thank you for your help and/or advice.
> 
> V.
> 

Re: [Exist-open] File upload leads to database crash

[Benoit M. <ben...@us...>]

I had the exact same problem few weeks ago with the char 😊 (U+1F60A 
<https://www.compart.com/fr/unicode/U+1F60A>) in a TEI document. I 
retested 10 minutes ago. Just creating a file with the following content 
from OxygenXML, performing an XQuery on//badChar and deleting the file 
(from Oxygen again) make my eXist server crashed. But few weeks ago the 
problem appeared while running Xqueries and/or reindexing, cannot 
remember, sorry.

    <debug>
         <badChar>😊</badChar>
    </debug>


[eXist Version : 6.2.0]
[eXist Build : 2023-02-04T22:42:29Z]

Hope this will help,

Benoit

Le 2024-09-30 à 09 h 55, Joe Wicentowski a écrit :
> Hi Jannik,
>
> I see from the screenshot that you're using version 6.2.0.
>
> When the problem occurs, do you see any errors in exist.log?
>
> If you isolate the character(s) in question, could you open an issue? 
> (Or, feel free to email me the file, and I can take a look.)
>
> Joe
>
> On Sun, Sep 29, 2024 at 4:58 PM Jean-Paul Rehr <re...@gm...> wrote:
>
>     Dear Jannik,
>
>     I ran into a similar issue some time ago, and it was due to a
>     problem with a hidden character inserted into the file. This may
>     or may not be your case, but if you have a backup version of the
>     file from when it worked fine, you could transform it into code
>     points, and do the same with the current file, and see if they are
>     truly identical.
>
>     Hope this helps,
>     JPR
>
>     On Sun, Sep 29, 2024 at 10:29 PM Jannik Franz <fr...@md...> wrote:
>
>
>         Dear eXist-db community,
>
>         in our project we are using eXist-db for over two years now
>         and since a few weeks we are having a problem uploading a
>         specific XML-file (via eXide's upload interface).
>         As soon as the file is uploaded, the database crashes and the
>         server has to be restarted.
>         After the restart there remains an empty file in the database
>         as a result of the interrupted upload process.
>
>         The problem occurs only with this single file. It is a simple
>         TEI-XML document, 68KB small and not special in any way (and
>         it didn't cause any problems for the last 2 years).
>
>         Attached is a screenshot of the Monex report after uploading
>         the file.
>
>         Has anyone had a similar problem or has any advice how to deal
>         with it?
>
>         Many thanks in advance and best regards
>         Jannik Franz
>
>
>         Jannik Franz
>         Universität für Musik und darstellende Kunst Wien
>         Institut für Musikwissenschaft und Interpretationsforschung
>         Abteilung Wissenschaftszentrum Arnold Schönberg und die Wiener
>         Schule
>         Schwarzenbergplatz 6/Zaunergasse 1-3
>         1030 Wien
>         E-Mail: fr...@md...
>         _______________________________________________
>         Exist-open mailing list
>         Exi...@li...
>         https://lists.sourceforge.net/lists/listinfo/exist-open
>         <https://lists.sourceforge.net/lists/listinfo/exist-open>
>
>     _______________________________________________
>     Exist-open mailing list
>     Exi...@li...
>     https://lists.sourceforge.net/lists/listinfo/exist-open
>     <https://lists.sourceforge.net/lists/listinfo/exist-open>
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] File upload leads to database crash

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

Hi Jannik,

I see from the screenshot that you're using version 6.2.0.

When the problem occurs, do you see any errors in exist.log?

If you isolate the character(s) in question, could you open an issue? (Or,
feel free to email me the file, and I can take a look.)

Joe

On Sun, Sep 29, 2024 at 4:58 PM Jean-Paul Rehr <re...@gm...> wrote:

> Dear Jannik,
>
> I ran into a similar issue some time ago, and it was due to a problem with
> a hidden character inserted into the file. This may or may not be your
> case, but if you have a backup version of the file from when it worked
> fine, you could transform it into code points, and do the same with the
> current file, and see if they are truly identical.
>
> Hope this helps,
> JPR
>
> On Sun, Sep 29, 2024 at 10:29 PM Jannik Franz <fr...@md...> wrote:
>
>>
>> Dear eXist-db community,
>>
>> in our project we are using eXist-db for over two years now and since a
>> few weeks we are having a problem uploading a specific XML-file (via
>> eXide's upload interface).
>> As soon as the file is uploaded, the database crashes and the server has
>> to be restarted.
>> After the restart there remains an empty file in the database as a result
>> of the interrupted upload process.
>>
>> The problem occurs only with this single file. It is a simple TEI-XML
>> document, 68KB small and not special in any way (and it didn't cause any
>> problems for the last 2 years).
>>
>> Attached is a screenshot of the Monex report after uploading the file.
>>
>> Has anyone had a similar problem or has any advice how to deal with it?
>>
>> Many thanks in advance and best regards
>> Jannik Franz
>>
>>
>> Jannik Franz
>> Universität für Musik und darstellende Kunst Wien
>> Institut für Musikwissenschaft und Interpretationsforschung
>> Abteilung Wissenschaftszentrum Arnold Schönberg und die Wiener Schule
>> Schwarzenbergplatz 6/Zaunergasse 1-3
>> 1030 Wien
>> E-Mail: fr...@md...
>> _______________________________________________
>> 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
>

Re: [Exist-open] File upload leads to database crash

[Jean-Paul R. <re...@gm...>]

Dear Jannik,

I ran into a similar issue some time ago, and it was due to a problem with
a hidden character inserted into the file. This may or may not be your
case, but if you have a backup version of the file from when it worked
fine, you could transform it into code points, and do the same with the
current file, and see if they are truly identical.

Hope this helps,
JPR

On Sun, Sep 29, 2024 at 10:29 PM Jannik Franz <fr...@md...> wrote:

>
> Dear eXist-db community,
>
> in our project we are using eXist-db for over two years now and since a
> few weeks we are having a problem uploading a specific XML-file (via
> eXide's upload interface).
> As soon as the file is uploaded, the database crashes and the server has
> to be restarted.
> After the restart there remains an empty file in the database as a result
> of the interrupted upload process.
>
> The problem occurs only with this single file. It is a simple TEI-XML
> document, 68KB small and not special in any way (and it didn't cause any
> problems for the last 2 years).
>
> Attached is a screenshot of the Monex report after uploading the file.
>
> Has anyone had a similar problem or has any advice how to deal with it?
>
> Many thanks in advance and best regards
> Jannik Franz
>
>
> Jannik Franz
> Universität für Musik und darstellende Kunst Wien
> Institut für Musikwissenschaft und Interpretationsforschung
> Abteilung Wissenschaftszentrum Arnold Schönberg und die Wiener Schule
> Schwarzenbergplatz 6/Zaunergasse 1-3
> 1030 Wien
> E-Mail: fr...@md...
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>