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

Using timezone: Eastern Standard Time
* awoods_ joins08:23
* mikeAtUVa joins08:24
* mhwood joins08:26
* awoods__ leaves08:27
* ajs6f joins08:44
* dhlamb joins08:45
* github-ff joins08:49
[fcrepo4-release-tests] ajs6f pushed 2 new commits to master: http://git.io/vqXZC
fcrepo4-release-tests/master b5a1960 Andrew Woods: Minor dependency updates...
fcrepo4-release-tests/master efb9485 A. Soroka: Merge pull request #12 from awoods/fcrepo-1615...
* github-ff leaves
* github-ff joins
[fcrepo4] ajs6f closed pull request #831: Enable JSON-LD profiles for response serializations (master...fcrepo-1615) http://git.io/vqzZY
* github-ff leaves
* mhwood leaves
<ajs6f>awoods_: Does it strike you as weird that our release tests are in the labs account? That's one of the things that makes me think we do need a third account.08:50
awoods_: or maybe, as a part of the reference impl, they belong in core.08:51
* awead joins08:54
* travis-ci joins08:55
fcrepo4-labs/fcrepo4-release-tests#41 (master - efb9485 : A. Soroka): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo4-release-tests/compare/7ad0e92525c3...efb948515df0
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo4-release-tests/builds/70216967
* travis-ci leaves
* whikloj joins08:57
* awead leaves09:02
* awead joins
* travis-ci joins
fcrepo4/fcrepo4#3806 (master - 9676db5 : A. Soroka): The build passed.09:03
Change view : https://github.com/fcrepo4/fcrepo4/compare/3d2d0bbb3f62...9676db5e7044
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/70217024
* travis-ci leaves
* Bethany joins
<awoods>ajs6f: yes, we need some github clean-up09:04
<ajs6f>awoods: DO you want to move the tests into core?09:05
<awoods>ajs6f: No, those tests bring in several elements, including non-core ones.09:06
<ajs6f>awoods: They really shouldn't be doing that, should they? What are they testing that isn't core?
<awoods>ajs6f: sparql queries09:07
<ajs6f>awoods: Against a triplestore?
<awoods>ajs6f: yes
ajs6f: they are automated sanity tests
<ajs6f>awoods: I would argue that that piece should be broken out. ONe reason: a set of release tests that tests only the core is the seed for an eventual TCK for the specifications.09:08
<awoods>ajs6f: fcrepo4-release-tests focuses mostly on the sparql recipes... maybe it needs to be renamed.09:09
<ajs6f>awoods: Okay, yeah. If it's really about the SPARQL stuff, that's cool and we do need that, but it should be named more accurately.
<awoods>ajs6f: yes. It was named based on projected intention.09:12
<ajs6f>awoods: Fedora 4 is mostly built on psychological projection.
<awoods>ajs6f: I noticed that you did not heed my request to squash commits: https://github.com/fcrepo4/fcrepo4/commits/master09:16
ajs6f: I am happy to do that once the code review is over in order to keep the history clean.09:17
ajs6f: just let me know.
<ajs6f>awwods: What request?09:29
* acoburn joins
* awoods_ joins
ajs6f: see the commit history: https://github.com/fcrepo4/fcrepo4/commits/master09:30
* ksclarke joins
<ajs6f>awoods: I see that. I don't see any request that you made, just a label on a commit.
<awoods_>ajs6f: yes, just words09:31
* awead leaves
<ajs6f>awoods: If you want me to do something unusual (like squash commits) putting a magic label on a commit is a shitty way to ask.
<awoods_>ajs6f: and more words in my last comment in the actual ticket: https://jira.duraspace.org/browse/FCREPO-1615
<ajs6f>awoods_: Okay, a ticket comment makes more sense. I should have caught that.09:32
awoods_: If you want something squashed, I would definitely do it yourself.
awoods_: My opinion is with cbeer's practice. Squashing is a bad practice.09:33
* awoods leaves
<awoods_>ajs6f: I am happy to do so. When you are reviewing I can do force commits instead of incremental commits.
<ajs6f>awoods_: Yes, that is what I would do. Nothing wrong with rewriting _private_ history.09:34
<awoods_>ajs6f: I find it extremely helpful to see incremental commits during the review iterations.
ajs6f: but if you do not, I am happy to do force commits.
<ajs6f>awoods_: That's fine with me, too. I am happy to see them go into the public history. It is you who have a problem with that.09:35
awoods: I am going to send you a PR for your PR827, with some cleanup.09:36
<awoods>ajs6f: do you have a link?
<ajs6f>awoods: Still making the changes… I will send you an actual Git PR.09:37
* awead joins09:41
* mikeAtUVa leaves09:42
* github-ff joins09:46
[fcrepo4] ajs6f created PatchForAwoods (+4 new commits): http://git.io/vqXMd
fcrepo4/PatchForAwoods 2426c46 Andrew Woods: Eliminate the publishing of UUID triples...
fcrepo4/PatchForAwoods 49efc50 Andrew Woods: Address code review comments....
fcrepo4/PatchForAwoods 5a2bfc6 Andrew Woods: PLEASE SQUASH...
* github-ff leaves
* mikeAtUVa joins09:53
* github-ff joins09:57
[fcrepo4] ajs6f deleted PatchForAwoods at 501b6ba: http://git.io/vqXQT
* github-ff leaves
<ajs6f>awoods: I'm goog with 827. Do you want to squash it?09:58
good
<awoods>ajs6f: yes, squashing now
<ajs6f>k
* mikeAtUVa leaves09:59
* travis-ci joins10:01
fcrepo4/fcrepo4#3807 (PatchForAwoods - 501b6ba : ajs6f): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/2426c46676be^...501b6ba3bdae
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/70225085
* travis-ci leaves
<awoods>ajs6f: https://github.com/fcrepo4/fcrepo4/pull/82710:09
<ajs6f>awoods: on it10:10
* github-ff joins10:27
[fcrepo4] ajs6f pushed 2 new commits to master: http://git.io/vq1vR
fcrepo4/master b13e961 Andrew Woods: Eliminate the publishing of UUID triples...
fcrepo4/master 2a4e650 A. Soroka: Merge pull request #827 from awoods/fcrepo-1539...
* github-ff leaves
* mikeAtUVa joins10:30
* jgpawletko joins10:35
* awead leaves
* mikeAtUVa leaves
* awead joins10:38
* travis-ci joins10:39
fcrepo4/fcrepo4#3810 (master - 2a4e650 : A. Soroka): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/9676db5e7044...2a4e650231b4
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/70231057
* travis-ci leaves
<f4jenkins>Yippee, build fixed!10:54
Project fcrepo4-T2 build #288: FIXED in 6 min 5 sec: http://jenkins.fcrepo.org/job/fcrepo4-T2/288/
* awoods: Remove fedora:hasNodeType triples from root description
* awoods: Enable JSON-LD profiles for response serializations
* awoods: Update jsonld.version to 0.5.1
* awoods: PLEASE SQUASH
* awoods: Eliminate the publishing of UUID triples
* apb18 joins10:58
<ajs6f>I'm here11:00
Welcome Bethany!11:02
<whikloj>hahaha11:07
<ajs6f>awoods: Why do you hate us?
<dhlamb>ruh roh
* awoods_ joins
<ajs6f>The evil awoods_ has taken control from the good awoods.11:08
<whikloj>ajs6f: maybe you should be the chairperson
* jrgriffiniii joins
<awoods_>back
<ajs6f>whikloj: You expect me to contribute? _I don't think so_.
<whikloj>ajs6f: no no, just not drop the connection.11:09
<acoburn>I'm here
<ajs6f>whikloj: I don't think my connection is much better than evil awoods_.
back11:10
* dwilcox joins
<whikloj>ajs6f: perhaps if we force the evil awoods_ and good awoods together the resulting being will transcend "internet"11:11
* awoods leaves
<ajs6f>whikloj: Or they will annihilate each other in a flash of raditation.11:12
whikloj: Either way, it sounds good.
<whikloj>ajs6f: lol
<escowles>awoods: gotta run to another meeting, sorry...11:30
<ajs6f>OSGi is probably the best way to do that to which we have access.11:33
* Bethany leaves11:47
<whikloj>acoburn: +1 to that11:54
http://www.osgi.org/Technology/WhyOSGi11:57
<ajs6f>https://github.com/frieder/servletbridge-felix
Just an example.
+1 to 311:59
<acoburn>also +1 to 3 organizations12:00
<whikloj>+1 to 3
<dhlamb>fcrepo-addons?
<ajs6f>fcrepo4-bag-of-stuff12:01
fcrepo4-junk-drawer
fcrepo4-compost-bin
<acoburn>fcrepo4-extensions
<dhlamb>awoods shaved his goatee and is now no longer evil?12:02
assuming _ denotes evilness
<whikloj>+1 fcrepo4-extensions
<awoods>fcrepo4- "ext", "extras", "addons", "bos", "junk", "extensions"
I like "extensions", but it is somewhat long.
<ajs6f>extensions is pretty neutral. How about -ext.
fcrepo4-ext
<dhlamb>addons, extensions, extras... any of those will do, i'm easy
<whikloj>*-ext is fine with me12:03
<awoods>dhlamb: ext?
<ajs6f>opt
<dhlamb>yes, it also allows for the possiblity of "extreme"
ext works for me
<acoburn>ext works for me
<whikloj>fcrepo4 "to the extreme!!!"
<dhlamb>fcrepo4-x
lol
srsly tho, -ext is fine
<awoods>acoburn/all: btw, the Sonatype people confirmed that we can define release permissions on a sub-packagename, such as: org.fcrepo.ext12:04
<ajs6f>Fedora 4: As extreme as Perry Como.
<awoods>related to this question: Should optional projects share the same "org.fcrepo" package namespace?
<whikloj>ajs6f: https://www.youtube.com/watch?v=XZpW2aBLm5I12:05
<dhlamb>i don't see why not, as long as they're under the duraspace umbrella, right?
assuming it would be org.fcrepo.ext.yourproject
<awoods>dhlamb: there is a potential issue around releases
namely, extension projects should be owned and released by others12:06
<dhlamb>that ext and core might not want to move in lockstep?
<ajs6f>whikloj: That is about the level of coolness that Fedora exhibits.
<dhlamb>ah, that
i gotcha
<ajs6f>awoods/dhlamb: I think that's a project-by-project question.
<awoods>dhlamb: in order to release to the org.fcrepo namespace, you need Sonatype permissions
<dhlamb>ic
<ajs6f>awoods/dhlamb: Some things in -ext may be "owned" by the committers, some not.
<awoods>dhlamb: however, we can grant permissions on org.fcrepo.ext12:07
and those permissions do not also allow release privilege on org.fcrepo
which is good
<dhlamb>if you can swing that, then sure
lock it down to org.fcrepo.ext
<whikloj>awoods: would that be specific to each extension or a blanket grant on all org.fcrepo.ext12:08
<awoods>dhlamb: confirmed today that it is swingable
<ajs6f>awoods is quite the swinger
<awoods>whikloj: good point
<acoburn>just a note the fcrepo-camel and fcrepo-camel-toolbox are both under the org.fcrepo.camel namespace
<awoods>whikloj: basically we can grant permissions on package names: org.fcrepo.whatever
<ajs6f>Why does everything in the Github account -et have to be in the same module space?12:09
<apb18>Are we talking about java package names, or maven groupIds when mentioning something like "org.fcrepo.ext"?
<awoods>ajs6f: that is a good question
<ajs6f>Aren't we confusing the managment of source code with the managment of artifacts?
<dhlamb>maven
<ajs6f>dhlamb: No, not so.
Maven does not make us do that.
<awoods>apb18: ideally they are the same
<whikloj>awoods: so is it preferably that acoburn moves camel to org.fcrepo.ext.camel?12:10
<awoods>whikloj: that depends on the answer that ajs6f raised: "Why does everything in the Github account -et have to be in the same module space?"12:12
<acoburn>whikloj: I have been thinking that o.f.ext was for extensions to the fedora core (audit, etc) — the camel stuff is a little different
<ajs6f>Let me answer my own question: it doesn't.12:13
<whikloj>awoods/ajs6f: so fcrepo-camel-toolbox can move to fcrepo4-ext but stay in org.fcrepo.camel?
<ajs6f>whikloj: I see no reason not.12:14
<acoburn>I'd suspect that fcrepo-camel would also move to fcrepo4-ext
and keep the same namespace
<awoods>ajs6f/whikloj: there are release implications to the package/groupId name
<whikloj>awoods: my release knowledge is limited, can you explain12:15
<ajs6f>awoods: Sure, but releases from -ext will be heterogenous anyway.
<awoods>whikloj: release artifacts (in the Fedora process) go through Sonatype
whikloj: Sonatype grants user-level permissions on who has the privilege to release to different namespaces12:16
whikloj: if we want developers in the wild to be able to create, maintain, and release extensions, they either need to be in a non-org.fcrepo namespace...
<whikloj>awoods: or you have to grant them permissions12:17
<awoods>whikloj: or those users need to be granted permissions on either org.fcrepo or org.fcrepo.whatever
<ajs6f>WHy would there be any prob with extensions being in a non org.fcrepo ns?
<whikloj>awoods: I don't see a problem there
<ajs6f>It's not like people are manually linking software here.
<awoods>whikloj: where?
<ajs6f>We have software that does that for us.12:18
<awoods>ajs6f: artifacts can only be released by people who have rights on namespaces...
<ajs6f>awoods: Yes, so/.
<apb18>Would we be offering the ability to publish to artifacts to maven central under groupid org.fcrepo.ext as a service to the extension-authoring community?
<ajs6f>apb18: I hope not.
<whikloj>awoods: obviously for some extensions (fcrepo-camel) the namespace is already org.fcrepo.camel, but that doesn't require the next extension to use org.fcrepo.anything, right?
<awoods>ajs6f: if we want to include specific extension artifacts in Fedora releases, the release manager needs to have rights on all of the packagenames that are included.12:19
<ajs6f>If an extension is com.foo.bar, and the people who maintainn it release it (because they have the Sonatype-rights to com.foo.bar) and the source code is in fcrepo4-ext, then where is the problem here?
<whikloj>awoods/ajs6f: see I thought the point was that your would NOT release the extensions with a Fedora release12:20
<ajs6f>If we want to include com.foo.bar.CoolThing in a release, then the people who maintain it needs to grant that permission, _which we would want them to do anyway_.
whikloj: That would be my default understanding, but even otherwise, I don't see a problem.
<awoods>ajs6f: all of these points are true. I am just trying to make the implications clear.12:21
<ajs6f>awoods: Oh, okay. I thought you had objetions.
afk bbl12:22
* ajs6f leaves
<whikloj>awoods: so you release Fedora, and if there is no change required to fcrepo-camel then acoburn does nothing.
<awoods>whikloj: ideally, yes.12:23
<whikloj>awoods: good done, thanks for coming out :)
<awoods>whikloj: that relates to: "Should we decouple the version number schemes of optional projects from core releases?"
<whikloj>awoods: yes, IMHO
awoods: pardon, yes we should decouple version number schemes of optional projects from core12:24
<awoods>whikloj: the primary arguments for coupling are: clarity of module compatibility, and pom.xml inheritance12:25
whikloj: currently most extension modules inherit from the main fcrepo4/pom.xml (to great benefit)
<acoburn>whikloj/awoods: maven inheritance is a big plus12:26
but for certain types of projects (camel-* and the fcrepo-client) that tight coupling is not necessary
<whikloj>acoburn/awoods: how big is the plus compared with the Sonatype issues?12:27
<awoods>whikloj: unrelated
<whikloj>awoods: so the coupling is purely that even if nothing changes in all these extensions you still have to mark them as changed with each release?12:28
<acoburn>whikloj: that is correct12:29
<whikloj>acoburn/awoods: but a feature change to any extension then has to wait for a release of fcrepo, correct?
<acoburn>whikloj: sometimes there may not be any code changes in the extension, but if the parent pom updates a certain dependency, that may also affect the downstream project12:30
whikloj: yes, a feature change to an extension must wait for a full fcrepo release
<whikloj>acoburn: this architecture sounds very un-OSGi12:31
<acoburn>whikloj: which is part of the reason why we've been aiming for frequent point releases
whikloj: it is
* dhlamb leaves12:32
<apb18>I'm actualy much more confused now as far as the goverance model of the contents of fcrepo4-ext, and its relationship to the activities of Fedora releases than I was before this conversation began.12:34
<whikloj>acoburn: it seems less than efficient to have a frequent point release of fedora to allow for changes to its extensions. How much of a benefit is this maven inheritence?12:35
* dhlamb joins12:36
* apb18 leaves
<whikloj>awoods/acoburn: If you are moving the modules to the fcrepo4-ext and separating them from core, but then still requiring them to rely on each other for releases. I see no reason to do this?12:37
<acoburn>whikloj: IMO, if we decoupled the fcrepo-kernel-api version from the implementation version, then we would have more flexibility w/r/t extension modules (which should only use the api)12:38
whikloj: if an extension module relies on the implementation (fcrepo-kernel-impl) then it should be in core and shouldn't be an extension
whikloj: much of this is just growing pains and an attempt to make fcrepo4-labs less of a mess12:39
<whikloj>acoburn: I agree with most of your points, except because an extension relies on fcrepo-kernel-impl does that make it automatically part of core?12:40
acoburn: or does this go to the larger question of what is "core" of fcrepo4?12:41
<acoburn>whikloj: in principle, an extension module shouldn't be messing with fcrepo-kernel-impl
whikloj: yes, this is exactly related to the question of what belongs in "core"12:42
whikloj: for instance, a good candidate for a module to be removed from core is fcrepo-transform
whikloj: it's very useful, but it's really more of an extension than a core part of the repository12:43
<whikloj>acoburn: right, I have never used fcrepo-transform
<acoburn>whikloj: we will be making significant use of it
whikloj: it implements a really great feature12:44
<whikloj>acoburn: foreshadowing++
acoburn: your talking about LDPath?12:48
<acoburn>whikloj: yes
<whikloj>acoburn: ok so why is it in core?12:49
<acoburn>whikloj: you'd have to ask awoods12:51
<whikloj>awoods: ^^
<awoods>whikloj: it is a historic artifact. I should be extracted.
whikloj: it is a historic artifact. It should be extracted.
<whikloj>awoods: what is involved in extracting fcrepo-transform from core?12:52
<awoods>whikloj: adding it to webapp-plus
whikloj: interested?12:53
<acoburn>whikloj: and making sure all the camel integration tests don't break
<awoods>which I assume they will12:54
<whikloj>awoods/acoburn: in a general "helping the community sense"? yes. Just not sure I understand the implications. Is there a ticket?
<acoburn>which I know they will
<whikloj>acoburn/awoods: does fcrepo-transform use fcrepo-camel or vice-versa?12:55
<awoods>whikloj: not unless acoburn happened to have created one.
whikloj: yes, vice-versa
<acoburn>whikloj: the camel projects make use of the fcr:transform endpoint
whikloj/awoods: I have not created a ticket for this12:56
<whikloj>acoburn: okay so fcrepo-transform is moved to fcrepo-webapp-plus. First question is should it be, or should it be it's own extension?12:57
<acoburn>whikloj: my understanding is that fcrepo-transform is its own extension, but it would be used by webapp-plus12:58
just like fcrepo-audit
<awoods>acoburn++
<whikloj>acoburn/awoods: okay, so conceivable this could be a 3 step process. 1) copy fcrepo-transform functionality to it's own extension and integrate with fcrepo-webapp-plus13:00
acoburn/awoods: 2) Point fcrepo-camel to work with fcrepo-webapp-plus13:01
acoburn/awoods: 3) remove fcrepo-transform from core
acoburn/awoods: yes/no/maybe?
<acoburn>whikloj: I would add: 0) add a fcrepo4-ext organization that will host the fcrepo-transform module13:02
<awoods>whikloj: sounds about right. I would also extend (2) to say "Fix breakage in satellite projects"13:03
<whikloj>acoburn: is that required or desired?
awoods: breakage in dependencies of fcrepo-camel or fcrepo-transform or both?13:04
<acoburn>whikloj: desired, but it should be happening pretty soon
<whikloj>acoburn: gotcha13:05
<awoods>whikloj: breakage, period.
<whikloj>awoods: see I am trying to make manageable chunks and you aren't playing nice.
<awoods>whikloj: I have a script that builds the following projects that I use after refactorings:13:07
<acoburn>whikloj: btw, the fcrepo-camel integration tests don't actually use fcrepo-webapp — they use a custom spring configuration, which *should* make it easier to fix
<awoods>PROJECTS=("fcrepo-build-tools \
fcrepo4 \
fcrepo-message-consumer \
fcrepo-module-auth-rbacl \
fcrepo-module-auth-xacml \
fcrepo-camel \
fcrepo4-client \
fcrepo-audit \
fcrepo-camel-toolbox \
fcrepo-webapp-plus \
fcrepo4-release-tests \
fcrepo4-oaiprovider \
fcrepo4-swordserver \
migration-utils")
whikloj: most of these will not be impacted, but it is good to check13:08
<acoburn>whikloj/awoods: the fcrepo-camel-toolbox projects use a prebuilt war file, but we should be able to just point that at webapp plus13:09
<whikloj>awoods/acoburn: nevermind13:10
<awoods>whikloj: nevermind about being interested in extracting fcr:tranform?13:11
<whikloj>awoods: nevermind about actually extracting fcr:transform. Apparently the implications are HUGE.13:13
<awoods>whikloj: I doubt the implications are huge, but there are impacts.13:14
whikloj: if anyone is up to the job, you are.13:15
<whikloj>awoods: I see what you're trying to do there.13:16
awoods: see once you you start to list impacts on the swordserver, I start to worry about the swordserver. I don't know what the swordserver is!!!13:19
<awoods>whikloj: you could locally rip out fcrepo-transform, run the script I just sent you, and see where the chips fall.
* dwilcox leaves13:42
* tolloid joins14:01
* ajs6f joins
A big +1 to factoring out fcrepo-transform.14:05
And I believe in whikloj!
* dwilcox joins14:18
* dwilcox leaves14:19
* dwilcox joins14:21
* awead_ joins14:41
* awead leaves14:43
* jmignault leaves14:56
* jmignault joins14:59
<whikloj>acoburn: ping15:04
<acoburn>whikloj: about to start a meeting… is it a quick question?15:05
<whikloj>acoburn: probably not, I'll catch you another time
<acoburn>whikloj: catch me in ~ an hour
* dwilcox leaves15:24
* awoods_ joins15:31
* awoods leaves15:35
* github-ff joins15:52
[fcrepo-webapp-plus] acoburn opened pull request #15: fix spring config for audit feature (master...fcrepo-1621) http://git.io/vqDDJ
* github-ff leaves
* github-ff joins15:53
[fcrepo-webapp-plus] awoods closed pull request #15: fix spring config for audit feature (master...fcrepo-1621) http://git.io/vqDDJ
* github-ff leaves
* ajs6f leaves15:54
* travis-ci joins15:59
fcrepo4-labs/fcrepo-webapp-plus#49 (master - 984c9a0 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-webapp-plus/compare/ad181675b6b1...984c9a021bac
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo-webapp-plus/builds/70279541
* travis-ci leaves
<acoburn>whikloj: ping16:04
* dhlamb leaves16:11
<whikloj>acoburn: hi16:13
<acoburn>whikloj: you had a question?16:14
<whikloj>acoburn: trying to make a simple camel script to accept a REST request and push a JMS message to a queue. I seem to have some problems with the activemq component and am not sure how to diagnose.
<acoburn>do you have some code I can look at?16:15
<whikloj>acoburn: https://gist.github.com/whikloj/5f0b355b343f89786c5516:16
<acoburn>whikloj: what does the spring/blueprint config look like? where you define {output.stream}16:17
<whikloj>acoburn: output.stream=activemq:${uofm-route.jms.endpoint:topic:fedora.apim.update}16:18
<acoburn>whikloj: you have to configure the activemq component like so: https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/blob/master/fcrepo-reindexing/src/main/resources/OSGI-INF/blueprint/blueprint.xml#L26-L2816:19
<whikloj>acoburn: sorry I have that in the applicationContext.xml https://gist.github.com/whikloj/9b4c2edf34f7a07d399816:20
<acoburn>whikloj: so what are the errors?16:21
whikloj: and what is the value of jms.brokerUrl?16:22
<whikloj>acoburn: essentially it times out waiting for a reply.16:23
acoburn: https://gist.github.com/whikloj/40396c4f0fee04b06436
acoburn: I stole this ^^ from fcrepo-camel-toolbox
<acoburn>whikloj: it looks familiar ;-)16:24
<whikloj>acoburn: it seems to create the TextMessage correctly, but I am not sure if it is not connecting to the broker or maybe I shouldn't be expecting a reply.16:25
acoburn: downloading hawtio now, just wondered if it might be something obvious.16:26
<acoburn>whikloj: do you have a listener on that activemq:topic?
<whikloj>acoburn: I don't, I am trying to fool the old GSearch to reindex an object but faking a Fedora update message. So I am watching the Gsearch log.16:27
<acoburn>here's a simple listener: https://www.ats.amherst.edu/~acoburn/listener.py
you'll need to update the configuration a bit (change the port, and the topic name)16:28
you can install with: $ pip install stomp.py
and run with $ python listener.py
whikloj: does gsearch rely on the message body or the message headers? (you're not passing in any message headers)16:31
<whikloj>acoburn: not sure to tell you the truth.
<acoburn>whikloj: the fedora3 jms stream also included the headers "pid" and "methodName"16:33
whikloj: without knowing anything about the gsearch code, you might start by adding those headers to your route16:34
whikloj: .addHeader("methodName", "modifyObject")16:35
whikloj: I mean .setHeader("methodName", constant("modifyObject"))16:36
<whikloj>acoburn: yeah I'm just looking at the AtomAPIMMessage class
<acoburn>whikloj: from the looks of that class, it seems to use the message body and not the headers16:43
<whikloj>acoburn: https://github.com/fcrepo3/fcrepo/blob/9c41b09a21a3a2615791fa4c614095a14512940f/fcrepo-server/src/main/java/org/fcrepo/server/messaging/MessagingImpl.java#L71-L83
acoburn: but also sets properties as you said
<acoburn>whikloj: yes, but gsearch only uses the body: https://github.com/fcrepo3/gsearch/blob/master/FedoraGenericSearch/src/java/dk/defxws/fedoragsearch/server/UpdateListener.java#L166-L16916:44
whikloj: and here's the defn of the AtomApimMessage class: https://github.com/mediashelf/fedora-client/blob/master/fedora-client-messaging/src/main/java/com/yourmediashelf/fedora/client/messaging/AtomApimMessage.java#L106-L12016:45
<whikloj>acoburn: that makes sense16:47
<acoburn>whikloj: have you turned gsearch logging up to debug to verify that it receives the messages?16:52
<whikloj>acoburn: no, I'm playing with your listener right now to see if I can catch anything with it.
acoburn: ok message is coming through, no headers all body. Perhaps I'll set those headers and crank up gsearch logging. thanks for the help.16:55
<acoburn>whikloj: good luck!16:56
<whikloj>acoburn: it works, stupid me was using "uofm:jared" as a PID. Once I put in a valid one it worked perfectly.16:58
<acoburn>whikloj: nice :-)17:04
<whikloj>acoburn: thank you again
* whikloj leaves
* jmignault leaves17:10
* tolloid leaves17:11
* acoburn leaves17:26
* jrgriffiniii leaves17:35
* github-ff joins18:05
[fcrepo-webapp-plus] awoods pushed 1 new commit to master: http://git.io/vqyav
fcrepo-webapp-plus/master eccc558 Andrew Woods: Update README.md
* github-ff leaves
* travis-ci joins18:11
fcrepo4-labs/fcrepo-webapp-plus#50 (master - eccc558 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-webapp-plus/compare/984c9a021bac...eccc558e5245
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo-webapp-plus/builds/70298941
* travis-ci leaves
* jrgriffiniii joins18:34
* jrgriffiniii leaves18:41
* ksclarke leaves18:45
* ksclarke joins19:13
* ksclarke leaves19:17
* ksclarke joins19:32
* awoods_ joins19:39
* awoods leaves19:42
* ksclarke leaves20:01
* awoods_ joins20:02
* awoods leaves20:06
* awoods__ joins20:07
* github-ff joins20:09
[fcrepo-camel] acoburn opened pull request #77: added links for 4.2.0 (gh-pages...fcrepo-1623) http://git.io/vqStS
* github-ff leaves
* awoods joins
* awoods_ leaves20:11
* awoods__ leaves20:12
* github-ff joins20:18
[fcrepo-camel] awoods closed pull request #77: added links for 4.2.0 (gh-pages...fcrepo-1623) http://git.io/vqStS
* github-ff leaves
* ksclarke joins20:19
* jrgriffiniii joins20:28
* jrgriffiniii leaves20:38
* awoods_ joins20:46
* awoods__ joins20:48
* awoods leaves20:50
* awoods_ leaves20:51
* awoods_ joins21:05
* awoods__ leaves21:08
* awead leaves21:32
* awead joins21:37
* jgpawletko leaves21:43
* jrgriffiniii joins21:44
* jrgriffiniii leaves21:57
* awoods__ joins21:59
* awoods_ leaves22:02
* awoods__ leaves22:14
* jrgriffiniii joins22:56
* jrgriffiniii leaves23:05
* awead leaves23:10

Generated by Sualtam