Jenkins build is back to normal : Geode-nightly #1289

See

[DISCUSS] Streamline return value from RemoteQuery

Currently, geode-native's query::execute returns a shared_ptr and that pointer can be either ResultSet or StructSet. RemoteQuery::execute contains logical code to determine with QueryResults are greater than 0... We should look at removing this logic and only returning StructSets This allows remo

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1008 was SUCCESSFUL (with 2423 tests)

--- Spring Data GemFire > Nightly-ApacheGeode > #1008 was successful. --- Scheduled 2425 tests in total. https://build.spring.io/browse/SGF-NAG-1008/ -- Thi

Re: Proposal to support custom java.security.Provider

Exactly. I would have assumed #2 is bringing in default context if the user does not specific keystore and truststore. But unfortunately, the current code loads keystore from "{user.home}/.keystore" and so the proposal for this new property. We should probably disable loading from user.home if not

Re: Proposal to support custom java.security.Provider

Good question. We can allow a user to use current properties ssl-protocols and ssl-ciphers even when he wants to use the default security provider. Here would be a sequence of steps user can to answer: 1) Decide whether you want SSL? 2) Great. Do you want to use 2.a) default ssl context? or

Re: Proposal to support custom java.security.Provider

Doing #2 an #3 alone would fix GEODE-5338, right? We don't really need this new option. On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda wrote: > To make it clear about the different options: > > 1) if ssl-enabled-component & ssl-use-default-context is configured then > use default SSL context. >

Re: Proposal to support custom java.security.Provider

How does this work if the user wants to use the Trust/KeyStoreManager from the default security provider but still override other SSL properties such as ciphers or protocols? --Jens On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda wrote: > To make it clear about the different options: > > 1) if

Re: Proposal to support custom java.security.Provider

To make it clear about the different options: 1) if ssl-enabled-component & ssl-use-default-context is configured then use default SSL context. 2) if ssl-enabled-component & no other ssl-* properties are configured then configure SSL context by loading truststore and keystore from user home direct

Re: Proposal to support custom java.security.Provider

I missed follow up emails on this thread, for some reason my email client didn't show there were new messages on this thread. Like Jinmei said, a user has to first enable SSL by configuring ssl-enable-component and then chose between using default context or using specific keystore/trustsore (exist