Timestamps are in GMT/BST.
[6:28] -zelazny.freenode.net- *** Looking up your hostname...
[6:28] -zelazny.freenode.net- *** Checking Ident
[6:28] -zelazny.freenode.net- *** Found your hostname
[6:28] -zelazny.freenode.net- *** No Ident response
[6:29] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:29] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:29] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:26] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[12:13] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:54] * cwilper (ad579d7c@gateway/web/freenode/ip.173.87.157.124) has joined #duraspace
[12:54] * elschlomo (2e05a4bb@gateway/web/freenode/ip.46.5.164.187) has joined #duraspace
[12:58] * Dan_Davis (4a4f9413@gateway/web/freenode/ip.74.79.148.19) has joined #duraspace
[13:06] * EdAtTheAlliance (811398fe@gateway/web/freenode/ip.129.19.152.254) has joined #duraspace
[13:14] <Dan_Davis> Its good they are not having to debug with OSGI too. :-)
[13:14] * ajs6f (893607f8@gateway/web/freenode/ip.137.54.7.248) has joined #duraspace
[13:17] * barmintor (~barmintor@cpe-72-229-190-215.nyc.res.rr.com) has joined #duraspace
[13:21] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[13:21] <Dan_Davis> If Chris is lonely, he needs a desktop docking station for Mo.
[13:23] <Dan_Davis> Chris: Status on notes for rescoping 1.6 to open up additional code improvements.
[13:24] <Dan_Davis> Frank: Problem with shutdown and embedded OIA provider.
[13:25] <Dan_Davis> Status on update of rework policy enforcement Springification, CXF integration.
[13:26] <Dan_Davis> It looks like CXF is in good shape now. Main problems are in FeSL test suite.
[13:26] <Dan_Davis> Chris: Now has issues.
[13:27] <Dan_Davis> Chris: After a fresh build - with Axis.
[13:27] <barmintor> git clean -df
[13:27] <cwilper> nice tip
[13:28] <elschlomo> check this: http://maven.apache.org/maven-1.x/plugins/eclipse/faq.html#generated-sources
[13:28] <kompewter> [ Maven Eclipse Plugin - FAQs ] - http://maven.apache.org/maven-1.x/plugins/eclipse/faq.html#generated-sources
[13:28] <Dan_Davis> Adam: May need to remove Axis machinery.
[13:31] <Dan_Davis> Ben: Do we need the Jersey library at all with CXF change.
[13:31] <elschlomo> this for maven2 and m2e plugin: http://stackoverflow.com/questions/6691723/m2e-generated-code-with-exec-maven-plugin
[13:31] <kompewter> [ java - m2e: Generated code with exec-maven-plugin - Stack Overflow ] - http://stackoverflow.com/questions/6691723/m2e-generated-code-with-exec-maven-plugin
[13:32] <Dan_Davis> Chris: Just need the dependency Jax-RS.
[13:33] <Dan_Davis> Chris: I would be nice to perform the 3.5 tests on the 3.6 code base.
[13:34] <Dan_Davis> Ben: Can predict the likely fails - messages returned.
[13:35] <Dan_Davis> Adam: Testing for the exception names are not a good idiom in current practice.
[13:36] <Dan_Davis> Chris: Agree on what is necessary for 3.6 to go out the door.
[13:36] <ajs6f> https://jira.duraspace.org/browse/FCREPO-1067
[13:36] <kompewter> [ [#FCREPO-1067] Create fault codes for Fedora exceptions to be used in Web service error reporting - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-1067
[13:40] <Dan_Davis> Chris: Using Git-K graphical browser.
[13:42] <elschlomo> https://github.com/fcrepo/fcrepo/commit/8747984584c8d1f217e9d81c2428b6957e40cb77
[13:42] <kompewter> [ Merge branch 'master' of github.com:fcrepo/fcrepo · 8747984 · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/commit/8747984584c8d1f217e9d81c2428b6957e40cb77
[13:44] <elschlomo> scroll to the left here: https://github.com/fcrepo/fcrepo/network
[13:44] <kompewter> [ Network Graph · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/network
[13:46] <barmintor> https://jira.duraspace.org/browse/FCREPO-1067
[13:46] <kompewter> [ [#FCREPO-1067] Create fault codes for Fedora exceptions to be used in Web service error reporting - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-1067
[13:49] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[13:51] <barmintor> In the end, nothing changed. The bleak philosophy of git. So modern!
[13:52] <Dan_Davis> Multiple fumblings to find out the state of master regarding FCREPO-1067 that does not need to be repeated.
[13:53] <Dan_Davis> Adam: Will remove Chris' issues and then recreate them.
[13:53] <Dan_Davis> In order, to have a clearly identified branch.
[13:55] <Dan_Davis> Chris: I anyone using local solutions for checking fault codes.
[13:56] <Dan_Davis> Chris: Are there people who have used brittle techniques out of necessity.
[13:57] <barmintor> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/utilities/CXFUtility.java#L52
[13:57] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/utilities/CXFUtility.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/utilities/CXFUtility.java#L52
[13:58] <Dan_Davis> Adam: It may be some pain but it will be welcomed by users of SOAP interface.
[13:59] <Dan_Davis> Ben: All the faults come from one class.
[14:00] <Dan_Davis> Chris: Will put into 3.6 release.
[14:00] <Dan_Davis> Dan: Easter Egg
[14:01] <Dan_Davis> Chris: Ben has acheived satori through refactoring
[14:02] <Dan_Davis> Chris: FeSL check on in the Web layer -- best to move PEP down.
[14:03] <barmintor> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-installer/src/main/resources/config/spring/policy-enforcement.xml
[14:03] <kompewter> [ fcrepo/fcrepo-installer/src/main/resources/config/spring/policy-enforcement.xml at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-installer/src/main/resources/config/spring/policy-enforcement.xml
[14:05] <Dan_Davis> Chris: Make the enforcer a Spring bean and wired in.
[14:07] <barmintor> No yawning!
[14:07] <Dan_Davis> Ben: Best way is to have an auth module that does all the work that is wired in, but it may not be easiest.
[14:07] <ajs6f> FCREPO-1067 is replaced by:
[14:07] <ajs6f> https://jira.duraspace.org/browse/FCREPO-1079
[14:07] <kompewter> [ [#FCREPO-1079] Create fault codes for Fedora exceptions to be used in Web service error reporting - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-1079
[14:09] <Dan_Davis> Adam: Ben: Chris: We should get the FeSL history to judge approach.
[14:10] <Dan_Davis> Chris: Chi may have considered FeSL and implementation of the interceptor pattern.
[14:12] <Dan_Davis> Adam: Need to abstract out operation from its origin.
[14:16] <Dan_Davis> http://en.wikipedia.org/wiki/XACML
[14:16] <kompewter> [ XACML - Wikipedia, the free encyclopedia ] - http://en.wikipedia.org/wiki/XACML
[14:17] <barmintor> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/security/Authorization.java
[14:17] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/security/Authorization.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/security/Authorization.java
[14:17] <Dan_Davis> http://www.birds-eye.net/definition/p/pdp-policy_decision_point.shtml
[14:17] <kompewter> [ Define PDP- Policy Decision Point ] - http://www.birds-eye.net/definition/p/pdp-policy_decision_point.shtml
[14:24] <barmintor> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/security/PolicyEnforcementPoint.java#L347
[14:24] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/security/PolicyEnforcementPoint.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/security/PolicyEnforcementPoint.java#L347
[14:24] <barmintor> ^^ why the file policy doesn't get checked
[14:25] <Dan_Davis> Chris: Adam: We need to patch for 3.6 and consider the bigger architecture changes for later. Let Ben continue where he is going right now.
[14:25] <barmintor> Muahahahahahah!
[14:25] <Dan_Davis> Chris: Will stay on IRC for Office hours today.
[14:26] <ajs6f> Chris: How 'bout those tests?
[14:26] <barmintor> cwilper: did your tests run?
[14:26] <cwilper> negatory; same problem
[14:26] <barmintor> null pointers?
[14:26] <barmintor> or the axis thing?
[14:26] <cwilper> APIAStubWrapper.java:[573,100] package org.apache.axis.types does not exist
[14:27] <barmintor> what's the package?
[14:27] <cwilper> fcrepo-client/fcrepo-client-admin/stubwrappers/org/fcrepo/client
[14:27] <barmintor> is it generated?
[14:28] <ajs6f> Maybe we need to check the Maven pom and see if Jiri cleaned everything out of there...
[14:29] <cwilper> i did git clean -df && mvn clean install...yeah in any case, all refs to axis should be eventually nuked.
[14:29] <ajs6f> Chris- can you check the appropriate maven pom and see if the axis stuff is still there?
[14:29] * elschlomo (2e05a4bb@gateway/web/freenode/ip.46.5.164.187) Quit (Quit: Page closed)
[14:30] <ajs6f> If the Maven axis plugin is still defined, there might be default executions taking places.
[14:31] <barmintor> Chris, can you delete that stub wrappers directory?
[14:31] <ajs6f> For example, did that pluging execute during your build-- it should be in the maven output.
[14:31] <barmintor> if stub wrappers is ignored, it won't be removed by git-clean
[14:32] <ajs6f> Stupid flexible sophisticated versioning software!
[14:32] <barmintor> this suggests there's still some POM cleanup to be done, also
[14:33] <barmintor> yeah, stubwrappers is in .gitignore
[14:34] <cwilper> ok, deleted manually...re-doing a build. yes, some cleanup probably still needed regardless...i did a "git grep apache.axis" and got http://pastebin.com/X62HSemH
[14:34] <kompewter> [ > git grep -l apache.axis Result: fcrepo-client/fcrepo-client-admin/src/ma - Pastebin.com ] - http://pastebin.com/X62HSemH
[14:36] <cwilper> The only ref to 'axis' in any pom is axistools-maven-plugin, used for wsdl2java, which I assume we still need
[14:36] <Dan_Davis> Edited (badly) notes are posted.
[14:36] <barmintor> thanks, Dan!
[14:38] * ajs6f (893607f8@gateway/web/freenode/ip.137.54.7.248) Quit (Ping timeout: 245 seconds)
[14:43] * ajs6f (89369b89@gateway/web/freenode/ip.137.54.155.137) has joined #duraspace
[14:43] <ajs6f> Any luck, Ben and Chris?
[14:43] <cwilper> My mac's still chugging away...it will only be a matter of eons now..
[14:44] <Dan_Davis> Ah. The allies against Axis. (j.p.sousa music in the background)
[14:45] <ajs6f> https://secure.wikimedia.org/wikipedia/en/wiki/Axis_%26_Allies
[14:45] <kompewter> [ Axis & Allies - Wikipedia, the free encyclopedia ] - https://secure.wikimedia.org/wikipedia/en/wiki/Axis_%26_Allies
[14:45] <ajs6f> Big part of my youth.
[14:50] <barmintor> cwilper: but the compiling is working?
[14:51] <cwilper> yes, it's been compiling for a while. i think it's further than where it got before, based on how long i've been waiting for it to finish...
[14:54] <barmintor> All right!
[14:55] <cwilper> [INFO] BUILD SUCCESSFUL
[14:55] <barmintor> HAH!
[14:56] <barmintor> Ok, I need to hop off IRC for a train ride, but I'll be able to help figure out bamboo's problems in about an hour.
[14:56] <barmintor> Thanks for double checking, cwilper
[14:56] * barmintor (~barmintor@cpe-72-229-190-215.nyc.res.rr.com) Quit (Quit: barmintor)
[14:56] <cwilper> Cool...I'll get to configuring the test server now, to save server logs as artifacts. Will also make sure it clears the build directory before each build, then I'll run a manual build which will of course totally work without any unanticipated problems <grin>
[16:08] <ajs6f> Chris-- you there? Did the Bamboo build go through? {crosses fingers}
[16:14] <cwilper> ajs6f: I'm actually just back from lunch -- doing the bamboo stuff now, should know within an hour or so
[16:14] <ajs6f> Groovy. Good luck!
[16:30] * mdiggory_ (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[16:31] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) has joined #duraspace
[16:31] <barmintor> cwilper: So, two things from this morning's talk-
[16:32] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Ping timeout: 260 seconds)
[16:32] * mdiggory_ is now known as mdiggory
[16:32] <barmintor> 1) .gitignore needs to be updated
[16:32] <barmintor> 2) the bamboo build needs to incorporate a git clean step
[16:33] <cwilper> #2 is now handled by having the bamboo do a "fresh checkout" (which is actually a fairly cheap operation, even for the fcrepo repository) per build
[16:33] <barmintor> oh, okay
[16:33] <cwilper> what needs to be added to .gitignore?
[16:33] <barmintor> stubwrappers might be removed; nothing needs to be added
[16:35] <cwilper> yeah, so let's figure out the fate of stubwrappers. first off, do we know why it's not in a target/ directory to begin with? if it were there, the whole issue of its presence in .gitignore would be irrelevant.
[16:38] <cwilper> it seems like its current location is non-maven-like for some reason. and conformity is key.
[16:41] <barmintor> I don't really understand why it was where it was.
[16:42] <barmintor> just to backtrack, has there been a successful build on bamboo now?
[16:43] <ajs6f> My guess would be history: the Axis machinery is older than the Maven machinery.
[16:43] <cwilper> in ~10 mins we should know. https://bamboo.duraspace.org/browse/FCREPO-CORE-11
[16:43] <kompewter> [ Fedora - Core Test 11: Build Result Summary - DuraSpace Bamboo ] - https://bamboo.duraspace.org/browse/FCREPO-CORE-11
[16:43] <barmintor> cwilper: nvm, I see that it's running
[16:46] * cwilper is trying to determine how stubwrappers came to be where it is
[16:48] <barmintor> design goal: minimize or eliminate the use of Server.getInstance(File fedoraHome) in favor of actual DI
[16:48] <ajs6f> +.5
[16:49] <barmintor> which half?
[16:49] <cwilper> +.4999
[16:49] <ajs6f> What about using OSGi service registry instead of pure DI?
[16:50] <barmintor> anything that gets us away from that janky static map of file objects to servers, that really only ever has one entry in it
[16:50] <ajs6f> Still possble to use DI (i.e. Spring/Blueprint)
[16:50] <ajs6f> Yeah, that was the half I agree with 100%.
[16:50] <ajs6f> "janky"?
[16:50] <ajs6f> hinky < janky < hacky
[16:50] <barmintor> DI (Spring) is more readily available than OSGi in the current codebase, but I'm not religious
[16:51] <barmintor> and yes, I think that's the etymology
[16:51] <ajs6f> Oh, are we talking 3.6?
[16:51] <barmintor> I try to replace it whenever I come across it in code
[16:51] <barmintor> as long as I don't change the interfaces
[16:51] <ajs6f> I thought you were talking about large-scale changes-- now I understand-- you're "leaving the camp site cleaner than you found it".
[16:52] <cwilper> I'd say nix Server.getInstance in favor of actual DI where possible. I tend to think constructor injection is where it's at, particularly for required dependencies. I'm not sure where OSGi fits in exactly, but tend to tread cautiously when it comes to adding a dependency on a particular framework.
[16:52] <barmintor> yeah. but I like the large-scale goals.
[16:52] <ajs6f> No, I wouldn't suggest adding OSGi to the mix.
[16:52] <ajs6f> I misunderstood what Ben was saying.
[16:53] <ajs6f> And if you like, don't think OSGi, think service registry.
[16:53] <ajs6f> http://martinfowler.com/articles/injection.html
[16:53] <kompewter> [ Inversion of Control Containers and the Dependency Injection pattern ] - http://martinfowler.com/articles/injection.html
[16:53] <barmintor> bamboo's interface is confusing me right now
[16:53] <ajs6f> SOmetimes a service registry is the Right Thing.
[16:54] <cwilper> ajs6f: gotcha. Maybe someday Server can go away altogether too. I'd be much happier with either a beanfactory or service registry.
[16:55] <ajs6f> Yeah, that's where I'm going with this.
[16:55] <ajs6f> OSGi just happens to do a nivce one along with a lot of other stuff.
[16:56] <barmintor> I think this means that these three tests are failing in one configuration?
[16:56] <ajs6f> Ben, can you put a link to the Bamboo here?
[16:57] <barmintor> https://bamboo.duraspace.org/browse/FCREPO-CORE-11
[16:57] <kompewter> [ Fedora - Core Test 11: Build Result Summary - DuraSpace Bamboo ] - https://bamboo.duraspace.org/browse/FCREPO-CORE-11
[16:57] <ajs6f> Thnx
[16:57] <cwilper> Yeah Bamboo's summary is confusing because it assume you have one set of test results that don't overlap in name. But we have several configurations, across which we run many of the same tests...
[16:57] <ajs6f> Aren't those the tests we knew would fail?
[16:58] <barmintor> they are the ones that failed with NPEs last night
[16:58] <ajs6f> The ones that relate to the changes in exception types.
[16:58] <barmintor> and are now reporting as both fixed and failing
[16:58] <barmintor> Oh, no
[16:58] <barmintor> Those tests are fixed
[16:58] <ajs6f> Gah?
[16:58] <cwilper> For the "raw" tests results (un-bamboo-ified), see https://bamboo.duraspace.org/browse/FCREPO-CORE-11/artifact/JOB1/Failsafe-reports/fcrepo-integrationtest
[16:58] <kompewter> [ fcrepo-integrationtest ] - https://bamboo.duraspace.org/browse/FCREPO-CORE-11/artifact/JOB1/Failsafe-reports/fcrepo-integrationtest
[16:59] <barmintor> I changed them to check for the message instead of the exception name
[16:59] <barmintor> ok, if Q didnt run they must have failed in C
[16:59] <ajs6f> Well, one is a NullPOinter, one is a failed assert
[16:59] <ajs6f> and one is
[16:59] <ajs6f> javax.xml.ws.soap.SOAPFaultException: java.lang.RuntimeException: XML datastreams must be of type Managed or Inline Caused by: Uncaught exception from Fedora Server
[17:00] <ajs6f> Did you see those locally, B, or did you just see NPEs?
[17:00] <barmintor> All 4 configs pass locally
[17:01] <barmintor> the NPEs were on bamboo last night
[17:01] <ajs6f> Oh, okay. Wait, what?
[17:02] <cwilper> Confirmed, the failure was in configC. https://bamboo.duraspace.org/artifact/FCREPO-CORE/JOB1/build-11/Failsafe-reports/fcrepo-integrationtest/fcrepo-integrationtest-configC/target/failsafe-reports/fcrepo-integrationtest-core/org.fcrepo.test.api.TestAPIM.txt
[17:02] <barmintor> Yesterday, after all 4 test suites passed on my development machine, I pushed to master
[17:02] <barmintor> bamboo failed to run
[17:02] <barmintor> cwilper restarted bamboo, which then ran with 3 test failures
[17:02] <barmintor> those 3 failures were NPEs
[17:03] <ajs6f> Okay. I think I get it. So how do we "diff" your setup vs. Bamboo? Possibly more git-fu?
[17:04] <ajs6f> brb
[17:06] <barmintor> ok, for there to be a NPE there, there would have to never have been set DSControlGroup on a datastream object.
[17:07] * ajs6f_ (89360899@gateway/web/freenode/ip.137.54.8.153) has joined #duraspace
[17:07] <barmintor> not sure how I could not get that error on one of my two dev machines
[17:07] <ajs6f_> back
[17:08] <ajs6f_> Ben-- have you got a link to the test code?
[17:08] <barmintor> cwilper: you had a successful local build too, right?
[17:08] * ajs6f (89369b89@gateway/web/freenode/ip.137.54.155.137) Quit (Ping timeout: 245 seconds)
[17:08] <barmintor> ajs6f_: Which test? The failing test?
[17:09] <barmintor> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java
[17:09] <kompewter> [ fcrepo/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java
[17:09] <ajs6f_> Yeah, the one what vomits forth NPE unto the congregation.
[17:10] <ajs6f_> Love that object setup.
[17:10] <ajs6f_> Going to have to tease Ross about that.
[17:15] <ajs6f_> I don't think I've ever seen that exception bfore-- it's weird. Why couldn't an XML datastream be External, for example POLICY?
[17:15] <ajs6f_> Not a good message.
[17:16] <ajs6f_> Chris-- can we see the server-side side logs to know where it arose?
[17:16] <ajs6f_> Sorry, whence. Whence it arose.
[17:16] <barmintor> https://bamboo.duraspace.org/artifact/FCREPO-CORE/JOB1/build-11/Fedora-server-logs/fcrepo-integrationtest-configC/target/fcrepo-3.6-SNAPSHOT/server/logs/fedora.log
[17:16] <ajs6f_> thnx
[17:17] <ajs6f_> java.lang.RuntimeException: XML datastreams must be of type Managed or Inline at org.fcrepo.server.storage.types.XMLDatastreamProcessor.<init>(XMLDatastreamProcessor.java:103) [fcrepo-server-3.6-SNAPSHOT.jar:na] at org.fcrepo.server.management.DefaultManagement.modifyDatastreamByValue(DefaultManagement.java:864) [fcrepo-server-3.6-SNAPSHOT.jar:na]
[17:18] <barmintor> Yeah, for some reason DSControlGroup looks not to be set in config C for those three tests
[17:18] <barmintor> Which I'm baffled by
[17:18] <barmintor> afk for a few minutes
[17:18] * barmintor is now known as barmintor_afk
[17:19] <ajs6f_> That shouldn't be valid. What sequence of operations could produce it?>
[17:20] <ajs6f_> And wy only in Config C?
[17:24] <ajs6f_> Anyone know where demo:14 gets created in the test code? It's not directly in TestAPIM.java that I notice.
[17:25] <ajs6f_> Oh, https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/DemoObjectTestSetup.java
[17:25] <kompewter> [ fcrepo/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/DemoObjectTestSetup.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/DemoObjectTestSetup.java
[17:28] <cwilper> yea, i've had successful local builds, so why this is happening on bamboo is a mystery to me.
[17:30] <ajs6f_> None of the demo objects appear to have been touched in years, so I don't think Jiri did anything to them.
[17:37] * EdAtTheAlliance (811398fe@gateway/web/freenode/ip.129.19.152.254) Quit (Ping timeout: 245 seconds)
[17:39] <ajs6f_> Okay, so if I'm not nuts, then here:
[17:39] <ajs6f_> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java#L1272
[17:40] <kompewter> [ fcrepo/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java#L1272
[17:40] <ajs6f_> is where that DS is created, and it is clearly created as type 'X".
[17:40] <ajs6f_> So how the heck is it changing or losing that attribute...?
[17:40] <ajs6f_> And why not on Ben's machine/
[17:40] <ajs6f_> ?
[17:45] <cwilper> (and why *only* on the Bamboo machine...since the tests are passing fine on my machine now)
[17:50] <ajs6f_> Oh, criminy.
[17:50] <ajs6f_> Seriously?
[17:51] <ajs6f_> Chris-- any possibility that this is some kind of state ambiguity, like temp files not getting wiped? I know that sounds desperate, but...
[17:52] <ajs6f_> I just can't see how the datastream loses (or changes) its X/M/E/R kind.
[17:54] <cwilper> All I can think of is a threading issue...and that's grasping and straws. Yeah, it's a field that's either set or not...never un-set afaik.
[17:55] <ajs6f_> Well, it could throw that exception if it were set to something other than X/M:
[17:55] <ajs6f_> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/storage/types/XMLDatastreamProcessor.java#L93
[17:55] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/storage/types/XMLDatastreamProcessor.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/storage/types/XMLDatastreamProcessor.java#L93
[17:56] <ajs6f_> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/storage/types/XMLDatastreamProcessor.java#L142
[17:56] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/storage/types/XMLDatastreamProcessor.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/storage/types/XMLDatastreamProcessor.java#L142
[17:57] <ajs6f_> Actually, there's a bunch of places in there where it could get thrown, but they're all checking explicitly for X/M.
[17:58] <ajs6f_> Say, come to think of it, could it be that the default type is somehow set to something other than X or M?
[18:00] <ajs6f_> I mean the default type for DC or RELS
[18:01] <cwilper> I don't know....maybe we should just change the code to log what it thinks it is and commit it so bamboo tells us in ~30 minutes
[18:02] <cwilper> Cue infomercial refrain "There's gotta be a better way!". Unfortunately I don't know of one when the test server is the only thing that seems wonky for some reason.
[18:03] <cwilper> But I do feel compelled to track this down, as it could certainly signal a bigger issue somewhere.
[18:03] <ajs6f_> Agreed. It's not okay to ignore this.
[18:04] <ajs6f_> Actually, loggin this at debug isn't crazy to my ears.
[18:04] <ajs6f_> Hm. I wonder about Config C... why only Config C?
[18:11] <ajs6f_> afk
[18:15] * ajs6f (89360899@gateway/web/freenode/ip.137.54.8.153) has joined #duraspace
[18:16] * ajs6f_ (89360899@gateway/web/freenode/ip.137.54.8.153) Quit (Ping timeout: 245 seconds)
[18:16] <ajs6f> back
[18:35] * barmintor_afk is now known as barmintor
[18:37] <barmintor> Did you guys sort it out?
[18:37] * barmintor crosses fingers
[18:51] * ajs6f (89360899@gateway/web/freenode/ip.137.54.8.153) Quit (Ping timeout: 245 seconds)
[18:57] <cwilper> Not yet. I'm resorting to updating the log message to include a little more detail...to aid in figuring out what's going on. https://github.com/fcrepo/fcrepo/commit/58784deb75a7791809b36c2aad241990660a740d
[18:57] <kompewter> [ include more detail with log message when datastream type isn't as expec... · 58784de · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/commit/58784deb75a7791809b36c2aad241990660a740d
[18:58] * ajs6f (89360899@gateway/web/freenode/ip.137.54.8.153) has joined #duraspace
[19:34] * ajs6f (89360899@gateway/web/freenode/ip.137.54.8.153) Quit (Ping timeout: 245 seconds)
[19:45] <cwilper> barmintor: ran again, this time got an NPE for modifyDatastreamByValue. So it appears that somehow XMLDatastreamProcessor constructor is getting called with a null ds value.
[19:46] <barmintor> Yeah. I'm looking at this stacktrace...
[19:47] <barmintor> https://gist.github.com/bb8c5df64dd214d8aabc
[19:47] <kompewter> [ fcrepo error — Gist ] - https://gist.github.com/bb8c5df64dd214d8aabc
[19:48] <barmintor> trying to find a config C error.
[19:49] <barmintor> The thing is that some of these are expected failures. But the NPE was the one that got through, so presumably that's the real problem
[19:54] <barmintor> this is also weird: https://bamboo.duraspace.org/browse/FCREPO-CORE-JOB1-11/test/case/918649
[19:54] <kompewter> [ FCREPO-CORE-JOB1-11 Validate: Test Case Result - DuraSpace Bamboo ] - https://bamboo.duraspace.org/browse/FCREPO-CORE-JOB1-11/test/case/918649
[19:55] <barmintor> The assertion at https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java#L2577
[19:55] <kompewter> [ fcrepo/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/java/org/fcrepo/test/api/TestAPIM.java#L2577
[19:55] <barmintor> cannot throw a null pointer and also have been reached.
[19:56] <barmintor> either the null pointer is on 2560, or that's a normal true/false assertion
[19:56] <barmintor> something is not right
[19:57] <cwilper> The NPE I'm seeing with build-12 is new, and it's in place of the previous error that was caused by the wrong "type" of datastream being passed in to XMLDatastreamProcessor's constructor. Search for XMLDatastreamProcessor in https://bamboo.duraspace.org/artifact/FCREPO-CORE/JOB1/build-12/Fedora-server-logs/fcrepo-integrationtest-configC/target/fcrepo-3.6-SNAPSHOT/server/logs/fedora.log to see it...the only way this could be thro
[19:57] <cwilper> ..as null
[20:18] <barmintor> It doesn't have anything to do with this, but I do see a bug I introduced in SimpleDOReader.
[20:20] * ajs6f (89360899@gateway/web/freenode/ip.137.54.8.153) has joined #duraspace
[20:20] <ajs6f> Hola-- I'm back. Had to help a colleague with Camel.
[20:20] <ajs6f> Any news with these weirdo test cases?
[20:22] <barmintor> It's still nonsense. Nonsense!
[20:23] <ajs6f> Well, I'm wondering if we can think of anything weird about the Bamboo environement. The big mystery to me is
[20:23] <ajs6f> how the test that fails on the datastream categroy
[20:24] <ajs6f> could be failing. How can that attribute "shift"?
[20:24] <barmintor> and so consistently, in one configuration?
[20:24] <ajs6f> It's being explicitly set a couple of dozen lines above that very test!
[20:24] <ajs6f> Yeah, yeah-- what about that config?
[20:24] <ajs6f> What's different about COnfig C?
[20:24] <barmintor> it uses FESL
[20:25] <ajs6f> Moy-hoy!
[20:25] <ajs6f> Actually, that doesn't inspire me with any insight immediately.
[20:25] <barmintor> but FESL doesn't mess with datastreams :(
[20:26] <ajs6f> No, no.
[20:26] <ajs6f> Hm.
[20:26] <ajs6f> FESL might be engaged at some point when storing or retrieving that datastream.
[20:26] <ajs6f> Is it conceivable that we've got a _very_ subtle bug here?
[20:27] <ajs6f> But then why doesn't it show up on your or Chris' builds?
[20:30] <ajs6f> Chris, did you get any insight from the logs on Bamboo?
[20:45] <barmintor> we did see that the two modify NPEs are both from a datastream not being returned
[20:46] <ajs6f> Not being returned at all?
[20:46] <ajs6f> This is where I wish I had carried the Cargo work a little further.
[20:46] <ajs6f> We could run clients against that repo and see whether the ds is really there, or what.
[20:46] <barmintor> the only way to get those two NPEs is for a null to be returned for a datastream internal to Fedora, not on the client side
[20:47] <ajs6f> Ah, I see.
[20:47] <ajs6f> Still, we would have the repo available for inspection.
[20:48] <ajs6f> Which we don't, unless we break an executing int-test run and examine the debris.
[20:48] <ajs6f> Which might be worth doing
[20:48] <ajs6f> break -> stop execution
[20:48] <ajs6f> Chris-- can we do that? Run the bamboo build, stop it right after that test, and examine the repo?
[20:49] <ajs6f> I mean just the files, not the running repo.
[20:57] <ajs6f> Well, I'm out of here for the day. Good luck with these exceptionally mysterious exceptions!
[20:57] <barmintor> thanks ajs6f
[20:57] <barmintor> have a good one
[20:58] <cwilper> back. also headed off for the day. i can try saving the state of the repo on the bamboo server if that seems useful.
[20:58] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[20:59] <barmintor> all right. I'm going to push a minor bugfix up. Still not sure why the DS would be null there. Will keep working on it.
[21:00] <cwilper> ok, g'night
[21:00] * ajs6f (89360899@gateway/web/freenode/ip.137.54.8.153) has left #duraspace
[21:42] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) has left #duraspace
[21:52] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:36] * cwilper (ad579d7c@gateway/web/freenode/ip.173.87.157.124) Quit (Quit: Page closed)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.