exist-development — eXist Developer's List

[Exist-development] Curiously repetitive console output during startup of 2.0RC

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

Hi all,

I believe I've seen this since Dannes upgraded us the 2.0 builds to
Jetty 8 - but I'm not sure what it is.  During the eXist-db startup,
the console shows the following (in part):

15 Jan 2013 23:04:49,401 [main] INFO  (JettyStart.java
[lifeCycleStarting]:404) - Jetty server starting...
15 Jan 2013 23:04:49,405 [main] INFO  (Server.java [doStart]:268) -
jetty-8.1.8.v20121106
Null identity service, trying login service: null
Finding identity service: null
LoginService=org.eclipse.jetty.plus.jaas.JAASLoginService@2b43fd2a
identityService=org.eclipse.jetty.security.DefaultIdentityService@7ca1e696
15 Jan 2013 23:04:50,108 [main] INFO  (ContextHandler.java
[callContextInitialized]:772) - started eXist-db Open Source Native
XML Database
15 Jan 2013 23:04:50,109 [main] INFO  (ContextHandler.java
[callContextInitialized]:772) - started eXist-db Open Source Native
XML Database
15 Jan 2013 23:04:50,109 [main] INFO  (ContextHandler.java
[callContextInitialized]:772) - started eXist-db Open Source Native
XML Database
Logging already initialized. Skipping...
15 Jan 2013 23:04:52,107 [main] INFO  (NCSARequestLog.java
[doStart]:649) - Opened
/Users/Joe/workspace/exist-trunk/tools/jetty/logs/2013_01_16.request.log
15 Jan 2013 23:04:52,112 [main] INFO  (ScanningAppProvider.java
[doStart]:113) - Deployment monitor
/Users/Joe/workspace/exist-trunk/tools/jetty/contexts at interval 10
15 Jan 2013 23:04:52,116 [main] INFO  (ScanningAppProvider.java
[doStart]:113) - Deployment monitor
/Users/Joe/workspace/exist-trunk/tools/jetty/webapps at interval 10
15 Jan 2013 23:04:52,119 [main] INFO  (DeploymentManager.java
[addApp]:132) - Deployable added:
/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/homepage
Null identity service, trying login service:
org.eclipse.jetty.security.DefaultIdentityService@7ca1e696
Finding identity service:
org.eclipse.jetty.security.DefaultIdentityService@7ca1e696
LoginService=org.eclipse.jetty.plus.jaas.JAASLoginService@2b43fd2a
identityService=org.eclipse.jetty.security.DefaultIdentityService@7ca1e696
15 Jan 2013 23:04:52,183 [main] INFO  (ContextHandler.java
[callContextInitialized]:772) - started
o.e.j.w.WebAppContext{/homepage,file:/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/homepage/},/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/homepage
15 Jan 2013 23:04:52,183 [main] INFO  (ContextHandler.java
[callContextInitialized]:772) - started
o.e.j.w.WebAppContext{/homepage,file:/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/homepage/},/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/homepage
15 Jan 2013 23:04:52,184 [main] INFO  (DeploymentManager.java
[addApp]:132) - Deployable added:
/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/portal
Null identity service, trying login service:
org.eclipse.jetty.security.DefaultIdentityService@7ca1e696
Finding identity service:
org.eclipse.jetty.security.DefaultIdentityService@7ca1e696
LoginService=org.eclipse.jetty.plus.jaas.JAASLoginService@2b43fd2a
identityService=org.eclipse.jetty.security.DefaultIdentityService@7ca1e696
15 Jan 2013 23:04:52,230 [main] INFO  (ContextHandler.java
[callContextInitialized]:772) - started
o.e.j.w.WebAppContext{/,file:/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/portal/},/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/portal
15 Jan 2013 23:04:52,231 [main] INFO  (ContextHandler.java
[callContextInitialized]:772) - started
o.e.j.w.WebAppContext{/,file:/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/portal/},/Users/Joe/workspace/exist-trunk/tools/jetty/webapps/portal

