Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* ksclarke leaves01:24
* github-ff joins08:41
[tuque] yqjiang synchronize pull request #5: Fedora4 (fedora4...fedora4) http://git.io/9ENurg
* github-ff leaves
* jay joins08:56
<pivotal-bot____>Yuqing Jiang finished "generate dc in tuque" https://www.pivotaltracker.com/story/show/5503880609:02
* mikeAtUVa joins09:11
* gregjansen joins09:14
<awoods>mikeAtUVa: As a note, the "3->4 Upgrade" project/module will likely not reside within the main fcrepo4 baseline, but rather as an external git project.09:17
<mikeAtUVa>That makes sense.09:18
<awoods>gregjansen: What was the plan with fcrepo-copy-federation?09:27
<gregjansen>aha, that was a project to explore copying federated nodes into modeshape storage
let me look at it09:28
<awoods>gregjansen: And when was it expected that the sequencer would be invoked?
<gregjansen>I had it configured to listen for new nodes under a certain path.. so it would turn a connector into a kind of ingest drop box09:29
the sequencer only does half the job as currently written.. it will copy the nodes, but any binary properties that are large still refer to the projected binaries
<awoods>gregjansen: ...and the sequencer would not act on any pre-existing content in the federation? only content that was added new?09:30
<gregjansen>IOW the workspace copy command seems to make references for binary content, which is true to form for modeshape only keeping one copy of unique binaries.. however in this case the binary is coming from a connector
I think that is how sequencers work.. It is triggered by property change event.09:31
(Which I'm not sure ever worked on bag it content, which was the connector used in tests)
awoods: this the path expression for the sequencer firing up: "default:/bagitLoadingDock/(*)[@jcr:created] => default:/objects/\$1"09:32
<awoods>gregjansen: Thanks.09:33
gregjansen: I was wondering if there was overlap with a potential need for "copy" in the 3->4 upgrade scenario.
<gregjansen>awoods: I think it is the same problem.. If you project f3 nodes, then you can copy them out to f4 storage in this 2-stage process.09:34
<awoods>gregjansen: Although I am not sure a sequencer will do the trick...
gregjansen: ...since we would be projecting over existing content.09:35
<gregjansen>awoods: an approach I mentioned to nigel yesterday was to project f3 using the REST API instead of f3 storage.. that way you cover many more versions and configs for f3
<awoods>gregjansen: I believe mikeAtUVa is exploring both options: connector via REST-API, and connector via f3 filesystem.09:36
<gregjansen>awoods: A sequencer is a weird fit. You might rather fire up an ordinary copy process when you want it.
<awoods>gregjansen: agreed. Although it would be nice to have an elegant copy process.09:37
<gregjansen>awoods: I like it. FWIW, a two stage process would be nice either way you trigger it.. Copying all the metadata into mode storage will give you effective access while the longer process of copying all the data takes place in the background..
awoods: for instance, your f4 indexing, solr and triple store might complete well before the binaries finish moving09:38
<awoods>gregjansen: That could be a plus.09:39
<gregjansen>awoods: agreed
<awoods>gregjansen: Is all well on the auth front?
<gregjansen>awoods: I had late afternoon meetings yesterday, but I did manage to exercise the PEP and find my next problem in an IT09:40
<awoods>gregjansen: Make some tickets...09:41
gregjansen: I may have some time to chip in.
<gregjansen>awoods: I have inserted my authorization provider into the modeshape security checks, but even though my PEP says it granted perm, it is still denied by the access control manager in the end.. Which is something I have been unable to find documentation for..09:42
awoods: seems to be using mode 1920 ACLs in addition to my authz provider and I've been digging in mode source code09:43
<awoods>gregjansen: The double-checking is discussed to some degree in this thread: https://github.com/ModeShape/modeshape/pull/84909:44
<gregjansen>awoods: good old 849, I was hoping that release would come with a doc.. :)
<gregjansen>awoods: this was my hope " if no ancestor has any ACLs, then the node can be accessed as usual. "
<awoods>gregjansen: We are on 3.4
<gregjansen>awoods: yup, I am double checking that my local jars still reflect that..09:47
awoods: they do, all is 3.4
awoods: so in debug I can see that (1) (2) (3) step authz hasPermission() happening.. my access is consistently denied by (3). it will not let my user add a node to the root node.09:49
awoods: my PEP is invoked at step (2) and says "yes" you have permission
* osmandin joins
<gregjansen>awoods: I am adding logging to inspect the root node for ACLs09:50
<awoods>gregjansen: As a side note, have you been able to make (2) say "no"?
<gregjansen>quite easily, since my authz provider makes a call to a mocked PEP at this point09:51
<awoods>gregjansen: Your IDE does not support a debugger, versus logging?
<gregjansen>awoods: so I am telling it what to say right in my test, which was meant to find exactly this kind of issue
<awoods>gregjansen: success
<gregjansen>awoods: I guess I could use the debugger pontentially09:52
* ksclarke joins
<awoods>gregjansen: I know you are an eclipse guy, but Intellij has strong support.
<gregjansen>awoods: eclipse debugger can look at all the variables in detail, but I should probably try intellij at some point09:53
<awoods>gregjansen: Fedora developers have a free license.09:54
<gregjansen>awoods: on a positive note, this test was meant to uncover exactly this kind of issue, so that's a form of success..
<awoods>gregjansen: success, exactly09:55
<pivotal-bot____>Mike Durbin started "Read-only federation over Fedora3 objects/datastreams" https://www.pivotaltracker.com/story/show/5576913210:04
<gregjansen>awoods: the default ACL is being used on the root node (in absence of an explicit ACL) and it only allows read and readACL privs to everyone... that is the problem as it stands. I am sort of surprised that the rest of our test code works against 3.4..
<awoods>gregjansen: Interesting. When I spin up fedora and create a top-level node... how is that able to work?10:06
<gregjansen>awoods: exactly, is it b/c I have an authz provider configured? I will have to disable it and test this.10:09
<awoods>gregjansen: Are you using the default repository.json?
gregjansen: There is a security element there.10:10
<gregjansen>more or less, I have the addition of a custom authn provider, which then creates a security context that can do custom authz provider
I will compare
our other tests probably work b/c they use anonymous logins which have the admin role10:11
* ermadmix joins
<pivotal-bot____>Mike Durbin added comment: "I've documented a few possible approaches and done a cursory examination of the relevant bits of code to inf..." https://www.pivotaltracker.com/story/show/5590857210:16
Mike Durbin finished "Evaluate and document feasibility and pitfalls associated with various techniques of federating over fedora 3 cont..." https://www.pivotaltracker.com/story/show/5590857210:17
Andrew Woods added comment: "Looks good. It appears your conclusion slightly leans towards the federation over F3-HTTP... which is the i..." https://www.pivotaltracker.com/story/show/5590857210:30
Andrew Woods accepted "Evaluate and document feasibility and pitfalls associated with various techniques of federating over fedora 3 con..." https://www.pivotaltracker.com/story/show/5590857210:31
<gregjansen>awoods: fwiw, I now know that my users (supplied by the custom authn) did not have adequate roles according to the docs. So I will try again, giving the user "read" and "write" roles.10:37
* github-ff joins10:38
[tuque] yqjiang synchronize pull request #5: Fedora4 (fedora4...fedora4) http://git.io/9ENurg
* github-ff leaves
<awoods>gregjansen: thanks. Try to keep in mind if there is a way to break this work into increasingly smaller pieces.10:39
<pivotal-bot____>Mike Durbin added "Document UVa's fedora 3 resource index queries" https://www.pivotaltracker.com/story/show/55980902
Mike Durbin started "Document UVa's fedora 3 resource index queries" https://www.pivotaltracker.com/story/show/5598090210:40
Mike Durbin added comment: "The major unique queries that are in use at UVa are documented here: ""10:41
https://wiki.duraspace.org/display/FF/U..." https://www.pivotaltracker.com/story/show/55980902
Mike Durbin accepted "Document UVa's fedora 3 resource index queries" https://www.pivotaltracker.com/story/show/55980902
* github-ff joins10:44
[tuque] yqjiang synchronize pull request #5: Fedora4 (fedora4...fedora4) http://git.io/9ENurg
* github-ff leaves
<awoods>osmandin: Where is the "test branch" you reference on this wiki page (at the bottom in the "Links" section): https://wiki.duraspace.org/display/FF/Test+-+Backup+and+Restore10:47
* jay leaves10:49
* jay joins10:56
* jongibson joins
<gregjansen>awoods: Turns out I rediscovered a 3.4 bug, https://community.jboss.org/thread/23166011:01
<awoods>gregjansen: coming?
<pivotal-bot____>Yuqing Jiang added comment: "https://github.com/yqjiang/tuque/commit/e5f673919b5d559cb2f3bce6e57375cdecdafce011:07
https://github.com/yqjian..." https://www.pivotaltracker.com/story/show/55038806
<osmandin>awoods: Actually, I found out that the tests in my branch were more or less the same as fcrepo/backup (FedoraBackupIT.java). So, I can remove the reference in wiki, or I can push up my test branch if you prefer11:21
<pivotal-bot____>Nigel Banks added "Create a pull request to ModeShape adding the FileSystemMonitor class to their FileSystemConnector code." https://www.pivotaltracker.com/story/show/5598533411:27
Nigel Banks edited "Create a pull request to ModeShape adding the FileSystemMonitor class to their FileSystemConnector code." https://www.pivotaltracker.com/story/show/55985334
Mike Durbin edited "Write a proof of concept read-only implementation of a federation over fedora 3 content" https://www.pivotaltracker.com/story/show/55769132
Nigel Banks started "Create a pull request to ModeShape adding the FileSystemMonitor class to their FileSystemConnector code." https://www.pivotaltracker.com/story/show/5598533411:28
<awoods>osmandin: maybe in the wiki just reference the test code in fcrepo/backup11:36
gregjansen: As is the case with most of the integration tests (except fcrepo-storage-policy), please put the IT tests in an "integration" java sub-package.11:38
<osmandin>awoods: changed wiki ref to point to fcrepo/backup11:40
<awoods>osmandin, you're the man.11:41
<pivotal-bot____>Eric James started "Setup basic FilesystemConnector" https://www.pivotaltracker.com/story/show/5581250211:47
Andrew Woods accepted "fcrepo-jms LegacyMethod hardcodes baseUrl" https://www.pivotaltracker.com/story/show/5260819711:52
Eric James accepted "Setup basic FilesystemConnector" https://www.pivotaltracker.com/story/show/5581250211:58
Eric James started "Identify bottlenecks" https://www.pivotaltracker.com/story/show/55719822
* jongibson leaves12:07
<gregjansen>awoods: okay, I will make an integration package for my tests12:08
* jongibson joins12:21
<ermadmix>Clicking on fcr:fixity for a federated node outputs:12:41
DEBUG 10:50:36.684 (LowLevelStorageService) Checking fixity for resource in cache store org.fcrepo.kernel.utils.impl.CacheStoreEntry@d630913c12:42
DEBUG 10:50:36.685 (StoreChunkInputStream) Read chunk 270b22170ea38d4fd4e909ed4c5c9627fac3ad17-data-0 from cache org.infinispan.loaders.file.FileCacheStore@28a38466
TRACE 10:50:36.685 (StoreChunkInputStream) Unable to read chunk 270b22170ea38d4fd4e909ed4c5c9627fac3ad17-data-0
DEBUG 10:50:36.686 (LowLevelCacheEntry) Got Fixity: checksum: urn:sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 / 0
ERROR 10:50:36.687 (DatastreamService) ALL COPIES OF /objects/1668.10.13.00_page2.tif HAVE FAILED FIXITY CHECKS.
And no matter what the node on the browser page has the same fedora-internal:computedChecksum urn:sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709
Is this a known bug?
<awoods>ermadmix: Quite honestly, I have not looked into the alpha fixity work. Please create a ticket as a bug, and we can take a deeper look.12:45
cbeer or barmintor may have a comment.12:49
<barmintor>the last time I looked at that stuff the fixity app worked12:50
is that the sha1 hash for an empty array?12:51
(checked) it is
the fixity app isn't getting any content for the checksums
<awoods>are you there, ermadmix?12:53
* mbklein joins12:59
* nbanks leaves13:00
<mbklein>With fedora 3.6.2, is there any way to run fedora-rebuild.sh without having to answer prompts? I want it to rebuild the DB (answer 2 at the first prompt, then 1 from the second), but I'm running from a maintenance script.
<barmintor>mbklein: Unfortunately not13:01
<barmintor>you know what they say about patches.
<mbklein>barmintor++ yeah, yeah.
Maybe I'll write an expect script. :)
* nbanks joins13:02
* osmandin leaves
<mikeAtUVa>I hate to ask questions that I could probably answer with google, but it might save a bit of time if any of you could help...13:46
What are the constraints on id values for nodes in ModeShape?
Do they have to be globally unique? Are there banned characters?13:47
* osmandin joins13:54
<pivotal-bot____>Osman Din added comment: "Initial development : https://github.com/osmandin/fcrepo4/commit/fd2ffb856e209802bcd05caba5526a07601d8a67" https://www.pivotaltracker.com/story/show/5463899813:57
Osman Din finished "Include object path in JMS messages" https://www.pivotaltracker.com/story/show/54638998
<awoods>mikeAtUVa: I believe these are the constraints: http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.2.2%20Local%20Names14:01
* jay leaves14:14
* jongibson leaves14:19
* ksclarke leaves14:31
<mbklein>barmintor: https://gist.github.com/mbklein/636964014:39
<barmintor>*sad trombone*14:40
<mbklein>It'll tide me over until Fedora 4. :)14:41
<barmintor>I think the 3.7.0-RC lets you parameterize the name of the rebuilder, but you'd still need a script like this to start the process
<ermadmix>Added ticket (is this the proper location?): https://jira.duraspace.org/browse/FCREPO-119814:44
fcr:fixity bug using the fcepo-fs-ms-federation-connecter
* nbanks leaves14:45
* ksclarke joins14:46
<pivotal-bot____>Eric James added "fcr:fixity bug using the fcepo-fs-ms-federation-connecter" https://www.pivotaltracker.com/story/show/5600291614:51
* github-ff joins14:53
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/fyjpuA
fcrepo4/master fd2ffb8 osmandin: Added node path information as a field in the atom message
* github-ff leaves
<pivotal-bot____>Andrew Woods delivered "Include object path in JMS messages" https://www.pivotaltracker.com/story/show/5463899814:54
Andrew Woods added comment: "Resolved with: http://git.io/fyjpuA" https://www.pivotaltracker.com/story/show/54638998
Andrew Woods accepted "Include object path in JMS messages" https://www.pivotaltracker.com/story/show/54638998
* travis-ci joins15:11
[travis-ci] futures/fcrepo4#973 (master - fd2ffb8 : osmandin): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/619a8b484fc6...fd2ffb856e20
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/10725366
* travis-ci leaves
* jongibson joins15:14
<gregjansen>anybody know if you can just use the @Autowired annotation to inject spring dependencies into ModeShape created instances?"15:18
* mbklein leaves15:24
<awoods>gregjansen: If those ModeShape created instances are managed by Spring, I would certainly think you could.15:25
bbi ~15, lunch
<gregjansen>awoods: testing it now, seems to work for the autowired repo property, which i see in other source..15:26
* jay joins15:27
<bljenkins>Project fcrepo-fixity-corrupter build #243: SUCCESS in 2 min 36 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/243/15:29
Project fcrepo-kitchen-sink build #511: SUCCESS in 8 min 3 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/511/15:42
<awoods>gregjansen: any luck?15:53
<gregjansen>awoods: nope, @Autowired doesn't get honored in my authentication provider, which is created via repository.json, not a spring context file.15:54
<awoods>gregjansen: That would make sense then.15:55
<gregjansen>awoods: having trouble passing dependencies without using a singleton factory pattern
awoods: which smells
awoods: let me try something here15:56
<awoods>gregjansen: Is this for your integration tests? or are you trying to plug your auth-provider into Modeshape in the production code?
<gregjansen>awoods: it is also for prod.. in prod I'd like the Mode created object to obtain a spring configured PEP15:57
awoods: hate to make it bean context aware..15:58
<awoods>gregjansen: What is Mode's plugin framework expecting?
gregjansen: Is there a suggested way within Mode to do such wiring?
<gregjansen>awoods: well, this particular config expects a classname that implements AuthenticationProvider15:59
awoods: no idea, but I will ask on #modeshape
awoods: i suspect that my class will need to be aware of the bean context16:01
<awoods>gregjansen: I wonder if there is any way of leveraging ModeShapeRepositoryFactoryBean.java16:06
in kernel
<gregjansen>awoods: I know you can make an object context aware if it was created by Spring, but this object was created by the modeshape repository, which was in turn created by that bean..16:08
<awoods>gregjansen: What is the modeshape class in question?16:09
<gregjansen>awoods: modeshape is instantiating my class as part of the repository configuration. I think there is a MODE class that represents the current configuration, so that might be it. I do not know specifically. Pretty sure that normal injection cannot work for this object. It will likely have to hunt down the application context and request the bean it needs.16:12
<awoods>gregjansen: Or there may be a setter.16:13
<gregjansen>awoods: que?
<awoods>gregjansen: I am suggesting there may be a non-spring way of setting/injecting your auth-provider into this mystery class.16:14
<gregjansen>awoods: okay, that would be neat. Overview: PEP bean is our interface and an extension point, with an implementation configured in the spring context. I want to inject the PEP bean into our authn provider, which is configured in repository.json and instantiated by modeshape. I suppose I can see how mode instantiates it by setting breakpoint on the constructor.. brb16:18
awoods: authn provider in repository.json is created via reflection in this class org.infinispan.util.Util.getInstance() 18116:23
It first looks for a static factory method of getInstance() and then invokes the default constructor.
<awoods>gregjansen: There are two classes at play: the Modeshape auth-provider and your pep, correct?16:25
<gregjansen>awoods: well, the third and fourth things in play are spring's application context and the modeshape application..16:26
<awoods>gregjansen: sure16:27
<gregjansen>awoods: the auth provider is a minion of modeshape, while the PEP is a minion of spring
<awoods>gregjansen: What I am wondering is how modeshape expects to have custom pep impls plugged in.
<gregjansen>modeshape only defines the authprovider interface. the PEP is my own creation, such that Fedora implementors can configure their own PEPs. It is also the home of methods that will filter the search results.16:29
<awoods>gregjansen: So your impl of the auth-provider interface is the object that is instantiated via reflection from the repository.json?16:31
<gregjansen>awoods: yes
awoods: yup. the repo is instantiated by the spring context, but as you'd expect, the objects instantiated by the repo are not spring beans.16:32
<awoods>gregjansen: and you want that object (the pep) to be injected somewhere else, also?16:33
<gregjansen>yes, it will be needed to filter search results
awoods: so it will need to be injected wherever that ends up happening.. It may also have it's own dependencies. Currently the only implementation of the PEP is a mock. Another future implementation will come from the authz-xacml project.16:35
<awoods>gregjansen: You said the reflection first tries to make a call of getInstance().16:36
<gregjansen>yes, aha
awoods: So I could potentially have the authprovider itself be a singleton pattern, a bean created via spring16:37
awoods: That would make everything easier to inject, perhaps even neatly handling some of the cyclical stuff that might happen (authnprovider dependency on repo, for instance)16:38
<awoods>gregjansen: Yes, something like that. A factory class could be context aware and injected with the auth-provider bean.
<gregjansen>awoods: I will try it16:39
<awoods>gregjansen: good luck, and be safe.16:40
<gregjansen>awoods: safety third, andrew
<pivotal-bot____>Andrew Woods edited "fcr:fixity bug using the fcepo-fs-ms-federation-connecter" https://www.pivotaltracker.com/story/show/5600291616:53
Andrew Woods edited "fcr:fixity bug using the fcepo-fs-ms-federation-connecter" https://www.pivotaltracker.com/story/show/56002916
* jongibson leaves16:57
* osmandin leaves17:01
* ksclarke leaves17:05
* ksclarke joins17:06
<gregjansen>awoods: I got it, thx17:16
<awoods>gregjansen: awesome17:17
<pivotal-bot____>Eric James added comment: "DEBUG 16:06:10.007 (DatastreamService) Checking resource: /objects/WallSsamAniC.jpg/jcr:content17:20
DEBUG 16:06:1..." https://www.pivotaltracker.com/story/show/56002916
* jongibson joins17:23
<pivotal-bot____>Eric James started "fcr:fixity bug using the fcepo-fs-ms-federation-connecter" https://www.pivotaltracker.com/story/show/5600291617:27
<awoods>ermadmix: The fcepo-fs-ms-federation-connecter project is some test code that nbanks put together last sprint. I would not suggest basing future work on that project.17:28
ermadmix: Regarding the SHA-1 slowdowns, you should base your work on ModeShape's implementation: ./modeshape-jcr/src/main/java/org/modeshape/connector/filesystem/FileSystemConnector.java17:32
<pivotal-bot____>Eric James added "fcrepo-fs-ms-federation-connector fires multiple polling events while same large file is transferred" https://www.pivotaltracker.com/story/show/56015622
<awoods>I repeat, ermadmix, do not worry about the fcrepo-fs-ms-federation-connector.17:33
<pivotal-bot____>Eric James edited "fcrepo-fs-ms-federation-connector fires multiple polling events while same large file is transferred" https://www.pivotaltracker.com/story/show/56015622
<ermadmix>awoods: I hear you17:36
<awoods>ermadmix: thanks
ermadmix: Your first bug (relating to fixity) will likely apply to the modeshape fs-connector.17:37
ermadmix: nbanks has a ticket relating to pushing his fs-connector eventing work down to modeshape: https://www.pivotaltracker.com/story/show/5598533417:38
ermadmix: at which point your polling ticket will probably still apply (but to the updated modeshape impl)17:39
<ermadmix>awoods: ok17:45
<awoods>ermadmix: You can probably update your new tickets to reflect the modeshape impl instead of the fcepo-fs-ms-federation-connecter17:46
<ermadmix>awoods: ok. Should I select finish on https://www.pivotaltracker.com/s/projects/684825/stories/55985334 too?17:50
<awoods>ermadmix: hmm, I was thinking that ticket was for nbanks to clean up his changes, add some tests, then send a pull request to the ModeShape team.17:52
ermadmix: Are you working that?17:53
<ermadmix>awoods: Yeah, just comparing Nigel's connector with the modeshape one, they're very similar. The main change appears to be that FileSystemMonitor.17:55
<awoods>ermadmix: Yes, that is what nbanks indicated... but I gave up looking for details while weeding through the format diffs.17:56
ermadmix: The ticket you mention includes:17:59
- creating a JIRA item: https://issues.jboss.org/browse/MODE
- writing some unit tests for the updates
- submitting the pull request
ermadmix: Currently nbanks has that ticket assigned to him, so if you plan on doing any work on that ticket, you may want to make sure you are both not working it.18:00
ermadmix: Also, I believe the updates to the fs-connector are limited to issues of emitting events on federated content addition/deletion/modification...18:01
ermadmix: Since you are less concerned with events and more concerned with the general slowness of that connector, it may make the most sense for you to just move forward using the modeshape impl.
ermadmix: btw, modeshape's irc channel is #modeshape18:04
<ermadmix>awoods: wait, pull down the whole modeshape, or create a new module around the FileSystemConnector class?18:05
<awoods>ermadmix: Any changes that will eventually fold back into the modeshape baseline should be worked within the modeshape code.18:07
ermadmix: Are you planning on working the SHA-1 slowness issue? ie. https://www.pivotaltracker.com/story/show/5571982218:08
<pivotal-bot____>feature: Identify bottlenecks (started) / owner: Eric James
<ermadmix>awoods: ok, also it looks like, but I maybe wrong, that the slow SHA-1 happens within the fcrepo-kernel18:09
<awoods>ermadmix: that would be an interesting, and surprising, find
ermadmix: My understanding is that the slowness shows up when creating the sha-1, and in the fact that the sha-1 needs to be recreated repeatedly.18:11
ermadmix: we should identify in very specific terms where that happens, and where it currently needs to be re-happening.18:12
ermadmix: In doing that testing, please work off of the modeshape code... as opposed to the fcrepo-fs-ms-federation-connector code.
<ermadmix>awoods: yes exactly, i've identified when it is occuring on the fixity call, but am looking to see where the initial computation occurs after the connector finds the file.18:15
<awoods>ermadmix: Great.
<pivotal-bot____>Andrew Woods edited "fcr:fixity bug using the FileSystemConnector" https://www.pivotaltracker.com/story/show/5600291618:16
Andrew Woods edited "fcrepo-fs-ms-federation-connector fires multiple polling events while same large file is transferred" https://www.pivotaltracker.com/story/show/5601562218:17
* ksclarke leaves18:19
<pivotal-bot____>Andrew Woods edited "REFERENCE properties integrity" https://www.pivotaltracker.com/story/show/5109847318:21
* jongibson leaves18:28
* jay leaves
<ermadmix>awoods: so you're saying work all the connector changes entirely within modeshape, and then later create a module to plug the necessary pieces into fcrepo 4?18:30
<awoods>ermadmix: Ideally... we make changes entirely within modeshape, then send a pull-request to modeshape who then incorporates our "fixes".18:31
ermadmix: they have a pretty tight release cycle18:32
3.4 came out at the end of July
3.5 is supposed to come out in the next week or two.
<ermadmix>awoods: so modeshape is a repository that can be spun up like fcrepo 4, with it's own flavor of nodetypes and a similar REST API for adding content?18:34
<awoods>ermadmix: modeshape is a jcr implementation over which f4 is built.18:35
ermadmix: f4 is a very thin layer over the much larger modeshape jcr.
ermadmix: when you spin up f4, what you are really doing is spinning up modeshape with a f4 webapp wrapper.18:36
<ermadmix>awoods: Sorry tons of questions, it'll probably make more sense when I get it running. So is there a POM dependency on the modeshape build? How are modeshape changes pulled into fcrepo 4?18:44
<awoods>ermadmix: I appreciate the questions, it is helpful...
see the top-level pom.xml18:45
ermadmix: modeshape version: https://github.com/futures/fcrepo4/blob/master/pom.xml#L31
ermadmix: modeshape dependency: https://github.com/futures/fcrepo4/blob/master/pom.xml#L6318:46
ermadmix: modeshape project, if you want a local fork: https://github.com/ModeShape/modeshape18:47
ermadmix: simple instructions for building modeshape: https://github.com/ModeShape/modeshape#building-modeshape
<ermadmix>awoods: Ah, this is beginning to penetrate my head now. So you could point the org.modeshape.bom dependency in the fcrepo POM to a snapshot build of your modeshape18:51
<awoods>ermadmix: indeed
<ermadmix>awoods: great, see you in the AM18:53
* ermadmix leaves
<awoods>ermadmix: until then
* ksclarke joins20:29
* jonathangee leaves22:09
<pivotal-bot____>Andrew Woods edited "Backup a running repository" https://www.pivotaltracker.com/story/show/4610822923:44
Andrew Woods started "Backup a running repository" https://www.pivotaltracker.com/story/show/46108229

Generated by Sualtam