You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stephen McConnell <mc...@apache.org> on 2003/09/08 10:20:17 UTC
probably bug in LocalDelivery
Have recently changed a bunch of things related to DNS, MX records, and
the configuration and location of my local james installation. In this
process I've managed to establish an error condition and on
investigation I've located a possible bug in the LocalDelivery mailet
(James HEAD).
In LocalDelivery.init()
if (newConfig.getInitParameter("users") != null) {
users = newConfig.getInitParameter("users");
localusers = getMailetContext().getUserRepository(users);
} else {
log("No users repository defined for LocalDelivery");
}
In the above fragment of code, the "users" and "localusers" variables
only get initialized if newConfig.getInitParameter("users") is not
null. In the case I'm dealing with the value is returning null.
Later on in LocalDelivery.service() we have the following:
if (ignoreCase) {
username = localusers.getRealName(recipient.getUser());
} else if (localusers.contains(recipient.getUser())) {
username = recipient.getUser();
}
As localusers is null we get an NPE.
So one question is - should the init function be throwing an exception
or should service throw an exception is localusers is null?
The second question concerns the recognition of the local user repository.
James is logging the following:
[INFO ] (james.james.Mailet): LocalDelivery: No inboxURI defined for
LocalDelivery
[INFO ] (james.james.Mailet): LocalDelivery: No users repository
defined for LocalDelivery
However, the james configuration contains:
<inboxRepository>
<repository destinationURL="file://var/mail/inboxes/" type="MAIL"/>
</inboxRepository>
... and the directory exists.
Ummm - I'm confussed - any pointers appreciated.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: probably bug in LocalDelivery
Posted by Danny Angus <da...@apache.org>.
> Have recently changed a bunch of things related to DNS, MX records, and
> the configuration and location of my local james installation. In this
> process I've managed to establish an error condition and on
> investigation I've located a possible bug in the LocalDelivery mailet
> (James HEAD).
> ... and the directory exists.
> Ummm - I'm confussed - any pointers appreciated.
Stephen, I've just commited an upgrade to this mailet such that omitting
EITHER of "inboxURI" or "users" causes it to ignore all the config settings
and behave exactly as LocalDelivery in James 2.1.3.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: probably bug in LocalDelivery
Posted by Danny Angus <da...@apache.org>.
> I can confirm that it doesn't ;-)
> Can I leave it to you to update this?
yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: probably bug in LocalDelivery
Posted by Stephen McConnell <mc...@apache.org>.
Danny Angus wrote:
>>Have recently changed a bunch of things related to DNS, MX records, and
>>the configuration and location of my local james installation. In this
>>process I've managed to establish an error condition and on
>>investigation I've located a possible bug in the LocalDelivery mailet
>>(James HEAD).
>>
>>
>
>Ah yes, there may well be a bug in there, I de-coupled the local-delivery
>mailet from the global "inbox" specification in order that we could support
>delivery to several "inbox" repositories. It's too long ago to recall
>exactly how much of the work I comitted, but read on..
>
>This was done in order to support virtual hosting, whereby several instances
>of local delivery could be created, each using a different repository and
>their inputs filtered by domain. Resulting in per-domain "inboxes", an
>essential prerequisite of vhosting.
>
>The local delivery mailet should use the global value if a local one isn't
>defined, looks to me like it doesn't.
>
>
I can confirm that it doesn't ;-)
Can I leave it to you to update this?
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: probably bug in LocalDelivery
Posted by Danny Angus <da...@apache.org>.
> Have recently changed a bunch of things related to DNS, MX records, and
> the configuration and location of my local james installation. In this
> process I've managed to establish an error condition and on
> investigation I've located a possible bug in the LocalDelivery mailet
> (James HEAD).
Ah yes, there may well be a bug in there, I de-coupled the local-delivery
mailet from the global "inbox" specification in order that we could support
delivery to several "inbox" repositories. It's too long ago to recall
exactly how much of the work I comitted, but read on..
This was done in order to support virtual hosting, whereby several instances
of local delivery could be created, each using a different repository and
their inputs filtered by domain. Resulting in per-domain "inboxes", an
essential prerequisite of vhosting.
The local delivery mailet should use the global value if a local one isn't
defined, looks to me like it doesn't.
(For completeness the rest of the work was to involve additional
configurations for pop3 which could:
EITHER specify inbox specifications mapped to bound IP addresses, for IP
based vhosting,
OR specify that the user would log-in with user@domain as their username
and that the domain part would map to an inbox, for name based vhosting,
OR the global inbox specification would be used for default no vhost as it
does at present.)
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org