Timestamps are in GMT/BST.
[4:06] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:06] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:06] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:19] [freenode-connect VERSION]
[5:35] * cwilper (n=cwilper@74-44-155-90.dsl1-erie.roch.ny.frontiernet.net) Quit (Read error: 110 (Connection timed out))
[7:26] * cwilper (n=cwilper@74-44-155-90.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[8:05] * mhwood (i=mwood@134.68.171.23) has joined #duraspace
[9:18] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[9:18] * bradmc (n=bradmc@207.172.69.79) has joined #duraspace
[9:21] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:39] * justben (n=ben@hypatia.library.emory.edu) has joined #duraspace
[10:18] * bradmc (n=bradmc@207.172.69.79) Quit (Read error: 131 (Connection reset by peer))
[10:18] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:15] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[11:25] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:39] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[14:12] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[14:13] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:32] * StuartLewis_ (n=StuartLe@121.98.157.79) has joined #duraspace
[14:40] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[14:56] * jeffreytrimble (n=jeffreyt@maag127.maag.ysu.edu) has joined #duraspace
[14:58] * snail1 (n=stuart@130.195.178.61) has joined #duraspace
[14:58] <tdonohue> hi all...we'll be starting the DSpace Developers meeting here in a few minutes. Feel free to start posting agenda/topic suggestions
[14:59] <tdonohue> A few known agenda items: (1) Update & Timelines for 1.6
[15:00] <tdonohue> (2) Discuss proposal to start holding Special Topic meetings: http://wiki.dspace.org/index.php/Special_Topics
[15:01] <tdonohue> (3) Mark Diggory made a suggestion on #dspace today to form some sort of DSpace Infrastructure/Admin Group to manage SVN rights, Maven Admin, etc.
[15:01] <StuartLewis_> 3) Larry wants approval for the meta-generator patch
[15:02] <StuartLewis_> JIRA cleanup?
[15:03] <tdonohue> we could knock out the Jira issues again...looks like by my search we only have 6 new ones since last time: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-4w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC
[15:03] <tdonohue> (we ended with DS-375 last week)
[15:03] <StuartLewis_> Approval to apply: http://jira.dspace.org/jira/browse/DS-295 CC License being assigned incorrect Mime Type during submission.
[15:04] <tdonohue> ok...how about we start with any 1.6 updates...which should eventually lead to Stuart's postings of patchs to approve
[15:04] <StuartLewis_> Ok then...
[15:05] <StuartLewis_> Here's the plan: is everyone OK if we aim for a testathon / 'big bug hunt' week beginning 7th December?
[15:05] <StuartLewis_> Depending on the results and the effort we can muster to fix issues, we can either aim for a release just before Christmas, or early in the new year.
[15:06] <kshepherd> sounds good to me
[15:06] <tdonohue> sounds reasonable to me, assuming stats is coming along nicely (which it seems to be)
[15:06] <mhwood> Yes
[15:06] <StuartLewis_> Or if there are *lots* of issues, we can have an rc2 ealry next year
[15:06] <StuartLewis_> (stats are looking good now: http://testathon.net/xmlui/handle/123456789/29/statistics)
[15:06] <mdiggory> yes, stats is primarily just tidying up now
[15:07] <tdonohue> cool, JSPUI is good to go as well?
[15:07] <mdiggory> well, not sure about JSPUI, Kim?
[15:07] <kshepherd> and won't take me long to catch up with JSPUI
[15:07] <tdonohue> awesome
[15:07] <kshepherd> not finished yet, i'll send an email to dspace-devel when it is so we can start testing early
[15:07] <kshepherd> it is definitely looking smart, now
[15:08] <StuartLewis_> If everyoe is Ok with those dates, then we need to get going with advertising the testathon.
[15:08] <StuartLewis_> The november DSpace newletter hasn't gone out yet (final draft needs approving by Friday) so we can get it included in that.
[15:08] <tdonohue> definitely - was just going to say that
[15:08] <mdiggory> kshepherd: one question, your putting stats behind authz?
[15:10] <StuartLewis_> dspace.cfg 'report.public = false' ?
[15:10] <mdiggory> is this the old reporting stats page?
[15:10] <mdiggory> or property?
[15:11] <kshepherd> ah, hrm.. i'll take care of authz
[15:11] <tdonohue> could be nice to have a simple config, to let each repository decide whether to make public or not
[15:11] <StuartLewis_> That is the dspace.cfg key for the old stats public/private. Didn't know if you were asking if we should do the same with solr-stats?
[15:11] <snail1> some people are using stats to motivate depositors and get content
[15:11] <mdiggory> yes, we are looking at it in the XMLUI as a confiurable behavior
[15:12] <StuartLewis_> Cool
[15:12] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[15:12] <kshepherd> ok
[15:12] <mdiggory> snail1: yes
[15:12] <tdonohue> mdiggory: with it turned "on" by default (i.e. public by default?)
[15:12] <kshepherd> mdiggory: whatever you've done most recently in XMLUI is what i'm going by ;)
[15:12] <StuartLewis_> OK - a couple of patches that need approval to be applied:
[15:12] <StuartLewis_> http://jira.dspace.org/jira/browse/DS-295 CC License being assigned incorrect Mime Type during submission.
[15:13] <mdiggory> the XMLUI is currently without any access control
[15:13] <kshepherd> mdiggory: it shouldn't need to get too granular
[15:13] <mdiggory> true
[15:13] <kshepherd> even things like bitstream restrictions don't prevent them from being listed in teh UIs, by default
[15:13] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:13] <StuartLewis_> (We'll come back to the patches - didn't realise stats was still going!)
[15:14] <mdiggory> we can discuss this outside the committer meeting..
[15:14] <kshepherd> yeah
[15:14] <tdonohue> mdiggory: sounds good. are we done with stats updates then?
[15:14] <mdiggory> yep
[15:14] <tdonohue> go ahead stuart
[15:14] <StuartLewis_> OK: Patch 1:
[15:14] <StuartLewis_> http://jira.dspace.org/jira/browse/DS-295 CC License being assigned incorrect Mime Type during submission.
[15:15] <kshepherd> +1, needs doco? (for upgraders)
[15:15] <StuartLewis_> Yes - will be assigned to Jeff to copy the SQL commands into the upgrade docs once it is applied.
[15:15] <mhwood> +1
[15:15] <tdonohue> +1 - i agree with kshepherd - needs docs for upgrading
[15:15] <kshepherd> StuartLewis_: and the need to create the new bitstream format..
[15:15] <StuartLewis_> Need someone to check they work in Oracle
[15:16] <StuartLewis_> kshepherd: Yep - the first of the sql statements does that
[15:16] <tdonohue> isn't larry the main oracle person these days?
[15:16] <StuartLewis_> tdonohue: Yes - will ask him to check.
[15:16] <kshepherd> StuartLewis_: right, i see that now, missed it ;)
[15:16] <jeffreytrimble> Yes...I've asked for detailed steps regarding Oracle during the upgrade process.
[15:16] <StuartLewis_> And the second patch is:
[15:16] <jeffreytrimble> My assumption is that the postgresql is just one step
[15:17] <StuartLewis_> http://jira.dspace.org/jira/browse/DS-377 Add META tags identifying DSpace source version to Web UIs
[15:17] <StuartLewis_> See the comments in this one, especially Larry's last comment to explain how the version will be identified.
[15:18] <mdiggory> Looking at the topic...
[15:18] <tdonohue> +1 sounds good to me - glad we can populate based on version in Maven POM
[15:18] <mhwood> +1
[15:18] <mdiggory> A maven based approach would use filtering in the mvn package phase
[15:19] <kshepherd> +1
[15:19] <mdiggory> you don't really need to java code this
[15:20] <tdonohue> mdiggory: does this mean you disagree with Larry's approach?
[15:20] <kshepherd> hmm.. needs more discussion?
[15:20] <mdiggory> identify the files you want to filter and create a parameter in them, map that parameter in the pom.xml
[15:20] <mdiggory> on release that parameter will be processed
[15:21] <mdiggory> Seems like its coding before researching
[15:21] <tdonohue> mdiggory: so you are saying you'd list the specific files in XMLUI or JSPUI that need a parameter to be replaced?
[15:21] <mdiggory> pretty much
[15:21] <tdonohue> and the maven will replace it during the packaging?
[15:21] <mhwood> So you want the package phase to customize the XSL or something? It'd have to track down all a site's themes....
[15:21] <mdiggory> war generation includes filtering
[15:22] <tdonohue> would it also work for completely custom themes, like mhwood brings up?
[15:22] <mdiggory> I assume you would run this risk if you were overriding that header in dri2xhtml
[15:23] <jeffreytrimble> We'd have to warn users about this....so they remember to re-customize those files affected by this.
[15:24] <mdiggory> but i will add... theres no reason this couldn't be in a properties file or the default Navigation transformer rather than chasing individual xslt templates
[15:24] <mhwood> It's being fetched from a properties file now.
[15:24] <jeffreytrimble> But it is entirely possible to gather up a list of files that this change would/does affect and let the users know the work they have in store?
[15:24] <mdiggory> in which case, it might not even be maven based filtering... just use SVN versioning infor
[15:25] <mdiggory> svn keywords in the java classes
[15:25] <mdiggory> or a properties file
[15:25] <bradmc> Seems fragile to have it scattered among customizable files. An include of a single file that gets changed seems more robust - but creates other issues.
[15:25] <tdonohue> jeffreytrimble: yes, you are right...we should warn users about this either way...and i think once we've finalized how to do this, we can get you a list of affected files
[15:25] <mdiggory> int he classpath for xmlui-api, dspace-api or jspui-api
[15:25] * StuartLewis__ (n=StuartLe@121.98.157.79) has joined #duraspace
[15:26] <mhwood> If sites have to be warned about such matters...do we really want to do that to them?
[15:26] <jeffreytrimble> let's not use the word warning...let just say they need to be aware that the upgrade has some changes they may need to address in customizations.
[15:27] <tdonohue> bradmc +1 changing in one place is probably best.
[15:27] <mdiggory> doesn't need to be perfect... you cannot guarantee UI html serialization behavior... another option might be response headers?
[15:28] <mdiggory> which could be theme independent
[15:28] <tdonohue> seems like we are over thinking this....to be honest, Larry's patch is rather small
[15:29] <tdonohue> and maybe there is some use to being able to get that version via a Java call
[15:29] <mdiggory> not really, All I'm talking about in this case is one line in the servlets that spits out the build number, replaced using svn keyword substitution
[15:29] <tdonohue> maybe eventually one could run "dspace --version" to get a report of what version they are running, etc
[15:30] <mdiggory> seems like a job for the XMLUI Control Panel
[15:30] <mhwood> I kinda want to use the same information in a human-readable place, like: "This is DSpace 1.6.0, ScholarWorks build 123"
[15:31] <bradmc> like having dspace validate that it's code matches it's database schema? Couldn't do that at the UI level.
[15:31] <snail1> it would also be useful to have the version in an HTML comment on the homepage by default
[15:32] <StuartLewis__> snail1: It was that suggestion that kicked-off this discussion :)
[15:32] <mdiggory> downfall with svn keyword approach is that it might change across repos where the code is being duplicated (yuck)
[15:32] <kshepherd> the original patch added a meta tag
[15:32] <kshepherd> but the discussion's gone a bit over my head since then ;)
[15:33] <mdiggory> can add meta tag, can also add response header... both relatively easy, first is UI dependent, second can be deeper in the content generation layer
[15:33] <mdiggory> big question, what is wanted to be known by "us" when looking at a DSpace instance
[15:34] <mhwood> I think it boils down to whether the cost of keeping multiple copies in sync. outweighs the cost of going to a single definitive copy every time you want it.
[15:34] <mdiggory> as someone troubleshooting DSpace I want to know (1) version (2) build (3) build date (4) by whom
[15:34] <tdonohue> so, how do we come to a consensus here? mdiggory are you still against Larry's approach?
[15:35] <mdiggory> Yes I'm against this code solution
[15:36] <mdiggory> hmmm.... wait
[15:36] <mdiggory> let me review it just a little more.
[15:36] * bradmc muses on bikesheds
[15:37] <kshepherd> i'm a bit worried about complicating things too much for a small feature that was an idea /we/ had rather than the community-at-large
[15:38] <mdiggory> ok... no I am not against this approach.
[15:38] <mdiggory> I will add
[15:38] <mdiggory> that if you want "build" specific customization...
[15:39] <tdonohue> ok, so do we want to revote to (1) start with Larry's approach for 1.6...after 1.6 (2) we can review it and see if it needs to be tweaked to provide more info (like kshepherd suggests)
[15:39] <mdiggory> generalize this slightly to (1) return the properties as well as string and (2) add ability to lookup pom by package
[15:40] <StuartLewis__> +1 Larry's solution, look at improving it later if required.
[15:40] <mdiggory> the mhwood can add his modules/xmlui/pom.xml properties for his particular build as a second property
[15:40] <mdiggory> in that packages pom.xml pom.properties
[15:42] <mdiggory> recommend adding call to this class in DSpaceServlet and/or appropriate class in XMLUI to support setting response headers
[15:42] * StuartLewis_ (n=StuartLe@121.98.157.79) Quit (Read error: 110 (Connection timed out))
[15:42] <tdonohue> mdiggory: I think you are starting into a different feature request. This feature was just a recommendation for a simple HTML <Meta> tag to identify the version of DSpace you are running
[15:43] <tdonohue> but, I think we could add a new Jira request for some of the features you are talking about
[15:43] <mdiggory> no, XMLUI themes may have overridden the creation of html head meta
[15:43] <mdiggory> sticking it into the response header assures robustness
[15:43] <tdonohue> mdiggory: true...but ast jeffreytrimble said, we can let users know that in the upgrade docs
[15:44] <mdiggory> we see this usefull for different reasons
[15:44] <mdiggory> response header requires no documentation caveats
[15:44] <jeffreytrimble> On the UI side, it's good to know what version a site is running....
[15:44] <tdonohue> yea, i can agree with that. That's part of why I wonder if this needs to be a separate Jira issue that we can vote on separately
[15:44] <jeffreytrimble> on the admin side, it's good to know the version and the build.
[15:45] <mdiggory> this is both cases
[15:45] <StuartLewis__> But joe-average-dspace-repo-manager doedn't know how to interrogate http headers
[15:45] <mhwood> I think the code as it stands can be used for several quite different purposes, including the original one. A separate issue could then evolve it as needed, later.
[15:45] <jeffreytrimble> really? My users could care less what build we are running...let alone versions...but all of us here today would be interested in at least the version
[15:46] <mdiggory> This is not for average joe
[15:46] <mdiggory> this is for webdeveloper troublshooter
[15:46] <mdiggory> developer administrator
[15:46] * tdonohue notices we've been on this same issue for 30+ minutes
[15:46] <StuartLewis__> Well it might be - if we tell them 'view the html source and tell us what is says at GENERATOR='
[15:46] <mhwood> And my supervisor, who regularly asks, "what versions are we running now?"
[15:46] <mdiggory> no, I say... send me a link to your site and I look
[15:47] <tdonohue> ok, i'd like to suggest we agree to disagree on this, and just choose something for 1.6. It can always be tweaked for 1.6.1 :)
[15:48] <mdiggory> you can always put it in the control panel or present it in the footer if you have such interested supervisors
[15:49] <mdiggory> agreed, at least we agree to add what is there
[15:49] <tdonohue> do we want to revote on Larry's suggestion for 1.6? And then add a new Jira issue with these extra suggestions (so that we can track them -- some good thoughts here)
[15:49] <kshepherd> having something simply for troubleshooting by developers sounds cool, but it can't be something that makes extra work for IR admins in terms of themes, etc...
[15:49] <kshepherd> especially since they're not the ones asking for it ;)
[15:50] <mdiggory> just tack them into the JIRA issue thats there... commit the patch and say... if you want to do more, continue to use this JIRA ticket.
[15:50] <mhwood> That's why I worry that I keep seeing, "we need to document how we're going to break your themes"
[15:50] <kshepherd> mhwood: yeah
[15:50] <mdiggory> themes not broken...
[15:50] <tdonohue> Ok, I'm calling for a revote on: http://jira.dspace.org/jira/browse/DS-377 as-is for 1.6.
[15:50] <mhwood> Feature broken unless you re-customize?
[15:50] <tdonohue> +1
[15:51] <kshepherd> but in this case, nothing 'broken', just.. it won't work without extra effort on those custom themes
[15:51] <mdiggory> nothing being done here is non-backward or forwards compatable
[15:51] <StuartLewis__> DS-377: +1
[15:51] <mhwood> +1
[15:51] <mdiggory> using response header is just more reliable given chance that its been customized out of someones theme
[15:51] <mdiggory> +1
[15:52] <kshepherd> +1
[15:52] <snail1> +1
[15:52] <StuartLewis__> We can do headers too if we get a patch
[15:52] * mdiggory hint taken
[15:52] <StuartLewis__> ;)
[15:52] <tdonohue> no worries, mark. It's good to have a nice disagreement every now and then...it's healthy :)
[15:53] <mhwood> I learned a few things, or will have when I've worked through them.
[15:53] <mdiggory> I totally disagree ;-)
[15:53] <tdonohue> haha :)
[15:53] <kshepherd> heh
[15:54] <tdonohue> while we are in Jira...has anyone had a chance to look at my proposal in http://jira.dspace.org/jira/browse/DS-382 - It's very small, and I thought we could squeeze this in
[15:54] <tdonohue> This is just to add 'dc.creator' to the Browse By Author indexes by default
[15:55] <kshepherd> yes, +1
[15:55] <StuartLewis__> +1
[15:55] <mhwood> 0
[15:55] <kshepherd> this is particularly useful since the OAI harvester patch is in 1.6
[15:55] <kshepherd> and if you harvest other dspace instances, you will end up with a lot of dc.creator metadata
[15:55] <mdiggory> +1
[15:55] <tdonohue> ok, i'll go ahead and commit it...just wanted to run it by folks first
[15:55] <snail1> +1
[15:56] <mdiggory> are we doing these in order?
[15:56] <mdiggory> I'm concerned about http://jira.dspace.org/jira/browse/DS-383
[15:57] <tdonohue> mdiggory - no..we actually weren't doing a formal Jira review (I just through that in the 1.6 discussion which Stuart started )
[15:58] <kshepherd> hmm
[15:58] <tdonohue> but, we could go ahead and talk about DS-383
[15:58] <StuartLewis__> Yeah - 1.6 discussion over for now?
[15:58] <tdonohue> yea..I think we are good on 1.6 now
[15:58] <mdiggory> I had assumed exceptions should cause a Context.abort
[15:59] <kshepherd> afk for a bit, too many meetings at once!
[15:59] <mdiggory> I can see that if the users customizing dspace and is not aborting in the case of an exception themselves... it may bubble up to this level
[16:00] <mdiggory> I assume Robin Taylor is doing some customization
[16:00] <tdonohue> anyone want to volunteer to follow up with her and get more background on DS-383?
[16:01] <tdonohue> but, it does sound/look fishy
[16:02] <mdiggory> I can look a little into it...
[16:02] <tdonohue> ack, sorry robin..i meant follow up with *him* (my mind is elsewhere)
[16:03] <tdonohue> mdiggory: thanks
[16:04] <tdonohue> well, we've gone over (as always)...I'm calling this to a close.
[16:05] <tdonohue> StuartLewis_ did you want to summarize/paste this discussion into DS-377 ... If not, I can do it
[16:05] <StuartLewis__> OK - I'll do it now
[16:05] <StuartLewis__> (and try and get the right issue ;)
[16:05] <tdonohue> cool, thanks. :)
[16:06] <StuartLewis__> tdonohue: Actually - could you do it - my IRC dropped out for a few minutes half way through
[16:07] <tdonohue> ok, no prob. I'll do it. Though, FYI...we are being "logged" : http://www.duraspace.org/irclogs/index.php?date=2009-11-18
[16:07] <StuartLewis__> Oh right - didn't know how often the logs were updates.
[16:07] <StuartLewis__> Thanks :)
[16:07] <tdonohue> yea, they update rather quickly actually
[16:07] <StuartLewis__> Wow - instant updates
[16:07] <grahamtriggs> We're assuming that by the time DSpaceCocoonServletFilter executes the closeContext, that the context hasn't already been aborted elsewhere (in which case, the closeContext will effectively no-op)
[16:08] <mhwood> So it's racy as well?
[16:08] <mdiggory> not so sure it is racy
[16:09] <mdiggory> as context is a request scoped object
[16:10] <mdiggory> } catch (Throwable t) {
[16:10] <mdiggory> ContextUtil.abortContext(realRequest);
[16:10] <mdiggory> } finally {
[16:10] <mdiggory> // Close out the DSpace context no matter what.
[16:10] <mdiggory> ContextUtil.completeContext(realRequest);
[16:10] <mdiggory> }
[16:10] <mdiggory> its aborted the line before if we are in a thrown exception
[16:11] <StuartLewis__> Ah - so that looks better.
[16:11] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[16:11] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:11] <mdiggory> but... does something like the
[16:11] <mdiggory> realResponse.sendRedirect
[16:12] <mdiggory> get in the way of anything
[16:13] <mdiggory> I assume sendRedirect returns and continues on to arg2.doFilter... brrrr
[16:13] <mdiggory> StuartLewis_ didn't we just learn this lesson elsewhere
[16:13] <StuartLewis__> Indeed ;)
[16:14] <StuartLewis__> doFilter must be in an 'else'
[16:16] <StuartLewis__> Apologies if I'm been distracted during the meeting - I've been 'enduring' a Wiggles DVD in the background!
[16:16] * tdonohue feels sorry for Stuart
[16:16] * StuartLewis__ sings "We're going to do the monkey"
[16:16] * mdiggory dislikes putting https redirection into servlet code... is responsibility of container
[16:16] <grahamtriggs> I think it's unlikely that you'll get an exception thrown out of the filterchain - Cocoon is catching them and pushing them through a org.apache.cocoon.generation.ExceptionGenerator to display the error page
[16:17] <StuartLewis__> Is there anything we can do to 'brand' the cocoon error page?
[16:17] <mdiggory> grahamtriggs: good point
[16:17] <StuartLewis__> Our users see it from time to time when their sessions time out during a deposit etc.
[16:17] <grahamtriggs> Most likely, we would need to create a custom ExceptionGenerator, which would ensure that any existing context is aborted
[16:18] <mdiggory> there are two places exceptions are serialized, one brands them, the other doesn't becuase its outside of the aspect chaining mechanism
[16:18] <tdonohue> StuartLewis_ +1 - branding those ugly cocoon errors would be nice to figure out
[16:18] * jeffreytrimble (n=jeffreyt@maag127.maag.ysu.edu) Quit ("Leaving")
[16:19] <mhwood> ExceptionGenerator kills both with one stone?
[16:19] <mdiggory> the relevant ones are... the ones not branded are outside of the sitemap where such branding occurs
[16:20] <mdiggory> do you really want to try to theme an exception caused in the themeing? sounds like a recipe for ad infinitum to me
[16:21] <StuartLewis__> Could use a generic 'DSpace error' theme - just slightly branded would be nice
[16:21] <mdiggory> probibly a good discussion point to include Scott Philips on
[16:21] <tdonohue> mdiggory good point - just be nice to avoid them in most normal browsing cases
[16:23] <snail1> StuartLewis__: I'm not sure it's possible to brand 100% of all cocoon errors without a custom build of cocoon
[16:23] <mdiggory> example (1) http://testathon.net/xmlui/browse?value=Cho,+YoonYoung&tye=author
[16:23] <mdiggory> example (2) http://testathon.net/xmlui/handle/1234567/123
[16:23] <StuartLewis__> What is the reason (1) can't be?
[16:24] <mdiggory> why it exceptions?
[16:24] <tdonohue> yea, seems like #1 could be themed like the "page not found" page
[16:24] <mdiggory> "tye" is not "type"
[16:25] <mdiggory> look inside, see why this exception isn't properly caught and handled
[16:25] <mdiggory> Null pointer exception in Validity
[16:26] <mdiggory> would seem catchable...
[16:26] <tdonohue> seems like that should throw a more informative exception than "NullPointer"
[16:26] <mdiggory> possibly at at org.dspace.app.xmlui.cocoon.AspectGenerator.setup(AspectGenerator.java:112)
[16:27] <grahamtriggs> mdiggory: I don't think the exception should be themed - but we could tart up the exception2html.xslt a bit
[16:27] <mdiggory> NullPointers are never very informative...
[16:27] <tdonohue> exactly
[16:27] <mdiggory> Sure wish java at least said what the null pointer was "on"
[16:28] <mdiggory> so I don't have to stare at the code for 10 minutes
[16:30] <mdiggory> dress it up
[16:32] <mdiggory> grahamtriggs: I agree... the importance of exceptions is that we can (a) get a copy of them and (b) replicate them... fully theming them adds a layer of further opportunities for something else to block our view of the error
[16:33] <mdiggory> but I agree... maybe a little more verbage and an attempt to include a administrotor/contact email might be helpful
[16:33] <mhwood> I can see reassuring the user that DSpace hasn't completely gone down in flames, and encouraging him to save the page and send it to the sysadmin (address given).
[16:34] <mdiggory> take it a little further and encode the exception and some of the request attributes into a mailto link and then the admin doesn't need to ask for a copy of the stack trace
[16:34] <grahamtriggs> except in a production environment, you don't necessarily want to scare the users / expose the internals of the system. *log* the exception, *email* the exception, but not display the exception. There ought to be an example provided to do that
[16:35] <mdiggory> true
[16:35] <mhwood> I like it.
[16:36] <mdiggory> getting back to the topic of DS-383
[16:36] <mhwood> "We're experiencing technical difficulties. The administrator has been notified."
[16:37] <mdiggory> we need to make sure all exception generator handling is aborting the context
[16:37] <StuartLewis__> brb - heading off to work now
[16:37] * StuartLewis__ (n=StuartLe@121.98.157.79) Quit ()
[16:39] <grahamtriggs> mhwood: "We're experiencing technical difficulties. The administrator is out getting drunk right now, but will probably get back to you in three days when the hangover subsides - providing the error report hasn't been deleted with the rest of the spam"
[16:39] <mhwood> grahamtriggs: Well, that's implied.
[16:40] <tdonohue> grahamtriggs: well, obviously we'd let you customize the message that gets displayed :)
[16:59] * mhwood (i=mwood@134.68.171.23) has left #duraspace
[17:10] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 131 (Connection reset by peer))
[17:10] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[18:02] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:03] * justben (n=ben@hypatia.library.emory.edu) Quit ("Leaving.")
[18:50] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit ()
[20:30] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) Quit ()
[21:39] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
[21:47] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
[22:17] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
[22:18] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
[23:21] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) Quit ()
[23:22] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.