.
>
>
>
> *From: *Sébastien Rebecchi
> *Date: *Wednesday, 6 April 2022 at 15:15
> *To: *dev@cassandra.apache.org ,
> e.dimitr...@gmail.com
> *Cc: *ble...@apache.org
> *Subject: *Re: UDF: adding custom jar to classpath
>
> Hi Ekaterina,
>
>
>
> I use 4.0.1.
>
...@gmail.com
Cc: ble...@apache.org
Subject: Re: UDF: adding custom jar to classpath
Hi Ekaterina,
I use 4.0.1.
But as I said I added a jar in classpath (/usr/share/cassandra/lib/ folder on
every node) and I see that the jar is loaded in the classpath from the
Cassandra command line. And I have
Hi Ekaterina,
I use 4.0.1.
But as I said I added a jar in classpath (/usr/share/cassandra/lib/ folder
on every node) and I see that the jar is loaded in the classpath from the
Cassandra command line. And I have "enable_user_defined_functions: true"
and "enable_user_defined_functions_threads: false
Hi Sebastian,
Do you use the latest 4.0.3 version? Those options were added in 4.0.2 I
believe, so if you try them with an earlier version - below message is what
you would get as they didn’t exist.
Best regards,
Ekaterina
On Wed, 6 Apr 2022 at 9:53, Sébastien Rebecchi
wrote:
> Hi Benjamin, Hi
Sorry, I found that allow_insecure_udfs and allow_extra_insecure_udfs have
been introduced in 4.0.2 but I run 4.0.1, so that explains the error.
So for 4.0.1 "enable_user_defined_functions_threads: false" should be
enough, no advance on that I still don't know why my UDF does not compile
then
Le m
Hi Benjamin, Hi everybody,
I found in the documentation that we should add "allow_insecure_udfs: true"
and optionally "allow_extra_insecure_udfs: true" so that
"enable_user_defined_functions_threads: false" is really taken into account
(I understood like that). That would explain why my UDF still
Unfortunately, I do not have much time for doing some digging. Sorry for
that :-(
You should look at JavaBasedUDFunction and UDFExecutorServic.
Le lun. 4 avr. 2022 à 17:25, Sébastien Rebecchi a
écrit :
> Hi!
> Do you have any more ideas for me?
> Cordially,
> Sébastien.
>
> Le lun. 28 mars 2022
Hi!
Do you have any more ideas for me?
Cordially,
Sébastien.
Le lun. 28 mars 2022 à 16:39, Sébastien Rebecchi
a écrit :
> Unfortunately, it is not working even with
> "enable_user_defined_functions_threads: false" in cassandra.yaml :/
> Is there any way to check the running configuration?
>
> Le
Unfortunately, it is not working even with
"enable_user_defined_functions_threads: false" in cassandra.yaml :/
Is there any way to check the running configuration?
Le lun. 28 mars 2022 à 15:35, Benjamin Lerer a écrit :
> I do not think that allowing to customize UDF classes whitelist has been
>
I do not think that allowing to customize UDF classes whitelist has been
discussed before. Feel free to open a JIRA ticket :-)
I have some plans to revisit how we securise UDFs as the current threading
approach has some impact in terms of latency. That can be a good
opportunity to look into providi
Thanks you very much! I will try that.
As you know, would it be a long-terms solution? Or is there any plan to add
the possibility to customize UDF classes whitelist?
Le lun. 28 mars 2022 à 14:31, Benjamin Lerer a écrit :
> Is there a way to customize that default behaviour?
>
>
> Looking at Jav
>
> Is there a way to customize that default behaviour?
Looking at JavaBasedUDFunction quickly it seems that the ClassLoader is
only used when you use the UDFExecutorService to execute your UDFs. You can
try to disable it using "enable_user_defined_functions_threads: false" and
see if it works.
N
Hi Benjamin,
Thanks for the answer.
Is there a way to customize that default behaviour? If no, could you
indicate where to find this class loader in the github of Cassandra please?
Le lun. 28 mars 2022 à 12:40, Benjamin Lerer a écrit :
> Hi Sébastien,
>
> Cassandra uses a special classloader fo
Hi Sébastien,
Cassandra uses a special classloader for UDFs that limit which classes can
be used.
You cannot rely on non-JDK classes for UDFs and some of the JDK packages
like the IO package for example cannot be used.
The goal is simply to ensure that UDFs cannot compromise the server
security.
CASSANDRA-17280 and CASSANDRA-17281 were opened to cover the work. Thank you
On Sun, 23 Jan 2022 at 11:46, Joshua McKenzie wrote:
> Lazy consensus seems like a safe path here.
>
> https://community.apache.org/committers/lazyConsensus.html
>
> On Sat, Jan 22, 2022 at 4:24 PM Ekaterina Dimitrova
Lazy consensus seems like a safe path here.
https://community.apache.org/committers/lazyConsensus.html
On Sat, Jan 22, 2022 at 4:24 PM Ekaterina Dimitrova
wrote:
>
> Hi everyone,
>
> Thank you for responding to my email.
>
> Looking at the responses, I guess I should directly open tickets - one
Hi everyone,
Thank you for responding to my email.
Looking at the responses, I guess I should directly open tickets - one for
deprecating in 4.0.2 (just warning and documenting it) and one for the
removal/providing interface for trunk?
Do we need more formal voting or anything else that I might
+1
Best Regards,
Aleksei Zotov.
On Thu, Jan 20, 2022 at 11:52 AM Marcus Eriksson wrote:
> +1
>
> On Tue, Jan 18, 2022 at 11:30:01AM -0500, Ekaterina Dimitrova wrote:
> > Hi everyone,
> >
> > With the work to add Java 17 support for Cassandra, a new question around
> > the future of UDF was ra
+1
On Tue, Jan 18, 2022 at 11:30:01AM -0500, Ekaterina Dimitrova wrote:
> Hi everyone,
>
> With the work to add Java 17 support for Cassandra, a new question around
> the future of UDF was raised. The scripted UDF was using Nashorn which is
> no longer packaged with the JDK. There are options to
+1 to deprecate, drop, add hooks.
On Wed, Jan 19, 2022 at 2:22 PM Brandon Williams wrote:
> Yes, just javascript.
>
> On Wed, Jan 19, 2022 at 1:20 PM Yifan Cai wrote:
> >>
> >> I think we should deprecate scripted UDFs now and drop them from the
> next major, but possibly provide hooks for pe
Yes, just javascript.
On Wed, Jan 19, 2022 at 1:20 PM Yifan Cai wrote:
>>
>> I think we should deprecate scripted UDFs now and drop them from the next
>> major, but possibly provide hooks for people to write their own UDF
>> "engines" and break out the current javascript implementation in to it
>
> I think we should deprecate scripted UDFs now and drop them from the next
> major, but possibly provide hooks for people to write their own UDF
> "engines" and break out the current javascript implementation in to its own
> repository (but not ship it with Cassandra).
+1
Just want to clarify
+1 (nb)
On 2022/01/19 15:10:20 Brandon Williams wrote:
> We can for completeness, but even with twice as much usage reported as the
> other methods, I don't think it will affect the outcome of the vote.
>
> On Wed, Jan 19, 2022, 7:25 AM Paulo Motta wrote:
>
> > This proposal looks good to me, +
We can for completeness, but even with twice as much usage reported as the
other methods, I don't think it will affect the outcome of the vote.
On Wed, Jan 19, 2022, 7:25 AM Paulo Motta wrote:
> This proposal looks good to me, +1. I was wondering if we should not run
> this proposal on the user@
This proposal looks good to me, +1. I was wondering if we should not run
this proposal on the user@ list to check if there's any additional feedback
in addition to the informal Twitter and Linkedin channels?
Em qua., 19 de jan. de 2022 às 10:18, Sylwester Lachiewicz <
slachiew...@gmail.com> escrev
+1 (Nb)
śr., 19 sty 2022, 12:31 użytkownik Brandon Williams
napisał:
> +1
>
> On Tue, Jan 18, 2022 at 10:30 AM Ekaterina Dimitrova
> wrote:
> >
> > Hi everyone,
> >
> > With the work to add Java 17 support for Cassandra, a new question
> around the future of UDF was raised. The scripted UDF was
+1
On Tue, Jan 18, 2022 at 10:30 AM Ekaterina Dimitrova
wrote:
>
> Hi everyone,
>
> With the work to add Java 17 support for Cassandra, a new question around the
> future of UDF was raised. The scripted UDF was using Nashorn which is no
> longer packaged with the JDK. There are options to add n
+1
> On Jan 18, 2022, at 8:38 AM, Jonathan Ellis wrote:
>
>
> +1
>
>> On Tue, Jan 18, 2022 at 10:34 AM C. Scott Andreas
>> wrote:
>> I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an
>> interface for those who would like to supply a UDF implementation; and to
>>
+1
On Tue, Jan 18, 2022 at 10:34 AM C. Scott Andreas
wrote:
> I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an
> interface for those who would like to supply a UDF implementation; and to
> extract/remove our current implementation.
>
> JDK17 support seems like a much hi
I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an
interface for those who would like to supply a UDF implementation; and to
extract/remove our current implementation.
JDK17 support seems like a much higher priority than in-tree JS UDFs.
— Scott
> On Jan 18, 2022, at 8:
I'm +1 with this solution going in 4.0.
That said, this make we realize that through this dependency we've
ended up exposing (publicly) a bit too much to UDF. Namely, all we really
need/want to expose for UDF is the "value" classes (UDTValue, TupleValue,
Duration and LocalDate) and the types (Data
It’s my understanding that the duplicated code is being fully donated - so
it’ll have all the usual ASF license/copyright headers when it lands in trunk.
No special steps to take here.
—
AY
On 11 September 2018 at 19:43:58, Jeremiah D Jordan (jeremiah.jor...@gmail.com)
wrote:
Be careful when
Be careful when pulling in source files from the DataStax Java Driver (or
anywhere) to make sure and respect its Apache License, Version 2.0 and keep all
Copyright's etc with said files.
-Jeremiah
> On Sep 11, 2018, at 12:29 PM, Jeff Jirsa wrote:
>
> +1 as well.
>
> On Tue, Sep 11, 2018 at 1
+1 as well.
On Tue, Sep 11, 2018 at 10:27 AM Aleksey Yeschenko
wrote:
> If this is about inclusion in 4.0, then I support it.
>
> Technically this is *mostly* just a move+donation of some code from
> java-driver to Cassandra. Given how important this seemingly is to the
> board and PMC for us to
If this is about inclusion in 4.0, then I support it.
Technically this is *mostly* just a move+donation of some code from java-driver
to Cassandra. Given how important this seemingly is to the board and PMC for us
to not have the dependency on the driver, the sooner it’s gone, the better.
I’d b
The patch is technically complete - i.e. it works and does its thing.
It's not strictly a bug fix but targets trunk. That's why I started the
discussion.
On 09/11/2018 02:53 PM, Jason Brown wrote:
Hi Robert,
Thanks for taking on this work. Is this message a heads up that a patch is
coming/c
Hi Robert,
Thanks for taking on this work. Is this message a heads up that a patch is
coming/complete, or to spawn a discussion about including this in 4.0?
Thanks,
-Jason
On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp wrote:
> In an effort to clean up our hygiene and limit the dependencies us
37 matches
Mail list logo
