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 Darrell DeBoer <li...@bigdaz.com> on 2002/01/03 08:40:07 UTC
Working on IMAPServer (and other things)
G'day
I've been having a bit of a play with the IMAP server proposal, writing some
tests and seeing what does/doesn't work. In doing so, I've done some work
which might be worth pushing into the main tree.
1) Upgraded to use the latest Phoenix and Cornerstone code (built from CVS,
since nightly builds aren't available). This includes updating to the
versions of avalon-framework, avalon-excalibur and avalon-scratchpad that
are included as jars in Phoenix CVS. The newer version of Pheonix seems
heaps more robust than the version we're currently running on, giving better
messages when you've done something wrong.
2) Converted a few of the Blocks to use the new LogEnabled logging
interface.
This was required to use the new Cornerstone ConnectionManager code.
3) Changed the build so that the source files aren't all copied to the
build/src directory before compiling. This step is unnecessary (except when
building with a proposal), and it can make it hard for IDEs to link
compilation problems to the offending source files.
Any comments? If all are keen I can commit these changes. Without them, the
IMAP proposal work I'm doing won't build in CVS.
ciao
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
discussion forum !!
Posted by baiju <ba...@jenterprise.de>.
hey all .
Is it possible to implement a web based discussion group using JAMES .
I did manage to configure in outlook ..but i do like to implement as web
based .(nntp) .
Could some body help me out how to proceed ..
cheers
baiju
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Serge Knystautas <se...@lokitech.com>.
+1 from me. I'm not sure if your logging changes fix this, but it'd be nice
if James would append logs again... right now your log files are wiped each
time you start.
The only tests I know of really are the hammering test and the basic pop3
test. We could really stand to use more testing as we add more features...
maybe a bunch of junit tests... I'm not sure what other projects are doing
these days for automated testing.
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Darrell DeBoer" <li...@bigdaz.com>
To: <ja...@jakarta.apache.org>
Sent: Thursday, January 03, 2002 2:40 AM
Subject: Working on IMAPServer (and other things)
> G'day
>
> I've been having a bit of a play with the IMAP server proposal, writing
some
> tests and seeing what does/doesn't work. In doing so, I've done some work
> which might be worth pushing into the main tree.
>
> 1) Upgraded to use the latest Phoenix and Cornerstone code (built from
CVS,
> since nightly builds aren't available). This includes updating to the
> versions of avalon-framework, avalon-excalibur and avalon-scratchpad that
> are included as jars in Phoenix CVS. The newer version of Pheonix seems
> heaps more robust than the version we're currently running on, giving
better
> messages when you've done something wrong.
>
> 2) Converted a few of the Blocks to use the new LogEnabled logging
> interface.
> This was required to use the new Cornerstone ConnectionManager code.
>
> 3) Changed the build so that the source files aren't all copied to the
> build/src directory before compiling. This step is unnecessary (except
when
> building with a proposal), and it can make it hard for IDEs to link
> compilation problems to the offending source files.
>
> Any comments? If all are keen I can commit these changes. Without them,
the
> IMAP proposal work I'm doing won't build in CVS.
>
> ciao
> Daz
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Darrell DeBoer <li...@bigdaz.com>.
> >
> > I had a look at WebMacro, and I thought it looked kind of similar to
> > Velocity. So similar, in fact, that there's a page on the Velocity site
> > describing the (slight) differences.
> >
> > So in the interest of promoting other Jakarta projects, I think I'd
probably
> > lean toward using Velocity. Thankfully, however, you've managed to
remove
> > any thoughts I had of trying to use Rhino (or similar) directly -
whatever
> > was I thinking? :)
>
> I would be strongly -1 towards using WebMacro in James.
>
> The differences between WebMacro and Velocity are not 'slight'. Velocity
is
> a far more mature product with solid version releases for well over a year
> now and a huge amount of user and developer testing.
>
> thanks,
>
> -jon
Thanks for the kind advice, Jon.
(I had no idea that there were Velocity advocates monitoring this list ;)
As I mentioned, I fully intend to use Apache technologies where possible.
ciao
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Darrell DeBoer <li...@bigdaz.com>.
G'day
> I agree that velocity has (a) good traction, (b) good developers and (c)
is
> Apache.
> So a hattrick and possibly first choice for James.
Yep, *if* I reckon that it's necessary to have more flexibility in the
Protocol tests, I'll use Velocity. (I'm kind of keen to learn it, anyhow).
> - I hope this does not turn into a long email chain.
Me neither - discussion can stop here. After all, this is only "impacting"
some *not-yet-implemented* *not-sure-if-it's-really-needed* *potential*
testing functionality!
ciao
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Harmeet Bedi <hb...@yahoo.com>.
I agree that velocity has (a) good traction, (b) good developers and (c) is
Apache.
So a hattrick and possibly first choice for James.
I had a good(better) experience with WebMacro. Found it reasonably mature,
solid and easy to get familiar with. I hope that there is a good feel about
Velocity and not a negative feel about WebMacro.
Harmeet
PS:
- I hope this does not turn into a long email chain. I think any template
technology that helps test is great. Whatever the Darrell likes. He is the
point man. :-)
- I am a user not a developer of either project. If you know specific
reasons why one is better than other, for e.g performace, ease of use etc. I
would appreciate if you could send me(harmeet@kodemuse.com) directly a
pointer or email - Thanks
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 1/7/02 7:00 PM, "Darrell DeBoer" <li...@bigdaz.com> wrote:
> Thanks for the tips.
>
> I had a look at WebMacro, and I thought it looked kind of similar to
> Velocity. So similar, in fact, that there's a page on the Velocity site
> describing the (slight) differences.
>
> So in the interest of promoting other Jakarta projects, I think I'd probably
> lean toward using Velocity. Thankfully, however, you've managed to remove
> any thoughts I had of trying to use Rhino (or similar) directly - whatever
> was I thinking? :)
I would be strongly -1 towards using WebMacro in James.
The differences between WebMacro and Velocity are not 'slight'. Velocity is
a far more mature product with solid version releases for well over a year
now and a huge amount of user and developer testing.
thanks,
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Darrell DeBoer <li...@bigdaz.com>.
Thanks for the tips.
I had a look at WebMacro, and I thought it looked kind of similar to
Velocity. So similar, in fact, that there's a page on the Velocity site
describing the (slight) differences.
So in the interest of promoting other Jakarta projects, I think I'd probably
lean toward using Velocity. Thankfully, however, you've managed to remove
any thoughts I had of trying to use Rhino (or similar) directly - whatever
was I thinking? :)
ciao
Daz
----- Original Message -----
From: "Harmeet" <ha...@kodemuse.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Tuesday, January 08, 2002 6:02 AM
Subject: Re: Working on IMAPServer (and other things)
> ----- Original Message -----
> From: "Darrell DeBoer" <li...@bigdaz.com>
> > Absolutely. I've already done a simple smtp test. Here's a sample:
> > (I'm hoping to use scripting (Rhino) or something instead of macros, but
> > haven't got there yet.)
>
> Looks cool.
> I would suggest webmacro for macros&scripting. If you like a full blown
> langauage, jython may be a good choice.
>
> Hope this help in some way,
> Harmeet
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Harmeet <ha...@kodemuse.com>.
----- Original Message -----
From: "Darrell DeBoer" <li...@bigdaz.com>
> Absolutely. I've already done a simple smtp test. Here's a sample:
> (I'm hoping to use scripting (Rhino) or something instead of macros, but
> haven't got there yet.)
Looks cool.
I would suggest webmacro for macros&scripting. If you like a full blown
langauage, jython may be a good choice.
Hope this help in some way,
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Working on IMAPServer (and other things)
Posted by Danny Angus <da...@thought.co.uk>.
> > I like the installer idea, can we detect the end of the initial
> un-packing
> > of the app?
>
> Hmmm, good point - you'd need to do the override after initial
> startup. Not
> sure about that. An installer would be very cool though. (This is surely
> something that would be beneficial to Phoenix apps in general.)
Actually I reckon an installer block in config.xml could do the trick,
<installer run=true> <installer/>
which setup would naturally re-write or remove.
It could also be used to store what stage the installer got to if a re-start
is needed during the install.(which I don't think is necessary)
and edited by hand to contain the values needed for a silent install.
This raises the question.. what do other jakarta projects do? if they all
require manual editing of config files there's perhaps a demand for a
generic apache installer.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Darrell DeBoer <li...@bigdaz.com>.
> > As part of my IMAP work, I've developed a simple "protocol testing
> > framework" (as JUnit tests), which allows tests to be defined as
> > text files
> > of the format:
> > C: <client-request>
> > S: <expected-server-response>
> > with a few macros such as ${ignore} and ${rfcDate} to handle variable
> > protocol elements.
>
> Sounds good, could I hack them for smtp & pop?
Absolutely. I've already done a simple smtp test. Here's a sample:
(I'm hoping to use scripting (Rhino) or something instead of macros, but
haven't got there yet.)
----------------------------------------------------------------------------
--
// Comment line - ignored.
// The ${ignore} macro accepts any single word element.
S: 220 ${ignore} SMTP Server (JAMES SMTP Server 2.0a2) ready ${rfcDate}
C: HELO localhost
S: 250 ${ignore} Hello localhost (127.0.0.1 [127.0.0.1])
// The ${from-address} and ${to-address} macros are NYI, but you get the
idea.
C: MAIL FROM: <${from-address}>
S: 250 Sender <${from-address}> OK
C: RCPT TO: <${to-address}>
S: 250 Recipient <${to-address}> OK
C: DATA
S: 354 Ok Send data ending with <CRLF>.<CRLF>
C: test
C: .
S: 250 Message received
C: QUIT
S: 221 ${ignore} Service closing transmission channel
----------------------------------------------------------------------------
------
As I said, I'll get this committed soon, so you can start playing with it.
>
> I like the installer idea, can we detect the end of the initial un-packing
> of the app?
Hmmm, good point - you'd need to do the override after initial startup. Not
sure about that. An installer would be very cool though. (This is surely
something that would be beneficial to Phoenix apps in general.)
ciao
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Working on IMAPServer (and other things)
Posted by Danny Angus <da...@thought.co.uk>.
> -----Original Message-----
> From: Darrell DeBoer [mailto:lists@bigdaz.com]
> Sent: Sunday, January 06, 2002 9:18 PM
> To: James Developers List
>
> I'm allergic to manual testing :)
> As part of my IMAP work, I've developed a simple "protocol testing
> framework" (as JUnit tests), which allows tests to be defined as
> text files
> of the format:
> C: <client-request>
> S: <expected-server-response>
> with a few macros such as ${ignore} and ${rfcDate} to handle variable
> protocol elements.
Sounds good, could I hack them for smtp & pop?
>
> >
> > I guess that tests which run on a clean build, with default
> configuration,
> > would be the easiest start, otherwise we could end up bogged down in
> issues
> > of how to stop repository and mailet configuration errors obscuring bugs
> in
> > the servers & handlers?
>
> Agreed, although developers are likely to have hacked the config file for
> their own DNS settings anyway. What would be great is a way to use a
> developer-specific properties file to automatically override certain
> settings in the config file (or even better, an installer).
I like the installer idea, can we detect the end of the initial un-packing
of the app?
>
> > 2/ deliver to that account using SMTP
> > 3/ collect the mail via POP
>
> This would be great for a start. We probably want to test SMTP
> and POP on 2
> levels.
> 1) Test the protocol for consistency, completeness and RFC
> compliance. This
> could include issues such as handling different date formats,
> case-sensitivity etc.
I have a short list of these things but no real experience of building
tests, time to learn methinks..
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Darrell DeBoer <li...@bigdaz.com>.
G'day
> >Does anyone have a set of tests which could form the starting point for a
> >full set of functional tests? I imagine that a bunch have been written in
> >the process of developing/testing the SMTP and POP servers.
>
> POP and SMTP functionality are easily tested using telnet, I suspect this
> has made me (at least) complacent.. good tests of basic function would
> indeed be worthwhile.
I'm allergic to manual testing :)
As part of my IMAP work, I've developed a simple "protocol testing
framework" (as JUnit tests), which allows tests to be defined as text files
of the format:
C: <client-request>
S: <expected-server-response>
with a few macros such as ${ignore} and ${rfcDate} to handle variable
protocol elements.
>
> I guess that tests which run on a clean build, with default configuration,
> would be the easiest start, otherwise we could end up bogged down in
issues
> of how to stop repository and mailet configuration errors obscuring bugs
in
> the servers & handlers?
Agreed, although developers are likely to have hacked the config file for
their own DNS settings anyway. What would be great is a way to use a
developer-specific properties file to automatically override certain
settings in the config file (or even better, an installer).
>
> I suggest we'd need three simple tests to start with
> 1/ create a test account
I've also got an "addUser" test, which uses the above framework against the
RemoteManager to add a named user.
(I expect to get this stuff committed within the next week or so).
> 2/ deliver to that account using SMTP
> 3/ collect the mail via POP
This would be great for a start. We probably want to test SMTP and POP on 2
levels.
1) Test the protocol for consistency, completeness and RFC compliance. This
could include issues such as handling different date formats,
case-sensitivity etc.
2) Full functional tests. Protocol-based testing probably isn't ideal for a
full set of functional tests; we might want to look at building tests on top
of JavaMail for this. (Or maybe there are some standard MailServer
functionality tests which would be just what we need?)
>
> the next logical one;
> 4/ deliver to a remote address
> is more problematic as it requires dns configuration, a good address to
> deliver to, and could still be caught out by the anti-spam mailets.
Agreed - but we'll probably all have a Test Account for this. Maybe the
actual address could be specified in a test config file (together with
settings like port numbers, timeouts etc.)
Good stuff to be thinking about, anyhoo.
ciao
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Working on IMAPServer (and other things)
Posted by Danny Angus <da...@thought.co.uk>.
>Does anyone have a set of tests which could form the starting point for a
>full set of functional tests? I imagine that a bunch have been written in
>the process of developing/testing the SMTP and POP servers.
POP and SMTP functionality are easily tested using telnet, I suspect this
has made me (at least) complacent.. good tests of basic function would
indeed be worthwhile.
I guess that tests which run on a clean build, with default configuration,
would be the easiest start, otherwise we could end up bogged down in issues
of how to stop repository and mailet configuration errors obscuring bugs in
the servers & handlers?
I suggest we'd need three simple tests to start with
1/ create a test account
2/ deliver to that account using SMTP
3/ collect the mail via POP
the next logical one;
4/ deliver to a remote address
is more problematic as it requires dns configuration, a good address to
deliver to, and could still be caught out by the anti-spam mailets.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Working on IMAPServer (and other things)
Posted by Darrell DeBoer <li...@bigdaz.com>.
G'day Danny
> > 1) Upgraded to use the latest Phoenix and Cornerstone code (built
> > from CVS,
> > since nightly builds aren't available). This includes updating to the
> > versions of avalon-framework, avalon-excalibur and avalon-scratchpad
that
> > are included as jars in Phoenix CVS. The newer version of Pheonix seems
> > heaps more robust than the version we're currently running on,
> > giving better
> > messages when you've done something wrong.
>
> if a build of the head of CVS works with these +1
>
I might even check to see that the server starts. ;)
It worries me a bit that I don't have any simple system tests to ensure that
I haven't broken any core functionality with these sorts of changes. It
would be great to have a set of tests which put the server through it's
paces.
Does anyone have a set of tests which could form the starting point for a
full set of functional tests? I imagine that a bunch have been written in
the process of developing/testing the SMTP and POP servers.
On another note; the new Pheonix code has support for the Java Service
Wrapper (http://wrapper.sourceforge.net), which we should be able to use to
run James as a NT Service, which would be cool.
ciao
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Working on IMAPServer (and other things)
Posted by Danny Angus <da...@thought.co.uk>.
>
> G'day
G'day yerself mate, an'a happy new year,
> 1) Upgraded to use the latest Phoenix and Cornerstone code (built
> from CVS,
> since nightly builds aren't available). This includes updating to the
> versions of avalon-framework, avalon-excalibur and avalon-scratchpad that
> are included as jars in Phoenix CVS. The newer version of Pheonix seems
> heaps more robust than the version we're currently running on,
> giving better
> messages when you've done something wrong.
if a build of the head of CVS works with these +1
>
> 2) Converted a few of the Blocks to use the new LogEnabled logging
> interface.
> This was required to use the new Cornerstone ConnectionManager code.
>
not sure about this, i don't know enough +0
> 3) Changed the build so that the source files aren't all copied to the
> build/src directory before compiling. This step is unnecessary
> (except when
> building with a proposal), and it can make it hard for IDEs to link
> compilation problems to the offending source files.
Big +1
I've done this for my local copy too, for precisely this reason.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>