I was wondering about all of the repetition here - notice all of the
references to "started eXist-db Open Source Native XML Database" and
"Null identity service, trying login service" and "started
o.e.j.w.WebAppContext" - these all appear at least 2 times.  Are these
really unique bits of information, or are they repetitive?

Thanks,
Joe

Re: [Exist-development] Tomcat realm - build by default?

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

FYI - After consulting with Dannes, I carried this proposal out in
rev. 18050.  After my change, Tomcat realm is still built by default,
but now you can disable it from the build by editing your
extensions/local.build.properties file to set
include.feature.tomcat-realm to false.

On Thu, Jan 10, 2013 at 3:25 PM, Joe Wicentowski <jo...@gm...> wrote:
> Hi all,
>
> Does anyone object to me making the building of tomcat-realm
> enforceable by local.build.properties? (See my original email about
> this below.)
>
> My proposal is to change lib/extensions/tomcat-realm/extension.xml
> lines 10-11 from:
>
>  <!--property name="extension.include" value="${include.feature.webdav}"/-->
>  <property name="extension.include" value="yes"/>
>
> ... to:
>
> <property name="extension.include" value="${include.feature.tomcat}"/>
>
> And then I would add a corresponding property to
> extensions/build.properties, defaulting to true:
>
> # Tomcat extension
> include.feature.tomcat = true
>
> My only question is whether tomcat counts as a feature, a module, or
> an extension -- with relation to the various categories included in
> build.properties.
>
> Thanks,
> Joe
>
> On Thu, Dec 6, 2012 at 4:30 PM, Joe Wicentowski <jo...@gm...> wrote:
>> Hi all,
>>
>> I noticed that the Tomcat extension seems to be turned on by default.
>> At least for me, when I build trunk, I get a
>> lib/extensions/exist-tomcat-realm.jar when the build is complete.
>> It's probably harmless, but shouldn't extensions be controlled by
>> extensions/local.build.properties?
>>
>> Joe

Re: [Exist-development] Upgrading Tika extension

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

Hi

On Thu, Jan 10, 2013 at 11:57 PM, Joe Wicentowski <jo...@gm...> wrote:

> Okay, thanks to Dannes's assistance with bizarre Maven dependencies,  we
> have upgraded Tika to 1.2 in trunk (rev. 18046), and we've updated
> Tika's POI jars to v3.9 to incorporate Claudius's brilliant fix to
> Outlook message date parsing (
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53784).  I also
> tested the CEX demo with the new libraries and confirmed that the
> contentextraction functionality still works.
>

Great to hear that Claudius' fix works for you, in combination with Tika
1.2.....

cheers

Dannes

-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] Upgrading Tika extension

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

