[jira] [Commented] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283906#comment-14283906
]
Edward Capriolo commented on CASSANDRA-6871:
I do not see how since dynamical loading code is insecure but feed free to have
at it.
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283697#comment-14283697
]
Robert Stupp commented on CASSANDRA-6871:
-
Shall we resolve this ticket in favor of a new one about something like
{{CREATE TRIGGER ... USING FUNCTION}}?
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938673#comment-13938673
]
Edward Capriolo commented on CASSANDRA-6871:
[~jbellis]
https://github.com/edwardcapriolo/cassandra/compare/dynamic_loading?expand=1
Do not mind the thrift-ness of the above patch. The concept here is that no
matter what the interface is triggers, UDF, scanners, we can load/reload the
component dynamically.
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938062#comment-13938062
]
Edward Capriolo commented on CASSANDRA-6871:
{quote}
It sounds like I'd still be shipping jars around
{quote}
You have the option of placing the payload of the UDF in the script field if
the spec supports its.
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938057#comment-13938057
]
Edward Capriolo commented on CASSANDRA-6871:
{quote}
Ultimately what I'd like to see is CREATE TRIGGER specify a UDF, with UDF
support for multiple languages a la postgresq
{quote}
I think we are in agreement. Right now when you create a trigger you only
specify a class name.
The syntax would be something like this
{code}
create trigger abc options {classname='abc', spec='groovy' script=' public
class {'
{code}
The spec could be any language and the script could be any language. clojure,
jruby etc.
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937978#comment-13937978
]
Jonathan Ellis commented on CASSANDRA-6871:
---
Ultimately what I'd like to see is CREATE TRIGGER specify a UDF, with UDF
support for multiple languages a la postgresql, but I'm not sure if this is a
step in that direction. It sounds like I'd still be shipping jars around, so
I'm not sure what you're proposing besides some kind of groovy support.
Did you mean to provide a link to the branch above?
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937250#comment-13937250
]
Edward Capriolo commented on CASSANDRA-6871:
I have this change in a branch here. It requires a very minimal changes to
build.xml, DatabaseDescriptor.java and Config.java. This is roughly a 30 line
patch.
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
