Closed acoburn closed 7 years ago
Please pull the trigger on a merge when you are satisfied, @birkland .
@birkland I addressed the concern about the use of FCREPO_IDENTIFIER
in the latest commit. If you are satisfied, feel free to merge.
Great, looks good. I don't think I have write permissions to fcrepo-camel-toolbox; if you can do that, I'd be happy to merge.
Resolves: https://jira.duraspace.org/browse/FCREPO-2333
The major change here is that the
fcrepo-ldpath
component's interface changes. The existing behavior is such that requests map a path like thishttp://localhost:7777/ldpath/some/fedora/resource
to a particular fedora resource (e.g.http://localhost:8080/fcrepo/rest/some/fedora/resource
).This PR changes that to be more generic:
http://localhost:7777/ldpath?context=http://localhost:8080/fcrepo/rest/some/fedora/resource
This change also makes the ldpath component more general such that requests can start from any linked data resource, not just Fedora resources. This change simplifies the code in both
fcrepo-ldpath
andfcrepo-indexing-solr
, making it unnecessary to rely on the JMS headers as outlined above.The other change relates to the serialization tool. The existing implementation uses the
org.fcrepo.jms.identifier
value to set the location of a filename. With this PR, the module uses the resource path, sohttp://localhost:8080/fcrepo/rest/path/to/resource
would map to a file at${configuredBaseDir}/fcrepo/rest/path/to/resource
(by way of comparison, the current behavior would store that resource at${configuredBaseDir}/path/to/resource
.