Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* ermadmix leaves00:35
* ksclarke leaves00:45
* longshou joins01:03
* ermadmix joins01:08
* ermadmix leaves02:17
* longshou leaves02:46
* ermadmix joins03:18
* ermadmix leaves03:50
* ermadmix joins03:59
* ermadmix leaves04:31
* ermadmix joins04:41
* ermadmix leaves05:45
* ermadmix joins05:47
* ermadmix leaves06:20
* ermadmix joins
* ermadmix leaves06:53
* ermadmix joins06:54
* dwilcox joins07:51
* ermadmix leaves08:32
* ermadmix joins08:33
* ksclarke joins08:38
* escowles leaves08:52
* mikeAtUVa joins09:04
* ermadmix leaves09:05
* ermadmix joins09:06
* escowles joins09:17
<pivotal-bot>Kevin Clarke started "Tighten code styling" https://www.pivotaltracker.com/story/show/7064878409:28
Benjamin Pennell finished "Create XACML AuthZ Project" https://www.pivotaltracker.com/story/show/7068813409:38
* tecoripa joins09:39
<awoods>tecoripa: I think we have two options with (or maybe three): https://www.pivotaltracker.com/story/show/7058481809:50
<pivotal-bot>feature: Address "Critical" Sonar Issues (finished) / owner: Scott Prater
<awoods>tecoripa: 1 - change the sonar rule to reduce the "criticality" of the exceptions situation09:51
tecoripa: 2 - refactor the problem errors so that the "catch" statements are not used in a problematic way09:52
tecoripa: 3 - log the exceptions and their stack traces :(
<tecoripa>awoods: yeah, for most of them, given the way the exceptions were thrown and what that meant for the code, I opted for number 3 as the path of least resistance09:53
<awoods>tecoripa: yes09:54
<tecoripa>Number 1 may make sense, but then we lose tracking of places where application logic occurs in the catch block... and maybe even lose track of places where *nothing* occurs in the catch block
<awoods>tecoripa: I lean a bit towards #209:55
<tecoripa>I'd need to spend some time to see how to loosen the rule without discarding it entirely
<awoods>tecoripa: in terms of loosening the rule, we would just changes its status
tecoripa: blocker/critical/major/minor/info
<tecoripa>I did spend some time looking at each case in regards to number 2, as that also seemed preferable to me -- but in almost every case, an exception was thrown, something needed to happen to it so that it didn't disturb the app, but in the context of what the app was trying to do, it wasn't really an error.09:56
* cjcolvar joins
<tecoripa>in this case, I think it may be an issue of overuse of exceptions at a lower (modeshape?) layer
awoods: so you don't like the LOGGER.debug solution? I actually thought that was pretty okay, and in the spirit of both the rule and complete debug information, giving you a picture of what the app is actually up to under the hood.09:58
<awoods>tecoripa: the trouble with #3 is that we will need to set those logging statements to TRACE in order to not be flooded with false stacktraces.
<tecoripa>awoods: yeah, I thought about that... again, I think it's a symptom of overuse of exceptions down below. In which case, maybe the best option to preserve sanity is to live with it, and lower the priority of the rule.09:59
awoods: as you recommend
<awoods>tecoripa: maybe dropping the rule to "major"10:00
<tecoripa>awoods: or even minor?
* cjcolvar leaves10:01
* cjcolvar joins
<awoods>tecoripa: do you feel good/better about "minor"?
<benpennell>mikeAtUVa: I think i'm doing it wrong with onParentVersion, when I set that to "VERSION" on a versionable descendent (datastream) of a versionable object it doesn't actually make a new version of the descendent. That's the expected behavior isn't it?10:02
<tecoripa>awoods: well, if we're making an explicit decision that these are issues we aren't going to let bother us, I'm thinking addressing them later should be way down on the priority stack...10:03
I could see us wanting to address all critical and major Sonar issues, and analyzing minor cases on an individual basis, as time and desire permits
<awoods>tecoripa: done10:04
tecoripa: so maybe update your PR accordingly.10:05
<tecoripa>awoods: okay. would you like me to re-do the commit, remove some of the LOGGER.debug() statements (revert the commits, in effect)?
<pivotal-bot>Esme Cowles started "Federation: How many files can be managed?" https://www.pivotaltracker.com/story/show/70724572
<awoods>tecoripa: yes. You can just pull those changes out and add another commit to that same branch.10:06
<tecoripa>awoods: will do.
<awoods>tecoripa: sorry for the trouble.
<mikeAtUVa>benpennell: I don't think it makes a version of a VERSIONABLE descendant when you make a version of the parent, instead it links to the current version of the VERSIONABLE descendant. Or at least that's how I read: http://www.day.com/maven/jcr/2.0/3_Repository_Model.html#3.13.9%20Versionable%20State
<tecoripa>awoods: no problem. it's a learning experience :)
<awoods>mikeAtUVa/benpennell: To be clear, we use "full versioning", and children nodes may or may not have the mixin "versionable"10:11
mikeAtUVa/benpennell: It sounds like depending on if children nodes have mixin "versionable", the expected behavior is different.10:12
* cjcolvar leaves10:13
<mikeAtUVa>awoods: hence the problem with those hierarchy-building container nodes... they result in versions creating copies of the entire subgraph..
<awoods>mikeAtUVa: unless we set the children to mixin:versionable, no?10:14
<mikeAtUVa>awoods: or possibly change the onParentVersion to ignore them in versioning... though I'm not 100% sure how to do that and the implications of all of these things need to be documented.10:16
<awoods>mikeAtUVa: where is the "onParentVersion"?10:18
<benpennell>i've been assigning it to the descendents
<pivotal-bot>Andrew Woods rejected "Address "Critical" Sonar Issues" https://www.pivotaltracker.com/story/show/7058481810:19
<mikeAtUVa>awoods: isn't it the part of the CND (COPY is often the value we use for properties)?10:20
<awoods>mikeAtUVa/benpennell: yes, I was confused because "onParentVersion" read like a method.
benpennell: so getting back to the original question, is it still outstanding? or did the spec clarify?10:23
<benpennell>mikeAtUVa/awoods: well i think i was applying onParentVersion incorrectly, i didn't realize it was supposed to be part of the CND, had been thinking it was a property10:25
<mikeAtUVa>They use the term "attribute" in the spec... and other than the CND, I'm not sure how to set it, or even inspect it.10:26
<awoods>benpennell: it is a part of the nodetype definition, which can be changed problematically, or more easily in the CND.
programmatically10:27
<benpennell>okay, so would the best way to apply this be to make mixins for the two onParentVersions we care about and apply those to the descendents?
<awoods>benpennell: sounds reasonable. You are just trying to work out the mechanics of a test setup, no?10:29
<mikeAtUVa>benpennell: I might be wrong, but I think the "on parent version" attribute is in the parent's CND when it lists the possible children... I don't know whether our wildcard specifications in the CND interact with explicit ones.
<pivotal-bot>Scott Prater added comment: "After discussing it with @awoods, I reverted the commit that added debug-level logging to empty/incomplete ..." https://www.pivotaltracker.com/story/show/70584818
Scott Prater started "Address "Critical" Sonar Issues" https://www.pivotaltracker.com/story/show/70584818
<mikeAtUVa>benpennell: https://docs.jboss.org/author/display/MODE/Defining+custom+node+types
* longshou joins10:30
* gregjansen joins
<pivotal-bot>Scott Prater finished "Address "Critical" Sonar Issues" https://www.pivotaltracker.com/story/show/70584818
<tecoripa>awoods: ^^^^
<awoods>tecoripa: thanks10:31
<pivotal-bot>Scott Prater started "Property CRUD performance testing" https://www.pivotaltracker.com/story/show/70266946
* escowles leaves10:33
* scossu joins
<mikeAtUVa>benpennell, awoods: COPY is the default "on parent version" attribute and fedora:resource defines wildcard children without overriding it... so I think the only way we could have another "on parent version" attribute is if a) another mixin (or primary node type) defines children with a different "on parent version" and b) that specification takes precedence over our wildcard.10:34
* escowles joins10:35
<awoods>mikeAtUVa: sounds right, and I believe that (b) is true in that more specific definitions override wildcards (but that should be verified).10:36
<tecoripa>awoods: does the change you made to the Sonar rule priority take effect immediately? I'm still seeing the exceptions rule violations as critical.10:37
<awoods>tecoripa: Yes, I would expect the change to take effect on the next successful build.10:38
<benpennell>mikeAtUVa: okay, i think i'm slowly catching up. so to change the versioning behavior I should apply a mixin with http://fedora.info/definitions/v4/repository#onParentVersion=VERSION to the descendents
<awoods>benpennell: but the mixin is applied to the parent that defines its children, no?10:39
<mikeAtUVa>benpennell: I don't think it's a property... perhaps the easiest test would be to change the fedora;resource mixin to have the word "VERSION" after "(undefined)"10:40
benpennell; ie, make that change globally and verify that the behavior changes...10:41
benpennell: then when this testing reveals something, the other ticket can implement and document best practices (as well as the implications of these sorts of changes... which as you can see are not well-known)10:42
<benpennell>mikeAtUVa: the nodeTypes page lists http://fedora.info/definitions/v4/repository#onParentVersion as a property of http://www.jcp.org/jcr/nt/1.0childNodeDefinition and http://www.jcp.org/jcr/nt/1.0propertyDefinition but i don't really know how to read this stuff10:43
<pivotal-bot>Andrew Woods added "Remove javax.servlet artifact from F4.war - again" https://www.pivotaltracker.com/story/show/7085650610:44
Andrew Woods estimated "Remove javax.servlet artifact from F4.war - again" as 1 point https://www.pivotaltracker.com/story/show/70856506
Andrew Woods started "Remove javax.servlet artifact from F4.war - again" https://www.pivotaltracker.com/story/show/70856506
<tecoripa>ksclarke: have you successfully configured checkstyle with eclipse recently? I installed a new version of eclipse and set it up yesterday, and now it's throwing my formatting out-of-whack, despite setting it up and importing the Fedora formatting files as before.
<mikeAtUVa>benpennell: perhaps it is a property then, and the CND is just shorthand for setting it.
<tecoripa>ksclarke: was there anything I needed to do in eclipse to get it to use your modified maven checkstyle artifact? (I still have that)10:45
<benpennell>mikeAtUVa: I had been trying to set it as a jcr property rather than fedora though, which is probably why i wasn't seeing it doing anything
<ksclarke>tecoripa: you don't need my modified artifact anymore, those changes have been incorporated into checkstyle proper now10:46
5.7 checkstyle is in the latest eclipse-cs and maven-checkstyle-plugin
<mikeAtUVa>benpennell: I'm not expert on our translation of JCR properties to fedora properties...
<awoods>escowles: you may be interested in this: https://wiki.duraspace.org/display/FF/IU+Fedora+4+Alpha+4+Acceptance+Testing+-+Federated+Filesystem+with+Large+Files
<benpennell>mikeAtUVa: I'll try to change the global setting to see if that works. is there an easy way to do that from the html interface? I see the update CND form, but do you have to fully redefine the CND or can you just do partial updates?
<ksclarke>tecoripa: there are some inconsistencies between the eclipse defaults and fedora's checkstyle though10:47
<tecoripa>ksclarke: thanks. I'll make sure I have the latest versions, then, and review my settings.
<mikeAtUVa>benpennell; last time I tested (6 months ago) you could just post a single mixin and it would replace the existing one.
<tecoripa>ksclarke: were you able to address those inconsistencies?
<ksclarke>err, I mean between the fedora eclipse settings and the fedora checkstyle settings10:48
I've err'ed towards checkstyle preferences since the maven build uses them
<benpennell>mikeAtUVa is there a way to get the non-html CND definition out of the interface?10:49
<ksclarke>are you just using the fedora eclipse formatter config file or the eclipse defaults, tecoripa?
<tecoripa>ksclarke... you mean the eclipse settings that are here: https://github.com/futures/fcrepo4/tree/master/src/site/eclipse ?10:50
ksclarke: that's what I'm using
ksclarke: in Eclipse
<mikeAtUVa>benpennell: with CURL and accept headers I imagine... https://wiki.duraspace.org/display/FF/RESTful+HTTP+API+-+Node+Types
<ksclarke>tecoripa: at one point, I ingested the fedora eclipse settings (that you reference), then exported my settings (which included a bunch of additional ones from eclipse)... part of one of my tickets is to compare what's different between them10:51
<benpennell>mikeAtUVa: thanks! sorry for all the questions
<ksclarke>tecoripa: I'd be glad to send my exports if you're interested in looking at them
<gregjansen>anyone else commonly see Eclipse errors having to do with checkstyle? I am trying to understand this one:10:52
"unable to parse configuration stream - Property ${checkstyle.suppressions.file} has not been set"
<tecoripa>ksclarke: yes, please. that would be useful. I ended up going all escowles on development yesterday, and doing my development in vi, so as not to check in a bunch of formatting changes.10:53
<awoods>intellij?
<ksclarke>gregjansen: you have to use the latest versions... the older version didn't support reading the suppressions file from the fcrepo-build-tools jar
(is my guess)
<gregjansen>okay, I will see if I can upgrade my checkstyle plugin.. thanks andrew, that solution is more mentally taxing for me..10:54
<ksclarke>tecoripa: there are still some inconsistencies (which need to be removed, one is an eclipse bug) which has caused me to drop down into a simple text editor, but I'll send them along10:55
<benpennell>awoods/mikeAtUVa: it doesn't seem like there is a text/cnd output for fcr:nodetypes even though that is the format you have to supply when doing updates?
<tecoripa>ksclarke: okay, thanks. do those inconsistencies cause your build to fail (so that at least you can catch them and fix them in a text editor) before you do your commits?10:56
<ksclarke>tecoripa: yes10:57
<awoods>benpennell: if that is a question, the answer is "yes"
<mikeAtUVa>benpennell: that's inconvenient. You can see the CND at /fcrepo-kernel/src/main/resources/fedora-node-types.cnd.10:58
<benpennell>awoods: okay, seems like you'd want to be able to get the same format out as you send in
thanks mikeAtUVa
<gregjansen>see you guys in the PM..11:11
<benpennell>be back later11:13
* gregjansen leaves11:16
<tecoripa>awoods: I have a lunch meeting from noon to one CST, which means I may be a few minutes late for the IIIF call11:22
<awoods>tecoripa: ok
<ksclarke>tecoripa: what's your email and I'll send those files
<tecoripa>ksclarke: just IM'd you11:23
<ksclarke>thanks11:24
<escowles>awoods: i see four issues in the IU filesystem federation page:
<awoods>tecoripa: Linux 2.6.18-348.12.1.el5xen x86_64
<escowles>1. copying files to federation slows down over time (this may just be the repo slowing down, which the transparent auto-hierarchy will address)
2. deleting files show up in list, but 404 when accessed (probably a ttl issue)11:25
3. local ops with NFS are much faster than to/from desktop (maybe just networks being slow, but seems like the most serious issue)11:26
<tecoripa>awoods: hmm, that looks like a redhat 5 machine.
<escowles>4. contentBasedSha1=true is slow/flaky (this is a known issue, but maybe should be stressed more in the wiki docs)
<tecoripa>awoods. I just happen to have one of those sitting two feet behind me. I'll checkout the jms indexer project there and try to build it.
<awoods>tecoripa: thanks11:27
escowles: re:1, the slowdown is minor (compared to what we have seen with larger tests), but likely the "many children" issue, yes.11:28
escowles: re:2, I am not sure our caching headers reflect the removal of children?
<escowles>awoods: that’s another possibility, but i know there is a configurable ttl, and filesystem changes won’t be seen until that expires — so they might be able to just decrease the ttl to get better results11:29
<awoods>escowles: re:3, I assume F4 is not running on his desktop. Is there anything that can be done with this issue?
escowles: re:4, yes yes yes11:30
<escowles>awoods: re:3 — i think the main thing to figure out is whether this is just the network speed difference11:31
because if the network between f4 and his desktop is slow, there’s nothing we can do
<awoods>escowles: thanks, I can have him explore the network i/o differences.11:32
* nikhiltri joins
<awoods>escowles: yes, federation ttl is available, default is "unclear", https://docs.jboss.org/author/display/MODE/File+system+connector11:33
<escowles>as part of repeating the december tests, i will see how pulling files out of the repo storage compares to pulling them out of federation — i remember them being pretty similar, but it would be good to be sure of that and diagnose any serious difference
the config provided on the page has a 5 sec ttl — that seems fast enough to address these issues, so maybe the caching headers are an issue11:34
<awoods>ksclarke: can you please add some description to the ticket: https://www.pivotaltracker.com/story/show/7064869411:36
<pivotal-bot>feature: Employ transparent auto-hierarchy for objects (unstarted) / owner: Longshou Situ
<awoods>ksclarke: I am not going to be available until 3pm at the earliest.
ksclarke: and it would be good to not hold up longshou.
<ksclarke>I can give some context for it; I also haven't enabled it (which was longshou's main question I think) so not sure I'll be much help there11:37
i.e., I have an understanding of what it does but not how to turn it on11:38
<longshou>Thanks, Kevin.11:41
* escowles leaves11:42
<tecoripa>ksclarke: got your eclipse configs, thanks. These are your current canonical configs, correct, after your modifications to get them more like checkstyle?11:44
<ksclarke>yes
<tecoripa>ksclarke: great, thank you. I'll take a look at them.
<ksclarke>let me know if you have any problems :-)
<tecoripa>@woods: what is the error that the build host is reporting for the jms-indexer?11:45
awoods: ^^^11:46
<awoods>tecoripa: http://ci.fcrepo.org/jenkins/view/FF/job/fcrepo-jms-indexer-pluggable/483/console11:47
tecoripa: looks like a header issue too
<tecoripa>awoods: okay. I got an error -- but much earlier in the process -- a SELinux relocation error. I'll fix that, and try again.11:48
awoods: it's building with java 1.7.0_55, correct?
<awoods>tecoripa: yes11:49
<tecoripa>awoods: ok. I'll continue poking at it.
<ksclarke>okay, bug report for maven-javadoc-plugin file... I'm going to grab a quick sandwich longshou then will fill out that ticket some11:52
* github-ff joins11:53
[fcrepo4] cbeer force-pushed refactor-fixity from 5095b93 to 0bfb112: http://git.io/TbjnLg
fcrepo4/refactor-fixity 6ac15ed Chris Beer: Remove the LowLevelStorageService and supporting classes
fcrepo4/refactor-fixity afc4e59 Chris Beer: Refactor CacheEntry classes to wrap a jcr property, whereever it is...
fcrepo4/refactor-fixity cffa66a Chris Beer: remove unused test imports
* github-ff leaves
<awoods>ksclarke/longshou: see:11:56
https://github.com/futures/fcrepo4/blob/master/fcrepo-webapp/src/main/resources/spring/rest.xml#L27
https://github.com/futures/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/api/rdf/HttpIdentifierTranslator.java#L308
https://github.com/futures/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/api/rdf/SpringContextAwareIdentifierTranslator.java#L34
https://github.com/futures/fcrepo4/blob/master/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/identifiers/ExternalIdentifierConverter.java#L41
* nikhiltri leaves12:00
<tecoripa>awoods: success, of a sort: I'm able to reproduce the jms-indexer error on my RHEL5 host.12:02
awoods: I see two issues: one is the missing license errors it's reporting
* scossu leaves12:03
<tecoripa>and the other, probably the more crucial error, are three failed IndexerGroupIT tests
<awoods>on a call12:05
<pivotal-bot>Scott Prater added comment: "@awoods: I'm able to reproduce the error on my RHEL5 host. I'll look into it." https://www.pivotaltracker.com/story/show/7067342612:07
Scott Prater edited "Fix fcrepo-jms-indexer-pluggable tests" https://www.pivotaltracker.com/story/show/7067342612:08
Scott Prater started "Fix fcrepo-jms-indexer-pluggable tests" https://www.pivotaltracker.com/story/show/70673426
* escowles joins12:12
* travis-ci joins12:19
[travis-ci] futures/fcrepo4#1928 (refactor-fixity - 0bfb112 : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/5095b93367e5...0bfb11239632
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/24637524
* travis-ci leaves
<pivotal-bot>Kevin Clarke added comment: "The auto-hierarchy for objects allows users to ingest objects without having to think about creating a hier..." https://www.pivotaltracker.com/story/show/7064869412:21
* scossu joins12:33
<longshou>Kevin: That’s helpful, Thank you very much for the background info. So now in https://www.pivotaltracker.com/story/show/70648694 we want the end user to aware of the backend storage path and expose it in the resource url?12:35
<pivotal-bot>feature: Employ transparent auto-hierarchy for objects (unstarted) / owner: Longshou Situ
<tecoripa>@ksclarke: I imported your files, they look good12:42
@ksclarke: but I have a problem that whenever I click "Save", the entire file is reformatted, not just my lines
ksclarke: this is despite my configuration setting to only format edited lines12:43
<ksclarke>yes, I see that problem too
<tecoripa>ksclarke: I'm wondering if this is an issue with checkstyle?
ksclarke: what checkstyle config is your default in eclipse? sun checks or sun checks (eclipse)?12:44
(not that I know what the difference between the two is)
ksclarke: mine is sun checks
<ksclarke>you might try removing Preferences > Java > Code Style > cleanup 's "format source code"12:46
not sure why that exists in addition to Preferences > Java > Editor > Content Assist > Save Actions12:47
seems like duplication between those two activities in what they do12:48
I've also wondered about whether checkstyle's plugin was an actor, like you
I think sun checks was my default as well
I haven't narrowed down what the problem yet is either though12:50
* escowles leaves12:51
<tecoripa>ksclarke: well, at least we know we're in this together. Thanks, I'll try removing the "format source code", and I'll poke around some more.12:53
<ksclarke>tecoripa: or it could even be any of those Content Assist > Save Actions... might be worth trying empting that config, reloading, and seeing what that does
tecoripa ... would be very nice to get these working though so there wouldn't have to be any thought about it at all :-)12:54
<tecoripa>ksclarke: ok, I'll also give that a try, as a second step. off to lunch right now, though
ttyl
ksclarke: I entirely agree. It's a headache, but if we can figure out... our descendants will thank us.12:55
<ksclarke>see ya
* nikhiltri joins12:59
Hey all, I'm looking for a code snippet that sends a JMS message, is there a place in the codebase you going direct me to?13:01
* ermadmix leaves13:02
* ermadmix joins13:08
* gregjansen joins13:33
<awoods>nikhiltri: I assume you have looked at: https://github.com/futures/fcrepo4/blob/master/fcrepo-jms/src/main/java/org/fcrepo/jms/observer/JMSTopicPublisher.java13:34
* ermadmix leaves13:39
<nikhiltri>awoods: That's what I had found, just checking I was going in the right direction. Thanks!13:41
* ermadmix joins13:43
* dwilcox leaves13:45
* dwilcox joins
<pivotal-bot>Andrew Woods edited "Employ transparent auto-hierarchy for objects" https://www.pivotaltracker.com/story/show/7064869413:46
* dwilcox leaves13:51
* dwilcox joins14:00
<awoods>tecoripa/dwilcox: https://plus.google.com/hangouts/_/event/c1glu6soq43r1rr6ou17qtobug814:01
* gregjansen leaves14:02
* scossu leaves14:05
* dwilcox leaves14:09
* dwilcox joins14:12
<benpennell>there seems to be a velocity error in the rest html interface when you try to visit a jcr:frozenNode
other formats are okay14:13
* gregjansen joins14:25
* scossu joins14:31
<awoods>ksclarke/tecoripa/mikeAtUVa: thanks14:52
<tecoripa>ksclarke: did you update mvn checkstyle rules to check for 2014 date in the copyright statement?14:53
awoods: sure, np
<ksclarke>tecoripa: I didn't
<tecoripa>ksclarke: or was that escowles?
<mikeAtUVa>tecoripa: there's a license plugin that does it.
tecoripa: and yeah, it was updated and merged into master.
<tecoripa>mikeAtUVa: I'm guessing this was updated recently, i.e., in the past day or so, as part of the license cleanup?14:54
mikeAtUVa: ah, that explains it.
<awoods>tecoripa: ksclarke was just kidding: https://github.com/futures/fcrepo-jms-indexer-pluggable/commit/d7c3197c14db97ff1ed6246ee112429d79e9bb7e
<tecoripa>mikeAtUVa, awoods: "It" being the "missing license" failure in the fcrepo-jms-indexer-pluggable project.14:55
awoods: that ksclarke: he's a funny guy
<ksclarke>is there a check in checkstyle for that date though?
<awoods>tecoripa: checkstyle and license rules are in the same bundle
https://github.com/futures/fcrepo-build-tools14:56
* mikeAtUVa knows nothing about fcrepo-jms-indexer-pluggable... except that he downloaded it today and couldn't find the error.
awoods: with a caveat that the license rules insert a property value for the date that is in the main project's pom.xml14:57
<tecoripa>mikeAtUVa: and you didn't get a missing license error?
<ksclarke>I did update jms-indexer to use the latest checkstyle but didn't touch the rules with respect to checking that date
<gregjansen>okay, how do I include said bundle in a pom that is outside of the core project?
<tecoripa>gregjansen: looks like fcrepo-jms-indexer-pluggable has it14:58
<awoods>tecoripa/ksclarke: I believe this is what happened: we updated the indexer checkstyle plugin, indexer built fine, then we updated the license part of the fcrepo-build-tools bundle, then the indexer broke.
<gregjansen>Okay, I will look there. I have the parent set to the main project
<ksclarke>awoods: that makes sense
<awoods>gregjansen: you should be fine
mikeAtUVa: could you quickly do your magic to update the years in the indexer source files?14:59
<tecoripa>awoods: yeah, that seems correct to me. esp. given what mikeAtUVa said, concerning the property that is set in the main project pom
<gregjansen>aha, okay, my problem is that this property is not set: ${checkstyle.suppressions.file}15:00
<mikeAtUVa>sure... you type "mvn license:format" to update all the licenses.
or "mvn license:check" to see which are wrong.
<awoods>mikeAtUVa: ok, I can do that ;)
<gregjansen>that placeholder above is in our checkstyle.xml file (in fcrepo-build-tools)
<tecoripa>awoods: I'll continue working on the other indexer problem... appears to be a jms communication issue on RHEL515:02
awoods: which means it real be really fun to try and figure out.
it will be really fun
<awoods>gregjansen: you will want to include this plugin: https://github.com/futures/fcrepo-jms-indexer-pluggable/blob/master/pom.xml#L319
tecoripa: you know that's true
<pivotal-bot>Scott Prater added comment: "@awoods: the "Missing License" error is fixed by changing the license copyright date to 2014." https://www.pivotaltracker.com/story/show/7067342615:03
* ermadmix leaves15:04
<pivotal-bot>Andrew Woods added "Update fcrepo-indexer-jms-pluggable license header" https://www.pivotaltracker.com/story/show/7088500615:05
Andrew Woods started "Update fcrepo-indexer-jms-pluggable license header" https://www.pivotaltracker.com/story/show/70885006
<gregjansen>thanks awoods, trying that now.. I probably can just use the plugin ref and not all that plugin management stuff right (given that I'm using the main project as a parent..)
or maybe I need it actually..15:06
<awoods>gregjansen: you may need it
gregjansen: although, it would be nice to be proven incorrect.15:07
* ermadmix joins15:08
<gregjansen>even all together they didn't fix it.. just now selected a eclipse checkstyle plugin option to "configure from blueprint.." and pointed it at the fcrepo project.. that worked.
* github-ff joins15:33
[fcrepo-jms-indexer-pluggable] awoods pushed 1 new commit to master: http://git.io/iPYP0g
fcrepo-jms-indexer-pluggable/master 5c6ced8 Andrew Woods: Add javax.servlet-api dependency...
* github-ff leaves
* github-ff joins15:38
[fcrepo-jms-indexer-pluggable] awoods pushed 1 new commit to master: http://git.io/BrskoA
fcrepo-jms-indexer-pluggable/master 46c89cb Andrew Woods: Update license header date...
* github-ff leaves
<pivotal-bot>Andrew Woods added comment: "Resolved with: https://github.com/futures/fcrepo-jms-indexer-pluggable/commit/46c89cb62e4f231c408f9543ba00f..." https://www.pivotaltracker.com/story/show/7088500615:39
Andrew Woods delivered "Update fcrepo-indexer-jms-pluggable license header" https://www.pivotaltracker.com/story/show/70885006
<awoods>tecoripa: the licenses have been updated.
<tecoripa>awoods: thanks. I'll pull now.15:40
* github-ff joins15:48
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/4lHpSA
fcrepo4/master a2b4ba4 Andrew Woods: Exclude servlet-api dependency...
* github-ff leaves
<pivotal-bot>Andrew Woods added comment: "Resolved with: https://github.com/futures/fcrepo4/commit/a2b4ba4e906c0d330d35d45077c3105f7e29e1d8" https://www.pivotaltracker.com/story/show/7085650615:49
Andrew Woods delivered "Remove javax.servlet artifact from F4.war - again" https://www.pivotaltracker.com/story/show/70856506
* travis-ci joins15:54
[travis-ci] futures/fcrepo-jms-indexer-pluggable#114 (master - 46c89cb : Andrew Woods): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo-jms-indexer-pluggable/compare/5c6ced8a79c4...46c89cb62e4f
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo-jms-indexer-pluggable/builds/24654890
* travis-ci leaves
* escowles joins15:55
* github-ff joins16:01
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/2G3_Sw
fcrepo4/master fb7e86c Scott Prater: Address Sonar critical warnings...
* github-ff leaves
<pivotal-bot>Andrew Woods added comment: "Resolved with: https://github.com/futures/fcrepo4/commit/fb7e86c792346e0b8cf5e8641d432872c870ea8e" https://www.pivotaltracker.com/story/show/70584818
Andrew Woods delivered "Address "Critical" Sonar Issues" https://www.pivotaltracker.com/story/show/7058481816:02
* github-ff joins
[fcrepo4] awoods closed pull request #346: Fcrepo 70584818 (master...fcrepo-70584818) http://git.io/lm-unQ
* github-ff leaves
* scossu leaves16:06
<pivotal-bot>Mike Durbin started "Getting lock metadata multiple times in a session throws exception." https://www.pivotaltracker.com/story/show/7059766616:09
* travis-ci joins
[travis-ci] futures/fcrepo4#1929 (master - a2b4ba4 : Andrew Woods): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/f2057e10a067...a2b4ba4e906c
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/24655685
* travis-ci leaves
<pivotal-bot>Mike Durbin added comment: "It turns out the code was right and the test was bad all along. As I've documented in the latest update t..." https://www.pivotaltracker.com/story/show/7059766616:11
Mike Durbin finished "Getting lock metadata multiple times in a session throws exception." https://www.pivotaltracker.com/story/show/70597666
* edInCo joins16:19
* travis-ci joins16:21
[travis-ci] futures/fcrepo4#1930 (master - fb7e86c : Scott Prater): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/a2b4ba4e906c...fb7e86c79234
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/24656449
* travis-ci leaves
<gregjansen>discovery in authz.. looks like the JBOSS PDP is relatively thin wrapper around the Sun PDP. Directly using the Sun classes makes a lot more sense. The JBoss stuff was mostly about their own specific configuration approach. The resulting code is much simpler.16:22
* dwilcox leaves16:28
<pivotal-bot>Andrew Woods added comment: "Although this appears to have been already merged, see code review comments." https://www.pivotaltracker.com/story/show/7068813416:33
Andrew Woods rejected "Create XACML AuthZ Project" https://www.pivotaltracker.com/story/show/70688134
* travis-ci joins16:34
[travis-ci] futures/fcrepo-module-auth-xacml#1 (master - c15a5e7 : Andrew Woods): The build has errored.
[travis-ci] Change view : https://github.com/futures/fcrepo-module-auth-xacml/compare/e628ebc21b94...c15a5e7da9f8
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo-module-auth-xacml/builds/24657997
* travis-ci leaves
<pivotal-bot>Andrew Woods added comment: "https://travis-ci.org/futures/fcrepo-module-auth-xacml/builds/24657997" https://www.pivotaltracker.com/story/show/7068813416:37
<tecoripa>escowles: have you done substantial work on the jms indexer?16:39
<awoods>tecoripa: escowles is on it like you would not believe.16:41
<tecoripa>awoods: think you can channel him?16:42
<escowles>tecoripa: you rang?
* awoods channeling
<tecoripa>awoods: wow, that's spooky... bu thank you
escowles: I'm looking at the jms indexer build problem16:43
it appears to manifest itself consistently on RHEL5
<escowles>tecoripa: what version of java is it using?16:44
<tecoripa>escowles: I've narrowed it down to a problem with the test repo, I think, not delivering messages
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) Server VM (build 24.45-b08, mixed mode)
<awoods>mikeAtUVa: could you rebase on master: https://github.com/futures/fcrepo4/pull/341
<mikeAtUVa>awoods: is that what happend? I was just looking into it...
<awoods>mikeAtUVa: did something happen?16:45
mikeAtUVa: there are just some conflicts in your interim commits.
<mikeAtUVa>Travis failed.
<escowles>tecoripa: i'm not sure what would prevent the messages from being received -- the ITs have sleep loops in them, if you increase those, do the messages ever arrive?
<tecoripa>escowles: the TestIndexer sits there, waiting for an update for the node, but gets nothing, and eventually times out.16:46
escowles: I doubled the timeout in the test... same thing happens
escowles: my next step was to turn on debug logging in fcrepo.jms, see if I get more info16:47
escowles: I suspect something needs to be configured on rhel5 for activemq to be happy, but that's a shot in the dark
<awoods>mikeAtUVa: are you on RedHat?
<tecoripa>escowles: here's what I see:
DEBUG 15:28:49.740 (TestIndexer) Checked whether we received an update for: http://localhost:8080/a1/b2, false16:48
DEBUG 15:28:49.740 (IndexerGroupIT) Waiting for next notification from TestIndexer...
<mikeAtUVa>awoods: Nope... fedora... maybe close enough.
<tecoripa>escowles: repeat until timeout.
escowles: am I correct in iterpreting that as waiting for an update message from the repo?
<escowles>tecoripa: yes, it's doing an update and then waiting for the message to make its way through the machinery and trigger the indexing in IndexerGroup16:49
tecoripa: i just setup configurable logging in fcrepo4, so you should be able to set system properties to increase the fcrepo4 logging side of things now
<tecoripa>escowles: so it appears either the message isn't getting sent, or being dropped.
escowles: so would a logical next stpe be to set up a really long wait time, and then get into the repo and see if 1) the update actually happened, as a first troubleshooting step?16:50
<escowles>tecoripa: yes, the first thing i'd look at is if the update is being made, and then if the event is being generated in the repo16:51
<tecoripa>escowles: that would help. is there an sl4j lo properties file somewhere I can edit?
<escowles>tecoripa: the system properties you can set to update logging are here: https://wiki.duraspace.org/display/FF/Configuring+Logging+With+System+Properties
that will affect the repo, not the indexer, but i think that's where the problem probably is
<tecoripa>escowles: fantastic, thanks. Let me try that, and see what I find.
<pivotal-bot>Longshou Situ estimated "Employ transparent auto-hierarchy for objects" as 1 point https://www.pivotaltracker.com/story/show/7064869416:57
Longshou Situ started "Employ transparent auto-hierarchy for objects" https://www.pivotaltracker.com/story/show/70648694
Longshou Situ estimated "Replace POST auto-hierarchy" as 2 points https://www.pivotaltracker.com/story/show/7064866616:58
* mikeAtUVa leaves17:02
* scossu joins
<awoods>mikeAtUVa: if you have not already started, you could alternatively just update the one actually file in a new PR: FedoraLocksIT.java17:05
<ksclarke>heh, awoods++ # response on iiif list ;-)
<awoods>ksclarke: I could not resist... but the response was actually only to you.17:06
<ksclarke>yeah saw that :-)
* scossu leaves17:09
* escowles leaves17:14
<pivotal-bot>Gregory Jansen started "Create a XACML AuthZ delegate and finder module stubs" https://www.pivotaltracker.com/story/show/7068886817:23
Andrew Woods added comment: "I am still getting undesired behavior: ""17:27
- Create a fedora object
- Create a child fedora datastream (ds)
- M..." https://www.pivotaltracker.com/story/show/70475058
Andrew Woods rejected "Improve and simplify fcr:versions response triples." https://www.pivotaltracker.com/story/show/70475058
* gregjansen leaves
<pivotal-bot>Andrew Woods added comment: "Rebase on master, please... or rather, just create a new PR with the single file update: FedoraLocksIT.java" https://www.pivotaltracker.com/story/show/7059766617:30
Andrew Woods rejected "Getting lock metadata multiple times in a session throws exception." https://www.pivotaltracker.com/story/show/70597666
Andrew Woods accepted "Address "Critical" Sonar Issues" https://www.pivotaltracker.com/story/show/70584818
<tecoripa>escowles: it looks like the tests begin to fail when we create the third and subsequent test objects17:31
<pivotal-bot>Andrew Woods accepted "Remove javax.servlet artifact from F4.war - again" https://www.pivotaltracker.com/story/show/70856506
Andrew Woods accepted "Update fcrepo-indexer-jms-pluggable license header" https://www.pivotaltracker.com/story/show/70885006
<tecoripa>escowles: I get back a 201, that the object have been created
escowles: but I never get back the JMS message confirming the creation
* ermadmix leaves17:39
<tecoripa>awoods,escowles: as you suspected, escowles, it's a timeout issue17:40
* ermadmix joins
<awoods>tecoripa: a timeout in the test? or the message broker?17:41
<tecoripa>in the test17:42
awoods: wait, I may have spoke too soon17:44
* scossu joins
* awoods waiting
<tecoripa>awoods: I'm seeing the problem again, even with the ridiculosuly long timeouts.17:45
awoods: the jms broker seems to flake out after a certain number of transactions
awoods: but it's not consistent. once out of every three or four tests, it will finish successfully.17:46
<awoods>tecoripa: that is very odd. I wonder if there is a redhat bug.
* nikhiltri leaves17:47
<tecoripa>awoods: or simply an issue of antiquated libraries. RHEL6 is long in the tooth, state of the art circa 2010... imagine RHEL5
awoods: I was so happy when they gave me a RHEL6 machine a few years ago... doing work on RHEL5 became almost impossible.
awoods: it does seem to be a JMS issue. when I query Fedora for the test object, I get it back immediately.17:49
<awoods>tecoripa: ideally (for a few reasons), it might be nice to have a different jenkins/sonar host.17:51
<tecoripa>awoods: yes, esp. as I'm not sure how worthwhile it is to debufg this issue if it's a low-level RHEL5 problem.
<awoods>tecoripa: I am good with you punting for now.17:52
tecoripa: you have found the issue... and the answer is likely to get on a modern CI server.17:53
tecoripa: do you have a modern CI server?
<tecoripa>awoods: I'm heading home in a few minutes. Let me run it through one or two more times, seem if bumping the timeout makes the odds better for success... if it does, I'll commit the change and submit a pull request. at the very least, it may fix the build problem temporarily.
I may have one at home. :)17:54
awoods: can we use AWS as a CI server?
<awoods>tecoripa: yes, but free is better.
<pivotal-bot>Longshou Situ added comment: "Okay, I am able to build the fcrepo4 with the HierarchyConverter configured for the fcrepo webapp after fi..." https://www.pivotaltracker.com/story/show/70648694
<tecoripa>awoods: yep, even with the long timeout, no response via JMS back from Fedora.17:57
<awoods>tecoripa: that is too bad17:58
tecoripa: you are quick on the email draw
* github-ff joins
[fcrepo4] lsitu opened pull request #349: Apply auto-hierarchy with the HierarchyConverter for objects, and fixed (master...feature/auto_hierarchy) http://git.io/aUC4Uw
* github-ff leaves
<tecoripa>awoods: sometimes I am... especially when packing up for the night. I don't know which phone I'll be carrying, though
<awoods>I am out for the next few hours17:59
tecoripa: you can decide on the phone on Saturday.
<tecoripa>awoods: tomorrow I'll see about hitching a ride from the airport with one of the other developers
<awoods>me too
* scossu leaves
<tecoripa>awoods: okay, tomorrow more. goodnight
* tecoripa leaves18:04
<pivotal-bot>Longshou Situ added comment: "@awoods What do you see when you run the following command, and what you expect to see: ""18:07
curl -H "Accept: t..." https://www.pivotaltracker.com/story/show/70475058
* tecoripa joins18:29
awoods: okay, something screwy is going on... because later tests do get messages from the broker. It's only that one test class that fails.
awoods: now I really am going home.18:30
* tecoripa leaves
* ermadmix leaves18:37
* ermadmix joins18:38
<pivotal-bot>Longshou Situ finished "Employ transparent auto-hierarchy for objects" https://www.pivotaltracker.com/story/show/7064869418:59
Longshou Situ started "Replace POST auto-hierarchy" https://www.pivotaltracker.com/story/show/70648666
* ermadmix leaves19:10
<pivotal-bot>Longshou Situ added comment: "https://github.com/futures/fcrepo4/pull/349" https://www.pivotaltracker.com/story/show/7064869419:13
* ksclarke leaves19:21
* edInCo leaves19:31
* ermadmix joins19:35
<pivotal-bot>Longshou Situ added comment: "@awoods I got two fcr:hasVersion links and one link for fcr:hasContent when I run the command above. Do yo..." https://www.pivotaltracker.com/story/show/7047505819:53
Longshou Situ estimated "Replace POST auto-hierarchy" as 0 points https://www.pivotaltracker.com/story/show/7064866620:18
* ermadmix leaves20:41
<pivotal-bot>Andrew Woods added "Clean-up HTML view of fcr:versions" https://www.pivotaltracker.com/story/show/7091066820:45
Andrew Woods added comment: "@longshous, feel free to capture the HTML portion of this work in this ticket: #70910668." https://www.pivotaltracker.com/story/show/7047505820:46
Andrew Woods edited "Clean-up HTML view of fcr:versions" https://www.pivotaltracker.com/story/show/70910668
Andrew Woods edited "Clean-up HTML view of fcr:versions" https://www.pivotaltracker.com/story/show/70910668
* ermadmix joins21:03
<pivotal-bot>Longshou Situ added comment: "@awoods Sure. Please let me know if anything need to be improved for this ticket so that I can work on it...." https://www.pivotaltracker.com/story/show/7047505821:28
* ermadmix leaves21:35
* ermadmix joins21:36
* ksclarke joins21:40
* ermadmix leaves22:08
* ermadmix joins22:30
* ermadmix leaves23:02
* ermadmix joins23:03
* ermadmix leaves23:35
* ermadmix joins23:39
* ermadmix leaves00:11
* ermadmix joins00:20
* ermadmix leaves00:52
* ermadmix joins01:10
* ksclarke leaves01:16
* ermadmix leaves01:44
* ermadmix joins02:06
* ermadmix leaves02:38
* ermadmix joins03:24
* ermadmix leaves03:56
* longshou leaves03:58

Generated by Sualtam