Re: SecurityService versus Cluster Config

I think we should revisit connecting to the distributed system with properties. In addition to what Kirk mentioned below, I think one of the big limitation of this is the inability to change properties on a running cluster. If there is a property that a user needs to change, they will have to

Re: SecurityService versus Cluster Config

The usage of CacheFactory#setSecurityManager (and setPostProcessor) is working as expected, both before and after my changes! The problem is that Cluster Config is requested during Cache initialization which means that any gemfire.properties stored in Cluster Config will not be used by

Re: SecurityService versus Cluster Config

I am not sure I follow everything that is happening here quite yet as I have not had time to go over this in more detail and digest it. But, I certainly hope that the security-manager property in Geode is not impacted by this in anyway since *Spring Data Geode* builds on this and, well, this

Re: SecurityService versus Cluster Config

Yeah I think we need #2 in the long run. Right now nearly all of the gemfire.properties are ignored if you use Cluster Config. The few gemfire.properties that are mutable by RuntimeDistributionConfigImpl will work when used in Cluster Config -- I believe all other gemfire.properties would be

Re: SecurityService versus Cluster Config

I've reverted my change on release/1.2.0. I'm currently planning to work on #1 on develop in the short term. On Fri, Jun 9, 2017 at 12:45 PM, Kirk Lund wrote: > The new changes for SecurityService don't work with Cluster Config. We > only had one test that would've failed but

Re: SecurityService versus Cluster Config

+1 for #2. It does seem more correct On 6/9/17 12:45, Kirk Lund wrote: The new changes for SecurityService don't work with Cluster Config. We only had one test that would've failed but it was annotated with @Ignore. The problem is this: The security-manager is a gemfire property and is now