Timestamps are in GMT/BST.
[5:59] * sbayliss (bcde58ad@gateway/web/freenode/ip.188.222.88.173) Quit (Quit: Page closed)
[6:32] -hubbard.freenode.net- *** Looking up your hostname...
[6:32] -hubbard.freenode.net- *** Checking Ident
[6:32] -hubbard.freenode.net- *** Found your hostname
[6:32] -hubbard.freenode.net- *** No Ident response
[6:32] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:32] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:32] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:07] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[11:56] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[12:15] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) Quit (Ping timeout: 264 seconds)
[12:15] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[12:49] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (Read error: Connection reset by peer)
[12:49] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[13:22] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[13:37] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) Quit (Ping timeout: 264 seconds)
[13:50] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[16:34] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[19:04] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) has joined #duraspace
[19:42] * keithgilbertson (~keithgilb@nc652091b.cns.vt.edu) has joined #duraspace
[19:50] * bojans (~Bojmen@91-118-59-116.dynamic.adsl-line.inode.at) has joined #duraspace
[19:51] <tdonohue> Hi all, reminder that DSpace Developers Mtg will start here in about 10 min: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-07
[19:51] <kompewter> [ DevMtg 2011-09-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-07
[19:56] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[19:56] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[20:00] <tdonohue> Hi all, the DSpace Developers Meeting is beginning here now. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-07
[20:00] <kompewter> [ DevMtg 2011-09-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-07
[20:01] <tdonohue> Essentially, today is dedicated towards any final preparations before 1.8.0 Testathon, which starts next Monday
[20:02] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:02] <tdonohue> One thing to note is that the Testathon announcement will go out immediately after this meeting (I meant to send it earlier today, but I'm catching up from my holiday)
[20:03] <tdonohue> beyond that, do we want to just dive in and talk about 1.8.0 updates & final Testathon planning?
[20:03] <tdonohue> robint, do you want to take the lead here?
[20:03] <robint> Ok, it would be good if people could review their Jira issues
[20:04] <robint> and any that wont make 1.8 they could reassign to post-1.8
[20:04] <robint> the main culprits are...
[20:04] * keithgilbertson (~keithgilb@nc652091b.cns.vt.edu) Quit (Quit: keithgilbertson)
[20:04] <robint> me ! Tim and Mark D
[20:05] <robint> Apart from that I think the big remaining job is the documentation
[20:05] <tdonohue> gulp. me, really? oh the "Replication Task Suite" -- yea, that probably needs a clearer "assignment" (even though it will be released as a separately installed add-on, it shouldn't be labeled as 1.8.0. I'll take care of that).
[20:06] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:06] <tdonohue> do you know offhand who is "lacking" in their documentation (i.e. who gave us undocumented features/improvements), so that we can pester them? :)
[20:06] <robint> I need to pester the MIT gang about docs for the CC Rewrite
[20:07] <robint> snap
[20:07] <PeterDietz_OSU> I need to pester myself to docify the RSS improvements
[20:07] <robint> Dont pester yourself in public !
[20:07] <tdonohue> PeterDietz_OSU -- yes, please. It'd be good to at least have a draft before Monday (so folks know how to enable it & test it)
[20:08] <robint> I have pestered Richard jones about the SWORD2 stuff
[20:08] <PeterDietz_OSU> Don't forget that lazy ...
[20:08] <robint> Although I am pretty relaxed about that as I doubt many people will have clients to try it out
[20:09] <KevinVdV> I plan to write some documentation about the services either tomorrow or the day after tomorrow (couldn't edit the wiki page until an hour ago so couldn't do it sooner)
[20:09] <tdonohue> mdiggory: you might want to go back & read the early logs of this mtg. you, robint & I need to clean up our assigned JIRA issues & either close them (if they actually are in 1.8.0) or move to "post-1.8.0" if they are delayed.
[20:10] <robint> The Configurable Workflow stuff is already nicely documented
[20:11] <robint> So, the CC stuff is the notable omission
[20:11] <robint> Oh, and maybe new Curation tasks, although I haven't looked at that yet
[20:12] <tdonohue> yea, I suspect there may be some necessary docs for the new Curation Tasks. Perhaps also the Virus checking during submission? (or are those done?)
[20:12] <robint> No that is still missing
[20:13] <robint> I wasn't sure where to put them,
[20:13] <robint> possibly in amongst the Curation stuff
[20:13] <tdonohue> yea, that seems logical enough for now. Either that, or as a subpage of the Submission stuff...
[20:14] <tdonohue> How about Installation & Upgrade Documentation? Do we have a first draft of either of those? Or, someone willing to write up a quick first draft?
[20:15] <mhwood> It's hypertext. One can point at the other.
[20:15] <robint> I confess I haven't given that any thought yet
[20:15] <tdonohue> (again, none of these docs need to be perfect right now -- we can clean them up in the coming weeks, etc. But, it'd be good to get a first draft of everything done, if possible)
[20:16] <tdonohue> Any volunteer(s) to do an initial draft of the Installation and/or Upgrade Docs? Likely they will be similar to past docs, but it'd be good to have someone go through them
[20:17] <hpottinger> I can take the Install/upgrade docs, was planning to edit them based on what I find as I install for the testathon
[20:18] <tdonohue> hpottinger, that'd be wonderful! Whoever sets up 'demo.dspace.org' (likely either Robint or I -- I haven't talked to robint about this yet) could also help give a read through, etc
[20:19] * robint_ (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[20:19] <robint_> Sorry, IE crashing
[20:20] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Ping timeout: 252 seconds)
[20:21] <tdonohue> hpottinger: also, once you know the URL for the Testathon instance you are planning to setup, we should provide links to it as well. Currently, there's a rough testathon page up at: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Testathon+Page (based heavily on the Testathon page that PeterDietz created for 1.7.0)
[20:21] <kompewter> [ DSpace Release 1.8.0 Testathon Page - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Testathon+Page
[20:21] <hpottinger> already have the domain, it doesn't "go anywhere" yet, but I can add it to that page
[20:22] <tdonohue> robint: hpottinger volunteered to help with install/upgrade docs. I said that whoever updates 'demo.dspace.org' (either you or I) should be able to help give an extra pair of eyes.
[20:23] <robint_> tdonohue: Great. My browser crashed just when you were asking for volunteers. Who says IE is rubbish !
[20:23] <robint_> Thanks hpottinger
[20:24] <tdonohue> Ok, so, robint will commence pestering of those who have not provided proper docs :)
[20:25] <mdiggory> tdonohue: ok... also need to invest the time on the SWROD release. I got distracted but it shouldn't take much time to execute.
[20:25] <robint_> mdiggory: Thanks for stepping in there, much appreciated
[20:26] <tdonohue> mdiggory: fyi, if you are moving around SWORD 2 stuff, you may need to "sync" things up with robint. I think robint is planning to "cut" 1.8.0 RC1 sometime tomorrow
[20:26] <mdiggory> yep. glad to be of service, and thank you robint
[20:27] <mdiggory> ok, its important to clear the snapshots from the dependencies.... that'll be your first warning....
[20:28] <tdonohue> mdiggory: yes, I just wanted to avoid a situation where you start your "cleanup" and robint releases 1.8.0 RC1 at the same time :)
[20:28] <mdiggory> right
[20:29] <hpottinger> I'll just jump in and say that I'm still plugging away at DS-990, hope to have something to commit by tonight... was supposed to be any easy "no brainer", I'm finding myself trying to grok the entire build.xml, fun times
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-990 ] - [#DS-990] Change 'ant update' to default to "overwrite=true" mode - DuraSpace JIRA
[20:29] <tdonohue> cool, I was going to bring that up just now, hpottinger. good timing
[20:30] <tdonohue> is there any more "eyes" or help/opinions you need on DS-990?
[20:30] <kompewter> [ https://jira.duraspace.org/browse/DS-990 ] - [#DS-990] Change 'ant update' to default to "overwrite=true" mode - DuraSpace JIRA
[20:30] <robint_> mdiggory: I'll delay doing the RC until later tommorow (my time) so that you are online and I can let you know what I;m up to.
[20:31] <hpottinger> sure, more the merrier! :-) note that it helps if you have a current version of Ant :-)
[20:31] <mdiggory> Ok, thanks, I'll leave IRC up, but you can also Skype me directly
[20:32] <tdonohue> I was going to ask about Ant versions. Is the whole issue because Ant 1.7.x acts differently than Ant 1.8.0 with regards to the "if/unless" settings in Ant Targets?
[20:32] <tdonohue> (i.e. should we think about just requiring Ant 1.8.0 or above? Or is that too drastic here?)
[20:32] <mdiggory> I will (1) release the foresite toolkit as 1.0 (2) update version info in dspace (3) work on SWORD and see if the snapshot release works as easy there and do the same
[20:33] <mdiggory> if (3) doesn't work too well, then rc1 will still hold the SWORD libs
[20:33] <hpottinger> actually, I think that might have been a red herring, in that I'm seeing the same behavior when running Ant 1.8.2
[20:33] <robint_> mdiggory: Sounds good. Thanks
[20:33] <mdiggory> tdonohue: probibly not too drastic...
[20:34] <tdonohue> ok, good to know hpottinger. I'd be glad to try and give an extra pair of eyes on whatever you come up with for Ds-990.
[20:35] <tdonohue> In general, we should feel free to change our pre-requisites as needed. If Ant 1.7 requirement is now outdated, I'm fine with switching to Ant 1.8 (I honest don't know what Linux systems come with these days in terms of Ant packages)
[20:35] <robint_> Re 990, this will need to be reflected in the upgrade and general docs
[20:35] <hpottinger> tdonohue, great, thanks, as it is, the patch on Ds-990 is what I'm using, and if you or anyone else is willing to test, just be sure you have Ant 1.7.1+
[20:35] <mhwood> Gentoo currently ships Ant 1.8.1.
[20:35] <hpottinger> RHEL5 comes with Ant 1.6.5 (circa 2006)
[20:37] <hpottinger> it's no big thing to set up a personal binary copy of Ant, though
[20:37] <tdonohue> robint_: yes, we need to make Ds-990 very *explicit* (bolded, in bright flashing colors, etc.) in the upgrade docs - ok, maybe it doesn't need to be flashing :)
[20:38] <tdonohue> ok, I'll help do some testing on Ds-990 as well, hpottinger. Likely won't get to it until tomorrow though, to be honest.
[20:39] <robint_> Is now a good time to have a wee chat about DS-959 ?
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-959 ] - [#DS-959] XMLUI login failure when using Tomcat 7.0.16 - DuraSpace JIRA
[20:39] <tdonohue> The other outstanding issue (a bug) that'd be nice to fix before 1.8.0 final -- DS-959. Has anyone had a chance to look into this? or would be willing to look into this in the coming weeks?
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-959 ] - [#DS-959] XMLUI login failure when using Tomcat 7.0.16 - DuraSpace JIRA
[20:39] <tdonohue> robint_ and I think alike :)
[20:39] <robint_> I noticed another email about it today on one of the mailing lists
[20:40] <robint_> If we don't fix it now we will have to sometime soon
[20:40] <hpottinger> I did some googling around, I think that there were significant changes to how Tomcat handles sessions from 6 to 7
[20:41] <tdonohue> yea, I see Ds-959 as a very high priority fix for 1.8.0 final. So, we really need to have someone or someones dig into what is going on.
[20:41] <robint_> I'll have a look next week
[20:42] <robint_> But the more people investigating the better
[20:42] <tdonohue> ok, sounds good. I can also try to chip in as well (and I'd encourage others to do so as well -- it seems like we have some good ideas in the comments, but nothing has been verified, and no one seems to have found the exact issue yet)
[20:42] <KevinVdV> I took a look at it quickly but haven't found anything at the moment
[20:42] <tdonohue> i agree, the more eyes on this the better. one of us has to be able to figure it out :)
[20:44] <robint_> I did notice in some of Stuart Lewis's comments that it seemed to work ok with 1.7.n but not 1.7.m
[20:44] <robint_> Might be worth looking to see what was changed in those minor revisions
[20:46] <tdonohue> ok. So, anything else that anyone wants to bring up around 1.8.0 in general?
[20:46] <hpottinger> I will add this to the ticket for 959, but, I googled "jsessionid tomcat 7 ie login problem" and came up with this: http://www.developer.com/java/web/article.php/3904871/Top-7-Features-in-Tomcat-7-The-New-and-the-Improved.htm
[20:46] <kompewter> [ Top 7 Features in Tomcat 7: The New and the Improved - Developer.com ] - http://www.developer.com/java/web/article.php/3904871/Top-7-Features-in-Tomcat-7-The-New-and-the-Improved.htm
[20:47] <hpottinger> "2. Changing the jsessionid on authentication to prevent session fixation attacks altogether"
[20:47] <robint_> Good spot
[20:48] <tdonohue> yea, seems like it could be related. I just hope there's an easy way to fix this in XMLUI (and it isn't a *Cocoon* issue)
[20:49] <robint_> tdonohue: I've nothing more to add re 1.8. Just getting suitably nervous about pressing the Maven button :)
[20:50] <tdonohue> robint_ : no worries... :) If anything goes wrong, I can work with you to frantically fix it at the very last moment on Friday (just kidding -- hopefully all should be smooth, to be honest)
[20:51] <tdonohue> robint_ : one question for you. Are you planning to try and do the demo.dspace.org update to 1.8.0RC1 on Friday? We just should finalize who is doing that upgrade -- likely either you or I
[20:52] <robint_> Don't mind. Hadn't given it any thought yet.
[20:52] <robint_> Happy either way
[20:52] <tdonohue> ok, I'll touch base with you via email on that. At the very least, I should set you up with access to demo.dspace.org so that you can tweak configs there if you need to.
[20:52] <robint_> Sounds good
[20:53] <tdonohue> BTW -- any committers who want command-line access to demo.dspace.org, just ask. It's meant to be jointly managed by the committer team. Currently I think only about 4-5 of us really manage it.
[20:54] <KevinVdV> I do have a small question about the setup of the demo, what will be done with the workflow ?
[20:55] <KevinVdV> Will the old one be enabled or the new (xmlworkflow)
[20:55] <tdonohue> KevinVdV : Usually we try and "enable" as many features as we possibly can on demo.dspace.org. In the case of the workflow, we'd probably want to enable to new one, so that it gets the proper testing during Testathon. But, if robint or I have trouble setting it up, we'll let you know
[20:56] <robint_> Does it need any config done or can we just turn it on ?
[20:56] <tdonohue> (this is also where we get to test everyone's docs -- if we don't have good docs, chances are we won't know how to enable each of the new features)
[20:56] <KevinVdV> Well it requires some config but also some database changes
[20:57] <KevinVdV> So if there is a shared database between the xmlui & jspui there may be issues
[20:57] <tdonohue> hmm... yea ,there is a shared DB between xmlui & jspui
[20:57] <snail> is there link to the SQL schema for 1.8 someplace? I've just had to make an update to my schema to 1.6.2 and I'm not sure whether it's been fixed in the latest version or whether I need to submit a fix/bug report
[20:58] * hpottinger is scribbling notes furiously
[20:58] <tdonohue> KevinVdV : are the DB changes in an upgrade script in [dspace-src]/dspace/etc/ yet? I don't see them there?
[20:59] <KevinVdV> Yes there should be scripts in both the oracle & postgres dir they are in a workflow subdir though
[20:59] <robint_> tdonohue: I've seen them. Ben added them.
[20:59] <KevinVdV> The directory is called xmlworkflow in the etc/postgres & etc/oracle dirs
[21:00] <tdonohue> oh, I see. I didn't expect them to be in an 'xmlworkflow' directory. I had assumed they would be in 'database-schema_17-18.sql'
[21:01] <KevinVdV> It is "optional" and xmlui only
[21:01] <aschweer> gotta go, bye everyone
[21:01] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:01] <tdonohue> ok, so, this is a bit "late in the game", but do I now understand that there are *2 different* DSpace Database schemas, based on whether you are using XML Workflow or not? I must've totally missed this fact.
[21:02] <KevinVdV> Yes
[21:02] <tdonohue> what happens if someone moves to the XML Workflow and (for whatever reason) wants to "undo that change"? Is that possible? Is this a one-way only upgrade?
[21:02] <mhwood> Is the schema just augmented, or does this change existing stuff?
[21:03] <KevinVdV> I'm afraid that at the moment it is a one way upgrade (might need to check to be 100% sure)
[21:04] <tdonohue> it looks like it is *not* just an augmentation. It looks like the workflow_migration.sql script actually removes the workflowitem entries (which would mean this cannot be undone)
[21:05] <KevinVdV> Although a going back option may be required for the DSpace 1.8.0 release
[21:06] <tdonohue> Since we are over time here, we may have to continue this discussion next week. I am a bit concerned that there is no way to "undo" the XML Workflow if this is an optional feature. If we wanted to make it *required*, then it wouldn't need an "undo" option.
[21:06] <tdonohue> But, in the meantime, what we can do is the following (1): Release it "as-is" in 1.8.0 RC1
[21:07] <tdonohue> (2) Continue this discussion in the coming weeks to figure out how we want it to be in 1.8.0 final
[21:07] <robint_> Bizzare as it sounds I know of a site that uses both the JSPUI and the XMLUI
[21:07] <hpottinger> I'd like to see a README in the xmlworkflow folder
[21:07] <tdonohue> (3) Enable it on one Testathon server and leave it disabled on another (to see both options during Testathon). We will have at least two testathon sites (demo.dspace.org, & hpottinger's Oracle Testathon site)
[21:08] <mhwood> Must go. Thanks, all.
[21:08] * mhwood (~mhwood@mhw.ulib.iupui.edu) has left #duraspace
[21:09] <tdonohue> +1 to hpottinger. I'd also agree with robint_ -- although extremely rare, I've heard of sites using both XMLUI & JSPUI -- but, usually XMLUI is for "access" and JSPUI is for Admin UI (at least when I've heard of it)
[21:09] <KevinVdV> Ok just be aware should you enable the xmlworkflow that this isn't compatible with JSPUI so shared db between User interfaces is a big no no I'm afraid
[21:09] <hpottinger> we used to use JSPUI and XMLUI (JSPUI was our admin interface)
[21:10] <tdonohue> KevinVdV. Ok, thanks for verifying that. We need a *big warning* about that. I'd hate it if someone accidentally ran these scripts and was still partially using JSPUI (and then couldn't "undo" it)
[21:11] <KevinVdV> Indeed I will talk it over with the guy in @mire who actually made the db script (not me)
[21:11] <KevinVdV> & see if we can get a rollback in
[21:11] <hpottinger> I've seen writeups where people referred to the JSPUI as an admin interface, can't remember where, though
[21:11] <robint_> Very sorry but I've got to run. Cheers all.
[21:12] <tdonohue> Ok, as we are over time, we may want to move this XML Workflow discussion to mailing lists (we can also set aside time next week as well, obviously!)
[21:12] * robint_ (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Quit: Page closed)
[21:12] <tdonohue> I'm going to call the meeting "closed". But, I'll be hanging around here for a while if anything comes up.
[21:18] <KevinVdV> tdonohue or anybody else interested in the configurable workflow we have already created some documentation & this can be found at the following location https://wiki.duraspace.org/display/DSDOCDEV/Configurable+Workflow
[21:18] <kompewter> [ Configurable Workflow - DSpace Unreleased Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOCDEV/Configurable+Workflow
[21:18] <hpottinger> Tim, it might help me get the Oracle testathon instance up, if I can just crib off of the setup of demo, so if you can get me command line access, that would be great, thanks!
[21:20] <tdonohue> hpottinger: makes sense. I'll send you & robint emails to get you access.
[21:21] <tdonohue> thanks KevinVdV
[21:22] <mdiggory> Oh, by the way folks... Lets all give a shout out to KevinVdV as our latest addition to the DSpace Committers Group. I'm working on an announcement to go out later today. But since there are a few of us left in the meeting... "Welcome Kevin"
[21:22] <tdonohue> yea, sorry about that, welcome to KevinVdV :) I'm not sure we ever even did the same for hpottinger (since he was out for a week or so after being voted in). So, welcome to both hpottinger & KevinVdV!
[21:24] <KevinVdV> Thanks all
[21:24] <PeterDietz_OSU> Hi KevinVdV, glad you've joined!
[21:25] <hpottinger> thanks, and welcome to KevinVdV (still looking for the liquor cabinet, but I *have* found the keys for IDEA)
[21:25] <KevinVdV> The keys for the IDEA will do for the moment
[21:25] <PeterDietz_OSU> ohh right, I think that means I can't close IDEA for a couple of days
[21:26] <hpottinger> erm, well, the old, just about expired keys, that is...
[21:26] <KevinVdV> *Hopes that hpottinger finds the liquor cabinet by OR 2012*
[21:27] <PeterDietz_OSU> Thats going to be near where Robin is, I'm guess that Robin will have the keys
[21:28] <mdiggory> Those Scotts have quite a liquor cabinet from what I hear
[21:28] <KevinVdV> Lots of scotch in it I heard
[21:29] * hpottinger realizes his cup is empty, wanders off...
[21:34] <KevinVdV> Got to run, need some sleep, should you require my aid about anything just email me
[21:34] * keithgilbertson (~keithgilb@63.164.30.58) has joined #duraspace
[21:35] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) Quit (Quit: KevinVdV)
[21:39] * keithgilbertson (~keithgilb@63.164.30.58) Quit (Client Quit)
[21:40] <mdiggory> PeterDietz_OSU: have you made any further progress on "business tier" shared code?
[21:42] <PeterDietz_OSU> mdiggory: I would love something like that, but I haven't been pushing in that direction lately. WebMVC GSOC wrapped up, so I suppose I could continue maintenance on the code. (I paused during GSOC so Robert could ignore my commits as well)
[21:43] <mdiggory> We've done an experimental rework of the way XMLUI loads so that Cocoon is just treated as a View by WebMVC It actually works very well
[21:43] <mdiggory> I rewrote the Cocoon "Servlet" (all 200 lines of code) to be a Spring WebMVC View
[21:44] <mdiggory> This means that one can execute a WebMVC controller then forward to cocoon for rendering the resulting presentation
[21:45] <PeterDietz_OSU> aha, thanks for the translation, (my head got stuck)
[21:45] <PeterDietz_OSU> forwarding to cocoon, means that we keep XSLT + XMLUI themes ?
[21:45] <mdiggory> In theory, it means that some of the cocoon flowscript stuff can be rewritten out of javascript.
[21:45] <mdiggory> right
[21:46] <PeterDietz_OSU> Where does the DRI doc get built? Normally thats an xmlui-api aspect pumping things into a doc
[21:47] <mdiggory> thats all the same still.
[21:47] <mdiggory> no change.
[21:48] <hpottinger> from the peanut gallery, I declare that this sounds awesome :-)
[21:48] <mdiggory> The work just rips a bunch of control away from the cocoon servlet and instead delegates it to Spring WebMVC....
[21:49] <mdiggory> THis is the "hardcoded" version.... https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/java/org/dspace/springmvc/CocoonForwardController.java
[21:49] <mdiggory> but we also rewrote it so the view is in the spring servlet xml file instead of hardcoded in a controller
[21:49] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/java/org/dspace/springmvc/ResourceIdentifierController.java
[21:50] * kdweeks_ (~kdweeks@2001:468:c80:a103:223:dfff:fefe:ac7d) has joined #duraspace
[21:50] * kdweeks_ (~kdweeks@2001:468:c80:a103:223:dfff:fefe:ac7d) has left #duraspace
[21:51] <mdiggory> This controller remaps "/resource" URI to resolve any identifier to a DSpace resource using our "IdentifierService" that allow multiple id services to be implemented (handle, doi, etc)
[21:51] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) has joined #duraspace
[21:51] <mdiggory> web.xml just uses Spring Servlet...
[21:51] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/webapp/WEB-INF/web.xml
[21:52] <mdiggory> and then the spring configuration blends the WebMVC and Cocoon beans together into one applicationContext.
[21:52] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/webapp/WEB-INF/spring-servlet.xml
[21:54] <mdiggory> So IMO, this approach applied in other webapps could standardize the web.xml for all webapplications in DSpace to use the Spring WebMVC controller.
[21:56] <mdiggory> So... PeterDietz_OSU one question about the DSpace webmvc stuff... I see alot of hardcoding of paths in files like this:
[21:56] <mdiggory> https://github.com/DSpace/webmvc/blob/master/freemarkerui-webapp/src/main/webapp/WEB-INF/dspace-servlet.xml
[21:56] <kompewter> [ freemarkerui-webapp/src/main/webapp/WEB-INF/dspace-servlet.xml at master from DSpace/webmvc - GitHub ] - https://github.com/DSpace/webmvc/blob/master/freemarkerui-webapp/src/main/webapp/WEB-INF/dspace-servlet.xml
[21:56] <mdiggory> any chance you guys can reduce this occurance?
[21:58] <PeterDietz_OSU> So that the mappings in dspace-servlet doesn't exist between URL and class/controller, but instead each controller is allowed to map itself based on annotations within that controller?
[21:59] <PeterDietz_OSU> I was going to add that I noticed that your web.xml had no servlet-mappings, other than to make spring do everything
[22:04] <tdonohue> :( DS-768 needs to wait for post-1.8.0 :( (just wish we could finally get this one "fixed")
[22:04] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[22:04] <mdiggory> Yep... We avoid "controlling" the controllers
[22:05] <mdiggory> This is an example of centralized configuration... which is bad for extensibility
[22:05] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:05] * hpottinger has to run to an appointment, will check on this discussion later tonight, very interesting stuff.
[22:05] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[22:06] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) Quit (Quit: Leaving.)
[22:08] <mdiggory> The goal is to allow controllers to be written that can do whatever they want to, then they can forward using the DefaultAnnotationHandlerMapping to any cocoon resources
[22:08] <mdiggory> the HttpServletRequest/Response is wrapped and passed onto Cocoon, Cocoon just sees the forwarded URI and doesn't realize everything was "mediated" by Spring
[22:09] <mdiggory> We set the Context and DSpaceObject into the HttpServletRequest, Cocoon just sees it like it looked it up itself
[22:12] <mdiggory> Other areas we are working on are to try to find a replacement for Continuations and swap out the Multipart File Upload functionality to come from Spring instead of Cocoon, which the later is buggy
[22:16] <mdiggory> So the take home is.... Anything we can do to make the basic logic executed from a Controller be encapsulated into individual classes that can be swapped out, the easier it will be to augment the behavior at these points. I'm not so sure I'd go as far as using Spring Controllers as Business Services, but that would be a curious idea too...
[22:17] <mdiggory> I'm unsure why all the Controllers are in the freemarkerui-webapp and not in the WebMVC project, are they really tied to Freemarker?
[22:18] <PeterDietz_OSU> Controllers don't need freemarker, and don't do anything specific for freemarker
[22:18] <mdiggory> oh wait... I'm wrong
[22:18] * PeterDietz_OSU sorry, gotta head home. I'll look into all of this.
[22:19] <mdiggory> kool, later
[22:19] <PeterDietz_OSU> controllers *are* in webmvc --- https://github.com/DSpace/webmvc/blob/master/webmvc-api/src/main/java/org/dspace/webmvc/controller/admin/CollectionController.java
[22:19] <kompewter> [ webmvc-api/src/main/java/org/dspace/webmvc/controller/admin/CollectionController.java at master from DSpace/webmvc - GitHub ] - https://github.com/DSpace/webmvc/blob/master/webmvc-api/src/main/java/org/dspace/webmvc/controller/admin/CollectionController.java
[22:19] <mdiggory> yep I corrected myself...
[22:19] <PeterDietz_OSU> The lady, and baby await me. Peace
[22:23] * bojans (~Bojmen@91-118-59-116.dynamic.adsl-line.inode.at) Quit (Remote host closed the connection)
[23:21] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.