[ https://issues.apache.org/jira/browse/GEODE-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645402#comment-15645402 ]
John Blum edited comment on GEODE-2083 at 11/7/16 8:48 PM: ----------------------------------------------------------- Note, I have (or rather, I am currently working on a) UC and example for this currently in the _Spring Data Geode_ RI ([Contacts Application|https://github.com/jxblum/contacts-application/tree/apache-geode]). I.e. I have figured out a way for users to still use the Geode {{security-manager}} (System) property, yet still allow them to configure the custom, application-specific, Geode-based {{SecurityManager}} implementation in a _Spring_ context. NOTE: you could still previously specify a {{SecurityManager}} using Geode's {{security-manager}} (System) property in _Spring_ configuration meta-data, you simply just could not "configure" the {{SecurityManager}} in the _Spring_ container since Geode itself took care of instantiating the {{SecurityManager}} object (using the {{SecurityService.getObjectOfTypeFromClassName(..)}}), which is less than ideal managed environment (_Spring_ or otherwise). Therefore, even [GEODE-2030] is *highly preferable* and *recommended* over and above this workaround/approach that I have come up to allow Apache Geode users also using SDG to use Geode {{security-manager}} (System) property, yet still configure the custom, application-specific {{SecurityManager}} in _Spring_. Hopefully, this all makes sense. Please ask if you have questions. In short though, [GEODE-2030] is the ultimate way to go (this is just another option to maximize flexibility in configuration). Thanks. was (Author: jblum): Note, I have (or rather, I am currently working on a) UC and example for this currently in the _Spring Data Geode_ RI ([Contacts Application|]). I.e. I have figured out a way for users to still use the Geode {{security-manager}} (System) property, yet still allow them to configure the custom, application-specific, Geode-based {{SecurityManager}} implementation in a _Spring_ context. NOTE: you could still previously specify a {{SecurityManager}} using Geode's {{security-manager}} (System) property in _Spring_ configuration meta-data, you simply just could not "configure" the {{SecurityManager}} in the _Spring_ container since Geode itself took care of instantiating the {{SecurityManager}} object (using the {{SecurityService.getObjectOfTypeFromClassName(..)}}), which is less than ideal managed environment (_Spring_ or otherwise). Therefore, even [GEODE-2030] is *highly preferable* and *recommended* over and above this workaround/approach that I have come up to allow Apache Geode users also using SDG to use Geode {{security-manager}} (System) property, yet still configure the custom, application-specific {{SecurityManager}} in _Spring_. Hopefully, this all makes sense. Please ask if you have questions. In short though, [GEODE-2030] is the ultimate way to go (this is just another option to maximize flexibility in configuration). Thanks. > Geode should call Declarable.init() when the SecurityManager component > implements Declarable. > --------------------------------------------------------------------------------------------- > > Key: GEODE-2083 > URL: https://issues.apache.org/jira/browse/GEODE-2083 > Project: Geode > Issue Type: Improvement > Reporter: John Blum > Assignee: Jinmei Liao > > Though, going forward (i.e. post {{1.0.0-incubating}}), there will be > multiple ways to configure Apache Geode's {{SecurityManager}} implementation > in effect, for instance, and most notably, [GEODE-2030], in addition to the > Geode {{security-manager}} (System) property, it would be highly valuable if > Apache Geode called > [Declarable.init()|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/cache/Declarable.html#init-java.util.Properties-] > on the custom, application-specific, Geode-based {{SecurityManager}} > implementation providing the custom, application-specific, Geode-based > [SecurityManager|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html] > implementation implemented the Geode > [Declarable|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/cache/Declarable.html] > interface. > This would be especially beneficial in situations where any post-construction > initialization logic needed to be invoked after the constructor, particularly > where the custom {{SecurityManager}} **this** reference needs to be accessed > by other classes/components in the {{init()}} method outside the > {{SecurityManager}} instance, which if done from/within a constructor during > construction would allow the **this** reference to escape (not good in a > multi-threaded environment). > This is also useful in situations where the GemFire {{security-manager}} > (System) property is still being used, as I suspect will be the case in some > situations/environments. > Tracing this through, the {{IntegratedSecurityService}} [delegates > |https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java#L335] > to the {{SecurityService.getObjectOfTypeFromClass(..)}} method. This > [method|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java#L67-L91] > (along with [similar supporting > methods|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java#L93-L129]) > could Introspect the class type and determine whether the custom, > application-specific, Geode-based {{SecurityManager}} implementation > implements the {{Declarable}} interface, invoking the {{init()}} method > before returning, if it does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)