[
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)
