Yes, IIUC, all version branches are either frozen to get to release or
bugfixes-only [1]. I'm not quite sure where new potential features are to go--
perhaps just parked in branches/PRs until the release of 4.0? In any event, I'm
happy to do whatever is appropriate for a new feature, of course.
I've rebased it onto trunk [2] and indeed, it needed only a few lines of
rewriting (ProtocolVersion was apparently added recently enough to matter). Now
I'll get onto trying to add some more tests (again, mostly to prove that I
understand the feature) and some prospective documentation. Thanks Jon Meredith!
ajs6f
[1]
https://cassandra.apache.org/doc/latest/development/patches.html#choosing-the-right-branches-to-work-on
[2] https://github.com/ajs6f/cassandra/blob/CASSANDRA-15005-trunk
> On Mar 15, 2019, at 1:12 PM, Jon Meredith wrote:
>
> I don’t think it will need too much rewriting, and you’re welcome to give
> it a go. However trunk is mostly feature frozen while it undergoes testing
> ahead of release.
>
> On Fri, Mar 15, 2019 at 9:43 AM A. Soroka (JIRA) wrote:
>
>>
>>[
>> https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793710#comment-16793710
>> ]
>>
>> A. Soroka commented on CASSANDRA-15005:
>> ---
>>
>> [~jmeredithco] I just realized that your branch being from the 3.0 line
>> means it runs up against the code freeze for that branch. I didn't
>> understand what you meant by writing "I'm also not sure what version this
>> could land in with the current freeze on trunk." but now I see that there's
>> a problem there. I can try rewriting this patch for {{trunk/4.0}} if you
>> think that would be feasible/better?
>>
>>> Configurable whilelist for UDFs
>>> ---
>>>
>>>Key: CASSANDRA-15005
>>>URL:
>> https://issues.apache.org/jira/browse/CASSANDRA-15005
>>>Project: Cassandra
>>> Issue Type: Improvement
>>> Components: CQL/Interpreter
>>> Reporter: A. Soroka
>>> Priority: Low
>>>
>>> I would like to use the UDF system to distribute some simple
>> calculations on values. For some use cases, this would require access only
>> to some Java API classes that aren't on the (hardcoded) whitelist (e.g.
>> {{java.security.MessageDigest}}). In other cases, it would require access
>> to a little non-C* library code, pre-distributed to nodes by out-of-band
>> means.
>>> As I understand the situation now, the whitelist for types UDFs can use
>> is hardcoded in java in [UDFunction|[
>> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99]
>> .]
>>> This ticket, then, is a request for a facility that would allow that
>> list to be extended via some kind of deployment-time configuration. I
>> realize that serious security concerns immediately arise for this kind of
>> functionality, but I hope that by restricting it (only used during startup,
>> no exposing the whitelist for introspection, etc.) it could be quite
>> practical.
>>> I'd like very much to assist with this ticket if it is accepted. (I
>> believe I have sufficient Java skill to do that, but no real familiarity
>> with C*'s codebase, yet. :) )
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v7.6.3#76005)
>>
>> -
>> To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: commits-h...@cassandra.apache.org
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
