Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* apb18 leaves00:07
* apb18 joins00:38
* apb18 leaves00:43
* jcoyne leaves00:47
* dwilcox joins05:44
* dwilcox_ joins05:48
* dwilcox leaves05:49
* dwilcox_ leaves06:16
* dwilcox joins06:21
* dwilcox_ joins06:23
* dwilcox leaves06:26
* dwilcox_ leaves06:30
* mcritchlow leaves08:38
* mcritchlow joins
* whikloj joins08:58
* kefo joins09:00
* mcritchlow leaves09:01
* arebenji` joins09:06
* kefo leaves09:15
* acoburn joins09:18
* mikeAtUVa joins09:20
* github-ff joins09:32
[fcrepo-camel-tests] awoods pushed 2 new commits to master: https://git.io/vrCgF
fcrepo-camel-tests/master d02e4fb Aaron Coburn: update camel-toolbox version to latest snapshot
fcrepo-camel-tests/master b2511ff Andrew Woods: Merge pull request #3 from acoburn/bump_version...
* github-ff leaves
* apb18 joins09:39
* travis-ci joins09:41
fcrepo4-exts/fcrepo-camel-tests#6 (master - b2511ff : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-tests/compare/4e1bae8a10f0...b2511ff59f95
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-tests/builds/130836462
* travis-ci leaves
* dwilcox joins09:45
* mcritchlow joins09:46
* dwilcox leaves09:50
* dwilcox joins09:51
* dwilcox leaves09:54
* apb18 leaves10:00
<mikeAtUVa>What's our plan for namespace prefix registration? I assume that whole mess will be an artifact that only exists in the modeshpae implementation and the fedora spec won't make any promises about namespace prefixes used in RDF responses?10:03
<acoburn>mikeAtUVa: that's my assumption, too10:04
<mikeAtUVa>acoburn: were you working on that utility to reassign them?
<acoburn>mikeAtUVa: https://github.com/fcrepo4-labs/fcrepo-namespace-util10:05
* dwilcox joins
<mikeAtUVa>acoburn: so it's probably reasonable (and likely not easily avoided) to allow non-privileged users to implicitly assign those namespaces?10:06
* peichman joins10:07
<acoburn>mikeAtUVa: I *think* that any use with access to any portion of the repository can assign a new namespace, but awoods could confirm that
s/any use with/any user with/
<mikeAtUVa>acoburn: they can't... that's the bug I'm trying to fix now.
<acoburn>mikeAtUVa: oh, I see...10:08
<mikeAtUVa>acoburn: I'm pretty comfortable allowing that to be true (especially since they can be changed) but I'm a little concerned about allowing them to register types since those can't be changed...10:09
https://jira.duraspace.org/browse/FCREPO-2024
<acoburn>mikeAtUVa: right, that makes sense — is there a way to easily distinguish between those two cases?10:10
<mikeAtUVa>Well, it's nasty... because if we disallow less-privileged users from creating types, then there's a subset of sparql updates they can't perform for seemingly arbitrary reasons.10:11
<awoods>mikeAtUVa: what exactly do you mean by "types" in this case?
rdf:types?
<acoburn>awoods: yes, rdf:type
<mikeAtUVa>awood: I think it's sparql updates that set the RDF:Type to a namespace whose prefix hasn't been registered... but I haven't actually explored that error thoroughly yet... having just discovered that getPropertyNameFromPredicate doesn't work for non admin users.10:12
<awoods>mikeAtUVa: what would be helpful for you?10:13
<acoburn>mikeAtUVa: look here: https://git.io/vrCXM
I see that the REGISTER_NAMESPACE permission is granted, but not the REGISTER_TYPES
REGISTER_TYPE, that is10:14
* dwilcox leaves
<mikeAtUVa>acoburn: it doesn't even get that far... just parsing the sparql update results in an AccessDenied exception from the PropertyConverter
* dwilcox joins
<ajs6f>Restricting the mapping of prefixes is one thing. That's syntactical. Restricting the assignment of types is a little different.10:15
If that's going to occur (and I can see the use cases) it needs to be consonant with other authZ practice.
<acoburn>ajs6f: yes, but the modeshape impl overloads that notion of types and puts any rdf:type into the jcr type system10:16
if rdf:type was just another property, we could completely avoid that
<ajs6f>acoburn: I know, but that can't stop us. MODE is one thing, the Semantic Web is something else.
acoburn: It will _never_ be just another property, because we have all kinds of ancillary machinery that is driven by it (indexing, etc.)10:17
acoburn: Or o you mean _stored_ as just another property?
<acoburn>ajs6f: I mean _stored_ as a jcr property
<ajs6f>acoburn: Okay, that seems reasonable. What side-effects are we _currently_ deriving from JCR type action?10:18
acoburn: Can we discard them?
<acoburn>ajs6f: in principle, someone could modify the cnd file and create certain kinds of type inference
ajs6f: but that's been strongly discouraged
<ajs6f>acoburn: If they are inflicting explicitly unsupported jankiness on themselves, they are going to get what they deserve.10:19
<mikeAtUVa>ajs6f,acoburn,awoods: to be clear, the [register_type] accessdenied exceptions I'm getting are for sparql as simple as "INSERT DATA { <> rdf:type dc:FakeType . }" the user has permission to Write to the resource in question, but type assignment fails if nothing else is that type.10:20
<acoburn>ajs6f: I *think* that discarding our using the jcr type system would be fine, though it will mean writing more migration utilities
<ajs6f>mikeAtUVa: Sure, but there's a context to it.10:21
<acoburn>mikeAtUVa: the webac module doesn't know what to do with the REGISTER_TYPE action, so it returns a not accessible error
* mcritchlow leaves
<ajs6f>acoburn: Small price for long-term love.
<acoburn>mikeAtUVa: I'd try just adding this line to the webac module: `map.put(REGISTER_TYPE, WEBAC_MODE_WRITE_VALUE);`10:22
in the WebACAuthorizationDelegate class
mikeAtUVa: I think that would fix it
<ajs6f>acoburn: Do you feel like that whole map init stanza should break out into a config file?10:23
* barmintor leaves
<acoburn>ajs6f: that's an interesting idea
<ajs6f>acoburn: Well, let's leave it there, then.10:24
<mikeAtUVa>acoburn, ajs6f, awoods: I guess all I need to know to proceed is confirmation that updating the codebase so that anyone who can update any resource can implicitly register namespaces and register types is an acceptable change in behavior?10:26
<ajs6f>mikeAtUVa: Are you comfortable with update including "can turn on indexing for this resource"?10:27
<awoods>mikeAtUVa: yes... I believe that is expected behavior.
<acoburn>mikeAtUVa: yes
<mikeAtUVa>ajs6f: if that's a result of RDF type, sure.10:28
<ajs6f>mikeAtUVa: Okay, then.
<mikeAtUVa>awoods, acoburn, ajs6f: thanks for your help and the consensus.10:29
* apb18 joins10:38
* dwilcox leaves10:40
<apb18>awoods: I took a look at upgrading to Jersey 2.22.2, and was successful. Even better, I'm seeing substantial improvements in latency and throughput in my little GET microbenchmark.10:50
<awoods>apb18: great news
apb18: was there much code impact?
<apb18>No, not reallly. There are three areas that needed modification due to method signature changes, but they were minor10:52
as far as the quality parsing, there were a handful of places that needed attention. qs=N where N>1.0 is problematic
* dwilcox joins10:54
<awoods>apb18: I will be interested in seeing the pull-request
<apb18>Should I create a new dicker and PR against that, or just update 2025?10:56
ticket
<awoods>apb18: this seems like the resolution to the 2015 dicker, no?10:57
apb18: this seems like the resolution to the 2025 dicker, no?10:58
<apb18>There is one place that looked like a bit of jersey hacking was going on, involving manipulating qs values so that requests without any Content-Type would go to the right place. My modifications would seem to circumvent that hack, but tests pass. I'll comment in the PR.10:59
awoods: Yes. So I'll just add commits to the existing PR?11:00
* dwilcox leaves11:01
<awoods>apb18: yes, please use https://jira.duraspace.org/browse/FCREPO-202511:02
apb18: is this the PR: https://github.com/fcrepo4/fcrepo4/pull/1037 ?
* mcritchlow joins
* dwilcox joins11:03
* awoods afk ~45min11:04
<apb18>awoods: that's it11:07
* mcritchlow leaves11:15
* kefo joins11:28
* apb18 leaves11:48
* github-ff joins11:52
[fcrepo-camel-toolbox] acoburn opened pull request #88: Enable checkstyle and license plugins (master...fcrepo-2026) https://git.io/vrWf3
* github-ff leaves
* dwilcox leaves11:57
* princesskittyfar joins12:07
* princesskittyfar leaves12:08
* dwilcox joins12:09
* dwilcox_ joins12:13
* dwilcox leaves
* kefo leaves12:17
* dwilcox_ leaves12:21
* apb18 joins12:24
* acoburn leaves13:01
<whikloj>bizarre use case. I create an resource A, then I create an indirect container (B) which has an ldp:membershipResource A13:07
then I create a resource C
lastly I create a proxy object inside the container B, which has the appropriate insertedContentRelation to point to C13:08
Now the kicker
I do this all inside a transaction, and when I commit it. I get the 4 objects, but now my insertedContentRelation has the tx ID in its path and so my resource A has the wrong resource (in fact no resource) for its hasMemberRelation13:10
ie. <> pcdm:hasMember http://localhost:8080/fcrepo/rest/tx:36a9caa8-8863-45f7-ac9e-6cbd9a53990f/b7/18/14/1e/b718141e-c280-4002-806c-9316fb89f96f
Did I do anything wrong? Or is this just a little gotcha around indirect containers and batch operations?13:11
* apb18 leaves13:16
* apb18 joins
<awoods>whikloj: it sounds like a bug.13:17
<whikloj>awoods: even if these are not server managed triples?13:18
<awoods>whikloj: I need to work through your example...13:20
<whikloj>awoods: alright, I'll open a ticket with all the details. If its not a bug then it can be closed.13:21
<awoods>whikloj: sure... assuming you have already dug into it.
<whikloj>awoods: that may not be a fair assumption, I'm just wondering if I can expect Fedora to fix potentially any triples with links created inside a transaction13:22
* acoburn joins13:29
<awoods>whikloj: Did you try adding the non-transaction URL for the resource?
<whikloj>awoods: do you mean PATCHing my proxy resource to correct the ldp:insertedContentRelation?13:30
<awoods>whikloj: or creating the proxy resource in the first place with the non-transaction ldp:insertedContentRelation.13:32
<whikloj>awoods: if I perform the same operations outside of a transaction then I have no issues. But each resource is created with the correct URI and therefore the ldp:insertedContentRelation has the correct final location.13:33
<awoods>whikloj: ok, I will look at the details you have in your ticket.13:34
<whikloj>awoods: ok, then I will create a ticket :)
<ajs6f>That sure as hell sounds like a bug to me. The tx is a discrete ontological region and once it ceases to exist the things in that region should simply reoccur in the larger repo w/o the user having to take other definite action.13:36
* kefo joins13:37
* github-ff joins13:54
[fcrepo-audit] awoods closed pull request #34: Removing filtering of events that contain only a lastModified property (master...remove-lastmod-filtering) https://git.io/vrm6v
* github-ff leaves
<awoods>apb18: If you do not mind, would you please add an avatar to your JIRA profile? Currently you show up as an "A". https://jira.duraspace.org/secure/RapidBoard.jspa?rapidView=27&projectKey=FCREPO13:56
ruebot: It would be interesting to see if apb18's PR addresses this ticket from York: https://jira.duraspace.org/browse/FCREPO-200214:00
* travis-ci joins
fcrepo4-exts/fcrepo-audit#101 (master - 8422d7a : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-audit/compare/4fee7a76b655...8422d7a5d896
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-audit/builds/130904569
* travis-ci leaves
<awoods>ruebot: apb18's PR: https://github.com/fcrepo4/fcrepo4/pull/1037
<apb18>awoods: avatar changed14:06
<awoods>apb18++
* github-ff joins14:14
[fcrepo-camel-toolbox] acoburn opened pull request #89: Move activemq support into an external OSGi service (master...fcrepo-2017) https://git.io/vrWuO
* github-ff leaves
* github-ff joins14:31
[fcrepo-camel-tests] acoburn opened pull request #4: update pax exam tests to include: (master...fcrepo-2017) https://git.io/vrW2m
* github-ff leaves
* arebenji` leaves14:33
* bseeger joins14:52
* ajs6f leaves15:16
<ruebot>awoods: back from meetings.15:29
* ruebot reads
<awoods>ruebot: welcome back15:30
<ruebot>awoods: when i run my tests again, i can build from head, and run that if it helps.
awoods: my goal was to get a new test running tomorrow or thursday, but i can hold off if you'd like.15:31
<awoods>ruebot: Since apb18's updates are just a PR and not in master, it would be good if you ran from his PR.
<ruebot>awoods: sure, i'll do that.15:32
<awoods>ruebot++
<ruebot>awoods: should i run with leveldb or postgres/mysql?15:33
<awoods>ruebot: postgres/mysql if possible
<ruebot>awoods: *naively asks where documentation on that is*15:34
<awoods>ruebot: https://jira.duraspace.org/browse/FCREPO-202515:35
<ruebot>awoods: oh, not that. configuring fcrepo4 to use postgres or mysql. i had never had the chance to deploy it in a non-leveldb state yet.15:36
<awoods>ruebot: https://wiki.duraspace.org/display/FEDORA4x/Configuring+JDBC+Object+Store
<ruebot>awoods++
awoods: i know what i'm doing tomorrow :-D15:37
awoods: question about fcrepo sprints if you have a sec.15:54
* tjohnson joins16:46
* whikloj leaves17:03
* apb18 leaves17:07
* acoburn leaves17:15
* bseeger leaves17:16
* peichman leaves17:49
* apb18 joins17:56
* apb18 leaves18:16
* dwilcox joins18:24
* dwilcox_ joins18:31
* dwilcox leaves18:32
* dwilcox joins19:21
* dwilcox_ leaves19:24
* tjohnson leaves19:26
* dwilcox_ joins19:53
* dwilcox leaves19:55
* dwilcox_ leaves20:43
* dwilcox joins20:47
* apb18 joins20:52
* dwilcox_ joins21:39
* dwilcox leaves21:41
* dwilcox_ leaves21:47
* dwilcox joins21:48
* apb18 leaves21:51
* arebenji` joins22:16
* kefo leaves22:20
* mikeAtUVa leaves23:10
* dwilcox leaves23:25
* dwilcox joins23:40
* dwilcox leaves23:41
* arebenji` leaves00:04

Generated by Sualtam