Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove dependency on fcrepo-mint #856

Closed
wants to merge 8 commits into from
Closed

remove dependency on fcrepo-mint #856

wants to merge 8 commits into from

Conversation

acoburn
Copy link
Contributor

@acoburn acoburn commented Jul 27, 2015

@escowles
Copy link
Contributor

This replicates the current behavior, but there's also an outstanding ticket for making the event ids configurable: https://jira.duraspace.org/browse/FCREPO-1568

Can we inject a Supplier, allowing us to wire up whatever kind of ID minter was desired? This would also remove the dependency on fcrepo-mint.

@ajs6f
Copy link
Contributor

ajs6f commented Jul 27, 2015

@escowles How do you want to use a Supplier? To supply a minter or to supply ids? Keep in mind that the basic Supplier type doesn't guarantee that you get the same thing each time, so supplying ids makes sense, but not supplying minters.

@escowles
Copy link
Contributor

@ajs6f I think it's stripping out the angle brackets: I meant to say Supplier<String> -- so a supplier of ids. I think it makes sense to use the same approach we're using for the main repository ids in https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/AbstractResource.java#L101

@ajs6f
Copy link
Contributor

ajs6f commented Jul 27, 2015

Holy crap! That's no good. Supplier doesn't guarantee that it won't give you the same thing over and over again. I hope I didn't do that in AbstractResource, but I think I might have absent-mindedly done that. If we want to use Supplier to produce a stream of unique things, we have to subtype it.

@escowles
Copy link
Contributor

So maybe we should add a PidMinter interface to fcrepo-kernel-api, and then inject fcrepo-mint instances in the fcrepo-http-commons repository config?

@ajs6f
Copy link
Contributor

ajs6f commented Jul 27, 2015

I don't think we should be as specific as PidMinter because we don't need to be. UniqueValueSupplier < Supplier would do. Then we could toast fcrepo-mint, right? We could offer a sidecar extension with the HTTP minter in it.

@escowles
Copy link
Contributor

UniqueValueSupplier<String> sounds good to me. Do you mean remove fcrepo-mint altogether? Do the UUID impls. get moved to fcrepo-kernel-modeshape or somewhere else?

@ajs6f
Copy link
Contributor

ajs6f commented Jul 27, 2015

Hey, man, this is Java 8! The UUID impl becomes default method bodies on the interface itself.

@@ -64,7 +61,7 @@
*/
public FedoraEvent(final Event e) {
checkArgument(e != null, "null cannot support a FedoraEvent!");
eventID = pidMinter.get();
eventID = randomUUID().toString();
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of hard-coding randomUUID() here, is there a reason why an UniqueValueSupplier<String>, as suggested in the code review comments, was not injected?

As a note, randomUUID().toString() is not equivalent to the previous UUIDPathMinter.get(). UUIDPathMinter provides a pairtree path with a UUID leaf element, whereas randomUUID simply provides a UUID.
The reason a full pairtree path is important is because the InternalAuditor uses the FedoraEvent#eventID as the identifier name at which an audit record resource is created:
https://github.com/fcrepo4-labs/fcrepo-audit/blob/master/src/main/java/org/fcrepo/audit/InternalAuditor.java#L211

The pairtree path provided by the UUIDPathMinter gets around the performance limitation of too many children of a given resource.

@acoburn
Copy link
Contributor Author

acoburn commented Aug 5, 2015

Updated PR with an injectable UniqueValueSupplier that subclasses Supplier<String>. Now neither of the fcrepo-kernel-* modules depend on fcrepo-mint.

* @author awoods
* @author acoburn
*/
public interface UniqueValueSupplier extends Supplier<String> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is way more specific than the name UniqueValueSupplier would imply. How about HierarchicalIdentifierSupplier < UniqueValueSupplier, with UniqueValueSupplier simply guaranteeing the uniqueness of results (no default impl) and HierarchicalIdentifierSupplier bringing the "minter that creates hierarchical IDs from a UUID" semantic with the default impl?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That works for me. I can add the additional interface.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right on.

@acoburn
Copy link
Contributor Author

acoburn commented Aug 5, 2015

added an interface for HierarchicalIdentifierSupplier < UniqueValueSupplier and moved the default impl to HierarchicalIdentifierSupplier, as @ajs6f suggested

import java.util.function.Supplier;

/**
* Unique value minter that creates unique IDs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now the wrong comment. This type just guarantees the uniqueness of its supplied values. It has nothing to do with minting IDs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment has been updated.

@awoods
Copy link

awoods commented Aug 6, 2015

This looks good. @escowles, you will note that the issue of injecting a pidMinter implementation into FedoraEvents is still outstanding, for the same reasons mentioned in the ticket:
https://jira.duraspace.org/browse/FCREPO-1568

If @escowles or @ajs6f are comfortable with this current PR as well, I will go ahead and squash/merge.

@escowles
Copy link
Contributor

escowles commented Aug 6, 2015

👍 -- looks like a good improvement, and we can figure out the injection separately.

@@ -54,8 +54,7 @@

private Set<Integer> eventTypes = new HashSet<>();
private Set<String> eventProperties = new HashSet<>();

private static final Supplier<String> pidMinter = new UUIDPathMinter();
private UniqueValueSupplier pidMinter = new DefaultPathMinter();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be static final?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you push one more commit with the addition of static we can close this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commit pushed (actually two). The nested classes had to be made static in order to use them on a static field.

@awoods
Copy link

awoods commented Aug 6, 2015

Resolved with: f7daf30

@awoods awoods closed this Aug 6, 2015
@acoburn acoburn deleted the fcrepo-1642 branch August 6, 2015 22:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants