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

2010-05-08 Thread Aaron Crow (JIRA)

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

2010-05-08 Thread Aaron Crow (JIRA)

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

2010-04-24 Thread Aaron Crow (JIRA)

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

2010-04-24 Thread Aaron Crow (JIRA)

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

2010-04-24 Thread Aaron Crow (JIRA)

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

2010-04-24 Thread Aaron Crow (JIRA)

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

2010-04-24 Thread Aaron Crow (JIRA)

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

2010-04-24 Thread Aaron Crow (JIRA)

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

2010-04-02 Thread Aaron Crow (JIRA)

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

2010-04-01 Thread Aaron Crow (JIRA)

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

2010-04-01 Thread Aaron Crow (JIRA)

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

2010-04-01 Thread Aaron Crow (JIRA)

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

2010-04-01 Thread Aaron Crow (JIRA)

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

2010-04-01 Thread Aaron Crow (JIRA)

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

2010-04-01 Thread Aaron Crow (JIRA)

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

2010-02-24 Thread Aaron Crow (JIRA)

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

2010-02-24 Thread Aaron Crow (JIRA)

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

2010-02-24 Thread Aaron Crow (JIRA)
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.