#duraspace IRC Log

Index

IRC Log for 2012-06-22

Timestamps are in GMT/BST.

[0:36] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[2:12] * lyncode (~DSpace@bl23-42-67.dsl.telepac.pt) Quit (Quit: lyncode)
[2:58] * elschlomo (~ruckus@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Ping timeout: 276 seconds)
[4:53] * ruckus (~ruckus@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[4:58] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[5:30] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[5:39] * eddies (~eddies@bb219-74-181-215.singnet.com.sg) has joined #duraspace
[5:39] * eddies (~eddies@bb219-74-181-215.singnet.com.sg) Quit (Changing host)
[5:39] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:08] * helix84 (a@195.113.97.174) has joined #duraspace
[6:28] -sendak.freenode.net- *** Looking up your hostname...
[6:28] -sendak.freenode.net- *** Checking Ident
[6:28] -sendak.freenode.net- *** Found your hostname
[6:28] -sendak.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
[6:46] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[10:36] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[10:47] <helix84> is anyone online who could help me with overlays?
[11:00] * ruckus (~ruckus@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Ping timeout: 265 seconds)
[12:52] * ruckus_ (~ruckus@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[13:22] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[13:53] * ruckus_ (~ruckus@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[14:09] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[14:09] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[14:09] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[14:45] * Dan_Davis (4a4f9413@gateway/web/freenode/ip.74.79.148.19) Quit (Quit: Page closed)
[15:17] * barmintor (~barmintor@cpe-72-229-190-215.nyc.res.rr.com) has joined #duraspace
[15:18] * cwilper (ad579e7f@gateway/web/freenode/ip.173.87.158.127) has joined #duraspace
[15:21] <cwilper> barmintor: regarding fcrepo-1102, it sounds like it would be ok to remove the pid regexes @Paths as long as we can ensure that the mapping is working right, then. I was planning on doing a test of each method with/without %3A in place of the pid namespace delimiter (":"), so it seems if I can get that to pass, we're golden.
[15:22] <cwilper> ...right?
[15:22] <barmintor> cwilper: I think so
[15:22] <cwilper> good enough for me at this point. I'll give it a shot and see what happens, then.
[15:24] <barmintor> it's possible that the status code for a malformed pid changes from a 404 to a 500
[15:26] <barmintor> I'm actually kind of surprised that these params aren't decoded before being matched
[15:27] <barmintor> in fact, http://cxf.apache.org/docs/jax-rs-basics.html says that they are decoded
[15:27] <kompewter> [ Apache CXF -- JAX-RS Basics ] - http://cxf.apache.org/docs/jax-rs-basics.html
[15:30] <barmintor> cwilper: You might want to keep the code more or less intact, and just swap in a different value for VALID_PID_PART
[15:30] <barmintor> b/c this CXF documentation is all suggesting that the params are decoded first
[15:32] <cwilper> right. there are some cases where VALID_PID_PART isn't used, like for getObjectExport though. Yes, I found that odd...the correct behavior is for the JAX-RS impl to decode the param value, but I wonder if that step is getting skipped by CXF because it's using a regex. I hunted for bug reports and couldn't find anything.
[15:39] <barmintor> cwilper: getObjectExport is not using it because of developer error :(
[15:42] <cwilper> , ahh: the old PICNIC bug: problem in chair, not in computer . Well that's easy enough to fix. The other place it's not used is at the top of DatastreamResource. Maybe I can refer to the constant there if I make it public (actually, it should probably be in BaseRestResource instead of FedoraObjectsResource, eh?)
[15:45] <barmintor> Yeah.
[15:46] <barmintor> cwilper: It's also possible that CXF is being smart about this to our detriment
[15:46] <barmintor> since a ':' is a valid character for a path segment
[15:54] <cwilper> Ahh, maybe the regex matching is happening on the non-decoded version of the path segment. So using %3A instead of ":" means no matching method is found.
[15:56] <cwilper> I'll try to figure out if that's the case now.
[16:09] <cwilper> Sure enough, looking at the server log, I see (JAXRSUtils) No operation matching request path "/fedora/objects/test%3ASomeObject" is found, Relative Path: /test%3ASomeObject, HTTP Method: GET, ContentType: */*, Accept: */*,...
[16:14] <barmintor> cwilper: so then the follow-up question is whether that path segment is decoded in the body of the method (if it's matched)
[16:15] <cwilper> yep. i tweaked the regex to allow for %3A and %3a, and I'm testing that now.
[16:38] <cwilper> The answer is yes. So just tweaking the regex fixes it. I'm inclined to call that a fix, then. I will do a full test and check in the change, which a) consistently uses the same constant for @Path annotation values involving PIDs, b) allows for ":", "%3A", or "%3a" as the namespace delimiter of the PID as it occurs in the path segment, and 3) tests all three of those encodings as part of the configA & B tests via some test reques
[16:39] <cwilper> any other things to test/look out for you can think of?
[16:43] <barmintor> cwilper: Not off the top of my head. Thanks for hunting this down, sorry the CXF/jaxrs move has been such a pain
[16:43] <barmintor> though I think we;re in better shape for it
[16:50] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) has joined #duraspace
[16:52] * vtkeithg (~vtkeithg@2001:468:c80:a103:29ff:e63:1f7b:2540) has left #duraspace
[17:00] <cwilper> definitely in better shape. getting axis out of there was important. thanks ben.
[17:24] * barmintor (~barmintor@cpe-72-229-190-215.nyc.res.rr.com) Quit (Read error: Connection reset by peer)
[17:56] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) Quit (Quit: lyncode)
[18:04] * cwilper (ad579e7f@gateway/web/freenode/ip.173.87.158.127) Quit (Quit: Page closed)
[18:55] * tdonohue1 (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[18:55] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Disconnected by services)
[18:55] * tdonohue1 is now known as tdonohue
[21:13] * lyncode (~DSpace@bl23-42-67.dsl.telepac.pt) has joined #duraspace
[21:27] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:29] * lyncode (~DSpace@bl23-42-67.dsl.telepac.pt) Quit (Read error: Connection reset by peer)
[21:29] * lyncode (~DSpace@bl23-42-67.dsl.telepac.pt) has joined #duraspace
[22:08] * PeterDietz (~peterdiet@128.146.173.59) Quit (Remote host closed the connection)
[22:09] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) Quit (Remote host closed the connection)

These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.