Hello, Ludovic Dubost wrote:
I'm not really sure I understand how you need these..Are you rebuilding some sort of portlet container ?
I need to be able to: 1) Use custom authorization, using information from HttpSession 2) Be able to include XWiki pages from main project pages, then include main project sub-pages from Xwiki's Velocity templates in a way so that these sub-pages work the same when included directly or through XWiki.
If you need shared Request and Response this means you are calling one webapps from the other.. In this case why can you put some data in the request context and/or use the Portlet API we have to call XWiki from your other app (or is the other way around ?).
For the shared Session, can't you access the session from the other webapp using the ServletContext and use this one ?
I tend to think you might hit quite a few problems having the webapps live together especially if we make modifications in the code in the future.. Some of the files are loaded by libs and not by XWiki.. You are going to put quite a mess in the directories which are going to make it difficult for you to
Yes, but libraries such as Velocity or Hibernate can be initialized from non-standard (such as mentioned "/WEB-INF/xwiki") locations, so this shouldn't be a problem.
maintain you link to the latest code.
On the contrary - I need it to avoid the mess. I did things like that before - it's not exactly pretty at the beginning, but the long-term benefits are worth it.
Ludovic
Greetings, Lilianne E. Blaze
Lilianne E. Blaze a écrit :
Hello, Unfortunately, that won't be enough, I've analyzed that option before. Basically I also need shared Request/Response/Session objects.
Greetings, Lilianne E. Blaze
Ludovic Dubost wrote:
Hi Lilianne,
I'm not sure that's the solution to your problem. I think you should look into the "cross-context" feature of Tomcat (Thanks benjamin from eXo for this info). This is the way exo accessed portlet context from a webapp
In your code ServletContext portletContext = portalContext.getContext("/" + portletApplicationName);
In the server.xml <Context path="/xwiki" docBase="content" debug="0" reloadable="true" crossContext="true"/>
It's the crossContext="true" that gives the right..
It's something like that that you should be looking for.
Ludovic
Lilianne E. Blaze a écrit :
Hello, For a project I work on I need ability to change all (or most) of XWiki directories, basically I need to: 1. Move everything from /WEB-INF/ to /WEB-INF/xwiki 2. Move everything from / to /xwiki 3. Everything in /WEB-INF/classes and /WEB-INF/lib can obviously remain where it is. 4. Merge two web.xml 5. Normally XWiki would have "/" directory on "/xwiki" context. What I need is for it to have "/xwiki" directory on "/" context.
Why: To be able to place XWiki on the same ServletContext as the main project, while maintaining "separate" directory structure. I have to use custom RightService and UserService which has to have access to main project's data through the ServletContext, so both this project and XWiki have to share the ServletContext, effectively being one web-app from container's point of view.
How: I was thinking about: 1. Modifying the default initialization so XWiki first tries to load /WEB-INF/xwiki.cfg, then if it fails /WEB-INF/xwiki/xwiki.cfg.
2.1. Having the ability to specify each configuration file (like hibernate.xml, velocity.properties) path in xwiki.cfg. or 2.2. Doing the same for every configuration file, first trying to load it from /WEB-INF/, then from /WEB-INF/xwiki/ (I think it's less prone to errors)
3. Changing the top-level directories (like /templates/) paths from xwiki.cfg
4. Changing the Struts paths (like /bin/)
Would such a functionality be welcome?
I think I can do much work on my own, but I'll probably need some pointers now and then.
Greetings, Lilianne E. Blaze
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws