Am 15.09.19 um 11:03 schrieb Mark Thomas: > On 14/09/2019 20:01, Felix Schumacher wrote: >> Am 12.09.19 um 22:40 schrieb ma...@apache.org: >>> This is an automated email from the ASF dual-hosted git repository. >>> >>> markt pushed a commit to branch master >>> in repository https://gitbox.apache.org/repos/asf/tomcat.git >>> >>> commit cae17a52598393680952aa21cee0e27b13a73455 >>> Author: Mark Thomas <ma...@apache.org> >>> AuthorDate: Thu Sep 12 15:31:26 2019 +0100 >>> >>> Additional changes required to enable EnvironmentPropertySource >>> --- >>> .../org/apache/tomcat/util/IntrospectionUtils.java | 49 >>> ++++++++++++++++++++-- >>> java/org/apache/tomcat/util/digester/Digester.java | 33 ++++++++++----- >>> webapps/docs/changelog.xml | 4 +- >>> 3 files changed, 69 insertions(+), 17 deletions(-) >>> >>> diff --git a/java/org/apache/tomcat/util/IntrospectionUtils.java >>> b/java/org/apache/tomcat/util/IntrospectionUtils.java >>> index 3ffa702..f6ac737 100644 >>> --- a/java/org/apache/tomcat/util/IntrospectionUtils.java >>> +++ b/java/org/apache/tomcat/util/IntrospectionUtils.java >>> @@ -476,9 +499,27 @@ public final class IntrospectionUtils { >>> // This provides a layer of abstraction >>> >>> public static interface PropertySource { >>> - >>> public String getProperty(String key); >>> - >>> } >>> >>> + >>> + public static interface PropertySourceSecure extends PropertySource { >> I think a better name would be SecurePropertySource or >> ClassloaderAwarePropertySource. The thing that it represents should be >> at the end of the name IMHO. > Fair enough. I prefer "SecurePropertySource" so I'll go with that before > I tag. > >> At work I prototyped a similar approach and introduced a >> NamespaceAwarePropertySource. It is basically an interface that has a >> getNamespace() method that returns a prefix for the keys. I think that >> it would be nice if these two approaches. > Sorry, I'm not quite understanding how this works or the use case it is > trying to address. Could you provide a simple example?
A namespaced PropertySource would look like this interface NamespacedPropertySource extends PropertySource { String getNamespace(); // or getPrefix() } Those PropertySources would be registered by the service loader approach into a map<String, PropertySource> with their namespace as a key. If a property is looked up with a key, for example "env.hostname", that key would be split into the namespace (or prefix) and the actual key for the source. The SecureProperty from the above map (found by the namespace) would then be asked to resolve the property. In this setup, the multiplexer that is looking up the source could check with the security manager whether access to the key is allowed and thus freeing the implementer of the NamespacedProperty of doing this work. class MultiPropertySource implements SecurePropertySource { // not a good name Map<String, PropertySource> sources = findThemByServiceLoader(); String getProperty(String key, ClassLoader classLoader) { String[] nameComponents = key.split(":", 2); // uses a colon for separation as split uses a regex and a dot is a special char in that context String namespace = nameComponents[0]; String realKey = nameComponents[1]; if (!checkSecurity(namespace, realKey, classLoader)) { // this would do the security check return null; } SecurePropertySource source = sources.get(namespace); return source.getProperty(realKey); } } Does this make sense to you? Felix > >> My prototype didn't try to >> call a security manager, but with this commit it would be easy to add. >> >> On the other hand it uses a ServiceLoader approach to automatically find >> all NamespaceAwarePropertySources. Do you think this would be a good >> addition for Tomcat? > There is an entry in TOMCAT-NEXT around reducing the use of system > properties. A ServiceLoader approach may be a good solution for some of > those. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org