[GitHub] tinkerpop issue #589: provide examples where merge operator actually has an ...

[mpollmeier]

Github user mpollmeier commented on the issue:

https://github.com/apache/tinkerpop/pull/589
  
@robertdale thanks for checking. Must have happened during rebase. Here 
they are again. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-891) Re-examine Sandboxing Abstractions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954179#comment-15954179
 ] 

ASF GitHub Bot commented on TINKERPOP-891:
--

Github user dpitera commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
I will have to investigate what you've just claimed, but if this is true, 
then yes you are right... I'll get back to you when I've confirmed. Thanks for 
the suggestion!


> Re-examine Sandboxing Abstractions
> --
>
> Key: TINKERPOP-891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-891
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.1.1-incubating
>
>
> The sandboxing abstractions are not so good a set of building blocks as I'd 
> once thought. Helper methods aren't in the right places and more flexibilty 
> is required in managing methods/variables than just simple filters.  Need to 
> develop more concrete actions on this still. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #179: TINKERPOP-891 Refactored the sandboxing abstractions f...

[dpitera]

Github user dpitera commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
I will have to investigate what you've just claimed, but if this is true, 
then yes you are right... I'll get back to you when I've confirmed. Thanks for 
the suggestion!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-891) Re-examine Sandboxing Abstractions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954163#comment-15954163
 ] 

ASF GitHub Bot commented on TINKERPOP-891:
--

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
That's a reasonable example. Could someone not just "blacklist" by 
whitelisting though? I just mean that the whitelisting system is all regex 
based. You could add negation to the whitelist and get rid of your troublesome 
method:

```text
java\.lang\.Boolean\#(?!getBoolean\(String\)).*
```

That allows everything else on `Boolean` except `getBoolean(String)`. 


> Re-examine Sandboxing Abstractions
> --
>
> Key: TINKERPOP-891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-891
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.1.1-incubating
>
>
> The sandboxing abstractions are not so good a set of building blocks as I'd 
> once thought. Helper methods aren't in the right places and more flexibilty 
> is required in managing methods/variables than just simple filters.  Need to 
> develop more concrete actions on this still. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #179: TINKERPOP-891 Refactored the sandboxing abstractions f...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
That's a reasonable example. Could someone not just "blacklist" by 
whitelisting though? I just mean that the whitelisting system is all regex 
based. You could add negation to the whitelist and get rid of your troublesome 
method:

```text
java\.lang\.Boolean\#(?!getBoolean\(String\)).*
```

That allows everything else on `Boolean` except `getBoolean(String)`. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-891) Re-examine Sandboxing Abstractions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954122#comment-15954122
 ] 

ASF GitHub Bot commented on TINKERPOP-891:
--

Github user dpitera commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
> Whitelisting tends to work best in cases like this as it assumes 
everything is bad except for this small, easy to maintain list.

Agreed. Which is what leads me to find myself in a situation where even 
things like `"^java\\.lang\\.String"` must be whitelisted to be called. 


However["^java\\.lang\\.String#getBoolean\\("](http://docs.oracle.com/javase/6/docs/api/java/lang/Boolean.html#getBoolean(java.lang.String))
 must be blacklisted because it leaks implementations details about the 
underlying System.

I believe this is a prime example for situations where the best filter is 
something like:
`!methodBlackList.any { descriptor =~ it } && methodWhiteList.any { 
descriptor =~ it }`.

Would you agree?

> I don't see a reference to methodBlackList in this PR

This is because the methodBlackList of which I speak is part of the 
deprecated sadnbox extension classes


> Re-examine Sandboxing Abstractions
> --
>
> Key: TINKERPOP-891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-891
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.1.1-incubating
>
>
> The sandboxing abstractions are not so good a set of building blocks as I'd 
> once thought. Helper methods aren't in the right places and more flexibilty 
> is required in managing methods/variables than just simple filters.  Need to 
> develop more concrete actions on this still. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #179: TINKERPOP-891 Refactored the sandboxing abstractions f...

[dpitera]

Github user dpitera commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
> Whitelisting tends to work best in cases like this as it assumes 
everything is bad except for this small, easy to maintain list.

Agreed. Which is what leads me to find myself in a situation where even 
things like `"^java\\.lang\\.String"` must be whitelisted to be called. 


However["^java\\.lang\\.String#getBoolean\\("](http://docs.oracle.com/javase/6/docs/api/java/lang/Boolean.html#getBoolean(java.lang.String))
 must be blacklisted because it leaks implementations details about the 
underlying System.

I believe this is a prime example for situations where the best filter is 
something like:
`!methodBlackList.any { descriptor =~ it } && methodWhiteList.any { 
descriptor =~ it }`.

Would you agree?

> I don't see a reference to methodBlackList in this PR

This is because the methodBlackList of which I speak is part of the 
deprecated sadnbox extension classes


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-891) Re-examine Sandboxing Abstractions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954092#comment-15954092
 ] 

