Your custom query code does need to be on the server in order for this to
work. Specifically, this lambda is your LuceneQueryProvider, which needs to
be serializable in some way (Serializable, DataSerializable, etc.) and the
code need to be on the server:
index -> {
Hi team,
Do I need to write & deploy a custom Geode Function in order to run the
dynamic Lucene query?
Can I get some help, please?
I need to somehow execute a dynamic lucene query on Geode cluster.
I am able to run successfully a static lucene query using the
standard Lucene's StandardQueryParse
+1 to backport
On 4/6/20, 9:14 AM, "Anthony Baker" wrote:
+1 to backport
> On Apr 6, 2020, at 8:54 AM, Owen Nichols wrote:
>
> Recently some Geode users have expressed concern that shiro-1.4.1.jar is
getting flagged for critical security vulnerability CVE-2020-1957.
+1 to backport
On 4/6/20, 9:14 AM, "Anthony Baker" wrote:
+1 to backport
> On Apr 6, 2020, at 8:54 AM, Owen Nichols wrote:
>
> Recently some Geode users have expressed concern that shiro-1.4.1.jar is
getting flagged for critical security vulnerability CVE-2020-1957.
++ Dev team
Hi team,
I am trying to execute Lucene query from Geode cache-client with the
following :
class CustomerServiceImplTest {
> @Inject CustomerServiceGemfireConfiguration
> customerServiceGemfireConfiguration;
> @Test
> void getAllInterestedCustomers() throws Exception {
> L
Yes, this behavior is correct. If the User provides their own logging
configuration (or a different logging impl such as logback) then none of
the log-* configuration properties in Geode have any effect.
On Mon, Apr 6, 2020 at 9:26 AM Alberto Bustamante Reyes
wrote:
> Hi all,
>
> I have observed
There appears to be consensus that this is a critical fix. I’ve brought the
change to support/1.12 and added 1.12.1 to the listed of fixed versions in Jira.
git cherry-pick -x 6fffd5c07a2f67575ccec6d19df48c70a51ab1c3
-Owen
> On Apr 6, 2020, at 10:35 AM, Dan Smith wrote:
>
> +1
>
> -Dan
>
>
Jake, to follow up on your previous comment re: consensus, after
face-to-face conversation I believe the following is our current status.
Agreed:
* Strong types with opaque struct pointers
* No complete structs in the API/ABI
* split shared libraries - one for C, one for C++, one mixed-mode assemb
Since the deadline for feedback has been reached and there have been no
objections to the proposed changes, this RFC has been moved to "In
Development" status.
Be on the lookout for a PR containing the internal Java API later today!
On Thu, Apr 2, 2020 at 10:16 AM Aaron Lindsey
wrote:
> Yes, th
+1
-Dan
On Mon, Apr 6, 2020 at 10:30 AM Bruce Schuchardt
wrote:
> +1 to backport to support/1.12
>
> On 4/6/20, 8:55 AM, "Owen Nichols" wrote:
>
> Recently some Geode users have expressed concern that shiro-1.4.1.jar
> is getting flagged for critical security vulnerability CVE-2020-1957.
+1 to backport to support/1.12
On 4/6/20, 8:55 AM, "Owen Nichols" wrote:
Recently some Geode users have expressed concern that shiro-1.4.1.jar is
getting flagged for critical security vulnerability CVE-2020-1957.
Analysis shows that Geode does not use Shiro in a manner that would
Hi all,
I have observed that "change loglevel" command doesn't work if the "log4j2.xml"
file used doesn't contain the "geode-default" property set to true. This
requirement is not documented [1], so I would like to confirm if this is the
correct behavior.
If we add "geode-default=true" in our
+1 to backport
> On Apr 6, 2020, at 8:54 AM, Owen Nichols wrote:
>
> Recently some Geode users have expressed concern that shiro-1.4.1.jar is
> getting flagged for critical security vulnerability CVE-2020-1957.
>
> Analysis shows that Geode does not use Shiro in a manner that would expose
> t
Recently some Geode users have expressed concern that shiro-1.4.1.jar is
getting flagged for critical security vulnerability CVE-2020-1957.
Analysis shows that Geode does not use Shiro in a manner that would expose this
vulnerability, so maybe there is no need to backport GEODE-7941.
The risk o
14 matches
Mail list logo