Okay, thanks to Dannes's assistance with bizarre Maven dependencies,
we have upgraded Tika to 1.2 in trunk (rev. 18046), and we've updated
Tika's POI jars to v3.9 to incorporate Claudius's brilliant fix to
Outlook message date parsing
(https://issues.apache.org/bugzilla/show_bug.cgi?id=53784).  I also
tested the CEX demo with the new libraries and confirmed that the
contentextraction functionality still works.

Joe

On Thu, Jan 10, 2013 at 2:48 PM, Joe Wicentowski <jo...@gm...> wrote:
> Hi all,
>
> Tika 1.2 was released in July, and I wonder if it's worth upgrading
> from 1.1?  There are some nice changes:
> http://www.apache.org/dist/tika/CHANGES-1.2.txt.  I think upgrading is
> simply a matter of changing the dependency/@rev value in
> extensions/contentextraction/ivy.xml from 1.1 to 1.2.  I could even do
> this - but are there tests that would reveal any regression that I
> should run before committing such a change?
>
> Joe

Re: [Exist-development] Tomcat realm - build by default?

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

Hi all,

Does anyone object to me making the building of tomcat-realm
enforceable by local.build.properties? (See my original email about
this below.)

My proposal is to change lib/extensions/tomcat-realm/extension.xml
lines 10-11 from:

 <!--property name="extension.include" value="${include.feature.webdav}"/-->
 <property name="extension.include" value="yes"/>

... to:

<property name="extension.include" value="${include.feature.tomcat}"/>

And then I would add a corresponding property to
extensions/build.properties, defaulting to true:

# Tomcat extension
include.feature.tomcat = true

My only question is whether tomcat counts as a feature, a module, or
an extension -- with relation to the various categories included in
build.properties.

Thanks,
Joe

On Thu, Dec 6, 2012 at 4:30 PM, Joe Wicentowski <jo...@gm...> wrote:
> Hi all,
>
> I noticed that the Tomcat extension seems to be turned on by default.
> At least for me, when I build trunk, I get a
> lib/extensions/exist-tomcat-realm.jar when the build is complete.
> It's probably harmless, but shouldn't extensions be controlled by
> extensions/local.build.properties?
>
> Joe

[Exist-development] Upgrading Tika extension

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

Hi all,

Tika 1.2 was released in July, and I wonder if it's worth upgrading
from 1.1?  There are some nice changes:
http://www.apache.org/dist/tika/CHANGES-1.2.txt.  I think upgrading is
simply a matter of changing the dependency/@rev value in
extensions/contentextraction/ivy.xml from 1.1 to 1.2.  I could even do
this - but are there tests that would reveal any regression that I
should run before committing such a change?

Joe

Re: [Exist-development] Xpath error/problem still in trunk!

[Jens Ø. P. <oe...@gm...>]

Hi Wolfgang,

There is also this small thing that surfaced on the eXist-TEIXML list, that 
	
	$input//(tei:placeName, tei:persName)[@corresp=$corresp]

only took notice of the first item if a sequence constitutes a step.

I know that for most purposes,

	$input//(tei:placeName | tei:persName)[@corresp=$corresp]

would serve as well (and this works fine), but I think a sequence is allowed here (and I can see some use cases).

Cheers,

Jens

On Jan 2, 2013, at 7:50 AM, Wolfgang Meier <wol...@ex...> wrote:

> Anrzej,
>> This xpath error still exists (all puns intended) in the RC2.0 (trunk) version. I concerns me,
>> since there is obviously an issue deep in the parsing or execution of XPath expressions....which
>> might cause other issues.
> 
> I tried to fix this before RC2, but debugging the issue is really time consuming. The problem seems to appear in certain constellations only and after processing the first bunch of nodes. I'm still trying to find the real cause. Probably something simple, but hard to pinpoint.
> 
> Wolfgang
> 
> ------------------------------------------------------------------------------
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612 
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development

Re: [Exist-development] Xpath error/problem still in trunk!

[Wolfgang M. <wol...@ex...>]

Anrzej,
> This xpath error still exists (all puns intended) in the RC2.0 (trunk) version. I concerns me,
> since there is obviously an issue deep in the parsing or execution of XPath expressions....which
> might cause other issues.

I tried to fix this before RC2, but debugging the issue is really time consuming. The problem seems to appear in certain constellations only and after processing the first bunch of nodes. I'm still trying to find the real cause. Probably something simple, but hard to pinpoint.

Wolfgang

[Exist-development] Xpath error/problem still in trunk!

[Andrzej J. T. <an...@ch...>]

Wolfgang:

This xpath error still exists (all puns intended) in the RC2.0 (trunk) version.  I concerns me,
since there is obviously an issue deep in the parsing or execution of XPath expressions....which
might cause other issues.

I've attached both a text.xql file and test.xml file.  Put them in /db and then execute the test.xql.

It dies with the following exception:

	cannot convert xs:boolean('false') to a node set

Now if you look at the rather complex xpath statement, if you remove both the exists() and
normalize-space() comparisons at the end, it works.  Also works if you remove the "and @extension =
$id" clause....or if you remove the "@root = "2.16.840.1.113883.4.98" and" clause.

Very strange behaviour.  This is valid xpath...and worked fine in the older 1.5 version I used in
the past.  Almost seems like there is something going on with the parser or the optimizer that is
causing this weird error.

I know that if you split the different conditions into separate paths  eg [...][...] etc, it will
work, but the xpath in the test.xql sample file should be acceptable according to the xpath spec and
should not error out like this.

I'm not very conversant with the intricacies of the query/xpath engine/parser/optimizer, so was
hoping you could take a look.  Hopefully this test case will let you replicate the issue and we can
resolve this long standing bug before 2.0 goes final?

Thanks!

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] 2.0RC2 installation failed on OS X 10.8

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

That sounds like the culprit, Wolfgang.  Thank you!

Joe

On Tue, Jan 1, 2013 at 4:43 PM, Wolfgang Meier <wol...@ex...> wrote:
> Hi Joe,
>> Yes, that was the case - I had tried to install 2.0RC2 over 2.0RC(1).
>> Deleting it then installing RC2 succeeded. Odd that the previous
>> version interfered with installing the new version, but not a big deal
>
> When I searched for the error message, the first hit indicated an issue if you install a package created with izpack 5 over an older installation of izpack 4:
>
> http://jira.codehaus.org/browse/IZPACK-705
>
> I thus assumed you may have hit a similar problem because RC1 was build with izpack 5 whereas we moved back to izpack 4 for RC2 (due to the failing console mode support).
>> - although when I see warnings like, "Are you sure you want to install
>> in /Applications/eXist-db? It will overwrite the data in that
>> directory!" I assumed the installer would first wipe that directory,
>> no?
>
> It does not wipe the directory but just overwrites files. We recommend to never install over a previous installation. I'll see if we can change the warning message to be more clear about this.
>
> Wolfgang

Re: [Exist-development] 2.0RC2 installation failed on OS X 10.8

[Wolfgang M. <wol...@ex...>]

Hi Joe, 
> Yes, that was the case - I had tried to install 2.0RC2 over 2.0RC(1).
> Deleting it then installing RC2 succeeded. Odd that the previous
> version interfered with installing the new version, but not a big deal

When I searched for the error message, the first hit indicated an issue if you install a package created with izpack 5 over an older installation of izpack 4:

http://jira.codehaus.org/browse/IZPACK-705

I thus assumed you may have hit a similar problem because RC1 was build with izpack 5 whereas we moved back to izpack 4 for RC2 (due to the failing console mode support).
> - although when I see warnings like, "Are you sure you want to install
> in /Applications/eXist-db? It will overwrite the data in that
> directory!" I assumed the installer would first wipe that directory,
> no?

It does not wipe the directory but just overwrites files. We recommend to never install over a previous installation. I'll see if we can change the warning message to be more clear about this.

Wolfgang

Re: [Exist-development] 2.0RC2 installation failed on OS X 10.8

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

Hi Wolfgang,

Yes, that was the case - I had tried to install 2.0RC2 over 2.0RC(1).
Deleting it then installing RC2 succeeded.  Odd that the previous
version interfered with installing the new version, but not a big deal
- although when I see warnings like, "Are you sure you want to install
in /Applications/eXist-db?  It will overwrite the data in that
directory!" I assumed the installer would first wipe that directory,
no?

Joe

On Tue, Jan 1, 2013 at 4:20 PM, Wolfgang Meier <wol...@ex...> wrote:
> Hi Joe,
>> I just tried installing 2.0RC2 (r17988) on Mac OS X 10.8, and it
>> failed on step 6.
>
> This is strange because this is the system Dannes and I have used for building. I have Mac OS X 10.8.2 with Java 1.7.0_09. To be sure, I just downloaded the installer from Sourceforge instead of using my local one: it works as expected. Did you maybe install over an existing version in the same target directory?
>
> Wolfgang

Re: [Exist-development] 2.0RC2 installation failed on OS X 10.8

[Wolfgang M. <wol...@ex...>]

