Hudson build is back to normal: ZooKeeper-trunk #33
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/33/changes
[jira] Created: (ZOOKEEPER-98) Make the ZooKeeper optional bits seperate jars.
Make the ZooKeeper optional bits seperate jars. --- Key: ZOOKEEPER-98 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-98 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Optional bits like the ZooKeeper jmx module and the upcoming protocol and spring support stuff should get packaged as separate jars so that they don't keep bloating up the main ZooKeeper jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-96) The jute parser should get generated from the jj files instead of checking in the generated sources
[ https://issues.apache.org/jira/browse/ZOOKEEPER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616946#action_12616946 ] Patrick Hunt commented on ZOOKEEPER-96: --- +1, good thing to cleanup The jute parser should get generated from the jj files instead of checking in the generated sources --- Key: ZOOKEEPER-96 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-96 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-95) There is no need to include the code generators in the zookeeper jar
[ https://issues.apache.org/jira/browse/ZOOKEEPER-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616945#action_12616945 ] Patrick Hunt commented on ZOOKEEPER-95: --- +1, looks like that's been happening forever, should clean that up. There is no need to include the code generators in the zookeeper jar Key: ZOOKEEPER-95 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-95 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-97) The code generators should support an optional output directory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616947#action_12616947 ] Patrick Hunt commented on ZOOKEEPER-97: --- +1 The code generators should support an optional output directory --- Key: ZOOKEEPER-97 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-97 Project: Zookeeper Issue Type: Improvement Reporter: Hiram Chirino Currently the code generators (jute compiler and version gen) generate code the current directory. If these tools are to be re-used by smart ides, ant tasks, or maven plugins, the output directory needs to be parameter to the tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-98) Make the ZooKeeper optional bits seperate jars.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616948#action_12616948 ] Patrick Hunt commented on ZOOKEEPER-98: --- +1, does this imply that we should move jmx to contrib? Recipes are slated for contrib, don't know about spring but I'm assuming that it should go into contrib as well. Make the ZooKeeper optional bits seperate jars. --- Key: ZOOKEEPER-98 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-98 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Optional bits like the ZooKeeper jmx module and the upcoming protocol and spring support stuff should get packaged as separate jars so that they don't keep bloating up the main ZooKeeper jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616954#action_12616954 ] chirino edited comment on ZOOKEEPER-82 at 7/25/08 10:13 AM: -- Weird the patch did not change QuorumPeer at all. QuorumPeer did not currently have a main method. Seem someone else moved it to ManagedQuorumPeer. But in my next patch I'll move those java docs and update the scripts. Yes main was moved from ZooKeeperServer to new class which my patch failed to include. Sorry I'll to a attach a new patch asap. Will also add some doco for the getters/setters. was (Author: chirino): Weird the patch did not change QuorumPeer at all. QuorumPeer did not currently have a main method. Seem someone else moved it to ManagedQuorumPeer. But in my next patch I'll move those java docs and update the scripts. Yes main was moved from ZooKeeperServer to new class which my patch failed to include. Sorry I'll to a attach a new patch asap. Will also add some doco for the getters/setters. BTW Make the ZooKeeperServer more DI friendly - Key: ZOOKEEPER-82 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Hiram Chirino Assignee: Hiram Chirino Attachments: ZOOKEEPER-82.patch Proposed changes were discussed in [this mailing list thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL PROTECTED]: Basic goals are: * Decouple the current configuration system from the public API. I see stuff like ZooKeeperServer being coupled to ServerConfig a bit. * Allow the use of setter injection in addition to constructor injection. This is the most important thing needed to let spring more easily configure the objects. * Move the main() methods out of the ZooKeeperServer class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616954#action_12616954 ] Hiram Chirino commented on ZOOKEEPER-82: Weird the patch did not change QuorumPeer at all. QuorumPeer did not currently have a main method. Seem someone else moved it to ManagedQuorumPeer. But in my next patch I'll move those java docs and update the scripts. Yes main was moved from ZooKeeperServer to new class which my patch failed to include. Sorry I'll to a attach a new patch asap. Will also add some doco for the getters/setters. BTW Make the ZooKeeperServer more DI friendly - Key: ZOOKEEPER-82 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Hiram Chirino Assignee: Hiram Chirino Attachments: ZOOKEEPER-82.patch Proposed changes were discussed in [this mailing list thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL PROTECTED]: Basic goals are: * Decouple the current configuration system from the public API. I see stuff like ZooKeeperServer being coupled to ServerConfig a bit. * Allow the use of setter injection in addition to constructor injection. This is the most important thing needed to let spring more easily configure the objects. * Move the main() methods out of the ZooKeeperServer class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-100) Avoid extending Thread in the public ZooKeeper API
Avoid extending Thread in the public ZooKeeper API -- Key: ZOOKEEPER-100 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-100 Project: Zookeeper Issue Type: Improvement Reporter: Hiram Chirino This was discussed in ZOOKEEPER-82 This would allow proper checked exceptions to get thrown when the objects are started/stopped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-59:
Attachment: (was: ZOOKEEPER-59_1.patch)
Synchronized block in NIOServerCnxn
---
Key: ZOOKEEPER-59
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Mahadev konar
There are two synchronized blocks locking on different objects, and to me
they should be guarded by the same object. Here are the parts of the code I'm
talking about:
{noformat}
[EMAIL PROTECTED]
...
synchronized (this) {
outstandingRequests++;
// check throttling
if (zk.getInProcess() factory.outstandingLimit) {
disableRecv();
// following lines should not be needed since we are
already
// reading
// } else {
// enableRecv();
}
}
{noformat}
{noformat}
[EMAIL PROTECTED]
...
synchronized (this.factory) {
outstandingRequests--;
// check throttling
if (zk.getInProcess() factory.outstandingLimit
|| outstandingRequests 1) {
sk.selector().wakeup();
enableRecv();
}
}
{noformat}
I think the second one is correct, and the first synchronized block should be
guarded by this.factory.
This could be related to issue ZOOKEEPER-57, but I have no concrete
indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-59:
Status: Patch Available (was: Open)
Have done what Pat requested... :-)
Synchronized block in NIOServerCnxn
---
Key: ZOOKEEPER-59
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Mahadev konar
Attachments: ZOOKEEPER-59.patch
There are two synchronized blocks locking on different objects, and to me
they should be guarded by the same object. Here are the parts of the code I'm
talking about:
{noformat}
[EMAIL PROTECTED]
...
synchronized (this) {
outstandingRequests++;
// check throttling
if (zk.getInProcess() factory.outstandingLimit) {
disableRecv();
// following lines should not be needed since we are
already
// reading
// } else {
// enableRecv();
}
}
{noformat}
{noformat}
[EMAIL PROTECTED]
...
synchronized (this.factory) {
outstandingRequests--;
// check throttling
if (zk.getInProcess() factory.outstandingLimit
|| outstandingRequests 1) {
sk.selector().wakeup();
enableRecv();
}
}
{noformat}
I think the second one is correct, and the first synchronized block should be
guarded by this.factory.
This could be related to issue ZOOKEEPER-57, but I have no concrete
indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-59:
Attachment: ZOOKEEPER-59.patch
Deleting old patches, and adding a new one that addresses all discussed points.
Synchronized block in NIOServerCnxn
---
Key: ZOOKEEPER-59
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Mahadev konar
Attachments: ZOOKEEPER-59.patch
There are two synchronized blocks locking on different objects, and to me
they should be guarded by the same object. Here are the parts of the code I'm
talking about:
{noformat}
[EMAIL PROTECTED]
...
synchronized (this) {
outstandingRequests++;
// check throttling
if (zk.getInProcess() factory.outstandingLimit) {
disableRecv();
// following lines should not be needed since we are
already
// reading
// } else {
// enableRecv();
}
}
{noformat}
{noformat}
[EMAIL PROTECTED]
...
synchronized (this.factory) {
outstandingRequests--;
// check throttling
if (zk.getInProcess() factory.outstandingLimit
|| outstandingRequests 1) {
sk.selector().wakeup();
enableRecv();
}
}
{noformat}
I think the second one is correct, and the first synchronized block should be
guarded by this.factory.
This could be related to issue ZOOKEEPER-57, but I have no concrete
indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-58) Race condition on ClientCnxn.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-58: Attachment: ZOOKEEPER-58.patch Adding new patch generated against the apache trunk. Race condition on ClientCnxn.java - Key: ZOOKEEPER-58 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-58 Project: Zookeeper Issue Type: Bug Components: java client Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Attachments: ZOOKEEPER-58.patch There is a race condition involving the ByteByffer incomingBuffer, a field of ClientCnxn.SendThread. SendThread reads a packet in two steps: first it reads the length of the packet, followed by a read of the packet itself. Each of these steps corresponds to a call to doIO() from the main loop of run(). If there is an exception or the session times out, then it may leave incomingBuffer in an inconsistent state. The attached patch adds code to reset incomingBuffer upon a call to SendThread.cleanup(). This method is called upon an exception on run(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-58) Race condition on ClientCnxn.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira reassigned ZOOKEEPER-58: --- Assignee: Benjamin Reed (was: Flavio Paiva Junqueira) Ben, you have reviewed this patch before, but since I have regenerated it against the apache trunk, you have to review it again. Race condition on ClientCnxn.java - Key: ZOOKEEPER-58 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-58 Project: Zookeeper Issue Type: Bug Components: java client Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-58.patch There is a race condition involving the ByteByffer incomingBuffer, a field of ClientCnxn.SendThread. SendThread reads a packet in two steps: first it reads the length of the packet, followed by a read of the packet itself. Each of these steps corresponds to a call to doIO() from the main loop of run(). If there is an exception or the session times out, then it may leave incomingBuffer in an inconsistent state. The attached patch adds code to reset incomingBuffer upon a call to SendThread.cleanup(). This method is called upon an exception on run(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-58) Race condition on ClientCnxn.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616998#action_12616998 ] Benjamin Reed commented on ZOOKEEPER-58: +1 Race condition on ClientCnxn.java - Key: ZOOKEEPER-58 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-58 Project: Zookeeper Issue Type: Bug Components: java client Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-58.patch There is a race condition involving the ByteByffer incomingBuffer, a field of ClientCnxn.SendThread. SendThread reads a packet in two steps: first it reads the length of the packet, followed by a read of the packet itself. Each of these steps corresponds to a call to doIO() from the main loop of run(). If there is an exception or the session times out, then it may leave incomingBuffer in an inconsistent state. The attached patch adds code to reset incomingBuffer upon a call to SendThread.cleanup(). This method is called upon an exception on run(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-97) The code generators should support an optional output directory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617000#action_12617000 ] Benjamin Reed commented on ZOOKEEPER-97: One thing to keep in mind is that the jute generators in ZooKeeper really need to be replace with something like thrift, so we probably shouldn't put too much work into them. The code generators should support an optional output directory --- Key: ZOOKEEPER-97 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-97 Project: Zookeeper Issue Type: Improvement Reporter: Hiram Chirino Currently the code generators (jute compiler and version gen) generate code the current directory. If these tools are to be re-used by smart ides, ant tasks, or maven plugins, the output directory needs to be parameter to the tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (ZOOKEEPER-97) The code generators should support an optional output directory
Ben you want to create a jira for marshalling then? Has anyone been tracking Google's protocol buffers, do they have C support yet/planned? Patrick Benjamin Reed (JIRA) wrote: [ https://issues.apache.org/jira/browse/ZOOKEEPER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617000#action_12617000 ] Benjamin Reed commented on ZOOKEEPER-97: One thing to keep in mind is that the jute generators in ZooKeeper really need to be replace with something like thrift, so we probably shouldn't put too much work into them. The code generators should support an optional output directory --- Key: ZOOKEEPER-97 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-97 Project: Zookeeper Issue Type: Improvement Reporter: Hiram Chirino Currently the code generators (jute compiler and version gen) generate code the current directory. If these tools are to be re-used by smart ides, ant tasks, or maven plugins, the output directory needs to be parameter to the tools.
[jira] Updated: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-82: --- Status: Patch Available (was: Open) Make the ZooKeeperServer more DI friendly - Key: ZOOKEEPER-82 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Hiram Chirino Assignee: Hiram Chirino Attachments: ZOOKEEPER-82-b.patch Proposed changes were discussed in [this mailing list thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL PROTECTED]: Basic goals are: * Decouple the current configuration system from the public API. I see stuff like ZooKeeperServer being coupled to ServerConfig a bit. * Allow the use of setter injection in addition to constructor injection. This is the most important thing needed to let spring more easily configure the objects. * Move the main() methods out of the ZooKeeperServer class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-82: --- Attachment: (was: ZOOKEEPER-82-b.patch) Make the ZooKeeperServer more DI friendly - Key: ZOOKEEPER-82 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Hiram Chirino Assignee: Hiram Chirino Attachments: ZOOKEEPER-82-b.patch Proposed changes were discussed in [this mailing list thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL PROTECTED]: Basic goals are: * Decouple the current configuration system from the public API. I see stuff like ZooKeeperServer being coupled to ServerConfig a bit. * Allow the use of setter injection in addition to constructor injection. This is the most important thing needed to let spring more easily configure the objects. * Move the main() methods out of the ZooKeeperServer class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-82: --- Attachment: ZOOKEEPER-82-b.patch Attaching updated patch. Make the ZooKeeperServer more DI friendly - Key: ZOOKEEPER-82 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Hiram Chirino Assignee: Hiram Chirino Attachments: ZOOKEEPER-82-b.patch Proposed changes were discussed in [this mailing list thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL PROTECTED]: Basic goals are: * Decouple the current configuration system from the public API. I see stuff like ZooKeeperServer being coupled to ServerConfig a bit. * Allow the use of setter injection in addition to constructor injection. This is the most important thing needed to let spring more easily configure the objects. * Move the main() methods out of the ZooKeeperServer class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ZooKeeper community
Have you guys setup a zookeeper-private list for the zookeeper ppmc + hadoop pmc to have private discussions? If not, I highly recommend it since it would be the only practical viecel for the ppmc to nominate new commiters or raise sensitive issues the the pmc. Regards, HIram On Wed, Jul 23, 2008 at 4:30 PM, Hiram Chirino [EMAIL PROTECTED] wrote: Ok good... as long as the PMC folks are participating it should not be a problem. Regards, Hiram On Wed, Jul 23, 2008 at 4:12 PM, Doug Cutting [EMAIL PROTECTED] wrote: Hiram Chirino wrote: looks like you guys are not in the PMC. Sorry about that. But it bring us a weird governance issue which is very anti Apahe.. usually an Apache project is self governed, but from the look of the authorization file, it seems like the zookeeper committers cannot properly self govern. It makes things like doing releases, adding new committers and pmc members much more complex since the PMC members are not actively working on the project. PMC members (like me) are expected to monitor the project. I don't moderate this list, but I'd be surprised if a few other PMC members are not also following it. We hope to eventually promote some of Zookeeper's committers to the Hadoop PMC. All seasoned committers should be on the PMC, but the Zookeeper folks are still relative newbies at Apache and none have made it there yet. To some degree the Hadoop PMC is incubating Zookeeper. Zookeeper's committers are like the PPMC. If things go well, as with all Hadoop committers, they'll be nominated to Hadoop's PMC. There'll be no formal graduation, just gradual maturation. If the community diverges sufficiently from Hadoop's, then it may someday make sense to promote Zookeeper to a TLP. Doug -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
[jira] Commented: (ZOOKEEPER-103) Reorganize the ZooKeeper source distro to follow maven conventions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617078#action_12617078 ] Patrick Hunt commented on ZOOKEEPER-103: What about additional contributions, they would be new directories at the same level (child of trunk)? trunk/zookeeper-recipes/..., trunk/zookeeper-spring/..., trunk/zookeeper-fuse/..., etc...? Reorganize the ZooKeeper source distro to follow maven conventions -- Key: ZOOKEEPER-103 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-103 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 3.0.0 Attachments: ZOOKEEPER-103.patch, ZOOKEEPER-103.sh This was sugested as way to bridge the gap in ZOOKEEPER-83 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617081#action_12617081 ] Mahadev konar commented on ZOOKEEPER-83: are we going to close this one then ? Switch to using maven to build ZooKeeper Key: ZOOKEEPER-83 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Assignee: Hiram Chirino Maven is a great too for building java projects at the ASF. It helps standardize the build a bit since it's a convention oriented. It's dependency auto downloading would remove the need to store the dependencies in svn, and it will handle many of the suggested ASF policies like gpg signing of the releases and such. The ZooKeeper build is almost vanilla except for the jute compiler bits. Things that would need to change are: * re-organize the source tree a little so that it uses the maven directory conventions * seperate the jute bits out into seperate modules so that a maven plugin can be with it -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617085#action_12617085 ] Patrick Hunt commented on ZOOKEEPER-83: --- Some additional background: similar request on hadoop core with list of pro/con HADOOP-3302 Switch to using maven to build ZooKeeper Key: ZOOKEEPER-83 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Assignee: Hiram Chirino Maven is a great too for building java projects at the ASF. It helps standardize the build a bit since it's a convention oriented. It's dependency auto downloading would remove the need to store the dependencies in svn, and it will handle many of the suggested ASF policies like gpg signing of the releases and such. The ZooKeeper build is almost vanilla except for the jute compiler bits. Things that would need to change are: * re-organize the source tree a little so that it uses the maven directory conventions * seperate the jute bits out into seperate modules so that a maven plugin can be with it -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-103) Reorganize the ZooKeeper source distro to follow maven conventions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617089#action_12617089 ] Hiram Chirino commented on ZOOKEEPER-103: - Hi Patrick yes. Lots projects just keep it flat like that. Some project will group stuff in a directory if there is a specific grouping to the modules. Generally it's more specific than a general 'contrib' grouping though. Also something to think about is the possibility of having independent release cycles for some of the modules. At this stage of the I don't think we need to worry about that complexity. Benjamin, Generally the final binary distribution does make that distinction. Some organize as: /bin : start scripts /lib : the main zoo keeper jar /lib/extras or /lib/contrib: optional libs that are not required to run ZK /doc : /src etc. etc. Reorganize the ZooKeeper source distro to follow maven conventions -- Key: ZOOKEEPER-103 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-103 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 3.0.0 Attachments: ZOOKEEPER-103.patch, ZOOKEEPER-103.sh This was sugested as way to bridge the gap in ZOOKEEPER-83 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-104) KeptSet: a distributed data stucture backed by the children of a ZooKeeper node
KeptSet: a distributed data stucture backed by the children of a ZooKeeper node --- Key: ZOOKEEPER-104 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-104 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Anthony Urso Priority: Minor Here is an implementation of a ZooKeeper backed Java Set. It should be generally useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-104) KeptSet: a distributed data stucture backed by the children of a ZooKeeper node
[ https://issues.apache.org/jira/browse/ZOOKEEPER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Urso updated ZOOKEEPER-104: --- Attachment: ZOOKEEPER-104.patch KeptSet: a distributed data stucture backed by the children of a ZooKeeper node --- Key: ZOOKEEPER-104 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-104 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Anthony Urso Priority: Minor Attachments: ZOOKEEPER-104.patch Here is an implementation of a ZooKeeper backed Java Set. It should be generally useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-104) KeptSet: a distributed data stucture backed by the children of a ZooKeeper node
[ https://issues.apache.org/jira/browse/ZOOKEEPER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Urso updated ZOOKEEPER-104: --- Status: Patch Available (was: Open) Patch attached. KeptSet: a distributed data stucture backed by the children of a ZooKeeper node --- Key: ZOOKEEPER-104 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-104 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Anthony Urso Priority: Minor Attachments: ZOOKEEPER-104.patch Here is an implementation of a ZooKeeper backed Java Set. It should be generally useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-105) ZooKeeper java client main loop crashes on KeeperExceptions
ZooKeeper java client main loop crashes on KeeperExceptions --- Key: ZOOKEEPER-105 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-105 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Anthony Urso Priority: Minor The ZooKeeper java client main loop crashes on KeeperExceptions. They should be handled when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-105) ZooKeeper java client main loop crashes on KeeperExceptions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Urso updated ZOOKEEPER-105: --- Attachment: ZOOKEEPER-105.patch Patch that wraps the processing of commands with a catch and print. ZooKeeper java client main loop crashes on KeeperExceptions --- Key: ZOOKEEPER-105 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-105 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Anthony Urso Priority: Minor Attachments: ZOOKEEPER-105.patch The ZooKeeper java client main loop crashes on KeeperExceptions. They should be handled when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-105) ZooKeeper java client main loop crashes on KeeperExceptions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Urso updated ZOOKEEPER-105: --- Status: Patch Available (was: Open) Patch attached. ZooKeeper java client main loop crashes on KeeperExceptions --- Key: ZOOKEEPER-105 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-105 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Anthony Urso Priority: Minor Attachments: ZOOKEEPER-105.patch The ZooKeeper java client main loop crashes on KeeperExceptions. They should be handled when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