ASF GitHub Bot commented on TINKERPOP-891:
--

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
I don't see a reference to `methodBlackList` in this PR, but if we were to 
just reduce the question to why do we have whitelisting and no blacklisting 
then I think I could probably answer that.  I'd rather not support blacklisting 
in TinkerPop, as it just seems to lead people into thinking they have a secure 
solution when they soon learn that they'd forgotten yet another harmful entry 
to blacklist. 

I think that the whitelist works really well in TinkerPop, because the base 
list of classes required to execute Gremlin is small (and really that's all we 
care about from TinkerPop's perspective). Whitelisting tends to work best in 
cases like this as it assumes everything is bad except for this small, easy to 
maintain list.  Since whitelisting fits this situation so well, a blacklist 
feels a bit useless - extra code without purpose which we try to avoid. 

Obviously, we do have the `SimpleSandboxExtension` which does some basic 
blacklisting but it's mostly for demonstration and for basic protection from 
the worst of the worst `System.exit()`. 

Does that make sense? 



> Re-examine Sandboxing Abstractions
> --
>
> Key: TINKERPOP-891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-891
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.1.1-incubating
>
>
> The sandboxing abstractions are not so good a set of building blocks as I'd 
> once thought. Helper methods aren't in the right places and more flexibilty 
> is required in managing methods/variables than just simple filters.  Need to 
> develop more concrete actions on this still. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #179: TINKERPOP-891 Refactored the sandboxing abstractions f...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
I don't see a reference to `methodBlackList` in this PR, but if we were to 
just reduce the question to why do we have whitelisting and no blacklisting 
then I think I could probably answer that.  I'd rather not support blacklisting 
in TinkerPop, as it just seems to lead people into thinking they have a secure 
solution when they soon learn that they'd forgotten yet another harmful entry 
to blacklist. 

I think that the whitelist works really well in TinkerPop, because the base 
list of classes required to execute Gremlin is small (and really that's all we 
care about from TinkerPop's perspective). Whitelisting tends to work best in 
cases like this as it assumes everything is bad except for this small, easy to 
maintain list.  Since whitelisting fits this situation so well, a blacklist 
feels a bit useless - extra code without purpose which we try to avoid. 

Obviously, we do have the `SimpleSandboxExtension` which does some basic 
blacklisting but it's mostly for demonstration and for basic protection from 
the worst of the worst `System.exit()`. 

Does that make sense? 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-891) Re-examine Sandboxing Abstractions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954051#comment-15954051
 ] 

ASF GitHub Bot commented on TINKERPOP-891:
--

Github user dpitera commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
@spmallette I am curious why this Pull Request got rid of the 
`methodBlackList`? I ask because I want to extend the `FileSandboxExtension` 
here to support blacklisting-- would you prefer I did the extension at that 
level, created another `FileSandboxWithBlacklistingExtension`, or did the 
extension at the `AbstractSandboxExtension`?


> Re-examine Sandboxing Abstractions
> --
>
> Key: TINKERPOP-891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-891
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.1.1-incubating
>
>
> The sandboxing abstractions are not so good a set of building blocks as I'd 
> once thought. Helper methods aren't in the right places and more flexibilty 
> is required in managing methods/variables than just simple filters.  Need to 
> develop more concrete actions on this still. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #179: TINKERPOP-891 Refactored the sandboxing abstractions f...

[dpitera]

Github user dpitera commented on the issue:

https://github.com/apache/tinkerpop/pull/179
  
