Hi Christian,
On 06/06/2015 02:39 PM, Christian Grün wrote:
Hi Ioan,
Just recently, there has been some discussion on Tomcat and BaseX on the mailing list. I think we managed to successully encounter various of the problems with Tomcats in the latest snapshot [1], so I will be interested in hearing more about your experiences with that version.
Sorry for my english expressing, which unfortunately are not helped me to be well understood!
I carefully watched to all recent discussions on the list, but what is of interest to us is different. I have seen that in these cases it is intended that each application to use a new instance of BaseX. And, on the same Tomcat, to use multiple separate instances of BaseX.
And, in general, I have seen that BaseX is used dedicated for a single application (very suitable for embeded), and used separated instances for other applications. But in our case is exactly the opposite.
We have some experience with web applications on Tomcat, made with JSP / Servlets and relational databases. The structure of the applications installed on web server looks like:
-webapps -app1 -app2 -app3
Each application is developed and deployed separately, as an war archive, having everything it needs inside.
We try to use BaseX in this way to access data directly in XML format. The structure should be something like:
-webapps -basex -bxapp1 -xqrepo1 -bxapp2 -xqrepo2 -bxapp3 -xqrepo3
We managed to make this model functional only if all 3 repositories we have put them together: or directly under BaseX, or in a separate application and setting according to this the path in context-param/restxqpath in web.xml.
But we want it so that each application to contain they repo. How?
It would be possible to set in web.xml, to restxqpath, a list of several repo? Or from somewhere to be told from where to load such a list? Maybe this would be an easier solution. It implies some security problems or other constraints? We looked a bit by sources, but not have identified which part it handles this.
Is welcomed any other idea.
Regarding CACHERESTXQ and .ignore: These features are already available in that snapshot as well (but they will only be officially announced with 8.3). Unless you don't build more complex RESTXQ applications, you won't probably need to care about these features.
Hope this helps, Christian
We tried this last version and, indeed, for what we want does not help us.
Many thanks for your understanding!
Ioan
Dear Ioan,
-webapps -basex -bxapp1 -xqrepo1 -bxapp2 -xqrepo2 -bxapp3 -xqrepo3
I see.. So you would like to have a single BaseX instance and three or more web applications that only contain webapp contents (restxq, repo, maybe database directories), right?
I don't think it can be done that easily right now, and I am not sure either how this would be done with any other Java web applications. Is there any particuar reason why would you want to avoid having more than one BaseX instance (apart from the issues discussed on previous posts)? What do the "xqrepo" directories contain?
Cheers, Christian
We managed to make this model functional only if all 3 repositories we have put them together: or directly under BaseX, or in a separate application and setting according to this the path in context-param/restxqpath in web.xml.
But we want it so that each application to contain they repo. How?
It would be possible to set in web.xml, to restxqpath, a list of several repo? Or from somewhere to be told from where to load such a list? Maybe this would be an easier solution. It implies some security problems or other constraints? We looked a bit by sources, but not have identified which part it handles this.
Is welcomed any other idea.
Regarding CACHERESTXQ and .ignore: These features are already available in that snapshot as well (but they will only be officially announced with 8.3). Unless you don't build more complex RESTXQ applications, you won't probably need to care about these features.
Hope this helps, Christian
We tried this last version and, indeed, for what we want does not help us.
Many thanks for your understanding!
Ioan
On 06/08/2015 11:01 PM, Christian Grün wrote:
Dear Ioan,
-webapps -basex -bxapp1 -xqrepo1 -bxapp2 -xqrepo2 -bxapp3 -xqrepo3
I see.. So you would like to have a single BaseX instance and three or more web applications that only contain webapp contents (restxq, repo, maybe database directories), right?
Yes, an instance of BaseX serving multiple applications. BaseX must ensure the role of database server and XQuery processor. The applications will interact with BaseX only via restxq, rest web service is disabled (in web.xml).
And yes, these applications would be desirable to have inside them the xq modules, one or more files contained in one folder like "xqrepo".
BaseX is installed (in .war format) on Tomcat, and it no longer changes, while applications are subject to frequent changes, both in the html, template, css, javascript ... and on the restxq queries. Therefore it would be good that "xqrepo" to be deployed together with the rest of the application to which it belongs.
The databases not need to be kept in separate locations.
Is there any particuar reason why would you want to avoid having more than one BaseX instance (apart from the issues discussed on previous posts)?
I started from the idea that Tomcat is a "container" of applications, many and distinct. And that too would not make sense to multiply BaseX for n times (with all its libraries and probably some resource consumption) within it.
On the other hand, seeking functionality watched by us, we took into account the option of using BaseX not deployed on Tomcat, but installed on system with Jetty embedded. But the problem remains unresolved if we have not restxq queries (like sql query in JSP) within each application.
What do the "xqrepo" directories contain?
Just files with .xqm or .xq extensions, containing the specific restxq functions of respective application. What we can now set for only one application such:
<context-param> <param-name>org.basex.restxqpath</param-name> <param-value>../bxapp1/xqrepo1</param-value> </context-param>
I do not really understand also what and how to use repopath setting (alongside numerous other things that do not know!). Repopath could help us with something on this line?
Cheers, Christian
All the best, Ioan
Hi Ioan,
I started from the idea that Tomcat is a "container" of applications, many and distinct. And that too would not make sense to multiply BaseX for n times (with all its libraries and probably some resource consumption) within it.
It would be interesting to see what other Tomcat users think about this. My experience with Tocat is rather limited, but I am not sure if your scenario could really work out. I can clearly see the motivation behind your planned architecture, but maybe it could be worthwhile to find out if it's a real bottleneck to deploy 3, 4 BaseX instances.
I do not really understand also what and how to use repopath setting (alongside numerous other things that do not know!). Repopath could help us with something on this line?
I invite you to check out our documentation [1].
Cheers, Christian
On 06/09/2015 03:48 PM, Christian Grün wrote:
It would be interesting to see what other Tomcat users think about this. My experience with Tocat is rather limited, but I am not sure if your scenario could really work out.
I also look forward to the views of some other users who use multiple BaseX applications simultaneously. The problem is not just to the Tomcat, but is valid to any Java web application server, including Jetty.
In the configurations tested by us, all is well if we have one single restxqpath and a structure that looks like this:
-webapps -basex -xqrepo -xq_app1 -xq_app2 -xq_app3 -bxapp1 -bxapp2 -bxapp3
And, in web.xml:
<context-param> <param-name>org.basex.restxqpath</param-name> <param-value>../xqrepo</param-value> </context-param>
It's uncomfortable to work in this mode, but if there's no other solution, we try to go forward on this way.
Thanks again, Ioan
Hello Ioan and rest!
My understanding is that you want to achieve: * one shared BaseX with databases for all your webapps * ease of maintaining the webapps separately, e.g having all relevant code to one webapp in one place
We try to achieve something similar, but we haven't come far yet and our architecture is the "regular" one BaseX per application. The reason for it is that our apps right now don't share any data yet, they only share some of the XQuery code. But maybe we can contribute to the discussion.
Right now we have factored out the shared XQuery code into a common module, which is maintained separately and each webapp deploys it's own copy of it. So each of our webapp has its "internal" XQuery code and this "shared" module. This is ofcourse risky, but we try our best with semantic versioning of the code and close coordination between the *two* developers.
One solution that pops up in my mind would be for you to use symlinks to the xquery code from your basex app. I haven't tried it so I'm not sure symlinks are supported. Your architecture would be like this:
webapps - BaseX - symlink to xqrepo1 - symlink to xqrepo2 - symlink to xqrepo3 - bxapp1 - xqrepo1 - bxapp2 - xqrepo2 - bxapp3 - xqrepo3
Thus your BaseX would be configured with the default xqrepo, and the filesystem would do the rest of the magic. Maybe Christian can comment on this?
Best regards Kristian K
09.06.2015 19:09, Ioan Fericel kirjutas:
On 06/09/2015 03:48 PM, Christian Grün wrote:
It would be interesting to see what other Tomcat users think about this. My experience with Tocat is rather limited, but I am not sure if your scenario could really work out.
I also look forward to the views of some other users who use multiple BaseX applications simultaneously. The problem is not just to the Tomcat, but is valid to any Java web application server, including Jetty.
In the configurations tested by us, all is well if we have one single restxqpath and a structure that looks like this:
-webapps -basex -xqrepo -xq_app1 -xq_app2 -xq_app3 -bxapp1 -bxapp2 -bxapp3
And, in web.xml:
<context-param> <param-name>org.basex.restxqpath</param-name> <param-value>../xqrepo</param-value> </context-param>
It's uncomfortable to work in this mode, but if there's no other solution, we try to go forward on this way.
Thanks again, Ioan
Hi Kristian, thanks for the suggestion. We tried symlinks variant and it works.
For the development is ok. For easy installation and portability across multiple destinations, it remains to follow.
Best regards, Ioan
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Ioan Fericel -
Kristian Kankainen