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

Allow override of JMS baseUrl ... #774

Closed
wants to merge 4 commits into from
Closed

Conversation

whikloj
Copy link
Collaborator

@whikloj whikloj commented Apr 17, 2015

...with system property fcrepo.jms.baseUrl with format host:port

Added Unit test

Addresses FCREPO-1259

if (propBaseURL.length() > 0) {
if (propBaseURL.indexOf(':') > -1) {
final String[] parts = propBaseURL.split(":");
return uriInfo.getBaseUriBuilder().clone().host(parts[0]).port(Integer.valueOf(parts[1])).toString();
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't parts[0] going to be "http" here?

Copy link
Contributor

Choose a reason for hiding this comment

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

could also be "https"

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, but not the hostname, which I would expect to be in parts[1]

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, I see what happened there. My expectation was host is host, and not protocol. But that could definitely depend on interpretation. I'll put in a check.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Before I do this, is it your expectation that if I am running Fcrepo at "http://blah.com:8080" I might want the JMS messages to reference "https://blah.com:8443"? I couldn't think of why you would, but now I'm thinking it might be easier to pass the whole property to UriBuilder.uri(String s)?

} else {
return uriInfo.getBaseUriBuilder().clone().scheme(parts[0]).host(parts[1].substring(2)).toString();
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the point of breaking up this URI and then reassembling it?

Copy link
Contributor

Choose a reason for hiding this comment

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

IMHO, we should return the fcrepo.jms.baseUrl as-is without parsing and rebuilding. The use case for this is users wanting to override the default generated baseURL, and I would expect it to be very frustrating if the value was altered in any way.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Honestly at this point, I'm not sure there is any point. I can replace it all with:
return uriInfo.getBaseUriBuilder().clone().uri(propBaseURL).toString();

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, brother.

protected String getBaseUrlProperty() {
final String propBaseURL = System.getProperty("fcrepo.jms.baseUrl", "");
if (propBaseURL.length() > 0 && propBaseURL.startsWith("http")) {
return uriInfo.getBaseUriBuilder().clone().uri(propBaseURL).toString();
Copy link
Contributor

Choose a reason for hiding this comment

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

Why the invocation of clone()?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Possibly a mistaken understanding of the UriBuilder, but my assumption from the Javadocs and the usage in IdentiferConverter was to preserve the original state. Perhaps its not needed?

@awoods
Copy link

awoods commented Apr 17, 2015

Resolved with: 8779cf0

@awoods awoods closed this Apr 17, 2015
@whikloj whikloj deleted the FCREPO-1259 branch October 22, 2016 02:22
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

5 participants