@spmallette I am curious why this Pull Request got rid of the 
`methodBlackList`? I ask because I want to extend the `FileSandboxExtension` 
here to support blacklisting-- would you prefer I did the extension at that 
level, created another `FileSandboxWithBlacklistingExtension`, or did the 
extension at the `AbstractSandboxExtension`?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1657) Provide abstraction to easily allow different HttpAuth schemes

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953887#comment-15953887
 ] 

ASF GitHub Bot commented on TINKERPOP-1657:
---

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/583#discussion_r109478243
  
--- Diff: 
gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java 
---
@@ -384,9 +384,25 @@ public SerializerSettings() {}
  * used to load the implementation from the classpath. Defaults to 
{@link AllowAllAuthenticator} when
  * not specified.
  */
+public String authenticator = null;
+
+/**
+ * The fully qualified class name of the {@link Authenticator} 
implementation. This class name will be
+ * used to load the implementation from the classpath. Defaults to 
{@link AllowAllAuthenticator} when
+ * not specified.
+ * Deprecated in favor of {@link authenticator}.
--- End diff --

Note that our deprecation form in javadoc typically looks like this:

```java
@deprecated As of release 3.2.5, replaced by {@link authenticator}.
```


> Provide abstraction to easily allow different HttpAuth schemes
> --
>
> Key: TINKERPOP-1657
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1657
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Reporter: Keith Lohnes
>
> The current HttpChannelizer allows for extension through an Authenticator 
> class supplied through the authorization settings. There isn't, however, an 
> extension point for an authentication handler. Currently the choice is 
> between the `AllowAllAuthenticator` or the `HttpBasicAuthenticationHandler`. 
> One would need to create a new channelizer where the HttpChannelizer would 
> suffice. Creating an abstract class that can be extended would make it easier 
> to extend Authentication for things like token authentication schemes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop pull request #583: TINKERPOP-1657 Provide abstraction to easily al...

[spmallette]

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/583#discussion_r109478243
  
--- Diff: 
gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java 
---
@@ -384,9 +384,25 @@ public SerializerSettings() {}
  * used to load the implementation from the classpath. Defaults to 
{@link AllowAllAuthenticator} when
  * not specified.
  */
