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 "Martin.Bergljung" <Ma...@opsera.com> on 2009/03/11 09:43:12 UTC

Are there nightly builds for http://svn.apache.org/repos/asf/james/protocols/imap/trunk?

Hi,

 

I am upgrading a product that uses an earlier version of Apache James
IMAP to use the new implementation under
http://svn.apache.org/repos/asf/james/protocols/imap/trunk 

 

However, when using the libs from the
james-server-spring-deployment-3.0-SNAPSHOT builds I noticed that the 

apache-james-imap-****-0.1-SNAPSHOT.jar libs did not correspond to the
source code under
http://svn.apache.org/repos/asf/james/protocols/imap/trunk 

(I assumed these libs were built from
http://svn.apache.org/repos/asf/james/protocols/imap/trunk nightly)

 

For example, the Mailbox class is in the
org.apache.james.mailboxmanager.mailbox package when using the
apache-james-imap-mailbox-0.1-SNAPSHOT.jar  lib but the source code
under http://svn.apache.org/repos/asf/james/protocols/imap/trunk  has it
in the org.apache.james.imap.mailbox package.

 

Is there any nightly builds for the IMAP protocol layer or should I
build from the source code. I tried to build from the source but got
some errors, probably because I did not configure the use of the
property files correctly or something. Any readme file available for how
to build the IMAP layer, should I use ant or maven? Sorry for the
trivial questions.

 

 

Martin Bergljung

 


Re: Are there nightly builds for http://svn.apache.org/repos/asf/james/protocols/imap/trunk?

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Mar 17, 2009 at 6:45 PM, Martin.Bergljung
<Ma...@opsera.com> wrote:
> Hi,
>
> Regarding the build: I can get the /james/server/trunk and build it
> without any problem.
>                     Building /james/protocols/imap/trunk does not work
> with ant. Missing some macros,
>                     added them but got more errors, libs missing.
>                     So just loaded everything into IDEA and build my
> own jar.


that's odd :-/

i built it several times yesterday without problem. if you could open
up a JIRA and attach a stack trace of the failure, that'd be great.

> I have now managed to swap out the Old IMAP protocol implementation for
> this new one in the Product I am developing.
> A have tested it in Outlook, Thunderbird, and Lotus Notes. Notes has a
> bit to go I think as it fetches partially instead of Full Content as
> Outlook and Thunderbird. But probably something in my Result builder I
> need to fix.

IMAP is a complete PITA. thunderbird doesn't work to my satisfaction
but since evolution has now broken IMAP (after the upgrade to SQLLite,
transaction bugs for multi mailboxes have only been fixed in the
unstable trunk) i'm now working on that.

to be honest, though i believe IMAP to be reasonably compliant with
the specification (the functional tests have good coverage of the
basics), i only really consider it alpha quality. in particular, the
torque backend needs to be replaced. developers have reported
successes forking the code for their own purposes but if the APIs are
still evolving so it's best to play close attention. if it's possible
for you to contribute to the development of james then it might be in
your best interests to do so.

> However, as my backend is Alfresco

(i'd be interested in collaborating in if this is an open source project)

if you're porting to a new backend, once the functional tests run then
you'll have basic IMAP compatibility

> and hierarchy delimiter is / I had to
> just change that directly in ImapConstants
> as the request for hierarchy delimiter is kept entirely in IMAP layer
> (i.e. A1 LIST "" ""). Or is there another way to do that.

this should really be configurable but probably only at assembly time

i've raised https://issues.apache.org/jira/browse/IMAP-70. hopefully,
someone will get to it sometime soon.

> Further on, when using the previous IMAP implementation I was keeping a
> ThreadLocal object that I called AlfrescoPerson with a couple of
> properties for logged on user. With this new implementation I will have
> to change that as the threads
> does not stick to an IMAP session, or I am doing something wrong, but
> better scaling anyway...

yes, the threads are pooled

if it's just a backend attribute then create a MailboxSession
implementation that stores the addition information (the API is still
fluid so if you have any design ideas or requests, feel free to post
them to the list or raise a JIRA)

if it's an attribute that processors are going to be need to
understand then use ImapSession getAttribute/setAttribute

> Also, I do not pass around the user namespace and username for the
> mailboxes (e.g. #mail.martin) but instead rely on
> being able to get to the AlfrescoPerson object for logged on user (i
> strip off the #mail.martin in the MailboxManager.resolve method -
> although this is not completely consistent as I still get the
> #mail.martin passed to for example MailboxManager.search).
>
> I deal with mailboxes such as "/Company Home", "/Company
> Home/Marketing", "/Company Home/User Homes/mbergljung" etc and the
> permission system in Alfresco controls if the user has access to them or
> not. So would have been good if I could have used the ImapSession and
> set and attribute there.
>
> So the MailboxManager and Mailbox interface methods could take the
> ImapSession (which includes any MailboxSession)
> and then you could just set any attributes you wanted and have them
> accessible whenever you wanted.

this separation is a consequence of legacy architecture decisions

i've created a JIRA (https://issues.apache.org/jira/browse/IMAP-71)
with some thoughts. please take a look.

> Also noticed that some calls such as SELECT generates more processing
> then necessary, in the following select call each response such as
> recent and total number of messages generates a lot of
> mailboxManager.getMailbox, only one call should be necessary, does it
> have to do with:
>
>        // TODO: compact this into a single API call for meta-data about
> the
>        // repository
>        flags(responder);
>        exists(responder, mailbox, mailboxSession);
>        recent(responder, selected);
>        uidValidity(responder, mailbox, mailboxSession);
>        unseen(responder, mailbox, mailboxSession, selected);
>        permanentFlags(responder, mailbox);
>        taggedOk(responder, tag, command, mailbox);
>
> In the AbstractSelectionProcessor?

i think this need more thought and discussion.

IMAP is an absolutely beastly protocol to use with a modern platform.
at first glance, it might seem to be better to map every protocol
command into a direct, specific data access call. separation of the
processor layer is intended to allow anyone who wants to go down that
route to just rip out the mailbox approach to data access.

however...

1 the justification for a separate mailbox layer for data access is
that it would present a more generally useful API. i've always been a
little sceptic about whether this would be possible but - so far -
i've been able to get adequate performance whist retaining it.
2 from a throughput perspective, when SEDA is switch on, the repeated
data access calls allow writing to start in parrellel to the socket.
in this case, probably single call would be better for many data
access layer. it's a hard call, because which is better depends on the
nature of the data store.

my thinking on transactions is that a call back interface would have
advantages but in any case,  calls would be need to control the
transaction. perhaps an elegant solution would be to allow a hint to
be passed to the mailbox to allow more efficient use of caching.

opinions?

> I will continue testing and fixing so hopefully I can get to a point
> where I can continue with the new IMAP protocol implementation.

great :-)

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


RE: Are there nightly builds for http://svn.apache.org/repos/asf/james/protocols/imap/trunk?

Posted by "Martin.Bergljung" <Ma...@opsera.com>.
Hi,

Regarding the build: I can get the /james/server/trunk and build it
without any problem. 
                     Building /james/protocols/imap/trunk does not work
with ant. Missing some macros, 
                     added them but got more errors, libs missing.
                     So just loaded everything into IDEA and build my
own jar.

I have now managed to swap out the Old IMAP protocol implementation for
this new one in the Product I am developing.
A have tested it in Outlook, Thunderbird, and Lotus Notes. Notes has a
bit to go I think as it fetches partially instead of Full Content as
Outlook and Thunderbird. But probably something in my Result builder I
need to fix.

However, as my backend is Alfresco and hierarchy delimiter is / I had to
just change that directly in ImapConstants
as the request for hierarchy delimiter is kept entirely in IMAP layer
(i.e. A1 LIST "" ""). Or is there another way to do that.

Further on, when using the previous IMAP implementation I was keeping a
ThreadLocal object that I called AlfrescoPerson with a couple of
properties for logged on user. With this new implementation I will have
to change that as the threads 
does not stick to an IMAP session, or I am doing something wrong, but
better scaling anyway...

Also, I do not pass around the user namespace and username for the
mailboxes (e.g. #mail.martin) but instead rely on 
being able to get to the AlfrescoPerson object for logged on user (i
strip off the #mail.martin in the MailboxManager.resolve method -
although this is not completely consistent as I still get the
#mail.martin passed to for example MailboxManager.search). 

I deal with mailboxes such as "/Company Home", "/Company
Home/Marketing", "/Company Home/User Homes/mbergljung" etc and the
permission system in Alfresco controls if the user has access to them or
not. So would have been good if I could have used the ImapSession and
set and attribute there.

So the MailboxManager and Mailbox interface methods could take the
ImapSession (which includes any MailboxSession) 
and then you could just set any attributes you wanted and have them
accessible whenever you wanted.

Also noticed that some calls such as SELECT generates more processing
then necessary, in the following select call each response such as
recent and total number of messages generates a lot of
mailboxManager.getMailbox, only one call should be necessary, does it
have to do with:

        // TODO: compact this into a single API call for meta-data about
the
        // repository
        flags(responder);
        exists(responder, mailbox, mailboxSession);
        recent(responder, selected);
        uidValidity(responder, mailbox, mailboxSession);
        unseen(responder, mailbox, mailboxSession, selected);
        permanentFlags(responder, mailbox);
        taggedOk(responder, tag, command, mailbox);

In the AbstractSelectionProcessor?

I will continue testing and fixing so hopefully I can get to a point
where I can continue with the new IMAP protocol implementation.

Thanks,
Martin







-----Original Message-----
From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com] 
Sent: den 14 mars 2009 10:17
To: James Developers List
Subject: Re: Are there nightly builds for
http://svn.apache.org/repos/asf/james/protocols/imap/trunk?

On Thu, Mar 12, 2009 at 1:19 PM, Bernd Fondermann
<bf...@brainlounge.de> wrote:
> Martin.Bergljung wrote:
>>
>> Hi,
>>
>>
>> I am upgrading a product that uses an earlier version of Apache James
>> IMAP to use the new implementation under
>> http://svn.apache.org/repos/asf/james/protocols/imap/trunk
>>
>> However, when using the libs from the
>> james-server-spring-deployment-3.0-SNAPSHOT builds I noticed that the
>> apache-james-imap-****-0.1-SNAPSHOT.jar libs did not correspond to
the
>> source code under
>> http://svn.apache.org/repos/asf/james/protocols/imap/trunk
>> (I assumed these libs were built from
>> http://svn.apache.org/repos/asf/james/protocols/imap/trunk nightly)
>>
>>
>> For example, the Mailbox class is in the
>> org.apache.james.mailboxmanager.mailbox package when using the
>> apache-james-imap-mailbox-0.1-SNAPSHOT.jar  lib but the source code
>> under http://svn.apache.org/repos/asf/james/protocols/imap/trunk  has
it
>> in the org.apache.james.imap.mailbox package.
>
> I found that the nightly build sometimes (often?) leaves moved
artifacts
> (especially libs) behind. This might be a specialty for the build
server, I
> never was able to reproduce locally, so...

IMAP is very much under development so the SNAPSHOT included in James
trunk is almost always out of date

>> Is there any nightly builds for the IMAP protocol layer or should I
>> build from the source code. I tried to build from the source but got
>> some errors, probably because I did not configure the use of the
>> property files correctly or something. Any readme file available for
how
>> to build the IMAP layer, should I use ant or maven? Sorry for the
>> trivial questions.

there aren't trivial at all - please feel free to ask

if you are still struggling then please post the error

> ... yes, I would recommend to build from source locally.

+1

use ant

> Pls come back to the list when you encounter any problems.

+1

- 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: Are there nightly builds for http://svn.apache.org/repos/asf/james/protocols/imap/trunk?

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Mar 12, 2009 at 1:19 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Martin.Bergljung wrote:
>>
>> Hi,
>>
>>
>> I am upgrading a product that uses an earlier version of Apache James
>> IMAP to use the new implementation under
>> http://svn.apache.org/repos/asf/james/protocols/imap/trunk
>>
>> However, when using the libs from the
>> james-server-spring-deployment-3.0-SNAPSHOT builds I noticed that the
>> apache-james-imap-****-0.1-SNAPSHOT.jar libs did not correspond to the
>> source code under
>> http://svn.apache.org/repos/asf/james/protocols/imap/trunk
>> (I assumed these libs were built from
>> http://svn.apache.org/repos/asf/james/protocols/imap/trunk nightly)
>>
>>
>> For example, the Mailbox class is in the
>> org.apache.james.mailboxmanager.mailbox package when using the
>> apache-james-imap-mailbox-0.1-SNAPSHOT.jar  lib but the source code
>> under http://svn.apache.org/repos/asf/james/protocols/imap/trunk  has it
>> in the org.apache.james.imap.mailbox package.
>
> I found that the nightly build sometimes (often?) leaves moved artifacts
> (especially libs) behind. This might be a specialty for the build server, I
> never was able to reproduce locally, so...

IMAP is very much under development so the SNAPSHOT included in James
trunk is almost always out of date

>> Is there any nightly builds for the IMAP protocol layer or should I
>> build from the source code. I tried to build from the source but got
>> some errors, probably because I did not configure the use of the
>> property files correctly or something. Any readme file available for how
>> to build the IMAP layer, should I use ant or maven? Sorry for the
>> trivial questions.

there aren't trivial at all - please feel free to ask

if you are still struggling then please post the error

> ... yes, I would recommend to build from source locally.

+1

use ant

> Pls come back to the list when you encounter any problems.

+1

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: Are there nightly builds for http://svn.apache.org/repos/asf/james/protocols/imap/trunk?

Posted by Bernd Fondermann <bf...@brainlounge.de>.
Martin.Bergljung wrote:
> Hi,
> 
>  
> 
> I am upgrading a product that uses an earlier version of Apache James
> IMAP to use the new implementation under
> http://svn.apache.org/repos/asf/james/protocols/imap/trunk 
> 
>  
> 
> However, when using the libs from the
> james-server-spring-deployment-3.0-SNAPSHOT builds I noticed that the 
> 
> apache-james-imap-****-0.1-SNAPSHOT.jar libs did not correspond to the
> source code under
> http://svn.apache.org/repos/asf/james/protocols/imap/trunk 
> 
> (I assumed these libs were built from
> http://svn.apache.org/repos/asf/james/protocols/imap/trunk nightly)
> 
>  
> 
> For example, the Mailbox class is in the
> org.apache.james.mailboxmanager.mailbox package when using the
> apache-james-imap-mailbox-0.1-SNAPSHOT.jar  lib but the source code
> under http://svn.apache.org/repos/asf/james/protocols/imap/trunk  has it
> in the org.apache.james.imap.mailbox package.

I found that the nightly build sometimes (often?) leaves moved artifacts 
(especially libs) behind. This might be a specialty for the build 
server, I never was able to reproduce locally, so...

> Is there any nightly builds for the IMAP protocol layer or should I
> build from the source code. I tried to build from the source but got
> some errors, probably because I did not configure the use of the
> property files correctly or something. Any readme file available for how
> to build the IMAP layer, should I use ant or maven? Sorry for the
> trivial questions.

... yes, I would recommend to build from source locally.

Pls come back to the list when you encounter any problems.

   Bernd


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org