Repository navigation
Conversation
There was a problem hiding this comment.
Can we remove these 1.7 compiler limitations? If not it is not a big deal, really, but it would be awesome if we could get rid of those as there are several features, such as default methods, that have been introduced in later JDK versions and that are not available in 1.7.
There was a problem hiding this comment.
We cannot: e.g. EAP adapters have 1.7 as mandatory JDK and all the dependencies including core have to adhere to this.
There was a problem hiding this comment.
I propose the introduction of this interface to allow the code that is initializing the instantiated factories to handle profiles only if the factory supports them, for efficiency reasons. But, of course, this can be changed.
There was a problem hiding this comment.
If the "inline" config is not empty, we assume it is trying to override one of the profiles with some area-specific needs, and thus we craft a componentId that conveys that.
There was a problem hiding this comment.
After I've finished implementing and testing this, I realized I can probably do without the "profile" scope altogether. So, instead of a config like this:
"mapStorage": {
"jpa-map-storage": {
"profile": {
"xyz": {
}
}
}
}
I could probably have just
"mapStorage": {
"jpa-map-storage": {
"xyz": {
}
}
}
There was a problem hiding this comment.
I think this is not a good way forward - the default configuration keys would be indistinguishable and might interfere with profile name.
There was a problem hiding this comment.
Good point, will stick with explicit profile scope scope.
There was a problem hiding this comment.
Thanks for providing an implementation here! Finally a way to iterate over the properties!
(resolve the comment)
There was a problem hiding this comment.
Just caught my eye - this implementation needs updating: keys do not support addAll, see https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html#keySet--
There was a problem hiding this comment.
Thanks, I've completely missed that one. Fixed.
There was a problem hiding this comment.
Where does this constant originate from?
There was a problem hiding this comment.
Right now it is coming from the SPI name. For authorization the different areas are not currently separated, they are all initialized to use the same storage factory. I don't know if we will change that in the future so that the different authz models will be configurable independently with respect to the storage factory, but for now they all share the same so I decided to use the SPI name.
There was a problem hiding this comment.
If we won't be splitting the different authz models, then perhaps a better name for the authz storage would be simply authorization.
Closes #10226