You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Pepijn de Vos <pe...@yahoo.com> on 2011/08/13 10:21:22 UTC
NoSQL backend for James
Hey,
I was Googling around for a mail server that I could use with a nice database, so I can query the mail in interesting ways for my webmail/newsgroup/whatever app.
I found a GSOC page that listed this as a possible project. I contacted the mentor (Robert) to see if someone picked it up yet. It seems like that someone is going to be me.
Robert told me to introduce myself and the project here, together with any questions.
For the database I was thinking about a graph database, such as Jiraph. But I think the community might be better served by a CouchDB backend. So what I might do is just run Jiraph on CouchDB.
If you just googled Jiraph, you'd have found it's written in Clojure. I can write Java as well, but if it is not a problem, I prefer Clojure for writing the backend.
This raises my second question: Will the backend be included in James, in an extras repo, or as a separate project? If it's *not* going to be a separate project, requiring Clojure as a runtime dependency might not be desirable.
I previously ran James as a standalone application, and successfully telnet'd into it. However, I could not figure out how to configure which backend to use. Could anyone explain that, or point me at the right documentation?
What would be the best way to start? I found the inmemory backend, which I suppose is the minimal required. Again, any links or explanations about the components are appreciated.
The GSOC description mentioned a REST protocol. What is meant here?
Pepijn de Vos
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 15, 2011 at 8:32 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
<snip>
> I'm still not sure what to think of the REST API. Do you want to have a IMAP 'replacement' that is RESTful, or just an abstraction over a simple key-value store? (I just realized that, in a way, a CouchDB mailbox is already a REST interface to James)
>
> Interesting reading material: http://www.prescod.net/rest/restmail/
:-)
REST [1] is often in the eye of the beholder ;-)
I often like to think of mail as a sea of resources - documents and
directories (and their meta-data) located by uniform descriptors - as
a contrast to the mainstream perspective focused on pushing bits
between file systems over heterogeneous networks. But I'm happy for
anyone else to reach their own opinion on what RESTful mail should
really mean...
Robert
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 21, 2011 at 10:06 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
> Wait, so this means there should be a *zip* inside the target dir? I only have a jar.
>
> I can't see anything wrong with the build, but this is the output: http://pastebin.com/7mrdseTA
>
> I hope someone can help me to get to a state where I can run James and load mailboxes.
The server just builds components. The easiest way to run James and
load mailboxes is to download Apache James 3.0-beta3 [1]. It's spring
based so if you want to blend in new components (for example, mailbox
implementations) just drop in the libraries and edit the
configuration.
This component orientation means that there's no reason to grapple to
understand the entire code base to create new mailbox implementations.
The mailbox source can be checked out independently [2] and the API
browsed online [3].
Robert
[1] http://james.apache.org/download.cgi#Apache_James_Server
[2] http://svn.apache.org/repos/asf/james/mailbox/trunk/
[3] http://svn.apache.org/repos/asf/james/mailbox/trunk/api/src/main/java/org/apache/james/mailbox/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Wait, so this means there should be a *zip* inside the target dir? I only have a jar.
I can't see anything wrong with the build, but this is the output: http://pastebin.com/7mrdseTA
I hope someone can help me to get to a state where I can run James and load mailboxes.
Pepijn
On Aug 16, 2011, at 12:43 AM, Ioan Eugen Stan wrote:
> If you ran the 'mvn package' command you should have that zip in the
> target directory, inside container-spring (at least for version v
> 3.0-m3-snapshot) only if the build succeded. The zip is built by rules
> in the maven pom (search maven assembly).
Re: NoSQL backend for James
Posted by Ioan Eugen Stan <st...@gmail.com>.
2011/10/10 Pepijn de Vos <pe...@yahoo.com>:
> Thanks a lot.
>
> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>
>> Have patience. You will need it if you wish to complete something.
>> Patience and perseverance or else you'll be just another one who
>> tried.
>
> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>
>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>
>> Not sure what you mean by that. It uses dependency injection provided
>> by Spring framework (and soon Guice) to inject object references into
>> other objects at runtime.
>
> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
Yes. The wonders of DI.
>>
>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>
>> I think this is because the configuration changed and now it's spring
>> based, and more modular. I see you are very ambitious but I sense you
>> have a lot of catching up. James is complex so give it time, if you
>> expect too much from yourself and fail you will probably be too
>> disappointed.
> Yea, I read a Java book long ago, never did any big projects with it.
>>
>> Make a public repo, commit something and ask if you get stuck. I will
>> try to help when/if I can. I suggest you start with simple
>> implementation that passes some unit tests.
>
> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
Maven download all it's dependencies. Just declare the group and the
artifact and make sure the repository has those (it will complain if
it doesn't find them). If not, find a maven repo that has them and put
it in your pom.
>>
>> See for example the unit tests I did for Mailbox interface in HBase
>> implementation:
>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
Up to some point, they should be generic because they implement an
API. Unit testing is suposed to test methods individually so they
should be quite simple. They have the purpose to keep you from writing
methods that accept or return values out of the accepted range. They
also keep you from introducing bugs in your implementation. Changes in
your method body will affect your tests. If they fail, something is
wrong. either your method, or your test. Having good tests is very
important.
Unit tests should especially test for boundary values (null, negatives, 0, etc).
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
On Sat, Oct 15, 2011 at 11:41 AM, Pepijn de Vos <pe...@yahoo.com> wrote:
> Thanks! :)
>
> I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
>
> Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
Basically in the mailbox project most stuff needs to know about the
object ID, since the type of the ID depends on the database, you have
to implement Y<String>, it is a way to decouple the mailbox code.
Generics are hard to learn and many times difficult to read though.
>
> The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
There are tons of literature about the matter, tests are cool because
they test the software and detect bugs when something is modified in
the future.
The InMemory test you took, extends AbstractMailboxManagerTest which
is really good since it is able to check a lot of features in all
mailbox implementations.
I have Fixed the test, but it runs very slow compared with jpa or
maildir, so the test can be useful to measure performance but we
should figure out where the problem is.
https://github.com/manolo/james-couchdb/commit/c68a6987e99f58eb4b8345492844cdfd2cb66abd
- Manolo
>
> Pepijn
>
> On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
>
>> You are right, you already sent the github link.
>>
>> I've checked out the code and I've made some changes to make it
>> compile, also I have changed id signature in messages and mailboxes to
>> String since couchdb uses string. I have hardcoded a user and password
>> in the Utils class, it should go in the configuration files though.
>>
>> I just have sent you a pull request
>> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>>
>> The unique Test in the tree do no pass, I think you can start fixing
>> the test so as it should be easier to follow the code taking a look to
>> tests.
>>
>> - Manolo
>>
>>
>> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>>
>>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>>
>>> Pepijn
>>>
>>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>>
>>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>>> could checkout it and take a look?
>>>>
>>>> Don't worry about if the code is ok or not, I think github could be
>>>> ok, but you could send a compressed file via email or whatever you
>>>> prefer.
>>>>
>>>> - Manolo
>>>>
>>>>
>>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>> Okay, I put up the result for the day.
>>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>>
>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>
>>>>> Pepijn
>>>>>
>>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>>
>>>>>> More questions. I started hacking!
>>>>>>
>>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>>
>>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>>
>>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>>
>>>>>> I'm getting there!
>>>>>>
>>>>>> Pepijn
>>>>>>
>>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>>
>>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>>
>>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>>> etc should be created.
>>>>>>>
>>>>>>> - Manolo
>>>>>>>
>>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>>
>>>>>>>> Pepijn
>>>>>>>>
>>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>
>>>>>>>>> Hi Pepijn
>>>>>>>>>
>>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>>
>>>>>>>>> - Manolo
>>>>>>>>>
>>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>>
>>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks a lot.
>>>>>>>>>>
>>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>>
>>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>>> tried.
>>>>>>>>>>
>>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>>
>>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>>
>>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>>> other objects at runtime.
>>>>>>>>>>
>>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>>
>>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>>
>>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>>> disappointed.
>>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>>
>>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>>
>>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>>
>>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>>> implementation:
>>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>>
>>>>>>>>>> Pepijn
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
>
> Why not adding the presentation or its link to the hupa documentation? We
> are lacking good documentation.
>
Although, I already added a presentations link to the James front page
in the wiki, i think it is a good idea.
Also, the hupa maven site was generated a long time ago and has not
been updated.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Felix Knecht <fe...@apache.org>.
On 10/31/2011 04:17 PM, Manuel Carrasco Moñino wrote:
> Hello Pepijn
>
> On Fri, Oct 28, 2011 at 3:12 PM, Pepijn de Vos<pe...@yahoo.com> wrote:
>> Hi,
>>
>> I decided to stop working on the CouchDB backend. I'm sorry.
>
> Bad news, it was a good idea James supporting couchdb
>
>>
>> There is something to be said for persisting and finishing, but I do not enjoy writing it and I don't need it. I'm going to focus instead on what I set out to do, write a webmail application. I will persist in that.
>>
>> I learned that what I wanted to do is not a good design at all. I thought it would be easy to write my webmail application on top of CouchDB and have James "fish from the same pool". This would create a tight coupling between my app and James, and leaves me at the mercy of future changes to the API.
>>
>> Instead, I'll just write my app on top of IMAP, and in fact, I couldn't care less how the mail server stores my email.
>
> Yeah, this is the approach used by HUPA (the webmail of James), take
> a look to its architecture in this presentation:
> http://www.slideshare.net/dodotis/apache-jameshupa-gwt
Why not adding the presentation or its link to the hupa documentation?
We are lacking good documentation.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
Hello Pepijn
On Fri, Oct 28, 2011 at 3:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
> Hi,
>
> I decided to stop working on the CouchDB backend. I'm sorry.
Bad news, it was a good idea James supporting couchdb
>
> There is something to be said for persisting and finishing, but I do not enjoy writing it and I don't need it. I'm going to focus instead on what I set out to do, write a webmail application. I will persist in that.
>
> I learned that what I wanted to do is not a good design at all. I thought it would be easy to write my webmail application on top of CouchDB and have James "fish from the same pool". This would create a tight coupling between my app and James, and leaves me at the mercy of future changes to the API.
>
> Instead, I'll just write my app on top of IMAP, and in fact, I couldn't care less how the mail server stores my email.
Yeah, this is the approach used by HUPA (the webmail of James), take
a look to its architecture in this presentation:
http://www.slideshare.net/dodotis/apache-jameshupa-gwt
IMAP is a good election since you will have your app decoupled from
the email server implementation, but you will need a backend able to
communicate with the imap server and cache session credentials etc, so
you have to think in clustering this tier. Using couchdb rest
services, the clustering should be easier and proly it should perform
better.
>
> Thank you very, very much for your patience, help and support. I learned quite a few things about Java and IMAP.
>
> If anyone does need a CouchDB backend, my code so far lives at https://github.com/pepijndevos/james-couchdb
Thank you, you did a good job with the implementation, I'm sure it can
be a good base of a couchdb mailbox implementation soon.
Cheers
- Manolo
>
> Pepijn
>
> On Oct 17, 2011, at 1:54 PM, Pepijn de Vos wrote:
>
>> Ah, it's just that I caught the wrong exception in my code. I'll fix that.
>>
>> On Oct 17, 2011, at 1:51 PM, Manuel Carrasco Moñino wrote:
>>
>>> I have added the Stress test and I see the exception, not sure how to fix yet.
>>> https://github.com/manolo/james-couchdb/commit/cf9a41116fca458c440a28ec937b83aeccd7967a
>>>
>>> - Manolo
>>>
>>> Exception in thread "pool-5-thread-61"
>>> org.ektorp.UpdateConflictException: document update conflict: id:
>>> 5e04b2a2c6fd920bc09af5a675000e7d rev:
>>> 3-ce227ff7c45a6905e010684f08011d05
>>> at org.ektorp.impl.StdCouchDbConnector$6.error(StdCouchDbConnector.java:319)
>>> at org.ektorp.impl.StdCouchDbConnector$6.error(StdCouchDbConnector.java:308)
>>> at org.ektorp.http.RestTemplate.handleResponse(RestTemplate.java:98)
>>> at org.ektorp.http.RestTemplate.put(RestTemplate.java:38)
>>> at org.ektorp.impl.StdCouchDbConnector.update(StdCouchDbConnector.java:307)
>>> at org.ektorp.support.CouchDbRepositorySupport.update(CouchDbRepositorySupport.java:155)
>>> at org.apache.james.mailbox.couchdb.mail.CouchDbMailboxMapper.save(CouchDbMailboxMapper.java:90)
>>> at org.apache.james.mailbox.couchdb.mail.CouchDbUidProvider.nextUid(CouchDbUidProvider.java:39)
>>> at org.apache.james.mailbox.store.mail.AbstractMessageMapper.add(AbstractMessageMapper.java:125)
>>> at org.apache.james.mailbox.store.StoreMessageManager$4.run(StoreMessageManager.java:532)
>>> at org.apache.james.mailbox.store.StoreMessageManager$4.run(StoreMessageManager.java:1)
>>> at org.apache.james.mailbox.store.transaction.TransactionalMapper.execute(TransactionalMapper.java:38)
>>> at org.apache.james.mailbox.store.StoreMessageManager.appendMessageToStore(StoreMessageManager.java:529)
>>> at org.apache.james.mailbox.store.StoreMessageManager$1.execute(StoreMessageManager.java:326)
>>> at org.apache.james.mailbox.store.StoreMessageManager$1.execute(StoreMessageManager.java:1)
>>> at org.apache.james.mailbox.store.AbstractMailboxPathLocker.executeWithLock(AbstractMailboxPathLocker.java:41)
>>> at org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:322)
>>> at org.apache.james.mailbox.AbstractStressTest$2.run(AbstractStressTest.java:92)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>> at java.lang.Thread.run(Thread.java:662)
>>>
>>> On Sun, Oct 16, 2011 at 6:24 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>> Thanks man, really appreciated.
>>>>
>>>> I too think my ModSeq impl looks good, but incrementing the modSeq 4 times in parallel, I noticed that
>>>>
>>>> the value is incremented only 2-3 times.
>>>> _rev is incremented even less.
>>>> additional documents get created.
>>>>
>>>> What happens is that the same mailbox object gets passed to all invocations of nextModSeq. This means that incrementing them in one increments it everywhere. Normally this would only create conflicts in all but one, but because this mailbox does not have an id yet, it creates a new mailbox for every conflict.
>>>>
>>>> So I assume this is not a problem in practice? Because after your fix, all created mailboxes actually do have an id. I'll test that later, and then try to figure out JUnit.
>>>>
>>>> Pepijn
>>>>
>>>> On Oct 16, 2011, at 4:23 PM, Manuel Carrasco Moñino wrote:
>>>>
>>>>> On Sat, Oct 15, 2011 at 5:40 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>> So, the result and questions for today:
>>>>>>
>>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>>
>>>>>> What is serialVersionUID?
>>>>>
>>>>> It is a good practice to define it for serializable classes
>>>>> http://www.javapractices.com/topic/TopicAction.do?Id=45
>>>>>
>>>>>>
>>>>>> Is UidValidity something else than what is provided by CouchDbUidProvider?
>>>>>
>>>>> It's a number that changes when all uids become invalid. The server
>>>>> cannot update this number during a session.
>>>>> http://www.afterlogic.com/mailbee-net/docs/MailBee.ImapMail.Imap.UidValidity.html
>>>>>
>>>>>>
>>>>>> I had a look at the InMemory test, and it seems to fail on remainders of the InMemory implementation(mentions of ConcurrentHashmap). I'm not sure what it tests, but I think it's more than just CouchDbMailboxManager.
>>>>>>
>>>>>> Today I tried to implement ModSeq and Uid. They work fine until you introduce concurrency. I'd be glad if someone would take a look at nextModSeq.
>>>>>
>>>>> Your implementation looks good.
>>>>>
>>>>>>
>>>>>> I'll try to write a test for it tomorrow. The thing is that the test would need the database, right? How do you handle that?
>>>>>
>>>>> Difficult since it seems there is no way to install couchdb and start
>>>>> it from maven.
>>>>> Right now tests should be ignored when ddbb is not running (see
>>>>> maildir tests which are omitted in windows systems)
>>>>> I've added in the setup a call to empty the 'james' database when the
>>>>> test run, also I have added initStandardDesignDocument() to
>>>>> initialize database.
>>>>> Be careful before run the test if you do not want the ddbb be re-created.
>>>>>
>>>>> Happy coding.
>>>>> - Manolo
>>>>>
>>>>>>
>>>>>> Pepijn
>>>>>>
>>>>>> On Oct 15, 2011, at 11:41 AM, Pepijn de Vos wrote:
>>>>>>
>>>>>>> Thanks! :)
>>>>>>>
>>>>>>> I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
>>>>>>>
>>>>>>> Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
>>>>>>>
>>>>>>> The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
>>>>>>>
>>>>>>> Pepijn
>>>>>>>
>>>>>>> On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
>>>>>>>
>>>>>>>> You are right, you already sent the github link.
>>>>>>>>
>>>>>>>> I've checked out the code and I've made some changes to make it
>>>>>>>> compile, also I have changed id signature in messages and mailboxes to
>>>>>>>> String since couchdb uses string. I have hardcoded a user and password
>>>>>>>> in the Utils class, it should go in the configuration files though.
>>>>>>>>
>>>>>>>> I just have sent you a pull request
>>>>>>>> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>>>>>>>>
>>>>>>>> The unique Test in the tree do no pass, I think you can start fixing
>>>>>>>> the test so as it should be easier to follow the code taking a look to
>>>>>>>> tests.
>>>>>>>>
>>>>>>>> - Manolo
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>>>>>>>>
>>>>>>>>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>>>>>>>>
>>>>>>>>> Pepijn
>>>>>>>>>
>>>>>>>>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>
>>>>>>>>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>>>>>>>>> could checkout it and take a look?
>>>>>>>>>>
>>>>>>>>>> Don't worry about if the code is ok or not, I think github could be
>>>>>>>>>> ok, but you could send a compressed file via email or whatever you
>>>>>>>>>> prefer.
>>>>>>>>>>
>>>>>>>>>> - Manolo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>> Okay, I put up the result for the day.
>>>>>>>>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>>>>>>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>>>>>>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>>>>>>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>>>>>>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>>>>>>>
>>>>>>>>>>> Pepijn
>>>>>>>>>>>
>>>>>>>>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>>>>>>>>
>>>>>>>>>>>> More questions. I started hacking!
>>>>>>>>>>>>
>>>>>>>>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>>>>>>>>
>>>>>>>>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>>>>>>>>
>>>>>>>>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm getting there!
>>>>>>>>>>>>
>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>>>>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>>>>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>>>>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>>>>>>>>> etc should be created.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Manolo
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Pepijn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Manolo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks a lot.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>>>>>>>>> tried.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>>>>>>>>> other objects at runtime.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>>>>>>>>> disappointed.
>>>>>>>>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>>>>>>>>> implementation:
>>>>>>>>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Hi,
I decided to stop working on the CouchDB backend. I'm sorry.
There is something to be said for persisting and finishing, but I do not enjoy writing it and I don't need it. I'm going to focus instead on what I set out to do, write a webmail application. I will persist in that.
I learned that what I wanted to do is not a good design at all. I thought it would be easy to write my webmail application on top of CouchDB and have James "fish from the same pool". This would create a tight coupling between my app and James, and leaves me at the mercy of future changes to the API.
Instead, I'll just write my app on top of IMAP, and in fact, I couldn't care less how the mail server stores my email.
Thank you very, very much for your patience, help and support. I learned quite a few things about Java and IMAP.
If anyone does need a CouchDB backend, my code so far lives at https://github.com/pepijndevos/james-couchdb
Pepijn
On Oct 17, 2011, at 1:54 PM, Pepijn de Vos wrote:
> Ah, it's just that I caught the wrong exception in my code. I'll fix that.
>
> On Oct 17, 2011, at 1:51 PM, Manuel Carrasco Moñino wrote:
>
>> I have added the Stress test and I see the exception, not sure how to fix yet.
>> https://github.com/manolo/james-couchdb/commit/cf9a41116fca458c440a28ec937b83aeccd7967a
>>
>> - Manolo
>>
>> Exception in thread "pool-5-thread-61"
>> org.ektorp.UpdateConflictException: document update conflict: id:
>> 5e04b2a2c6fd920bc09af5a675000e7d rev:
>> 3-ce227ff7c45a6905e010684f08011d05
>> at org.ektorp.impl.StdCouchDbConnector$6.error(StdCouchDbConnector.java:319)
>> at org.ektorp.impl.StdCouchDbConnector$6.error(StdCouchDbConnector.java:308)
>> at org.ektorp.http.RestTemplate.handleResponse(RestTemplate.java:98)
>> at org.ektorp.http.RestTemplate.put(RestTemplate.java:38)
>> at org.ektorp.impl.StdCouchDbConnector.update(StdCouchDbConnector.java:307)
>> at org.ektorp.support.CouchDbRepositorySupport.update(CouchDbRepositorySupport.java:155)
>> at org.apache.james.mailbox.couchdb.mail.CouchDbMailboxMapper.save(CouchDbMailboxMapper.java:90)
>> at org.apache.james.mailbox.couchdb.mail.CouchDbUidProvider.nextUid(CouchDbUidProvider.java:39)
>> at org.apache.james.mailbox.store.mail.AbstractMessageMapper.add(AbstractMessageMapper.java:125)
>> at org.apache.james.mailbox.store.StoreMessageManager$4.run(StoreMessageManager.java:532)
>> at org.apache.james.mailbox.store.StoreMessageManager$4.run(StoreMessageManager.java:1)
>> at org.apache.james.mailbox.store.transaction.TransactionalMapper.execute(TransactionalMapper.java:38)
>> at org.apache.james.mailbox.store.StoreMessageManager.appendMessageToStore(StoreMessageManager.java:529)
>> at org.apache.james.mailbox.store.StoreMessageManager$1.execute(StoreMessageManager.java:326)
>> at org.apache.james.mailbox.store.StoreMessageManager$1.execute(StoreMessageManager.java:1)
>> at org.apache.james.mailbox.store.AbstractMailboxPathLocker.executeWithLock(AbstractMailboxPathLocker.java:41)
>> at org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:322)
>> at org.apache.james.mailbox.AbstractStressTest$2.run(AbstractStressTest.java:92)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> at java.lang.Thread.run(Thread.java:662)
>>
>> On Sun, Oct 16, 2011 at 6:24 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>> Thanks man, really appreciated.
>>>
>>> I too think my ModSeq impl looks good, but incrementing the modSeq 4 times in parallel, I noticed that
>>>
>>> the value is incremented only 2-3 times.
>>> _rev is incremented even less.
>>> additional documents get created.
>>>
>>> What happens is that the same mailbox object gets passed to all invocations of nextModSeq. This means that incrementing them in one increments it everywhere. Normally this would only create conflicts in all but one, but because this mailbox does not have an id yet, it creates a new mailbox for every conflict.
>>>
>>> So I assume this is not a problem in practice? Because after your fix, all created mailboxes actually do have an id. I'll test that later, and then try to figure out JUnit.
>>>
>>> Pepijn
>>>
>>> On Oct 16, 2011, at 4:23 PM, Manuel Carrasco Moñino wrote:
>>>
>>>> On Sat, Oct 15, 2011 at 5:40 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>> So, the result and questions for today:
>>>>>
>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>
>>>>> What is serialVersionUID?
>>>>
>>>> It is a good practice to define it for serializable classes
>>>> http://www.javapractices.com/topic/TopicAction.do?Id=45
>>>>
>>>>>
>>>>> Is UidValidity something else than what is provided by CouchDbUidProvider?
>>>>
>>>> It's a number that changes when all uids become invalid. The server
>>>> cannot update this number during a session.
>>>> http://www.afterlogic.com/mailbee-net/docs/MailBee.ImapMail.Imap.UidValidity.html
>>>>
>>>>>
>>>>> I had a look at the InMemory test, and it seems to fail on remainders of the InMemory implementation(mentions of ConcurrentHashmap). I'm not sure what it tests, but I think it's more than just CouchDbMailboxManager.
>>>>>
>>>>> Today I tried to implement ModSeq and Uid. They work fine until you introduce concurrency. I'd be glad if someone would take a look at nextModSeq.
>>>>
>>>> Your implementation looks good.
>>>>
>>>>>
>>>>> I'll try to write a test for it tomorrow. The thing is that the test would need the database, right? How do you handle that?
>>>>
>>>> Difficult since it seems there is no way to install couchdb and start
>>>> it from maven.
>>>> Right now tests should be ignored when ddbb is not running (see
>>>> maildir tests which are omitted in windows systems)
>>>> I've added in the setup a call to empty the 'james' database when the
>>>> test run, also I have added initStandardDesignDocument() to
>>>> initialize database.
>>>> Be careful before run the test if you do not want the ddbb be re-created.
>>>>
>>>> Happy coding.
>>>> - Manolo
>>>>
>>>>>
>>>>> Pepijn
>>>>>
>>>>> On Oct 15, 2011, at 11:41 AM, Pepijn de Vos wrote:
>>>>>
>>>>>> Thanks! :)
>>>>>>
>>>>>> I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
>>>>>>
>>>>>> Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
>>>>>>
>>>>>> The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
>>>>>>
>>>>>> Pepijn
>>>>>>
>>>>>> On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
>>>>>>
>>>>>>> You are right, you already sent the github link.
>>>>>>>
>>>>>>> I've checked out the code and I've made some changes to make it
>>>>>>> compile, also I have changed id signature in messages and mailboxes to
>>>>>>> String since couchdb uses string. I have hardcoded a user and password
>>>>>>> in the Utils class, it should go in the configuration files though.
>>>>>>>
>>>>>>> I just have sent you a pull request
>>>>>>> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>>>>>>>
>>>>>>> The unique Test in the tree do no pass, I think you can start fixing
>>>>>>> the test so as it should be easier to follow the code taking a look to
>>>>>>> tests.
>>>>>>>
>>>>>>> - Manolo
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>>>>>>>
>>>>>>>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>>>>>>>
>>>>>>>> Pepijn
>>>>>>>>
>>>>>>>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>
>>>>>>>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>>>>>>>> could checkout it and take a look?
>>>>>>>>>
>>>>>>>>> Don't worry about if the code is ok or not, I think github could be
>>>>>>>>> ok, but you could send a compressed file via email or whatever you
>>>>>>>>> prefer.
>>>>>>>>>
>>>>>>>>> - Manolo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>> Okay, I put up the result for the day.
>>>>>>>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>>>>>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>>>>>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>>>>>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>>>>>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>>>>>>>
>>>>>>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>>>>>>
>>>>>>>>>> Pepijn
>>>>>>>>>>
>>>>>>>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>>>>>>>
>>>>>>>>>>> More questions. I started hacking!
>>>>>>>>>>>
>>>>>>>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>>>>>>>
>>>>>>>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>>>>>>>
>>>>>>>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>>>>>>>
>>>>>>>>>>> I'm getting there!
>>>>>>>>>>>
>>>>>>>>>>> Pepijn
>>>>>>>>>>>
>>>>>>>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>>>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>>>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>>>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>>>>>>>> etc should be created.
>>>>>>>>>>>>
>>>>>>>>>>>> - Manolo
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Pepijn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Manolo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks a lot.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>>>>>>>> tried.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>>>>>>>> other objects at runtime.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>>>>>>>> disappointed.
>>>>>>>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>>>>>>>> implementation:
>>>>>>>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Ah, it's just that I caught the wrong exception in my code. I'll fix that.
On Oct 17, 2011, at 1:51 PM, Manuel Carrasco Moñino wrote:
> I have added the Stress test and I see the exception, not sure how to fix yet.
> https://github.com/manolo/james-couchdb/commit/cf9a41116fca458c440a28ec937b83aeccd7967a
>
> - Manolo
>
> Exception in thread "pool-5-thread-61"
> org.ektorp.UpdateConflictException: document update conflict: id:
> 5e04b2a2c6fd920bc09af5a675000e7d rev:
> 3-ce227ff7c45a6905e010684f08011d05
> at org.ektorp.impl.StdCouchDbConnector$6.error(StdCouchDbConnector.java:319)
> at org.ektorp.impl.StdCouchDbConnector$6.error(StdCouchDbConnector.java:308)
> at org.ektorp.http.RestTemplate.handleResponse(RestTemplate.java:98)
> at org.ektorp.http.RestTemplate.put(RestTemplate.java:38)
> at org.ektorp.impl.StdCouchDbConnector.update(StdCouchDbConnector.java:307)
> at org.ektorp.support.CouchDbRepositorySupport.update(CouchDbRepositorySupport.java:155)
> at org.apache.james.mailbox.couchdb.mail.CouchDbMailboxMapper.save(CouchDbMailboxMapper.java:90)
> at org.apache.james.mailbox.couchdb.mail.CouchDbUidProvider.nextUid(CouchDbUidProvider.java:39)
> at org.apache.james.mailbox.store.mail.AbstractMessageMapper.add(AbstractMessageMapper.java:125)
> at org.apache.james.mailbox.store.StoreMessageManager$4.run(StoreMessageManager.java:532)
> at org.apache.james.mailbox.store.StoreMessageManager$4.run(StoreMessageManager.java:1)
> at org.apache.james.mailbox.store.transaction.TransactionalMapper.execute(TransactionalMapper.java:38)
> at org.apache.james.mailbox.store.StoreMessageManager.appendMessageToStore(StoreMessageManager.java:529)
> at org.apache.james.mailbox.store.StoreMessageManager$1.execute(StoreMessageManager.java:326)
> at org.apache.james.mailbox.store.StoreMessageManager$1.execute(StoreMessageManager.java:1)
> at org.apache.james.mailbox.store.AbstractMailboxPathLocker.executeWithLock(AbstractMailboxPathLocker.java:41)
> at org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:322)
> at org.apache.james.mailbox.AbstractStressTest$2.run(AbstractStressTest.java:92)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
>
> On Sun, Oct 16, 2011 at 6:24 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>> Thanks man, really appreciated.
>>
>> I too think my ModSeq impl looks good, but incrementing the modSeq 4 times in parallel, I noticed that
>>
>> the value is incremented only 2-3 times.
>> _rev is incremented even less.
>> additional documents get created.
>>
>> What happens is that the same mailbox object gets passed to all invocations of nextModSeq. This means that incrementing them in one increments it everywhere. Normally this would only create conflicts in all but one, but because this mailbox does not have an id yet, it creates a new mailbox for every conflict.
>>
>> So I assume this is not a problem in practice? Because after your fix, all created mailboxes actually do have an id. I'll test that later, and then try to figure out JUnit.
>>
>> Pepijn
>>
>> On Oct 16, 2011, at 4:23 PM, Manuel Carrasco Moñino wrote:
>>
>>> On Sat, Oct 15, 2011 at 5:40 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>> So, the result and questions for today:
>>>>
>>>> https://github.com/pepijndevos/james-couchdb
>>>>
>>>> What is serialVersionUID?
>>>
>>> It is a good practice to define it for serializable classes
>>> http://www.javapractices.com/topic/TopicAction.do?Id=45
>>>
>>>>
>>>> Is UidValidity something else than what is provided by CouchDbUidProvider?
>>>
>>> It's a number that changes when all uids become invalid. The server
>>> cannot update this number during a session.
>>> http://www.afterlogic.com/mailbee-net/docs/MailBee.ImapMail.Imap.UidValidity.html
>>>
>>>>
>>>> I had a look at the InMemory test, and it seems to fail on remainders of the InMemory implementation(mentions of ConcurrentHashmap). I'm not sure what it tests, but I think it's more than just CouchDbMailboxManager.
>>>>
>>>> Today I tried to implement ModSeq and Uid. They work fine until you introduce concurrency. I'd be glad if someone would take a look at nextModSeq.
>>>
>>> Your implementation looks good.
>>>
>>>>
>>>> I'll try to write a test for it tomorrow. The thing is that the test would need the database, right? How do you handle that?
>>>
>>> Difficult since it seems there is no way to install couchdb and start
>>> it from maven.
>>> Right now tests should be ignored when ddbb is not running (see
>>> maildir tests which are omitted in windows systems)
>>> I've added in the setup a call to empty the 'james' database when the
>>> test run, also I have added initStandardDesignDocument() to
>>> initialize database.
>>> Be careful before run the test if you do not want the ddbb be re-created.
>>>
>>> Happy coding.
>>> - Manolo
>>>
>>>>
>>>> Pepijn
>>>>
>>>> On Oct 15, 2011, at 11:41 AM, Pepijn de Vos wrote:
>>>>
>>>>> Thanks! :)
>>>>>
>>>>> I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
>>>>>
>>>>> Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
>>>>>
>>>>> The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
>>>>>
>>>>> Pepijn
>>>>>
>>>>> On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
>>>>>
>>>>>> You are right, you already sent the github link.
>>>>>>
>>>>>> I've checked out the code and I've made some changes to make it
>>>>>> compile, also I have changed id signature in messages and mailboxes to
>>>>>> String since couchdb uses string. I have hardcoded a user and password
>>>>>> in the Utils class, it should go in the configuration files though.
>>>>>>
>>>>>> I just have sent you a pull request
>>>>>> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>>>>>>
>>>>>> The unique Test in the tree do no pass, I think you can start fixing
>>>>>> the test so as it should be easier to follow the code taking a look to
>>>>>> tests.
>>>>>>
>>>>>> - Manolo
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>>>>>>
>>>>>>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>>>>>>
>>>>>>> Pepijn
>>>>>>>
>>>>>>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>>>>>>
>>>>>>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>>>>>>> could checkout it and take a look?
>>>>>>>>
>>>>>>>> Don't worry about if the code is ok or not, I think github could be
>>>>>>>> ok, but you could send a compressed file via email or whatever you
>>>>>>>> prefer.
>>>>>>>>
>>>>>>>> - Manolo
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>> Okay, I put up the result for the day.
>>>>>>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>>>>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>>>>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>>>>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>>>>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>>>>>>
>>>>>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>>>>>
>>>>>>>>> Pepijn
>>>>>>>>>
>>>>>>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>>>>>>
>>>>>>>>>> More questions. I started hacking!
>>>>>>>>>>
>>>>>>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>>>>>>
>>>>>>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>>>>>>
>>>>>>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>>>>>>
>>>>>>>>>> I'm getting there!
>>>>>>>>>>
>>>>>>>>>> Pepijn
>>>>>>>>>>
>>>>>>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>>
>>>>>>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>>>>>>
>>>>>>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>>>>>>> etc should be created.
>>>>>>>>>>>
>>>>>>>>>>> - Manolo
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>>>>>>
>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Pepijn
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Manolo
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks a lot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>>>>>>> tried.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>>>>>>> other objects at runtime.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>>>>>>> disappointed.
>>>>>>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>>>>>>> implementation:
>>>>>>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
I have added the Stress test and I see the exception, not sure how to fix yet.
https://github.com/manolo/james-couchdb/commit/cf9a41116fca458c440a28ec937b83aeccd7967a
- Manolo
Exception in thread "pool-5-thread-61"
org.ektorp.UpdateConflictException: document update conflict: id:
5e04b2a2c6fd920bc09af5a675000e7d rev:
3-ce227ff7c45a6905e010684f08011d05
at org.ektorp.impl.StdCouchDbConnector$6.error(StdCouchDbConnector.java:319)
at org.ektorp.impl.StdCouchDbConnector$6.error(StdCouchDbConnector.java:308)
at org.ektorp.http.RestTemplate.handleResponse(RestTemplate.java:98)
at org.ektorp.http.RestTemplate.put(RestTemplate.java:38)
at org.ektorp.impl.StdCouchDbConnector.update(StdCouchDbConnector.java:307)
at org.ektorp.support.CouchDbRepositorySupport.update(CouchDbRepositorySupport.java:155)
at org.apache.james.mailbox.couchdb.mail.CouchDbMailboxMapper.save(CouchDbMailboxMapper.java:90)
at org.apache.james.mailbox.couchdb.mail.CouchDbUidProvider.nextUid(CouchDbUidProvider.java:39)
at org.apache.james.mailbox.store.mail.AbstractMessageMapper.add(AbstractMessageMapper.java:125)
at org.apache.james.mailbox.store.StoreMessageManager$4.run(StoreMessageManager.java:532)
at org.apache.james.mailbox.store.StoreMessageManager$4.run(StoreMessageManager.java:1)
at org.apache.james.mailbox.store.transaction.TransactionalMapper.execute(TransactionalMapper.java:38)
at org.apache.james.mailbox.store.StoreMessageManager.appendMessageToStore(StoreMessageManager.java:529)
at org.apache.james.mailbox.store.StoreMessageManager$1.execute(StoreMessageManager.java:326)
at org.apache.james.mailbox.store.StoreMessageManager$1.execute(StoreMessageManager.java:1)
at org.apache.james.mailbox.store.AbstractMailboxPathLocker.executeWithLock(AbstractMailboxPathLocker.java:41)
at org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:322)
at org.apache.james.mailbox.AbstractStressTest$2.run(AbstractStressTest.java:92)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
On Sun, Oct 16, 2011 at 6:24 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
> Thanks man, really appreciated.
>
> I too think my ModSeq impl looks good, but incrementing the modSeq 4 times in parallel, I noticed that
>
> the value is incremented only 2-3 times.
> _rev is incremented even less.
> additional documents get created.
>
> What happens is that the same mailbox object gets passed to all invocations of nextModSeq. This means that incrementing them in one increments it everywhere. Normally this would only create conflicts in all but one, but because this mailbox does not have an id yet, it creates a new mailbox for every conflict.
>
> So I assume this is not a problem in practice? Because after your fix, all created mailboxes actually do have an id. I'll test that later, and then try to figure out JUnit.
>
> Pepijn
>
> On Oct 16, 2011, at 4:23 PM, Manuel Carrasco Moñino wrote:
>
>> On Sat, Oct 15, 2011 at 5:40 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>> So, the result and questions for today:
>>>
>>> https://github.com/pepijndevos/james-couchdb
>>>
>>> What is serialVersionUID?
>>
>> It is a good practice to define it for serializable classes
>> http://www.javapractices.com/topic/TopicAction.do?Id=45
>>
>>>
>>> Is UidValidity something else than what is provided by CouchDbUidProvider?
>>
>> It's a number that changes when all uids become invalid. The server
>> cannot update this number during a session.
>> http://www.afterlogic.com/mailbee-net/docs/MailBee.ImapMail.Imap.UidValidity.html
>>
>>>
>>> I had a look at the InMemory test, and it seems to fail on remainders of the InMemory implementation(mentions of ConcurrentHashmap). I'm not sure what it tests, but I think it's more than just CouchDbMailboxManager.
>>>
>>> Today I tried to implement ModSeq and Uid. They work fine until you introduce concurrency. I'd be glad if someone would take a look at nextModSeq.
>>
>> Your implementation looks good.
>>
>>>
>>> I'll try to write a test for it tomorrow. The thing is that the test would need the database, right? How do you handle that?
>>
>> Difficult since it seems there is no way to install couchdb and start
>> it from maven.
>> Right now tests should be ignored when ddbb is not running (see
>> maildir tests which are omitted in windows systems)
>> I've added in the setup a call to empty the 'james' database when the
>> test run, also I have added initStandardDesignDocument() to
>> initialize database.
>> Be careful before run the test if you do not want the ddbb be re-created.
>>
>> Happy coding.
>> - Manolo
>>
>>>
>>> Pepijn
>>>
>>> On Oct 15, 2011, at 11:41 AM, Pepijn de Vos wrote:
>>>
>>>> Thanks! :)
>>>>
>>>> I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
>>>>
>>>> Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
>>>>
>>>> The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
>>>>
>>>> Pepijn
>>>>
>>>> On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
>>>>
>>>>> You are right, you already sent the github link.
>>>>>
>>>>> I've checked out the code and I've made some changes to make it
>>>>> compile, also I have changed id signature in messages and mailboxes to
>>>>> String since couchdb uses string. I have hardcoded a user and password
>>>>> in the Utils class, it should go in the configuration files though.
>>>>>
>>>>> I just have sent you a pull request
>>>>> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>>>>>
>>>>> The unique Test in the tree do no pass, I think you can start fixing
>>>>> the test so as it should be easier to follow the code taking a look to
>>>>> tests.
>>>>>
>>>>> - Manolo
>>>>>
>>>>>
>>>>> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>>>>>
>>>>>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>>>>>
>>>>>> Pepijn
>>>>>>
>>>>>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>>>>>
>>>>>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>>>>>> could checkout it and take a look?
>>>>>>>
>>>>>>> Don't worry about if the code is ok or not, I think github could be
>>>>>>> ok, but you could send a compressed file via email or whatever you
>>>>>>> prefer.
>>>>>>>
>>>>>>> - Manolo
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>> Okay, I put up the result for the day.
>>>>>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>>>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>>>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>>>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>>>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>>>>>
>>>>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>>>>
>>>>>>>> Pepijn
>>>>>>>>
>>>>>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>>>>>
>>>>>>>>> More questions. I started hacking!
>>>>>>>>>
>>>>>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>>>>>
>>>>>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>>>>>
>>>>>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>>>>>
>>>>>>>>> I'm getting there!
>>>>>>>>>
>>>>>>>>> Pepijn
>>>>>>>>>
>>>>>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>
>>>>>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>>>>>
>>>>>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>>>>>> etc should be created.
>>>>>>>>>>
>>>>>>>>>> - Manolo
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>>>>>
>>>>>>>>>>> Pepijn
>>>>>>>>>>>
>>>>>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Pepijn
>>>>>>>>>>>>
>>>>>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>>>>>
>>>>>>>>>>>> - Manolo
>>>>>>>>>>>>
>>>>>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks a lot.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>>>>>> tried.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>>>>>> other objects at runtime.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>>>>>> disappointed.
>>>>>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>>>>>> implementation:
>>>>>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Thanks man, really appreciated.
I too think my ModSeq impl looks good, but incrementing the modSeq 4 times in parallel, I noticed that
the value is incremented only 2-3 times.
_rev is incremented even less.
additional documents get created.
What happens is that the same mailbox object gets passed to all invocations of nextModSeq. This means that incrementing them in one increments it everywhere. Normally this would only create conflicts in all but one, but because this mailbox does not have an id yet, it creates a new mailbox for every conflict.
So I assume this is not a problem in practice? Because after your fix, all created mailboxes actually do have an id. I'll test that later, and then try to figure out JUnit.
Pepijn
On Oct 16, 2011, at 4:23 PM, Manuel Carrasco Moñino wrote:
> On Sat, Oct 15, 2011 at 5:40 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>> So, the result and questions for today:
>>
>> https://github.com/pepijndevos/james-couchdb
>>
>> What is serialVersionUID?
>
> It is a good practice to define it for serializable classes
> http://www.javapractices.com/topic/TopicAction.do?Id=45
>
>>
>> Is UidValidity something else than what is provided by CouchDbUidProvider?
>
> It's a number that changes when all uids become invalid. The server
> cannot update this number during a session.
> http://www.afterlogic.com/mailbee-net/docs/MailBee.ImapMail.Imap.UidValidity.html
>
>>
>> I had a look at the InMemory test, and it seems to fail on remainders of the InMemory implementation(mentions of ConcurrentHashmap). I'm not sure what it tests, but I think it's more than just CouchDbMailboxManager.
>>
>> Today I tried to implement ModSeq and Uid. They work fine until you introduce concurrency. I'd be glad if someone would take a look at nextModSeq.
>
> Your implementation looks good.
>
>>
>> I'll try to write a test for it tomorrow. The thing is that the test would need the database, right? How do you handle that?
>
> Difficult since it seems there is no way to install couchdb and start
> it from maven.
> Right now tests should be ignored when ddbb is not running (see
> maildir tests which are omitted in windows systems)
> I've added in the setup a call to empty the 'james' database when the
> test run, also I have added initStandardDesignDocument() to
> initialize database.
> Be careful before run the test if you do not want the ddbb be re-created.
>
> Happy coding.
> - Manolo
>
>>
>> Pepijn
>>
>> On Oct 15, 2011, at 11:41 AM, Pepijn de Vos wrote:
>>
>>> Thanks! :)
>>>
>>> I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
>>>
>>> Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
>>>
>>> The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
>>>
>>> Pepijn
>>>
>>> On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
>>>
>>>> You are right, you already sent the github link.
>>>>
>>>> I've checked out the code and I've made some changes to make it
>>>> compile, also I have changed id signature in messages and mailboxes to
>>>> String since couchdb uses string. I have hardcoded a user and password
>>>> in the Utils class, it should go in the configuration files though.
>>>>
>>>> I just have sent you a pull request
>>>> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>>>>
>>>> The unique Test in the tree do no pass, I think you can start fixing
>>>> the test so as it should be easier to follow the code taking a look to
>>>> tests.
>>>>
>>>> - Manolo
>>>>
>>>>
>>>> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>>>>
>>>>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>>>>
>>>>> Pepijn
>>>>>
>>>>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>>>>
>>>>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>>>>> could checkout it and take a look?
>>>>>>
>>>>>> Don't worry about if the code is ok or not, I think github could be
>>>>>> ok, but you could send a compressed file via email or whatever you
>>>>>> prefer.
>>>>>>
>>>>>> - Manolo
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>> Okay, I put up the result for the day.
>>>>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>>>>
>>>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>>>
>>>>>>> Pepijn
>>>>>>>
>>>>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>>>>
>>>>>>>> More questions. I started hacking!
>>>>>>>>
>>>>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>>>>
>>>>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>>>>
>>>>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>>>>
>>>>>>>> I'm getting there!
>>>>>>>>
>>>>>>>> Pepijn
>>>>>>>>
>>>>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>
>>>>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>>>>
>>>>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>>>>> etc should be created.
>>>>>>>>>
>>>>>>>>> - Manolo
>>>>>>>>>
>>>>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>>>>
>>>>>>>>>> Pepijn
>>>>>>>>>>
>>>>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Pepijn
>>>>>>>>>>>
>>>>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>>>>
>>>>>>>>>>> - Manolo
>>>>>>>>>>>
>>>>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks a lot.
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>>>>> tried.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>>>>> other objects at runtime.
>>>>>>>>>>>>
>>>>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>>>>> disappointed.
>>>>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>>>>
>>>>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>>>>> implementation:
>>>>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>>>>
>>>>>>>>>>>> Pepijn
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
On Sat, Oct 15, 2011 at 5:40 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
> So, the result and questions for today:
>
> https://github.com/pepijndevos/james-couchdb
>
> What is serialVersionUID?
It is a good practice to define it for serializable classes
http://www.javapractices.com/topic/TopicAction.do?Id=45
>
> Is UidValidity something else than what is provided by CouchDbUidProvider?
It's a number that changes when all uids become invalid. The server
cannot update this number during a session.
http://www.afterlogic.com/mailbee-net/docs/MailBee.ImapMail.Imap.UidValidity.html
>
> I had a look at the InMemory test, and it seems to fail on remainders of the InMemory implementation(mentions of ConcurrentHashmap). I'm not sure what it tests, but I think it's more than just CouchDbMailboxManager.
>
> Today I tried to implement ModSeq and Uid. They work fine until you introduce concurrency. I'd be glad if someone would take a look at nextModSeq.
Your implementation looks good.
>
> I'll try to write a test for it tomorrow. The thing is that the test would need the database, right? How do you handle that?
Difficult since it seems there is no way to install couchdb and start
it from maven.
Right now tests should be ignored when ddbb is not running (see
maildir tests which are omitted in windows systems)
I've added in the setup a call to empty the 'james' database when the
test run, also I have added initStandardDesignDocument() to
initialize database.
Be careful before run the test if you do not want the ddbb be re-created.
Happy coding.
- Manolo
>
> Pepijn
>
> On Oct 15, 2011, at 11:41 AM, Pepijn de Vos wrote:
>
>> Thanks! :)
>>
>> I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
>>
>> Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
>>
>> The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
>>
>> Pepijn
>>
>> On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
>>
>>> You are right, you already sent the github link.
>>>
>>> I've checked out the code and I've made some changes to make it
>>> compile, also I have changed id signature in messages and mailboxes to
>>> String since couchdb uses string. I have hardcoded a user and password
>>> in the Utils class, it should go in the configuration files though.
>>>
>>> I just have sent you a pull request
>>> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>>>
>>> The unique Test in the tree do no pass, I think you can start fixing
>>> the test so as it should be easier to follow the code taking a look to
>>> tests.
>>>
>>> - Manolo
>>>
>>>
>>> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>>>
>>>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>>>
>>>> Pepijn
>>>>
>>>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>>>
>>>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>>>> could checkout it and take a look?
>>>>>
>>>>> Don't worry about if the code is ok or not, I think github could be
>>>>> ok, but you could send a compressed file via email or whatever you
>>>>> prefer.
>>>>>
>>>>> - Manolo
>>>>>
>>>>>
>>>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>> Okay, I put up the result for the day.
>>>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>>>
>>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>>
>>>>>> Pepijn
>>>>>>
>>>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>>>
>>>>>>> More questions. I started hacking!
>>>>>>>
>>>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>>>
>>>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>>>
>>>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>>>
>>>>>>> I'm getting there!
>>>>>>>
>>>>>>> Pepijn
>>>>>>>
>>>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>>>
>>>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>>>
>>>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>>>> etc should be created.
>>>>>>>>
>>>>>>>> - Manolo
>>>>>>>>
>>>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>>>
>>>>>>>>> Pepijn
>>>>>>>>>
>>>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>>
>>>>>>>>>> Hi Pepijn
>>>>>>>>>>
>>>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>>>
>>>>>>>>>> - Manolo
>>>>>>>>>>
>>>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>>>
>>>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks a lot.
>>>>>>>>>>>
>>>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>>>> tried.
>>>>>>>>>>>
>>>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>>>
>>>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>>>
>>>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>>>> other objects at runtime.
>>>>>>>>>>>
>>>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>>>
>>>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>>>
>>>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>>>> disappointed.
>>>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>>>
>>>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>>>
>>>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>>>
>>>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>>>> implementation:
>>>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>>>
>>>>>>>>>>> Pepijn
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
So, the result and questions for today:
https://github.com/pepijndevos/james-couchdb
What is serialVersionUID?
Is UidValidity something else than what is provided by CouchDbUidProvider?
I had a look at the InMemory test, and it seems to fail on remainders of the InMemory implementation(mentions of ConcurrentHashmap). I'm not sure what it tests, but I think it's more than just CouchDbMailboxManager.
Today I tried to implement ModSeq and Uid. They work fine until you introduce concurrency. I'd be glad if someone would take a look at nextModSeq.
I'll try to write a test for it tomorrow. The thing is that the test would need the database, right? How do you handle that?
Pepijn
On Oct 15, 2011, at 11:41 AM, Pepijn de Vos wrote:
> Thanks! :)
>
> I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
>
> Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
>
> The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
>
> Pepijn
>
> On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
>
>> You are right, you already sent the github link.
>>
>> I've checked out the code and I've made some changes to make it
>> compile, also I have changed id signature in messages and mailboxes to
>> String since couchdb uses string. I have hardcoded a user and password
>> in the Utils class, it should go in the configuration files though.
>>
>> I just have sent you a pull request
>> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>>
>> The unique Test in the tree do no pass, I think you can start fixing
>> the test so as it should be easier to follow the code taking a look to
>> tests.
>>
>> - Manolo
>>
>>
>> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>>
>>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>>
>>> Pepijn
>>>
>>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>>
>>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>>> could checkout it and take a look?
>>>>
>>>> Don't worry about if the code is ok or not, I think github could be
>>>> ok, but you could send a compressed file via email or whatever you
>>>> prefer.
>>>>
>>>> - Manolo
>>>>
>>>>
>>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>> Okay, I put up the result for the day.
>>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>>
>>>>> https://github.com/pepijndevos/james-couchdb
>>>>>
>>>>> Pepijn
>>>>>
>>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>>
>>>>>> More questions. I started hacking!
>>>>>>
>>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>>
>>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>>
>>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>>
>>>>>> I'm getting there!
>>>>>>
>>>>>> Pepijn
>>>>>>
>>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>>
>>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>>
>>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>>> etc should be created.
>>>>>>>
>>>>>>> - Manolo
>>>>>>>
>>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>>
>>>>>>>> Pepijn
>>>>>>>>
>>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>>
>>>>>>>>> Hi Pepijn
>>>>>>>>>
>>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>>
>>>>>>>>> - Manolo
>>>>>>>>>
>>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>>
>>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks a lot.
>>>>>>>>>>
>>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>>
>>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>>> tried.
>>>>>>>>>>
>>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>>
>>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>>
>>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>>> other objects at runtime.
>>>>>>>>>>
>>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>>
>>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>>
>>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>>> disappointed.
>>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>>
>>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>>
>>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>>
>>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>>> implementation:
>>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>>
>>>>>>>>>> Pepijn
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Thanks! :)
I have no idea what you did with the generics though. I read an article about them, and thought I understood them.
Basically they are just statically checked casts, right? So what does it mean to write X implements Y<Z>?
The tests are just leftovers from InMemory. I'm not doing TDD, but I rather see tests as a frozen REPL. I write code, test it in the REPL, if I find myself repeating pieces in the REPL, I make them into a test. I didn't get to the stage where I could even compile anything.
Pepijn
On Oct 14, 2011, at 8:14 PM, Manuel Carrasco Moñino wrote:
> You are right, you already sent the github link.
>
> I've checked out the code and I've made some changes to make it
> compile, also I have changed id signature in messages and mailboxes to
> String since couchdb uses string. I have hardcoded a user and password
> in the Utils class, it should go in the configuration files though.
>
> I just have sent you a pull request
> https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
>
> The unique Test in the tree do no pass, I think you can start fixing
> the test so as it should be easier to follow the code taking a look to
> tests.
>
> - Manolo
>
>
> On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>>
>> Her it is again: https://github.com/pepijndevos/james-couchdb
>>
>> Pepijn
>>
>> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>>
>>> Hi Pepjin, could be possible to share your code anywhere, so as I
>>> could checkout it and take a look?
>>>
>>> Don't worry about if the code is ok or not, I think github could be
>>> ok, but you could send a compressed file via email or whatever you
>>> prefer.
>>>
>>> - Manolo
>>>
>>>
>>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>> Okay, I put up the result for the day.
>>>> I made a CouchDbMailbox with Ektorp @annotations.
>>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>>> I stuffed the CouchDB connection in a class, not happy with it.
>>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>>
>>>> https://github.com/pepijndevos/james-couchdb
>>>>
>>>> Pepijn
>>>>
>>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>>
>>>>> More questions. I started hacking!
>>>>>
>>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>>
>>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>>
>>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>>
>>>>> I'm getting there!
>>>>>
>>>>> Pepijn
>>>>>
>>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>>
>>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>>> JPA like API with support to many of its annotations etc.
>>>>>>
>>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>>> etc should be created.
>>>>>>
>>>>>> - Manolo
>>>>>>
>>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>>
>>>>>>> Pepijn
>>>>>>>
>>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>>
>>>>>>>> Hi Pepijn
>>>>>>>>
>>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>>
>>>>>>>> - Manolo
>>>>>>>>
>>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>>
>>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>> Thanks a lot.
>>>>>>>>>
>>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>>
>>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>>> tried.
>>>>>>>>>
>>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>>
>>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>>
>>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>>> other objects at runtime.
>>>>>>>>>
>>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>>
>>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>>
>>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>>> disappointed.
>>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>>
>>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>>
>>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>>
>>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>>> implementation:
>>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>>
>>>>>>>>> Pepijn
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ioan Eugen Stan
>>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
You are right, you already sent the github link.
I've checked out the code and I've made some changes to make it
compile, also I have changed id signature in messages and mailboxes to
String since couchdb uses string. I have hardcoded a user and password
in the Utils class, it should go in the configuration files though.
I just have sent you a pull request
https://github.com/manolo/james-couchdb/commit/2b6b0ebce5c78198b14d1e7ec05c178d56482919
The unique Test in the tree do no pass, I think you can start fixing
the test so as it should be easier to follow the code taking a look to
tests.
- Manolo
On Thu, Oct 13, 2011 at 9:54 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
> I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
>
> Her it is again: https://github.com/pepijndevos/james-couchdb
>
> Pepijn
>
> On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
>
>> Hi Pepjin, could be possible to share your code anywhere, so as I
>> could checkout it and take a look?
>>
>> Don't worry about if the code is ok or not, I think github could be
>> ok, but you could send a compressed file via email or whatever you
>> prefer.
>>
>> - Manolo
>>
>>
>> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>> Okay, I put up the result for the day.
>>> I made a CouchDbMailbox with Ektorp @annotations.
>>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>>> I stuffed the CouchDB connection in a class, not happy with it.
>>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>>
>>> https://github.com/pepijndevos/james-couchdb
>>>
>>> Pepijn
>>>
>>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>>
>>>> More questions. I started hacking!
>>>>
>>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>>
>>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>>
>>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>>
>>>> I'm getting there!
>>>>
>>>> Pepijn
>>>>
>>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>>
>>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>>> JPA like API with support to many of its annotations etc.
>>>>>
>>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>>> James starts the first time, the database, views, design, mapreduce,
>>>>> etc should be created.
>>>>>
>>>>> - Manolo
>>>>>
>>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>>
>>>>>> Pepijn
>>>>>>
>>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>>
>>>>>>> Hi Pepijn
>>>>>>>
>>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>>
>>>>>>> - Manolo
>>>>>>>
>>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>>
>>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>>
>>>>>>>> Thanks a lot.
>>>>>>>>
>>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>>
>>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>>> tried.
>>>>>>>>
>>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>>
>>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>>
>>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>>> other objects at runtime.
>>>>>>>>
>>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>>
>>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>>
>>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>>> disappointed.
>>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>>
>>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>>> implementation that passes some unit tests.
>>>>>>>>
>>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>>
>>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>>> implementation:
>>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>>
>>>>>>>> Pepijn
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ioan Eugen Stan
>>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
I added the github link to the beautifully formatted original email, but I think Google mistreated my message.
Her it is again: https://github.com/pepijndevos/james-couchdb
Pepijn
On Oct 13, 2011, at 9:28 PM, Manuel Carrasco Moñino wrote:
> Hi Pepjin, could be possible to share your code anywhere, so as I
> could checkout it and take a look?
>
> Don't worry about if the code is ok or not, I think github could be
> ok, but you could send a compressed file via email or whatever you
> prefer.
>
> - Manolo
>
>
> On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>> Okay, I put up the result for the day.
>> I made a CouchDbMailbox with Ektorp @annotations.
>> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
>> I stuffed the CouchDB connection in a class, not happy with it.
>> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
>> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>>
>> https://github.com/pepijndevos/james-couchdb
>>
>> Pepijn
>>
>> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>>
>>> More questions. I started hacking!
>>>
>>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>>
>>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>>
>>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>>
>>> I'm getting there!
>>>
>>> Pepijn
>>>
>>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>>
>>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>>> JPA like API with support to many of its annotations etc.
>>>>
>>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>>> James starts the first time, the database, views, design, mapreduce,
>>>> etc should be created.
>>>>
>>>> - Manolo
>>>>
>>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>>
>>>>> Pepijn
>>>>>
>>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>>
>>>>>> Hi Pepijn
>>>>>>
>>>>>> Which java library are you considering to use to connect with couchdb?
>>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>>
>>>>>> - Manolo
>>>>>>
>>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>>
>>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>>
>>>>>>> Thanks a lot.
>>>>>>>
>>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>>
>>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>>> tried.
>>>>>>>
>>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>>
>>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>>
>>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>>> other objects at runtime.
>>>>>>>
>>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>>
>>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>>
>>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>>> disappointed.
>>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>>
>>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>>> implementation that passes some unit tests.
>>>>>>>
>>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>>
>>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>>> implementation:
>>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>>
>>>>>>> Pepijn
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ioan Eugen Stan
>>>>>>>> http://ieugen.blogspot.com/
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
Hi Pepjin, could be possible to share your code anywhere, so as I
could checkout it and take a look?
Don't worry about if the code is ok or not, I think github could be
ok, but you could send a compressed file via email or whatever you
prefer.
- Manolo
On Thu, Oct 13, 2011 at 8:12 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
> Okay, I put up the result for the day.
> I made a CouchDbMailbox with Ektorp @annotations.
> I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
> I stuffed the CouchDB connection in a class, not happy with it.
> I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
> Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
>
> https://github.com/pepijndevos/james-couchdb
>
> Pepijn
>
> On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
>
>> More questions. I started hacking!
>>
>> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>>
>> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>>
>> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>>
>> I'm getting there!
>>
>> Pepijn
>>
>> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>>
>>> Actually Ektorp is not a full implementation of JPA, but it provides a
>>> JPA like API with support to many of its annotations etc.
>>>
>>> Anyway, based on my experience, Ektorp simplifies the access from java
>>> to couchdb and the bootstrap of couchdb, so as theoretically when
>>> James starts the first time, the database, views, design, mapreduce,
>>> etc should be created.
>>>
>>> - Manolo
>>>
>>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>>
>>>> Pepijn
>>>>
>>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>>
>>>>> Hi Pepijn
>>>>>
>>>>> Which java library are you considering to use to connect with couchdb?
>>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>>
>>>>> - Manolo
>>>>>
>>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>>
>>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>>
>>>>>> Thanks a lot.
>>>>>>
>>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>>
>>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>>> tried.
>>>>>>
>>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>>
>>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>>
>>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>>> other objects at runtime.
>>>>>>
>>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>>
>>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>>
>>>>>>> I think this is because the configuration changed and now it's spring
>>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>>> expect too much from yourself and fail you will probably be too
>>>>>>> disappointed.
>>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>>
>>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>>> implementation that passes some unit tests.
>>>>>>
>>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>>
>>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>>> implementation:
>>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>>
>>>>>> Pepijn
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ioan Eugen Stan
>>>>>>> http://ieugen.blogspot.com/
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Okay, I put up the result for the day.
I made a CouchDbMailbox with Ektorp @annotations.
I made an attempt to make the MailboxMapper, but I got stuck at the <type> casting sugar which I don't grok. My IDE keeps complaining it can't resolve the incompatible types, while both are just Mailboxes.
I stuffed the CouchDB connection in a class, not happy with it.
I'm not sure how to implement the findMailboxWithPathLike and hasChildren methods.
Any help appreciated, especially with the... <> things. list() is the only one that's red wiggly lines, the others are just unchecked casts. I've been adding random casts and <> left and right.
https://github.com/pepijndevos/james-couchdb
Pepijn
On Oct 13, 2011, at 6:23 PM, Pepijn de Vos wrote:
> More questions. I started hacking!
>
> I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
>
> What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
>
> To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
>
> I'm getting there!
>
> Pepijn
>
> On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
>
>> Actually Ektorp is not a full implementation of JPA, but it provides a
>> JPA like API with support to many of its annotations etc.
>>
>> Anyway, based on my experience, Ektorp simplifies the access from java
>> to couchdb and the bootstrap of couchdb, so as theoretically when
>> James starts the first time, the database, views, design, mapreduce,
>> etc should be created.
>>
>> - Manolo
>>
>> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>>
>>> Pepijn
>>>
>>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>>
>>>> Hi Pepijn
>>>>
>>>> Which java library are you considering to use to connect with couchdb?
>>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>>
>>>> - Manolo
>>>>
>>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>>
>>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>>
>>>>> Thanks a lot.
>>>>>
>>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>>
>>>>>> Have patience. You will need it if you wish to complete something.
>>>>>> Patience and perseverance or else you'll be just another one who
>>>>>> tried.
>>>>>
>>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>>
>>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>>
>>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>>> other objects at runtime.
>>>>>
>>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>>
>>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>>
>>>>>> I think this is because the configuration changed and now it's spring
>>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>>> expect too much from yourself and fail you will probably be too
>>>>>> disappointed.
>>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>>
>>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>>> try to help when/if I can. I suggest you start with simple
>>>>>> implementation that passes some unit tests.
>>>>>
>>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>>
>>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>>> implementation:
>>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>>
>>>>> Pepijn
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ioan Eugen Stan
>>>>>> http://ieugen.blogspot.com/
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
More questions. I started hacking!
I'm going with Ektorp. I figured out most of it, I think. Except that I don't understand the configuration. It does have a Spring module. Any pointers on how to organize the config and connections?
What does findMailboxWithPathLike do? The implementations seem to do weird things with regexes. Preferably I make that into a nice CouchDB view. CouchDB can't do fulltext search. As far as I can tell, the IMAP RFC doesn't say anything about it.
To have custom message and mailbox classes, do I need to do anything else besides subclassing the corresponding *Manager class to return one?
I'm getting there!
Pepijn
On Oct 12, 2011, at 9:35 PM, Manuel Carrasco Moñino wrote:
> Actually Ektorp is not a full implementation of JPA, but it provides a
> JPA like API with support to many of its annotations etc.
>
> Anyway, based on my experience, Ektorp simplifies the access from java
> to couchdb and the bootstrap of couchdb, so as theoretically when
> James starts the first time, the database, views, design, mapreduce,
> etc should be created.
>
> - Manolo
>
> On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>>
>> Pepijn
>>
>> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>>
>>> Hi Pepijn
>>>
>>> Which java library are you considering to use to connect with couchdb?
>>> I'm using [1] ektorp and makes really easy to map domain models.
>>>
>>> - Manolo
>>>
>>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>>
>>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>>
>>>> Thanks a lot.
>>>>
>>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>>
>>>>> Have patience. You will need it if you wish to complete something.
>>>>> Patience and perseverance or else you'll be just another one who
>>>>> tried.
>>>>
>>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>>
>>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>>
>>>>> Not sure what you mean by that. It uses dependency injection provided
>>>>> by Spring framework (and soon Guice) to inject object references into
>>>>> other objects at runtime.
>>>>
>>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>>
>>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>>
>>>>> I think this is because the configuration changed and now it's spring
>>>>> based, and more modular. I see you are very ambitious but I sense you
>>>>> have a lot of catching up. James is complex so give it time, if you
>>>>> expect too much from yourself and fail you will probably be too
>>>>> disappointed.
>>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>>
>>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>>> try to help when/if I can. I suggest you start with simple
>>>>> implementation that passes some unit tests.
>>>>
>>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>>
>>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>>> implementation:
>>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>>
>>>> Pepijn
>>>>>
>>>>>
>>>>> --
>>>>> Ioan Eugen Stan
>>>>> http://ieugen.blogspot.com/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
Actually Ektorp is not a full implementation of JPA, but it provides a
JPA like API with support to many of its annotations etc.
Anyway, based on my experience, Ektorp simplifies the access from java
to couchdb and the bootstrap of couchdb, so as theoretically when
James starts the first time, the database, views, design, mapreduce,
etc should be created.
- Manolo
On Wed, Oct 12, 2011 at 1:05 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
> Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
>
> Pepijn
>
> On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
>
>> Hi Pepijn
>>
>> Which java library are you considering to use to connect with couchdb?
>> I'm using [1] ektorp and makes really easy to map domain models.
>>
>> - Manolo
>>
>> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>>
>> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>>
>>> Thanks a lot.
>>>
>>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>>
>>>> Have patience. You will need it if you wish to complete something.
>>>> Patience and perseverance or else you'll be just another one who
>>>> tried.
>>>
>>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>>
>>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>>
>>>> Not sure what you mean by that. It uses dependency injection provided
>>>> by Spring framework (and soon Guice) to inject object references into
>>>> other objects at runtime.
>>>
>>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>>
>>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>>
>>>> I think this is because the configuration changed and now it's spring
>>>> based, and more modular. I see you are very ambitious but I sense you
>>>> have a lot of catching up. James is complex so give it time, if you
>>>> expect too much from yourself and fail you will probably be too
>>>> disappointed.
>>> Yea, I read a Java book long ago, never did any big projects with it.
>>>>
>>>> Make a public repo, commit something and ask if you get stuck. I will
>>>> try to help when/if I can. I suggest you start with simple
>>>> implementation that passes some unit tests.
>>>
>>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>>
>>>> See for example the unit tests I did for Mailbox interface in HBase
>>>> implementation:
>>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>>
>>> Pepijn
>>>>
>>>>
>>>> --
>>>> Ioan Eugen Stan
>>>> http://ieugen.blogspot.com/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Ektorp seems nice, but I'm more comfortable just using something that resembles the HTTP API, since I'm not familiar with JPA. Haven't decided yet.
Pepijn
On Oct 11, 2011, at 5:08 PM, Manuel Carrasco Moñino wrote:
> Hi Pepijn
>
> Which java library are you considering to use to connect with couchdb?
> I'm using [1] ektorp and makes really easy to map domain models.
>
> - Manolo
>
> [1] http://www.ektorp.org/reference_documentation.html#d0e532
>
> On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>>
>> Thanks a lot.
>>
>> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>>
>>> Have patience. You will need it if you wish to complete something.
>>> Patience and perseverance or else you'll be just another one who
>>> tried.
>>
>> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
>> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
>> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>>>
>>>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>>>
>>> Not sure what you mean by that. It uses dependency injection provided
>>> by Spring framework (and soon Guice) to inject object references into
>>> other objects at runtime.
>>
>> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>>>
>>>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>>>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>>>
>>> I think this is because the configuration changed and now it's spring
>>> based, and more modular. I see you are very ambitious but I sense you
>>> have a lot of catching up. James is complex so give it time, if you
>>> expect too much from yourself and fail you will probably be too
>>> disappointed.
>> Yea, I read a Java book long ago, never did any big projects with it.
>>>
>>> Make a public repo, commit something and ask if you get stuck. I will
>>> try to help when/if I can. I suggest you start with simple
>>> implementation that passes some unit tests.
>>
>> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>>>
>>> See for example the unit tests I did for Mailbox interface in HBase
>>> implementation:
>>> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
>> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>>
>> Pepijn
>>>
>>>
>>> --
>>> Ioan Eugen Stan
>>> http://ieugen.blogspot.com/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
Hi Pepijn
Which java library are you considering to use to connect with couchdb?
I'm using [1] ektorp and makes really easy to map domain models.
- Manolo
[1] http://www.ektorp.org/reference_documentation.html#d0e532
On Mon, Oct 10, 2011 at 10:44 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>
> Thanks a lot.
>
> On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
>
> > Have patience. You will need it if you wish to complete something.
> > Patience and perseverance or else you'll be just another one who
> > tried.
>
> I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
> I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
> Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
> >
> >> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
> >
> > Not sure what you mean by that. It uses dependency injection provided
> > by Spring framework (and soon Guice) to inject object references into
> > other objects at runtime.
>
> Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
> >
> >> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
> >> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
> >
> > I think this is because the configuration changed and now it's spring
> > based, and more modular. I see you are very ambitious but I sense you
> > have a lot of catching up. James is complex so give it time, if you
> > expect too much from yourself and fail you will probably be too
> > disappointed.
> Yea, I read a Java book long ago, never did any big projects with it.
> >
> > Make a public repo, commit something and ask if you get stuck. I will
> > try to help when/if I can. I suggest you start with simple
> > implementation that passes some unit tests.
>
> So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
> >
> > See for example the unit tests I did for Mailbox interface in HBase
> > implementation:
> > http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
> What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
>
> Pepijn
> >
> >
> > --
> > Ioan Eugen Stan
> > http://ieugen.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Thanks a lot.
On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote:
> Have patience. You will need it if you wish to complete something.
> Patience and perseverance or else you'll be just another one who
> tried.
I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort.
I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application.
Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA.
>
>> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
>
> Not sure what you mean by that. It uses dependency injection provided
> by Spring framework (and soon Guice) to inject object references into
> other objects at runtime.
Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James?
>
>> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
>> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
>
> I think this is because the configuration changed and now it's spring
> based, and more modular. I see you are very ambitious but I sense you
> have a lot of catching up. James is complex so give it time, if you
> expect too much from yourself and fail you will probably be too
> disappointed.
Yea, I read a Java book long ago, never did any big projects with it.
>
> Make a public repo, commit something and ask if you get stuck. I will
> try to help when/if I can. I suggest you start with simple
> implementation that passes some unit tests.
So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code.
>
> See for example the unit tests I did for Mailbox interface in HBase
> implementation:
> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation.
Pepijn
>
>
> --
> Ioan Eugen Stan
> http://ieugen.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Ioan Eugen Stan <st...@gmail.com>.
2011/10/10 Pepijn de Vos <pe...@yahoo.com>:
> Thanks, helpful :) More questions!
>
> What is the modification sequence? (ModSeqProvider) This? http://tools.ietf.org/html/rfc4551
It's a way to see if the mailbox has been modified (flags changed, etc.).
> I guess the UID is just that of a message?
It's a number that uniquely identifies a message in a mailbox. the RFC
states it is 32 bits long.
> Do both need to be an increasing long? ( http://wiki.apache.org/couchdb/HttpGetUuids )
>
> I'm soon going to start my implementation. I will force myself to have *something* by the end of the week, or I'll just give up and use JPA.
Have patience. You will need it if you wish to complete something.
Patience and perseverance or else you'll be just another one who
tried.
> Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
Not sure what you mean by that. It uses dependency injection provided
by Spring framework (and soon Guice) to inject object references into
other objects at runtime.
> The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
> Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
I think this is because the configuration changed and now it's spring
based, and more modular. I see you are very ambitious but I sense you
have a lot of catching up. James is complex so give it time, if you
expect too much from yourself and fail you will probably be too
disappointed.
Make a public repo, commit something and ask if you get stuck. I will
try to help when/if I can. I suggest you start with simple
implementation that passes some unit tests.
See for example the unit tests I did for Mailbox interface in HBase
implementation:
http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Thanks, helpful :) More questions!
What is the modification sequence? (ModSeqProvider) This? http://tools.ietf.org/html/rfc4551
I guess the UID is just that of a message?
Do both need to be an increasing long? ( http://wiki.apache.org/couchdb/HttpGetUuids )
I'm soon going to start my implementation. I will force myself to have *something* by the end of the week, or I'll just give up and use JPA.
Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict.
The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html
Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations.
Pepijn
On Oct 4, 2011, at 11:49 AM, Ioan Eugen Stan wrote:
> 2011/10/4 Pepijn de Vos <pe...@yahoo.com>:
>> Another piece of the puzzle. HBase and JPA use less of the classes from the Store API. Therefore they also extend the managers to provide their custom classes. I'm still not sure why they do that, instead of using for example SimpleMessage.
>>
>> I found a Couch library that claims to be a lot like JPA. I would study the JPA impl, but maybe there is a good reason to look at HBase instead?
>
> There are a couple of things that a mailbox implementation must do,
> but it's main job is to store messages in mailboxes and provide a way
> for the user to retrieve them back.
>
> The main "components" that you must be aware in a mailbox implementation are:
>
> 1. Mailboxes - they are similar to file-system folders and are used to
> group together related messages.
> 2. Messages - must belong to a mailbox (default is INBOX) and have
> some interesting properties (unique UIDs, they are immutable, they
> have properties and flags). Much of this information is defined in
> specific RFC's (Mail RFC, IMAP RFC, MIME RFC).
> 3. Subscription - the best way I can explain this is that you can
> subscribe to mailboxes (other than you own - like news, etc; See IMAP
> RFC). When you connect to receive mails, you will be notified for
> messages that arrive to your subscribed mailboxes.
>
> the Store is a generic framework and each Mailbox implementation must
> provide the means to save the information on disk. The JPA
> implementation for example uses object relational mapping to map a
> Java class to a relational table in a RDBMS.
> Check out http://svn.apache.org/repos/asf/james/mailbox/trunk/jpa/src/main/java/org/apache/james/mailbox/jpa/mail/model/JPAMailbox.java
> to see how JPAMailbox class uses annotations to map fields to table
> columns. That's why you can't use SimpleMessage, because OpenJPA would
> not know how to save what field to what column.
>
> The Hbase implementation is more suitable for you to learn because it
> explicitly saves/retrieves content to HBase, whereas in JPA you will
> see a lot of annotations but the actual persistence is hidden.
>
> In order to build an implementation I suggest you start by
> implementing the tests which will initially fail and then try to make
> the failing tests pass one by one. This is the way I started and it
> was clear. I also suggest you start by implementing
> SubscriptionManager and MailboxManager first. MessageMannager and
> Message related classes are harder.
>
> The API is pretty good so most of the work will be to implement the
> *Mapper classes. Other than that you should probably do very little
> work say for Managers.
>
> A word about the mappers:
>
> They are three of them: SubscriptionMapper, MailboxMapper and
> MessageMapper. They are defined as interfaces (please have a look at
> those interfaces) and provide CRUD (creat, read, update, delete) for
> subscriptions, mailboxes and messages. They are used by *Managers to
> do work in the Mailbox (NOTE: be aware that mailbox has many meanings:
> the actual store for your emails (e.g. Apache Mailbox), one folder for
> storing emails, etc. see http://en.wikipedia.org/wiki/Email_box ).
> Mappers provide simple operations that are used by Managers and beyond
> to do complex stuff. For example when a user reads a new message, the
> server must perform some of the following:
>
> - access the mailbox
> - find the message
> - read the message
> - update it's flags: UNREAD and maybe RECENT flag
> - etc.
>
> So a user reading a message is a complex operation that spans multiple
> simple opperations provided by Mapper implementations (see
> updateFlags, findMessage, findMailbox, etc).
>
>> I'm not sure how I would do TDD. What to test? Who tests the tester? But maybe TDD will change my way of looking at the code, and proving assumptions. I still find it hard to read Java code that spans more than 5 classes.
>
> Try reading a book and most importantly: do exercises. Doing is the
> only way to get better at stuff.
>
> I hope that you have a better understanding now and I wish you good
> luck. Don't hesitate if you have other questions. I will try to answer
> as much as my time aloes me.
>
> Bye,
>
> --
> Ioan Eugen Stan
> http://ieugen.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Ioan Eugen Stan <st...@gmail.com>.
2011/10/4 Pepijn de Vos <pe...@yahoo.com>:
> Another piece of the puzzle. HBase and JPA use less of the classes from the Store API. Therefore they also extend the managers to provide their custom classes. I'm still not sure why they do that, instead of using for example SimpleMessage.
>
> I found a Couch library that claims to be a lot like JPA. I would study the JPA impl, but maybe there is a good reason to look at HBase instead?
There are a couple of things that a mailbox implementation must do,
but it's main job is to store messages in mailboxes and provide a way
for the user to retrieve them back.
The main "components" that you must be aware in a mailbox implementation are:
1. Mailboxes - they are similar to file-system folders and are used to
group together related messages.
2. Messages - must belong to a mailbox (default is INBOX) and have
some interesting properties (unique UIDs, they are immutable, they
have properties and flags). Much of this information is defined in
specific RFC's (Mail RFC, IMAP RFC, MIME RFC).
3. Subscription - the best way I can explain this is that you can
subscribe to mailboxes (other than you own - like news, etc; See IMAP
RFC). When you connect to receive mails, you will be notified for
messages that arrive to your subscribed mailboxes.
the Store is a generic framework and each Mailbox implementation must
provide the means to save the information on disk. The JPA
implementation for example uses object relational mapping to map a
Java class to a relational table in a RDBMS.
Check out http://svn.apache.org/repos/asf/james/mailbox/trunk/jpa/src/main/java/org/apache/james/mailbox/jpa/mail/model/JPAMailbox.java
to see how JPAMailbox class uses annotations to map fields to table
columns. That's why you can't use SimpleMessage, because OpenJPA would
not know how to save what field to what column.
The Hbase implementation is more suitable for you to learn because it
explicitly saves/retrieves content to HBase, whereas in JPA you will
see a lot of annotations but the actual persistence is hidden.
In order to build an implementation I suggest you start by
implementing the tests which will initially fail and then try to make
the failing tests pass one by one. This is the way I started and it
was clear. I also suggest you start by implementing
SubscriptionManager and MailboxManager first. MessageMannager and
Message related classes are harder.
The API is pretty good so most of the work will be to implement the
*Mapper classes. Other than that you should probably do very little
work say for Managers.
A word about the mappers:
They are three of them: SubscriptionMapper, MailboxMapper and
MessageMapper. They are defined as interfaces (please have a look at
those interfaces) and provide CRUD (creat, read, update, delete) for
subscriptions, mailboxes and messages. They are used by *Managers to
do work in the Mailbox (NOTE: be aware that mailbox has many meanings:
the actual store for your emails (e.g. Apache Mailbox), one folder for
storing emails, etc. see http://en.wikipedia.org/wiki/Email_box ).
Mappers provide simple operations that are used by Managers and beyond
to do complex stuff. For example when a user reads a new message, the
server must perform some of the following:
- access the mailbox
- find the message
- read the message
- update it's flags: UNREAD and maybe RECENT flag
- etc.
So a user reading a message is a complex operation that spans multiple
simple opperations provided by Mapper implementations (see
updateFlags, findMessage, findMailbox, etc).
> I'm not sure how I would do TDD. What to test? Who tests the tester? But maybe TDD will change my way of looking at the code, and proving assumptions. I still find it hard to read Java code that spans more than 5 classes.
Try reading a book and most importantly: do exercises. Doing is the
only way to get better at stuff.
I hope that you have a better understanding now and I wish you good
luck. Don't hesitate if you have other questions. I will try to answer
as much as my time aloes me.
Bye,
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Another piece of the puzzle. HBase and JPA use less of the classes from the Store API. Therefore they also extend the managers to provide their custom classes. I'm still not sure why they do that, instead of using for example SimpleMessage.
I found a Couch library that claims to be a lot like JPA. I would study the JPA impl, but maybe there is a good reason to look at HBase instead?
I'm not sure how I would do TDD. What to test? Who tests the tester? But maybe TDD will change my way of looking at the code, and proving assumptions. I still find it hard to read Java code that spans more than 5 classes.
Pepijn
On Sep 23, 2011, at 10:26 PM, Robert Burrell Donkin wrote:
> On Fri, Sep 23, 2011 at 12:30 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
>> Looking at memory, I see mappers and providers, what do these terms imply?
>>
>> Now, I would think another mailbox would look similar to this one, because they do the same thing, right?
>
> The mailbox API is an adaption layer abstracting quite different
> storage implementations.
>
>> Looking at jpa, I suddenly see manager classes added to the mix, and in general just twice as many classes. Are these part of the mailbox spec, or just an artifact of JPA?
>>
>> It looks like there is a discrepancy to what I think is the responsibility of a mailbox, and what the actual responsibilities are.
>>
>> This is how I would imagine stuff works:
>> There are mailbox and message classes which belong to each other. Say IMessage and IMailbox. Now I simply implement these interface that have methods such as list() and save()
>>
>> Now the reality seems to be somewhat more involved. I'm not going to look at jpa, but for memory it seems like these mapper classes take concrete Message, Mailbox and Subscription(?) objects and store them.
>>
>> There are a lot of seemingly Mailbox related methods on the MessageMapper?
>>
>> It seems the provider classes are mainly concerned with the Message-ID header?
>>
>> Writing this email cleared up some relations already, but looking at anything other than memory, makes me think I'm not even halfway there.
>
> There are different ways to tackle API implementation. I find it often
> takes a long time to understand lots of existing implementations but
> if I were to pick one implementation to study, it would be HBase.
>
> I prefer to dive straight in with TDD: write a test, make it pass, repeat.
>
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Sep 23, 2011 at 12:30 PM, Pepijn de Vos <pe...@yahoo.com> wrote:
> Looking at memory, I see mappers and providers, what do these terms imply?
>
> Now, I would think another mailbox would look similar to this one, because they do the same thing, right?
The mailbox API is an adaption layer abstracting quite different
storage implementations.
> Looking at jpa, I suddenly see manager classes added to the mix, and in general just twice as many classes. Are these part of the mailbox spec, or just an artifact of JPA?
>
> It looks like there is a discrepancy to what I think is the responsibility of a mailbox, and what the actual responsibilities are.
>
> This is how I would imagine stuff works:
> There are mailbox and message classes which belong to each other. Say IMessage and IMailbox. Now I simply implement these interface that have methods such as list() and save()
>
> Now the reality seems to be somewhat more involved. I'm not going to look at jpa, but for memory it seems like these mapper classes take concrete Message, Mailbox and Subscription(?) objects and store them.
>
> There are a lot of seemingly Mailbox related methods on the MessageMapper?
>
> It seems the provider classes are mainly concerned with the Message-ID header?
>
> Writing this email cleared up some relations already, but looking at anything other than memory, makes me think I'm not even halfway there.
There are different ways to tackle API implementation. I find it often
takes a long time to understand lots of existing implementations but
if I were to pick one implementation to study, it would be HBase.
I prefer to dive straight in with TDD: write a test, make it pass, repeat.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Looking at memory, I see mappers and providers, what do these terms imply?
Now, I would think another mailbox would look similar to this one, because they do the same thing, right?
Looking at jpa, I suddenly see manager classes added to the mix, and in general just twice as many classes. Are these part of the mailbox spec, or just an artifact of JPA?
It looks like there is a discrepancy to what I think is the responsibility of a mailbox, and what the actual responsibilities are.
This is how I would imagine stuff works:
There are mailbox and message classes which belong to each other. Say IMessage and IMailbox. Now I simply implement these interface that have methods such as list() and save()
Now the reality seems to be somewhat more involved. I'm not going to look at jpa, but for memory it seems like these mapper classes take concrete Message, Mailbox and Subscription(?) objects and store them.
There are a lot of seemingly Mailbox related methods on the MessageMapper?
It seems the provider classes are mainly concerned with the Message-ID header?
Writing this email cleared up some relations already, but looking at anything other than memory, makes me think I'm not even halfway there.
Pepijn
On Sep 23, 2011, at 12:20 PM, Ioan Eugen Stan wrote:
> 2011/9/23 Pepijn de Vos <pe...@yahoo.com>:
>> Has anything like this happened?
>
> Hello Pepjin,
>>
>> I got James running, but I tried to look at the source with a regular text editor, and couldn't really figure out where stuff comes from an what it does. Does it help to use a Java IDE? To me everything looks like AbstractSingletonProxyFactoryBeans[1]
>
> Could you be more explicit?
>
>> Pepijn
>>
>> [1]: http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html
>
> p.s. I am late with docs for Mailbox, sorry about that, they are still on todo.
>
> --
> Ioan Eugen Stan
> http://ieugen.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Ioan Eugen Stan <st...@gmail.com>.
2011/9/23 Pepijn de Vos <pe...@yahoo.com>:
> Has anything like this happened?
Hello Pepjin,
>
> I got James running, but I tried to look at the source with a regular text editor, and couldn't really figure out where stuff comes from an what it does. Does it help to use a Java IDE? To me everything looks like AbstractSingletonProxyFactoryBeans[1]
Could you be more explicit?
> Pepijn
>
> [1]: http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html
p.s. I am late with docs for Mailbox, sorry about that, they are still on todo.
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Has anything like this happened?
I got James running, but I tried to look at the source with a regular text editor, and couldn't really figure out where stuff comes from an what it does. Does it help to use a Java IDE? To me everything looks like AbstractSingletonProxyFactoryBeans[1]
Pepijn
[1]: http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html
On Aug 17, 2011, at 11:03 PM, Ioan Eugen Stan wrote:
> 2011/8/16 Pepijn de Vos <pe...@yahoo.com>:
>> I think the link has gone missing, but it would indeed be very helpful if you wrote a bit about your experience navigating James.
>
> It's coming. It will be here in the next week or so. Now I'm
> concentrating on finishing the job (integration tests). Next week is
> for documentation and other stuff. So if you're not in a hurry, please
> wait a bit.
>
> Regards,
> --
> Ioan Eugen Stan
> http://ieugen.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Ioan Eugen Stan <st...@gmail.com>.
2011/8/16 Pepijn de Vos <pe...@yahoo.com>:
> I think the link has gone missing, but it would indeed be very helpful if you wrote a bit about your experience navigating James.
It's coming. It will be here in the next week or so. Now I'm
concentrating on finishing the job (integration tests). Next week is
for documentation and other stuff. So if you're not in a hurry, please
wait a bit.
Regards,
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
I think the link has gone missing, but it would indeed be very helpful if you wrote a bit about your experience navigating James.
> And nice to see you are interested. I worked on the HBase mailbox implementation so I can help also. I am preparing a schema design [1]
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hello Pepijn,
And nice to see you are interested. I worked on the HBase mailbox
implementation so I can help also. I am preparing a schema design [1]
2011/8/15 Pepijn de Vos <pe...@yahoo.com>:
> Thanks for the answers, more questions coming!
>
> I checked out the server and the mailbox repo, and followed the instructions, I ran a couple of mvn commands, and got a bunch of jars. All is fine until I get here:
>
> Step 2: Unpack the archive into your James installation directory -- what... where? I only have jars.
The James instalation directory is the directory where you will have
all the James jars and the directory structure (I have downloaded the
zip on the website and I have dirs like bin/, var/, conf/, lib/ etc.).
If you ran the 'mvn package' command you should have that zip in the
target directory, inside container-spring (at least for version v
3.0-m3-snapshot) only if the build succeded. The zip is built by rules
in the maven pom (search maven assembly).
> It continues to describe a binary folder, which is nowhere to be seen in the container-spring project, nor in the cli and core projects. Apparently I'm missing something?
>
> Meanwhile I'm browsing the javadocs for the mailbox project. I'm starting to get an idea what the store API is used for and how the memory mailbox works, but the grand scheme still eludes me.
>
> Is there any more documentation about installing and configuring James for development?
Well, there is the tutorial that shows how to build James from Eclipse
and from Netbeans (I sent a patch but I'm not sure it's uploaded yet).
> I'm still not sure what to think of the REST API. Do you want to have a IMAP 'replacement' that is RESTful, or just an abstraction over a simple key-value store? (I just realized that, in a way, a CouchDB mailbox is already a REST interface to James)
I'm not familiar with CouchDB but I think that the idea here is to use
plain HTTP requests (GET/POST/PUT/DELETE) to manage your emails,
instead of the usual IMAP protocol commands.
> Interesting reading material: http://www.prescod.net/rest/restmail/
>
> Pepijn
Yes, it is interesting.
Hope that helps,
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Pepijn de Vos <pe...@yahoo.com>.
Thanks for the answers, more questions coming!
I checked out the server and the mailbox repo, and followed the instructions, I ran a couple of mvn commands, and got a bunch of jars. All is fine until I get here:
Step 2: Unpack the archive into your James installation directory -- what... where? I only have jars.
It continues to describe a binary folder, which is nowhere to be seen in the container-spring project, nor in the cli and core projects. Apparently I'm missing something?
Meanwhile I'm browsing the javadocs for the mailbox project. I'm starting to get an idea what the store API is used for and how the memory mailbox works, but the grand scheme still eludes me.
Is there any more documentation about installing and configuring James for development?
I'm still not sure what to think of the REST API. Do you want to have a IMAP 'replacement' that is RESTful, or just an abstraction over a simple key-value store? (I just realized that, in a way, a CouchDB mailbox is already a REST interface to James)
Interesting reading material: http://www.prescod.net/rest/restmail/
Pepijn
On Aug 13, 2011, at 7:26 PM, Norman Maurer wrote:
> Hi there,
>
> first of welcome to JAMES :) Answer of your questions inline..
>
> 2011/8/13 Pepijn de Vos <pe...@yahoo.com>:
>> Hey,
>>
>> I was Googling around for a mail server that I could use with a nice database, so I can query the mail in interesting ways for my webmail/newsgroup/whatever app.
>>
>> I found a GSOC page that listed this as a possible project. I contacted the mentor (Robert) to see if someone picked it up yet. It seems like that someone is going to be me.
>>
>> Robert told me to introduce myself and the project here, together with any questions.
>>
>> For the database I was thinking about a graph database, such as Jiraph. But I think the community might be better served by a CouchDB backend. So what I might do is just run Jiraph on CouchDB.
>
> CouchDB sounds like a good fit for a mailbox storage
>
>>
>> If you just googled Jiraph, you'd have found it's written in Clojure. I can write Java as well, but if it is not a problem, I prefer Clojure for writing the backend.
>>
>> This raises my second question: Will the backend be included in James, in an extras repo, or as a separate project? If it's *not* going to be a separate project, requiring Clojure as a runtime dependency might not be desirable.
>
> It would be a sub-module in the mailbox project. See:
> http://svn.apache.org/viewvc/james/mailbox/trunk/
>
> We have the following implementations astm:
> * memory
> * maildir
> * jpa
> * jcr
> * hbase (once it get imported as it get currently coded a port of GSOC)
>
>
>>
>> I previously ran James as a standalone application, and successfully telnet'd into it. However, I could not figure out how to configure which backend to use. Could anyone explain that, or point me at the right documentation?
>
> Its done via the mailbox.xml There is a BeanFactoryPostProcessor which
> takes care of loading the right classes then...
>
>
>>
>> What would be the best way to start? I found the inmemory backend, which I suppose is the minimal required. Again, any links or explanations about the components are appreciated.
>
> The best way to start is to have a look at the currently existing
> implementations. You should also use the higher level API which resist
> in the store module, as it makes it easier to write your own
> implementation
>
>
>>
>> The GSOC description mentioned a REST protocol. What is meant here?
>
> I think the idea was to provide an REST-LIKE implementation of the
> mailbox. So you could write your mailbox implementation in whatever
> programming language. You would just talk via a webservice to your
> impl.
>
> See http://www.infoq.com/articles/rest-introduction
>
>
>>
>> Pepijn de Vos
>
> I also have a Cassandra implementation of the mailbox here (still a
> prototype and not opensource atm). So we have currently the Hbase and
> the Cassandra impls as nosql solution.
>
> Bye,
> Norman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: NoSQL backend for James
Posted by Norman Maurer <no...@googlemail.com>.
Hi there,
first of welcome to JAMES :) Answer of your questions inline..
2011/8/13 Pepijn de Vos <pe...@yahoo.com>:
> Hey,
>
> I was Googling around for a mail server that I could use with a nice database, so I can query the mail in interesting ways for my webmail/newsgroup/whatever app.
>
> I found a GSOC page that listed this as a possible project. I contacted the mentor (Robert) to see if someone picked it up yet. It seems like that someone is going to be me.
>
> Robert told me to introduce myself and the project here, together with any questions.
>
> For the database I was thinking about a graph database, such as Jiraph. But I think the community might be better served by a CouchDB backend. So what I might do is just run Jiraph on CouchDB.
CouchDB sounds like a good fit for a mailbox storage
>
> If you just googled Jiraph, you'd have found it's written in Clojure. I can write Java as well, but if it is not a problem, I prefer Clojure for writing the backend.
>
> This raises my second question: Will the backend be included in James, in an extras repo, or as a separate project? If it's *not* going to be a separate project, requiring Clojure as a runtime dependency might not be desirable.
It would be a sub-module in the mailbox project. See:
http://svn.apache.org/viewvc/james/mailbox/trunk/
We have the following implementations astm:
* memory
* maildir
* jpa
* jcr
* hbase (once it get imported as it get currently coded a port of GSOC)
>
> I previously ran James as a standalone application, and successfully telnet'd into it. However, I could not figure out how to configure which backend to use. Could anyone explain that, or point me at the right documentation?
Its done via the mailbox.xml There is a BeanFactoryPostProcessor which
takes care of loading the right classes then...
>
> What would be the best way to start? I found the inmemory backend, which I suppose is the minimal required. Again, any links or explanations about the components are appreciated.
The best way to start is to have a look at the currently existing
implementations. You should also use the higher level API which resist
in the store module, as it makes it easier to write your own
implementation
>
> The GSOC description mentioned a REST protocol. What is meant here?
I think the idea was to provide an REST-LIKE implementation of the
mailbox. So you could write your mailbox implementation in whatever
programming language. You would just talk via a webservice to your
impl.
See http://www.infoq.com/articles/rest-introduction
>
> Pepijn de Vos
I also have a Cassandra implementation of the mailbox here (still a
prototype and not opensource atm). So we have currently the Hbase and
the Cassandra impls as nosql solution.
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org