submitting with method "post" and loosing session attributes

> Hi,
>
> I'm using struts/tiles with the nightly build of xforms (separartely
> deployed). I have successfully created and populated my xform, but now,
> when I try to submit the results back to another action using the "post"
> method, I loose my profile information that was stored in the session.
> This is what my submission looks like:
>
>    <xforms:submission id="test-submit"
>        action="http://localhost:8080/umadmin/someAction" method="post"
>        ref="instance('document-instance')/data/DocumentRevision"
> replace="all"/>
>
>    <xforms:submit submission="test-submit">
>        <xforms:label>Go to action!</xforms:label>
>    </xforms:submit>
>
> The complete flow is like this:
>
>  - setup: /xforms-jsp/* is setup to be filtered by OPS
>  - User logs into the website, profile information is stored in session
>  - form is generated by navigating to URL:
> http://localhost:8080/umadmin/xforms-jsp/some-app
>  - User fills in data
>  - User presses the submit button labeled "Go to action!" mentioned
> above
>  - PROBLEM: user is prompted for login again since no profile
> information was found in session
>
> How can I make sure the profile information is not lost on submission?

> method, I loose my profile information that was stored in the session.
> This is what my submission looks like:
>
>    <xforms:submission id="test-submit"
>        action="http://localhost:8080/umadmin/someAction" method="post"
>        ref="instance('document-instance')/data/DocumentRevision"
> replace="all"/>
>
>    <xforms:submit submission="test-submit">
>        <xforms:label>Go to action!</xforms:label>
>    </xforms:submit>
>
> The complete flow is like this:
>
>  - setup: /xforms-jsp/* is setup to be filtered by OPS
>  - User logs into the website, profile information is stored in

> method, I loose my profile information that was stored in the session.
> This is what my submission looks like:
>
>    <xforms:submission id="test-submit"
>        action="http://localhost:8080/umadmin/someAction" method="post"
>        ref="instance('document-instance')/data/DocumentRevision"
> replace="all"/>
>
>    <xforms:submit submission="test-submit">
>        <xforms:label>Go to action!</xforms:label>
>    </xforms:submit>
>
> The complete flow is like this:
>
>  - setup: /xforms-jsp/* is setup to be filtered by OPS
>  - User logs into the website, profile information is stored in

>  - form is generated by navigating to URL:
> http://localhost:8080/umadmin/xforms-jsp/some-app
>  - User fills in data
>  - User presses the submit button labeled "Go to action!" mentioned
> above
>  - PROBLEM: user is prompted for login again since no profile
> information was found in session
>
> How can I make sure the profile information is not lost on submission?
>
> Sincerely
> Gerrit
>
>
>
> --
> You receive this message as a subscriber of the [hidden email]

> Hi Chaminda,
>
> I'm also new to orbeon and xforms, so this might not be (most  
> probably)
> the correct way to do it, but it seems to be working for us so far.
> Here's how we set things up:
>
> - Our webapp is at /umadmin
> - Separate deployment to /ops
> - In the /umadmin context, the /umadmin/xforms-jsp/* is filtered by  
> OPS,
> so this is where we put the .jsp file that generates the XHTML/Xforms
> output (or in your case, you could simply put the .xhtml file  
> somewhere
> in that directory). As a side-note, maybe also tell you that you
> shouldn't put the .xml files that you load from the xform itself in  
> any
> directory in /umadmin/xforms-jsp/*.. I've lost a lot of time being
> puzzled by why it wasn't working...
> - We created a HttpServletResponseWrapper object to be able to capture
> the output of the page generated by Xforms (see later)
> - We add a cookie (JSESSIONID) with a path of "/" to that response
> object so it is accessible by both contexts and we don't loose our
> profile information put in the session during login
> - From within the servlet, we do a forward to the /xforms-jsp/* URL  
> that
> generates the actual form and capture the output generated by OPS:
>
> RequestDispatcher rd =
> servlet.getServletContext().getRequestDispatcher("/xforms-jsp/our-
> app/in
> dex.xhtml");
> rd.forward(request, new MyHttpServletResponseWrapper(response));
> form.setHTML(response.toString());
> return mapping.findForward("success");
>
> - This way, we can create a .jsp file and use "<%= form.getHTML()  
> %>" in
> the JSP file to actually include the generated form wherever we want  
> in
> the page.
> - As an additional benefit, this way of doing it allows us to use  
> tiles
> too
>
> - Next problem was when submitting the data in the form, this would  
> give
> us a URL like: http://localhost:8080/ops/xforms-server-submit which we
> didn't want, so here's how we "fixed" this:
>
> The target of the submission defined in the xform is another struts
> action. We defined a global forward in the struts-config.xml having  
> the
> 'redirect="true"' attribute pointing to the first action again. After
> doing the processing on the submitted data (by processing the
> request.getInputStream()), we simply do a
> 'mapping.findForward("ourforward");' which makes the client re-request
> the original .jsp file generating the form again...
>
>
> Again, I emphasise that this is probably not the way of working with
> Xforms, so any suggestions or remarks are most welcome..
>
> Hope this helps,
> Gerrit
>
>
>
> -----Original Message-----
> From: Chaminda [mailto:[hidden email]]
> Sent: Friday, November 16, 2007 10:34 AM
> To: [hidden email]
> Subject: Re: [ops-users] submitting with method "post" and loosing
> session attributes
>
>
> Hi Gerrit,
>
> Sorry for replying your thread to, This is not an answer for you
> problem.
> According to your problem I guess you are familiar with this. Thats  
> why
> Im
> posing my problem here,
>
> I want to send request to a servlet and in the servlet set a request
> attribute. Upto that part I know. But I  dont know how to dispatch the
> request to XHTML other that JSP.
>
>
> In JSP we do like this
>
> dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>
> How can I do this for xhtml,
>
> Thanks, Sorry again for posing to here
>
>
>
> Gerrit Germis-2 wrote:
>>
>> Hi,
>>
>> I'm using struts/tiles with the nightly build of xforms (separartely
>> deployed). I have successfully created and populated my xform, but
> now,
>> when I try to submit the results back to another action using the
> "post"
>> method, I loose my profile information that was stored in the  
>> session.
>> This is what my submission looks like:
>>
>>   <xforms:submission id="test-submit"
>>       action="http://localhost:8080/umadmin/someAction" method="post"
>>       ref="instance('document-instance')/data/DocumentRevision"
>> replace="all"/>
>>
>>   <xforms:submit submission="test-submit">
>>       <xforms:label>Go to action!</xforms:label>
>>   </xforms:submit>
>>
>> The complete flow is like this:
>>
>> - setup: /xforms-jsp/* is setup to be filtered by OPS
>> - User logs into the website, profile information is stored in
> session
>> - form is generated by navigating to URL:
>> http://localhost:8080/umadmin/xforms-jsp/some-app
>> - User fills in data
>> - User presses the submit button labeled "Go to action!" mentioned
>> above
>> - PROBLEM: user is prompted for login again since no profile
>> information was found in session
>>
>> How can I make sure the profile information is not lost on  
>> submission?
>>
>> Sincerely
>> Gerrit
>>
>>
>>
>> --
>> You receive this message as a subscriber of the [hidden email]
> mailing
>> list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
> ion-attributes-tf4803253.html#a13790034
> Sent from the ObjectWeb OPS - Users mailing list archive at  
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

> Gerrit,
>
> This is not just one way of using XForms or Orbeon Forms, so don't worry
> about doing something wrong. If the solution works for you, then that's
> great. So thanks for sharing it on the list!
>
> -Erik
>
>
> On Nov 16, 2007, at 11:43 AM, Gerrit Germis wrote:
>
>> Hi Chaminda,
>>
>> I'm also new to orbeon and xforms, so this might not be (most probably)
>> the correct way to do it, but it seems to be working for us so far.
>> Here's how we set things up:
>>
>> - Our webapp is at /umadmin
>> - Separate deployment to /ops
>> - In the /umadmin context, the /umadmin/xforms-jsp/* is filtered by OPS,
>> so this is where we put the .jsp file that generates the XHTML/Xforms
>> output (or in your case, you could simply put the .xhtml file somewhere
>> in that directory). As a side-note, maybe also tell you that you
>> shouldn't put the .xml files that you load from the xform itself in any
>> directory in /umadmin/xforms-jsp/*.. I've lost a lot of time being
>> puzzled by why it wasn't working...
>> - We created a HttpServletResponseWrapper object to be able to capture
>> the output of the page generated by Xforms (see later)
>> - We add a cookie (JSESSIONID) with a path of "/" to that response
>> object so it is accessible by both contexts and we don't loose our
>> profile information put in the session during login
>> - From within the servlet, we do a forward to the /xforms-jsp/* URL that
>> generates the actual form and capture the output generated by OPS:
>>
>> RequestDispatcher rd =
>> servlet.getServletContext().getRequestDispatcher("/xforms-jsp/our-app/in
>> dex.xhtml");
>> rd.forward(request, new MyHttpServletResponseWrapper(response));
>> form.setHTML(response.toString());
>> return mapping.findForward("success");
>>
>> - This way, we can create a .jsp file and use "<%= form.getHTML() %>" in
>> the JSP file to actually include the generated form wherever we want in
>> the page.
>> - As an additional benefit, this way of doing it allows us to use tiles
>> too
>>
>> - Next problem was when submitting the data in the form, this would give
>> us a URL like: http://localhost:8080/ops/xforms-server-submit which we
>> didn't want, so here's how we "fixed" this:
>>
>> The target of the submission defined in the xform is another struts
>> action. We defined a global forward in the struts-config.xml having the
>> 'redirect="true"' attribute pointing to the first action again. After
>> doing the processing on the submitted data (by processing the
>> request.getInputStream()), we simply do a
>> 'mapping.findForward("ourforward");' which makes the client re-request
>> the original .jsp file generating the form again...
>>
>>
>> Again, I emphasise that this is probably not the way of working with
>> Xforms, so any suggestions or remarks are most welcome..
>>
>> Hope this helps,
>> Gerrit
>>
>>
>>
>> -----Original Message-----
>> From: Chaminda [mailto:[hidden email]]
>> Sent: Friday, November 16, 2007 10:34 AM
>> To: [hidden email]
>> Subject: Re: [ops-users] submitting with method "post" and loosing
>> session attributes
>>
>>
>> Hi Gerrit,
>>
>> Sorry for replying your thread to, This is not an answer for you
>> problem.
>> According to your problem I guess you are familiar with this. Thats why
>> Im
>> posing my problem here,
>>
>> I want to send request to a servlet and in the servlet set a request
>> attribute. Upto that part I know. But I  dont know how to dispatch the
>> request to XHTML other that JSP.
>>
>>
>> In JSP we do like this
>>
>> dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>>
>> How can I do this for xhtml,
>>
>> Thanks, Sorry again for posing to here
>>
>>
>>
>> Gerrit Germis-2 wrote:
>> >
>> > Hi,
>> >
>> > I'm using struts/tiles with the nightly build of xforms (separartely
>> > deployed). I have successfully created and populated my xform, but
>> now,
>> > when I try to submit the results back to another action using the
>> "post"
>> > method, I loose my profile information that was stored in the session.
>> > This is what my submission looks like:
>> >
>> >   <xforms:submission id="test-submit"
>> >       action="http://localhost:8080/umadmin/someAction" method="post"
>> >       ref="instance('document-instance')/data/DocumentRevision"
>> > replace="all"/>
>> >
>> >   <xforms:submit submission="test-submit">
>> >       <xforms:label>Go to action!</xforms:label>
>> >   </xforms:submit>
>> >
>> > The complete flow is like this:
>> >
>> > - setup: /xforms-jsp/* is setup to be filtered by OPS
>> > - User logs into the website, profile information is stored in
>> session
>> > - form is generated by navigating to URL:
>> > http://localhost:8080/umadmin/xforms-jsp/some-app
>> > - User fills in data
>> > - User presses the submit button labeled "Go to action!" mentioned
>> > above
>> > - PROBLEM: user is prompted for login again since no profile
>> > information was found in session
>> >
>> > How can I make sure the profile information is not lost on submission?
>> >
>> > Sincerely
>> > Gerrit
>> >
>> >
>> >
>> > --
>> > You receive this message as a subscriber of the [hidden email]
>> mailing
>> > list.
>> > To unsubscribe: mailto:[hidden email]
>> > For general help: mailto:[hidden email]?subject=help
>> > OW2 mailing lists service home page: http://www.ow2.org/wws
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
>> ion-attributes-tf4803253.html#a13790034
>> Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com.
>>
>>
>> --
>> You receive this message as a subscriber of the [hidden email] mailing
>> list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>

> Hi Erik,
>
>
> I have also faced the same problem before, i.e. loosing session  
> attributes when submitting with method "post" (on the first  
> submission only), but unfortunately I haven't found a working  
> solution yet.
>
> I attached a simple example web application (servlet) which  
> reproduces the problem. When the servlet is requested (e.g., http://localhost:8080/OFSession)
> , the doGet() method responses with a generated XHTML+XForms page.  
> The generated page contains the following data:
> *Current (at the time when doGet() method was being processed)  
> session ID
> *Current (at the time when doGet() method was being processed) &  
> stored attribute value (i.e. session ID)
>
>
> The generated page also contains XForms markup, which submits a  
> request with method "post" to the servlet. The servlet responses  
> with an XML document. The XML document contains the following data:
> *Current (at the time when doPost() method was being processed)  
> session ID
> *Current (at the time when doPost() method was being processed) &  
> stored attribute value (i.e. session ID)
>
>
> Logically, all four values ought to be same, right?. However, if the  
> XForms request is submitted automatically upon the "xforms-ready"  
> event, then on the first time/submission the session ID has changed  
> and, therefore, also the stored session attribute value is null  
> (cannot be found from this session because it is the same session  
> where to the attribute was set). If the request is submitted again  
> (CTRL+F5 in Firefox), then the values match.
>
> If the XForms request is submitted manually, i.e. by clicking a  
> button/trigger, then all four values are the same even on the first  
> time/submission. In addition, the example works fine also when used  
> without Orbeon Forms XForms Engine (ops xforms filter turned off and  
> using Mozilla XForms plug-in).
>
> I'm using Orbeon Forms 3.6.0rc1 (filter set the the URL "/*") with  
> standard configurations. You can test the example/behaviour with  
> manual/automatic submission by commenting two lines (marked) in the  
> servlet.SessionTesterServlet.java class (lines 56 and 67.
>
> Is this a bug in Oreon Forms? If not, how do I need to modify my  
> example web application to make it work also on the first time/
> submission?
>
> Best regards
>
>
> -Markku Laine
>
> On Fri, 16 Nov 2007, Erik Bruchez wrote:
>
>> Gerrit,
>>
>> This is not just one way of using XForms or Orbeon Forms, so don't  
>> worry about doing something wrong. If the solution works for you,  
>> then that's great. So thanks for sharing it on the list!
>>
>> -Erik
>>
>>
>> On Nov 16, 2007, at 11:43 AM, Gerrit Germis wrote:
>>
>>> Hi Chaminda,
>>> I'm also new to orbeon and xforms, so this might not be (most  
>>> probably)
>>> the correct way to do it, but it seems to be working for us so far.
>>> Here's how we set things up:
>>> - Our webapp is at /umadmin
>>> - Separate deployment to /ops
>>> - In the /umadmin context, the /umadmin/xforms-jsp/* is filtered  
>>> by OPS,
>>> so this is where we put the .jsp file that generates the XHTML/
>>> Xforms
>>> output (or in your case, you could simply put the .xhtml file  
>>> somewhere
>>> in that directory). As a side-note, maybe also tell you that you
>>> shouldn't put the .xml files that you load from the xform itself  
>>> in any
>>> directory in /umadmin/xforms-jsp/*.. I've lost a lot of time being
>>> puzzled by why it wasn't working...
>>> - We created a HttpServletResponseWrapper object to be able to  
>>> capture
>>> the output of the page generated by Xforms (see later)
>>> - We add a cookie (JSESSIONID) with a path of "/" to that response
>>> object so it is accessible by both contexts and we don't loose our
>>> profile information put in the session during login
>>> - From within the servlet, we do a forward to the /xforms-jsp/*  
>>> URL that
>>> generates the actual form and capture the output generated by OPS:
>>> RequestDispatcher rd =
>>> servlet.getServletContext().getRequestDispatcher("/xforms-jsp/our-
>>> app/in
>>> dex.xhtml");
>>> rd.forward(request, new MyHttpServletResponseWrapper(response));
>>> form.setHTML(response.toString());
>>> return mapping.findForward("success");
>>> - This way, we can create a .jsp file and use "<%= form.getHTML()  
>>> %>" in
>>> the JSP file to actually include the generated form wherever we  
>>> want in
>>> the page.
>>> - As an additional benefit, this way of doing it allows us to use  
>>> tiles
>>> too
>>> - Next problem was when submitting the data in the form, this  
>>> would give
>>> us a URL like: http://localhost:8080/ops/xforms-server-submit 
>>> which we
>>> didn't want, so here's how we "fixed" this:
>>> The target of the submission defined in the xform is another struts
>>> action. We defined a global forward in the struts-config.xml  
>>> having the
>>> 'redirect="true"' attribute pointing to the first action again.  
>>> After
>>> doing the processing on the submitted data (by processing the
>>> request.getInputStream()), we simply do a
>>> 'mapping.findForward("ourforward");' which makes the client re-
>>> request
>>> the original .jsp file generating the form again...
>>> Again, I emphasise that this is probably not the way of working with
>>> Xforms, so any suggestions or remarks are most welcome..
>>> Hope this helps,
>>> Gerrit
>>> -----Original Message-----
>>> From: Chaminda [mailto:[hidden email]]
>>> Sent: Friday, November 16, 2007 10:34 AM
>>> To: [hidden email]
>>> Subject: Re: [ops-users] submitting with method "post" and loosing
>>> session attributes
>>> Hi Gerrit,
>>> Sorry for replying your thread to, This is not an answer for you
>>> problem.
>>> According to your problem I guess you are familiar with this.  
>>> Thats why
>>> Im
>>> posing my problem here,
>>> I want to send request to a servlet and in the servlet set a request
>>> attribute. Upto that part I know. But I  dont know how to dispatch  
>>> the
>>> request to XHTML other that JSP.
>>> In JSP we do like this
>>> dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>>> How can I do this for xhtml,
>>> Thanks, Sorry again for posing to here
>>> Gerrit Germis-2 wrote:
>>> > > Hi,
>>> > > I'm using struts/tiles with the nightly build of xforms  
>>> (separartely
>>> > deployed). I have successfully created and populated my xform, but
>>> now,
>>> > when I try to submit the results back to another action using the
>>> "post"
>>> > method, I loose my profile information that was stored in the  
>>> session.
>>> > This is what my submission looks like:
>>> > >   <xforms:submission id="test-submit"
>>> >       action="http://localhost:8080/umadmin/someAction"  
>>> method="post"
>>> >       ref="instance('document-instance')/data/DocumentRevision"
>>> > replace="all"/>
>>> > >   <xforms:submit submission="test-submit">
>>> >       <xforms:label>Go to action!</xforms:label>
>>> >   </xforms:submit>
>>> > > The complete flow is like this:
>>> > > - setup: /xforms-jsp/* is setup to be filtered by OPS
>>> > - User logs into the website, profile information is stored in
>>> session
>>> > - form is generated by navigating to URL:
>>> > http://localhost:8080/umadmin/xforms-jsp/some-app
>>> > - User fills in data
>>> > - User presses the submit button labeled "Go to action!" mentioned
>>> > above
>>> > - PROBLEM: user is prompted for login again since no profile
>>> > information was found in session
>>> > > How can I make sure the profile information is not lost on  
>>> submission?
>>> > > Sincerely
>>> > Gerrit
>>> > > > > --
>>> > You receive this message as a subscriber of the [hidden email]
>>> mailing
>>> > list.
>>> > To unsubscribe: mailto:[hidden email]
>>> > For general help: mailto:[hidden email]?subject=help
>>> > OW2 mailing lists service home page: http://www.ow2.org/wws
>>> > > --
>>> View this message in context:
>>> http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
>>> ion-attributes-tf4803253.html#a13790034
>>> Sent from the ObjectWeb OPS - Users mailing list archive at  
>>> Nabble.com.
>>> --
>>> You receive this message as a subscriber of the [hidden email]  
>>> mailing list.
>>> To unsubscribe: mailto:[hidden email]
>>> For general help: mailto:[hidden email]?subject=help
>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>
> --
> Markku Laine <[hidden email]>
> Research assistant, Helsinki University of Technology
> Telecommunications Software and Multimedia Laboratory
> P.O.Box 5400, FIN-02015 HUT, FINLAND
> Mobile. +358-50-565 8179 (Finland)
> Mobile.  +64-21-037 3605 (New Zealand, 01 Oct - 21 Dec,  
> 2007)<OFSession.war>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

> Hi Erik,
>
>
> I have also faced the same problem before, i.e. loosing session  
> attributes when submitting with method "post" (on the first  
> submission only), but unfortunately I haven't found a working  
> solution yet.
>
> I attached a simple example web application (servlet) which  
> reproduces the problem. When the servlet is requested (e.g., http://localhost:8080/OFSession)
> , the doGet() method responses with a generated XHTML+XForms page.  
> The generated page contains the following data:
> *Current (at the time when doGet() method was being processed)  
> session ID
> *Current (at the time when doGet() method was being processed) &  
> stored attribute value (i.e. session ID)
>
>
> The generated page also contains XForms markup, which submits a  
> request with method "post" to the servlet. The servlet responses  
> with an XML document. The XML document contains the following data:
> *Current (at the time when doPost() method was being processed)  
> session ID
> *Current (at the time when doPost() method was being processed) &  
> stored attribute value (i.e. session ID)
>
>
> Logically, all four values ought to be same, right?. However, if the  
> XForms request is submitted automatically upon the "xforms-ready"  
> event, then on the first time/submission the session ID has changed  
> and, therefore, also the stored session attribute value is null  
> (cannot be found from this session because it is the same session  
> where to the attribute was set). If the request is submitted again  
> (CTRL+F5 in Firefox), then the values match.
>
> If the XForms request is submitted manually, i.e. by clicking a  
> button/trigger, then all four values are the same even on the first  
> time/submission. In addition, the example works fine also when used  
> without Orbeon Forms XForms Engine (ops xforms filter turned off and  
> using Mozilla XForms plug-in).
>
> I'm using Orbeon Forms 3.6.0rc1 (filter set the the URL "/*") with  
> standard configurations. You can test the example/behaviour with  
> manual/automatic submission by commenting two lines (marked) in the  
> servlet.SessionTesterServlet.java class (lines 56 and 67.
>
> Is this a bug in Oreon Forms? If not, how do I need to modify my  
> example web application to make it work also on the first time/
> submission?
>
> Best regards
>
>
> -Markku Laine
>
> On Fri, 16 Nov 2007, Erik Bruchez wrote:
>
>> Gerrit,
>>
>> This is not just one way of using XForms or Orbeon Forms, so don't  
>> worry about doing something wrong. If the solution works for you,  
>> then that's great. So thanks for sharing it on the list!
>>
>> -Erik
>>
>>
>> On Nov 16, 2007, at 11:43 AM, Gerrit Germis wrote:
>>
>>> Hi Chaminda,
>>> I'm also new to orbeon and xforms, so this might not be (most  
>>> probably)
>>> the correct way to do it, but it seems to be working for us so far.
>>> Here's how we set things up:
>>> - Our webapp is at /umadmin
>>> - Separate deployment to /ops
>>> - In the /umadmin context, the /umadmin/xforms-jsp/* is filtered  
>>> by OPS,
>>> so this is where we put the .jsp file that generates the XHTML/
>>> Xforms
>>> output (or in your case, you could simply put the .xhtml file  
>>> somewhere
>>> in that directory). As a side-note, maybe also tell you that you
>>> shouldn't put the .xml files that you load from the xform itself  
>>> in any
>>> directory in /umadmin/xforms-jsp/*.. I've lost a lot of time being
>>> puzzled by why it wasn't working...
>>> - We created a HttpServletResponseWrapper object to be able to  
>>> capture
>>> the output of the page generated by Xforms (see later)
>>> - We add a cookie (JSESSIONID) with a path of "/" to that response
>>> object so it is accessible by both contexts and we don't loose our
>>> profile information put in the session during login
>>> - From within the servlet, we do a forward to the /xforms-jsp/*  
>>> URL that
>>> generates the actual form and capture the output generated by OPS:
>>> RequestDispatcher rd =
>>> servlet.getServletContext().getRequestDispatcher("/xforms-jsp/our-
>>> app/in
>>> dex.xhtml");
>>> rd.forward(request, new MyHttpServletResponseWrapper(response));
>>> form.setHTML(response.toString());
>>> return mapping.findForward("success");
>>> - This way, we can create a .jsp file and use "<%= form.getHTML()  
>>> %>" in
>>> the JSP file to actually include the generated form wherever we  
>>> want in
>>> the page.
>>> - As an additional benefit, this way of doing it allows us to use  
>>> tiles
>>> too
>>> - Next problem was when submitting the data in the form, this  
>>> would give
>>> us a URL like: http://localhost:8080/ops/xforms-server-submit 
>>> which we
>>> didn't want, so here's how we "fixed" this:
>>> The target of the submission defined in the xform is another struts
>>> action. We defined a global forward in the struts-config.xml  
>>> having the
>>> 'redirect="true"' attribute pointing to the first action again.  
>>> After
>>> doing the processing on the submitted data (by processing the
>>> request.getInputStream()), we simply do a
>>> 'mapping.findForward("ourforward");' which makes the client re-
>>> request
>>> the original .jsp file generating the form again...
>>> Again, I emphasise that this is probably not the way of working with
>>> Xforms, so any suggestions or remarks are most welcome..
>>> Hope this helps,
>>> Gerrit
>>> -----Original Message-----
>>> From: Chaminda [mailto:[hidden email]]
>>> Sent: Friday, November 16, 2007 10:34 AM
>>> To: [hidden email]
>>> Subject: Re: [ops-users] submitting with method "post" and loosing
>>> session attributes
>>> Hi Gerrit,
>>> Sorry for replying your thread to, This is not an answer for you
>>> problem.
>>> According to your problem I guess you are familiar with this.  
>>> Thats why
>>> Im
>>> posing my problem here,
>>> I want to send request to a servlet and in the servlet set a request
>>> attribute. Upto that part I know. But I  dont know how to dispatch  
>>> the
>>> request to XHTML other that JSP.
>>> In JSP we do like this
>>> dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>>> How can I do this for xhtml,
>>> Thanks, Sorry again for posing to here
>>> Gerrit Germis-2 wrote:
>>> > > Hi,
>>> > > I'm using struts/tiles with the nightly build of xforms  
>>> (separartely
>>> > deployed). I have successfully created and populated my xform, but
>>> now,
>>> > when I try to submit the results back to another action using the
>>> "post"
>>> > method, I loose my profile information that was stored in the  
>>> session.
>>> > This is what my submission looks like:
>>> > >   <xforms:submission id="test-submit"
>>> >       action="http://localhost:8080/umadmin/someAction"  
>>> method="post"
>>> >       ref="instance('document-instance')/data/DocumentRevision"
>>> > replace="all"/>
>>> > >   <xforms:submit submission="test-submit">
>>> >       <xforms:label>Go to action!</xforms:label>
>>> >   </xforms:submit>
>>> > > The complete flow is like this:
>>> > > - setup: /xforms-jsp/* is setup to be filtered by OPS
>>> > - User logs into the website, profile information is stored in
>>> session
>>> > - form is generated by navigating to URL:
>>> > http://localhost:8080/umadmin/xforms-jsp/some-app
>>> > - User fills in data
>>> > - User presses the submit button labeled "Go to action!" mentioned
>>> > above
>>> > - PROBLEM: user is prompted for login again since no profile
>>> > information was found in session
>>> > > How can I make sure the profile information is not lost on  
>>> submission?
>>> > > Sincerely
>>> > Gerrit
>>> > > > > --
>>> > You receive this message as a subscriber of the [hidden email]
>>> mailing
>>> > list.
>>> > To unsubscribe: mailto:[hidden email]
>>> > For general help: mailto:[hidden email]?subject=help
>>> > OW2 mailing lists service home page: http://www.ow2.org/wws
>>> > > --
>>> View this message in context:
>>> http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
>>> ion-attributes-tf4803253.html#a13790034
>>> Sent from the ObjectWeb OPS - Users mailing list archive at  
>>> Nabble.com.
>>> --
>>> You receive this message as a subscriber of the [hidden email]  
>>> mailing list.
>>> To unsubscribe: mailto:[hidden email]
>>> For general help: mailto:[hidden email]?subject=help
>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>
> --
> Markku Laine <[hidden email]>
> Research assistant, Helsinki University of Technology
> Telecommunications Software and Multimedia Laboratory
> P.O.Box 5400, FIN-02015 HUT, FINLAND
> Mobile. +358-50-565 8179 (Finland)
> Mobile.  +64-21-037 3605 (New Zealand, 01 Oct - 21 Dec,  
> 2007)<OFSession.war>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

> Markku,
>
> I investigated this a bit. Thanks for the reproducible case. It does  
> seem to be a little tricky!
>
> Here are my findings:
>
> 1. Web browser initially doesn't send any session cooke
> 2. /OFSession servlet creates session with id FOO
> 3. XForms filter cross-context forwards request to /ops servlet with  
> XForms content
> 4. Orbeon Forms processes XForms content and performs submission  
> upon xforms-ready
> 5. Submission attempts to forward JSESSION cookie but doesn't find  
> any so none is forwarded
> 6. Submission request hits /OFSession again, and since there is no  
> JSESSION id cookie, a new session BAR is created
> 7. Problem!
>
> The main issue is with #5 above. The session created in /OFSession  
> is new, and Tomcat doesn't create the session cookie at that point,  
> so /ops doesn't get any cookie from the forwarded request. What's  
> more troubling though is that if you call request.getSession(false),  
> no session object is returned either. However, if you call  
> request.getSession(true), you get a session with id "FOO", which is  
> what we want.
>
> So we could in theory force the creation of a session, get the  
> session id, and use this id to create a new JSESSIONID cookie to  
> forward during submission if we don't find one in the first place.  
> However this is not great because we may create a session needlessly.
>
> Another solution would be for the XForms filter to store the session  
> id into the request, and then the XForms submission could use that  
> session id. Or, similarly, simply information that a session is  
> available. Then the XForms submission would know that it must call  
> request.getSession(true). This code could actually be hidden in  
> ServletExternalContext.
>
> The latter possibility sounds reasonably good. The only drag,  
> besides the relative complexity of the code, is that it's not clear  
> to me whether this is a Tomcat-only issue and/or solution.
>
> I entered a bug to track this:
>
> http://forge.objectweb.org/tracker/index.php?func=detail&aid=308023&group_id=168&atid=350207
>
> Any thoughts on the above?
>
> -Erik
>
> On Nov 28, 2007, at 3:24 AM, .::: Markku :::. wrote:
>
>> Hi Erik,
>>
>>
>> I have also faced the same problem before, i.e. loosing session  
>> attributes when submitting with method "post" (on the first  
>> submission only), but unfortunately I haven't found a working  
>> solution yet.
>>
>> I attached a simple example web application (servlet) which  
>> reproduces the problem. When the servlet is requested (e.g., http://localhost:8080/OFSession)
>> , the doGet() method responses with a generated XHTML+XForms page.  
>> The generated page contains the following data:
>> *Current (at the time when doGet() method was being processed)  
>> session ID
>> *Current (at the time when doGet() method was being processed) &  
>> stored attribute value (i.e. session ID)
>>
>>
>> The generated page also contains XForms markup, which submits a  
>> request with method "post" to the servlet. The servlet responses  
>> with an XML document. The XML document contains the following data:
>> *Current (at the time when doPost() method was being processed)  
>> session ID
>> *Current (at the time when doPost() method was being processed) &  
>> stored attribute value (i.e. session ID)
>>
>>
>> Logically, all four values ought to be same, right?. However, if  
>> the XForms request is submitted automatically upon the "xforms-
>> ready" event, then on the first time/submission the session ID has  
>> changed and, therefore, also the stored session attribute value is  
>> null (cannot be found from this session because it is the same  
>> session where to the attribute was set). If the request is  
>> submitted again (CTRL+F5 in Firefox), then the values match.
>>
>> If the XForms request is submitted manually, i.e. by clicking a  
>> button/trigger, then all four values are the same even on the first  
>> time/submission. In addition, the example works fine also when used  
>> without Orbeon Forms XForms Engine (ops xforms filter turned off  
>> and using Mozilla XForms plug-in).
>>
>> I'm using Orbeon Forms 3.6.0rc1 (filter set the the URL "/*") with  
>> standard configurations. You can test the example/behaviour with  
>> manual/automatic submission by commenting two lines (marked) in the  
>> servlet.SessionTesterServlet.java class (lines 56 and 67.
>>
>> Is this a bug in Oreon Forms? If not, how do I need to modify my  
>> example web application to make it work also on the first time/
>> submission?
>>
>> Best regards
>>
>>
>> -Markku Laine
>>
>> On Fri, 16 Nov 2007, Erik Bruchez wrote:
>>
>>> Gerrit,
>>>
>>> This is not just one way of using XForms or Orbeon Forms, so don't  
>>> worry about doing something wrong. If the solution works for you,  
>>> then that's great. So thanks for sharing it on the list!
>>>
>>> -Erik
>>>
>>>
>>> On Nov 16, 2007, at 11:43 AM, Gerrit Germis wrote:
>>>
>>>> Hi Chaminda,
>>>> I'm also new to orbeon and xforms, so this might not be (most  
>>>> probably)
>>>> the correct way to do it, but it seems to be working for us so far.
>>>> Here's how we set things up:
>>>> - Our webapp is at /umadmin
>>>> - Separate deployment to /ops
>>>> - In the /umadmin context, the /umadmin/xforms-jsp/* is filtered  
>>>> by OPS,
>>>> so this is where we put the .jsp file that generates the XHTML/
>>>> Xforms
>>>> output (or in your case, you could simply put the .xhtml file  
>>>> somewhere
>>>> in that directory). As a side-note, maybe also tell you that you
>>>> shouldn't put the .xml files that you load from the xform itself  
>>>> in any
>>>> directory in /umadmin/xforms-jsp/*.. I've lost a lot of time being
>>>> puzzled by why it wasn't working...
>>>> - We created a HttpServletResponseWrapper object to be able to  
>>>> capture
>>>> the output of the page generated by Xforms (see later)
>>>> - We add a cookie (JSESSIONID) with a path of "/" to that response
>>>> object so it is accessible by both contexts and we don't loose our
>>>> profile information put in the session during login
>>>> - From within the servlet, we do a forward to the /xforms-jsp/*  
>>>> URL that
>>>> generates the actual form and capture the output generated by OPS:
>>>> RequestDispatcher rd =
>>>> servlet.getServletContext().getRequestDispatcher("/xforms-jsp/our-
>>>> app/in
>>>> dex.xhtml");
>>>> rd.forward(request, new MyHttpServletResponseWrapper(response));
>>>> form.setHTML(response.toString());
>>>> return mapping.findForward("success");
>>>> - This way, we can create a .jsp file and use "<%= form.getHTML()  
>>>> %>" in
>>>> the JSP file to actually include the generated form wherever we  
>>>> want in
>>>> the page.
>>>> - As an additional benefit, this way of doing it allows us to use  
>>>> tiles
>>>> too
>>>> - Next problem was when submitting the data in the form, this  
>>>> would give
>>>> us a URL like: http://localhost:8080/ops/xforms-server-submit 
>>>> which we
>>>> didn't want, so here's how we "fixed" this:
>>>> The target of the submission defined in the xform is another struts
>>>> action. We defined a global forward in the struts-config.xml  
>>>> having the
>>>> 'redirect="true"' attribute pointing to the first action again.  
>>>> After
>>>> doing the processing on the submitted data (by processing the
>>>> request.getInputStream()), we simply do a
>>>> 'mapping.findForward("ourforward");' which makes the client re-
>>>> request
>>>> the original .jsp file generating the form again...
>>>> Again, I emphasise that this is probably not the way of working  
>>>> with
>>>> Xforms, so any suggestions or remarks are most welcome..
>>>> Hope this helps,
>>>> Gerrit
>>>> -----Original Message-----
>>>> From: Chaminda [mailto:[hidden email]]
>>>> Sent: Friday, November 16, 2007 10:34 AM
>>>> To: [hidden email]
>>>> Subject: Re: [ops-users] submitting with method "post" and loosing
>>>> session attributes
>>>> Hi Gerrit,
>>>> Sorry for replying your thread to, This is not an answer for you
>>>> problem.
>>>> According to your problem I guess you are familiar with this.  
>>>> Thats why
>>>> Im
>>>> posing my problem here,
>>>> I want to send request to a servlet and in the servlet set a  
>>>> request
>>>> attribute. Upto that part I know. But I  dont know how to  
>>>> dispatch the
>>>> request to XHTML other that JSP.
>>>> In JSP we do like this
>>>> dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>>>> How can I do this for xhtml,
>>>> Thanks, Sorry again for posing to here
>>>> Gerrit Germis-2 wrote:
>>>> > > Hi,
>>>> > > I'm using struts/tiles with the nightly build of xforms  
>>>> (separartely
>>>> > deployed). I have successfully created and populated my xform,  
>>>> but
>>>> now,
>>>> > when I try to submit the results back to another action using the
>>>> "post"
>>>> > method, I loose my profile information that was stored in the  
>>>> session.
>>>> > This is what my submission looks like:
>>>> > >   <xforms:submission id="test-submit"
>>>> >       action="http://localhost:8080/umadmin/someAction"  
>>>> method="post"
>>>> >       ref="instance('document-instance')/data/DocumentRevision"
>>>> > replace="all"/>
>>>> > >   <xforms:submit submission="test-submit">
>>>> >       <xforms:label>Go to action!</xforms:label>
>>>> >   </xforms:submit>
>>>> > > The complete flow is like this:
>>>> > > - setup: /xforms-jsp/* is setup to be filtered by OPS
>>>> > - User logs into the website, profile information is stored in
>>>> session
>>>> > - form is generated by navigating to URL:
>>>> > http://localhost:8080/umadmin/xforms-jsp/some-app
>>>> > - User fills in data
>>>> > - User presses the submit button labeled "Go to action!"  
>>>> mentioned
>>>> > above
>>>> > - PROBLEM: user is prompted for login again since no profile
>>>> > information was found in session
>>>> > > How can I make sure the profile information is not lost on  
>>>> submission?
>>>> > > Sincerely
>>>> > Gerrit
>>>> > > > > --
>>>> > You receive this message as a subscriber of the [hidden email]
>>>> mailing
>>>> > list.
>>>> > To unsubscribe: mailto:[hidden email]
>>>> > For general help: mailto:[hidden email]?subject=help
>>>> > OW2 mailing lists service home page: http://www.ow2.org/wws
>>>> > > --
>>>> View this message in context:
>>>> http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
>>>> ion-attributes-tf4803253.html#a13790034
>>>> Sent from the ObjectWeb OPS - Users mailing list archive at  
>>>> Nabble.com.
>>>> --
>>>> You receive this message as a subscriber of the [hidden email]  
>>>> mailing list.
>>>> To unsubscribe: mailto:[hidden email]
>>>> For general help: mailto:[hidden email]?subject=help
>>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>>
>>> --
>>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>>> http://www.orbeon.com/
>>>
>>>
>>
>> --
>> Markku Laine <[hidden email]>
>> Research assistant, Helsinki University of Technology
>> Telecommunications Software and Multimedia Laboratory
>> P.O.Box 5400, FIN-02015 HUT, FINLAND
>> Mobile. +358-50-565 8179 (Finland)
>> Mobile.  +64-21-037 3605 (New Zealand, 01 Oct - 21 Dec,  
>> 2007)<OFSession.war>
>> --
>> You receive this message as a subscriber of the [hidden email]  
>> mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>

> A quick follow-up: I experimented a bit and implemented the solution below.
> It seems to do the trick and solve the problem, but I haven't checked it in
> yet as I am wondering if it could break with other servlet containers.
>
> Thoughts on this welcome.
>
> -Erik
>
> On Dec 10, 2007, at 4:44 PM, Erik Bruchez wrote:
>
>> Markku,
>>
>> I investigated this a bit. Thanks for the reproducible case. It does seem
>> to be a little tricky!
>>
>> Here are my findings:
>>
>> 1. Web browser initially doesn't send any session cooke
>> 2. /OFSession servlet creates session with id FOO
>> 3. XForms filter cross-context forwards request to /ops servlet with XForms
>> content
>> 4. Orbeon Forms processes XForms content and performs submission upon
>> xforms-ready
>> 5. Submission attempts to forward JSESSION cookie but doesn't find any so
>> none is forwarded
>> 6. Submission request hits /OFSession again, and since there is no JSESSION
>> id cookie, a new session BAR is created
>> 7. Problem!
>>
>> The main issue is with #5 above. The session created in /OFSession is new,
>> and Tomcat doesn't create the session cookie at that point, so /ops doesn't
>> get any cookie from the forwarded request. What's more troubling though is
>> that if you call request.getSession(false), no session object is returned
>> either. However, if you call request.getSession(true), you get a session
>> with id "FOO", which is what we want.
>>
>> So we could in theory force the creation of a session, get the session id,
>> and use this id to create a new JSESSIONID cookie to forward during
>> submission if we don't find one in the first place. However this is not
>> great because we may create a session needlessly.
>>
>> Another solution would be for the XForms filter to store the session id
>> into the request, and then the XForms submission could use that session id.
>> Or, similarly, simply information that a session is available. Then the
>> XForms submission would know that it must call request.getSession(true).
>> This code could actually be hidden in ServletExternalContext.
>>
>> The latter possibility sounds reasonably good. The only drag, besides the
>> relative complexity of the code, is that it's not clear to me whether this
>> is a Tomcat-only issue and/or solution.
>>
>> I entered a bug to track this:
>>
>> http://forge.objectweb.org/tracker/index.php?func=detail&aid=308023&group_id=168&atid=350207
>>
>> Any thoughts on the above?
>>
>> -Erik
>>
>> On Nov 28, 2007, at 3:24 AM, .::: Markku :::. wrote:
>>
>> > Hi Erik,
>> >
>> >
>> > I have also faced the same problem before, i.e. loosing session
>> > attributes when submitting with method "post" (on the first submission
>> > only), but unfortunately I haven't found a working solution yet.
>> >
>> > I attached a simple example web application (servlet) which reproduces
>> > the problem. When the servlet is requested (e.g.,
>> > http://localhost:8080/OFSession), the doGet() method responses with a
>> > generated XHTML+XForms page. The generated page contains the following
>> > data:
>> > *Current (at the time when doGet() method was being processed) session ID
>> > *Current (at the time when doGet() method was being processed) & stored
>> > attribute value (i.e. session ID)
>> >
>> >
>> > The generated page also contains XForms markup, which submits a request
>> > with method "post" to the servlet. The servlet responses with an XML
>> > document. The XML document contains the following data:
>> > *Current (at the time when doPost() method was being processed) session
>> > ID
>> > *Current (at the time when doPost() method was being processed) & stored
>> > attribute value (i.e. session ID)
>> >
>> >
>> > Logically, all four values ought to be same, right?. However, if the
>> > XForms request is submitted automatically upon the "xforms-ready" event,
>> > then on the first time/submission the session ID has changed and,
>> > therefore, also the stored session attribute value is null (cannot be
>> > found from this session because it is the same session where to the
>> > attribute was set). If the request is submitted again (CTRL+F5 in
>> > Firefox), then the values match.
>> >
>> > If the XForms request is submitted manually, i.e. by clicking a
>> > button/trigger, then all four values are the same even on the first
>> > time/submission. In addition, the example works fine also when used
>> > without Orbeon Forms XForms Engine (ops xforms filter turned off and
>> > using Mozilla XForms plug-in).
>> >
>> > I'm using Orbeon Forms 3.6.0rc1 (filter set the the URL "/*") with
>> > standard configurations. You can test the example/behaviour with
>> > manual/automatic submission by commenting two lines (marked) in the
>> > servlet.SessionTesterServlet.java class (lines 56 and 67.
>> >
>> > Is this a bug in Oreon Forms? If not, how do I need to modify my example
>> > web application to make it work also on the first time/submission?
>> >
>> > Best regards
>> >
>> >
>> > -Markku Laine
>> >
>> > On Fri, 16 Nov 2007, Erik Bruchez wrote:
>> >
>> > > Gerrit,
>> > >
>> > > This is not just one way of using XForms or Orbeon Forms, so don't
>> > > worry about doing something wrong. If the solution works for you, then
>> > > that's great. So thanks for sharing it on the list!
>> > >
>> > > -Erik
>> > >
>> > >
>> > > On Nov 16, 2007, at 11:43 AM, Gerrit Germis wrote:
>> > >
>> > > > Hi Chaminda,
>> > > > I'm also new to orbeon and xforms, so this might not be (most
>> > > > probably)
>> > > > the correct way to do it, but it seems to be working for us so far.
>> > > > Here's how we set things up:
>> > > > - Our webapp is at /umadmin
>> > > > - Separate deployment to /ops
>> > > > - In the /umadmin context, the /umadmin/xforms-jsp/* is filtered by
>> > > > OPS,
>> > > > so this is where we put the .jsp file that generates the XHTML/Xforms
>> > > > output (or in your case, you could simply put the .xhtml file
>> > > > somewhere
>> > > > in that directory). As a side-note, maybe also tell you that you
>> > > > shouldn't put the .xml files that you load from the xform itself in
>> > > > any
>> > > > directory in /umadmin/xforms-jsp/*.. I've lost a lot of time being
>> > > > puzzled by why it wasn't working...
>> > > > - We created a HttpServletResponseWrapper object to be able to
>> > > > capture
>> > > > the output of the page generated by Xforms (see later)
>> > > > - We add a cookie (JSESSIONID) with a path of "/" to that response
>> > > > object so it is accessible by both contexts and we don't loose our
>> > > > profile information put in the session during login
>> > > > - From within the servlet, we do a forward to the /xforms-jsp/* URL
>> > > > that
>> > > > generates the actual form and capture the output generated by OPS:
>> > > > RequestDispatcher rd =
>> > > > servlet.getServletContext().getRequestDispatcher("/xforms-jsp/our-app/in
>> > > > dex.xhtml");
>> > > > rd.forward(request, new MyHttpServletResponseWrapper(response));
>> > > > form.setHTML(response.toString());
>> > > > return mapping.findForward("success");
>> > > > - This way, we can create a .jsp file and use "<%= form.getHTML() %>"
>> > > > in
>> > > > the JSP file to actually include the generated form wherever we want
>> > > > in
>> > > > the page.
>> > > > - As an additional benefit, this way of doing it allows us to use
>> > > > tiles
>> > > > too
>> > > > - Next problem was when submitting the data in the form, this would
>> > > > give
>> > > > us a URL like: http://localhost:8080/ops/xforms-server-submit which
>> > > > we
>> > > > didn't want, so here's how we "fixed" this:
>> > > > The target of the submission defined in the xform is another struts
>> > > > action. We defined a global forward in the struts-config.xml having
>> > > > the
>> > > > 'redirect="true"' attribute pointing to the first action again. After
>> > > > doing the processing on the submitted data (by processing the
>> > > > request.getInputStream()), we simply do a
>> > > > 'mapping.findForward("ourforward");' which makes the client
>> > > > re-request
>> > > > the original .jsp file generating the form again...
>> > > > Again, I emphasise that this is probably not the way of working with
>> > > > Xforms, so any suggestions or remarks are most welcome..
>> > > > Hope this helps,
>> > > > Gerrit
>> > > > -----Original Message-----
>> > > > From: Chaminda [mailto:[hidden email]]
>> > > > Sent: Friday, November 16, 2007 10:34 AM
>> > > > To: [hidden email]
>> > > > Subject: Re: [ops-users] submitting with method "post" and loosing
>> > > > session attributes
>> > > > Hi Gerrit,
>> > > > Sorry for replying your thread to, This is not an answer for you
>> > > > problem.
>> > > > According to your problem I guess you are familiar with this. Thats
>> > > > why
>> > > > Im
>> > > > posing my problem here,
>> > > > I want to send request to a servlet and in the servlet set a request
>> > > > attribute. Upto that part I know. But I  dont know how to dispatch
>> > > > the
>> > > > request to XHTML other that JSP.
>> > > > In JSP we do like this
>> > > > dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>> > > > How can I do this for xhtml,
>> > > > Thanks, Sorry again for posing to here
>> > > > Gerrit Germis-2 wrote:
>> > > > > >  Hi,
>> > > > > >  I'm using struts/tiles with the nightly build of xforms
>> > > > > >  (separartely
>> > > > >  deployed). I have successfully created and populated my xform, but
>> > > > now,
>> > > > >  when I try to submit the results back to another action using the
>> > > > "post"
>> > > > >  method, I loose my profile information that was stored in the
>> > > > >  session.
>> > > > >  This is what my submission looks like:
>> > > > > >    <xforms:submission id="test-submit"
>> > > > >        action="http://localhost:8080/umadmin/someAction"
>> > > > >        method="post"
>> > > > >        ref="instance('document-instance')/data/DocumentRevision"
>> > > > >  replace="all"/>
>> > > > > >    <xforms:submit submission="test-submit">
>> > > > >        <xforms:label>Go to action!</xforms:label>
>> > > > >    </xforms:submit>
>> > > > > >  The complete flow is like this:
>> > > > > >  - setup: /xforms-jsp/* is setup to be filtered by OPS
>> > > > >  - User logs into the website, profile information is stored in
>> > > > session
>> > > > >  - form is generated by navigating to URL:
>> > > > >  http://localhost:8080/umadmin/xforms-jsp/some-app
>> > > > >  - User fills in data
>> > > > >  - User presses the submit button labeled "Go to action!" mentioned
>> > > > >  above
>> > > > >  - PROBLEM: user is prompted for login again since no profile
>> > > > >  information was found in session
>> > > > > >  How can I make sure the profile information is not lost on
>> > > > > >  submission?
>> > > > > >  Sincerely
>> > > > >  Gerrit
>> > > > > > > >  --
>> > > > >  You receive this message as a subscriber of the [hidden email]
>> > > > mailing
>> > > > >  list.
>> > > > >  To unsubscribe: mailto:[hidden email]
>> > > > >  For general help: mailto:[hidden email]?subject=help
>> > > > >  OW2 mailing lists service home page: http://www.ow2.org/wws
>> > > > > >  --
>> > > > View this message in context:
>> > > > http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
>> > > > ion-attributes-tf4803253.html#a13790034
>> > > > Sent from the ObjectWeb OPS - Users mailing list archive at
>> > > > Nabble.com.
>> > > > --
>> > > > You receive this message as a subscriber of the [hidden email]
>> > > > mailing list.
>> > > > To unsubscribe: mailto:[hidden email]
>> > > > For general help: mailto:[hidden email]?subject=help
>> > > > OW2 mailing lists service home page: http://www.ow2.org/wws
>> > >
>> > > --
>> > > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> > > http://www.orbeon.com/
>> > >
>> > >
>> >
>> > --
>> > Markku Laine <[hidden email]>
>> > Research assistant, Helsinki University of Technology
>> > Telecommunications Software and Multimedia Laboratory
>> > P.O.Box 5400, FIN-02015 HUT, FINLAND
>> > Mobile. +358-50-565 8179 (Finland)
>> > Mobile.  +64-21-037 3605 (New Zealand, 01 Oct - 21 Dec,
>> > 2007)<OFSession.war>
>> > --
>> > You receive this message as a subscriber of the [hidden email] mailing
>> > list.
>> > To unsubscribe: mailto:[hidden email]
>> > For general help: mailto:[hidden email]?subject=help
>> > OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>

> Hi Erik,
>
>
> Firstly, thanks for solving the problem!
>
> Secondly, your solution seems to be reasonable and workable so at  
> least I'm happy with it :) I'm also using Tomcat (version 5.5.23) at  
> the moment. I haven't tried to use other servlet containers with  
> Orbeon Forms so I really can't tell whether this is a Tomcat only  
> issue.
>
> Could you inform me when the fix has been checked in and included to  
> the newest Orbeon Forms Nightly Build version? Once again, thanks a  
> lot! Great work!
>
> Regards
>
>
> -Markku
>
>
> On Mon, 10 Dec 2007, Erik Bruchez wrote:
>
>> A quick follow-up: I experimented a bit and implemented the  
>> solution below. It seems to do the trick and solve the problem, but  
>> I haven't checked it in yet as I am wondering if it could break  
>> with other servlet containers.
>>
>> Thoughts on this welcome.
>>
>> -Erik
>>
>> On Dec 10, 2007, at 4:44 PM, Erik Bruchez wrote:
>>
>>> Markku,
>>> I investigated this a bit. Thanks for the reproducible case. It  
>>> does seem to be a little tricky!
>>> Here are my findings:
>>> 1. Web browser initially doesn't send any session cooke
>>> 2. /OFSession servlet creates session with id FOO
>>> 3. XForms filter cross-context forwards request to /ops servlet  
>>> with XForms content
>>> 4. Orbeon Forms processes XForms content and performs submission  
>>> upon xforms-ready
>>> 5. Submission attempts to forward JSESSION cookie but doesn't find  
>>> any so none is forwarded
>>> 6. Submission request hits /OFSession again, and since there is no  
>>> JSESSION id cookie, a new session BAR is created
>>> 7. Problem!
>>> The main issue is with #5 above. The session created in /OFSession  
>>> is new, and Tomcat doesn't create the session cookie at that  
>>> point, so /ops doesn't get any cookie from the forwarded request.  
>>> What's more troubling though is that if you call  
>>> request.getSession(false), no session object is returned either.  
>>> However, if you call request.getSession(true), you get a session  
>>> with id "FOO", which is what we want.
>>> So we could in theory force the creation of a session, get the  
>>> session id, and use this id to create a new JSESSIONID cookie to  
>>> forward during submission if we don't find one in the first place.  
>>> However this is not great because we may create a session  
>>> needlessly.
>>> Another solution would be for the XForms filter to store the  
>>> session id into the request, and then the XForms submission could  
>>> use that session id. Or, similarly, simply information that a  
>>> session is available. Then the XForms submission would know that  
>>> it must call request.getSession(true). This code could actually be  
>>> hidden in ServletExternalContext.
>>> The latter possibility sounds reasonably good. The only drag,  
>>> besides the relative complexity of the code, is that it's not  
>>> clear to me whether this is a Tomcat-only issue and/or solution.
>>> I entered a bug to track this:
>>> http://forge.objectweb.org/tracker/index.php?func=detail&aid=308023&group_id=168&atid=350207
>>> Any thoughts on the above?
>>> -Erik
>>> On Nov 28, 2007, at 3:24 AM, .::: Markku :::. wrote:
>>> > Hi Erik,
>>> > > > I have also faced the same problem before, i.e. loosing  
>>> session > attributes when submitting with method "post" (on the  
>>> first submission > only), but unfortunately I haven't found a  
>>> working solution yet.
>>> > > I attached a simple example web application (servlet) which  
>>> reproduces > the problem. When the servlet is requested (e.g., > http://localhost:8080/OFSession)
>>> , the doGet() method responses with a > generated XHTML+XForms  
>>> page. The generated page contains the following > data:
>>> > *Current (at the time when doGet() method was being processed)  
>>> session ID
>>> > *Current (at the time when doGet() method was being processed) &  
>>> stored > attribute value (i.e. session ID)
>>> > > > The generated page also contains XForms markup, which  
>>> submits a request > with method "post" to the servlet. The servlet  
>>> responses with an XML > document. The XML document contains the  
>>> following data:
>>> > *Current (at the time when doPost() method was being processed)  
>>> session > ID
>>> > *Current (at the time when doPost() method was being processed)  
>>> & stored > attribute value (i.e. session ID)
>>> > > > Logically, all four values ought to be same, right?.  
>>> However, if the > XForms request is submitted automatically upon  
>>> the "xforms-ready" event, > then on the first time/submission the  
>>> session ID has changed and, > therefore, also the stored session  
>>> attribute value is null (cannot be > found from this session  
>>> because it is the same session where to the > attribute was set).  
>>> If the request is submitted again (CTRL+F5 in > Firefox), then the  
>>> values match.
>>> > > If the XForms request is submitted manually, i.e. by clicking  
>>> a > button/trigger, then all four values are the same even on the  
>>> first > time/submission. In addition, the example works fine also  
>>> when used > without Orbeon Forms XForms Engine (ops xforms filter  
>>> turned off and > using Mozilla XForms plug-in).
>>> > > I'm using Orbeon Forms 3.6.0rc1 (filter set the the URL "/*")  
>>> with > standard configurations. You can test the example/behaviour  
>>> with > manual/automatic submission by commenting two lines  
>>> (marked) in the > servlet.SessionTesterServlet.java class (lines  
>>> 56 and 67.
>>> > > Is this a bug in Oreon Forms? If not, how do I need to modify  
>>> my example > web application to make it work also on the first  
>>> time/submission?
>>> > > Best regards
>>> > > > -Markku Laine
>>> > > On Fri, 16 Nov 2007, Erik Bruchez wrote:
>>> > > > Gerrit,
>>> > > > > This is not just one way of using XForms or Orbeon Forms,  
>>> so don't > > worry about doing something wrong. If the solution  
>>> works for you, then > > that's great. So thanks for sharing it on  
>>> the list!
>>> > > > > -Erik
>>> > > > > > > On Nov 16, 2007, at 11:43 AM, Gerrit Germis wrote:
>>> > > > > > Hi Chaminda,
>>> > > > I'm also new to orbeon and xforms, so this might not be  
>>> (most > > > probably)
>>> > > > the correct way to do it, but it seems to be working for us  
>>> so far.
>>> > > > Here's how we set things up:
>>> > > > - Our webapp is at /umadmin
>>> > > > - Separate deployment to /ops
>>> > > > - In the /umadmin context, the /umadmin/xforms-jsp/* is  
>>> filtered by > > > OPS,
>>> > > > so this is where we put the .jsp file that generates the  
>>> XHTML/Xforms
>>> > > > output (or in your case, you could simply put the .xhtml  
>>> file > > > somewhere
>>> > > > in that directory). As a side-note, maybe also tell you that  
>>> you
>>> > > > shouldn't put the .xml files that you load from the xform  
>>> itself in > > > any
>>> > > > directory in /umadmin/xforms-jsp/*.. I've lost a lot of time  
>>> being
>>> > > > puzzled by why it wasn't working...
>>> > > > - We created a HttpServletResponseWrapper object to be able  
>>> to > > > capture
>>> > > > the output of the page generated by Xforms (see later)
>>> > > > - We add a cookie (JSESSIONID) with a path of "/" to that  
>>> response
>>> > > > object so it is accessible by both contexts and we don't  
>>> loose our
>>> > > > profile information put in the session during login
>>> > > > - From within the servlet, we do a forward to the /xforms-
>>> jsp/* URL > > > that
>>> > > > generates the actual form and capture the output generated  
>>> by OPS:
>>> > > > RequestDispatcher rd =
>>> > > > servlet.getServletContext().getRequestDispatcher("/xforms-
>>> jsp/our-app/in
>>> > > > dex.xhtml");
>>> > > > rd.forward(request, new  
>>> MyHttpServletResponseWrapper(response));
>>> > > > form.setHTML(response.toString());
>>> > > > return mapping.findForward("success");
>>> > > > - This way, we can create a .jsp file and use "<%=  
>>> form.getHTML() %>" > > > in
>>> > > > the JSP file to actually include the generated form wherever  
>>> we want > > > in
>>> > > > the page.
>>> > > > - As an additional benefit, this way of doing it allows us  
>>> to use > > > tiles
>>> > > > too
>>> > > > - Next problem was when submitting the data in the form,  
>>> this would > > > give
>>> > > > us a URL like: http://localhost:8080/ops/xforms-server- 
>>> submit which > > > we
>>> > > > didn't want, so here's how we "fixed" this:
>>> > > > The target of the submission defined in the xform is another  
>>> struts
>>> > > > action. We defined a global forward in the struts-config.xml  
>>> having > > > the
>>> > > > 'redirect="true"' attribute pointing to the first action  
>>> again. After
>>> > > > doing the processing on the submitted data (by processing the
>>> > > > request.getInputStream()), we simply do a
>>> > > > 'mapping.findForward("ourforward");' which makes the client  
>>> > > > re-request
>>> > > > the original .jsp file generating the form again...
>>> > > > Again, I emphasise that this is probably not the way of  
>>> working with
>>> > > > Xforms, so any suggestions or remarks are most welcome..
>>> > > > Hope this helps,
>>> > > > Gerrit
>>> > > > -----Original Message-----
>>> > > > From: Chaminda [mailto:[hidden email]]
>>> > > > Sent: Friday, November 16, 2007 10:34 AM
>>> > > > To: [hidden email]
>>> > > > Subject: Re: [ops-users] submitting with method "post" and  
>>> loosing
>>> > > > session attributes
>>> > > > Hi Gerrit,
>>> > > > Sorry for replying your thread to, This is not an answer for  
>>> you
>>> > > > problem.
>>> > > > According to your problem I guess you are familiar with  
>>> this. Thats > > > why
>>> > > > Im
>>> > > > posing my problem here,
>>> > > > I want to send request to a servlet and in the servlet set a  
>>> request
>>> > > > attribute. Upto that part I know. But I  dont know how to  
>>> dispatch > > > the
>>> > > > request to XHTML other that JSP.
>>> > > > In JSP we do like this
>>> > > > dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>>> > > > How can I do this for xhtml,
>>> > > > Thanks, Sorry again for posing to here
>>> > > > Gerrit Germis-2 wrote:
>>> > > > > >  Hi,
>>> > > > > >  I'm using struts/tiles with the nightly build of xforms  
>>> > > > > >  (separartely
>>> > > > >  deployed). I have successfully created and populated my  
>>> xform, but
>>> > > > now,
>>> > > > >  when I try to submit the results back to another action  
>>> using the
>>> > > > "post"
>>> > > > >  method, I loose my profile information that was stored in  
>>> the > > > >  session.
>>> > > > >  This is what my submission looks like:
>>> > > > > >    <xforms:submission id="test-submit"
>>> > > > >        action="http://localhost:8080/umadmin/someAction" >  
>>> > > >        method="post"
>>> > > > >        ref="instance('document-instance')/data/
>>> DocumentRevision"
>>> > > > >  replace="all"/>
>>> > > > > >    <xforms:submit submission="test-submit">
>>> > > > >        <xforms:label>Go to action!</xforms:label>
>>> > > > >    </xforms:submit>
>>> > > > > >  The complete flow is like this:
>>> > > > > >  - setup: /xforms-jsp/* is setup to be filtered by OPS
>>> > > > >  - User logs into the website, profile information is  
>>> stored in
>>> > > > session
>>> > > > >  - form is generated by navigating to URL:
>>> > > > >  http://localhost:8080/umadmin/xforms-jsp/some-app
>>> > > > >  - User fills in data
>>> > > > >  - User presses the submit button labeled "Go to action!"  
>>> mentioned
>>> > > > >  above
>>> > > > >  - PROBLEM: user is prompted for login again since no  
>>> profile
>>> > > > >  information was found in session
>>> > > > > >  How can I make sure the profile information is not lost  
>>> on > > > > >  submission?
>>> > > > > >  Sincerely
>>> > > > >  Gerrit
>>> > > > > > > >  --
>>> > > > >  You receive this message as a subscriber of the [hidden email]
>>> > > > mailing
>>> > > > >  list.
>>> > > > >  To unsubscribe: mailto:[hidden email]
>>> > > > >  For general help: mailto:[hidden email]?subject=help
>>> > > > >  OW2 mailing lists service home page: http://www.ow2.org/wws
>>> > > > > >  --
>>> > > > View this message in context:
>>> > > > http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
>>> > > > ion-attributes-tf4803253.html#a13790034
>>> > > > Sent from the ObjectWeb OPS - Users mailing list archive at  
>>> > > > Nabble.com.
>>> > > > --
>>> > > > You receive this message as a subscriber of the [hidden email]
>>>  > > > mailing list.
>>> > > > To unsubscribe: mailto:[hidden email]
>>> > > > For general help: mailto:[hidden email]?subject=help
>>> > > > OW2 mailing lists service home page: http://www.ow2.org/wws
>>> > > > > --
>>> > > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>>> > > http://www.orbeon.com/
>>> > > > > > > --
>>> > Markku Laine <[hidden email]>
>>> > Research assistant, Helsinki University of Technology
>>> > Telecommunications Software and Multimedia Laboratory
>>> > P.O.Box 5400, FIN-02015 HUT, FINLAND
>>> > Mobile. +358-50-565 8179 (Finland)
>>> > Mobile.  +64-21-037 3605 (New Zealand, 01 Oct - 21 Dec, >  
>>> 2007)<OFSession.war>
>>> > --
>>> > You receive this message as a subscriber of the ops-
>>> [hidden email] mailing > list.
>>> > To unsubscribe: mailto:[hidden email]
>>> > For general help: mailto:[hidden email]?subject=help
>>> > OW2 mailing lists service home page: http://www.ow2.org/wws
>>> --
>>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>>> http://www.orbeon.com/
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

> Markku,
>
> I have now committed this code. Please let us know if 1) it fixes the problem
> and/or 2) it causes any other problems.
>
> -Erik
>
> On Dec 10, 2007, at 6:11 PM, .::: Markku :::. wrote:
>
>> Hi Erik,
>>
>>
>> Firstly, thanks for solving the problem!
>>
>> Secondly, your solution seems to be reasonable and workable so at least I'm
>> happy with it :) I'm also using Tomcat (version 5.5.23) at the moment. I
>> haven't tried to use other servlet containers with Orbeon Forms so I really
>> can't tell whether this is a Tomcat only issue.
>>
>> Could you inform me when the fix has been checked in and included to the
>> newest Orbeon Forms Nightly Build version? Once again, thanks a lot! Great
>> work!
>>
>> Regards
>>
>>
>> -Markku
>>
>>
>> On Mon, 10 Dec 2007, Erik Bruchez wrote:
>>
>> > A quick follow-up: I experimented a bit and implemented the solution
>> > below. It seems to do the trick and solve the problem, but I haven't
>> > checked it in yet as I am wondering if it could break with other servlet
>> > containers.
>> >
>> > Thoughts on this welcome.
>> >
>> > -Erik
>> >
>> > On Dec 10, 2007, at 4:44 PM, Erik Bruchez wrote:
>> >
>> > > Markku,
>> > > I investigated this a bit. Thanks for the reproducible case. It does
>> > > seem to be a little tricky!
>> > > Here are my findings:
>> > > 1. Web browser initially doesn't send any session cooke
>> > > 2. /OFSession servlet creates session with id FOO
>> > > 3. XForms filter cross-context forwards request to /ops servlet with
>> > > XForms content
>> > > 4. Orbeon Forms processes XForms content and performs submission upon
>> > > xforms-ready
>> > > 5. Submission attempts to forward JSESSION cookie but doesn't find any
>> > > so none is forwarded
>> > > 6. Submission request hits /OFSession again, and since there is no
>> > > JSESSION id cookie, a new session BAR is created
>> > > 7. Problem!
>> > > The main issue is with #5 above. The session created in /OFSession is
>> > > new, and Tomcat doesn't create the session cookie at that point, so
>> > > /ops doesn't get any cookie from the forwarded request. What's more
>> > > troubling though is that if you call request.getSession(false), no
>> > > session object is returned either. However, if you call
>> > > request.getSession(true), you get a session with id "FOO", which is
>> > > what we want.
>> > > So we could in theory force the creation of a session, get the session
>> > > id, and use this id to create a new JSESSIONID cookie to forward during
>> > > submission if we don't find one in the first place. However this is not
>> > > great because we may create a session needlessly.
>> > > Another solution would be for the XForms filter to store the session id
>> > > into the request, and then the XForms submission could use that session
>> > > id. Or, similarly, simply information that a session is available. Then
>> > > the XForms submission would know that it must call
>> > > request.getSession(true). This code could actually be hidden in
>> > > ServletExternalContext.
>> > > The latter possibility sounds reasonably good. The only drag, besides
>> > > the relative complexity of the code, is that it's not clear to me
>> > > whether this is a Tomcat-only issue and/or solution.
>> > > I entered a bug to track this:
>> > > http://forge.objectweb.org/tracker/index.php?func=detail&aid=308023&group_id=168&atid=350207
>> > > Any thoughts on the above?
>> > > -Erik
>> > > On Nov 28, 2007, at 3:24 AM, .::: Markku :::. wrote:
>> > > >  Hi Erik,
>> > > > > >  I have also faced the same problem before, i.e. loosing session
>> > > > > >  > attributes when submitting with method "post" (on the first
>> > > > > >  submission > only), but unfortunately I haven't found a working
>> > > > > >  solution yet.
>> > > > >  I attached a simple example web application (servlet) which
>> > > > >  reproduces > the problem. When the servlet is requested (e.g., >
>> > > > >  http://localhost:8080/OFSession), the doGet() method responses
>> > > > >  with a > generated XHTML+XForms page. The generated page contains
>> > > > >  the following > data:
>> > > >  *Current (at the time when doGet() method was being processed)
>> > > >  session ID
>> > > >  *Current (at the time when doGet() method was being processed) &
>> > > >  stored > attribute value (i.e. session ID)
>> > > > > >  The generated page also contains XForms markup, which submits a
>> > > > > >  request > with method "post" to the servlet. The servlet
>> > > > > >  responses with an XML > document. The XML document contains the
>> > > > > >  following data:
>> > > >  *Current (at the time when doPost() method was being processed)
>> > > >  session > ID
>> > > >  *Current (at the time when doPost() method was being processed) &
>> > > >  stored > attribute value (i.e. session ID)
>> > > > > >  Logically, all four values ought to be same, right?. However, if
>> > > > > >  the > XForms request is submitted automatically upon the
>> > > > > >  "xforms-ready" event, > then on the first time/submission the
>> > > > > >  session ID has changed and, > therefore, also the stored session
>> > > > > >  attribute value is null (cannot be > found from this session
>> > > > > >  because it is the same session where to the > attribute was
>> > > > > >  set). If the request is submitted again (CTRL+F5 in > Firefox),
>> > > > > >  then the values match.
>> > > > >  If the XForms request is submitted manually, i.e. by clicking a >
>> > > > >  button/trigger, then all four values are the same even on the
>> > > > >  first > time/submission. In addition, the example works fine also
>> > > > >  when used > without Orbeon Forms XForms Engine (ops xforms filter
>> > > > >  turned off and > using Mozilla XForms plug-in).
>> > > > >  I'm using Orbeon Forms 3.6.0rc1 (filter set the the URL "/*") with
>> > > > >  > standard configurations. You can test the example/behaviour with
>> > > > >  > manual/automatic submission by commenting two lines (marked) in
>> > > > >  the > servlet.SessionTesterServlet.java class (lines 56 and 67.
>> > > > >  Is this a bug in Oreon Forms? If not, how do I need to modify my
>> > > > >  example > web application to make it work also on the first
>> > > > >  time/submission?
>> > > > >  Best regards
>> > > > > >  -Markku Laine
>> > > > >  On Fri, 16 Nov 2007, Erik Bruchez wrote:
>> > > > > >  Gerrit,
>> > > > > > >  This is not just one way of using XForms or Orbeon Forms, so
>> > > > > > >  don't > > worry about doing something wrong. If the solution
>> > > > > > >  works for you, then > > that's great. So thanks for sharing it
>> > > > > > >  on the list!
>> > > > > > >  -Erik
>> > > > > > > > >  On Nov 16, 2007, at 11:43 AM, Gerrit Germis wrote:
>> > > > > > > >  Hi Chaminda,
>> > > > > >  I'm also new to orbeon and xforms, so this might not be (most >
>> > > > > >  > > probably)
>> > > > > >  the correct way to do it, but it seems to be working for us so
>> > > > > >  far.
>> > > > > >  Here's how we set things up:
>> > > > > >  - Our webapp is at /umadmin
>> > > > > >  - Separate deployment to /ops
>> > > > > >  - In the /umadmin context, the /umadmin/xforms-jsp/* is filtered
>> > > > > >  by > > > OPS,
>> > > > > >  so this is where we put the .jsp file that generates the
>> > > > > >  XHTML/Xforms
>> > > > > >  output (or in your case, you could simply put the .xhtml file >
>> > > > > >  > > somewhere
>> > > > > >  in that directory). As a side-note, maybe also tell you that you
>> > > > > >  shouldn't put the .xml files that you load from the xform itself
>> > > > > >  in > > > any
>> > > > > >  directory in /umadmin/xforms-jsp/*.. I've lost a lot of time
>> > > > > >  being
>> > > > > >  puzzled by why it wasn't working...
>> > > > > >  - We created a HttpServletResponseWrapper object to be able to >
>> > > > > >  > > capture
>> > > > > >  the output of the page generated by Xforms (see later)
>> > > > > >  - We add a cookie (JSESSIONID) with a path of "/" to that
>> > > > > >  response
>> > > > > >  object so it is accessible by both contexts and we don't loose
>> > > > > >  our
>> > > > > >  profile information put in the session during login
>> > > > > >  - From within the servlet, we do a forward to the /xforms-jsp/*
>> > > > > >  URL > > > that
>> > > > > >  generates the actual form and capture the output generated by
>> > > > > >  OPS:
>> > > > > >  RequestDispatcher rd =
>> > > > > >  servlet.getServletContext().getRequestDispatcher("/xforms-jsp/our-app/in
>> > > > > >  dex.xhtml");
>> > > > > >  rd.forward(request, new MyHttpServletResponseWrapper(response));
>> > > > > >  form.setHTML(response.toString());
>> > > > > >  return mapping.findForward("success");
>> > > > > >  - This way, we can create a .jsp file and use "<%=
>> > > > > >  form.getHTML() %>" > > > in
>> > > > > >  the JSP file to actually include the generated form wherever we
>> > > > > >  want > > > in
>> > > > > >  the page.
>> > > > > >  - As an additional benefit, this way of doing it allows us to
>> > > > > >  use > > > tiles
>> > > > > >  too
>> > > > > >  - Next problem was when submitting the data in the form, this
>> > > > > >  would > > > give
>> > > > > >  us a URL like: http://localhost:8080/ops/xforms-server-submit 
>> > > > > >  which > > > we
>> > > > > >  didn't want, so here's how we "fixed" this:
>> > > > > >  The target of the submission defined in the xform is another
>> > > > > >  struts
>> > > > > >  action. We defined a global forward in the struts-config.xml
>> > > > > >  having > > > the
>> > > > > >  'redirect="true"' attribute pointing to the first action again.
>> > > > > >  After
>> > > > > >  doing the processing on the submitted data (by processing the
>> > > > > >  request.getInputStream()), we simply do a
>> > > > > >  'mapping.findForward("ourforward");' which makes the client > >
>> > > > > >  > re-request
>> > > > > >  the original .jsp file generating the form again...
>> > > > > >  Again, I emphasise that this is probably not the way of working
>> > > > > >  with
>> > > > > >  Xforms, so any suggestions or remarks are most welcome..
>> > > > > >  Hope this helps,
>> > > > > >  Gerrit
>> > > > > >  -----Original Message-----
>> > > > > >  From: Chaminda [mailto:[hidden email]]
>> > > > > >  Sent: Friday, November 16, 2007 10:34 AM
>> > > > > >  To: [hidden email]
>> > > > > >  Subject: Re: [ops-users] submitting with method "post" and
>> > > > > >  loosing
>> > > > > >  session attributes
>> > > > > >  Hi Gerrit,
>> > > > > >  Sorry for replying your thread to, This is not an answer for you
>> > > > > >  problem.
>> > > > > >  According to your problem I guess you are familiar with this.
>> > > > > >  Thats > > > why
>> > > > > >  Im
>> > > > > >  posing my problem here,
>> > > > > >  I want to send request to a servlet and in the servlet set a
>> > > > > >  request
>> > > > > >  attribute. Upto that part I know. But I  dont know how to
>> > > > > >  dispatch > > > the
>> > > > > >  request to XHTML other that JSP.
>> > > > > >  In JSP we do like this
>> > > > > >  dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>> > > > > >  How can I do this for xhtml,
>> > > > > >  Thanks, Sorry again for posing to here
>> > > > > >  Gerrit Germis-2 wrote:
>> > > > > > > >   Hi,
>> > > > > > > >   I'm using struts/tiles with the nightly build of xforms > >
>> > > > > > > >   > > >  (separartely
>> > > > > > >   deployed). I have successfully created and populated my
>> > > > > > >   xform, but
>> > > > > >  now,
>> > > > > > >   when I try to submit the results back to another action using
>> > > > > > >   the
>> > > > > >  "post"
>> > > > > > >   method, I loose my profile information that was stored in the
>> > > > > > >   > > > >  session.
>> > > > > > >   This is what my submission looks like:
>> > > > > > > >     <xforms:submission id="test-submit"
>> > > > > > >         action="http://localhost:8080/umadmin/someAction" > > >
>> > > > > > >         >        method="post"
>> > > > > > >         ref="instance('document-instance')/data/DocumentRevision"
>> > > > > > >   replace="all"/>
>> > > > > > > >     <xforms:submit submission="test-submit">
>> > > > > > >         <xforms:label>Go to action!</xforms:label>
>> > > > > > >     </xforms:submit>
>> > > > > > > >   The complete flow is like this:
>> > > > > > > >   - setup: /xforms-jsp/* is setup to be filtered by OPS
>> > > > > > >   - User logs into the website, profile information is stored
>> > > > > > >   in
>> > > > > >  session
>> > > > > > >   - form is generated by navigating to URL:
>> > > > > > >   http://localhost:8080/umadmin/xforms-jsp/some-app
>> > > > > > >   - User fills in data
>> > > > > > >   - User presses the submit button labeled "Go to action!"
>> > > > > > >   mentioned
>> > > > > > >   above
>> > > > > > >   - PROBLEM: user is prompted for login again since no profile
>> > > > > > >   information was found in session
>> > > > > > > >   How can I make sure the profile information is not lost on
>> > > > > > > >   > > > > >  submission?
>> > > > > > > >   Sincerely
>> > > > > > >   Gerrit
>> > > > > > > > > >   --
>> > > > > > >   You receive this message as a subscriber of the
>> > > > > > >   [hidden email]
>> > > > > >  mailing
>> > > > > > >   list.
>> > > > > > >   To unsubscribe: mailto:[hidden email]
>> > > > > > >   For general help: mailto:[hidden email]?subject=help
>> > > > > > >   OW2 mailing lists service home page: http://www.ow2.org/wws
>> > > > > > > >   --
>> > > > > >  View this message in context:
>> > > > > >  http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
>> > > > > >  ion-attributes-tf4803253.html#a13790034
>> > > > > >  Sent from the ObjectWeb OPS - Users mailing list archive at > >
>> > > > > >  > Nabble.com.
>> > > > > >  --
>> > > > > >  You receive this message as a subscriber of the
>> > > > > >  [hidden email] > > > mailing list.
>> > > > > >  To unsubscribe: mailto:[hidden email]
>> > > > > >  For general help: mailto:[hidden email]?subject=help
>> > > > > >  OW2 mailing lists service home page: http://www.ow2.org/wws
>> > > > > > >  --
>> > > > >  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> > > > >  http://www.orbeon.com/
>> > > > > > > > >  --
>> > > >  Markku Laine <[hidden email]>
>> > > >  Research assistant, Helsinki University of Technology
>> > > >  Telecommunications Software and Multimedia Laboratory
>> > > >  P.O.Box 5400, FIN-02015 HUT, FINLAND
>> > > >  Mobile. +358-50-565 8179 (Finland)
>> > > >  Mobile.  +64-21-037 3605 (New Zealand, 01 Oct - 21 Dec, >
>> > > >  2007)<OFSession.war>
>> > > >  --
>> > > >  You receive this message as a subscriber of the [hidden email]
>> > > >  mailing > list.
>> > > >  To unsubscribe: mailto:[hidden email]
>> > > >  For general help: mailto:[hidden email]?subject=help
>> > > >  OW2 mailing lists service home page: http://www.ow2.org/wws
>> > > --
>> > > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> > > http://www.orbeon.com/
>> >
>> > --
>> > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> > http://www.orbeon.com/
>> >
>> >
>>
>> --
>> You receive this message as a subscriber of the [hidden email] mailing
>> list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>

> Hi Erik,
>
>
> Hmm... I just downloaded the newest version of Orbeon Forms  
> (3.6.0.200712180008) and ran my web apps plus the reproducable test  
> case using that Orbeon Forms' version. The problem is still exists.  
> Is it working properly for you? Or is the fix committed to the  
> Nightly Builds/Orbeon Forms version I'm using?
>
> I'm using Apache Tomcat 5.5.23 as a servlet container.
>
> Regards
>
>
> -Markku
>
> On Mon, 17 Dec 2007, Erik Bruchez wrote:
>
>> Markku,
>>
>> I have now committed this code. Please let us know if 1) it fixes  
>> the problem and/or 2) it causes any other problems.
>>
>> -Erik
>>
>> On Dec 10, 2007, at 6:11 PM, .::: Markku :::. wrote:
>>
>>> Hi Erik,
>>> Firstly, thanks for solving the problem!
>>> Secondly, your solution seems to be reasonable and workable so at  
>>> least I'm happy with it :) I'm also using Tomcat (version 5.5.23)  
>>> at the moment. I haven't tried to use other servlet containers  
>>> with Orbeon Forms so I really can't tell whether this is a Tomcat  
>>> only issue.
>>> Could you inform me when the fix has been checked in and included  
>>> to the newest Orbeon Forms Nightly Build version? Once again,  
>>> thanks a lot! Great work!
>>> Regards
>>> -Markku
>>> On Mon, 10 Dec 2007, Erik Bruchez wrote:
>>> > A quick follow-up: I experimented a bit and implemented the  
>>> solution > below. It seems to do the trick and solve the problem,  
>>> but I haven't > checked it in yet as I am wondering if it could  
>>> break with other servlet > containers.
>>> > > Thoughts on this welcome.
>>> > > -Erik
>>> > > On Dec 10, 2007, at 4:44 PM, Erik Bruchez wrote:
>>> > > > Markku,
>>> > > I investigated this a bit. Thanks for the reproducible case.  
>>> It does > > seem to be a little tricky!
>>> > > Here are my findings:
>>> > > 1. Web browser initially doesn't send any session cooke
>>> > > 2. /OFSession servlet creates session with id FOO
>>> > > 3. XForms filter cross-context forwards request to /ops  
>>> servlet with > > XForms content
>>> > > 4. Orbeon Forms processes XForms content and performs  
>>> submission upon > > xforms-ready
>>> > > 5. Submission attempts to forward JSESSION cookie but doesn't  
>>> find any > > so none is forwarded
>>> > > 6. Submission request hits /OFSession again, and since there  
>>> is no > > JSESSION id cookie, a new session BAR is created
>>> > > 7. Problem!
>>> > > The main issue is with #5 above. The session created in /
>>> OFSession is > > new, and Tomcat doesn't create the session cookie  
>>> at that point, so > > /ops doesn't get any cookie from the  
>>> forwarded request. What's more > > troubling though is that if you  
>>> call request.getSession(false), no > > session object is returned  
>>> either. However, if you call > > request.getSession(true), you get  
>>> a session with id "FOO", which is > > what we want.
>>> > > So we could in theory force the creation of a session, get the  
>>> session > > id, and use this id to create a new JSESSIONID cookie  
>>> to forward during > > submission if we don't find one in the first  
>>> place. However this is not > > great because we may create a  
>>> session needlessly.
>>> > > Another solution would be for the XForms filter to store the  
>>> session id > > into the request, and then the XForms submission  
>>> could use that session > > id. Or, similarly, simply information  
>>> that a session is available. Then > > the XForms submission would  
>>> know that it must call > > request.getSession(true). This code  
>>> could actually be hidden in > > ServletExternalContext.
>>> > > The latter possibility sounds reasonably good. The only drag,  
>>> besides > > the relative complexity of the code, is that it's not  
>>> clear to me > > whether this is a Tomcat-only issue and/or solution.
>>> > > I entered a bug to track this:
>>> > > http://forge.objectweb.org/tracker/index.php?func=detail&aid=308023&group_id=168&atid=350207
>>> > > Any thoughts on the above?
>>> > > -Erik
>>> > > On Nov 28, 2007, at 3:24 AM, .::: Markku :::. wrote:
>>> > > >  Hi Erik,
>>> > > > > >  I have also faced the same problem before, i.e. loosing  
>>> session > > > > >  > attributes when submitting with method  
>>> "post" (on the first > > > > >  submission > only), but  
>>> unfortunately I haven't found a working > > > > >  solution yet.
>>> > > > >  I attached a simple example web application (servlet)  
>>> which > > > >  reproduces > the problem. When the servlet is  
>>> requested (e.g., > > > > >  http://localhost:8080/OFSession), the  
>>> doGet() method responses > > > >  with a > generated XHTML+XForms  
>>> page. The generated page contains > > > >  the following > data:
>>> > > >  *Current (at the time when doGet() method was being  
>>> processed) > > >  session ID
>>> > > >  *Current (at the time when doGet() method was being  
>>> processed) & > > >  stored > attribute value (i.e. session ID)
>>> > > > > >  The generated page also contains XForms markup, which  
>>> submits a > > > > >  request > with method "post" to the servlet.  
>>> The servlet > > > > >  responses with an XML > document. The XML  
>>> document contains the > > > > >  following data:
>>> > > >  *Current (at the time when doPost() method was being  
>>> processed) > > >  session > ID
>>> > > >  *Current (at the time when doPost() method was being  
>>> processed) & > > >  stored > attribute value (i.e. session ID)
>>> > > > > >  Logically, all four values ought to be same, right?.  
>>> However, if > > > > >  the > XForms request is submitted  
>>> automatically upon the > > > > >  "xforms-ready" event, > then on  
>>> the first time/submission the > > > > >  session ID has changed  
>>> and, > therefore, also the stored session > > > > >  attribute  
>>> value is null (cannot be > found from this session > > > > >  
>>> because it is the same session where to the > attribute was > > >  
>>> > >  set). If the request is submitted again (CTRL+F5 in >  
>>> Firefox), > > > > >  then the values match.
>>> > > > >  If the XForms request is submitted manually, i.e. by  
>>> clicking a > > > > >  button/trigger, then all four values are the  
>>> same even on the > > > >  first > time/submission. In addition,  
>>> the example works fine also > > > >  when used > without Orbeon  
>>> Forms XForms Engine (ops xforms filter > > > >  turned off and >  
>>> using Mozilla XForms plug-in).
>>> > > > >  I'm using Orbeon Forms 3.6.0rc1 (filter set the the URL "/
>>> *") with > > > >  > standard configurations. You can test the  
>>> example/behaviour with > > > >  > manual/automatic submission by  
>>> commenting two lines (marked) in > > > >  the >  
>>> servlet.SessionTesterServlet.java class (lines 56 and 67.
>>> > > > >  Is this a bug in Oreon Forms? If not, how do I need to  
>>> modify my > > > >  example > web application to make it work also  
>>> on the first > > > >  time/submission?
>>> > > > >  Best regards
>>> > > > > >  -Markku Laine
>>> > > > >  On Fri, 16 Nov 2007, Erik Bruchez wrote:
>>> > > > > >  Gerrit,
>>> > > > > > >  This is not just one way of using XForms or Orbeon  
>>> Forms, so > > > > > >  don't > > worry about doing something  
>>> wrong. If the solution > > > > > >  works for you, then > > that's  
>>> great. So thanks for sharing it > > > > > >  on the list!
>>> > > > > > >  -Erik
>>> > > > > > > > >  On Nov 16, 2007, at 11:43 AM, Gerrit Germis wrote:
>>> > > > > > > >  Hi Chaminda,
>>> > > > > >  I'm also new to orbeon and xforms, so this might not be  
>>> (most > > > > > >  > > probably)
>>> > > > > >  the correct way to do it, but it seems to be working  
>>> for us so > > > > >  far.
>>> > > > > >  Here's how we set things up:
>>> > > > > >  - Our webapp is at /umadmin
>>> > > > > >  - Separate deployment to /ops
>>> > > > > >  - In the /umadmin context, the /umadmin/xforms-jsp/* is  
>>> filtered > > > > >  by > > > OPS,
>>> > > > > >  so this is where we put the .jsp file that generates  
>>> the > > > > >  XHTML/Xforms
>>> > > > > >  output (or in your case, you could simply put  
>>> the .xhtml file > > > > > >  > > somewhere
>>> > > > > >  in that directory). As a side-note, maybe also tell you  
>>> that you
>>> > > > > >  shouldn't put the .xml files that you load from the  
>>> xform itself > > > > >  in > > > any
>>> > > > > >  directory in /umadmin/xforms-jsp/*.. I've lost a lot of  
>>> time > > > > >  being
>>> > > > > >  puzzled by why it wasn't working...
>>> > > > > >  - We created a HttpServletResponseWrapper object to be  
>>> able to > > > > > >  > > capture
>>> > > > > >  the output of the page generated by Xforms (see later)
>>> > > > > >  - We add a cookie (JSESSIONID) with a path of "/" to  
>>> that > > > > >  response
>>> > > > > >  object so it is accessible by both contexts and we  
>>> don't loose > > > > >  our
>>> > > > > >  profile information put in the session during login
>>> > > > > >  - From within the servlet, we do a forward to the /
>>> xforms-jsp/* > > > > >  URL > > > that
>>> > > > > >  generates the actual form and capture the output  
>>> generated by > > > > >  OPS:
>>> > > > > >  RequestDispatcher rd =
>>> > > > > >  servlet.getServletContext().getRequestDispatcher("/
>>> xforms-jsp/our-app/in
>>> > > > > >  dex.xhtml");
>>> > > > > >  rd.forward(request, new  
>>> MyHttpServletResponseWrapper(response));
>>> > > > > >  form.setHTML(response.toString());
>>> > > > > >  return mapping.findForward("success");
>>> > > > > >  - This way, we can create a .jsp file and use "<%= > >  
>>> > > >  form.getHTML() %>" > > > in
>>> > > > > >  the JSP file to actually include the generated form  
>>> wherever we > > > > >  want > > > in
>>> > > > > >  the page.
>>> > > > > >  - As an additional benefit, this way of doing it allows  
>>> us to > > > > >  use > > > tiles
>>> > > > > >  too
>>> > > > > >  - Next problem was when submitting the data in the  
>>> form, this > > > > >  would > > > give
>>> > > > > >  us a URL like: http://localhost:8080/ops/xforms-server-submit 
>>>  > > > > >  which > > > we
>>> > > > > >  didn't want, so here's how we "fixed" this:
>>> > > > > >  The target of the submission defined in the xform is  
>>> another > > > > >  struts
>>> > > > > >  action. We defined a global forward in the struts-
>>> config.xml > > > > >  having > > > the
>>> > > > > >  'redirect="true"' attribute pointing to the first  
>>> action again. > > > > >  After
>>> > > > > >  doing the processing on the submitted data (by  
>>> processing the
>>> > > > > >  request.getInputStream()), we simply do a
>>> > > > > >  'mapping.findForward("ourforward");' which makes the  
>>> client > > > > > > >  > re-request
>>> > > > > >  the original .jsp file generating the form again...
>>> > > > > >  Again, I emphasise that this is probably not the way of  
>>> working > > > > >  with
>>> > > > > >  Xforms, so any suggestions or remarks are most welcome..
>>> > > > > >  Hope this helps,
>>> > > > > >  Gerrit
>>> > > > > >  -----Original Message-----
>>> > > > > >  From: Chaminda [mailto:[hidden email]]
>>> > > > > >  Sent: Friday, November 16, 2007 10:34 AM
>>> > > > > >  To: [hidden email]
>>> > > > > >  Subject: Re: [ops-users] submitting with method "post"  
>>> and > > > > >  loosing
>>> > > > > >  session attributes
>>> > > > > >  Hi Gerrit,
>>> > > > > >  Sorry for replying your thread to, This is not an  
>>> answer for you
>>> > > > > >  problem.
>>> > > > > >  According to your problem I guess you are familiar with  
>>> this. > > > > >  Thats > > > why
>>> > > > > >  Im
>>> > > > > >  posing my problem here,
>>> > > > > >  I want to send request to a servlet and in the servlet  
>>> set a > > > > >  request
>>> > > > > >  attribute. Upto that part I know. But I  dont know how  
>>> to > > > > >  dispatch > > > the
>>> > > > > >  request to XHTML other that JSP.
>>> > > > > >  In JSP we do like this
>>> > > > > >  dispatcher.forward("/WEB-INF/Jsp/my.jsp");
>>> > > > > >  How can I do this for xhtml,
>>> > > > > >  Thanks, Sorry again for posing to here
>>> > > > > >  Gerrit Germis-2 wrote:
>>> > > > > > > >   Hi,
>>> > > > > > > >   I'm using struts/tiles with the nightly build of  
>>> xforms > > > > > > > > >   > > >  (separartely
>>> > > > > > >   deployed). I have successfully created and populated  
>>> my > > > > > >   xform, but
>>> > > > > >  now,
>>> > > > > > >   when I try to submit the results back to another  
>>> action using > > > > > >   the
>>> > > > > >  "post"
>>> > > > > > >   method, I loose my profile information that was  
>>> stored in the > > > > > >   > > > >  session.
>>> > > > > > >   This is what my submission looks like:
>>> > > > > > > >     <xforms:submission id="test-submit"
>>> > > > > > >         action="http://localhost:8080/umadmin/ 
>>> someAction" > > > > > > > > >         >        method="post"
>>> > > > > > >         ref="instance('document-instance')/data/
>>> DocumentRevision"
>>> > > > > > >   replace="all"/>
>>> > > > > > > >     <xforms:submit submission="test-submit">
>>> > > > > > >         <xforms:label>Go to action!</xforms:label>
>>> > > > > > >     </xforms:submit>
>>> > > > > > > >   The complete flow is like this:
>>> > > > > > > >   - setup: /xforms-jsp/* is setup to be filtered by  
>>> OPS
>>> > > > > > >   - User logs into the website, profile information is  
>>> stored > > > > > >   in
>>> > > > > >  session
>>> > > > > > >   - form is generated by navigating to URL:
>>> > > > > > >   http://localhost:8080/umadmin/xforms-jsp/some-app
>>> > > > > > >   - User fills in data
>>> > > > > > >   - User presses the submit button labeled "Go to  
>>> action!" > > > > > >   mentioned
>>> > > > > > >   above
>>> > > > > > >   - PROBLEM: user is prompted for login again since no  
>>> profile
>>> > > > > > >   information was found in session
>>> > > > > > > >   How can I make sure the profile information is not  
>>> lost on > > > > > > >   > > > > >  submission?
>>> > > > > > > >   Sincerely
>>> > > > > > >   Gerrit
>>> > > > > > > > > >   --
>>> > > > > > >   You receive this message as a subscriber of the > >  
>>> > > > >   [hidden email]
>>> > > > > >  mailing
>>> > > > > > >   list.
>>> > > > > > >   To unsubscribe: mailto:[hidden email]
>>> > > > > > >   For general help: mailto:[hidden email]?subject=help
>>> > > > > > >   OW2 mailing lists service home page: http://www.ow2.org/wws
>>> > > > > > > >   --
>>> > > > > >  View this message in context:
>>> > > > > >  http://www.nabble.com/submitting-with-method-%22post%22-and-loosing-sess
>>> > > > > >  ion-attributes-tf4803253.html#a13790034
>>> > > > > >  Sent from the ObjectWeb OPS - Users mailing list  
>>> archive at > > > > > > >  > Nabble.com.
>>> > > > > >  --
>>> > > > > >  You receive this message as a subscriber of the > > > >  
>>> >  [hidden email] > > > mailing list.
>>> > > > > >  To unsubscribe: mailto:[hidden email]
>>> > > > > >  For general help: mailto:[hidden email]?subject=help
>>> > > > > >  OW2 mailing lists service home page: http://www.ow2.org/wws
>>> > > > > > >  --
>>> > > > >  Orbeon Forms - Web Forms for the Enterprise Done the  
>>> Right Way
>>> > > > >  http://www.orbeon.com/
>>> > > > > > > > >  --
>>> > > >  Markku Laine <[hidden email]>
>>> > > >  Research assistant, Helsinki University of Technology
>>> > > >  Telecommunications Software and Multimedia Laboratory
>>> > > >  P.O.Box 5400, FIN-02015 HUT, FINLAND
>>> > > >  Mobile. +358-50-565 8179 (Finland)
>>> > > >  Mobile.  +64-21-037 3605 (New Zealand, 01 Oct - 21 Dec, > >  
>>> > >  2007)<OFSession.war>
>>> > > >  --
>>> > > >  You receive this message as a subscriber of the [hidden email]
>>>  > > >  mailing > list.
>>> > > >  To unsubscribe: mailto:[hidden email]
>>> > > >  For general help: mailto:[hidden email]?subject=help
>>> > > >  OW2 mailing lists service home page: http://www.ow2.org/wws
>>> > > --
>>> > > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>>> > > http://www.orbeon.com/
>>> > > --
>>> > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>>> > http://www.orbeon.com/
>>> > > --
>>> You receive this message as a subscriber of the [hidden email]  
>>> mailing list.
>>> To unsubscribe: mailto:[hidden email]
>>> For general help: mailto:[hidden email]?subject=help
>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>
> --
> Markku Laine <[hidden email]>
> Research assistant, Helsinki University of Technology
> Telecommunications Software and Multimedia Laboratory
> P.O.Box 5400, FIN-02015 HUT, FINLAND
> Mobile. +358-50-565 8179 (Finland)
> Mobile.  +64-21-037 3605 (New Zealand, 01 Oct - 21 Dec, 2007)
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

> Hi Erik,
>
>
>> I checked in all the code should be checked in and present in the  
>> build you got.
>>
>> You wouln't have both an ops.jar and an orbeon.jar in your WEB-INF/
>> lib, by any chance?
>
> You were right, I had forgot to update the JAR file to my web apps.  
> Now, the test app and my own apps are working perfectly! Thanks  
> heaps!!!
>
> Btw. According to the instructions at:
> http://www.orbeon.com/ops/doc/reference-xforms-java
>
> One should copy ops-xforms-filter.jar into WEB-Inf/lib/. However,  
> the newest version of Orbeon Forms doesn't inlcude that file. It  
> includes orbeon-xforms-filter.jar which is probably equivalent to  
> the old one, right?
>
> What about ops.jar and orbeon.jar you are referring to above? Should  
> I copy/use orbeon.jar instead of orbeon-xforms-filter.jar or what is  
> the purpose of that JAR file? Well... anyway, at least by using the  
> orbeon-xforms-filter.jar file the systme works. Maybe updating the  
> instructions would be a good idea, in case you have forgot to do so.
>
> Again, thanks heaps! Finally, my own XForms-based framework and  
> sample web apps are working perfectly :)
>
>
> -Markku