Hi BaseX,
Did I mention recently what a great product you have here?
So I have found by tweaking webapp/WEB-INF/web.xml I can point BaseX to someplace other than its restxq directory to find its RESTXQ .xqm files. This is cool. (I am encapsulating code for maximum portability and this is a help.)
But in this project we are also looking forward to when we'll be serving multiple different datasets with different document types and logic, and we wish to keep them separate.
Will I be able to ask BaseX to look in more than one place for its RESTXQ? (For its databases?)
Thanks -- Wendell
-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^
Hi Wendell,
finally some feedback.
Did I mention recently what a great product you have here?
you did.. thanks anyway ;)
Will I be able to ask BaseX to look in more than one place for its RESTXQ? (For its databases?)
Per BaseX instance, there will only be a single database and RESTXQ path. What you can do is:
– run one web server and deploy several BaseX instances as WAR files with different configurations – use the existing configuration and specify your own conventions for database and RESTXQ directory names.
I would usually opt for the second solution, as long as the RESTXQ paths don’t overlap.
Hope this helps, Christian
Hi again Christian,
On Fri, Mar 1, 2013 at 5:16 AM, Christian Grün christian.gruen@gmail.com wrote:
Will I be able to ask BaseX to look in more than one place for its RESTXQ? (For its databases?)
Per BaseX instance, there will only be a single database and RESTXQ path. What you can do is:
– run one web server and deploy several BaseX instances as WAR files with different configurations – use the existing configuration and specify your own conventions for database and RESTXQ directory names.
I would usually opt for the second solution, as long as the RESTXQ paths don’t overlap.
If Arve's suggestion of using symlinks to manage the encapsulation amounts to your second suggestion, I concur that sounds like the simplest approach. It's our job to see that the RESTXQ paths don't overlap in any case isn't it? :-)
(The only question in my mind is how portable symlinks are across operating systems, but I have hopes as long as everything is NTFS, right? I'm sure you and many readers of this list know the answer to that question, and in any case one can always try.)
Thanks again, Wendell
If Arve's suggestion of using symlinks to manage the encapsulation amounts to your second suggestion, I concur that sounds like the simplest approach. It's our job to see that the RESTXQ paths don't overlap in any case isn't it? :-)
True, symbolic links can be used, too (at least, I guess, on Linux & Unix-based systems; you may have to try and see what happens). I’m not 100% sure what you are after here.. What’s the main reasons for not leaving all RESTXQ files in the restxq (sub)directories?
Hi,
Well, we've gone around on this ... given the tradeoffs and potential portability issues we've decided to break our separate application logic into different subdirectories inside restxq after all.
It's no big deal ... only a matter of making the best choice we can for something we expect to grow (in both size and complexity) -- fairly rapidly, at least potentially.
Thanks again, Wendell
On Fri, Mar 1, 2013 at 9:48 AM, Christian Grün christian.gruen@gmail.com wrote:
If Arve's suggestion of using symlinks to manage the encapsulation amounts to your second suggestion, I concur that sounds like the simplest approach. It's our job to see that the RESTXQ paths don't overlap in any case isn't it? :-)
True, symbolic links can be used, too (at least, I guess, on Linux & Unix-based systems; you may have to try and see what happens). I’m not 100% sure what you are after here.. What’s the main reasons for not leaving all RESTXQ files in the restxq (sub)directories?
-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^
basex-talk@mailman.uni-konstanz.de