Timestamps are in GMT/BST.
[0:09] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[0:31] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[0:43] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[1:04] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[2:55] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[3:05] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[3:05] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Client Quit)
[3:52] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[4:27] * snail (~yeatesst@130.195.179.107) Quit (Ping timeout: 250 seconds)
[4:40] * snail (~yeatesst@130.195.179.107) has joined #duraspace
[6:17] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[6:38] -hitchcock.freenode.net- *** Looking up your hostname...
[6:38] -hitchcock.freenode.net- *** Checking Ident
[6:38] -hitchcock.freenode.net- *** Found your hostname
[6:38] -hitchcock.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:38] -hitchcock.freenode.net- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[12:04] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:54] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[12:54] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[12:54] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:59] * cwilper (ad55a88f@gateway/web/freenode/ip.173.85.168.143) has joined #duraspace
[13:00] <cwilper> Starting https://wiki.duraspace.org/display/FCREPO/2012-05-17+-+Fedora+Committer+Meeting
[13:00] <kompewter> [ 2012-05-17 - Fedora Committer Meeting - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/2012-05-17+-+Fedora+Committer+Meeting
[13:13] * ajs6f (89360ec9@gateway/web/freenode/ip.137.54.14.201) has joined #duraspace
[13:15] <cwilper> Ben: Move to CXF: 5 tests failing, one is for uploads. Differences between CXF and Jersey in terms of how multipart messages indicate they have zero length.
[13:16] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) has joined #duraspace
[13:18] <eddies> adam: proposal to generate WADL statically for the 3.6 release
[13:19] <ajs6f> ajs6f: Ben is having trouble getting the CXF-generated WADL to show up in the same place as the Axis-generated WADL, hence my suggestion.
[13:24] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[13:26] <eddies> FCREPO-1085: Ben's CXF JAX-RS branch
[13:27] <ajs6f> Summary of WADL discussion: We're not very worried about perfect dynamically-generated WADL.
[13:29] <ajs6f> https://jira.duraspace.org/browse/FCREPO-893
[13:29] <kompewter> [ [#FCREPO-893] Refactor authN/authZ servlet filters. - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-893
[13:30] <barmintor> Target Features/Fixes for 3.6 release: FCREPO-787, FCREPO-893, FCREPO-1085, UNC pull request
[13:31] <eddies> and FCREPO-831
[13:36] <barmintor> do we have a tracking issue for Greg's pull request?
[13:36] * barmintor looks
[13:39] <barmintor> tracking issue for Greg's pull request is FCREPO-1020
[13:40] <barmintor> So, revised 3.6 Remaining Feature/Fix List: FCREPO-787, FCREPO-831, FCREPO-893, FCREPO-1020, FCREPO-1085
[13:41] <ajs6f> Eddie: Can we push 831 to a hypothetical 3.6.1?
[13:41] <ajs6f> Chris: Not seeing a problem, because 831 is not a feature.
[13:43] <ajs6f> Eddie: Rationales for 831: makes tests easier to work with, gets client into the mainline of development
[13:44] <ajs6f> (note: we're talking about the new MediaShelf-sourced client)
[13:49] <ajs6f> ajs6f: Perhaps we can split 831 into smaller tasks.
[13:49] <ajs6f> Chris: Yeah, maybe.
[13:50] <ajs6f> Eddie and Chris: Wouldn't mean bringing the MS client into the source tree, just adding it as a maven dependency.
[13:51] <ajs6f> Decision: we're going to split 831 as follows:
[13:52] <ajs6f> 1) Bring MS client into test venue as Maven dependency and cnvert at least one test to use it.
[13:52] <ajs6f> 2) Decide on whether to use Jersey for MS client or convert to CXF.
[13:53] <ajs6f> 3) Convert all tests to use new client. (Probably a 3.6.1 issue)
[13:54] <ajs6f> Chris: OR2012! Who's going to be there?
[13:54] <ajs6f> https://wiki.duraspace.org/display/FCREPO/July+9th+2012%2C+OR12+Committer+Meeting
[13:54] <kompewter> [ July 9th 2012, OR12 Committer Meeting - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/July+9th+2012%2C+OR12+Committer+Meeting
[13:56] <ajs6f> CHris: will be out for next few weeks, on vacation
[13:56] <ajs6f> Chris: hopes discussion about managed projects will continue
[13:57] <ajs6f> https://jira.duraspace.org/browse/FCREPO-1084
[13:57] <kompewter> [ [#FCREPO-1084] Improve handling of datastream bindings for disseminations - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-1084
[13:57] <ajs6f> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/access/dissemination/DisseminationService.java#L455
[13:57] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/access/dissemination/DisseminationService.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/access/dissemination/DisseminationService.java#L455
[13:57] <ajs6f> https://github.com/fcrepo/fcrepo/blob/fcrepo-1084/fcrepo-server/src/main/java/org/fcrepo/server/access/dissemination/DisseminationService.java#L517
[13:57] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/access/dissemination/DisseminationService.java at fcrepo-1084 · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/fcrepo-1084/fcrepo-server/src/main/java/org/fcrepo/server/access/dissemination/DisseminationService.java#L517
[14:11] <barmintor> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/access/DescribeRepositoryServlet.java
[14:11] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/access/DescribeRepositoryServlet.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/access/DescribeRepositoryServlet.java
[14:12] <barmintor> https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/access/DescribeRepositoryServlet.java#L266 more specifically
[14:12] <kompewter> [ fcrepo/fcrepo-server/src/main/java/org/fcrepo/server/access/DescribeRepositoryServlet.java at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-server/src/main/java/org/fcrepo/server/access/DescribeRepositoryServlet.java#L266
[14:18] <ajs6f> Input pattern 2: dissURL/(bindingKey) Old output pattern: dissURL/NON-URL-encoded-datastream-URL New output pattern: dissURL/URL-encoded-datastream-URL
[14:28] <barmintor> cwilper: I have about 30 mins before a meeting, if you want to look at the 1085 branch
[14:29] <barmintor> I'm a little bit baffled by one of the failing tests: TestRESTAPI#testResponseOverride
[14:30] <cwilper> cool. which config test was spewing the errors? i'll just try to run that one.
[14:30] <barmintor> oh, I'm just running configA right now
[14:30] * ajs6f (89360ec9@gateway/web/freenode/ip.137.54.14.201) Quit (Ping timeout: 245 seconds)
[14:31] <barmintor> my bafflement for that test is more "what is the error I'm supposed to be accommodating here?"
[14:31] <cwilper> ok, running configA on 1085 locally...will have more context when i see a stack trace
[14:32] <barmintor> sure
[14:37] * ajs6f (89369bea@gateway/web/freenode/ip.137.54.155.234) has joined #duraspace
[14:42] <cwilper> ugh. this time i had another tomcat running so lots of stuff failed. re-trying.
[14:53] <cwilper> while it's re-running i'm looking at #testResponseOverride. It's testing the functionality of FilterRestApiFlash, a servlet filter that supports a "flash=true" argument to force all responses to be in the 200 range. Good old flash.
[14:54] <cwilper> If responses aren't in the 200 range, apparently flash get scared and runs off.
[14:55] <barmintor> so that's weird, but I'm also not sure what error I'm supposed to be dealing with before that in the test
[14:56] <ajs6f> One more reason to kill the Web admin.
[14:56] <ajs6f> The Flash Web admin, that is. Not your local human Web admin.
[14:56] <barmintor> As in: Am I supposed to be returning a 400 when someone POSTs to a non-existent url?
[14:57] <barmintor> Oh, I think part of this is that I'm checking fpr PID format in the path matching now
[14:58] <cwilper> Yeah I guess I thought of it as a syntax issue. "BOGUS_PID" is a malformed pid, so it could be seen as a "bad request" in that sense. But if it were a well-formed pid I'd definitely expect a 404.
[14:58] <barmintor> and BOGUS_PID doesn't match the regex
[14:59] <barmintor> we use "demo:BOGUS_PID" in some other places. Might just want to change that test.
[15:00] <barmintor> also may want to see if we can encode that regex somewhere in a constant.
[15:00] * barmintor makes a note
[15:00] <cwilper> Yeah, I don't think the contract for the rest api needs to be that strong. Generally clients should be dealing with non-200 responses in about the same way.
[15:01] <cwilper> So 400 vs 404 is kind of a toss up.
[15:01] <barmintor> have to run to a meeting, will check in later
[15:02] <cwilper> Tests finished on my end. I see that 404 vs 400 error, which makes sense for that method, as described. My total test Failures was 30, and test Errors was 3.
[15:02] <cwilper> ok
[15:26] <ajs6f> Eddie-- you online?
[15:27] <ajs6f> I've got a question or to about adding header-manipulation to the Fedora client.
[15:58] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[16:02] <cwilper> maybe he'll get an alert if you do eddies:, as in:
[16:02] <cwilper> eddies: Adam has a question
[16:03] <eddies> yesh?
[16:03] <eddies> ajs6f: i'm about to turn in, but i can answer a quickie
[16:06] <cwilper> not sure what adam was asking, but looking at the request classes, it occurs to me that FedoraRequest might be the appropriate place to add a addRequestHeader method.
[16:07] <cwilper> similar to what's done for queryParam, here https://github.com/mediashelf/fedora-client/blob/master/fedora-client-core/src/main/java/com/yourmediashelf/fedora/client/request/FedoraRequest.java
[16:07] <kompewter> [ fedora-client/fedora-client-core/src/main/java/com/yourmediashelf/fedora/client/request/FedoraRequest.java at master · mediashelf/fedora-client · GitHub ] - https://github.com/mediashelf/fedora-client/blob/master/fedora-client-core/src/main/java/com/yourmediashelf/fedora/client/request/FedoraRequest.java
[16:12] <eddies> yeah, that's sort of what i was thinking too. but i also see that as currently implemented, it's in the execute(FedoraClient) method of the individual concrete request classes that you'd have to apply the header(s), since that's where you get an instance of WebResource
[16:15] <eddies> i never worked through getting #execute(FedoraClient) to be DRYer for precisely something like applying headers and still return the specific FedoraResponse classes (e.g. AddDatastreamResponse)
[16:18] <ajs6f> Hoi! I'm back.
[16:18] <ajs6f> And I had gotten pretty much to where you guys were just talking.
[16:18] <ajs6f> I did look at supplying a
[16:19] <ajs6f> com.sun.jersey.api.client.filter.ClientFilter
[16:19] <ajs6f> but it doesn't appear that there is mutation of the headers available there.
[16:19] <ajs6f> So I'm looking now at offering a new constructor for FedoraClient
[16:19] <cwilper> Hi Adam. I guess the superclass could just put it in a protected field and then the concrete impls could prepare the WebResource object via calls to WebResource.header()
[16:19] <ajs6f> Superclass of what?
[16:20] <ajs6f> You mean Fedorarequest?
[16:20] <cwilper> yes
[16:20] <ajs6f> Yeah, I didn't want to do that because I'm lazy and it would mean altering every single conrete impl.
[16:20] <ajs6f> But maybe that's the right thing to do for now.
[16:21] <ajs6f> "i never worked through getting #execute(FedoraClient) to be DRYer for precisely something like applying headers and still return the specific FedoraResponse classes (e.g. AddDatastreamResponse)"
[16:21] <ajs6f> -- said by eddie
[16:21] <ajs6f> Is what I'd rather do, but I don't know that I should take the time.
[16:23] <cwilper> Hmm...how about creating FedoraRequest#getWebResource(FedoraClient client), which would pre-populate the WebResource with the header values set via FedoraRequest#addRequestHeader ...then subclasses at least don't have to have a lot of repetitive code.
[16:24] <cwilper> They'd just change "WebResource wr = fedora.resource();" to "WebResource wr = getWebResource(fedora);"
[16:24] <ajs6f> I was conteplating doing more-orless that at FedoraClient.resource(), but
[16:24] <ajs6f> your way is better.
[16:25] <ajs6f> I defeinitely want to set the header on a per-request basis.
[16:26] <ajs6f> Actually, that prettty well covers it, I think. It's pretty DRY (for me) and it's per-request and shouldn't take but a few moments.
[16:26] <cwilper> Right. I could see a desire to set it across a whole series of requests, too, though.
[16:26] <cwilper> But that's left as an exercise for the reader :)
[16:27] <ajs6f> yeah, that's where changing FedoraClient.resource() makes sense again.
[16:27] <ajs6f> Maybe I'll do both.
[16:27] <ajs6f> We have a readership?
[16:27] <cwilper> I think that ship has sailed.
[16:27] <cwilper> (trying to fill in for Dan, here)
[16:28] <ajs6f> <deadpan>Thanks.</deadpan>
[16:28] <ajs6f> I'm having the devil of a time running the tests for Fedora client. Does it have dependencies on network resources?
[16:29] <cwilper> oh gee, look at the time
[16:29] <cwilper> Are you talking about the old or new FedoraClient? Either way, it would be a bug if so.
[16:30] <ajs6f> New.
[16:33] <cwilper> trying to build it now...
[16:34] <cwilper> Oh, the integration tests.
[16:34] <ajs6f> Right.
[16:34] <cwilper> Yeah, I'm guessing you need to bring up a Fedora before running those.
[16:34] <ajs6f> I get tons of com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused
[16:34] <ajs6f> Oh, phooy.
[16:35] <ajs6f> Okay. I can do that. But it sounds like a job for Cargo.
[16:35] <cwilper> mvn verify -DskipITs=true <-- works
[16:36] <cwilper> yep, auto-starting a fedora repo with cargo would be awesome for stuff like this
[17:16] <ajs6f> afk
[18:00] * ajs6f (89369bea@gateway/web/freenode/ip.137.54.155.234) Quit (Ping timeout: 245 seconds)
[18:44] <barmintor> cwilper: do we expect the upload REST service to receive a multipart attachment named "file"?
[18:45] <cwilper> I believe the part is expected to be named "file", yes. At least that's what I recall.
[18:45] <barmintor> ok, that's helpful.
[19:40] * cwilper (ad55a88f@gateway/web/freenode/ip.173.85.168.143) Quit (Quit: Page closed)
[19:41] * cwilper (ad55a88f@gateway/web/freenode/ip.173.85.168.143) has joined #duraspace
[20:16] <barmintor> cwilper: is that flash parameter supposed to be available on all of the REST api, or just on object creation?
[20:18] <cwilper> I believe it's on the whole thing...jussec
[20:19] <cwilper> yep, the whole thing, and it's even documented woohoo
[20:24] <barmintor> oh god, that's horrible. We may need to give up on CXF for rest.
[20:25] <barmintor> damn. let me think about this.
[20:27] <cwilper> Yuck. Well a whole 'nother approach to the flash thing is to implement it in the Resource methods. But that's a lot of copy/paste code so doing it a little earlier in the call, before the dispatch to the appropriate method is made, would be ideal. Question is whether CXF allows that.
[20:30] <cwilper> CXF has a neat feature where you can specify _method=PUT when invoking any REST call...in order to "force" the method for clients that don't support it. Similar in purpose to X-HTTP-Method-Override, which CXF also does out of box.
[20:31] <cwilper> Looking at Fedora's current REST docs, it says we currently support X-HTTP-Method-Override. Not sure if that's via Jersey or some special hack we did.
[20:32] <cwilper> In any case, if we can find out where CXF intercepts requests to "force" the http method, that's probably close to where a common @QueryParam that applies to all methods, without being stated, would be introduced. Not sure that's an extension point they planned for, though.
[20:42] <cwilper> Aha: http://cxf.apache.org/docs/jax-rs-filters.html
[20:42] <kompewter> [ Apache CXF -- JAX-RS Filters ] - http://cxf.apache.org/docs/jax-rs-filters.html
[20:54] <barmintor> ok, so we should be able to get the request parms from OperationResourceInfo, and use that in a responsehandler to override the status code. Gross, but doable.
[20:55] <barmintor> Damn you, flash admin widget! Damn you!
[20:57] <barmintor> Also messed up: The @Path annotation supports a regex for the pid portion, but I'm working around using it so that we can reject the request in another way.
[21:00] <barmintor> Actually, do we really want to support that? I'd rather let it reject that stuff with 404's, and save the flash override behavior for things that might possibly have worked (like trying to update a nonexistent but otherwise valid PID)
[21:06] <cwilper> Regex support seems unnecessary, and rejecting with 404 is fine I think. GOtta go though..
[21:06] * cwilper (ad55a88f@gateway/web/freenode/ip.173.85.168.143) Quit (Quit: Page closed)
[21:11] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:52] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.