> > I just realized that like an idiot, I just committed the
> > changes before testing them. :-( I'll be doing that
> > immediately.
> Sounds great, (except for the non-testing part ;-))
Well, at least the dogfood tastes good ...
Changing to use org.xbill.DNS.Address instead of InetAddress fo
L PROTECTED]
> Sent: martedì 13 aprile 2004 16.48
> To: James Developers List
> Subject: RE: MxSorter and changes to DNSServer.java
>
>
> > after your commit I'm getting the following build error:
>
> Did you update the whole project? There are an updated dnsja
> Also, was a JIRA issue created for this change?
For the dnsjava change? Kind of bundled with another, but I've created an
explicit one for it.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comma
> after your commit I'm getting the following build error:
Did you update the whole project? There are an updated dnsjava JAR and
build.xml.
--- Noel
See:
http://cvs.apache.org/viewcvs.cgi/james-server/lib/?only_with_tag=branch_2_1
_fcs
http://cvs.apache.org/viewcvs.cgi/james-server
On Tuesday 13 April 2004 03:49, Noel J. Bergman wrote:
> > I haven't looked at the org.xbill.DNS.Address but it
> > sounds like a good solution.
>
> Agreed. I'll look at making that change.
>
> > I have put it on my todo-list to go through the code and
> > weed-out InetAddress, just haven't gotten
Vincenzo Gianferrari Pini wrote:
Noel,
after your commit I'm getting the following build error:
compile:
Compiling James Java sources
Compiling 228 source files to C:\cvsssh\james-branch_2_1_fcs\build\classes
C:\cvsssh\james-branch_2_1_fcs\src\java\org\apache\james\dnsserver\DNSServer.java:257:
rs List
> Subject: RE: MxSorter and changes to DNSServer.java
>
>
> > I haven't looked at the org.xbill.DNS.Address but it
> > sounds like a good solution.
>
> Agreed. I'll look at making that change.
>
> > I have put it on my todo-list to go thr
> I haven't looked at the org.xbill.DNS.Address but it
> sounds like a good solution.
Agreed. I'll look at making that change.
> I have put it on my todo-list to go through the code and
> weed-out InetAddress, just haven't gotten around to it yet.
I just did:
$ grep --recursive "InetAddress\
On Friday 09 April 2004 17:12, Noel J. Bergman wrote:
> > My concern on this is that InetAddress caches successfull DNS
> > lookups forever (at least on default) and this strategy is not
> > very sound for a mailserver
>
> Good point, Søren. And that happens in InetAddress, but through
> contamina
> My concern on this is that InetAddress caches successfull DNS
> lookups forever (at least on default) and this strategy is not
> very sound for a mailserver
Good point, Søren. And that happens in InetAddress, but through
contamination with sun.* classes. It isn't pluggable. The is a comment i
Hi Noel,
My concern on this is that InetAddress caches successfull DNS lookups forever
(at least on default) and this strategy is not very sound for a mailserver,
as I happened to discover :-(
A possible (not optimal) solution is to set the security property
networkaddress.cache.ttl to someth
> I haven't looked at this code recently, but I guess this change
> might end the reliance upon the org.xbill jar. Do you know
> offhand if it does?
No, it does not. All that the change really does is revert to the same use
we made before the change to handle multi-homed hosts. We use the DNS t
Noel J. Bergman wrote:
The more important change in DNSServer was reverting to the previous
technique of using InetAddress.getAllByName to get the IP addresses for the
SMTP hosts, rather than the Type.A lookup.
I haven't looked at this code recently, but I guess this change might
end the reliance
I have modified getSMTPHostAddresses to call findMXRecords and then use the
Iterator from that collection. We could go back to using MxSorter (the
comment I just put in about being able to us MxSorter within findMXRecords
is wrong, since we don't ever see a Collection over which to iterate; we get
14 matches
Mail list logo
