Rich plugin usage #110
Closed
Rich plugin usage #110
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Obviously, this is a breaking API change. The reason this method is
being removed is that we would like RichPlugin to implement
BasicDetails, which has its own get(String) method with an incompatible
return type. So the Gateway method ultimately has to go.
Upon consideration, the Gateway#get(String) method was not very useful
anyway: what would you do with the (weakly typed) Service once you got
it back? You'd have to cast it to make any calls to its service API
specifically, which would necessitate a compile-time dependency on the
service's artifact, which would obviate the need to call
Gateway#get(String) in the first place -- in that case, you could just
call Gateway#get(Class) instead.
I suppose there is a _rare_ case where you'd want to check for a service
at runtime only, without an explicit compile-time dependency, and then
invoke one or more of its methods via reflection. But this is certainly
not an encouraged practice, so let's not have the Gateway make it easy.
It is still easy enough to do anyway:
Service s = myGateway.context().service("MyService");
Now, all rich plugins are Identifiable, Locatable, Versioned, and know their own BasicDetails (which comes from their linked PluginInfo). This makes it easier to enable tracking of usage statistics relating to a particular kind of plugin.
This method makes it easy for subclasses to register usage of their plugins in whatever way they see fit.
It is very straightforward when a Handler or Wrapper plugin is being "used": the service returns the appropriate and specifically requested Handler or Wrapper instance for the task at hand. So let's count it in our usage statistics when that happens!
All RichPlugins are now versioned.
It now more closely resembles AbstractUIDetails. However, we may want to factor this sort of logic into a shared method somewhere, since it currently is not very DRY.
|
This branch will need more scrutiny. The |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MERGE ONLY IN CONCERT WITH THE OTHER 3.0.0 BRANCHES.
This makes all
RichPlugintypes implement the interfaces necessary for tracking their usage, and in particular tracks all uses of "handler" and "wrapper" plugin types.Unfortunately, to do this, a method had to be removed from the
Gatewayinterface, which breaks backwards compatibility. So this PR will be part of SJC3.