Hi Joe, 
> I just tried installing 2.0RC2 (r17988) on Mac OS X 10.8, and it
> failed on step 6. 

This is strange because this is the system Dannes and I have used for building. I have Mac OS X 10.8.2 with Java 1.7.0_09. To be sure, I just downloaded the installer from Sourceforge instead of using my local one: it works as expected. Did you maybe install over an existing version in the same target directory?

Wolfgang

[Exist-development] 2.0RC2 installation failed on OS X 10.8

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

Hi all,

I just tried installing 2.0RC2 (r17988) on Mac OS X 10.8, and it
failed on step 6.  I used only the defaults throughout the
installation process.  I'm attaching a screenshot of the error.  It
reads, "com.izforge.izpack.api.data.Pack."  When I click on OK, the
installer quits.

Joe

Re: [Exist-development] exist-db: dead link on site

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

Hi Maarten, James,

Thnx for reporting

On 31 Dec 2012, at 12:53 , James Fuller <ji...@we...> wrote:

> nice catch,
> 
> forwarding this to the existdev list
> 
> ---------- Forwarded message ----------
> From: Maarten Ligtvoet <ligtvoet@###.nl>
> Date: Sun, Dec 30, 2012 at 8:41 PM
> Subject: exist-db: dead link on site
> To: "jim.fuller@###.com" <jim.fuller@###.com>
> 
> 
> 
> I found a dead link on:
> 
> exist-db.org/exist/repo/repo.xml#d364e795
> 
> 
> Do you still maintain this page, or should I contact someone else?

The website that is currently visible on exist-db.org/ will be replaced soonish by http://demo.exist-db.org/exist/apps/doc/repo.xml ...

We tried to avoid as much as deadlinks in the current site, but we rather like to spend time to get 2.0 out :-) 
Please note that http://demo.exist-db.org/exist/apps/doc/repo.xml actually reflects the 2.0RC contents....

regards

Dannes

Re: [Exist-development] exist-db: dead link on site

[James F. <ji...@we...>]

nice catch,

forwarding this to the existdev list

J

---------- Forwarded message ----------
From: Maarten Ligtvoet <lig...@ni...>
Date: Sun, Dec 30, 2012 at 8:41 PM
Subject: exist-db: dead link on site
To: "jim...@we..." <jim...@we...>


Dear James,



I found a dead link on:

exist-db.org/exist/repo/repo.xml#d364e795



[quote]

8. Public Repository

The Public repository is empty by default and can be reached here.



[/quote]



The repo is not empty be default, and I think it should point here:

http://exist-db.org/exist/apps/public-repo/retrieve.html



Do you still maintain this page, or should I contact someone else?



greetings,


Maarten Ligtvoet
ICT-Architect

Nictiz
Nationaal ICT Instituut in de Zorg
Postbus 19121
2500 CC Den Haag
Oude Middenweg 55
2491 AC Den Haag
T 070 317 34 42
F 070 320 74 37
M 06 4378 3214
lig...@ni...
www.nictiz.nl

Dit bericht kan vertrouwelijke informatie bevatten die niet voor u
bestemd is. Indien u niet de geadresseerde bent of dit bericht
abusievelijk aan u is toegezonden, wordt u verzocht dat aan de
afzender te melden en het bericht te verwijderen. Nictiz aanvaardt
geen aansprakelijkheid voor schade, van welke aard ook, die verband
houdt met risico's verbonden aan het elektronisch verzenden van
berichten.

This message may contain confidential information that is not intended
for you. If you are not the addressee or if this message was sent to
you by mistake, you are requested to inform the sender and delete the
message. Nictiz accepts no liability for damage of any kind resulting
from the risks inherent in the electronic transmission of messages.

Re: [Exist-development] dashboard url

[Jens Ø. P. <oe...@gm...>]

Hi Wolfgang,

Did the

./build.sh clean
./build.sh clean-default-data-dir
./build.sh