+public String authenticator = null;
+
+/**
+ * The fully qualified class name of the {@link Authenticator} 
implementation. This class name will be
+ * used to load the implementation from the classpath. Defaults to 
{@link AllowAllAuthenticator} when
+ * not specified.
+ * Deprecated in favor of {@link authenticator}.
--- End diff --

Note that our deprecation form in javadoc typically looks like this:

```java
@deprecated As of release 3.2.5, replaced by {@link authenticator}.
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[DISCUSS] Remove deprecated fields/methods in Gremlin Server

[Stephen Mallette]

Every once in a while I peruse JIRA and I take notice of the large body of
tickets around removing deprecated fields and methods in Gremlin Server.
Some of this deprecation occurred along the 3.1.x line of code - I think
it's time to just go through and clean all that up at this point. Here's
the ones I'm looking at:

https://issues.apache.org/jira/browse/TINKERPOP-1010
https://issues.apache.org/jira/browse/TINKERPOP-1046
https://issues.apache.org/jira/browse/TINKERPOP-1049
https://issues.apache.org/jira/browse/TINKERPOP-1296
https://issues.apache.org/jira/browse/TINKERPOP-1465
https://issues.apache.org/jira/browse/TINKERPOP-1526

If you happen to go through them, you'll see that they are all "low-level"
sorts of changes that likely wouldn't affect anyone except perhaps those
who are embedding Gremlin Server in some way. If that's the case, these
folks probably won't have too much trouble sorting out the issues.

I plan to bundle all these changes up into one pull request to master. It
should clean up a fair bit of code to drop all that deprecated stuff.
Please let me know if there are any concerns about killing out this old
code.

Thanks,

Stephen

[jira] [Commented] (TINKERPOP-1438) Consider GraphManager as an interface

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953726#comment-15953726
 ] 

ASF GitHub Bot commented on TINKERPOP-1438:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/569
  
Ran Gremlin Server integration tests locally to success - VOTE +1


> Consider GraphManager as an interface
> -
>
> Key: TINKERPOP-1438
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1438
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Priority: Minor
>  Labels: breaking
>
> If {{GraphManager}} were an interface it would make embedding Gremlin Server 
> easier as {{Graph}} instances could be more easily supplied by the host 
> application. In doing this, It also might be good to force a 
> {{TraversalSource}} to be referred to by both the {{Graph}} name and  
> {{TraversalSource}} name.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #569: TINKERPOP-1438: GraphManager becomes a customizable in...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/569
  
Ran Gremlin Server integration tests locally to success - VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #583: TINKERPOP-1657 Provide abstraction to easily allow dif...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/583
  
@robertdale i'm glad you're thinking at that level wrt to security aspects 
of Gremlin Server. My understanding of SSL beyond what I've implemented so far 
is pretty weak, so if you have additional ideas there that would make things 
better that would be great. I can't say if this PR helps with what you 
described. My understanding of your comment makes me feel like it doesn't help 
directly and that the current way to do that would be a fresh `Channelizer` 
implementation, but I could be missing something.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1657) Provide abstraction to easily allow different HttpAuth schemes

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953681#comment-15953681
 ] 

ASF GitHub Bot commented on TINKERPOP-1657:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/583
  
@robertdale i'm glad you're thinking at that level wrt to security aspects 
of Gremlin Server. My understanding of SSL beyond what I've implemented so far 
is pretty weak, so if you have additional ideas there that would make things 
better that would be great. I can't say if this PR helps with what you 
described. My understanding of your comment makes me feel like it doesn't help 
directly and that the current way to do that would be a fresh `Channelizer` 
implementation, but I could be missing something.




> Provide abstraction to easily allow different HttpAuth schemes
> --
>
> Key: TINKERPOP-1657
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1657
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Reporter: Keith Lohnes
>
> The current HttpChannelizer allows for extension through an Authenticator 
> class supplied through the authorization settings. There isn't, however, an 
> extension point for an authentication handler. Currently the choice is 
> between the `AllowAllAuthenticator` or the `HttpBasicAuthenticationHandler`. 
> One would need to create a new channelizer where the HttpChannelizer would 
> suffice. Creating an abstract class that can be extended would make it easier 
> to extend Authentication for things like token authentication schemes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1664) StarVertexProperty#property should throw an NPE if the value is null

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953572#comment-15953572
 ] 

ASF GitHub Bot commented on TINKERPOP-1664:
---

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/590
  
Looks like a candidate for tp31


> StarVertexProperty#property should throw an NPE if the value is null
> 
>
> Key: TINKERPOP-1664
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1664
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> Currently properties are checked for nullness but meta-properties arenot. 
> This leads to NPEs further down the line.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #590: TINKERPOP-1664 StarVertexProperty will check meta-prop...

[robertdale]

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/590
  
Looks like a candidate for tp31


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #590: TINKERPOP-1664 StarVertexProperty will check me...

[okram]

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/590#discussion_r109411238
  
--- Diff: CHANGELOG.asciidoc ---
@@ -64,6 +64,7 @@ TinkerPop 3.2.5 (Release Date: NOT OFFICIALLY RELEASED 
YET)
 * Improved error handling of compilation failures for very large or highly 
parameterized script sent to Gremlin Server.
 * Fixed a bug in `RangeByIsCountStrategy` that changed the meaning of 
inner traversals.
 * Improved Gremlin-Python Driver implementation by adding a threaded 
client with basic connection pooling and support for pluggable websocket 
clients.
+* StarVertexProperty will check meta-properties are valid.
--- End diff --

This should be written as:

Fixed a bug in `StarVertexProperty` where properties are now validated. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #590: TINKERPOP-1664 StarVertexProperty will check meta-prop...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/590
  
VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1664) StarVertexProperty#property should throw an NPE if the value is null

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953436#comment-15953436
 ] 

ASF GitHub Bot commented on TINKERPOP-1664:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/590
  
VOTE +1


> StarVertexProperty#property should throw an NPE if the value is null
> 
>
> Key: TINKERPOP-1664
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1664
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> Currently properties are checked for nullness but meta-properties arenot. 
> This leads to NPEs further down the line.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1664) StarVertexProperty#property should throw an NPE if the value is null

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953435#comment-15953435
 ] 

ASF GitHub Bot commented on TINKERPOP-1664:
---

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/590#discussion_r109411238
  
--- Diff: CHANGELOG.asciidoc ---
@@ -64,6 +64,7 @@ TinkerPop 3.2.5 (Release Date: NOT OFFICIALLY RELEASED 
YET)
 * Improved error handling of compilation failures for very large or highly 
parameterized script sent to Gremlin Server.
 * Fixed a bug in `RangeByIsCountStrategy` that changed the meaning of 
inner traversals.
 * Improved Gremlin-Python Driver implementation by adding a threaded 
client with basic connection pooling and support for pluggable websocket 
clients.
+* StarVertexProperty will check meta-properties are valid.
--- End diff --

This should be written as:

Fixed a bug in `StarVertexProperty` where properties are now validated. 


> StarVertexProperty#property should throw an NPE if the value is null
> 
>
> Key: TINKERPOP-1664
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1664
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> Currently properties are checked for nullness but meta-properties arenot. 
> This leads to NPEs further down the line.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1663) Validate a maximum for the number of parameters passed to Gremlin Server

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953329#comment-15953329
 ] 

ASF GitHub Bot commented on TINKERPOP-1663:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/591

TINKERPOP-1663 Validation for maximum number of parameters on a request

https://issues.apache.org/jira/browse/TINKERPOP-1663

Provides a configuration option to validate the number of parameters that 
gremlin server will accept on a request for script evaluation.

Ran integration tests for gremlin-server and console.

vOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1663

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/591.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #591


commit a4c652ae3c071c15c5a57524a797707f5ea318a4
Author: Stephen Mallette 
Date:   2017-04-03T11:04:42Z

TINKERPOP-1663 Validation for maximum number of parameters on a request

The default is set to 16 and there is a configuration option to allow it to 
be changed.




> Validate a maximum for the number of parameters passed to Gremlin Server
> 
>
> Key: TINKERPOP-1663
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1663
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> Given that tests have shown that scripts with very large number of parameters 
> take a longer amount of time to compile than scripts with smaller numbers of 
> parameters, having some control over the number of allowed parameters might 
> help prevent users from falling into an anti-pattern. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1664) StarVertexProperty#property should throw an NPE if the value is null

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953302#comment-15953302
 ] 

ASF GitHub Bot commented on TINKERPOP-1664:
---

GitHub user BrynCooke opened a pull request:

https://github.com/apache/tinkerpop/pull/590

TINKERPOP-1664 StarVertexProperty will check meta-properties are valid.

StarVertexProperty will check meta-properties are valid.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-1664

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/590.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #590


commit 0b05c937ee0b0f9025bd4faf8c101ee3d49a3d62
Author: BrynCooke 
Date:   2017-04-03T11:19:54Z

TINKERPOP-1664
StarVertexProperty will check meta-properties are valid.




> StarVertexProperty#property should throw an NPE if the value is null
> 
>
> Key: TINKERPOP-1664
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1664
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> Currently properties are checked for nullness but meta-properties arenot. 
> This leads to NPEs further down the line.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop pull request #590: TINKERPOP-1664 StarVertexProperty will check me...

[BrynCooke]

GitHub user BrynCooke opened a pull request:

https://github.com/apache/tinkerpop/pull/590

TINKERPOP-1664 StarVertexProperty will check meta-properties are valid.

StarVertexProperty will check meta-properties are valid.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-1664

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/590.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #590


commit 0b05c937ee0b0f9025bd4faf8c101ee3d49a3d62
Author: BrynCooke 
Date:   2017-04-03T11:19:54Z

TINKERPOP-1664
StarVertexProperty will check meta-properties are valid.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TINKERPOP-1664) StarVertexProperty#property should throw an NPE if the value is null

[Bryn Cooke (JIRA)]

Bryn Cooke created TINKERPOP-1664:
-

 Summary: StarVertexProperty#property should throw an NPE if the 
value is null
 Key: TINKERPOP-1664
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1664
 Project: TinkerPop
  Issue Type: Improvement
  Components: structure
Affects Versions: 3.2.4
Reporter: Bryn Cooke


Currently properties are checked for nullness but meta-properties arenot. This 
leads to NPEs further down the line.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)