Glad that works. I'll keep an eye out for a pull request. On Wed, Jan 20, 2021 at 7:03 AM Jan Jansen <[email protected]> wrote:
> I think a static protected method would quiet okay. > > On 2021/01/19 14:04:44, Stephen Mallette <[email protected]> wrote: > > Is there a way to do this so that createDefaultYamlConstructor() is not > > public? Perhaps you could make it protected scope and then create a > > JanusGraphServerSettings to extend it so you could access it that way? I > > guess I'm just thinking that Settings shouldn't publicly expose yaml > > related details like that.....on the other hand, this class is not one > that > > is really a common public class that users interact with so perhaps it's > > not something to worry about too much. thoughts? > > > > On Sat, Jan 16, 2021 at 6:19 AM Jan Jansen <[email protected] > .invalid> > > wrote: > > > > > Yeah, It would be easiest solution. So we don't have to copy the > > > constructor, but can add our fields. > > > > > > On 2021/01/15 16:38:59, Stephen Mallette <[email protected]> wrote: > > > > Are you saying you only care about getting the Constructor object, > > > > modifying it and then using it to your own ends? I assume you would > then > > > > make your own Yaml parser: > > > > > > > > Constructor modifiedConstructor = > > > Settings.createDefaultYamlConstructor(); > > > > // do some changes to "modifiedConstructor".... > > > > Yaml yaml = new Yaml(modifiedConstructor); > > > > > > > > Is that right? > > > > > > > > > > > > > > > > On Wed, Jan 13, 2021 at 10:22 AM Jan Jansen > > > > <[email protected]> wrote: > > > > > > > > > Basic idea would to do following: > > > > > > > > > https://gist.github.com/farodin91/b81f6e9bccbae88d04a0dc7006bf0b16#file-settings-java-L274-L346 > > > > > > > > > > Greetings, > > > > > Jan > > > > > > > > > > > > > > > On 2021/01/07 17:16:36, Stephen Mallette <[email protected]> > wrote: > > > > > > Could you be more specific about what you propose in your second > > > idea? I > > > > > > guess i'd like to know how you would like to get the Constructor > and > > > how > > > > > it > > > > > > would affect the API. Thanks > > > > > > > > > > > > On Wed, Jan 6, 2021 at 7:13 AM <[email protected]> wrote: > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > > > > We (JanusGraph) are already automatically settings overwriting > > > > > defaults of > > > > > > > gremlin server settings, see here > > > > > > > > > > > > > > > > https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-server/src/main/java/org/janusgraph/graphdb/server/utils/JanusGraphSettingsUtils.java > > > > > . > > > > > > > We are working on adding a GrpcServer to JanusGraph for > management > > > > > > > interactions. Therefore, we would like to extend gremlin > settings > > > with > > > > > our > > > > > > > own settings. The main problem is that gremlin using strict > > > parsing of > > > > > Yaml > > > > > > > which is great in the most place but prevent us from easying > > > extending > > > > > it. > > > > > > > > > > > > > > I have some ideas: > > > > > > > > > > > > > > * Provide a config flag to allow unknown properties > (easiest > > > > > solution) > > > > > > > * Provide a method which returns the snakeyaml Constructor > > > > > > > > > > > > > > > > https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java > > > > > , > > > > > > > we could use it extend the constructor our way. > > > > > > > > > > > > > > Our current way to use just one config: > > > > > > > > > > > > > > 1. Parse our settings > > > > > > > 2. Parse gremlin-server.yaml as Map<string, object> > > > > > > > 3. Remove our custom fields > > > > > > > 4. Reconstruct yaml from map > > > > > > > 5. Parse yaml with Settings.read > > > > > > > > > > > > > > Any idea's? > > > > > > > > > > > > > > Greetings, > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > >
