2011/9/2 Eric Charles <[email protected]>: > On 02/09/11 02:25, Ioan Eugen Stan wrote: >> >> 2011/9/2 Eric Charles<[email protected]>: >>> >>> Hi, >>> >>> Just to inform you I have submitted on a talk '4 mailbox technologies >>> with >>> Apache James 3.0' for the ApacheCon 2011 BarCamp. >>> >>> http://lanyrd.com/2011/apachecon-vancouver-2011-barcamp/ >>> >>> Feel free to feed me with ideas, we can always change the title and the >>> content. >> >> Looks good, I don't have anything to add now, but I decided to hijack >> the thread and inform you that I will be exercising my new commit >> power and upload the mailbox implementation, the integration tests and >> then update everything to follow trunk. I will start sometime these >> days. Any wishes/recommendations are welcomed now. >> > > +1 > > Just put a small comment and a reference to the jira (MAILBOX-44). > > I updated the hg repo, and I've some failures, like cluster is not started > > 11/09/02 04:38:15 WARN zookeeper.ClientCnxn: Session 0x0 for server null, > unexpected error, closing socket connection and attempting reconnect > java.net.ConnectException: Connection refused > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) > at > org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1119)
That's the regression I was talking about. Please run the commit before that. I have no idea what is going on in that commit, everything seems ok. I just switched to using TablePool and I get those kind of errors. I will look over the implementation sometime next week. > >> We will probably have to sync the mailbox HBase singleton with the >> User/Domain HBase singleton. TablePool is implemented but I'm having >> regressions so it will not go into trunk yet. >> > > It would be good to share some classes between mailbox and user/domain > projects. For now, I don't see how we could do, cause we don't want to > introduce a direct dependency between user/domain and mailbox. > > A way to solve it would be to create a common (or util) project, but I find > we already have too much projects, and we should not go this way for now. > > The number of potential class sharing being limited for now, I propose to > leave it as such. Ok, it should not be that much of a problem. We can probably use the same bean in spring to inject the HBase config. Regards, -- Ioan Eugen Stan http://ieugen.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
