Robert Burrell Donkin ha scritto:
On Fri, Jul 11, 2008 at 6:43 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Stefano Bagnara ha scritto:
Robert Burrell Donkin ha scritto:
On 7/11/08, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
As I reported some weeks ago I found that many IMAP/SUBSCRIBER tests was
failing in my environment when I used Java 1.4 while they passed under
java 5+.
I debugged this and found that the
FileUserMetaDataRepository.fileSystemSafeName when called with long
names (e.g:
org.apache.james.imapserver.processor.imap4rev1.SUBSCRIPTIONS) resulted
in very long file names (e.g:
pgaashaahgaaocaabgaaqhaabgaadgaaigaafgaaocaakgaabgaangaafgaathaaocaajgaangaabgaaqhaathaafgaashaawhaafgaashaaocaaqhaashaapgaadgaafgaathaathaapgaashaaocaajgaangaabgaaqhaaudaashaafgaawhaardaaocaatfaavfaaceaatfaadeaasfaajeaaqfaaufaajeaapeaaoeaatfaa.ser
)
Adding this code at the beginning of the method made the test pass:
-------------
int dotPos = value.lastIndexOf(".");
if (false && dotPos > 0) {
value = value.substring(dotPos);
}
------------
Of course this may not be appropriate (I don't know what keys are used
there): Robert, have you any suggestion for this?
windows?
Yes, Windows Vista Hope Premium x86/ITA
I guess this could be the cause:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4403166
Windows NT + on NTFS does indeed support very long (255+) file names, but
java 1.4 on windows does not.
good hunting, sounds about right 8-)
Either we try to use shorter names or we write somewhere that under windows
we don't support java 1.4.
that particular implementation is a bit of a toy anyway, not something
i'd recommend using in production. feel free to note that IMAP
subscriptions for deeply nested directory structures are not supported
on windows when using Java1.4 and that particular user preference
backend. or just patch the code or the test.
I don't know that code: can we simply use a shorter identifier instead
of "org.apache.james.imapserver.processor.imap4rev1.SUBSCRIPTIONS" ?
(e.g: "james.imap4r1.SUBSCRIPTIONS")
i'm now think that factoring out an API was a poor tradeoff. so this
will probably end up being deleted. i'm now in favour of pushing all
the function required by IMAP into the mailbox API and letting the
backend sort out the implementation. this task was waiting for the
backend rewrite, though.
Sounds good!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
