James Server
  1. James Server
  2. JAMES-461

Javamail Store based MailRepository support (was: Maildir support)

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Labels:
      None

      Description

      Add support for Javamail Stores as MailRepositories

      1. diff_to-javamaildir-0.7-pre1-2.diff
        74 kB
        Joachim Draeger
      2. JavamailStoreMailRepository.java
        12 kB
        Norman Maurer
      3. JavamailStoreMailRepository2.zip
        21 kB
        Joachim Draeger
      4. javamailstore-mailrepository-3.zip
        175 kB
        Joachim Draeger
      5. javamailstore-mailrepository-4.zip
        188 kB
        Joachim Draeger
      6. javamailstore-mailrepository-5.jar
        26 kB
        Norman Maurer
      7. MaildirMailRepository.java
        12 kB
        Stefano Bagnara
      8. MaildirMailRepository.java
        13 kB
        Norman Maurer
      9. UIDPlusFolderMailRepository1.zip
        9 kB
        Joachim Draeger

        Issue Links

          Activity

          Hide
          Norman Maurer added a comment -

          First Version based un the patch of alex.. This need the javamail.jar for compile

          Show
          Norman Maurer added a comment - First Version based un the patch of alex.. This need the javamail.jar for compile
          Hide
          Stefano Bagnara added a comment -

          It is ok if it needs javamail. The problematic import is the one from "javamailDIR".

          You should use MimeMessage instead of MaildirMessage.
          The problem is the missing getUniq method.

          But reviewing the code I see further problems: using that code you are not able to retrieve a message from a repository given the message key (name) without a prior "list()" call. This is not part of the "repository contract".

          If we cannot find a workaround for this we probably should wait until we'll refactor the repository interface so that the store() return an handler to retrieve the message later.

          Show
          Stefano Bagnara added a comment - It is ok if it needs javamail. The problematic import is the one from "javamailDIR". You should use MimeMessage instead of MaildirMessage. The problem is the missing getUniq method. But reviewing the code I see further problems: using that code you are not able to retrieve a message from a repository given the message key (name) without a prior "list()" call. This is not part of the "repository contract". If we cannot find a workaround for this we probably should wait until we'll refactor the repository interface so that the store() return an handler to retrieve the message later.
          Hide
          Stefano Bagnara added a comment -

          I removed all but one of the references to javamaildir.
          I added a TODO to the last call that should be replaced.
          It still will not be compliant to the mailrepository contract but maybe it will work because of the current usage of the mailrepository bundled objects by james.

          If somewhere in the james code we expect to find a message in a repository by name after having stored it this repository will not work.

          Show
          Stefano Bagnara added a comment - I removed all but one of the references to javamaildir. I added a TODO to the last call that should be replaced. It still will not be compliant to the mailrepository contract but maybe it will work because of the current usage of the mailrepository bundled objects by james. If somewhere in the james code we expect to find a message in a repository by name after having stored it this repository will not work.
          Hide
          Norman Maurer added a comment -

          Rename the class and fix the TODO

          Show
          Norman Maurer added a comment - Rename the class and fix the TODO
          Hide
          Stefano Bagnara added a comment -

          Here is a problematic scenario:

          Iterator i1 = repos.list();
          Iterator i2 = repos.list();
          repos.retrieve(i1.next());

          IMHO the second call to repos.list() reset/renew the uniqToMessageNumber hashtable and it will prevent the following retrieve from working.

          MailRepository MUST be thread safe, so we cannot relay on the exact sequence list=>retrieve. Another thread could run another list before our retrieve.

          Any idea on how to solve this?

          Show
          Stefano Bagnara added a comment - Here is a problematic scenario: Iterator i1 = repos.list(); Iterator i2 = repos.list(); repos.retrieve(i1.next()); IMHO the second call to repos.list() reset/renew the uniqToMessageNumber hashtable and it will prevent the following retrieve from working. MailRepository MUST be thread safe, so we cannot relay on the exact sequence list=>retrieve. Another thread could run another list before our retrieve. Any idea on how to solve this?
          Hide
          Norman Maurer added a comment -

          Not yet.. But maybe someone else.. How you solve the problem in MboxMailRepository.. Maybe we can use something like in there..

          Show
          Norman Maurer added a comment - Not yet.. But maybe someone else.. How you solve the problem in MboxMailRepository.. Maybe we can use something like in there..
          Hide
          Joachim Draeger added a comment -

          This is my proposal for the Maildir access in James.
          For better traceability i have extendet Alexander's and Norman's efforts.
          I think it's the right approach to access Maildir through the existing implementation (javamaildir) and if needed contribute back to it.
          By the way, Javamail would be a sufficient backend for a imap, one of the most missed features in James.
          I have made some progress getting the existing imap code to run that way, more to it later.

          My solution to the "James message key to Javamail message" problem depends on the UID capabilities of Javamail and Javamaildir. That is managed by the UIDFolder http://java.sun.com/products/javamail/javadocs/javax/mail/UIDFolder.html interface which is implemented by MaildirFolder. Unfortunately Javamail has imho a few design deficiencies. You cannot determine which uid a stored message is assigned. The IMAPFolder has such methods: http://java.sun.com/products/javamail/javadocs/com/sun/mail/imap/IMAPFolder.html#appendUIDMessages(javax.mail.Message[])
          Why the didn't they encapsulate that important functionality in an extra interface?
          I wrote a patch for javamaildir-0.6.2 (just a few lines) to implement that imaginary interface (UIDPlusFolder) and a MailRepository implementation which should work with any Javamail store which Folder implements that UIDPlusFolder interface.

          Imo at the moment there is no way to implement this in pure Javamail. Maybe it is possible to implement an universal Javamail store adapter for James depending on MD5 sums etc, but that would cost the biggest Maildir advantage: speed.
          I guess it is no problem to ask to include that few new methods in javamaildir, which allow getting UIDs for added messages.
          Asking for including UIDPlusFolder in Javamail is an attempt worth, but will surely take years.
          Without common interface there are these ugly licensing problems and dependencies again. But we shouldn't get slow down by that. In a worst case
          needed methods could be called via reflection. (i hate the word impossible)
          Maven2 could maybe make things easier, too.

          What do you think, could this be an solution to fulfill the James MailStore contract?

          Some notes for running the code:

          • The code is some kind of "proof-of-concept" and not really testet. (messages are stored and loaded, log looks good)
          • I run it in a test enviroment using trunk r399103 (it should run with newer/older versions too)
          • It depends on javamail-1.4.0.
          • The java-maildir-0.6.2-UIDPlusFolder.patch has to be applied to the archive from http://devel.priocom.com/~zhukov/javamaildir/ the resulting jar is needed to compile UIDPlusFolderMailRepository because of the UIDPlusFolder interface (I can send you a copy of the resulting jar by private email, just ask)

          Joachim Draeger <jd at joachim-draeger.de>

          Cologne, Germany, 2006-05-16

          Show
          Joachim Draeger added a comment - This is my proposal for the Maildir access in James. For better traceability i have extendet Alexander's and Norman's efforts. I think it's the right approach to access Maildir through the existing implementation (javamaildir) and if needed contribute back to it. By the way, Javamail would be a sufficient backend for a imap, one of the most missed features in James. I have made some progress getting the existing imap code to run that way, more to it later. My solution to the "James message key to Javamail message" problem depends on the UID capabilities of Javamail and Javamaildir. That is managed by the UIDFolder http://java.sun.com/products/javamail/javadocs/javax/mail/UIDFolder.html interface which is implemented by MaildirFolder. Unfortunately Javamail has imho a few design deficiencies. You cannot determine which uid a stored message is assigned. The IMAPFolder has such methods: http://java.sun.com/products/javamail/javadocs/com/sun/mail/imap/IMAPFolder.html#appendUIDMessages(javax.mail.Message[ ]) Why the didn't they encapsulate that important functionality in an extra interface? I wrote a patch for javamaildir-0.6.2 (just a few lines) to implement that imaginary interface (UIDPlusFolder) and a MailRepository implementation which should work with any Javamail store which Folder implements that UIDPlusFolder interface. Imo at the moment there is no way to implement this in pure Javamail. Maybe it is possible to implement an universal Javamail store adapter for James depending on MD5 sums etc, but that would cost the biggest Maildir advantage: speed. I guess it is no problem to ask to include that few new methods in javamaildir, which allow getting UIDs for added messages. Asking for including UIDPlusFolder in Javamail is an attempt worth, but will surely take years. Without common interface there are these ugly licensing problems and dependencies again. But we shouldn't get slow down by that. In a worst case needed methods could be called via reflection. (i hate the word impossible) Maven2 could maybe make things easier, too. What do you think, could this be an solution to fulfill the James MailStore contract? Some notes for running the code: The code is some kind of "proof-of-concept" and not really testet. (messages are stored and loaded, log looks good) I run it in a test enviroment using trunk r399103 (it should run with newer/older versions too) It depends on javamail-1.4.0. The java-maildir-0.6.2-UIDPlusFolder.patch has to be applied to the archive from http://devel.priocom.com/~zhukov/javamaildir/ the resulting jar is needed to compile UIDPlusFolderMailRepository because of the UIDPlusFolder interface (I can send you a copy of the resulting jar by private email, just ask) Joachim Draeger <jd at joachim-draeger.de> Cologne, Germany, 2006-05-16
          Hide
          Norman Maurer added a comment -

          Nice to see that people work on james
          I will test your patch tomorrow. But the main problem with this is that we need to patch javamail. Thats really ugly BTW i don'T think that if you contribute this patches to javamail that they will ever be included.

          Maybe we can find a other solution...

          thx anyway

          Show
          Norman Maurer added a comment - Nice to see that people work on james I will test your patch tomorrow. But the main problem with this is that we need to patch javamail. Thats really ugly BTW i don'T think that if you contribute this patches to javamail that they will ever be included. Maybe we can find a other solution... thx anyway
          Hide
          Joachim Draeger added a comment -

          No, it isn't necessary to patch javamail. I don't think it's a big problem to contribute that few, little but powerful methods to javamaildir.
          The problem is how to access that methods because javamail nonsensically doesn't offer such an interface (UIDPlusFolder). (But using that methods in the class IMAPFolder)
          I'm not willing to accept this seeming insuperable borders between Apache and GPL. There is a good java implementation of maildir, we should use it.
          In a worst case we could use reflection to avoid strong dependencies.

          To clarify the original problem: When you store a mail in a javamail Folder, a copy get's stored and it is not possible to find that copy again. So this doesn't fit in James MailStore contract.

          Show
          Joachim Draeger added a comment - No, it isn't necessary to patch javamail. I don't think it's a big problem to contribute that few, little but powerful methods to javamaildir. The problem is how to access that methods because javamail nonsensically doesn't offer such an interface (UIDPlusFolder). (But using that methods in the class IMAPFolder) I'm not willing to accept this seeming insuperable borders between Apache and GPL. There is a good java implementation of maildir, we should use it. In a worst case we could use reflection to avoid strong dependencies. To clarify the original problem: When you store a mail in a javamail Folder, a copy get's stored and it is not possible to find that copy again. So this doesn't fit in James MailStore contract.
          Hide
          Noel J. Bergman added a comment -

          We cannot use any GPL code. Period. It will not happen. If someone wants to write a new maildir implementation using an acceptable license, that's fine.

          Show
          Noel J. Bergman added a comment - We cannot use any GPL code. Period. It will not happen. If someone wants to write a new maildir implementation using an acceptable license, that's fine.
          Hide
          Joachim Draeger added a comment -

          This proposal has no other dependencies than Javamail (i think even before 1.4) and James.

          HashJavamailStoreMailRepository should work with every JavamailStore implementation that has deterministic
          message content. (checksum save). Performance could be quite good because after storing/listing it tries to get the messages by the last seen message number.

          UIDPlusFolderMailRepository depends on javamail Folders that have a public long[] addUIDMessages(Message[] msgs); method which returns the uids of the added messages. This method is called via reflection, and in the future even the message name might be configureable form config.xml.
          At the moment there is no known Javamail store implementation that provides such a method, but it should come soon.

          The Javamail store url is not configureable in the unit tests at the moment. Nearly all tests depend on getNativeMessageCount(), and getNativeMessages() at the moment. I plan to write a few more general tests in the future.

          This implementation should be considered as EXPERIMENTAL, but I think it's not so far from being stable.

          Joachim

          Show
          Joachim Draeger added a comment - This proposal has no other dependencies than Javamail (i think even before 1.4) and James. HashJavamailStoreMailRepository should work with every JavamailStore implementation that has deterministic message content. (checksum save). Performance could be quite good because after storing/listing it tries to get the messages by the last seen message number. UIDPlusFolderMailRepository depends on javamail Folders that have a public long[] addUIDMessages(Message[] msgs); method which returns the uids of the added messages. This method is called via reflection, and in the future even the message name might be configureable form config.xml. At the moment there is no known Javamail store implementation that provides such a method, but it should come soon. The Javamail store url is not configureable in the unit tests at the moment. Nearly all tests depend on getNativeMessageCount(), and getNativeMessages() at the moment. I plan to write a few more general tests in the future. This implementation should be considered as EXPERIMENTAL, but I think it's not so far from being stable. Joachim
          Hide
          Norman Maurer added a comment -

          Just after a quick review it seems to be nice work. Will install it tomorrow and test it a bit . Thx for your help and work.

          Show
          Norman Maurer added a comment - Just after a quick review it seems to be nice work. Will install it tomorrow and test it a bit . Thx for your help and work.
          Hide
          Joachim Draeger added a comment -

          Issue in JavamailStoreMailRepository2.zip: When accessed by multiple threads, Folder should be closed when all have finished. (remove getOpenedFolder in favour of getFolder and void openFolder, increment a counter in openFolder, synchronized void closeFolder: decrement counter, close when 0)

          Show
          Joachim Draeger added a comment - Issue in JavamailStoreMailRepository2.zip: When accessed by multiple threads, Folder should be closed when all have finished. (remove getOpenedFolder in favour of getFolder and void openFolder, increment a counter in openFolder, synchronized void closeFolder: decrement counter, close when 0)
          Hide
          Norman Maurer added a comment -

          After first test i don't get it to work.

          1. It don't seems to create the inboxes folder. I have set the mailstore logging level to DEBUG. No exceptions seen here
          2. When try login via pop3 it just disconnect after the pass is passed. I also changed here the logging level. No exceptions found. Should it not throw and illegalStateException ?

          Show
          Norman Maurer added a comment - After first test i don't get it to work. 1. It don't seems to create the inboxes folder. I have set the mailstore logging level to DEBUG. No exceptions seen here 2. When try login via pop3 it just disconnect after the pass is passed. I also changed here the logging level. No exceptions found. Should it not throw and illegalStateException ?
          Hide
          Joachim Draeger added a comment -

          To setup a Javamail store MailRepository you have to make sure the corresponding Javamail implementation, e.g. javamaildir-0.6.2.jar, is added at the SAR-INF/lib directory of the james.sar. To check this, you can open james.sar with your favorite ZIP packer.

          1. possibility: put the jar in the lib directory of the trunk and modify include.properties and build.xml

          Index: B:/java/jamesws/JamesSecondTrunk/build.xml
          ===================================================================
          — B:/java/jamesws/JamesSecondTrunk/build.xml (revision 409878)
          +++ B:/java/jamesws/JamesSecondTrunk/build.xml (working copy)
          @@ -503,6 +503,7 @@
          <include name="$

          {excalibur-datasource.jar}

          "/>
          <include name="$

          {javax-activation.jar}

          "/>
          <include name="$

          {javax-mail.jar}

          "/>
          + <include name="$

          {javamaildir.jar}

          "/>
          <include name="$

          {commons-dbcp.jar}

          "/>
          <include name="$

          {commons-pool.jar}

          "/>
          <include name="$

          {bcmail.jar}

          "/>

          Index: B:/java/jamesws/JamesSecondTrunk/include.properties
          ===================================================================
          — B:/java/jamesws/JamesSecondTrunk/include.properties (revision 409878)
          +++ B:/java/jamesws/JamesSecondTrunk/include.properties (working copy)
          @@ -42,6 +42,9 @@

          1. ----- Activation -----
            javax-activation.jar=$ {activation.id}

            .jar

          +# ----- javamaildir
          +javamaildir.jar=javamaildir-0.6.2.jar
          +

          1. ----- DNS -----
            dns.jar=dnsjava-2.0.1.jar

          then run ant.

          2. possibility: open james.sar with you favorite zip packer and inject the jar directly into the SAR-INF/lib directory.

          I don't like both methods. There should be a more convenient way. Is there?

          Of course you have to add JavamailStoreMailRepository code, too. You can do this by putting source files directly into the src/java directory of the trunk. Another way, that has the advantage of not touching your working copy, is to build a jar of the code first and add it like the javamail store implementation explained above.

          Show
          Joachim Draeger added a comment - To setup a Javamail store MailRepository you have to make sure the corresponding Javamail implementation, e.g. javamaildir-0.6.2.jar, is added at the SAR-INF/lib directory of the james.sar. To check this, you can open james.sar with your favorite ZIP packer. 1. possibility: put the jar in the lib directory of the trunk and modify include.properties and build.xml Index: B:/java/jamesws/JamesSecondTrunk/build.xml =================================================================== — B:/java/jamesws/JamesSecondTrunk/build.xml (revision 409878) +++ B:/java/jamesws/JamesSecondTrunk/build.xml (working copy) @@ -503,6 +503,7 @@ <include name="$ {excalibur-datasource.jar} "/> <include name="$ {javax-activation.jar} "/> <include name="$ {javax-mail.jar} "/> + <include name="$ {javamaildir.jar} "/> <include name="$ {commons-dbcp.jar} "/> <include name="$ {commons-pool.jar} "/> <include name="$ {bcmail.jar} "/> Index: B:/java/jamesws/JamesSecondTrunk/include.properties =================================================================== — B:/java/jamesws/JamesSecondTrunk/include.properties (revision 409878) +++ B:/java/jamesws/JamesSecondTrunk/include.properties (working copy) @@ -42,6 +42,9 @@ ----- Activation ----- javax-activation.jar=$ {activation.id} .jar +# ----- javamaildir +javamaildir.jar=javamaildir-0.6.2.jar + ----- DNS ----- dns.jar=dnsjava-2.0.1.jar then run ant. 2. possibility: open james.sar with you favorite zip packer and inject the jar directly into the SAR-INF/lib directory. I don't like both methods. There should be a more convenient way. Is there? Of course you have to add JavamailStoreMailRepository code, too. You can do this by putting source files directly into the src/java directory of the trunk. Another way, that has the advantage of not touching your working copy, is to build a jar of the code first and add it like the javamail store implementation explained above.
          Hide
          Joachim Draeger added a comment -

          javamailstore-mailrepository-3

          • folder is now accessed through a gatekeeper that manages open/close operation
            this allows access by concurrent threads
          • introduced several interfaces for easier mock based tests
          • ant build
          • jMock based interaction/behavior tests
          • optional code coverage analysis by cobertura

          Oh, "mock framework" and "code coverage", isn't that a bit overkill?
          Mmhhhh.. let me think... No!
          I think xMock can always be useful even if only used for a few lines. Making a code coverage analysis showed me a few missing important test cases (not only to reach the 100%)
          Okay, maybe I mocked a bit to low level. But I wanted to evaluate how it can
          help. The build process with integrated code coverage analysis was made for
          evaluation too. Looking forward to imap!
          I'll drop a few lines, why I have decided for jMock and Cobertura soon.

          Show
          Joachim Draeger added a comment - javamailstore-mailrepository-3 folder is now accessed through a gatekeeper that manages open/close operation this allows access by concurrent threads introduced several interfaces for easier mock based tests ant build jMock based interaction/behavior tests optional code coverage analysis by cobertura Oh, "mock framework" and "code coverage", isn't that a bit overkill? Mmhhhh.. let me think... No! I think xMock can always be useful even if only used for a few lines. Making a code coverage analysis showed me a few missing important test cases (not only to reach the 100%) Okay, maybe I mocked a bit to low level. But I wanted to evaluate how it can help. The build process with integrated code coverage analysis was made for evaluation too. Looking forward to imap! I'll drop a few lines, why I have decided for jMock and Cobertura soon.
          Hide
          Joachim Draeger added a comment -

          1. Please note that it is much easier to add the jars than described above: see INSTALL.txt. (Thanks to Norman)

          2. There is an issue with storing messages and the Flag.RECENT.
          At the moment messages are stored, after opening the JavaMail Folder. This may cause that the RECENT Flag is removed after storing. In Maildir this means that the message gets moved immediately from the new into the cur folder.
          AFAIK James doesn't care about the RECENT Flag and POP3 doesn't make a difference at all.
          Apart from that: It is impossible to preserve the RECENT Flag between MailRepository.list() and retrieve() with JavaMail API.
          An IMAP enabled MessageRepository would have to be some kind of session agnostic.
          Anyway: I'll try to make it deliver to closed Folders. That way we would fulfill the contract for 3rd party apps accessing e.g. Maildir directly. The IMAP server will also need that.

          Show
          Joachim Draeger added a comment - 1. Please note that it is much easier to add the jars than described above: see INSTALL.txt. (Thanks to Norman) 2. There is an issue with storing messages and the Flag.RECENT. At the moment messages are stored, after opening the JavaMail Folder. This may cause that the RECENT Flag is removed after storing. In Maildir this means that the message gets moved immediately from the new into the cur folder. AFAIK James doesn't care about the RECENT Flag and POP3 doesn't make a difference at all. Apart from that: It is impossible to preserve the RECENT Flag between MailRepository.list() and retrieve() with JavaMail API. An IMAP enabled MessageRepository would have to be some kind of session agnostic. Anyway: I'll try to make it deliver to closed Folders. That way we would fulfill the contract for 3rd party apps accessing e.g. Maildir directly. The IMAP server will also need that.
          Hide
          Joachim Draeger added a comment -

          javamailstore-mailrepository-4

          • HashJavamailStoreMailRepository always allows to deliver to a closed
            folder. It opens the folder for getMessageCount() only if necessary
          • HashJavamailStoreMailRepository was missing capability to update
            message when store got called with an existing key
          • UIDPlusFolderMailRepository tries first to deliver to a closed folder.
            If IllegalStateException was caught it retries on the opened folder.
          • Flag.RECENT is set on MimeMessage before passed to JavaMail Store
          • when using javamaildir, new messages should stay in the new folder
            until list() or retrieve() is called on Repository.
            thanks to Norman for reporting this!
          • tested with James-2.3.0b1

          see INSTALL.txt

          A completely compatible javamaildir version (greater than 0.7-pre1) is on the way, I will announce it here. I provide unofficial prerelease by private email for the impatient!

          I appreciate any feedback! Success, issues, bad style...

          Show
          Joachim Draeger added a comment - javamailstore-mailrepository-4 HashJavamailStoreMailRepository always allows to deliver to a closed folder. It opens the folder for getMessageCount() only if necessary HashJavamailStoreMailRepository was missing capability to update message when store got called with an existing key UIDPlusFolderMailRepository tries first to deliver to a closed folder. If IllegalStateException was caught it retries on the opened folder. Flag.RECENT is set on MimeMessage before passed to JavaMail Store when using javamaildir, new messages should stay in the new folder until list() or retrieve() is called on Repository. thanks to Norman for reporting this! tested with James-2.3.0b1 see INSTALL.txt A completely compatible javamaildir version (greater than 0.7-pre1) is on the way, I will announce it here. I provide unofficial prerelease by private email for the impatient! I appreciate any feedback! Success, issues, bad style...
          Hide
          Joachim Draeger added a comment -

          patch to javamaildir-0.7-pre1 for javamailstore-mailrepository-4

          Show
          Joachim Draeger added a comment - patch to javamaildir-0.7-pre1 for javamailstore-mailrepository-4
          Hide
          Stefano Bagnara added a comment -

          I proposed UIDFolderPlus to javamail interest, let's say what Bill Shannon thinks about it.
          http://archives.java.sun.com/cgi-bin/wa?A2=ind0609&L=javamail-interest&F=&S=&P=78

          I also think that we could start including the "Javamail Store based MailRepository" into the source repository now that we found a license compatible javamail store implementation (MStore => file based, mbox format, repository). If MStor works like expected this is indeed a great news for our IMAP roadmap as we don't need to depend on javamaildir and we don't have to wait for a in house development of the JDBC based javamail store.

          Show
          Stefano Bagnara added a comment - I proposed UIDFolderPlus to javamail interest, let's say what Bill Shannon thinks about it. http://archives.java.sun.com/cgi-bin/wa?A2=ind0609&L=javamail-interest&F=&S=&P=78 I also think that we could start including the "Javamail Store based MailRepository" into the source repository now that we found a license compatible javamail store implementation (MStore => file based, mbox format, repository). If MStor works like expected this is indeed a great news for our IMAP roadmap as we don't need to depend on javamaildir and we don't have to wait for a in house development of the JDBC based javamail store.
          Hide
          Norman Maurer added a comment -

          I did two fixes on joachims great work:

          • fix the path where the messages get stored
          • connect the store
          Show
          Norman Maurer added a comment - I did two fixes on joachims great work: fix the path where the messages get stored connect the store
          Hide
          Joachim Draeger added a comment -

          Unfortunately mstor does not support any UID capabilities. So it is not suitable as an IMAP backend. And I guess it does not fully support the needed flags. (didn't test it).
          From my point of view the IMAP blocker is not the lack of a suitable implementation but of new repository API for James.
          It would be a pleasure for me starting with or helping on a corresponding JDBC implementation after some decisions have been made how the API should look like.

          At the moment I would be +0 for including javamailstore-mailrepository into trunk because I hope for a new API in James that fits the needs of JavaMail a bit better.
          The current "client" generated permanent key in MailRepository is totally incompatible with the requirements of mbox, IMAP and JavaMail.

          Joachim

          Show
          Joachim Draeger added a comment - Unfortunately mstor does not support any UID capabilities. So it is not suitable as an IMAP backend. And I guess it does not fully support the needed flags. (didn't test it). From my point of view the IMAP blocker is not the lack of a suitable implementation but of new repository API for James. It would be a pleasure for me starting with or helping on a corresponding JDBC implementation after some decisions have been made how the API should look like. At the moment I would be +0 for including javamailstore-mailrepository into trunk because I hope for a new API in James that fits the needs of JavaMail a bit better. The current "client" generated permanent key in MailRepository is totally incompatible with the requirements of mbox, IMAP and JavaMail. Joachim
          Hide
          Norman Maurer added a comment -

          mstor provide to store metadata (flags etc ) to xml files so it should be ok. See: http://mstor.sourceforge.net/features.html

          Show
          Norman Maurer added a comment - mstor provide to store metadata (flags etc ) to xml files so it should be ok. See: http://mstor.sourceforge.net/features.html
          Hide
          Norman Maurer added a comment -

          was applied to trunk

          Show
          Norman Maurer added a comment - was applied to trunk

            People

            • Assignee:
              Norman Maurer
              Reporter:
              Norman Maurer
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development