June 2015 - BaseX-Talk - mailman.uni-konstanz.de

Strange path problem (revisited)
by Kristian Kankainen 01 Jun '15

01 Jun '15

Hello! I noticed that I get different results if I visit the following two urls: http://myhost.domain/webappname/ http://myhost.domain/webappname The only difference is the trailing slash. My RESTXQ has a path for '/' but not for ''. My setup is with Tomcat. The difference seems to be the basepath for the webapp. Static files etc are not found. This also applies for the BaseX DBA: http://myhost.domain/webappname/dba/login resolves correctly http://myhost.domain/webappname/dba/login/ doesn't find it's static files etc. For my own webapp, it's the other way around --- with the trailing slash everything works fine, without it the static files etc aren't found. Is it yet another Tomcat problem or can it be reproduced on your setups? Cheers! Kristian

1 0

Re: [basex-talk] Multiple BaseX Tomcat webapps
by Kristian Kankainen 01 Jun '15

01 Jun '15

Since this conversation accidentally went off-list somewhere on it's way... I am happy to announce that Christian now has solved the Tomcat problem. Cheers! Kristian 29.05.2015 20:48, Christian Grün kirjutas: > Hi Kristian, > > I'm quite positive I could fix some potential Tomcat-related issues > today! It shouldn't happen anymore that the database paths of multiple > instances are mixed up. Your feedback on the latest snapshot [1] is > welcome. > > Have a nice evening or even weekend, > Christian > > [1] http://files.basex.org/releases/latest/ > > > > On Fri, May 29, 2015 at 11:55 AM, Kristian Kankainen > <kristian(a)keeleleek.ee> wrote: >> Hi, I try to describe a possible solution scenario even though I am not at >> all familiar with Java. Please bare with me and help me to debug my scenario >> :-) >> >> I found Tomcat documentation for class loaders[1]. Since I don't know any >> Java, I can't really understand any of it. But it does state, that Tomcats >> way of loading classes is fundamentally different from standard Java class >> loading. Maybe this can be part of the problem? >> >> Also the comment at the end of the documentation asks about an attribute >> "delegate=true" that can impose (I guess) the standard Java way of loading >> classes... >> >> As I understand it, there is a way of achieving class loading in a way that >> allready loaded classes are re-used -- this I understand as the situation of >> our problem. >> >> Maybe the way of loading classes has to be explicitly spelled out in a >> context.xml file which BaseX doesn't have? >> >> Cheers >> Kristian >> >> [1] http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html >> >> >> >> 28.05.2015 12:45, Christian Grün kirjutas: >>> Hi Kristian, >>> >>> Thanks, keep on going, every feedback is valuable. >>> >>> Christian >>> >>> >>> On Thu, May 28, 2015 at 9:22 AM, Kristian Kankainen >>> <kristian(a)keeleleek.ee> wrote: >>>> I haven't found any solutions, but I wrote down what I noticed: >>>> >>>> None of my webapps have a corresponding context.xml file in: >>>> $CATALINA_BASE/conf/[enginename]/[hostname]/ >>>> >>>> Neither is there any default context file in: >>>> $CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.default >>>> >>>> So the only default values are read from: >>>> $CATALINA_BASE/conf/context.xml >>>> >>>> When looking at the WEB-INF/web.xml that is shipped with BaseX I notice >>>> it >>>> doesn't give the context parameter for: >>>> * restpath >>>> * webpath >>>> >>>> Comparing both of my webapps >>>> http://[...]/rest?command=info >>>> I noticed that one has EVENTPORT: 1985 set while the other lacks it >>>> completely, >>>> one has CACHEQUERY: false while the other lacks it completely, >>>> one has MAXHITS: -1 while the other lacks it completely. >>>> >>>> Please tell me to stop if you feel I clutter the list. I thought maybe it >>>> helps to share my observations. >>>> >>>> Best wishes >>>> Kristian >>>> >>>> >>>> >>>> 28.05.2015 09:03, Kristian Kankainen kirjutas: >>>>> I think it has to do with Tomcat webapps' context settings [1]. It >>>>> states >>>>> that there is some kind of default context that will be used if no other >>>>> contexts are matched. I'm reading it now and will try some >>>>> experimenting. >>>>> >>>>> I also note that my Tomcat setup is not configured for multiple >>>>> instances, >>>>> thus my CATALINA_BASE is the same as CATALINA_HOME. >>>>> >>>>> Cheers >>>>> Kristian >>>>> >>>>> [1]: http://tomcat.eki.ee/docs/config/context.html >>>>> >>>>> 27.05.2015 13:53, Christian Grün kirjutas: >>>>>> Hi Kristian, >>>>>> >>>>>>> I previously had BaseX 8.1.1 working as a Tomcat webapp and it all >>>>>>> worked >>>>>>> fine. I know tried to simply put BaseX82.war as another webapp, but >>>>>>> the >>>>>>> second webapp seems to connect to the BaseX instance in the first >>>>>>> webapp. >>>>>> True, same on my machine. It doesn't seem to be due to 8.2. Instead, >>>>>> Tomcat seems to adopts some options from a running BaseX instance (and >>>>>> the primary instance might differ after a restart of Tomcat): >>>>>> >>>>>> http://localhost:8080/BaseX811/rest?query=db:system() >>>>>> >>>>>> <system> >>>>>> <generalinformation> >>>>>> <version>8.1.1</version> >>>>>> </generalinformation> >>>>>> <globaloptions> >>>>>> <dbpath>C:\Program Files\Apache Software Foundation\Tomcat >>>>>> 8.0\webapps\BaseX811\data</dbpath> >>>>>> ... >>>>>> >>>>>> http://localhost:8080/BaseX82/rest?query=db:system() >>>>>> >>>>>> <system> >>>>>> <generalinformation> >>>>>> <version>8.2</version> >>>>>> <usedmemory>37 MB</usedmemory> >>>>>> </generalinformation> >>>>>> <globaloptions> >>>>>> <authmethod>Basic</authmethod> >>>>>> <dbpath>C:\Program Files\Apache Software Foundation\Tomcat >>>>>> 8.0\webapps\BaseX811\data</dbpath> >>>>>> ... >>>>>> >>>>>> I currently have no idea if this can be fixed in Tomcat or BaseX (I >>>>>> don't know such a behavior from Jetty), but... I'll try to find out >>>>>> more. >>>>>> >>>>>> Christian >>>>>

2 1

rest:resource vs db:list-details resource
by James Ball 01 Jun '15

01 Jun '15

Hello, If I use the REST interface to get details of the resources in a database (http://localhost:8984/rest/TEST-DATABASE for example) the result is rest:resource elements that include size. <rest:resource type="xml" content-type="application/xml" size="46”> I assumed that db:list-details was the XQuery equivalent but the resource elements it returns do not include size. <resource raw="false" content-type="application/xml" modified-date="2015-05-31T17:12:32.907Z”> I’m sure it is staring me in the face but I can’t work out how to get the size value from within XQuery. Can someone point me in the right direction? I’m trying to do some database pruning based on the size of the documents which would be very easy if I had rest:resource elements. Many thanks, James

2 2