-
Notifications
You must be signed in to change notification settings - Fork 11
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
Service discovery and registry implementation as per #14 #39
Conversation
I found an 11th hour issue with the ITs, so those were elided in this PR until that can be sorted out. |
public void init() { | ||
if (ontologyIRIsToLocation != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not to create more work, but what is the threading model? Is this thread safe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was (as the commit says) hack, but one that is not really impactful in practice. The hack is to allow the service to initialize (and be available in an OSGi sense) before the underlying container exists, in cases where the service is not configured to create its own container. Proper behaviour would be to fail all requests until the underlying registry is accessible, or fail to initialize in the first place (which is what the previous code did). This hack is temporary and will be resolved as part of the process to fix the ITs (which were redacted from this PR), but was necessary to get this PR out so that people can look at.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yes. This was just me being over-eager with comments!
Blueprint startup dependeny resolution required refactoring service discovery into its own module Tweaked service registry and extension registry impls to be OK with extensions that exposes services that are not described in the registry.
ITs fail using MacOS. May possibly be related to: https://groups.google.com/forum/#!msg/ops4j/1pBcHkBihzg/nRyHS3eDBAAJ/
- Closes fcrepo4-labs#39. Squashed commit of the following: commit 1d8077b Author: Aaron Birkland <apb@jhu.edu> Date: Mon Sep 12 14:23:34 2016 -0400 Revert ITs to failsafe 2.18.1 ITs fail using MacOS. May possibly be related to: https://groups.google.com/forum/#!msg/ops4j/1pBcHkBihzg/nRyHS3eDBAAJ/ commit 8b3e6c0 Author: Aaron Birkland <apb@jhu.edu> Date: Mon Sep 12 13:35:58 2016 -0400 Fix issue with failsafe VM termination error commit 5ab2133 Author: Aaron Birkland <apb@jhu.edu> Date: Fri Sep 9 20:16:59 2016 -0400 Add integration tests, and associated fixes Blueprint startup dependeny resolution required refactoring service discovery into its own module Tweaked service registry and extension registry impls to be OK with extensions that exposes services that are not described in the registry. commit d8cd008 Author: Aaron Birkland <apb@jhu.edu> Date: Thu Sep 1 10:41:08 2016 -0400 Use fedora 4.6.0 instead of 4.7-SNAPSHOT commit bdc8ef6 Author: Aaron Birkland <apb@jhu.edu> Date: Thu Sep 1 10:25:43 2016 -0400 fix/hack to assure initialization of ITs succeed commit 8ec6924 Author: Aaron Birkland <apb@jhu.edu> Date: Thu Sep 1 08:56:19 2016 -0400 Service discovery and registry implementation
Includes
Does not include: