RE: [PATCH] Server-wide default hello name

[Danny Angus]

No, my mistake, I *had* meant the root of config, but then realised its only
the mailet context that needs this added, all the connection handlers
already have it.

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: 20 August 2002 08:07
> To: James Developers List
> Subject: RE: [PATCH] Server-wide default hello name
>
>
> Oh!  I got it now.  Sorry.  I hadn't realize what you'd meant by "the root
> of config".  You'd meant the spool manager.  No worries.  I can do that
> quickly enough when I wake up in the AM.
>
>   --- Noel
>
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 20, 2002 2:39
> To: James Developers List
> Subject: RE: [PATCH] Server-wide default hello name
>
>
> put it in the spool manager block exactly as for the connection
> handlers and
> expose it to the mailets as a context attribute
>
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > Sent: 20 August 2002 00:37
> > To: James Developers List
> > Subject: [PATCH] Server-wide default hello name
> >
> >
> > Danny,
> >
> > OK, helloName it is, then.  Are you being specific that you want it as a
> > separate element (as opposed to an attribute), or were you just
> indicating
> > the name?  In other words:
> >
> >  
> > 
> >  OPTION 1 
> > 
> > 
> > 
> >  
> >
> > Next up ... the interface.  getAttribute("helloName") or
> > getHelloName()?  If
> > the latter, let me point out that MailServer does not have attributes
> > (MailContext does, though).
> >
> > --- Noel
> >
> > -Original Message-
> > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, August 19, 2002 10:21
> > To: James Developers List
> > Subject: RE: [PATCH] james-config.xml/james.java
> >
> >
> > I believe that we should use  as for the connection
> > handlers, for
> > consistent naming, I know the use will be slightly different,
> in that its
> > not used for hello, but I don't think its so far out to as be
> wrong as its
> > still the name we identify ourselves by.
> >
> > d.
> >
> > > -Original Message-
> > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > > Sent: 19 August 2002 00:22
> > > To: James Developers List
> > > Subject: RE: [PATCH] james-config.xml/james.java
> > >
> > >
> > > Danny,
> > >
> > > I'll be happy to make that change.  What attribute name for
> > > MailetContext.getAttribute() would you like for me to use?
> > > Constants.HELLO_NAME?  By "root of the config", do you mean an
> > > child element of the  section?  Do you want this to be
> > > an element or an attribute, e.g.,
> > >
> > > 
> > >
> > > OPTION 1 
> > >
> > >
> > >
> > > 
> > >
> > > I'd like to use this in BaseConnectionHandler.configure() to
> > > autodetect the
> > > helloName:
> > >
> > > if (autodetect) {
> > > helloName = defaultHelloName != null ? defaultHelloName :
> > > hostName;
> > > }
> > > else
> > > helloName = helloConf.getValue("localhost");
> > >
> > > To do this, I propose restoring this line of code in James:
> > >
> > > //compMgr.put("org.apache.mailet.MailetContext", this);
> > >
> > > so that I can request the attribute from James in
> > > BaseConnectionHandler.configure().
> > >
> > >   --- Noel
> > >
> > > -Original Message-
> > > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> > >
> > > I like the servername attribute for remote delivery, I believe that we
> > > should actually add it at the root of config, and make it
> > available to all
> > > mailets as a parameter in the context, to be added to the
> mailet API in
> > > time. see my other mail regarding ipaddresses.
> > >
> > > d.
> > >
> > > > -Original Message-
> > > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > > [clip]
> > > > As submitted in a separate patch, RemoteDelivery.java has
> > already had a
> > > >  attribute added to it.  With out, James uses the
> > > > first name in the server name collection, which would often
> be either
> > > > localhost or, if autodetected were turned on, the internal
> name of the
> > > > computer.  This behavior was undocumented, and with the
> HashSet change
> > > > is undefined.  I've updated the james-config.xml comments
> for this new
> > > > element.  The  element is necessary with the
> > HashSet change,
> > > > but is otherwise still useful (and optional).
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Configuration: "[postmaster|root]@localhost"

[Noel J. Bergman]

> That AOL, and many others apache included, won't accept mail from
> unreturnable addresses is neither here nor there.

This is the point of disagreement.  The e-mail address is unreturnable.  Why
should an enterprise mail server have an unreturnable default postmaster
address?

It isn't the local part (root vs postmaster) that bothers me, since
PostmasterAlias takes care of the local part mapping; it is the use of
localhost.  Given how PostmasterAlias works, any other valid domain that the
server listens on would be a better fallback than localhost, IMO.

Regardless, I do feel strongly that we need to document why the default
configured value of postmaster@localhost is a bad idea.

--- Noel

P.S.  I have no idea why Peter likes the idea.  I hadn't discussed it with
him.

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 20, 2002 2:44
To: James Developers List
Subject: RE: Configuration: "[postmaster|root]@localhost"


> Is it reasonable to change the internal default from "root@localhost" to
> "postmaster@helloName"?

No, root@localhost is a reasonable default email address, it is a real email
address, it refers to a real account on a real machine.
That AOL, and many others apache included, won't accept mail from
unreturnable addresses is neither here nor there.

>
>   --- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Server-wide default hello name

[Noel J. Bergman]

Oh!  I got it now.  Sorry.  I hadn't realize what you'd meant by "the root
of config".  You'd meant the spool manager.  No worries.  I can do that
quickly enough when I wake up in the AM.

--- Noel

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 20, 2002 2:39
To: James Developers List
Subject: RE: [PATCH] Server-wide default hello name


put it in the spool manager block exactly as for the connection handlers and
expose it to the mailets as a context attribute

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: 20 August 2002 00:37
> To: James Developers List
> Subject: [PATCH] Server-wide default hello name
>
>
> Danny,
>
> OK, helloName it is, then.  Are you being specific that you want it as a
> separate element (as opposed to an attribute), or were you just indicating
> the name?  In other words:
>
>  
> 
>  OPTION 1 
> 
> 
> 
>  
>
> Next up ... the interface.  getAttribute("helloName") or
> getHelloName()?  If
> the latter, let me point out that MailServer does not have attributes
> (MailContext does, though).
>
>   --- Noel
>
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 10:21
> To: James Developers List
> Subject: RE: [PATCH] james-config.xml/james.java
>
>
> I believe that we should use  as for the connection
> handlers, for
> consistent naming, I know the use will be slightly different, in that its
> not used for hello, but I don't think its so far out to as be wrong as its
> still the name we identify ourselves by.
>
> d.
>
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > Sent: 19 August 2002 00:22
> > To: James Developers List
> > Subject: RE: [PATCH] james-config.xml/james.java
> >
> >
> > Danny,
> >
> > I'll be happy to make that change.  What attribute name for
> > MailetContext.getAttribute() would you like for me to use?
> > Constants.HELLO_NAME?  By "root of the config", do you mean an
> > child element of the  section?  Do you want this to be
> > an element or an attribute, e.g.,
> >
> > 
> >
> > OPTION 1 
> >
> >
> >
> > 
> >
> > I'd like to use this in BaseConnectionHandler.configure() to
> > autodetect the
> > helloName:
> >
> > if (autodetect) {
> > helloName = defaultHelloName != null ? defaultHelloName :
> > hostName;
> > }
> > else
> > helloName = helloConf.getValue("localhost");
> >
> > To do this, I propose restoring this line of code in James:
> >
> > //compMgr.put("org.apache.mailet.MailetContext", this);
> >
> > so that I can request the attribute from James in
> > BaseConnectionHandler.configure().
> >
> > --- Noel
> >
> > -Original Message-
> > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> >
> > I like the servername attribute for remote delivery, I believe that we
> > should actually add it at the root of config, and make it
> available to all
> > mailets as a parameter in the context, to be added to the mailet API in
> > time. see my other mail regarding ipaddresses.
> >
> > d.
> >
> > > -Original Message-
> > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > [clip]
> > > As submitted in a separate patch, RemoteDelivery.java has
> already had a
> > >  attribute added to it.  With out, James uses the
> > > first name in the server name collection, which would often be either
> > > localhost or, if autodetected were turned on, the internal name of the
> > > computer.  This behavior was undocumented, and with the HashSet change
> > > is undefined.  I've updated the james-config.xml comments for this new
> > > element.  The  element is necessary with the
> HashSet change,
> > > but is otherwise still useful (and optional).


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Configuration: "[postmaster|root]@localhost"

[Danny Angus]

> Noel et al,
> 
> I definitely like this change.

Why, it makes no sense to me?
d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Configuration: "[postmaster|root]@localhost"

[Danny Angus]

> Is it reasonable to change the internal default from "root@localhost" to
> "postmaster@helloName"?

No, root@localhost is a reasonable default email address, it is a real email
address, it refers to a real account on a real machine.
That AOL, and many others apache included, won't accept mail from
unreturnable addresses is neither here nor there.

>
>   --- Noel
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Server-wide default hello name

[Danny Angus]

put it in the spool manager block exactly as for the connection handlers and
expose it to the mailets as a context attribute

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: 20 August 2002 00:37
> To: James Developers List
> Subject: [PATCH] Server-wide default hello name
>
>
> Danny,
>
> OK, helloName it is, then.  Are you being specific that you want it as a
> separate element (as opposed to an attribute), or were you just indicating
> the name?  In other words:
>
>  
> 
>  OPTION 1 
> 
> 
> 
>  
>
> Next up ... the interface.  getAttribute("helloName") or
> getHelloName()?  If
> the latter, let me point out that MailServer does not have attributes
> (MailContext does, though).
>
>   --- Noel
>
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 10:21
> To: James Developers List
> Subject: RE: [PATCH] james-config.xml/james.java
>
>
> I believe that we should use  as for the connection
> handlers, for
> consistent naming, I know the use will be slightly different, in that its
> not used for hello, but I don't think its so far out to as be wrong as its
> still the name we identify ourselves by.
>
> d.
>
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > Sent: 19 August 2002 00:22
> > To: James Developers List
> > Subject: RE: [PATCH] james-config.xml/james.java
> >
> >
> > Danny,
> >
> > I'll be happy to make that change.  What attribute name for
> > MailetContext.getAttribute() would you like for me to use?
> > Constants.HELLO_NAME?  By "root of the config", do you mean an
> > child element of the  section?  Do you want this to be
> > an element or an attribute, e.g.,
> >
> > 
> >
> > OPTION 1 
> >
> >
> >
> > 
> >
> > I'd like to use this in BaseConnectionHandler.configure() to
> > autodetect the
> > helloName:
> >
> > if (autodetect) {
> > helloName = defaultHelloName != null ? defaultHelloName :
> > hostName;
> > }
> > else
> > helloName = helloConf.getValue("localhost");
> >
> > To do this, I propose restoring this line of code in James:
> >
> > //compMgr.put("org.apache.mailet.MailetContext", this);
> >
> > so that I can request the attribute from James in
> > BaseConnectionHandler.configure().
> >
> > --- Noel
> >
> > -Original Message-
> > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> >
> > I like the servername attribute for remote delivery, I believe that we
> > should actually add it at the root of config, and make it
> available to all
> > mailets as a parameter in the context, to be added to the mailet API in
> > time. see my other mail regarding ipaddresses.
> >
> > d.
> >
> > > -Original Message-
> > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > [clip]
> > > As submitted in a separate patch, RemoteDelivery.java has
> already had a
> > >  attribute added to it.  With out, James uses the
> > > first name in the server name collection, which would often be either
> > > localhost or, if autodetected were turned on, the internal name of the
> > > computer.  This behavior was undocumented, and with the HashSet change
> > > is undefined.  I've updated the james-config.xml comments for this new
> > > element.  The  element is necessary with the
> HashSet change,
> > > but is otherwise still useful (and optional).
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Configuration: "[postmaster|root]@localhost"

[Noel J. Bergman]

Peter,

Actually, I'm not sure that it's quite right, but I'm fairly sure that it is
an improvement.

For example, my mail server is mail.devtech.com.  But the postmaster is
[EMAIL PROTECTED] (actually, postmaster@any-local-domain).  I don't
really want mail.devtech.com listed in the configuration as a domain for
which I receive e-mail, but if I don't then with the proposed default,
[EMAIL PROTECTED], won't be recognized as local.  You see my
point?

But that's a more advanced configuration.  I think that the proposed change
is still better than @localhost.

--- Noel

-Original Message-
From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 21:31
To: 'James Developers List'
Subject: RE: Configuration: "[postmaster|root]@localhost"

Noel et al,

I definitely like this change.

--Peter

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 6:17 PM
> To: James-Dev Mailing List
> Subject: Configuration: "[postmaster|root]@localhost"
>
> The default configuration (yeah, yeah, it says to check it but it
doesn't
> give guidelines) is accepted by name e-mail servers, but not by AOL,
as
> shown:
>
> telnet mailin-03.mx.aol.com 25
> Trying 64.12.137.121...
> Connected to mailin-03.mx.aol.com.
> Escape character is '^]'.
> 220-rly-xh01.mx.aol.com ESMTP mail_relay_in-xh1.4; Mon, 19 Aug 2002
> 21:06:43
> 2000
> 220-America Online (AOL) and its affiliated companies do not
> 220- authorize the use of its proprietary computers and computer
> 220- networks to accept, transmit, or distribute unsolicited bulk
> 220  e-mail sent from the internet.
> HELO mail.devtech.com
> 250 rly-xh01.mx.aol.com OK
> MAIL FROM: 
> 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
> MAIL FROM: 
> 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
> MAIL FROM: postmaster
> 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
> MAIL FROM: 
> 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
> MAIL FROM: <[EMAIL PROTECTED]>
> 250 OK
>
> Is it reasonable to change the internal default from "root@localhost"
to
> "postmaster@helloName"?
>
>   --- Noel
>
>
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> For additional commands, e-mail:  [EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Lots of twisty, er, servers all the same ...

[Noel J. Bergman]

As you can see from the nslookup of ATT.NET that follows, they have lots of
MX records, all the same IP address.  On nights like tonight when AT&T is
jammed, this can block a delivery thread for over an hour.

Is there a reason why getMailServers [actually, DNSServer.findMXRecords()]
should not return a collection containing only one entry per IP address?

--- Noel

> set q=mx
> att.net
Server:  MACU.MA.MT.NP.ELS-GMS.att.net
Address:  199.191.145.136

att.net MX preference = 5, mail exchanger = gateway1.att.net
att.net MX preference = 5, mail exchanger = gateway2.att.net
att.net MX preference = 5, mail exchanger = gateway3.att.net
att.net MX preference = 5, mail exchanger = gateway4.att.net
att.net MX preference = 5, mail exchanger = gateway5.att.net
att.net MX preference = 5, mail exchanger = gateway6.att.net
att.net MX preference = 5, mail exchanger = gateway8.att.net
att.net nameserver = ohcu.oh.mt.np.els-gms.att.net
att.net nameserver = macu.ma.mt.np.els-gms.att.net
att.net nameserver = orcu.or.br.np.els-gms.att.net
att.net nameserver = wycu.wy.br.np.els-gms.att.net
gateway1.att.netinternet address = 204.127.134.23
gateway2.att.netinternet address = 204.127.134.23
gateway3.att.netinternet address = 204.127.134.23
gateway4.att.netinternet address = 204.127.134.23
gateway5.att.netinternet address = 204.127.134.23
gateway6.att.netinternet address = 204.127.134.23
gateway8.att.netinternet address = 204.127.134.23
ohcu.oh.mt.np.els-gms.att.net   internet address = 199.191.144.75
macu.ma.mt.np.els-gms.att.net   internet address = 199.191.145.136
orcu.or.br.np.els-gms.att.net   internet address = 199.191.129.139
wycu.wy.br.np.els-gms.att.net   internet address = 199.191.128.43
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Configuration: "[postmaster|root]@localhost"

[Peter M. Goldstein]

Noel et al,

I definitely like this change.

--Peter

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 6:17 PM
> To: James-Dev Mailing List
> Subject: Configuration: "[postmaster|root]@localhost"
> 
> The default configuration (yeah, yeah, it says to check it but it
doesn't
> give guidelines) is accepted by name e-mail servers, but not by AOL,
as
> shown:
> 
> telnet mailin-03.mx.aol.com 25
> Trying 64.12.137.121...
> Connected to mailin-03.mx.aol.com.
> Escape character is '^]'.
> 220-rly-xh01.mx.aol.com ESMTP mail_relay_in-xh1.4; Mon, 19 Aug 2002
> 21:06:43
> 2000
> 220-America Online (AOL) and its affiliated companies do not
> 220- authorize the use of its proprietary computers and computer
> 220- networks to accept, transmit, or distribute unsolicited bulk
> 220  e-mail sent from the internet.
> HELO mail.devtech.com
> 250 rly-xh01.mx.aol.com OK
> MAIL FROM: 
> 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
> MAIL FROM: 
> 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
> MAIL FROM: postmaster
> 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
> MAIL FROM: 
> 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
> MAIL FROM: <[EMAIL PROTECTED]>
> 250 OK
> 
> Is it reasonable to change the internal default from "root@localhost"
to
> "postmaster@helloName"?
> 
>   --- Noel
> 
> 
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> For additional commands, e-mail:  [EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Configuration: "[postmaster|root]@localhost"

[Noel J. Bergman]

The default configuration (yeah, yeah, it says to check it but it doesn't
give guidelines) is accepted by name e-mail servers, but not by AOL, as
shown:

telnet mailin-03.mx.aol.com 25
Trying 64.12.137.121...
Connected to mailin-03.mx.aol.com.
Escape character is '^]'.
220-rly-xh01.mx.aol.com ESMTP mail_relay_in-xh1.4; Mon, 19 Aug 2002 21:06:43
2000
220-America Online (AOL) and its affiliated companies do not
220- authorize the use of its proprietary computers and computer
220- networks to accept, transmit, or distribute unsolicited bulk
220  e-mail sent from the internet.
HELO mail.devtech.com
250 rly-xh01.mx.aol.com OK
MAIL FROM: 
501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
MAIL FROM: 
501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
MAIL FROM: postmaster
501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
MAIL FROM: 
501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS
MAIL FROM: <[EMAIL PROTECTED]>
250 OK

Is it reasonable to change the internal default from "root@localhost" to
"postmaster@helloName"?

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta James Nightly Build

[Stephen McConnell]

Danny Angus wrote:

>the problem is that Avalon isn't building, in particular
>http://jakarta.apache.org/builds/gump/latest/jakarta-avalon-excalibur.html
>  
>

Generalization isn't a good thing!
James has depedencies on a set of the Excalibur projects - not all of 
Excalibur.  What is needed is that the James gumjp description is 
specific about the paricular Excalibur projects that James requires. 
 After all - Exalibur contains a lot of things that vary from new, 
exciting and alpha, through to dull boring and stable.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] Server-wide default hello name

[Noel J. Bergman]

Danny,

OK, helloName it is, then.  Are you being specific that you want it as a
separate element (as opposed to an attribute), or were you just indicating
the name?  In other words:

 

 OPTION 1 



 

Next up ... the interface.  getAttribute("helloName") or getHelloName()?  If
the latter, let me point out that MailServer does not have attributes
(MailContext does, though).

--- Noel

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 10:21
To: James Developers List
Subject: RE: [PATCH] james-config.xml/james.java


I believe that we should use  as for the connection handlers, for
consistent naming, I know the use will be slightly different, in that its
not used for hello, but I don't think its so far out to as be wrong as its
still the name we identify ourselves by.

d.

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: 19 August 2002 00:22
> To: James Developers List
> Subject: RE: [PATCH] james-config.xml/james.java
>
>
> Danny,
>
> I'll be happy to make that change.  What attribute name for
> MailetContext.getAttribute() would you like for me to use?
> Constants.HELLO_NAME?  By "root of the config", do you mean an
> child element of the  section?  Do you want this to be
> an element or an attribute, e.g.,
>
> 
>
> OPTION 1 
>
>
>
> 
>
> I'd like to use this in BaseConnectionHandler.configure() to
> autodetect the
> helloName:
>
> if (autodetect) {
> helloName = defaultHelloName != null ? defaultHelloName :
> hostName;
> }
> else
> helloName = helloConf.getValue("localhost");
>
> To do this, I propose restoring this line of code in James:
>
> //compMgr.put("org.apache.mailet.MailetContext", this);
>
> so that I can request the attribute from James in
> BaseConnectionHandler.configure().
>
>   --- Noel
>
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
>
> I like the servername attribute for remote delivery, I believe that we
> should actually add it at the root of config, and make it available to all
> mailets as a parameter in the context, to be added to the mailet API in
> time. see my other mail regarding ipaddresses.
>
> d.
>
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> [clip]
> > As submitted in a separate patch, RemoteDelivery.java has already had a
> >  attribute added to it.  With out, James uses the
> > first name in the server name collection, which would often be either
> > localhost or, if autodetected were turned on, the internal name of the
> > computer.  This behavior was undocumented, and with the HashSet change
> > is undefined.  I've updated the james-config.xml comments for this new
> > element.  The  element is necessary with the HashSet change,
> > but is otherwise still useful (and optional).


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Bizzarre new bug...

[Danny Angus]

because you're using UTF-8 .. it only bugs out on US-ASCII, its my fault for not 
paying attention, not a bug, forget it.

Content-Type: text/plain;
charset="UTF-8"

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: 19 August 2002 21:09
> To: James Developers List
> Subject: RE: Bizzarre new bug...
> 
> 
> > > try £ for ? (in UTF-8 this time) and then the bug is with 
> James on Linux,
> > > and Windows ASCII encoded mail.
> 
> > is it really a bug / james bug?
> 
> Actually, I cannot reproduce it with James on linux and Microsoft 
> Outlook 2000.  I mentioned this in another message that hasn't 
> clear the queue yet.  So far, the £ has remained intact.
> 
>   --- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] GenericListserv/AvalonListserv - prefix control

[Noel J. Bergman]

The attached patch to GenericListserv and AvalonListserv adds a new
configuration option.  GenericListserv now adds:

 /**
  * Should the subject prefix be automatically surrounded by [].
  */
 public boolean getAutoBracketPrefix() throws MessagingException {
 return true; // preserve old behavior unless subclass overrides.
 }

This is true by default to preserve compatibility with any existing
subclasses and configurations.

AvalonListserv.init() adds:

 try {
 autoBracket = new
Boolean(getInitParameter("autobracket")).booleanValue();
 } catch (Exception e) {
 }

and the class gets:

 public boolean getAutoBracketPrefix() {
 return autoBracket;
 }

Existing list classes and configurations work as-is with no changes
required.  If the new functionality is desired, an explicit
false element must be added.

All of this (and more) is in the revised class documentation.

--- Noel


Index: AvalonListserv.java
===
RCS file: 
/home/cvspublic/jakarta-james/src/java/org/apache/james/transport/mailets/AvalonListserv.java,v
retrieving revision 1.4
diff -u -r1.4 AvalonListserv.java
--- AvalonListserv.java 19 Aug 2002 18:57:07 -  1.4
+++ AvalonListserv.java 19 Aug 2002 21:10:41 -
@@ -23,11 +23,33 @@
  * MailingListServer capability.
  * 
  * Requires a configuration element in the .conf.xml file of the form:
- * name of user repository configured in UsersStore block 

- * 
- * 
- * 
- * 
+ *   
+ * LIST-NAME
+ * [true|false]
+ * [true|false]
+ * [true|false]
+ * [true|false]
+ * SUBJECT-PREFIX
+ *   
+ * repositoryName - the name of a user repository configured in the
+ * UsersStore block, e.g.,
+ *   
+ * file://conf/sqlResources.xml
+ *   
+ * or
+ *   
+ * 
+ *   
+ * membersonly - if true only members can post to the list
+ * attachmentsallowed - if false attachments are not allowed
+ * replytolist - if true, replies go back to the list address; if
+ * false they go to the sender.
+ * subjectprefix - a prefix that will be inserted at the front of
+ * the subject.  If autobracketing is disabled (see below), the
+ * xml:space="preserve" attribute can be used to precisely control the
+ * prefix.
+ * autobracket - if true the subject prefix will be rendered as
+ * "[PREFIX] ", if false, the prefix will be used literally.
  *
  * @author  Serge Knystautas 
  * @version This is $Revision: 1.4 $
@@ -39,6 +61,7 @@
 protected boolean attachmentsAllowed = true;
 protected boolean replyToList = true;
 protected String subjectPrefix = null;
+protected boolean autoBracket = true;
 private UsersRepository members;
 
 public void init() {
@@ -55,6 +78,10 @@
 } catch (Exception e) {
 }
 subjectPrefix = getInitParameter("subjectprefix");
+try {
+autoBracket = new Boolean(getInitParameter("autobracket")).booleanValue();
+} catch (Exception e) {
+}
 
 ComponentManager compMgr = 
(ComponentManager)getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER);
 try {
@@ -93,11 +120,16 @@
 return subjectPrefix;
 }
 
+public boolean getAutoBracketPrefix() {
+return autoBracket;
+}
+
 /**
  * Return a string describing this mailet.
  *
  * @return a string describing this mailet
  */
+
 public String getMailetInfo() {
 return "AvalonListserv Mailet";
 }
Index: GenericListserv.java
===
RCS file: 
/home/cvspublic/jakarta-james/src/java/org/apache/james/transport/mailets/GenericListserv.java,v
retrieving revision 1.8
diff -u -r1.8 GenericListserv.java
--- GenericListserv.java16 Aug 2002 17:05:49 -  1.8
+++ GenericListserv.java19 Aug 2002 21:10:41 -
@@ -57,11 +57,18 @@
 }
 
 /**
- * An optional subject prefix which will be surrounded by [].
+ * An optional subject prefix
  */
 public abstract String getSubjectPrefix() throws MessagingException;
 
 /**
+ * Should the subject prefix be automatically surrounded by [].
+ */
+public boolean getAutoBracketPrefix() throw

Re: James End User Documentation

[Andrew C. Oliver]

On this we can all agree...  wikis are very powerful tools for 
generating documentation.  I'm very impressed with the progress made on 
the Cocoon wiki.  Stephen Noles (sp?) will be very suprised when he gets 
back from vacation.

-Andy

Noel J. Bergman wrote:
> Nicola,
> 
> Assuming that folks vote for a wiki, can we set one up on apache, or did
> this require a server elsewhere?
> 
> I like wikis.  Been running vqWiki on several projects.
> 
>   --- Noel
> 
> -Original Message-
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 15:25
> To: James Developers List
> Subject: Re: James End User Documentation
> 
> 
> 
> Noel J. Bergman wrote:
> 
>>>solicit away.
>>
>>
>> 1. Can we agree on some [DOCUMENTATION] prefix that people can use, so
> 
> that
> 
>>documentation submissions can be located in the archives?
>>
>> 2. How's:
>>
>>If you have James related tips, documentation bits, or just questions
> 
> about
> 
>>things that you need help with, please submit them to the James project
> 
> with
> 
>>a [DOCUMENTATION] prefix on the subject.  The more contributions, the
> 
> better
> 
>>the user documentation will get.
>>
>>I don't supposed anyone on the list is a tech writer, eh?  :-)
>>
>>I'll post up an example of multiple mailing lists so that people can see
>>what needs to be done for EACH new mailing list.  The current
> 
> documentation
> 
>>isn't clear on that (in fact, mine works but perhaps I missed a point).
> 
> 
> On the Cocoon project, we have already done this.
> 
> We started asking to commit doc stuff with [DOCS], then we moved to
> asking to put them in Bugzilla.
> 
> Finally we set up a Wiki, and this last solution brought us more
> documentation inh a week than the other two in a month!
> 
> --
> Nicola Ken Barozzi   [EMAIL PROTECTED]
>  - verba volant, scripta manent -
> (discussions get forgotten, just code remains)





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: What do we need to release 2.1

[Andrew C. Oliver]

I'm willing to set up a wiki for james on my server if needed.  I'd do 
it on jakarta.apache.org but I don't believe we have a cgi-bin 
directory.  If there is consensus on this let me know and I'll be happy 
to do it.

Noel J. Bergman wrote:
> Does a template for such a release plan exist from previous releases?
> 
> Peter's issues were expressed in his original post:
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg03100.html,
> which kicked off this round of discussion.  Other folks have added their
> viewpoints, which can be found in the archives.  Now that we've updated the
> Milestone build, I'd amend some of my earlier points.
> 
> This is a case where a Wiki would be a useful tool as the details of the
> release plan are hashed out.
> 
>   --- Noel
> 
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 11:43
> To: James Developers List
> Subject: What do we need to release 2.1
> 
> 
> Ok,
> 
> 1/ we need a release plan, circulated to this list or put into cvs then put
> to a vote.
> 
> Should include all steps needed to make a release, including..
> 
> issue management, fix, close or defer all open bugs.
> build & test, make a release candidate available to canvas widest testing
> audience
> 
> Vote on progress to the next step after completion of issue management.
> 
> update all documentation
> update website
> build, upload, announce
> 
> d.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Bizzarre new bug...

[Noel J. Bergman]

Danny,

I cannot reproduce this defect.  I took your message, which came in via a non-James 
server, and sent it via my ISP's SMTP server to myself at an account on the James 
server.  Then I turned around and sent it back via James to myself at my ISP account.  
I am now sending this back to the list, and you will observe that the £ is intact.

I am running James CVS on RedHat 6.2, and using Outlook 2000 on Windows XP.

--- Noel

-Original Message-
From: Noel J. Bergman [my james account]
Sent: Monday, August 19, 2002 15:32
To: [my isp account]
Subject: RE: Bizzarre new bug...

-Original Message-
From: Noel J. Bergman [from my ISP account]
Sent: Monday, August 19, 2002 15:25
To: [my james account]
Subject: FW: Bizzarre new bug...

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 15:08
To: James Developers List
Subject: RE: Bizzarre new bug...

Bollocks, I *did* send it through James, Idiot that I am :-)
try £ for ? (in UTF-8 this time) and then the bug is with James on Linux, and Windows 
ASCII encoded mail.

d.

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 14:19
To: James Developers List
Subject: Bizzarre new bug...

? is being changed to ? in mail handled by James, in 
particular the message body is being re-cycled into a new message.

Odd.
d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Bizzarre new bug...

[Noel J. Bergman]

> > try £ for ? (in UTF-8 this time) and then the bug is with James on Linux,
> > and Windows ASCII encoded mail.

> is it really a bug / james bug?

Actually, I cannot reproduce it with James on linux and Microsoft Outlook 2000.  I 
mentioned this in another message that hasn't clear the queue yet.  So far, the £ has 
remained intact.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Bizzarre new bug...

[Danny Angus]

you're absolutely right, I didn't realise my mail client was doing that, US-ASCII 
would change £ for ?

> -Original Message-
> From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]]
> Sent: 19 August 2002 20:25
> To: James Developers List
> Subject: Re: Bizzarre new bug...
> 
> 
> is it really a bug / james bug? If your mail for example declares that the
> charset is US-ASCII , then it is very correct to replace  with ? (because
> there is no 
> in the US-ASCII charset). Both a suitable content-transfer-encoding and
> charset must be specified and followed by the client.
> 
> 
> - Original Message -
> From: "Danny Angus" <[EMAIL PROTECTED]>
> To: "James Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, August 19, 2002 9:08 PM
> Subject: RE: Bizzarre new bug...
> 
> 
> Bollocks, I *did* send it through James, Idiot that I am :-)
> try  for ? (in UTF-8 this time) and then the bug is with James on Linux,
> and Windows ASCII encoded mail.
> 
> d.
> 
> > -Original Message-
> > From: Steve Short [mailto:[EMAIL PROTECTED]]
> > Sent: 19 August 2002 19:53
> > To: James Developers List
> > Subject: RE: Bizzarre new bug...
> >
> >
> > Maybe he sent his message via James, so his ? got changed to a ?.
> >
> > Steve
> >
> > > -Original Message-
> > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, August 19, 2002 11:56 AM
> > > To: James Developers List
> > > Subject: RE: Bizzarre new bug...
> > >
> > >
> > > I'm lost.  What is the problem?  "? is being changed to ?"
> > >
> > > As for the message body being recycled, isn't that what
> > > happens (not looking at the code) when a new Mail object is
> > > created for a given subset of recipients?
> > >
> > > I'm sorry, but I really have no idea what this is about.
> > >
> > > --- Noel
> > >
> > > -Original Message-
> > > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, August 19, 2002 14:19
> > > To: James Developers List
> > > Subject: Bizzarre new bug...
> > >
> > >
> > > ? is being changed to ? in mail handled by James, in
> > > particular the message body is being re-cycled into a new message.
> > >
> > > Odd.
> > > d.
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >  [EMAIL PROTECTED]>
> > > For
> > > additional commands,
> > > e-mail: 
> > >
> > >
> >
> > --
> > To unsubscribe, e-mail:
> 
> For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: James End User Documentation

[Noel J. Bergman]

Nicola,

Assuming that folks vote for a wiki, can we set one up on apache, or did
this require a server elsewhere?

I like wikis.  Been running vqWiki on several projects.

--- Noel

-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 15:25
To: James Developers List
Subject: Re: James End User Documentation



Noel J. Bergman wrote:
>>solicit away.
>
>
>  1. Can we agree on some [DOCUMENTATION] prefix that people can use, so
that
> documentation submissions can be located in the archives?
>
>  2. How's:
>
> If you have James related tips, documentation bits, or just questions
about
> things that you need help with, please submit them to the James project
with
> a [DOCUMENTATION] prefix on the subject.  The more contributions, the
better
> the user documentation will get.
>
> I don't supposed anyone on the list is a tech writer, eh?  :-)
>
> I'll post up an example of multiple mailing lists so that people can see
> what needs to be done for EACH new mailing list.  The current
documentation
> isn't clear on that (in fact, mine works but perhaps I missed a point).

On the Cocoon project, we have already done this.

We started asking to commit doc stuff with [DOCS], then we moved to
asking to put them in Bugzilla.

Finally we set up a Wiki, and this last solution brought us more
documentation inh a week than the other two in a month!

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Bizzarre new bug...

[Hontvari Jozsef]

is it really a bug / james bug? If your mail for example declares that the
charset is US-ASCII , then it is very correct to replace £ with ? (because
there is no £
in the US-ASCII charset). Both a suitable content-transfer-encoding and
charset must be specified and followed by the client.


- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
Sent: Monday, August 19, 2002 9:08 PM
Subject: RE: Bizzarre new bug...


Bollocks, I *did* send it through James, Idiot that I am :-)
try £ for ? (in UTF-8 this time) and then the bug is with James on Linux,
and Windows ASCII encoded mail.

d.

> -Original Message-
> From: Steve Short [mailto:[EMAIL PROTECTED]]
> Sent: 19 August 2002 19:53
> To: James Developers List
> Subject: RE: Bizzarre new bug...
>
>
> Maybe he sent his message via James, so his ? got changed to a ?.
>
> Steve
>
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, August 19, 2002 11:56 AM
> > To: James Developers List
> > Subject: RE: Bizzarre new bug...
> >
> >
> > I'm lost.  What is the problem?  "? is being changed to ?"
> >
> > As for the message body being recycled, isn't that what
> > happens (not looking at the code) when a new Mail object is
> > created for a given subset of recipients?
> >
> > I'm sorry, but I really have no idea what this is about.
> >
> > --- Noel
> >
> > -Original Message-
> > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, August 19, 2002 14:19
> > To: James Developers List
> > Subject: Bizzarre new bug...
> >
> >
> > ? is being changed to ? in mail handled by James, in
> > particular the message body is being re-cycled into a new message.
> >
> > Odd.
> > d.
> >
> >
> > --
> > To unsubscribe, e-mail:
> >  [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: 
> >
> >
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: James End User Documentation

[Nicola Ken Barozzi]

Noel J. Bergman wrote:
>>solicit away.
> 
> 
>  1. Can we agree on some [DOCUMENTATION] prefix that people can use, so that
> documentation submissions can be located in the archives?
> 
>  2. How's:
> 
> If you have James related tips, documentation bits, or just questions about
> things that you need help with, please submit them to the James project with
> a [DOCUMENTATION] prefix on the subject.  The more contributions, the better
> the user documentation will get.
> 
> I don't supposed anyone on the list is a tech writer, eh?  :-)
> 
> I'll post up an example of multiple mailing lists so that people can see
> what needs to be done for EACH new mailing list.  The current documentation
> isn't clear on that (in fact, mine works but perhaps I missed a point).

On the Cocoon project, we have already done this.

We started asking to commit doc stuff with [DOCS], then we moved to 
asking to put them in Bugzilla.

Finally we set up a Wiki, and this last solution brought us more 
documentation inh a week than the other two in a month!

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

James End User Documentation

[Noel J. Bergman]

> solicit away.

 1. Can we agree on some [DOCUMENTATION] prefix that people can use, so that
documentation submissions can be located in the archives?

 2. How's:

If you have James related tips, documentation bits, or just questions about
things that you need help with, please submit them to the James project with
a [DOCUMENTATION] prefix on the subject.  The more contributions, the better
the user documentation will get.

I don't supposed anyone on the list is a tech writer, eh?  :-)

I'll post up an example of multiple mailing lists so that people can see
what needs to be done for EACH new mailing list.  The current documentation
isn't clear on that (in fact, mine works but perhaps I missed a point).

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Bizzarre new bug...

[Danny Angus]

Bollocks, I *did* send it through James, Idiot that I am :-)
try £ for ? (in UTF-8 this time) and then the bug is with James on Linux, and Windows 
ASCII encoded mail.

d.

> -Original Message-
> From: Steve Short [mailto:[EMAIL PROTECTED]]
> Sent: 19 August 2002 19:53
> To: James Developers List
> Subject: RE: Bizzarre new bug...
> 
> 
> Maybe he sent his message via James, so his ? got changed to a ?.
> 
> Steve
> 
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> > Sent: Monday, August 19, 2002 11:56 AM
> > To: James Developers List
> > Subject: RE: Bizzarre new bug...
> > 
> > 
> > I'm lost.  What is the problem?  "? is being changed to ?"
> > 
> > As for the message body being recycled, isn't that what 
> > happens (not looking at the code) when a new Mail object is 
> > created for a given subset of recipients?
> > 
> > I'm sorry, but I really have no idea what this is about.
> > 
> > --- Noel
> > 
> > -Original Message-
> > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, August 19, 2002 14:19
> > To: James Developers List
> > Subject: Bizzarre new bug...
> > 
> > 
> > ? is being changed to ? in mail handled by James, in 
> > particular the message body is being re-cycled into a new message.
> > 
> > Odd.
> > d.
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> >  [EMAIL PROTECTED]>
> > For 
> > additional commands, 
> > e-mail: 
> > 
> > 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-james/src/java/org/apache/mailet GenericMailet.java GenericMatcher.java GenericRecipientMatcher.java MailAddress.java

[pgoldstein]

pgoldstein2002/08/19 11:57:08

  Modified:src/java/org/apache/james BaseConnectionHandler.java
James.java JamesMBean.java
   src/java/org/apache/james/core MimeMessageWrapper.java
   src/java/org/apache/james/nntpserver
DateSinceFileFilter.java LISTGroup.java
NNTPException.java
   src/java/org/apache/james/transport/mailets AddFooter.java
AvalonListserv.java AvalonListservManager.java
Forward.java JDBCAlias.java JDBCListserv.java
LocalDelivery.java NotifyPostmaster.java
NotifySender.java Null.java PostmasterAlias.java
Redirect.java ServerTime.java ToProcessor.java
ToRepository.java UseHeaderRecipients.java
   src/java/org/apache/james/transport/mailets/debug
Counter.java DumpSystemErr.java
ExceptionThrowingMailet.java Identity.java
   src/java/org/apache/james/userrepository
AbstractJdbcUsersRepository.java DefaultUser.java
DefaultUsersJdbcRepository.java
JamesUsersJdbcRepository.java
ListUsersJdbcRepository.java
   src/java/org/apache/mailet GenericMailet.java
GenericMatcher.java GenericRecipientMatcher.java
MailAddress.java
  Log:
  More comments, fixed a tab
  
  Revision  ChangesPath
  1.10  +10 -0 
jakarta-james/src/java/org/apache/james/BaseConnectionHandler.java
  
  Index: BaseConnectionHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-james/src/java/org/apache/james/BaseConnectionHandler.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- BaseConnectionHandler.java18 Aug 2002 07:32:38 -  1.9
  +++ BaseConnectionHandler.java19 Aug 2002 18:57:07 -  1.10
  @@ -24,7 +24,15 @@
* @author Harmeet Bedi <[EMAIL PROTECTED]>
*/
   public class BaseConnectionHandler extends AbstractLogEnabled implements 
Configurable {
  +
  +/**
  + * The timeout for the connection
  + */
   protected int timeout;
  +
  +/**
  + * The hello name for the connection
  + */
   protected String helloName;
   
   /**
  @@ -55,6 +63,8 @@
   
   /**
* Release a previously created ConnectionHandler e.g. for spooling.
  + *
  + * @param connectionHandler the ConnectionHandler to be released
*/
   public void releaseConnectionHandler(ConnectionHandler connectionHandler) {
   }
  
  
  
  1.27  +116 -3jakarta-james/src/java/org/apache/james/James.java
  
  Index: James.java
  ===
  RCS file: /home/cvs/jakarta-james/src/java/org/apache/james/James.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- James.java18 Aug 2002 07:32:38 -  1.26
  +++ James.java19 Aug 2002 18:57:07 -  1.27
  @@ -98,7 +98,12 @@
* thread safety and to ensure that all threads see the latest value.
*/
   private static long count;
  +
  +/**
  + * The address of the postmaster for this server
  + */
   private MailAddress postmaster;
  +
   private Map mailboxes; //Not to be shared!
   
   /**
  @@ -267,6 +272,14 @@
   getLogger().info("JAMES ...init end");
   }
   
  +/**
  + * Place a mail on the spool for processing
  + *
  + * @param message the message to send
  + *
  + * @throws MessagingException if an exception is caught while placing the mail
  + *on the spool
  + */
   public void sendMail(MimeMessage message) throws MessagingException {
   MailAddress sender = new MailAddress((InternetAddress)message.getFrom()[0]);
   Collection recipients = new HashSet();
  @@ -277,11 +290,32 @@
   sendMail(sender, recipients, message);
   }
   
  +/**
  + * Place a mail on the spool for processing
  + *
  + * @param sender the sender of the mail
  + * @param recipients the recipients of the mail
  + * @param message the message to send
  + *
  + * @throws MessagingException if an exception is caught while placing the mail
  + *on the spool
  + */
   public void sendMail(MailAddress sender, Collection recipients, MimeMessage 
message)
   throws MessagingException {
   sendMail(sender, recipients, message, Mail.DEFAULT);
   }
   
  +/**
  + * Place a mail on the spool for processing
  + *
  + * @param sender the sender of the mail
  + * @param recipients the recipients of 

RE: Bizzarre new bug...

[Steve Short]

Maybe he sent his message via James, so his ? got changed to a ?.

Steve

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, August 19, 2002 11:56 AM
> To: James Developers List
> Subject: RE: Bizzarre new bug...
> 
> 
> I'm lost.  What is the problem?  "? is being changed to ?"
> 
> As for the message body being recycled, isn't that what 
> happens (not looking at the code) when a new Mail object is 
> created for a given subset of recipients?
> 
> I'm sorry, but I really have no idea what this is about.
> 
>   --- Noel
> 
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 14:19
> To: James Developers List
> Subject: Bizzarre new bug...
> 
> 
> ? is being changed to ? in mail handled by James, in 
> particular the message body is being re-cycled into a new message.
> 
> Odd.
> d.
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Bizzarre new bug...

[Noel J. Bergman]

I'm lost.  What is the problem?  "? is being changed to ?"

As for the message body being recycled, isn't that what happens (not looking
at the code) when a new Mail object is created for a given subset of
recipients?

I'm sorry, but I really have no idea what this is about.

--- Noel

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 14:19
To: James Developers List
Subject: Bizzarre new bug...


? is being changed to ? in mail handled by James, in particular the message
body is being re-cycled into a new message.

Odd.
d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Bizzarre new bug...

[Danny Angus]

? is being changed to ? in mail handled by James, in particular the message
body is being re-cycled into a new message.

Odd.
d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: What do we need to release 2.1

[Noel J. Bergman]

Does a template for such a release plan exist from previous releases?

Peter's issues were expressed in his original post:
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg03100.html,
which kicked off this round of discussion.  Other folks have added their
viewpoints, which can be found in the archives.  Now that we've updated the
Milestone build, I'd amend some of my earlier points.

This is a case where a Wiki would be a useful tool as the details of the
release plan are hashed out.

--- Noel

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 11:43
To: James Developers List
Subject: What do we need to release 2.1


Ok,

1/ we need a release plan, circulated to this list or put into cvs then put
to a vote.

Should include all steps needed to make a release, including..

issue management, fix, close or defer all open bugs.
build & test, make a release candidate available to canvas widest testing
audience

Vote on progress to the next step after completion of issue management.

update all documentation
update website
build, upload, announce

d.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

> You did.  :-)  My question was about soliciting documentation 
> contributions.

solicit away.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> > Would you mind if a message went out on James-User [asking]
> > them for contributions towards the [user] documentation?

> That should wait until we have a release plan

OK

> (I thought I did announce the build, if not feel free to repeat it)

You did.  :-)  My question was about soliciting documentation contributions.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta James Nightly Build

[Noel J. Bergman]

> But thats the point isn't it? Gump isn't just there to make nightly
builds.

That isn't what I understood previously, so this is enlightening.  :-)

> Of course if you'd asked on the list you could have been told. :-)

I refer you to the start of this thread: a message was posted to the list
saying that we had noticed that the Nighly Builds weren't working, and
asking questions.  And answers have been posted.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

> Thank you.  Would you mind if a message went out on James-User
> telling folks
> that we're working towards a new Release Build, and asking them for
> contributions towards the documentation?  They could contribute
> actual bits
> of documentation, or just questions that they are having trouble with.

That should wait until we have a release plan, and are happy that we have a
release candiidate, which we can release for testing and annouce the planned
release.

(I thought I did announce the build, if not feel free to repeat it)

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> > If 2.1aX is an improvement, as we all seem to believe
> > that it is

> We don't, or at least _I_ didn't until two days ago

I didn't think so either, until recently.  And I'm NOT saying that it is
ready today, either, because there ARE issues that should be resolved before
the Release Build.  The question is what are the items to be done to get it
that way.  That was the question Peter raised in his initial post, and the
question you raised again in your post of a few minutes ago.  :-)

> the user documentation and open bugs (still being actively discussed)

Both are things that I agree need to be addressed.

> IMHO 2.1.1 is *not* an improvement until the documentation that
> accompanies it is of an acceptable standard to at least avoid
> leading people astray, even if it isn't actually helpful.

Agreed.

> If you're refering to a milestone, its already been made.

Thank you.  Would you mind if a message went out on James-User telling folks
that we're working towards a new Release Build, and asking them for
contributions towards the documentation?  They could contribute actual bits
of documentation, or just questions that they are having trouble with.

I'll post up an example of multiple mailing lists so that people can see
what needs to be done for EACH new mailing list.  The current documentation
isn't clear on that (in fact, mine works but perhaps I missed a point).
Should such contributions be posted to James-Dev or James-User?

> I don't believe that we javadocs are a showstopper, but neither do I
believe
> that they should be swept under the carpet.

That is exactly what I have been saying, Danny.  No one is sweeping javadocs
under the carpet, or deferring them.  They are being worked on actively.
Andrew has been arguing vociferously that they are a showstopper, and that's
the point of disagreement.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta James Nightly Build

[Danny Angus]

> Fair enough.  I would not have gotten that from the description of Nightly
> Build.

But thats the point isn't it? Gump isn't just there to make nightly builds.

> This comfirms what I said to Peter

What did you say to Peter? *please* don't refer, in an offhand way, to
conversations we haven't all been privy to.

> about how I thought the earlier builds
> had been done.  You did them on a clean machine, and posted them back up.

Of course if you'd asked on the list you could have been told. :-)

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

> Exactly.  The CVS has corrected documentation that should be made
> available
> to the user community.

Up to date documentation is available on the website, this is common
practice.
Unless we seperate the release of docs from code its unavoidable, not least
because we're bound to increment release numbers by the jakarta standards we
can't patch a release once its been made, and incrementing release numbers
to patch docs would lead to a flood of email asking us what exactly had
changed in the product..

> The fact remains that 2.0a3 is out there as a Release Build.  For
> better or
> for worse.  If 2.1aX is an improvement, as we all seem to believe
> that it is

No, actually we don't, or at least _I_ didn't until two days ago, and even
then there are still the user documentation and open bugs (still being
actively discussed) to be dealt with notwithstanding the javadocs. IMHO
2.1.1 is *not* an improvement until the documentation that accompanies it is
of an acceptable standard to at least avoid leading people astray, even if
it isn't actually helpful.

> (or is close to being), then it should be put out as the next incremental
> step on the road.

If you're refering to a milestone, its already been made.

I don't believe that we javadocs are a showstopper, but neither do I believe
that they should be swept under the carpet.
Once the precendent has been establised to defer unpopular tasks it is hard
to instil any urgency in them.
I believe that we should certainly be considering the javadocs when we vote,
as well as the user docs, website and functionality.
What emphasis each commiter gives to that will be reflected in their vote.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: address-literal addressing not working

[Noel J. Bergman]

> trying to produce predictable and easily controllable behaviour
> keep configuration simple and flexible.

Yes, yes, and yes.  :-)

> If you don't care about IPaddresses James will work fine when you ignore
> that section

If you really DON'T care, James will work fine if you ignore that attribute.
If you DO care, then you can turn off auto-discovery, and add (or not) the
IP addresses manually.  I do believe that satisfying the RFC should be the
default polarity, but I had added the configurability that you requested.

I think we agree.  I just don't think that it requires a separate element to
do this.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta James Nightly Build

[Noel J. Bergman]

> the premis of Gump, as I understand it, that it encourages
> continuous integration within the jakarta domain.

Fair enough.  I would not have gotten that from the description of Nightly
Build.

> Its certainly reasonable to suggest a self-contained nightly build of
James,
> the problem is resources, the apache machines ('cept nagoya) run BSD so we
> can't build on them, therefore someone needs to donate the build location.

Thanks for explaining this, Danny.  :-)

> I changed build.xml to put the downloads into a directory that can be
scp'ed
> across by a single command to make automatic releases easier, and I have a
> "clean" machine that I build releases on ...

This comfirms what I said to Peter about how I thought the earlier builds
had been done.  You did them on a clean machine, and posted them back up.
(a) thanks, (b) how can anyone help?

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> how long did it take you to find a class to use as an example, 
> or did you just go down the left nav in alphabetical order?

About 30 seconds.  I just picked at random from the nav bar.

> some of the committers of POI would like a policy of
> requiring a unit test per class before release!

A good idea.  Something that we all ought to be doing.

> I'll NEVER understand your position that javadoc isn't
> important enough to hold up a formal release.

Fact: 2.0a3 is listed as a Release Build.
Fact: 2.1a1 improves upon 2.0a3.

View: IF it is as/more stable, it should replace its predecessor.

--- Noel



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> > how to setup a database URL (which is correct in the
> > CVS, and wrong in the current download).

> If this is the case it because the docs have been fixed.

Exactly.  The CVS has corrected documentation that should be made available
to the user community.

> you should only consider the relevance of the stable "release"
> versions' documentation

I was refering to 2.0a3, which IS the latest "stable Release Build."

> Furthermore James has never released a Beta quality version yet,

Perhaps not, but in Apache terminology, James 2.0a3 is a Release Build.  If
you are saying that James should never have had a Release, only a Milestone,
I won't argue the point.

> I subscribe to Andy's opinion that James is hard for a new user to get
> started with ...

So do I.  But that has to do with end user documentation, not javadocs,
except for the headers on Matchers & Mailets that contain samples, which
I've been fixing as I spot them.

On the one hand, Andy is taking an all-or-nothing position on javadocs (if
we don't have them all, we have nothing); on the other hand, he said "If I
weren't a semi-decent Java developer I couldn't even set up JAMES."

Contrary to his accusations, I've recently found, fixed and documented
various issues involving the spooler (locking, the mysterious NPE, the
reason why a message might no longer be in the spool after accept() gives it
to you); the potential for an infinite loop involving Forward;
address-literals; discrepancies between RFCs and the size of database
fields; and more.  Fortunately, I have a sense of humor.

> a +1 vote for a release binds the voter to support that release

A good policy.  :-)  I've been doing that even without a vote.  And that's
why I want to see a new release, because it will be easier to support.

As for the javadocs, I agree with everything you said about the value of
code documentation.  In every case, everyone says that it is important, no
one has said anything about not documenting or slowing documentation.  The
only issue is whether or not to update what is currently published with what
is available.  It is a matter of improvement while continuing towards
perfection.

The fact remains that 2.0a3 is out there as a Release Build.  For better or
for worse.  If 2.1aX is an improvement, as we all seem to believe that it is
(or is close to being), then it should be put out as the next incremental
step on the road.  Andy views that statement as tantamount to dismissing
javadocs as worthless.  I view his approach as being roughly the same as
saying my transmission needs an overhaul so I'll skip the oil changes until
I can afford to pay for the major service.  Both things need to be done, and
are continuing apace.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

What do we need to release 2.1

[Danny Angus]

Ok,

1/ we need a release plan, circulated to this list or put into cvs then put
to a vote.

Should include all steps needed to make a release, including..

issue management, fix, close or defer all open bugs.
build & test, make a release candidate available to canvas widest testing
audience

Vote on progress to the next step after completion of issue management.

update all documentation
update website
build, upload, announce

d.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: What do we need to release 2.1?

[Lach, Thierry]

Title: RE: What do we need to release 2.1?





In the interest of stability, I'd suggest releasing it with IMAP turned off and those that want it can enable it.  


-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, August 17, 2002 5:46 AM
To: James Developers List
Subject: RE: What do we need to release 2.1?



> My impression what I look at James from the Merlin perspective is that 
> James is actualy made up of a number of reusable components - and DNS 
> sever, SMTP server, mail reposirtory, NNTP server, etc.  IMAP is just 
> another component.  The point I'm getting at is that it could be 
> usefull to look at James in terms of its component parts - start 
> qualifying these in terms of stability,


We already do this, but not versioning.


and IMHO it is perfectly acceptable to release James with unstable alpha IMAP, and stable other protocols, because users who don't want IMAP can turn it off.

d.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta James Nightly Build

[Danny Angus]

Noel wrote,

> > But the point of Gump is that it tests the domain level build
> by building
> > every part of the domain from scratch.
>
> That assumes that the domain is evolving in synch, and is intended to be
> released in synch.  It works great for a domain level project, but that's
> not necessarily the case.

No, but it is the premis of Gump, as I understand it, that it encourages
continuous integration within the jakarta domain.



> From that perspective, I could see two nightly builds: a domain
> level build,
> and the other a build of James against the components that it is
> intended to
> work with.

Its certainly reasonable to suggest a self-contained nightly build of James,
the problem is resources, the apache machines ('cept nagoya) run BSD so we
can't build on them, therefore someone needs to donate the build location.

I changed build.xml to put the downloads into a directory that can be scp'ed
across by a single command to make automatic releases easier, and I have a
"clean" machine that I build releases on, but I wouldn't like James to rely
on it, as its continued presence is outwith my control.
I would also be wary of entrusting my apache password or keys to a machine
on which there are other people with root.

Hence the reason I instigated the "latest" directory, to make builds
available at random when it seems worthwhile, and that aren't deleted by
someones cron job.
Anyone is welcome to cajole us into putting a new version in latest.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta James Nightly Build

[Noel J. Bergman]

> But the point of Gump is that it tests the domain level build by building
> every part of the domain from scratch.

That assumes that the domain is evolving in synch, and is intended to be
released in synch.  It works great for a domain level project, but that's
not necessarily the case.

> a newcomer to the ideas of domain engineering I can totally
> subscribe to the principles of Gump, and seeing Avalon as a
> provider of domain commonalities, and James as an expression
> of variability, I can see how the domain level build testing
> of Gump would help accelerate the handling of James/Avalon issues.

>From that perspective, I could see two nightly builds: a domain level build,
and the other a build of James against the components that it is intended to
work with.

At some point a project with dependencies needs to freeze the dependencies.
You can't just take their latest CVS.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta James Nightly Build

[Danny Angus]

the problem is that Avalon isn't building, in particular
http://jakarta.apache.org/builds/gump/latest/jakarta-avalon-excalibur.html


> it is very clear that this definition is pretty far out of date.  Among
> other things, the file refers to a James.bar, which if I recall
> correctly was the predecessor to the current James.sar.  So the file
> needs to be updated.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

consider yourself upgraded in my book! ;-)

Danny Angus wrote:
>>or something as
>>fundamental as the correct documentation for how to setup a database URL
>>(which is correct in the CVS, and wrong in the current download).
> 
> 
> If this is the case it because the docs have been fixed.
> 
> And.. you should only consider the relevance of the stable "release"
> versions' documentation, the "latest" and "nightly" builds are strictly
> snapshots of work-in-progress, as such they should not be expected to
> function, nor should documentation be expected to be correct in any aspect.
> 
> Furthermore James has never released a Beta quality version yet, all the
> releases so far have, for various reasons, been considered to be Alpha
> quality code.
> 
> I subscribe to Andy's opinion that James is hard for a new user to get
> started with, because I have had to nursemaid many such users through their
> first experience with James.
> 
> In addition to documentation making life easier for users remember also that
> a +1 vote for a release binds the voter to support that release by
> participating on the developers and users lists. This is a great incentive
> to commiters to produce clear and accurate user documentation, and clear and
> accurate code documentation.
> 
> IMHO while the XP case for not documenting code is based in part upon the
> assumption that the code should be easy to follow and documentation  ca be
> used to avoid writing clear code, it does not follow that concise targeted
> code documentation obfuscates the code.
> 
> I rather believe that good javadoc documentation can encourage encapsulation
> and re-use by removing the necessity for programmers to concern themselves
> with the detail of code not directly relevant to the issues they are
> addressing, revealing method signatures and documenting their intended use
> cannot, surely, be counter productive, particularly in an OSS project.
> 
> Take a look at the Tomcat javadocs, they reveal the architecture of Tomcat
> in just enough detail for an outsider to extend and adapt the product,
> without explaining away bad practices, or forcing you to read the code
> itself.
> 
> I strongly believe that code documentation should be a halfway house between
> user documentation and the code itself, providing a convenient and easily
> navigable journey through the architecture, un-encumbered by the
> implementation details.
> 
> d.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: address-literal addressing not working

[Danny Angus]

> I consider a separate serveraddresses section to be unnecessary.  It is
> perfectly permissible today to add elements of the form:
>
> xxx.xxx.xxx.xxx
>
> to the  element today.  If truely desired, we could accept:
>
> [xxx.xxx.xxx.xxx]
>
> and strip the brackets.  The brackets must be stripped because the
> comparison is made against MailAddress.getHost(), and getHost()
> must return
> a valid host (which is why getHost() strips the brackets when it provides
> the host).


The point is that we should be trying to produce predictable and easily
controllable behaviour, keep configuration simple and flexible.
If you don't care about IPaddresses James will work fine when you ignore
that section, if you do care you can reuse your knowledge of how to
configure other aspects of James and plainly see exactly what you should
modify.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] james-config.xml/james.java

[Danny Angus]

I believe that we should use  as for the connection handlers, for
consistent naming, I know the use will be slightly different, in that its
not used for hello, but I don't think its so far out to as be wrong as its
still the name we identify ourselves by.

d.



> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: 19 August 2002 00:22
> To: James Developers List
> Subject: RE: [PATCH] james-config.xml/james.java
>
>
> Danny,
>
> I'll be happy to make that change.  What attribute name for
> MailetContext.getAttribute() would you like for me to use?
> Constants.HELLO_NAME?  By "root of the config", do you mean an
> child element
> of the  section?  Do you want this to be an element or an
> attribute,
> e.g.,
>
> 
>
> OPTION 1 
>
>
>
> 
>
> I'd like to use this in BaseConnectionHandler.configure() to
> autodetect the
> helloName:
>
> if (autodetect) {
> helloName = defaultHelloName != null ? defaultHelloName :
> hostName;
> }
> else
> helloName = helloConf.getValue("localhost");
>
> To do this, I propose restoring this line of code in James:
>
> //compMgr.put("org.apache.mailet.MailetContext", this);
>
> so that I can request the attribute from James in
> BaseConnectionHandler.configure().
>
>   --- Noel
>
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
>
> I like the servername attribute for remote delivery, I believe that we
> should actually add it at the root of config, and make it available to all
> mailets as a parameter in the context, to be added to the mailet API in
> time. see my other mail regarding ipaddresses.
>
> d.
>
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> [clip]
> > As submitted in a separate patch, RemoteDelivery.java has already had a
> >  attribute added to it.  With out, James uses the
> > first name in the server name collection, which would often be either
> > localhost or, if autodetected were turned on, the internal name of the
> > computer.  This behavior was undocumented, and with the HashSet change
> > is undefined.  I've updated the james-config.xml comments for this new
> > element.  The  element is necessary with the HashSet change,
> > but is otherwise still useful (and optional).
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

> or something as
> fundamental as the correct documentation for how to setup a database URL
> (which is correct in the CVS, and wrong in the current download).

If this is the case it because the docs have been fixed.

And.. you should only consider the relevance of the stable "release"
versions' documentation, the "latest" and "nightly" builds are strictly
snapshots of work-in-progress, as such they should not be expected to
function, nor should documentation be expected to be correct in any aspect.

Furthermore James has never released a Beta quality version yet, all the
releases so far have, for various reasons, been considered to be Alpha
quality code.

I subscribe to Andy's opinion that James is hard for a new user to get
started with, because I have had to nursemaid many such users through their
first experience with James.

In addition to documentation making life easier for users remember also that
a +1 vote for a release binds the voter to support that release by
participating on the developers and users lists. This is a great incentive
to commiters to produce clear and accurate user documentation, and clear and
accurate code documentation.

IMHO while the XP case for not documenting code is based in part upon the
assumption that the code should be easy to follow and documentation  ca be
used to avoid writing clear code, it does not follow that concise targeted
code documentation obfuscates the code.

I rather believe that good javadoc documentation can encourage encapsulation
and re-use by removing the necessity for programmers to concern themselves
with the detail of code not directly relevant to the issues they are
addressing, revealing method signatures and documenting their intended use
cannot, surely, be counter productive, particularly in an OSS project.

Take a look at the Tomcat javadocs, they reveal the architecture of Tomcat
in just enough detail for an outsider to extend and adapt the product,
without explaining away bad practices, or forcing you to read the code
itself.

I strongly believe that code documentation should be a halfway house between
user documentation and the code itself, providing a convenient and easily
navigable journey through the architecture, un-encumbered by the
implementation details.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

Yeah, I don't see a problem with that.  its with an actual release.

Danny Angus wrote:
> If thats what you want to do we can put out another dated 2.1a1.
> d.
> 
> 
>>>As I said in another e-mail, let's put out a 2.1a2 Milestone Build to
>>>replace the ancient May 30 2.1a1 Milestone, and I'll feel much 
>>
>>better for
>>
>>>our end users.
>>>
>>> --- Noel
>>
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   
> 
> 
> For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

> James' code isn't undocumented, but there are various uncommented members,
> so Peter is trying to complete the documentation.  The same can be said of
> org.apache.poi.  For example, AbstractFunctionPtg is missing javadocs for a
> number of members.

I'll bite...

While this is a tad offtopic...



For one, some of the members are deliberately uncommented (I don't do
inherited members as the javadoc will override the parent's).

However, POI will not have a release with formulas enabled by default 
until its fixed.  It will have "development builds" (alphas or 
"milestones") until then, but thats it.  Why: its not of release 
quality.  As evidence, formula support is still in early beta.

So Noel, how long did it take you to find a class to use as an example, 
or did you just go down the left nav in alphabetical order? That one is 
a few layers deep and in the most beta of code!  I'm impressed at your 
resolve!  If you can find others I'll make a list of them and make sure 
I catch them all before +1'ing our next release.

To take THAT a step further, some of the committers of POI would like a 
policy of requiring a unit test per class before release!  That will 
likely pass for our 3.0 release.  We'll probably need a few enhancements 
to Centipede to support "test-first" a little better before we draft that.

Just FYI, the policy on this is covered here: 
http://jakarta.apache.org/poi/resolutions/res001.html

and more or less here:

http://jakarta.apache.org/site/source.html

Its a quality thing.



Anyhow, I'm just a guy trying to make hide or hair of james.  My opinion 
shouldn't count for much, but I'll NEVER understand your position that 
javadoc isn't important enough to hold up a formal release.  (I already 
said milestone and dev releases are reasonable, but I don't think YOU 
gave it a close read)

Thanks,

Andy




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

I will write Javadocs as I come to understand what the heck things are
(this is of course is a chicken and the egg proposition).

My interest is more in creating an M$ Exchange protocol replacement. 
But its a ways out and first IMAP needs to get up to snuff.

-Andy

Tetsuya Kitahata wrote:
> On Mon, 19 Aug 2002 00:46:55 -0400
> "Noel J. Bergman" <[EMAIL PROTECTED]> wrote:
> 
> 
>>And, of course, this has nothing to do with end user documentation,
>>such as telling a user how to install and deploy James.  You know,
>>little things like how to setup a mailing list (have fun reading the
>>docs and FAQ), how different matchers and mailets interact with each
>>other, or something as fundamental as the correct documentation for
>>how to setup a database URL (which is correct in the CVS, and wrong in
>> the current download).
> 
> 
> I agree with this. James' user documents are very good and smart.
> I think just Andy want to commit some Mailets as a developer, or
> seek where to.
> 
> I'm wondering how nice it would be to add Mailet which automatically
> collect the attached MS-Office files in e-mails and produce
> automatically RDF/XMLs of these files ... for example.
> (This is why I have come to be interested in POI and James)
> 
> -- Tetsuya Kitahata <[EMAIL PROTECTED]>





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

New "latest" build available

[Danny Angus]

There is now a new dated build of the HEAD of CVS in
http://jakarta.apache.org/builds/jakarta-james/latest/
This is a snapshot of recent changes for evaluation, and should not be
considered to be a stable release.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-james/www index.html

[danny]

danny   2002/08/19 05:09:00

  Modified:www  index.html
  Log:
  news, annouced new "latest" build
  
  Revision  ChangesPath
  1.14  +7 -3  jakarta-james/www/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-james/www/index.html,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- index.html30 Jul 2002 13:50:13 -  1.13
  +++ index.html19 Aug 2002 12:09:00 -  1.14
  @@ -176,21 +176,25 @@
   
   
   
  +
  +Latest: james-2.1a1-2002-08-18
  + There is a new dated build in the http://jakarta.apache.org/builds/jakarta-james/latest";>download area. This 
build should only be considered for evaluation, and should not be considered stable. 
It represents a snapshot of the most recent changes
   
   
  -Just released: v2.0a3
  +Stable: v2.0a3
   This version displays improved stability and a number of bug fixes over v2.0a2 
and is the recommended stable version
   
   
   http://jakarta.apache.org/builds/jakarta-james/release/v2.0a3";>Binary and 
Source distributions of v2.0a3
   
   
  +
  +
   
   Get your hands on the latest versions..
  -We have started putting significant milestones, and potential release 
candidates in the http://jakarta.apache.org/builds/jakarta-james/latest";>download area.
  +We put significant milestones, and potential release candidates in the http://jakarta.apache.org/builds/jakarta-james/latest";>download area.
   Whilst the quality of these versions cannot be guaranteed they may contain 
important bug fixes and cool new features. They also provide an opportunity for 
interested users to test our latest changes, we're *always* happy to receive bug 
reports.
   
  -
   
   
   We've added an FAQ page.
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-james/src/xdocs index.xml

[danny]

danny   2002/08/19 05:08:48

  Modified:src/xdocs index.xml
  Log:
  news, annouced new "latest" build
  
  Revision  ChangesPath
  1.16  +4 -3  jakarta-james/src/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-james/src/xdocs/index.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- index.xml 30 May 2002 11:21:03 -  1.15
  +++ index.xml 19 Aug 2002 12:08:48 -  1.16
  @@ -15,12 +15,13 @@
   James is based upon the Apache Avalon application framework. (For more 
information about Avalon, please go to http://jakarta.apache.org/avalon";>http://jakarta.apache.org/avalon)
   James requires Java 2 (either JRE 1.3 or 1.4 as of 2.0a3). 
   
  -
  -Just released: v2.0a3This version displays improved stability and a 
number of bug fixes over v2.0a2 and is the recommended stable version
  +Latest: james-2.1a1-2002-08-18 There is a new dated build in the http://jakarta.apache.org/builds/jakarta-james/latest";>download area. This 
build should only be considered for evaluation, and should not be considered stable. 
It represents a snapshot of the most recent changes
  +Stable: v2.0a3This version displays improved stability and a number 
of bug fixes over v2.0a2 and is the recommended stable version
   
   http://jakarta.apache.org/builds/jakarta-james/release/v2.0a3";>Binary and 
Source distributions of v2.0a3
  -Get your hands on the latest versions..We have started putting 
significant milestones, and potential release candidates in the http://jakarta.apache.org/builds/jakarta-james/latest";>download 
area.Whilst the quality of these versions cannot be guaranteed they may 
contain important bug fixes and cool new features. They also provide an 
opportunity for interested users to test our latest changes, we're *always* happy to 
receive bug reports.
   
  +Get your hands on the latest versions..We put significant 
milestones, and potential release candidates in the http://jakarta.apache.org/builds/jakarta-james/latest";>download 
area.Whilst the quality of these versions cannot be guaranteed they may 
contain important bug fixes and cool new features. They also provide an 
opportunity for interested users to test our latest changes, we're *always* happy to 
receive bug reports.
  +
   We've added an FAQ page.There are only half a dozen FAQ's so far, 
but its a beginning.
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

If thats what you want to do we can put out another dated 2.1a1.
d.

> > As I said in another e-mail, let's put out a 2.1a2 Milestone Build to
> > replace the ancient May 30 2.1a1 Milestone, and I'll feel much 
> better for
> > our end users.
> > 
> > --- Noel
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta James Nightly Build

[Peter Donald]

The gump descriptors are part of Gump which is a proposal in the Alexandria 
project. You can locate the descriptor by looking in cvs at

jakarta-alexandria/proposal/gump/projects/jakarta-james.xml

And send questions, diffs and patches to [EMAIL PROTECTED] 
mailing list.

On Mon, 19 Aug 2002 11:45, Peter M. Goldstein wrote:
> To more knowledgeable heads than I,
>
> Noel and I have been looking at the nightly build process and are a
> little disturbed by the fact that:
>
> i) It is failing
> ii) It is failing without notifying james-dev
>
> See the nightly build report here:
>
> http://jakarta.apache.org/builds/gump/latest/jakarta-james.html
>
> After examining the definition file here,
>
> http://jakarta.apache.org/builds/gump/latest/module_jakarta-james.html
>
> it is very clear that this definition is pretty far out of date.  Among
> other things, the file refers to a James.bar, which if I recall
> correctly was the predecessor to the current James.sar.  So the file
> needs to be updated.
>
> The build is currently failing because of unnecessary dependencies -
> James builds off snapshots of the assorted Avalon subprojects and hence
> does not need those project builds to succeed.  So the dependency
> entries need to be updated.
>
> I'm willing to volunteer to do the jakarta-james.xml file update.  My
> big problem is that I don't know where the file is, and I don't think I
> have write-access to it.  I'd like to get one of the Apache elders to
> give me a hand with this.  As Peter Donald is listed in the nag tag, I'm
> cc'ing him on this email.  Any help would be greatly appreciated.
>
> --Peter

-- 
Cheers,

Peter Donald
--
 Logic: The art of being wrong with confidence...
--


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: NNTP auth issues

[Jason Webb]

Obvious if you think about it...

All you need to do is add the datasource selector lines as follows:
(I'm very sorry, but given my dev env., I can't provide diffs without
destroying lots of work, or giving you stuff you don't need)

In AuthServiceImpl.xinfo add:

  


In james-assembly.xml:
(add the DataSourceSelector line)

  
  


  

-- Jason


-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
Sent: 19 August 2002 07:39
To: James Developers List
Subject: RE: NNTP auth issues


Paul,

FYI, the NNTP code is not a Mailet.  :-)  It is one of these:

public class AuthServiceImpl extends AbstractLogEnabled
implements AuthService, Composable, Configurable

and acquired by the NNTPHandler like this:

  auth =
(AuthService)componentManager.lookup("org.apache.james.nntpserver.AuthSe
rvic
e");

so I presume that it is probably supposed to carry the Component
decoration until you show us how you want that replaced.

> anti-pattern of Mailets getting free reign of the ComponentManager

We'll get there.  There is no way to have a portable Mailet API if
Mailets have to keep getting at non-portable services.

--- Noel

-Original Message-
From: Paul Hammant [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 2:18
To: James Developers List
Subject: Re: NNTP auth issues


Noel,  Jason,

>Shouldn't be any different.  Did you make any progress on this?
>
>You might want to ask Paul Hammant to take a look at it.  For example, 
>I don't know what the relationship is between the .xinfo files and 
>things
like
>the assembly file, but the .xinfo for the nntp server doesn't have an 
>entry for the UsersStore, which is present in the .xinfo for other 
>services.
>
There is a strong relationship is Noel suspects.

You will have to fork the root NNTP block to declare its need for and
get DataSource from ComponentManager in its compose method.

At least until we find a way of eliminating the dar I suggest insecure
anti-pattern of Mailets getting free reign of the ComponentManager.

- Paul

>   --- Noel
>
>-Original Message-
>From: Jason Webb [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, August 15, 2002 6:30
>To: 'James Developers List'
>Subject: NNTP auth issues
>
>
>I'm trying to link our database into the NNTP auth mechanism as we 
>provide an MLM that has a lot of NNTP style features. However, when I 
>ask for a DataSource from the ComponentManager, I get an exception 
>thrown at me:
>
>org.apache.avalon.framework.component.ComponentException: Unable to 
>provide implementation for 
>org.apache.avalon.cornerstone.services.datasource.DataSourceSelector
>at 
>org.apache.avalon.framework.component.DefaultComponentManager.lookup
>DefaultComponentManager.java:70)
>at 
>org.apache.james.nntpserver.AuthServiceImpl.isAuthenticated(AuthService
>I
>mpl.java:84)
>at
>org.apache.james.nntpserver.AuthServiceImpl.isAuthorized(AuthServiceImp
l
>.java:53)
>
>
>Etc
>
>It all works fine in the mailet we use for our MLM. Is NNTP special 
>with regards to DataSources?
>
>Help!
>
>-- Jason
>
>
>--
>To unsubscribe, e-mail:

>For additional commands, e-mail: 
>
>
>
>




--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:

For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta James Nightly Build

[Danny Angus]

I wrote,
> >But the point of Gump is that it tests the domain level build by building
> >every part of the domain from scratch.
Steve replied,
> Which from my point of view is the really valuble thing

Mine too, as a newcomer to the ideas of domain engineering I can totally
subscribe to the principles of Gump, and seeing Avalon as a provider of
domain commonalities, and James as an expression of variability, I can see
how the domain level build testing of Gump would help accelerate the
handling of James/Avalon issues.

I'm not sure what to do about Gump/James, but I do know where to start
poking around..

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta James Nightly Build

[Stephen McConnell]

Danny Angus wrote:

>>Again, personally, I would not want James to build against the Phoenix
>>nightly builds.  I'd prefer that it build against the snapshot
>>that is part
>>of James.
>>
>>
>
>But the point of Gump is that it tests the domain level build by building
>every part of the domain from scratch.
>  
>

Which from my point of view is the really valuble thing - validation the 
Avalon Framework, Excalibur Xxxx, Cornerstone component Xxxx, Phoenix, 
etc. are all in sync - and delivering what your expecting.  It goes a 
long way in providing the James community much more specific information 
about a problem - information that is sufficient for the Avalon 
community to react appropriately if a problem does occur.  If the same 
thing were put in place with Cocoon the we (Avalon Land) would have a 
rather nice early warning process in place.

Cheers, Steve.


>d.
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta James Nightly Build

[Danny Angus]

> Again, personally, I would not want James to build against the Phoenix
> nightly builds.  I'd prefer that it build against the snapshot
> that is part
> of James.

But the point of Gump is that it tests the domain level build by building
every part of the domain from scratch.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: