I'm not really sure I understand how you need these..Are you rebuilding some sort of portlet container ? 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 maintain you link to the latest code. Ludovic 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 xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

------------------------------------------------------------------------

-- You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

------------------------------------------------------------------------

-- You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

Lillianne, Despite the various descriptions you have provided for your application requirements, I confess that I cannot draw a very good mental diagram of the client-side, server-side and any middle-ware that you are using to cobble your solution. So, it's rather likely that nothing of which I am going to offer will turn out to be of value to you; nonetheless, it is something I can contribute via this open system forum. 01. My own 'world view' [sent to Ludovic in the form of a diagram sometime back] is that a wiki is just part of the desired set of services to provide to my user community. [That user community is strictly friends and family members ranging in age from seven to seventy with modest computing resources in their homes and modest connection capabilities to the Internet. Since, however, my own background is in the development of corporate transaction processing systems, the infrastructure for this 'strictly for fun' set of services has most of the characteristics of a J2EE application designed for reliable corporate, customer-facing, work.] 02. Because of the beginning premise that the wiki is just part of the solution, I have worked rather harder on various aspects of integrating with Xwiki than on attempting to turn Xwiki into a Swiss Army Knife. [Once when working on the development team of a data warehouse shop, when someone added the ability to access SMTP via a Java User Defined Function, a wizened friend sent out an email saying something like, "Every piece of software, no matter how small, grows until it can be used to send email..."]. 03. Some of the pieces of the current client-server pair I have cobbled are: a. SWT for a 'richer client experience' which includes an embedded method of using the client's browser. [Current SWT limitation is that it has to be IE, even when the client has probably already made Firefox his preferred default, but since there is also need/desire to provide some nice SVG output, the IE implementation is not terribly bad -- we have a means to almost eliminate pop-ups. And, admittedly, I am not supporting the three family members who are died-in-the-wool Mac users in any case.] b. A Jabber server and the client libraries for XMPP support so that the members may safely engage in discussion groups without any fear of intrusion from unwanted postings. c. Tomcat for our webapp as well as Xwiki. Tomcat is NOT configured for any sharing of contexts. At the moment there are not even any instances when a servlet from our webapp redirects to a URL that resolves to Xwiki. At the moment, the client menu tree has discrete items like "Web Browsing", "Discussion Group", "Wiki", "Music", etc., and that client-side code is directing the user session to one or another webapp each running in a different tab of a tabbed window widget. d. The Apache xmlrpc library -- somewhat modified for our needs -- for very thin, very fast client-server interaction where full servlet overhead really isn't needed. This point only becomes clear when you consider that one of my objectives is to provide 'richer client experiences' even when the client has no network connection. So, often in our application, extensions to the JNLP discipline are used to download code and files that are locally resident. The SWT embedded browser is then just used for its familiar rendering capabilities. An xmlrpc 'transaction' will probably not return a complete html page, but may return some content that will be html-rendered then or at a later time when the user cannot stay connected. [The central suite of servers for the application -- two running Windows 2000, one running SuSE 9.3 -- is just running off of my single, personal ISP account. We don't even have the luxury of a Domain Name or a fixed IP address -- 'less is truly more' around here.] e. The Adobe SVG viewer, which is problematic since they will probably drop it in favor of their recent acquisition, so transition effects are now using the HTML+TIME extensions from Microsoft with hope that SMIL will be implemented in whatever comes next. f. Some TextToSpeech usage so that members can hear some on-line help spoken by a member of the community whose voice they know. 04. I have not had time to investigate a full LDAP implementation to solve the needs for authentication in the various services where authentication is required. [The user only has to authenticate when it would be dangerous to let unauthenticated usage continue. So, for example, if the person is just browsing, no authentication is required; if the person wants to hear the correct pronunciation of one of the Japanese Kana syllables and watch the correct drawing order demonstrated on the screen, no authentication is required. If, however, the user attempts to use the Wiki, an authentication challenge is presented. Since, my most successful hope will be -- when this is finally ready to go -- maybe 30 users, I guess I have the luxury of not really having to worry about managing some duplication of effort. When a new user is to be set up, s/he does need a userid and a password. So, the same userid and password is forced on Xwiki and the Jabber server. [Our extension of XWikiAuthService uses Cookies to pick up the necessary userid from whichever 'authentication incident' first occurs on the client.] 05. Now I am not even sure how to explain what we do with Sessions. When the client 'UserAgent' is the embedded instance of IE, the establishment of the SessionID is -- as far as I have been able to attempt it -- outside my control. When the client 'UserAgent', however, is using the xmlrpc protocol, I do have control over the Session usage on both sides of the network interface, so I set the JSESSIONID Cookie on the client side to be equal to the JSESSIONID that was first created by the Servlet Container on the server side. Granted this is only a small part of what I think you want to accomplish, but it is convenient to be able to have a many-to-one relationship between client agents and a webapp server. No matter whether straight browser-based HTTP 'transactions' are taking place, or modified xmlrpc-based HTTP 'transactions' are taking place, there is a single session with a single set of session objects being shared by different servlets. Depending upon how Tomcat determines when to create a new session -- and assign the JSESSIONID -- with two or more distinct webapps, I think you could use the same 'trick' to share the key application objects between those webapps. By looking at the results of request.getSession() and session.isNew(), I think I am tricking Tomcat into NOT creating a separate session for a client request. It finds a Cookie with a JSESSIONID that it knows about. If that 'lookup' for an already-assigned session id is honored across webapps, you can turn my many-to-one fanout into a many-to-many fanout. ----- Original Message ----- From: "Lilianne E. Blaze" <lilianne_blaze@tlen.pl> To: <xwiki-dev@objectweb.org> Sent: Sunday, June 26, 2005 11:14 Subject: Re: [xwiki-dev] Ability to change xwiki directories 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 xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

------------------------------------------------------------------------

-- You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

------------------------------------------------------------------------

-- You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

------------------------------------------------------------------------

-- You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

---------------------------------------------------------------------------- ----

-- You receive this message as a subscriber of the xwiki-dev@objectweb.org

mailing list.

To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws