Danny,
I see. And since the connection handlers might provide a different hello
name for each protocol, e.g., smtp.domain, pop.domain, news.domain, perhaps
a global hello name default doesn't make as much sense.
The hello name is supposed to relate to some external visible entity. Right
now, each handler has a hello name, and I had put one on the RemoteDelivery
mailet, which you suggested would be nice if moved to a shared position for
all mailets. That makes sense, but it raises another question in my mind.
Conceptually, it seems to me that the current spool manager processors are
SMTP server related. For example, I would expect that we'd NNTP related
items would route through some different processors, with their own matchers
and mailets. Is that why the NNTP server has its own spool block, albeit
pretty much empty? Is the spool manager section supposed to be SMTP
specific?
In any event, before I create a separate hello name for the mailet context,
if the current spool manager is really the smtp spool, then should I just
grab the smtp server's hello name, rather than replicate it?
--- Noel
-----Original Message-----
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 20, 2002 3:19
To: James Developers List
Subject: RE: [PATCH] Server-wide default hello name
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:
> >
> > <james>
> > <postmaster/>
> > <helloName> OPTION 1 </helloName>
> > <servernames helloName="OPTION 2" />
> > <usernames/>
> > <inboxRepository/>
> > </james>
> >
> > 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 <helloName> 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 <James> section? Do you want this to be
> > > an element or an attribute, e.g.,
> > >
> > > <james>
> > > <postmaster/>
> > > <servername> OPTION 1 </servername>
> > > <servernames helloName="OPTION 2" />
> > > <usernames/>
> > > <inboxRepository/>
> > > </james>
> > >
> > > 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
> > > > <serverName> 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 <serverName> element is necessary with the
> > HashSet change,
> > > > but is otherwise still useful (and optional).
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
