You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Aaron Crow (JIRA)" <ji...@apache.org> on 2010/02/24 19:41:29 UTC

[jira] Created: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

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: java client, tests
            Reporter: Aaron Crow
            Priority: Minor


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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Attachment: ZOOKEEPER-679.patch

> 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: java client, tests
>            Reporter: Aaron Crow
>            Priority: Minor
>         Attachments: 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mahadev konar updated ZOOKEEPER-679:
------------------------------------

    Status: Open  (was: Patch Available)

> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: Patch Available  (was: Open)

> 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: java client, tests
>            Reporter: Aaron Crow
>            Priority: Minor
>         Attachments: 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.

Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856642#action_12856642 ] 

Mahadev konar commented on ZOOKEEPER-679:
-----------------------------------------

aaron,
  i was looking at the patch. I think we should move the source and the tests to src/contrib/ztree. It would be more appropriate as a contrib module. Do you want to upload a new patch with this as a contrib module. Please take a look at src/contrib on how to make this as a contrib module.



> 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
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860608#action_12860608 ] 

Hadoop QA commented on ZOOKEEPER-679:
-------------------------------------

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12442757/ZOOKEEPER-679.patch
  against trunk revision 936624.

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 3 new or modified tests.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac compiler warnings.

    +1 findbugs.  The patch does not introduce any new Findbugs warnings.

    +1 release audit.  The applied patch does not increase the total number of release audit warnings.

    +1 core tests.  The patch passed core unit tests.

    +1 contrib tests.  The patch passed contrib unit tests.

Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/73/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/73/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/73/console

This message is automatically generated.

> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: Open  (was: Patch Available)

oops, I think I forgot to upload latest diff

> 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.

Posted by "Chris K Wensel (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865526#action_12865526 ] 

Aaron Crow commented on ZOOKEEPER-679:
--------------------------------------

Hi Chris, my apologies, I haven't had much time to continue with this patch. I kind of got held up by the combination of limited time, and apparently being required to engineer a standalone build for the patch. 

This is actually my first significant contribution, so I'm feeling a little lost at this point. Is it kosher to move patches out of zk contrib and into independent repos? And what would make it easer to collaborate on in github vs. the main zk project?

Many thanks for your interest and time...

Aaron

> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: In Progress  (was: Patch Available)

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Patrick Hunt (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Hunt updated ZOOKEEPER-679:
-----------------------------------

      Component/s: contrib
         Priority: Major  (was: Minor)
    Fix Version/s: 3.4.0

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: Patch Available  (was: Open)

Moving ztree library to contrib, per Mahadev's request.

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: Patch Available  (was: Open)

now with proper diff, to put ztree library in contrib

> 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] Assigned: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mahadev konar reassigned ZOOKEEPER-679:
---------------------------------------

    Assignee: Aaron Crow

> 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: java client, tests
>            Reporter: Aaron Crow
>            Assignee: Aaron Crow
>            Priority: Minor
>         Attachments: 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Attachment: ZOOKEEPER-679.patch

Upgrade to previous submission. Better design and resolved FindBugs issues.

> 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
>
>
> 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.

Posted by "Henry Robinson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865639#action_12865639 ] 

Henry Robinson commented on ZOOKEEPER-679:
------------------------------------------

Hi Aaron - 

The great thing about open source, and the relatively permissive Apache license in particular, is that Chris is free to copy any and all of ZK into github and continue with a development process that he finds more agreeable. It is completely kosher to do this. As Chris says, you are welcome to contribute, fork or ignore it. 

As far as I am concerned, contrib is an excellent place to put projects that directly add more functionality to their parent project (the language bindings and this patch are good examples), but not a great place to store standalone projects that simply leverage the parent (an example might be a DNS server, written in ZooKeeper). This is a needfully vague distinction, and others will have different opinions.

I do not know specifically to what Chris is referring when he talks about an 'onerous' patch process, but I speculate he might mean that the role of 'committer' - someone who is gating the submission of patches - makes it harder to get your patches available for others to use quickly. Of course there are also benefits of this approach, such as a ready collection of experienced users on hand to offer advice and the relatively high standard for patches to be accepted to trunk arguably improves code quality. What's great is the two development styles are not mutually exclusive, and can, ideally, benefit from each other. If you are having difficulties with, or are frustrated by, the patch submission process here, ask for help. The community here is very happy to help, and we'll do what we can to address pain points. 

As for this patch, I'm happy it's going into contrib - users sometimes find ZooKeeper difficult to program to, and examples and new abstractions are always welcome. Keeping this patch in the main repository means that newcomers to ZooKeeper will find it more easily. Thanks for the contribution!

Henry

> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: In Progress  (was: Patch Available)

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Patrick Hunt (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Hunt updated ZOOKEEPER-679:
-----------------------------------

    Status: Open  (was: Patch Available)

Cancelling the patch, Aaron, can you take a look at addressing the findbugs issues?

> 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
>
>
> 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.

Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864043#action_12864043 ] 

Mahadev konar commented on ZOOKEEPER-679:
-----------------------------------------

+1 the patch looks good!!!! 

> 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.

Posted by "Chris K Wensel (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

Posted by "Chris K Wensel (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.


[jira] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Attachment: ZOOKEEPER-679.patch

Added some clarification of intent in unit tests

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: Patch Available  (was: In Progress)

> 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
>
>
> 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.

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852612#action_12852612 ] 

Hadoop QA commented on ZOOKEEPER-679:
-------------------------------------

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12440556/ZOOKEEPER-679.patch
  against trunk revision 929564.

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 3 new or modified tests.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac compiler warnings.

    +1 findbugs.  The patch does not introduce any new Findbugs warnings.

    +1 release audit.  The applied patch does not increase the total number of release audit warnings.

    +1 core tests.  The patch passed core unit tests.

    +1 contrib tests.  The patch passed contrib unit tests.

Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/42/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/42/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/42/console

This message is automatically generated.

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Attachment: ZOOKEEPER-679.patch

Actual patch to move library to contrib/ztree

> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: Patch Available  (was: Open)

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: Patch Available  (was: In Progress)

> 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
>
>
> 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.

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852869#action_12852869 ] 

Hadoop QA commented on ZOOKEEPER-679:
-------------------------------------

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12440561/ZOOKEEPER-679.patch
  against trunk revision 929564.

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 3 new or modified tests.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac compiler warnings.

    +1 findbugs.  The patch does not introduce any new Findbugs warnings.

    +1 release audit.  The applied patch does not increase the total number of release audit warnings.

    +1 core tests.  The patch passed core unit tests.

    +1 contrib tests.  The patch passed contrib unit tests.

Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/43/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/43/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/43/console

This message is automatically generated.

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: In Progress  (was: Patch Available)

> 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
>
>
> 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.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865540#action_12865540 ] 

Aaron Crow commented on ZOOKEEPER-679:
--------------------------------------

Hi Mahadev, apologies for the delayed response. Yes you're right, I didn't include a build.xml file. I'm really sorry, just haven't found the time to put all that together. 

Related, it's interesting to me what Chris is saying about "abandoned (partly because patch process is too onerous)". When I had the patch in the main project, it was pretty easy to get it running with the main project's test framework. As a standalone contrib, however, I felt kinda stymied because there's real overhead in putting everything together.

Any thoughts from your end on the github approach vs. main project?

Thanks for all your time and help with the patch...


Aaron

> 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.

Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864047#action_12864047 ] 

Mahadev konar commented on ZOOKEEPER-679:
-----------------------------------------

aah just noticed that the src/ztree is missing a build.xml. Did you forget to add a build.xml to the ztree package aaron?

> 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.

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860597#action_12860597 ] 

Hadoop QA commented on ZOOKEEPER-679:
-------------------------------------

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12440561/ZOOKEEPER-679.patch
  against trunk revision 936624.

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 3 new or modified tests.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac compiler warnings.

    +1 findbugs.  The patch does not introduce any new Findbugs warnings.

    +1 release audit.  The applied patch does not increase the total number of release audit warnings.

    +1 core tests.  The patch passed core unit tests.

    +1 contrib tests.  The patch passed contrib unit tests.

Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/72/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/72/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/72/console

This message is automatically generated.

> 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
>
>
> 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mahadev konar updated ZOOKEEPER-679:
------------------------------------

    Status: Open  (was: Patch Available)

> 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
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837960#action_12837960 ] 

Hadoop QA commented on ZOOKEEPER-679:
-------------------------------------

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12436892/ZOOKEEPER-679.patch
  against trunk revision 915466.

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 3 new or modified tests.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac compiler warnings.

    -1 findbugs.  The patch appears to cause Findbugs to fail.

    +1 release audit.  The applied patch does not increase the total number of release audit warnings.

    -1 core tests.  The patch failed core unit tests.

    +1 contrib tests.  The patch passed contrib unit tests.

Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/123/testReport/
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/123/console

This message is automatically generated.

> 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: java client, tests
>            Reporter: Aaron Crow
>            Priority: Minor
>         Attachments: 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] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

Posted by "Aaron Crow (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Crow updated ZOOKEEPER-679:
---------------------------------

    Status: Patch Available  (was: In Progress)

> 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
>
>
> 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.