[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865523#action_12865523 ] Chris K Wensel commented on ZOOKEEPER-679: -- actually, I went ahead and threw this on github http://github.com/cwensel/ztree the tests don't compile or run as they depend on un-jarred zk test classes, but there is a build file that will create a simple jar. Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865527#action_12865527 ] Chris K Wensel commented on ZOOKEEPER-679: -- Its more of a mater of what's more utilitarian. Your code can be locked up into the apache repo where only mods must be submitted as patch files, or in github where people can branch/fork/merge at will. note that some projects are doing away with contrib folders since most of the contributions either become abandoned (partly because patch process is too onerous) or are very immature and buggy. the code is now in github, you can choose to fork it and modify it. or ignore it. Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865354#action_12865354 ] Chris K Wensel commented on ZOOKEEPER-679: -- wondering if this would be better served as a github project so it can be collaborated on much easier. Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
