[ http://jira.dspace.org/jira/browse/DS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Donohue updated DS-613:
Assignee: Tim Donohue
Status: Open (was: Received)
This issue was discussed in the Developer Meeting on 08 Sept 2010.
Needs further investigation into the best solution. But, it definitely shouldn't be throwing such an ugly, meaningless exception message.
[20:04] <tdonohue> DS-613 : Error Handling in the XMLUI interface after section expired http://jira.dspace.org/jira/browse/DS-613
[20:04] <grahamtriggs> sounds like the rdf should be internal - which is not the same as saying it doesn't get exposed ever by any part of the system (otherwise there wouldn't be any point in storing it)
[20:05] <tdonohue> mhwood -- yea, I think the fix for the other bug caused this DS-612 problem -- in either way, MIT is reworking the CC License stuff, so once that code is in, it *may* fix DS-612
[20:07] <tdonohue> Thoughts on DS-613 ? Seems like it might be logical to try and catch this "invalid continuation" error and at least display a nicer "Your Session has Expired" page ?
[20:07] <mhwood> DS-613: well, it shouldn't do *that*. If the session is expired then doesn't the user need to login again? And if so, what is the state of the submission?
[20:07] <mhwood> *That* was meant to be "throw an invalid-continuation page".
[20:08] <tdonohue> yea, I agree mhwood -- it needs to at least display some sort of nice message (even if that message is just "please login again"
[20:08] <grahamtriggs> not clear how continuation and login are related (may not necessarily have the same lifecycle).... should have a nicer error if possible
[20:08] <mhwood> The poor user probably has no idea what an invalid continuation is.
[20:08] <richardrodgers> +1 but needs a volunteer
[20:09] <tdonohue> grahamtriggs -- 'invalid continuation' is basically Cocoon reporting that it has lost its session info
[20:09] <tdonohue> +1 -- any volunteers?
[20:10] <grahamtriggs> yes, but is that the same as a http (/ dspace) session? eg. frameworks like Seam have multiple lifecycles that aren't related to the HTTP session
[20:10] <mhwood> So how does the user get a new valid session?
[20:11] <mhwood> Or whatever it is called.
[20:12] <tdonohue> I think basically they need to relogin. Something in cocoon has "timed out" -- so it's either increase the cocoon timeout (as cocoon imbeds 'continuation IDs' into each HTML page and uses those to keep its 'context'), or catch this exception and display a nicer page
[20:12] <tdonohue> I can dig into this one a bit -- if I cannot figure it out, we'll revisit. Assign DS-613 to tdonohue for analysis.
[20:12] <grahamtriggs> and similarly, could we be potentially use a continuation for an anonymous session (ie. refining search queries)
[20:12] <mhwood> Yes, if we can't tidy things automatically then we must tell the user what he needs to do in terms he understands.
[20:13] <mdiggory> continuations actually are maintained separate from sessions in Cocoon. I'm not 100% sure how thy get expired with the session.
[20:13] <tdonohue> grahamtriggs -- right. eventually. Currently though we are really only using continuations in places where a user is logged in -- so, right now, when the continuation times out, it can be refreshed with a login
[20:14] <grahamtriggs> so we should be careful in our handling not to tie the message to 'you must log in again', as that may not always be true
[20:15] <tdonohue> possibly. I'm not sure if that's even the best resolution (to display a nicer error page) -- it's possible there's a way to just avoid this problem by trying to extend the timeout. It basically needs further analysis before we can make a decision
[20:15] <mhwood> The association with session may be just what the reporter thinks is happening. Still, how does the user get a fresh continuation or get back into the process he was following?
[20:17] <tdonohue> mhwood -- continuations are setup during processes like Editing or a new submission. So, essentialy if your continuation is gone, you have to relogin in and then go back to edit that item or continue your submission.
[20:17] <tdonohue> mhwood -- but as grahamtriggs pointed out, it's possible to use continuations in other areas as well
[20:18] <mhwood> Unfriendly -- I HATE sites that drag you through a long complex process only to find that you've been timed out in the interval.
[20:18] <tdonohue> mdiggory -- yea, I'd not be against discontinuing them -- but, that's a much larger project to rip out Cocoon continuations altogether :(
[20:19] <tdonohue> any other thoughts on this? Should we open up a 'placeholder' issue to investigate removing usage of continuations altogether?
[20:20] <mdiggory> possible example of handling the error differently....
[20:20] <mdiggory> http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html
[20:21] <tdonohue> thanks for the link -- I thought there was a better way to catch the error, minimally
[20:21] <tdonohue> Ok, for now, assign DS-613 to tdonohue for investigation.
[20:21] <mdiggory> more specifically... the handle errors section of the sitemap code
[20:21] <mdiggory> <map:handle-errors>
> Error Handling in the XMLUI interface after section expired
> Key: DS-613
> URL: http://jira.dspace.org/jira/browse/DS-613
> Project: DSpace 1.x
> Issue Type: Improvement
> Components: XMLUI
> Affects Versions: 1.6.0
> Environment: apache-tomcat-6.0.18
> Debian GNU Linux 5.0
> Reporter: Antero Neto
> Assignee: Tim Donohue
> Fix For: 1.7.0
> Attachments: invalid-continuation.jpeg
> When editing metadata if the user is away long enough to the section expire, the return is a cocoon "invalid continuation" error.
> See attached print.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://jira.dspace.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira