[jira] [Updated] (GEODE-10310) Deactivate possibility to retry operation on partitioned region, when member containing primary bucket is restarted
[ https://issues.apache.org/jira/browse/GEODE-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-10310: - Affects Version/s: (was: 1.14.4) > Deactivate possibility to retry operation on partitioned region, when member > containing primary bucket is restarted > --- > > Key: GEODE-10310 > URL: https://issues.apache.org/jira/browse/GEODE-10310 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > In case client is putting data in partitioned region, and server is > restarted, add option not to retry operation for case when member with > primary bucket is restarted. In that case, operation will be aborted and > notified to client, instead of waiting for primary bucket to be reallocated. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10317) Range query with wildcard character(%) doing wrong comparison
Mario Kevo created GEODE-10317: -- Summary: Range query with wildcard character(%) doing wrong comparison Key: GEODE-10317 URL: https://issues.apache.org/jira/browse/GEODE-10317 Project: Geode Issue Type: Bug Components: querying Reporter: Mario Kevo The problem is when we are using the wildcard character(%), there are no results for the query as it is being turned in two comparisons, GE(>=) and LT(<), with AND junction. This will lead to the wrong output for these queries. The same thing happened for both queries when they had wildcard character % in the middle or at the end of the compared string. As discussed on the [dev list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], the correct way to use, like comparison with the string that contains wildcard character % at the end will be just GE(>=). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10317) Range query with wildcard character(%) doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10317: -- Labels: needsTriage (was: ) > Range query with wildcard character(%) doing wrong comparison > - > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10317) Range query with wildcard character(%) doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-10317: -- Assignee: Mario Kevo > Range query with wildcard character(%) doing wrong comparison > - > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: needsTriage > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10317) Range query with wildcard character doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-10317: --- Summary: Range query with wildcard character doing wrong comparison (was: Range query with wildcard character(%) doing wrong comparison) > Range query with wildcard character doing wrong comparison > -- > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: needsTriage > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10076) Fix string codepoint detection
[ https://issues.apache.org/jira/browse/GEODE-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538923#comment-17538923 ] ASF GitHub Bot commented on GEODE-10076: albertogpz opened a new pull request, #973: URL: https://github.com/apache/geode-native/pull/973 The Geode C++ native client library serializes strings of PdxSerializable objects with DSCode CacheableString. Nevertheless, the Java client, in order to serialize Strings, it analyzes them and different DSCodes are assigned depending on the contents (only ASCII vs not only ASCII chars) and length. In the native client, it's always set to CacheableString, whenever for example in the case of an ASCII string should be CacheableASCIIString. This can provoke that two objects with the same contents created one by the native client and the other by the Java classes return false when compared with the equals method. The writeString() method of the DataOutput() class of the Geode C++ native client library has been aligned with its counterpart in the Java library so that the serialization is the same in both cases. > Fix string codepoint detection > -- > > Key: GEODE-10076 > URL: https://issues.apache.org/jira/browse/GEODE-10076 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString > Also I've noticed the following scenario requires to fix the codepoint > detection: > # From a native client, I create an object using a PdxSerializable > implementation, which has an String field. > # After that, we are reading this object from a java client which cache has > readPdxSerialized=true and comparing it with a PdxInstance created locally > inside the Java client. > # As PdxInstanceImpl.equals method uses rawBytes for strings, if the string > is serialized using different DSCodes, the comparison will fail, even if the > length and content are the same. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10076) Fix string codepoint detection
[ https://issues.apache.org/jira/browse/GEODE-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10076: --- Labels: pull-request-available (was: ) > Fix string codepoint detection > -- > > Key: GEODE-10076 > URL: https://issues.apache.org/jira/browse/GEODE-10076 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString > Also I've noticed the following scenario requires to fix the codepoint > detection: > # From a native client, I create an object using a PdxSerializable > implementation, which has an String field. > # After that, we are reading this object from a java client which cache has > readPdxSerialized=true and comparing it with a PdxInstance created locally > inside the Java client. > # As PdxInstanceImpl.equals method uses rawBytes for strings, if the string > is serialized using different DSCodes, the comparison will fail, even if the > length and content are the same. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10076) Fix string codepoint detection
[ https://issues.apache.org/jira/browse/GEODE-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10076: --- Assignee: Alberto Gomez (was: Mario Salazar de Torres) > Fix string codepoint detection > -- > > Key: GEODE-10076 > URL: https://issues.apache.org/jira/browse/GEODE-10076 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString > Also I've noticed the following scenario requires to fix the codepoint > detection: > # From a native client, I create an object using a PdxSerializable > implementation, which has an String field. > # After that, we are reading this object from a java client which cache has > readPdxSerialized=true and comparing it with a PdxInstance created locally > inside the Java client. > # As PdxInstanceImpl.equals method uses rawBytes for strings, if the string > is serialized using different DSCodes, the comparison will fail, even if the > length and content are the same. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[ https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538956#comment-17538956 ] ASF GitHub Bot commented on GEODE-10276: gaussianrecurrence commented on PR #969: URL: https://github.com/apache/geode-native/pull/969#issuecomment-1130249492 @pivotal-jbarrett I've addressed all of your comments, plus I've fixed some logic issues and introduced some changes, mostly to cover all edge cases. Additionally, added a bunch of new tests to verify the functionality refactored by the change. So long store sort, I've marked the PR as ready for review, any comments are welcomed :) > Refactor PDX (de)serialziation code to align it with Java client > > > Key: GEODE-10276 > URL: https://issues.apache.org/jira/browse/GEODE-10276 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > Currently there are the following open issues regarding PDX (de)serialization: > * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable > class|https://issues.apache.org/jira/browse/GEODE-9968] > * [GEODE-9753 - Coredump during PdxSerializable object > serialization|https://issues.apache.org/jira/browse/GEODE-9753] > * [GEODE-10220 - Coredump while initializing PdxType > remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220] > * [GEODE-10255 - PdxSerializable not working correctly for multiple versions > of the same class|https://issues.apache.org/jira/browse/GEODE-10255] > Also, the implementation on this ticket ([GEODE-8212: Reduce connections to > server to get type id|https://issues.apache.org/jira/browse/GEODE-8212]) > poses some issues with PDX entries which fields are a permutation. Thing is > that PdxTypes which fields are a permutation might use the wrong offsets, > leading to a corrupt serialization. This is something that was not taken into > account at the time of getting this PR merged. > So this ticket should be reverted and possibly an alternative solution > proposed. > In order to tackle these issues, a code refactoring is needed to introduce > the following implementations: > * Single type of PdxWriter > * An implementation PdxReader that tracks unread data, and other that don't. > * An implementation for PdxInstances that guarantees that fields are > actually written in alphabetical order, independently of the writeFields call > order. This should tackle the issue described above regarding GEODE-8212. > * Also, it'd be ideal to make it so PDX code is cleaner and easier to > understand, though that's a complex matter, and also, subjective. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10317) Range query with wildcard character doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10317: -- Labels: (was: needsTriage) > Range query with wildcard character doing wrong comparison > -- > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[
https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538995#comment-17538995
]
ASF GitHub Bot commented on GEODE-10300:
albertogpz commented on code in PR #970:
URL: https://github.com/apache/geode-native/pull/970#discussion_r876196927
##
cppcache/src/StreamDataInput.hpp:
##
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#pragma once
+
+#ifndef GEODE_STREAMDATAINPUT_H_
+#define GEODE_STREAMDATAINPUT_H_
+
+#include
+
+#include "Connector.hpp"
+#include "geode/DataInput.hpp"
+
+/**
+ * @file
+ */
+
+namespace apache {
+namespace geode {
+namespace client {
+
+#include "geode/DataInput.hpp"
Review Comment:
@pivotal-jbarrett Anything else to change?
> C++ Native client messages coming from the locator cannot be longer than 3000
> bytes
> ---
>
> Key: GEODE-10300
> URL: https://issues.apache.org/jira/browse/GEODE-10300
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> If a locator sends a response to the C++ native client that is longer than
> 3000 bytes the C++ native client library will only read the first 3000 bytes.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10290) GII requester should remove departed members
[ https://issues.apache.org/jira/browse/GEODE-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539012#comment-17539012 ] ASF subversion and git services commented on GEODE-10290: - Commit 3d6354cb6b182d54531a8103a357f03754cf5165 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3d6354cb6b ] GEODE-10290: GII requester should remove departed members (#7670) > GII requester should remove departed members > > > Key: GEODE-10290 > URL: https://issues.apache.org/jira/browse/GEODE-10290 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > In non-persistent but concurrent-check enabled case, members departed will be > marked. They should be removed from RVV during GII to prevent memberToVersion > in RVV grows bigger and bigger. > However, we only removed them from GII provider, not in GII requester. The > good opportunity to remove them in GII requester is when calculating > unfinished operations. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10290) GII requester should remove departed members
[ https://issues.apache.org/jira/browse/GEODE-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-10290. --- Fix Version/s: 1.16.0 Resolution: Fixed > GII requester should remove departed members > > > Key: GEODE-10290 > URL: https://issues.apache.org/jira/browse/GEODE-10290 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > In non-persistent but concurrent-check enabled case, members departed will be > marked. They should be removed from RVV during GII to prevent memberToVersion > in RVV grows bigger and bigger. > However, we only removed them from GII provider, not in GII requester. The > good opportunity to remove them in GII requester is when calculating > unfinished operations. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
[
https://issues.apache.org/jira/browse/GEODE-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10318:
--
Labels: needsTriage (was: )
> locators property is unexpectedly being modified in InternalLocator
> ---
>
> Key: GEODE-10318
> URL: https://issues.apache.org/jira/browse/GEODE-10318
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> if a locator is started with existing "locators" attributes that points to
> itself using ip address, ie.
> {code:java}
> locators=192.168.0.15[22348]
> {code}
> if the machine has a hostname specified in its host file
> {code:java}
> 192.168.0.15 abc-a01
> {code}
> Then after the locator is started, the log banner would show duplicate
> entries in the locators attributes:
> {code:java}
> locators=192.168.0.15[22348],abc-a01[22348]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
Jinmei Liao created GEODE-10318:
---
Summary: locators property is unexpectedly being modified in
InternalLocator
Key: GEODE-10318
URL: https://issues.apache.org/jira/browse/GEODE-10318
Project: Geode
Issue Type: Bug
Components: locator
Reporter: Jinmei Liao
if a locator is started with existing "locators" attributes that points to
itself using ip address, ie.
{code:java}
locators=192.168.0.15[22348]
{code}
if the machine has a hostname specified in its host file
{code:java}
192.168.0.15 abc-a01
{code}
Then after the locator is started, the log banner would show duplicate entries
in the locators attributes:
{code:java}
locators=192.168.0.15[22348],abc-a01[22348]
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
[
https://issues.apache.org/jira/browse/GEODE-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539020#comment-17539020
]
Jinmei Liao commented on GEODE-10318:
-
We should not have duplicate entries in the locators attributes. User's
original specification should be honored first. The order of precedence to use
in the locator's list is:
To summarize the thread, the order of precedence is:
# Address from locator list
# hostname-for-client
# bind-address
# guess, prefer hostname
> locators property is unexpectedly being modified in InternalLocator
> ---
>
> Key: GEODE-10318
> URL: https://issues.apache.org/jira/browse/GEODE-10318
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> if a locator is started with existing "locators" attributes that points to
> itself using ip address, ie.
> {code:java}
> locators=192.168.0.15[22348]
> {code}
> if the machine has a hostname specified in its host file
> {code:java}
> 192.168.0.15 abc-a01
> {code}
> Then after the locator is started, the log banner would show duplicate
> entries in the locators attributes:
> {code:java}
> locators=192.168.0.15[22348],abc-a01[22348]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
[
https://issues.apache.org/jira/browse/GEODE-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10318:
---
Assignee: Jinmei Liao
> locators property is unexpectedly being modified in InternalLocator
> ---
>
> Key: GEODE-10318
> URL: https://issues.apache.org/jira/browse/GEODE-10318
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> if a locator is started with existing "locators" attributes that points to
> itself using ip address, ie.
> {code:java}
> locators=192.168.0.15[22348]
> {code}
> if the machine has a hostname specified in its host file
> {code:java}
> 192.168.0.15 abc-a01
> {code}
> Then after the locator is started, the log banner would show duplicate
> entries in the locators attributes:
> {code:java}
> locators=192.168.0.15[22348],abc-a01[22348]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
[
https://issues.apache.org/jira/browse/GEODE-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10318:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> locators property is unexpectedly being modified in InternalLocator
> ---
>
> Key: GEODE-10318
> URL: https://issues.apache.org/jira/browse/GEODE-10318
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> if a locator is started with existing "locators" attributes that points to
> itself using ip address, ie.
> {code:java}
> locators=192.168.0.15[22348]
> {code}
> if the machine has a hostname specified in its host file
> {code:java}
> 192.168.0.15 abc-a01
> {code}
> Then after the locator is started, the log banner would show duplicate
> entries in the locators attributes:
> {code:java}
> locators=192.168.0.15[22348],abc-a01[22348]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539035#comment-17539035
]
ASF subversion and git services commented on GEODE-10115:
-
Commit 868e1ac1899eaef836dd52713dfce2a97abfd4dc in geode's branch
refs/heads/develop from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=868e1ac189 ]
GEODE-10115: fix javadoc (#7698)
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Lynn Gallinat
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10115.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Lynn Gallinat
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10319) Stopping the metrics service does not delete its meters
[
https://issues.apache.org/jira/browse/GEODE-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10319:
--
Labels: needsTriage (was: )
> Stopping the metrics service does not delete its meters
> ---
>
> Key: GEODE-10319
> URL: https://issues.apache.org/jira/browse/GEODE-10319
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> Some of Geode's standard meters hold references the cache.
> {{InternalDistributedSystemMetricsService.clearAndCloseMeterRegistry()}}
> closes the meter registry without deleting its meters. As a result, the
> closed registry retains indirect references to the cache, holding the closed
> cache in memory.
> {{clearAndCloseMeterRegistry()}} should clear the registry in addition to
> closing it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10319) Stopping the metrics service does not delete its meters
Dale Emery created GEODE-10319:
--
Summary: Stopping the metrics service does not delete its meters
Key: GEODE-10319
URL: https://issues.apache.org/jira/browse/GEODE-10319
Project: Geode
Issue Type: Bug
Components: statistics
Affects Versions: 1.15.0, 1.16.0
Reporter: Dale Emery
Some of Geode's standard meters hold references the cache.
{{InternalDistributedSystemMetricsService.clearAndCloseMeterRegistry()}} closes
the meter registry without deleting its meters. As a result, the closed
registry retains indirect references to the cache, holding the closed cache in
memory.
{{clearAndCloseMeterRegistry()}} should clear the registry in addition to
closing it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10319) Stopping the metrics service does not delete its meters
[
https://issues.apache.org/jira/browse/GEODE-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10319:
--
Assignee: Dale Emery
> Stopping the metrics service does not delete its meters
> ---
>
> Key: GEODE-10319
> URL: https://issues.apache.org/jira/browse/GEODE-10319
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> Some of Geode's standard meters hold references the cache.
> {{InternalDistributedSystemMetricsService.clearAndCloseMeterRegistry()}}
> closes the meter registry without deleting its meters. As a result, the
> closed registry retains indirect references to the cache, holding the closed
> cache in memory.
> {{clearAndCloseMeterRegistry()}} should clear the registry in addition to
> closing it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10106:
--
Labels: blocks-1.15.0 pull-request-available (was: pull-request-available)
> CI Failure: CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer
> ---
>
> Key: GEODE-10106
> URL: https://issues.apache.org/jira/browse/GEODE-10106
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1382]
> {noformat}
> CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer FAILED
> 11:49:39java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 11:49:39Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 11:49:39
> ---
> 11:49:39Found suspect string in 'dunit_suspect-vm4.log' at line 431
> 11:49:39
> 11:49:39[error 2022/03/05 19:49:36.075 UTC
> tid=55] Error in
> redundancy satisfier
> 11:49:39java.lang.NullPointerException
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:856)
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1454)
> 11:49:39 at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
> 11:49:39 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:49:39 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:49:39 at java.lang.Thread.run(Thread.java:750)
> 11:49:39at org.junit.Assert.fail(Assert.java:89)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
> 11:49:39at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:49:39at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:49:39at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:49:39at java.lang.reflect.Method.invoke(Method.java:498)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> 11:49:39at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 11:49:39at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 11:49:39at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 11:49:39at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> 11:49:39at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> 11:49:39at
> org.junit.runners.Paren
[jira] [Updated] (GEODE-10319) Stopping the metrics service does not delete its meters
[
https://issues.apache.org/jira/browse/GEODE-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10319:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> Stopping the metrics service does not delete its meters
> ---
>
> Key: GEODE-10319
> URL: https://issues.apache.org/jira/browse/GEODE-10319
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> Some of Geode's standard meters hold references the cache.
> {{InternalDistributedSystemMetricsService.clearAndCloseMeterRegistry()}}
> closes the meter registry without deleting its meters. As a result, the
> closed registry retains indirect references to the cache, holding the closed
> cache in memory.
> {{clearAndCloseMeterRegistry()}} should clear the registry in addition to
> closing it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10320) bump micrometer to 1.9.0
Owen Nichols created GEODE-10320: Summary: bump micrometer to 1.9.0 Key: GEODE-10320 URL: https://issues.apache.org/jira/browse/GEODE-10320 Project: Geode Issue Type: Improvement Reporter: Owen Nichols To remain Spring-friendly and JDK17-optimal, it will help if Geode 1.15.0 can ship with micrometer 1.9.0 (rather than 1.8.9) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10320) bump micrometer to 1.9.0
[ https://issues.apache.org/jira/browse/GEODE-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10320: - Labels: blocks-1.15.0 (was: ) > bump micrometer to 1.9.0 > > > Key: GEODE-10320 > URL: https://issues.apache.org/jira/browse/GEODE-10320 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Priority: Major > Labels: blocks-1.15.0 > > To remain Spring-friendly and JDK17-optimal, it will help if Geode 1.15.0 can > ship with micrometer 1.9.0 (rather than 1.8.9) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10320) bump micrometer to 1.9.0
[ https://issues.apache.org/jira/browse/GEODE-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10320: --- Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0) > bump micrometer to 1.9.0 > > > Key: GEODE-10320 > URL: https://issues.apache.org/jira/browse/GEODE-10320 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > To remain Spring-friendly and JDK17-optimal, it will help if Geode 1.15.0 can > ship with micrometer 1.9.0 (rather than 1.8.9) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539113#comment-17539113 ] ASF subversion and git services commented on GEODE-10315: - Commit cb5703dca3aee203a82b8bad1f510a38407cdad4 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cb5703dca3 ] GEODE-10315: remove unneeded add-opens (#7699) > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10315. -- Fix Version/s: 1.16.0 Resolution: Fixed > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.16.0 > > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10315: - Fix Version/s: 1.15.0 > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539115#comment-17539115 ] ASF subversion and git services commented on GEODE-10315: - Commit fb1d5a3c4ae6cea333574a45294a9505ab87a15d in geode's branch refs/heads/support/1.15 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fb1d5a3c4a ] GEODE-10315: remove unneeded add-opens (#7699) (cherry picked from commit cb5703dca3aee203a82b8bad1f510a38407cdad4) > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.16.0 > > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10320) bump micrometer to 1.9.0
[ https://issues.apache.org/jira/browse/GEODE-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10320: - Description: To remain Spring-friendly and JDK17-optimal, it will help if Geode 1.15.0 can ship with micrometer 1.9.0 (rather than 1.8.5) (was: To remain Spring-friendly and JDK17-optimal, it will help if Geode 1.15.0 can ship with micrometer 1.9.0 (rather than 1.8.9)) > bump micrometer to 1.9.0 > > > Key: GEODE-10320 > URL: https://issues.apache.org/jira/browse/GEODE-10320 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > To remain Spring-friendly and JDK17-optimal, it will help if Geode 1.15.0 can > ship with micrometer 1.9.0 (rather than 1.8.5) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10320) bump micrometer to 1.9.0
[ https://issues.apache.org/jira/browse/GEODE-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-10320: Assignee: Owen Nichols > bump micrometer to 1.9.0 > > > Key: GEODE-10320 > URL: https://issues.apache.org/jira/browse/GEODE-10320 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > To remain Spring-friendly and JDK17-optimal, it will help if Geode 1.15.0 can > ship with micrometer 1.9.0 (rather than 1.8.5) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols reassigned GEODE-10312:
Assignee: Patrick Johnson
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnson
>Priority: Major
> Labels: blocks-1.15.0
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1352)
> at
> org.springframework.beans.fac
[jira] [Resolved] (GEODE-10316) Convert the rest APIs to use plain spring rather than Spring Boot.
[ https://issues.apache.org/jira/browse/GEODE-10316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-10316. Resolution: Duplicate Closing in favor of GEODE-10312 > Convert the rest APIs to use plain spring rather than Spring Boot. > -- > > Key: GEODE-10316 > URL: https://issues.apache.org/jira/browse/GEODE-10316 > Project: Geode > Issue Type: Task > Components: rest (admin), rest (dev) >Affects Versions: 1.15.0 >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Related to https://issues.apache.org/jira/browse/GEODE-10282, where Boot was > introduced. -- This message was sent by Atlassian Jira (v8.20.7#820007)