routine on a co updating to 17969, and ran into this problem (easy enough to solve, by updating the dashboard to 0.2.7), but a completely fresh download of 17971 works fine (has 0.2.7), so I guess the repo was not cleaned after all? Sorry for the static.

Another small thing: when one goes into the package manager, one either wants to install or remove something (well, or to see which libraries are installed), so why not show the icons used for this, without having to hover over some invisible point?

Best,

Jens


On Dec 30, 2012, at 12:27 PM, Wolfgang Meier <wol...@ex...> wrote:

> Hi Jens,  
> 
> are you sure your webapp/controller.xql is up to date? I committed a fix for this yesterday.
> 
> Wolfgang  
> 
> 
> Am Sonntag, 30. Dezember 2012 um 12:24 schrieb Jens Østergaard Petersen:
> 
>> Hi,
>> 
>> A clean install of 17969 leads to the url <http://localhost:8080/exist/apps/db/dashboard/> from <http://localhost:8080/exist/>.
>> 
>> Jens
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. ON SALE this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_123012
>> _______________________________________________
>> Exist-development mailing list
>> Exi...@li... (mailto:Exi...@li...)
>> https://lists.sourceforge.net/lists/listinfo/exist-development
> 
> 
> 

Re: [Exist-development] dashboard url

[Wolfgang M. <wol...@ex...>]

Hi Jens,  

are you sure your webapp/controller.xql is up to date? I committed a fix for this yesterday.

Wolfgang  


Am Sonntag, 30. Dezember 2012 um 12:24 schrieb Jens Østergaard Petersen:

> Hi,
>  
> A clean install of 17969 leads to the url <http://localhost:8080/exist/apps/db/dashboard/> from <http://localhost:8080/exist/>.
>  
> Jens
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_123012
> _______________________________________________
> Exist-development mailing list
> Exi...@li... (mailto:Exi...@li...)
> https://lists.sourceforge.net/lists/listinfo/exist-development

[Exist-development] dashboard url

[Jens Ø. P. <oe...@gm...>]

Hi,

A clean install of 17969 leads to the url <http://localhost:8080/exist/apps/db/dashboard/> from <http://localhost:8080/exist/>.

Jens

[Exist-development] Admin Client documentation

[Jens Ø. P. <oe...@gm...>]

Hi,

The Admin Client documentation has become outdated after Adam's remake. Is anybody (else) thinking of reworking this?

I wonder if "put" and "get" are still supposed to work in interactive shell mode? I don't see that they do.

One would have to refer to ACLs, but there is no documentation on ACLs, as far as I can see.

Cheers,

Jens

Re: [Exist-development] [Exist-open] [ANN] exist-db.org offline for upgrade

[Jens Ø. P. <oe...@gm...>]

Hi Dannes,

The eXist-db Documentation app must be pre-17808. The search button "Go" does nothing.

Cheers,

Jens

On Dec 28, 2012, at 8:32 PM, Dannes Wessels <da...@ex...> wrote:

> Hi
> 
> On 28 Dec 2012, at 16:44 , Jens Østergaard Petersen <oe...@gm...> wrote:
> 
>> Would it be possible to update the XSLTForms Demo? What is displayed is the very first draft I made …. The XSLT Files are old as well.
> 
> thnx for triggering me; the new version is available now on http://demo.exist-db.org/exist/apps/XSLTForms-Demo/index.html (looks nice!)
> 
> 
>> 
>> Tamboti should probably be built to link to this URL: <http://demo.exist-db.org/exist/apps/library/modules/search/index.html>, not the one with our institute logo. The current version of Tamboti is 1.0.3.
> 
> not sure what you mean, but wolf says he'll pick up...
> 
> D.

Re: [Exist-development] [Exist-open] [ANN] exist-db.org offline for upgrade

[Jens Ø. P. <oe...@gm...>]

Hi,

I look forward to that!

Perhaps I am seeing problems where there are none, but if people interested in what this "eXist-db" thing is that everybody is talking about google for it and land on the demo site, they will be very mystified. Perhaps this site should have a banner stating what kind of site it is and where to find information on eXist-db.

