Timestamps are in GMT/BST.
[0:14] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
[4:33] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) Quit (Remote host closed the connection)
[4:33] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[4:33] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Changing host)
[4:33] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[5:25] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) Quit (Ping timeout: 260 seconds)
[6:44] -gibson.freenode.net- *** Looking up your hostname...
[6:44] -gibson.freenode.net- *** Checking Ident
[6:44] -gibson.freenode.net- *** Found your hostname
[6:44] -gibson.freenode.net- *** No Ident response
[6:44] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:44] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:44] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:24] * bigbrovar (~quassel@83.229.6.19) has joined #duraspace
[10:34] * royopa (bd2e7739@gateway/web/freenode/ip.189.46.119.57) has joined #duraspace
[11:11] * bigbrovar (~quassel@83.229.6.19) Quit (Ping timeout: 258 seconds)
[11:12] * bigbrovar (~quassel@41.220.68.31.vgccl.net) has joined #duraspace
[11:14] * royopa (bd2e7739@gateway/web/freenode/ip.189.46.119.57) Quit (Quit: Page closed)
[12:10] * bigbrovar (~quassel@41.220.68.31.vgccl.net) Quit (Ping timeout: 276 seconds)
[12:52] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:20] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
[13:24] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Quit: Leaving)
[13:25] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:53] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) Quit (Quit: Please, sir, I want some more.)
[13:53] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[13:53] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Changing host)
[13:53] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[14:49] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[16:17] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[16:17] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[16:33] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[18:37] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[19:00] * pbecker (~rooms@2001:6f8:900:8f1c:584f:8682:9b5e:bb42) has joined #duraspace
[19:06] <pbecker> Where is the kompewter?
[19:21] * pbecker (~rooms@2001:6f8:900:8f1c:584f:8682:9b5e:bb42) Quit (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
[19:25] * pbecker (~rooms@port-92-206-113-210.dynamic.qsc.de) has joined #duraspace
[19:29] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[19:31] * hpottinger waves affably at ksclarke
[19:32] * ksclarke waves back
[19:36] * pbecker (~rooms@port-92-206-113-210.dynamic.qsc.de) Quit (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
[19:38] * pbecker (~rooms@2001:6f8:900:8f1c:584f:8682:9b5e:bb42) has joined #duraspace
[19:55] <tdonohue> Reminder: our DSpace Devel Mtg starts in about 5 mins: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-04-03
[19:55] <kompewter> [ DevMtg 2013-04-03 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-04-03
[20:01] <tdonohue> Hello all. It's time for our weekly DSpace Developers Mtg. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-04-03
[20:01] <kompewter> [ DevMtg 2013-04-03 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-04-03
[20:02] <tdonohue> Hmm..noticing we don't seem to have too many Committers here right now, but hopefully others will pop in soon. Otherwise, we may not be able to hit too much of the main agenda items
[20:03] <hpottinger> odd
[20:03] <pbecker> If so, we could start perhaps with a smaller issue? Im here DS-1469 but not sure if I can stay till the end...
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1469 ] - [#DS-1469] Repository name with the accent (dspace.cfg with UTF-8 encoding show incorrect) - DuraSpace JIRA
[20:04] <tdonohue> pbecker. Sure, we can start there...as mentioned, our usually attendees not here yet..so we'll take a little diversion for DS-1469
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1469 ] - [#DS-1469] Repository name with the accent (dspace.cfg with UTF-8 encoding show incorrect) - DuraSpace JIRA
[20:05] <tdonohue> This was an issue I had highlighted in the agenda as possibly warranting a 3.2 bug-fix-only release. Essentially it sounds like there may be a few things to try and fix with 'build.properties' before 4.0 next fall/winter
[20:06] <tdonohue> Did you have any specific updates on this ticket, pbecker? I notice you've been involved with it
[20:06] <pbecker> As I already wrote in a comment to the ticket, I think we should split it into to tickets.
[20:06] <pbecker> One problem is in DSpace directly, the other one is with the filtering in maven.
[20:06] <tdonohue> makes sense to me. it does sound like two separate issues (and thanks for the pull request for one of those -- we'll have to get that reviewed quickly)
[20:07] <pbecker> I think I fixed the problem within DSpace (see the pull request, mentioned in the comments to the ticket).
[20:07] <tdonohue> And, if I'm understanding, the Maven filtering issue doesn't have a solution/resolution yet? Or at least no one has figured it out?
[20:07] <pbecker> The pull request should be quite easy to review. DSpace does not read some files with the correct encoding (UTF-8).
[20:08] <pbecker> The problem with maven is that it reads the build.properties as if it were ISO-latin1 encoded.
[20:08] <pbecker> As far as I know, there is no fix for the maven problem yet.
[20:10] <tdonohue> At a glance the pull request looks reasonable to me (haven't tested it though, but it seems logical by looking at it)
[20:10] <hpottinger> so, if we make 1469 the ticket for the problem fixed by pull 199, where dspace.cfg is read correctly, that deals with part of the problem, and then make a new ticket for the issue with build.properties filtering
[20:10] <tdonohue> that's a shame that there doesn't seem to be a Maven filtering fix yet.
[20:11] <tdonohue> hpottinger -- yea, that seems reasonable. Split out the Maven filtering part into a separate ticket
[20:11] <pbecker> perhaps we should make a small example and ask at maven project for help?
[20:11] <pbecker> if we fix the problem within DSpace, we would have a work around at least.
[20:12] <hpottinger> I like closing existing tickets, and leaving new tickets open
[20:13] <tdonohue> I noticed that Steve Swinsburg mentioned that the 'maven-resources-plugin' has an encoding setting (in the comments of Ds-1469). It sounds like that hasn't worked based on helix84's tests. We may want to do a few more tests of that setting, and if necessary we can report a bug to the 'maven-resources-plugin'
[20:13] <pbecker> I tried it also, it didn't helped.
[20:14] <pbecker> But I do not know maven and pom files very well.
[20:14] <tdonohue> hmm..it's possible there's a bug in the maven-resources-plugin then..or we haven't figured out the correct setting. According to the docs for "maven-resources-plugin", it is supposed to support UTF-8: http://maven.apache.org/plugins/maven-resources-plugin/faq.html#What_encoding_values_are_allowed
[20:14] <kompewter> [ Maven Resources plugin - Frequently Asked Questions ] - http://maven.apache.org/plugins/maven-resources-plugin/faq.html#What_encoding_values_are_allowed
[20:16] <tdonohue> yea, I don't know the answer to the Maven Resources issues, but I'd be willing to look into it a bit...
[20:16] <pbecker> great. :-)
[20:16] * robint (522a6b02@gateway/web/freenode/ip.82.42.107.2) has joined #duraspace
[20:16] <robint> hi all
[20:16] <tdonohue> hi robint :) It's a small group today, but glad you can join us
[20:17] <hpottinger> I do think splitting 1469 is a good idea, no reason to hold up a partial fix
[20:17] * hpottinger waves to robint.
[20:18] <tdonohue> hpottinger - I agree completely. We should associate Ds-1469 with just the fix in pull 199, and open a new ticket for the 'maven-resource-plugin' stuff
[20:19] <tdonohue> I'd be willing to open the new ticket for the maven-resource-plugin stuff (and even try a few tests myself)...if someone else will handle pull #199 and Ds-1469
[20:20] <robint> I'll take it
[20:20] <tdonohue> thanks robint!
[20:21] <tdonohue> should mention, at a glance pull #199 looks reasonable to me...I just haven't tested it out (but I'm assuming pbecker has, of course)
[20:21] <robint> assigned to me
[20:21] <robint> ok thanks
[20:21] <pbecker> I did of course. ;-)
[20:21] <tdonohue> I figured you did..thanks for verifying though :)
[20:22] <tdonohue> Ok. I'll open a new ticket for the maven-resources-plugin encoding issues after this meeting (and link it to Ds-1469)
[20:23] <tdonohue> thanks for all your help on this pbecker..much appreciated. Hopefully we'll find a way to fix the Maven part (or report a bug back to the Maven project team)
[20:24] <pbecker> I'll have to thank helix, you and robint when the pull request get merged...
[20:24] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:24] <pbecker> hi helix
[20:25] <helix84> hello everyone
[20:25] <robint> I confess thge build.properties stuff hasn't been the success I had hoped for
[20:25] <tdonohue> and there's helix84 :)
[20:25] <robint> hi helix84
[20:25] <tdonohue> robint -- I think the build.properties stuff has still been a worthwhile change...it's just not as "smooth" as it could be quite yet
[20:25] <robint> I like your thinking!
[20:26] <pbecker> I really like the build.properties stuff.
[20:26] <pbecker> It makes it easy to setup a little test instance.
[20:26] <robint> Oh well, that is good to hear pbecker
[20:26] <hpottinger> I *love* the .properties changes, one of the main reasons I'm pushing for an upgrade to 3.x for my repository
[20:27] <hpottinger> it makes setting things up so much more straightforward: checkout, copy one file, done
[20:27] <tdonohue> I like the *.properties stuff too. It's only been frustrating around this UTF-8 stuff, and when you stumble on a config that you *wish* was in build.properties
[20:27] <robint> build.properties is feeling the love
[20:27] <hpottinger> :-)
[20:28] <tdonohue> btw -- I likely will have a few small tweaks to suggest in nearish future around things to *add* to build.properties, based on my work with DSpace 3.1 for our new DSpaceDirect service
[20:28] <tdonohue> (it's minor stuff..nothing super exciting, just stuff that I wish was in that build file)
[20:29] <tdonohue> in any case...bringing us back to agenda (at least a bit back)..
[20:29] <tdonohue> we're a smallish group still today...but, I did want to float the idea of a possible 3.2 bug-fix-only release
[20:30] <hpottinger> I'm OK with a 3.2 for the changes you mention in the agenda, tdonohue
[20:30] <tdonohue> namely to possibly fix these build.properties issues (Ds-1469, future ticket on encoding issues, DS-1525?)
[20:30] <kompewter> [ https://jira.duraspace.org/browse/DS-1525 ] - [#DS-1525] build.properties not interpolated properly when building with Maven 3 - DuraSpace JIRA
[20:30] <helix84> does anyone remember the reason why it's not allowed to just filter *any* configuration property from build.properties and have the rest fall back? I remember it was a design limitation but I don't know the exact reason.
[20:31] <tdonohue> helix84...technically you can add anything you want to build.properties...you just need to replace the "default value" in dspace.cfg with ${propname}... that way it gets filled out by build.properties
[20:32] <tdonohue> the design limitation is that "${propname}" value needs to be in dspace.cfg (or whatever other config -- it also works for the configs under /config/modules/)
[20:32] <pbecker> But what for would we then need a dspace.cfg in the source directory?
[20:32] <tdonohue> not sure if that makes sense?
[20:32] <helix84> yes, and then by putting everything to build.properties we'd effectively have another dspace.cfg
[20:33] <robint> helix84: yes, it only makes sense if it remains a smallish subset
[20:33] <pbecker> What I like on build.properties it that it shows me the few properties I really have to change, whenever I set up a new DSpace instance to test something...
[20:33] <tdonohue> helix84 -- yea, exactly. You don't want *everything* in build.properties...you just want to main fields there
[20:33] <helix84> but what I'm asking is - is there a way to have a default value for a property if it's not in build.properties? (there is a common problem that breaks the build if you comment out any property from build.properties)
[20:34] <tdonohue> helix84 : unfortunately I think that's a design limitation of build.properties
[20:34] <hpottinger> default is build.properties, use someotherfile.properties to override
[20:34] <tdonohue> the only other way I could think of having a "default value" that is not in build.properties is to actually hardcode some default values in the Maven pom.xml itself
[20:35] <pbecker> helix: what is the reason to comment a properties out? you can always overwritte it in dspace.cfg...
[20:35] <helix84> pbecker: if you comment it out by accident instead of leaving it empty, it breaks the build and it can be quite hard to figure out if you don't know about it
[20:35] <helix84> I remember the messages don't point to build.properties
[20:36] <pbecker> okay
[20:37] <hpottinger> it's a bit of a trap, since the comments for dspace.cfg (ported over the build.properties) suggest (or at least used to suggest) that you comment out a setting if you didn't need to use it
[20:38] <tdonohue> yea, I think these are just limitations with the current build.properties design. I agree it'd be nice to also be able to comment out fields in build.properties...but, not sure how easy that would truly be to implement.
[20:38] <helix84> I'm still hoping Joao will come up with something completely new (working title - dynamic configurations). the idea is that all you would need at DSpace startup amounts to approximately what's now in build.properties
[20:39] <tdonohue> So, are there other tickets out there we should consider for a 3.2 release?
[20:39] <pbecker> could ds-1459 be something for 3.2?
[20:39] <kompewter> [ https://jira.duraspace.org/browse/ds-1459 ] - [#DS-1459] Testing of dissemination crosswalks - DuraSpace JIRA
[20:39] <helix84> oh, there are a few we pushed back that were scheduled for 3.1 but unresolved
[20:40] <tdonohue> helix84 -- yea, that'd be nice. We've talked about moving more configs to the Database (or similar) for a long time
[20:40] <helix84> tdonohue: I think the new UI will be dependent on it, so I really think we could have it for 4.0
[20:41] <tdonohue> pbecker: Ds-1459 looks like it's already been committed to the 3.x branch...so, yes, it'd be in the 3.2 release
[20:41] <tdonohue> (anything that gets committed to the 3.x branch would be released in 3.2)
[20:41] <helix84> ehm, i don't think it is
[20:41] <helix84> it's a new feature
[20:41] <helix84> even though it's minor
[20:42] <tdonohue> why is it listed as having been committed to 3.x branch then? https://jira.duraspace.org/browse/DS-1459?page=com.xiplink.jira.git.jira-git-plugin:git-commits-tabpanel
[20:42] <kompewter> [ https://jira.duraspace.org/browse/DS-1459 ] - [#DS-1459] Testing of dissemination crosswalks - DuraSpace JIRA
[20:43] <hpottinger> its closed and resolved
[20:43] <kompewter> [ [#DS-1459] Testing of dissemination crosswalks - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1459?page=com.xiplink.jira.git.jira-git-plugin:git-commits-tabpanel
[20:43] <pbecker> tdonohue: yes it is, did not notice it...
[20:43] <pbecker> it's part of 3.x branch, just checked it.
[20:44] <pbecker> you can although considering it as a bug fix. With the new OAI interface it was not possible to check dissemination crosswalks anymore. this is the fix for it
[20:45] <helix84> sorry, i'm trying to check just my jira connection seems very lazy today
[20:45] <robint> Was the original fix commited to both master and 3.1, but the later fix to just master?
[20:45] <pbecker> The pull request was for the master only.
[20:46] <pbecker> That's the reason why I asked if it could be something for 3.2
[20:46] <tdonohue> I see a total of 4 related commits -- two to master and two to dspace-3_x branch. So, it looks like it was merged into both.
[20:47] <tdonohue> in any case, we can probably figure this all out later. The reality is that currently Ds-1459 *is* on 3.x branch...so as-is, it would be released in 3.2, unless for some reason we decided to remove it from that 3.x branch.
[20:48] <helix84> I really don't remember why I commited it to 3_x. I didn't mention it in the Jira issue, so it might have been a mistake.
[20:50] <tdonohue> well, it's probably in a "grey-ish" area between improvement and bug fix. It may not hurt to release in a 3.2 anyhow
[20:50] <hpottinger> +1 release it anyhow
[20:50] <pbecker> I just saw, that it seems already to be in 3.1?
[20:50] <tdonohue> (especially since, as pbecker noted, this feature *used to exist*...it only stopped working in 3.0 with the new OAI-PMH interface)
[20:51] <pbecker> Sorry for bringing it up at all.
[20:51] <helix84> pbecker: not at all, thanks for the feature
[20:51] <pbecker> https://github.com/DSpace/DSpace/blob/dspace-3.1/dspace-api/src/main/java/org/dspace/content/crosswalk/XSLTDisseminationCrosswalk.java
[20:51] <hpottinger> no apologies necessary, it's a good idea to figure out what should be in a release :-)
[20:51] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/crosswalk/XSLTDisseminationCrosswalk.java at dspace-3.1 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/dspace-3.1/dspace-api/src/main/java/org/dspace/content/crosswalk/XSLTDisseminationCrosswalk.java
[20:51] <tdonohue> haha..yea, it is in 3.1. this is a moot point. no need to discuss future. I missed that was commited before 3.1 release :)
[20:52] <tdonohue> so, back to the original question -- anything else we should consider for a 3.2 release?
[20:52] <pbecker> okay, so I should fix the documentation for 3.x tomorrow (its just in the doumentation for 4.0)
[20:52] <robint> I'm afraid I'm a wee bit out of touch with recent issues
[20:52] <robint> pbecker: yes thanks
[20:53] <helix84> pbecker: do you have edit rights for the official docs?
[20:53] <pbecker> helix84: I think so
[20:53] <hpottinger> I'm curious if anyone knows more about the bit of code that was mentioned recently in dsapce_tech, that turns on byte-range requests?
[20:53] <pbecker> At least I was able to document it in the official 4.0 documentation.
[20:53] <tdonohue> yep, pbecker has official wiki docs rights -- I just verified.
[20:54] <pbecker> I'm sorry, I have to leave now (its almos 11 p.m. here).
[20:54] <tdonohue> thanks for joining us today, pbecker!
[20:54] <pbecker> bye everybody!
[20:54] <hpottinger> "bit of code" mentioned here: http://dspace.2283337.n4.nabble.com/Psuedo-video-streaming-with-item-attachment-and-seeking-enabled-td4662291.html
[20:54] <kompewter> [ DSpace - Tech - Psuedo video streaming with item attachment and seeking enabled ] - http://dspace.2283337.n4.nabble.com/Psuedo-video-streaming-with-item-attachment-and-seeking-enabled-td4662291.html
[20:54] <helix84> hpottinger: i was surprised it was needed. because by default, you can resume downloads from dspace. so it's not clear to me why streaming wouldn't work.
[20:54] * pbecker (~rooms@2001:6f8:900:8f1c:584f:8682:9b5e:bb42) has left #duraspace
[20:55] <hpottinger> helix84, I think it has to do with random seek
[20:55] <helix84> what's the difference between random seek and REST?
[20:55] <tdonohue> well, it sounds like kgilbertson has that "bit of code"...so maybe we ask him about it, as he's a committer
[20:56] <helix84> (sorry, REST is an FTP term, not HTTP)
[20:56] <hpottinger> it's actually code already in DSpae, just commented out
[20:56] <hpottinger> like the c in DSpace I just typed :-)
[20:57] <tdonohue> where is this commented out code in DSpace then?
[20:57] <hpottinger> "Just uncomment partial download code in org.dspace.app.xmlui.cocoon.BitstreamReader under generate(). It's disabled because some browser integrated PDF readers crash (says documentation code)."
[20:58] <helix84> ah, yes, the good old ambiguous finger pointing
[20:58] <tdonohue> I was noticing the part from kgilbertson saying: "You have to uncomment some code in BitstreamReader, and then fix a couple of bugs in it to get things working. "
[20:59] <tdonohue> Here's that "commented out code": https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/BitstreamReader.java#L578
[20:59] <kompewter> [ DSpace/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/BitstreamReader.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/BitstreamReader.java#L578
[20:59] <hpottinger> don't want to sidetrack meeting, just wondering if anyone knows more about the commented code
[21:01] <tdonohue> GitHub blame says the "commented out code" was initially written by Scott Phillips back in 2007 (when XMLUI was created). It was commented out in 2010 by Graham Triggs as part of DS-707 (he said it was a "malicious code vulnerability")
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-707 ] - [#DS-707] Fix/improve DSpace through static code inspections - DuraSpace JIRA
[21:01] <tdonohue> that's all I know about it :)
[21:02] <robint> Sorry, I've got to head off. Cheers all!
[21:02] * robint (522a6b02@gateway/web/freenode/ip.82.42.107.2) Quit (Quit: Page closed)
[21:03] <hpottinger> aha, good ol' Blame, I'll ask graham about it
[21:03] <tdonohue> yea, I think we're done here anyhow. Our attendance is rather small today... I do want to start planning 4.0 & seeing who is willing to be on the release team. But, we can leave that for next week, I guess
[21:03] <helix84> I justed tested resuming an interrupted download. It restarts from the beginning.
[21:05] <helix84> I have a question I was hoping someone could answer
[21:06] <tdonohue> yea, I still wonder if there's more too this.... as kgilbertson specifically mentioned needing to "fix a few bugs" in the commented out code
[21:06] <tdonohue> go ahead, helix84...I'm around for a bit
[21:06] <helix84> I inherited a DSpace instance where I'm getting stacktraces of errors sent to the admin email. I'm wondering if this is just a configuration switch I don't know about or if it's custom code or a Tomcat feature.
[21:08] <hpottinger> tdonohue, I think there's more to it than just uncommenting some code, there's certainly a number of moving parts in the change set referenced here: https://github.com/DSpace/DSpace/commit/c64399459fe088521176a4faec19420e61b5738f (sorry for interrupting, helix84)
[21:08] <kompewter> [ [DS-707] Malicious code vulnerabilities · c643994 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/commit/c64399459fe088521176a4faec19420e61b5738f
[21:09] <tdonohue> helix84 : so, you don't want stacktraces sent to the admin email. Or you need help in fixing the stacktraces? Not sure I understand your end goal?
[21:10] <helix84> tdonohue: I like the feature and I'd like to use it on my other instances as well :) But I don't know how to turn it on.
[21:10] <tdonohue> oh, there's a dspace.cfg setting for that I think (IIRC).. It's one of the email settings
[21:11] <tdonohue> I think it's this: https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L117 But, I could be wrong
[21:11] <kompewter> [ DSpace/dspace/config/dspace.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L117
[21:12] <helix84> Right, that must be it, thanks. I must have overlooked it.
[21:13] <hpottinger> I have missed that as well… looks handy
[21:14] <helix84> On second look, I have that set on my other instance but I have never received such an email from there. And there are errors in the log.
[21:16] <helix84> I get it now, it works only for dspace-jspui and dspace-api, not dspace-xmlui
[21:16] <hpottinger> pooh…. a potential valuable contribution to DSpace :-)
[21:17] <helix84> and I haven't been getting those on the XMLUI instances
[21:17] * hpottinger eyes autocorrect sternly
[21:17] <tdonohue> really, it only works for jspui & api?
[21:17] <helix84> that's what grep tells me
[21:18] <helix84> and anecdotal evidence
[21:18] <tdonohue> huh..that seems like it should be considered a bug then
[21:19] <helix84> basically, it's opt in - you have to send the error explicitly, it's not a feature of the logger
[21:19] <helix84> so it works only for a few specific errors
[21:20] <tdonohue> hm.. we may want to create a ticket around that. Seems like it *should* be either a feature of the logger or some sort of "listener" that emails when errors happen
[21:20] <hpottinger> I volunteer as a tester for the patch you're working on helix84
[21:20] <tdonohue> I'd like to see that patch too ;)
[21:20] <helix84> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/search/DSIndexer.java#L844
[21:20] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/search/DSIndexer.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/search/DSIndexer.java#L844
[21:20] <helix84> example usage
[21:21] <helix84> sorry guys, my java-fu is still weak
[21:21] <hpottinger> only one way to make it stronger
[21:22] <helix84> I made the first step - I installed Eclipse. I can't get to the second one - to run it.
[21:22] <hpottinger> I feel your pain, IntelliJ IDEA + Oracle was a big hurdle for me to jump
[21:24] <tdonohue> see...the problem is that you started with Eclipse (kidding ;)
[21:24] <helix84> what I was told by a person closely familiar with the matter, it's not all java applications that are a bother to develope because of looong edit-compile-run cycle, it's just DSpace
[21:25] <hpottinger> My wife is reminding me that I need to pick up the kids, I gotta run, but helix84, if you want to compare notes on this potential patch, let's move it to e-mail and keep talking
[21:26] <helix84> I suggest to make a Jira ticket instead, I don't have any cycles to devote to that at this time
[21:26] <tdonohue> I'd say definitely stick it in JIRA. You can still compare notes later if needed, but best get it logged first
[21:27] <hpottinger> helix84, if you can spare the time to do a brain dump of your research today and ideas for what needs to happen, I will take the ball and run with it
[21:28] <helix84> tdonohue: btw the reason I chose Eclipse instead of NetBeans/Idea is that Eclipse is recommended for Android development. And that would be a useful skill to have these days.
[21:28] <hpottinger> we have random error reports from repo managers, I've got 'em trained to give me the stack trace, but it would be helpful if I already have the trace
[21:29] <helix84> I'll file the ticket, I just don't think there will be anything there besides what you've just seen here. Don't let me keep you, Hardy.
[21:29] <tdonohue> yea. I'm just teasing you, helix84. I understand there are good reasons to use Eclipse. Someday maybe I'll try it again and see if I like it better. I just recall that about 3-5 years ago the majority of DSpace Committers all used Eclipse. Now, almost no one does.
[21:31] <hpottinger> OK, make the ticket, I've got a local ticket for the work in our own ticket system, I'll link them and will try to get some cycles for it
[21:31] <hpottinger> gotta run, bye!
[21:31] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:43] <helix84> https://jira.duraspace.org/browse/DS-1529
[21:43] <kompewter> [ [#DS-1529] make alert.recipient generally usable - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1529
[21:43] <kompewter> [ https://jira.duraspace.org/browse/DS-1529 ] - [#DS-1529] make alert.recipient generally usable - DuraSpace JIRA
[21:43] <helix84> bye
[21:43] <kompewter> see ya!
[21:43] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[21:52] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:49] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.