Cheers,

Jens

On Dec 29, 2012, at 10:37 AM, Wolfgang Meier <wol...@ex...> wrote:

> Hi Jens, 
>> Is something being prepared to replace the (informative) home page at <http://exist-db.org>?
> 
> Yes, there will be a brand new home page for 2.0 final. We hope it will be a nice surprise ;-)
> 
> Wolfgang

Re: [Exist-development] help debugging "no supertype for empty()" warning when importing functx

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

Adam and Wolfgang, 

Fascinating discussion.  I always enjoy learning about how eXist-db works under the hood.  So many optimization that are there to help our queries run quickly and efficiently.  

Adam - I'd love to know more about how you tracked this down.  

The idea to add handling for this case sounds good.  

Thanks,
Joe

Sent from my iPhone


On Saturday, December 29, 2012 at 10:46 AM, Wolfgang Meier wrote:

> > Basically the outer xs:string uses the CastExpression class in eXist,
> > and at compilation time it needs to understand what the possible type
> > of the evaluated if/else expression could be. As such it gets the type
> > of the result of the 'then' branch of the if expression, and also get
> > the type of the result of the 'else' branch of the if expression. It
> > then tries to find a super-type of these two types
> > (Type.getCommonSuperType(x, y) in eXist Java code).
> > 
> 
> 
> Correct. Expression.returnsType is called to make a "best guess" of the possible return type of an expression. This is not always possible though (due to a lack of static type information), in which case Type.ITEM is returned.
> 
> The important point here is that returnsType should return a specific type like Type.NODE, if and only if we can be sure both clauses of the if...then...else return nodes. In this case the optimizer may choose a different evaluation strategy. On the other hand, if Type.ITEM is returned, the query engine should not make any assumption about the type of the sequence to be expected. The optimizer interprets Type.ITEM as: it's not possible to determine the correct type.
> 
> I would expect eXist to correctly process expressions returning empty() despite the warning in the logs. I actually think the EMPTY case should be handled by Type.getSuperType instead of printing a warning. I will check this.
> 
> Wolfgang 

Re: [Exist-development] help debugging "no supertype for empty()" warning when importing functx

[Wolfgang M. <wol...@ex...>]

> Basically the outer xs:string uses the CastExpression class in eXist,
> and at compilation time it needs to understand what the possible type
> of the evaluated if/else expression could be. As such it gets the type
> of the result of the 'then' branch of the if expression, and also get
> the type of the result of the 'else' branch of the if expression. It
> then tries to find a super-type of these two types
> (Type.getCommonSuperType(x, y) in eXist Java code).

Correct. Expression.returnsType is called to make a "best guess" of the possible return type of an expression. This is not always possible though (due to a lack of static type information), in which case Type.ITEM is returned.

The important point here is that returnsType should return a specific type like Type.NODE, if and only if we can be sure both clauses of the if...then...else return nodes. In this case the optimizer may choose a different evaluation strategy. On the other hand, if Type.ITEM is returned, the query engine should not make any assumption about the type of the sequence to be expected. The optimizer interprets Type.ITEM as: it's not possible to determine the correct type.

I would expect eXist to correctly process expressions returning empty() despite the warning in the logs. I actually think the EMPTY case should be handled by Type.getSuperType instead of printing a warning. I will check this.

Wolfgang

Re: [Exist-development] help debugging "no supertype for empty()" warning when importing functx

[Wolfgang M. <wol...@ex...>]

> @Override
> public int returnsType() {
> if(steps.isEmpty()) {
> return Type.EMPTY;
> } else {
> return steps.get(steps.size() - 1).returnsType();
> }
> }

This seems like the best solution, but I'm not sure if it has any effects on the query optimizer, which relies on the type information. I just think there must have been a reason why Type.NODE is returned and not Type.EMPTY. I suggest I change the code locally for a while and see if it triggers something we can't overlook right now.

Wolfgang