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 Serge Sozonoff <se...@globalbeach.com> on 2003/01/02 16:00:16 UTC
[Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to neaten code in RemoteDelivery & more ....
Hi,
1.
The current release 1.3.1 of DnsJava fixes some bugs and also contains a
feature to auto detect the dns servers of the OS on which it is running.
"Currently, this works if either the appropriate properties are set, the OS
has a unix-like /etc/resolv.conf, or the system is Windows based with
ipconfig or winipcfg"
This is a nice to have that has been requested.
2.
There is a higher level DnsJava API we could make use of to neaten up the
code in RemoteDelivery.
3.
It might be worth having a discussion of the impact DnsJava could have on
the scalability of RemoteDelivery.
The ExtendedResolver in DnsJava uses several threads to do concurrent
lookups against the defined Dns servers. The first returned answer gets
used. Currently there is a hard coded limit of max 10 threads in DnsJava
which as far as I can tell we don't initialize to anything bigger in JAMES.
In theory this means that if RemoteDelivery is under heavy load things could
get held up on dns lookups.
I am not familiar enough with the DNS implementation in JNDI so I am not
sure how it works compared to DnsJava.
I will take a look at this.
I guess one of the main questions is, do we stick with DnsJava or do we use
the DNS service provider of the JNDI extension?
If we are leaning towards heavy use of JRE 1.4+, we would have the benefit
of the DNS service included.
One could also argue that we could write a test using both options to see
which is faster....
Thanks,
Serge
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Wednesday, January 01, 2003 10:15 PM
Subject: [V3] DNSJava / JNDI DNS Service Provider
> Serge,
>
> > FYI, DnsJava currently does [discovery], we are just not using it that
> way.
> > One of the things I had thought about for v3 and RemoteDelivery was to
> > clean up and do some work regarding DNS.
>
> Please submit a proposal. Depending upon the scope, perhaps it would make
> sense to roll some or all of that change into the v2 series as well.
>
> > I guess we will need a discussion as to the pros and cons for moving to
> the
> > JNDI [DNS] Service provider. Maybe we make the DNS service pluggable?
>
> It already is pluggable, and should certainly stay that way.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to neaten code in RemoteDelivery & more ....
Posted by Serge Knystautas <se...@lokitech.com>.
Serge,
Like Noel said, why don't we just upgrade dnsjava on the 2.1 branch
(actually both if it's not that hard), and then we can discuss whether for
3.0 we want to replace dnsjava with the JNDI DNS service.
I'd prefer to move to JNDI DNS long-term since unless there are things we
can do with dnsjava that we can't do with JNDI DNS, it seems like we might
as well leverage the code that's getting bundled with JDKs.
But in any case, +1 to upgrading libraries for now.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
Harmeet Bedi wrote:
> At the moment Serge S's code is working so it does not impede anyone. I
> could roll it back or one could apply additional improvements that Serge S
> sends. Let me know if you prefer rollback.
Yeah, I think it's functional and just has a design flaw (a static
reference or something), so I would just apply new patch(es) as they're
available.
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Serge Knystautas" <se...@lokitech.com>
> There was conversation on the list about it... the faults were pointed out
> and (other) Serge said he would go fix and send revised changes.
>..
> I don't think the library changes are in discussion. It's the code
changes
> that's in question.
Sorry I missed that. Too many emails....
At the moment Serge S's code is working so it does not impede anyone. I
could roll it back or one could apply additional improvements that Serge S
sends. Let me know if you prefer rollback.
I am in favor of applying additional patches as Serge sends as there is
already an improvement from the earlier iteration - cleaner code with
library upgraded and tested. Serge would prob. send patches to one class and
that should be easy to add on top.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
> From: "Serge Sozonoff" <se...@globalbeach.com>
> > Please hold off on the Commit of the DnsJava upgrade, I am still
> > cleaning/clearing up a few things with Noel and we should have a new
> version
>
> Sorry wasn't aware. I was concerned that your patch wasn't committed for a
> few days and there was no conversation about it on the list.
There was conversation on the list about it... the faults were pointed out
and (other) Serge said he would go fix and send revised changes. I'm not
sure what email reader you're using, but Mozilla or Outlook would let you
track threads pretty easily.
> Upgrade seems fine. I have tested the upgrade on James 2.1 and have been
> using upgraded DNS Java library on my mail servers for some time. (this
> email is through the same server)
I don't think the library changes are in discussion. It's the code changes
that's in question.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Sorry wasn't aware. I was concerned that your patch wasn't committed for a
> few days and there was no conversation about it on the list.
I don't know how you missed it. There were immediate replies to his post:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
.org&msgNo=6756
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
.org&msgNo=6762
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Serge Sozonoff" <se...@globalbeach.com>
> Please hold off on the Commit of the DnsJava upgrade, I am still
> cleaning/clearing up a few things with Noel and we should have a new
version
Sorry wasn't aware. I was concerned that your patch wasn't committed for a
few days and there was no conversation about it on the list.
Upgrade seems fine. I have tested the upgrade on James 2.1 and have been
using upgraded DNS Java library on my mail servers for some time. (this
email is through the same server)
I don't think dns lookups are broken atm but can be made better as you
submit another patch. One thing is that you may not need to set
ExtendedResolver. I believe it is the default Resolver.
From: "Serge Sozonoff" <se...@globalbeach.com>
> May I ask what the problem is with Wildcard imports? Is it simpley an
> estetical/readability issue?
Specific imports help readability. Number of committers have converted the
wildcard import to specific ones. Not a big deal. If you can do it that is
great.
From: "Serge Sozonoff" <se...@globalbeach.com>
> Are you suggesting that we remove the <authoritative> config option?
No, just trying to understand if anyone changes this config.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Serge Sozonoff <se...@globalbeach.com>.
Too late......
Sergei
----- Original Message -----
From: "Serge Sozonoff" <se...@globalbeach.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, January 19, 2003 10:14 AM
Subject: Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
> Hi Harmeet,
>
> Please hold off on the Commit of the DnsJava upgrade, I am still
> cleaning/clearing up a few things with Noel and we should have a new
version
> of the Patch in a couple of days.
>
> May I ask what the problem is with Wildcard imports? Is it simpley an
> estetical/readability issue?
>
> Are you suggesting that we remove the <authoritative> config option?
>
> Thanks, Sergei
>
> ----- Original Message -----
> From: "Harmeet Bedi" <ha...@kodemuse.com>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Saturday, January 18, 2003 8:22 PM
> Subject: Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
> Make use of higher level api
>
>
> > Looks good but a few minor things
> > - I don't think there is any need to change DNServer interface to return
a
> > list instead of collection. The results obtained are already sorted
> > according to priority and there is no need to do any more sorting. The
> > results returned are a collection of IP address so not sure what List to
> > collection does. Would prefer backward compatible API unless there is a
> real
> > gain.
> > - 'PriorityClass' instead of 'priorityClass' for class name.
> > - Avoid wildcard import.
> >
> > Will commit it later today unless someone gets to it before.
> >
> >
> > One general question. Do we ever need to do autoritative lookups for MX
> > record ? Wouldn't that slow up.
> >
> > Harmeet
> > ----- Original Message -----
> > From: "Serge Sozonoff" <se...@globalbeach.com>
> > To: "James Developers List" <ja...@jakarta.apache.org>
> > Sent: Wednesday, January 15, 2003 6:05 AM
> > Subject: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make
> > use of higher level api
> >
> >
> > > Hi All,
> > >
> > > Attached is a patch to upgrade to DnsJava 1.3.1
> > > The Patch also adds DNS Server autodetect, simplifys some code and
takes
> > > care of some TODO items.
> > >
> > > DnsJava brings several bug fixes, the ChangeLog can be found here
though
> > for
> > > some reason it only includes changes up
> > > until version 1.3.0 (http://www.xbill.org/dnsjava/Changelog)
> > >
> > > As fare as DNS autodetect goes, currently, this works if the OS has a
> > > unix-like /etc/resolv.conf, or the system is Windows based with
ipconfig
> > or
> > > winipcfg.
> > >
> > > I am a little mixed up with the exact way we intend to handle to 2.1
> > branch
> > > so this patch was made against HEAD.
> > >
> > > Thanks,
> > > Sergei
> > >
> > >
> > >
> >
> >
>
> --------------------------------------------------------------------------
> --
> > ----
> >
> >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Harmeet,
Please hold off on the Commit of the DnsJava upgrade, I am still
cleaning/clearing up a few things with Noel and we should have a new version
of the Patch in a couple of days.
May I ask what the problem is with Wildcard imports? Is it simpley an
estetical/readability issue?
Are you suggesting that we remove the <authoritative> config option?
Thanks, Sergei
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, January 18, 2003 8:22 PM
Subject: Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
> Looks good but a few minor things
> - I don't think there is any need to change DNServer interface to return a
> list instead of collection. The results obtained are already sorted
> according to priority and there is no need to do any more sorting. The
> results returned are a collection of IP address so not sure what List to
> collection does. Would prefer backward compatible API unless there is a
real
> gain.
> - 'PriorityClass' instead of 'priorityClass' for class name.
> - Avoid wildcard import.
>
> Will commit it later today unless someone gets to it before.
>
>
> One general question. Do we ever need to do autoritative lookups for MX
> record ? Wouldn't that slow up.
>
> Harmeet
> ----- Original Message -----
> From: "Serge Sozonoff" <se...@globalbeach.com>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Wednesday, January 15, 2003 6:05 AM
> Subject: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make
> use of higher level api
>
>
> > Hi All,
> >
> > Attached is a patch to upgrade to DnsJava 1.3.1
> > The Patch also adds DNS Server autodetect, simplifys some code and takes
> > care of some TODO items.
> >
> > DnsJava brings several bug fixes, the ChangeLog can be found here though
> for
> > some reason it only includes changes up
> > until version 1.3.0 (http://www.xbill.org/dnsjava/Changelog)
> >
> > As fare as DNS autodetect goes, currently, this works if the OS has a
> > unix-like /etc/resolv.conf, or the system is Windows based with ipconfig
> or
> > winipcfg.
> >
> > I am a little mixed up with the exact way we intend to handle to 2.1
> branch
> > so this patch was made against HEAD.
> >
> > Thanks,
> > Sergei
> >
> >
> >
>
>
> --------------------------------------------------------------------------
--
> ----
>
>
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Ok, we just don't agree on this. We're not making any progress, so
> let's just leave it as is.
I'm sure we'll get there eventually. I agree that we're spending more
cycles on this than it is worth right now.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> I understand that you want a contract that tells the client that the
> collection is ordered. The catch is that there is nothing in the Java
> Collection classes that exposes any notion of semantic ordering other than
> Comparator.
Ok, we just don't agree on this. We're not making any progress, so
let's just leave it as is.
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
Serge Knystautas wrote:
> Please let's just let this rest. There's no sense spending this much
> energy talking on this topic when there's code and documentation that
> everyone seems comfortable solving.
And to follow that, a community where everyone agrees isn't feasible...
(let's focus on where we do agree and build on that rather than go into
long diatribes on where we don't).
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
> I'm sorry you feel you had to write so much...
What? You think that Stephen McConnell should have the exclusive on long
messages? ;-) LOL
I just walked through the steps, since there seemed to be disagreement. The
simpler way to say it is just that List is a subset of Collection classes
that support ordering. It may be the only one that Java Collection provides
*today* that supports duplicates, but it isn't the only possible one. And I
don't want to cut off alternative choices when/if they might actually have a
benefit in the future.
> Sorry, don't mean to be a last word freak
<<shrug>> Someone's got to have it, might as well be you. And you're right.
We have other work to do. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Again, if someone can demonstrate the List methods that embody this presumed
> contract, I'm happy to listen. The fact that we don't use methods other
> than those found on Collection belies the necessity, in my view.
I'm sorry you feel you had to write so much... again I'm willing to
leave it as a Collection since you're so adamant on this point.
As to your last point, read the first line to List's JavaDocs... it says
it is an ordered Collection. To me as a Java developer, an ordered
Collection with duplicates is a List... that's all the Collection API
provides. I'm sorry, but I haven't heard a negative implication of
allowing index references.
Please let's just let this rest. There's no sense spending this much
energy talking on this topic when there's code and documentation that
everyone seems comfortable solving (sorry, don't mean to be a last word
freak).
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
> I'll say Iterator as it can allow for MX Records
> to be read on demand.
Elaborating a bit more on why this may be a good idea
- Usu. only one MX record is needed. Not sure why 2 would ever be needed if
mail can be sent to the first one.
- Most Domains have multiple Nameservers. No need to figure out all the MX
records from all the nameservers even for the first. It is not unusual for
one of the nameservers to be down.
- Most domains have either 1 MX record or have MX records with same
priority. So in most cases I think sorting/order doesn't achieve much.
- It usu. doesn't matter if you send to an MX address that has lower
priority as long as you can send email.
- James really does not need to reread the list of mx records so reset for
MX Record iteration may be useful but not needed atm.
Having said all this, I also have to say that this is not a matter that I
care too much about. All suggestions for the return type work for me.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my original patch
Posted by Harmeet Bedi <ha...@kodemuse.com>.
2 years back or so when I contributed my first patches, I think I was asked
or did both diff and full source.
I find full source is convenient and prefer that. Don't think there is any
need to have any hard and fast rules, if a contributor can submit source
good, otherwise good too.
Serge if you can submit source good, saves one step for the person adding it
in.
From: "Noel J. Bergman" <no...@devtech.com>
> Do you need help with patch? Danny and I know how to use the linux
version.
> I presume that Serge can tell you how to use a Windows version.
I don't think it is such a big deal. If you or Danny are around and want to
add the patch go ahead or I'll do it over the weekend if it has not been
done.
The patch seems pretty straight forward. Noel, what sort of help did you
have in mind ? version of what ?
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Thursday, January 23, 2003 11:38 PM
Subject: RE: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my original
patch
> > Serge, could you please post the modified DNSServer.java and
> > james-config.xml file.
>
> > It will be easier to apply the patch if you post these sources.
>
> See: http://james.apache.org/contribute.html
>
> Sergei followed the rules as we've asked. I remember Danny sending me a
> message in response to my first contribution asking just the opposite: I
> should post a diff, not send the code.
>
> Do you need help with patch? Danny and I know how to use the linux
version.
> I presume that Serge can tell you how to use a Windows version.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my original patch
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Serge, could you please post the modified DNSServer.java and
> james-config.xml file.
> It will be easier to apply the patch if you post these sources.
See: http://james.apache.org/contribute.html
Sergei followed the rules as we've asked. I remember Danny sending me a
message in response to my first contribution asking just the opposite: I
should post a diff, not send the code.
Do you need help with patch? Danny and I know how to use the linux version.
I presume that Serge can tell you how to use a Windows version.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my original patch
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Serge, could you please post the modified DNSServer.java and
james-config.xml file.
It will be easier to apply the patch if you post these sources.
thanks,
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my original patch
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sergei,
Thanks. I have applied this to the CVS, and updated the changelog document.
Also added you to the "we are" page. Those changes will appear next time we
re-publish the web site.
--- Noel
-----Original Message-----
From: Serge Sozonoff [mailto:serge@globalbeach.com]
Sent: Thursday, January 23, 2003 17:14
To: James Developers List
Subject: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my original
patch
Hi all,
This patch:
Upgrades to the just released DnsJava 1.3.2 :-)
Reverts some code back because the use of the static class dns was not a
good idea.
Adds an autodiscover config parameter so that dns server autodiscover can
be turned on/off
method findMXRecords() returns an unmodifiable Collection
Added some more logging
I have done some basic testing and everything seems to work well.
Thanks to Noel and others for the help/input on this.
Sergei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my original patch
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi all,
This patch:
Upgrades to the just released DnsJava 1.3.2 :-)
Reverts some code back because the use of the static class dns was not a
good idea.
Adds an autodiscover config parameter so that dns server autodiscover can
be turned on/off
method findMXRecords() returns an unmodifiable Collection
Added some more logging
I have done some basic testing and everything seems to work well.
Thanks to Noel and others for the help/input on this.
Sergei
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
> DNSSever block or implementation has returned a collection from the first
> checkin on 2.5 years back.
I know. I've pointed that out. The CVS lists Charles as the original
entry, but see that there was some CVS re-org that must have lost even
earlier changes.
> If you ask my vote today, I'll say Iterator as it can allow for MX Records
> to be read on demand.
> - Usu. only one MX record is needed. Not sure why 2 would ever be needed
if
mail can be sent to the first one.
I had thought of delayed resolution earlier, but realized that we are still
required to fetch all of the MX records so that we can sort by preference.
The only part that we could save would be resolution of multi-homing for
hosts that we don't need to resolve.
> - Most Domains have multiple Nameservers. No need to figure out all the MX
> records from all the nameservers even for the first. It is not unusual
for
> one of the nameservers to be down.
I don't believe that there is any requirement to check all name servers.
> - Most domains have either 1 MX record or have MX records with same
priority. So in most cases I think sorting/order doesn't achieve much.
PLEASE read the RFC! I quoted the section earlier. There *IS* an RFC
mandated requirement that MX records with the same preference be randomized.
> - It usu. doesn't matter if you send to an MX address that has lower
priority as long as you can send email.
Again, please read the RFC.
> - James really does not need to reread the list of mx records so reset for
> MX Record iteration may be useful but not needed atm.
Iterator doesn't have a reset() method, but it would be quite simple
(trivial) to create a ResetableIterator that would work with all Collection
classes.
At the moment, no one seems to have a compelling reason to change anything,
so we're leaving it as-is.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> Charles did the correct thing when he hid the implementation, and exposed
> the narrow interface.
Actually Serge choose Collection in the implementation, and I exposed it as
the narrow interface. Charles improved the implementation.
DNSSever block or implementation has returned a collection from the first
checkin on 2.5 years back.
If you ask my vote today, I'll say Iterator as it can allow for MX Records
to be read on demand. Collection or List or Array or SortedSet work for me
too. :-)
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
OK, let me back this up to First Principles. We ought to be able to agree
on the following points:
1. The semantic ordering required by RFC 2821 is mandatory.
2. The ordering is based upon any preference indicated by
the MX record.
3. There may be more than one entry with the same preference.
4. Ordering of records with the same preference is required
to be randomized.
[RFC 2821: "If there are multiple destinations with the
same preference and there is no clear reason to favor
one (e.g., by recognition of an easily-reached address),
then the sender-SMTP MUST randomize them to spread the
load across multiple mail exchangers for a specific
organization.]
5. There may be more than one IP address for a given host.
6. IP addresses for a given host must be tried in the order
presented.
[RFC 2821: "The destination host (perhaps taken from the
preferred MX record) may be multihomed, in which case
the domain name resolver will return a list of
alternative IP addresses. It is the responsibility of
the domain name resolver interface to have ordered this
list by decreasing preference if necessary, and SMTP
MUST try them in the order presented.
That is the contract mandated by RFC 2821, and it does required an order.
Hopefully we can also agree on another point:
7. One of the fundamental principles of object programming is
implementation hiding.
What does implementation hiding mean? It doesn't mean that the behavior of
a class is hidden. It means that the implementation of that behavior is
hidden. In this case, it is semantically important that the client be given
contents in a certain order, but how that order is computed or how it is
maintained should be opaque to the client.
The key issue here appears to be the entirely false premise that Collection
implies a lack of order, and the equally false premise that List implies
anything about order other than index.
If either of those false premises were true, we wouldn't be having this
argument.
I am presuming from the arguments presented that everyone is in favor of
strong typing. Fine. But this is also not an issue of strong vs weak
typing. Earlier Serge raised the issue of Object vs Collection, saying
(paraphrasing) that methods would just return Object if type didn't matter.
The difference is that we would need to cast from Object to a Collection,
but we don't need to cast from a Collection to a more specific type in order
to access the necessary behavior. If we never need to know anything about
an object other than that it IS an Object, then returning an Object would be
perfectly valid, because that interface provides the desired behavior.
Anything more specific that the interface that provides the necessary
behavior begins to violate the principle of implementation hiding.
INTERNALLY, as a matter of implementation, we receive an array from DNSJava,
and we sort that array with Array.sort. After that we create a Vector from
that array, and return the Collection. The Collection interface provides
the ability to get an Iterator, and iteration is the only behavior we allow
of a client. In fact, I am quite tempted to insert a call to
Collection.unmodifiableCollection() in our implementation.
But, you say, List provides order! It says so! This is a misinterpretation
of what List means by order. What List means by order is the ability to
manipulate the list by index. If our client code needed to manipulate the
results, having the ability to manipulate the order of the collection using
the index would be a compelling argument. But our clients only iterate.
Iteration is opaque. The whole point of an Iterator is implementation
hiding. Switching to List violates the principle of implementation hiding
by mandating that our iteration be index based. Furthermore it does not buy
us the benefit that people seem to believe that it would.
Look at the code as it exists today. Change the signature to return List,
and comment out the Array.sort call. You would have a List that is of no
value. You would have enforced nothing, nor implied that there is an
important semantic order was important.
Now, as for some specific comments:
> The salient fact is that a /contract/ accompanies the List interface.
> This contract is critical to our application and does _not_ accompany
> the Collection interface.
Please document the List-specific methods that embody this critical
contract.
> returning a list provides a degree of compile-time checking
> for adherence to our required contract, returning a
> Collection does not.
There is no such benefit, as indicated by my observation regarding the
removal of Array.sort in the code. From the perspective of the provider, we
must still document the semantic contract, and they must still implement it.
The client must still take the Iterator, and trust that it is in the correct
order. Therefore I consider this to be demonstrably false: returning a List
does not provide any useful degree of compile-time checking, and prevents
the use of any other Collection subclass that would provide the correct
behavior.
> Returning a Collection implies that any Collection could be substituted.
- Returning a Collection implies only that from the
perspective of the client the exposed behavior is
that of a Collection. Nothing more or less.
- Returning a List adds nothing more or less than
the presence an index ordered relationship between
elements. Exposing a List violates the principle of
implementation hiding unless the interface contract
requires index-based behavior.
Charles did the correct thing when he hid the implementation, and exposed
the narrow interface. If anything, the change that I might make would be to
change the return type from Collection to Iterator. Iteration is the only
permissible operation allowed to our client code, and the only reason for
our client code to have a Collection is to avoid having to rebuild the data
set in order to renew the Iterator. We should probably use
Collection.unmodifiableCollection() to enforce the immutable nature of the
provided contents.
Again, if someone can demonstrate the List methods that embody this presumed
contract, I'm happy to listen. The fact that we don't use methods other
than those found on Collection belies the necessity, in my view.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Posted by Aaron Knauf <ak...@xtra.co.nz>.
FWIW, I agree with Serge on this one. Returning a List implies that the
contents are ordered. (Which order is not specified, of course.)
Returning a Collection does not imply that.
Returning a SortedSet would imply that the contents are both ordered
*and* that there are no duplicates. The choice between these two
interfaces obviously comes down to whether or not we require uniqueness.
If your contention is that we should not preclude ourselves from
switching from List to SortedSet in future, then I believe that simply
indicates a lack of understanding of the requirements.
If the requirement is not known at this point, then deferring the
decision is a good choice, so the Collection should stay. If the
requirement is known, then we should choose the interface that most
closely matches the requirement.
If the requirement is that we be able to support either possibility,
then what we really need is an OrderedCollection interface, from which
both SortedSet and List derive. I do not believe that this is really
the case.
The fact that List provides no additional methods that we wish to use is
neither here nor there. The salient fact is that a /contract/
accompanies the List interface. This contract is critical to our
application and does _not_ accompany the Collection interface. Sure,
the current implementation does honour the required contract. It does
that only because the implementation class happens to be of a type that
does have that contract.
Returning a Collection implies that any Collection could be substituted.
This is not true. Returning a List implies that any List would do the
job. This *is* true!
The more of our contract that is designed into place, as opposed to just
documented into place, the better.
At the end of the day, returning a list provides a degree of
compile-time checking for adherence to our required contract, returning
a Collection does not. Sure, it would be better still to have checking
for the ordering criteria too, but the cost/benefit ratio of providing
this does not stack up.
Cheers
ADK
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I understand, and I am all for meaningful contracts. My point is that a
> > Java Collection is not unordered. It can be either ordered or
unordered,
> > based upon the implementation class.
> Yes, this is my point... we should not leave it up to the implementation
> as to whether it is ordered or not.
> Since the MX record query produce an ordered set of IP addresses,
> I'm saying the interface should return an ordered collection.
I understand that you want a contract that tells the client that the
collection is ordered. The catch is that there is nothing in the Java
Collection classes that exposes any notion of semantic ordering other than
Comparator.
When accessing a Java Collection, there are only two possible orders:
Iterator and/or index. What the List hierarchy introduces is an index.
Being given a List only means is that you have an index with which to
manipulate or examine the List. From the presence of an index are derived
additional behaviors such as backwards iteration, insertion at an index,
etc., all of which are based upon the index, not the data. None of those
behaviors are necessary for our code. All that we care about is that there
is an appropriate semantic order provided by the Iterator. No other
ordering is exposed as an interface contract to a client anywhere in Java.
A client accepts the ordering provided by the Interator, and that behavior
is deliberately opaque to the client.
As a client of the DNS, I just want to be told that when I iterate over the
entries, that they will be in an MX priority order. Getting a List as
opposed to a Collection does not provide me with that semantic. List does
not introduce a semantically useful Iterator order, unless you consider the
index within the list to be the desired semantic. The fact that it is in
some useful order is because the code that creates the Collection, prepares
it with an order, and returns an object that will preserve that order. It
could be a List or any other type of Collection that provides the order
during iteration.
List is only one of the ordered collection types. So long as the MX record
query returns a priority ordered collection, I don't care what
implementation type is used. And there is no interface contract that
describes the desire. Nor is there anything I can do with the data once
retrieved, because all that I have are the target host strings. Any data by
which the client could ensure the result has been discarded.
Now, if you say that the index is useful by itself, or if you say that you
want the client to be able to re-sort the contents, then we have a different
discussion. But if all that we're trying to do is provide a strongly typed
interface contract to the client that says this is an ordered collection,
then I hope I've shown why List doesn't accomplish that task.
By adopting List, all that we'd be exposing to the client is that the
Collection has an index, which the client would never use. We would not be
saying anything about the semantic order, we've discared the data that would
allow the client to enforce or verify it, and we'd be precluding our ability
to use another type of ordered collection in the future.
The underlying DNS code returns an array of records. Currently we convert
that to a Vector of target host names as String objects, discarding all
else. We might, at some point, change or enhance the interface to return a
collection of MX records sorted by priority. We could easily implement a
non-indexed sorted Collection that allows duplicates. We already have the
Comparator in our code. But if we were to replace one collection
implementation with another in the future, we'd have to change the method
interface unless we kept it as Collection. So I don't see why keeping it as
Collection is considered a problem (note: it always has been a Collection
from the first instance of the code), and I do see an issue with adopting
List.
If I am missing something, I'm sure that you'll explain.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> If the question is whether the interface should change, there ought to be
> reasons. So far, I have not seen any was my point.
Ok, I just meant that you can't reference the implementation if we're
talking interfaces.
> I understand, and I am all for meaningful contracts. My point is that a
> Java Collection is not unordered. It can be either ordered or unordered,
> based upon the implementation class.
Yes, this is my point... we should not leave it up to the implementation
as to whether it is ordered or not.
Agreed, a Collection is ordered or unordered. And a List is, "An
ordered collection (also known as a sequence)" as you quoted from the
javadocs. Since the MX record query produce an ordered set of IP
addresses, I'm saying the interface should return an ordered collection.
> The ListIterator also adds backwards traversal, list mutators, and index
> operations.
Backwards trasversal is a consequence of having order. Mutators also
are a consequence of order. Index operations are a consequence of
having order while allowing duplicates.
> None of these List behaviors are necessary parts of the client contract we
> need to expose as far as I can see. All that we require is that the
> elements be ordered according to our application (RFC) defined scheme. But
> by changing the interface to a List, we preclude the ability to use any
> other type of ordered collection.
The only other ordered collections I know of aside from List is the
SortedSet. If we can determine whether we need to allow duplicates, we
can choose one or the other. I'm not looking to enable methods that
shouldn't be allowed on this result, but for the same reason that we
return a Collection instead of an Object, if we have certain
characteristics that we know should be present in the result, we should
pick the appropriate interface.
> I hope I am clearer now.
Yes, and I hope I am as well.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The question is whether the interface should change, and
> you're talking about how the underlying implementation behaves.
If the question is whether the interface should change, there ought to be
reasons. So far, I have not seen any was my point.
> The reason to change the interface is that MX Records have an ordering,
> so the interface that returns a IP addresses based on MX records should
> return something that indicates that this is ordered. Right now our
> interface does not indicate it is ordered.
I understand, and I am all for meaningful contracts. My point is that a
Java Collection is not unordered. It can be either ordered or unordered,
based upon the implementation class.
Java does not have an explicit Collection that uniquely says "I am ordered."
The List class is not the base of all ordered collection classes. There are
other ordered collections. List is the base of a particular type of ordered
collection classes, all of which share additional behaviors. As per the
List javadoc:
* An ordered collection (also known as a <i>sequence</i>). The user of
this
* interface has precise control over where in the list each element is
* inserted. The user can access elements by their integer index (position
in
* the list), and search for elements in the list.<p>
The ListIterator also adds backwards traversal, list mutators, and index
operations.
None of these List behaviors are necessary parts of the client contract we
need to expose as far as I can see. All that we require is that the
elements be ordered according to our application (RFC) defined scheme. But
by changing the interface to a List, we preclude the ability to use any
other type of ordered collection.
I hope I am clearer now.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>Change from Collection->List sounds good to me. Will go ahead and make
>
> this
>
>>change in a day or two unless someone objects or gets to it sooner.
>
>
> The method returns a Collection of servers. At the time when we use the
> Collection, all that we can know, without changing the content of the
> Collection, is the order and value of the elements. Each Collection class
> provides its own Iterator type. If the actual Collection is sorted, the
> order is not lost; the underlying object is still the same. Any decision
> about sorting can be done within the method when it decides which subclass
> of Collection to return.
>
> In this case, we use a Vector. Vector is an AbstractList, and the provided
> Iterator iterates through the contents in order. If there is any sorting to
> do, we can do it before returning the Vector. When we use the Collection in
> RemoteDelivery, for example, we get an Iterator from the Collection, and use
> it:
>
> Iterator i = targetServers.iterator();
>
> I haven't seen anyone provide a justification to change the current
> interface. Whatever policy we want to manage the MX records can be handled
> by the current interface, from what I've seen.
Well, you're using a straw man argument IMHO. The question is whether
the interface should change, and you're talking about how the underlying
implementation behaves.
The reason to change the interface is that MX Records have an ordering,
so the interface that returns a IP addresses based on MX records should
return something that indicates that this is ordered. Right now our
interface does not indicate it is ordered. Sure, we are *implementing*
the ordering, but the interface isn't accurate and hence needs to be
changed.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Change from Collection->List sounds good to me. Will go ahead and make
this
> change in a day or two unless someone objects or gets to it sooner.
The method returns a Collection of servers. At the time when we use the
Collection, all that we can know, without changing the content of the
Collection, is the order and value of the elements. Each Collection class
provides its own Iterator type. If the actual Collection is sorted, the
order is not lost; the underlying object is still the same. Any decision
about sorting can be done within the method when it decides which subclass
of Collection to return.
In this case, we use a Vector. Vector is an AbstractList, and the provided
Iterator iterates through the contents in order. If there is any sorting to
do, we can do it before returning the Vector. When we use the Collection in
RemoteDelivery, for example, we get an Iterator from the Collection, and use
it:
Iterator i = targetServers.iterator();
I haven't seen anyone provide a justification to change the current
interface. Whatever policy we want to manage the MX records can be handled
by the current interface, from what I've seen.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Regd: Collection vs. List in DNSServer and MailetContext.
Change from Collection->List sounds good to me. Will go ahead and make this
change in a day or two unless someone objects or gets to it sooner.
Regd: autoritative dns lookup option in config.xml
From: "Serge Knystautas" <se...@lokitech.com>
> Ok, so we're leaving it as is?
I think it is a good config option. I am only interested in knowing how
folks use this. If anyone changes this flag, I would be curious to know the
use case.
Harmeet
----- Original Message -----
From: "Serge Knystautas" <se...@lokitech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, January 19, 2003 1:42 PM
Subject: Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
> ----- Original Message -----
> From: "Harmeet Bedi" <ha...@kodemuse.com>
>
>
> > DNSServer block returs a sorted collection now and has been from the
first
> > instance of the block. One could loose ordering in a collection but
> > converting to list does not help as list is a collection. Iterator may
be
> > the best to express the idea of order.
>
> err, a Collection is unordered, and a List is an *ordered* Collection.
Yes,
> a List is a Collection, differentiated by the exact attribute we want...
> ordering. An Iterator would restrict how you could use the result.
>
> > Sorting is the responsibility of DNSServer implementation not the user
of
> > API. The collection returns MX Records sorted by priority. Remote
Delivery
> > gets hold of and collection through mailet context(o.a.j.James),
converts
> to
> > an iterator and attempts to send email to the first mail server address
> than
> > second if first fails and so on. The only 2 methods called on Collection
> are
> > Collection::size and Collection::iterator.
>
> Right, and on a Collection, iterator is not guaranteeing an order.
>
> > Converting to a List will not really help as the returned
collection/list
> > contains only contains the IP address. There is not enough context like
> > priority in the returned collection/list to allow the user of the API to
> > effectively sort on.
>
> The DNS server needs to return the List... it *will* know the correct
order
> to put the IP addresses in. Yes, we cannot later convert it to a List and
> expect it to create an order, which I why I think the DNS server should
> return a List. If it is already, that's great.
>
> > /**
> > * Returns a Collection of Strings of hostnames or ip addresses that
> > * are specified as mail server listeners for the given hostname.
> > * This is done using MX records, and the hostnames or ip addresses
> > * are returned sorted by MX priority.
> > *
> > * @param host - the domain name for which to find mail servers
> > * @return a Collection of Strings of hostnames, sorted by priority
> > */
> > Collection getMailServers(String host);
>
> Yes ok, so this should be changed... getMailServers(String host) should
> return a List because those IP addresses should be ordered by the
underlying
> implementation.
>
> > > I thought there was a conf option for whether to do authoritative
> lookups,
> > > no?
> >
> > Yes it does and it seems good to have the config option.
> > The default is false and that is probably the better option. I am not
> > suggesting the config option should be removed but curious if folks ever
> > change the authoritative lookup setting.
>
> Ok, so we're leaving it as is?
>
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
> DNSServer block returs a sorted collection now and has been from the first
> instance of the block. One could loose ordering in a collection but
> converting to list does not help as list is a collection. Iterator may be
> the best to express the idea of order.
err, a Collection is unordered, and a List is an *ordered* Collection. Yes,
a List is a Collection, differentiated by the exact attribute we want...
ordering. An Iterator would restrict how you could use the result.
> Sorting is the responsibility of DNSServer implementation not the user of
> API. The collection returns MX Records sorted by priority. Remote Delivery
> gets hold of and collection through mailet context(o.a.j.James), converts
to
> an iterator and attempts to send email to the first mail server address
than
> second if first fails and so on. The only 2 methods called on Collection
are
> Collection::size and Collection::iterator.
Right, and on a Collection, iterator is not guaranteeing an order.
> Converting to a List will not really help as the returned collection/list
> contains only contains the IP address. There is not enough context like
> priority in the returned collection/list to allow the user of the API to
> effectively sort on.
The DNS server needs to return the List... it *will* know the correct order
to put the IP addresses in. Yes, we cannot later convert it to a List and
expect it to create an order, which I why I think the DNS server should
return a List. If it is already, that's great.
> /**
> * Returns a Collection of Strings of hostnames or ip addresses that
> * are specified as mail server listeners for the given hostname.
> * This is done using MX records, and the hostnames or ip addresses
> * are returned sorted by MX priority.
> *
> * @param host - the domain name for which to find mail servers
> * @return a Collection of Strings of hostnames, sorted by priority
> */
> Collection getMailServers(String host);
Yes ok, so this should be changed... getMailServers(String host) should
return a List because those IP addresses should be ordered by the underlying
implementation.
> > I thought there was a conf option for whether to do authoritative
lookups,
> > no?
>
> Yes it does and it seems good to have the config option.
> The default is false and that is probably the better option. I am not
> suggesting the config option should be removed but curious if folks ever
> change the authoritative lookup setting.
Ok, so we're leaving it as is?
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Harmeet Bedi <ha...@kodemuse.com>.
---- Original Message -----
From: "Serge Knystautas" <se...@lokitech.com>
.. DNSServer API
>
> Are you saying it's returning a Collection right now? If it is, then it
> should be returned as a List. MX records have an order, and if we put the
> results in a Collection, it seems that we risk losing the ordering,
doesn't
> it?
DNSServer block returs a sorted collection now and has been from the first
instance of the block. One could loose ordering in a collection but
converting to list does not help as list is a collection. Iterator may be
the best to express the idea of order.
Sorting is the responsibility of DNSServer implementation not the user of
API. The collection returns MX Records sorted by priority. Remote Delivery
gets hold of and collection through mailet context(o.a.j.James), converts to
an iterator and attempts to send email to the first mail server address than
second if first fails and so on. The only 2 methods called on Collection are
Collection::size and Collection::iterator.
Converting to a List will not really help as the returned collection/list
contains only contains the IP address. There is not enough context like
priority in the returned collection/list to allow the user of the API to
effectively sort on.
I think it may be better to narrow the API to use Iterator rather than
broadening to use List and taking the sorting responsibility out of the
DNSServer implementation.
Having said all this, it doesn't really matter. The returned collection can
be cast to a List. But to expose List instead of Collection effectively,
would also mean the MailetContext API will need to expose List not
Collection. At present MailetContext exposes
/**
* Returns a Collection of Strings of hostnames or ip addresses that
* are specified as mail server listeners for the given hostname.
* This is done using MX records, and the hostnames or ip addresses
* are returned sorted by MX priority.
*
* @param host - the domain name for which to find mail servers
* @return a Collection of Strings of hostnames, sorted by priority
*/
Collection getMailServers(String host);
This API wraps call to DNSServer:findMXRecords.
>
> > One general question. Do we ever need to do autoritative lookups for MX
> > record ? Wouldn't that slow up.
>
> I thought there was a conf option for whether to do authoritative lookups,
> no?
Yes it does and it seems good to have the config option.
The default is false and that is probably the better option. I am not
suggesting the config option should be removed but curious if folks ever
change the authoritative lookup setting.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
> Looks good but a few minor things
> - I don't think there is any need to change DNServer interface to return a
> list instead of collection. The results obtained are already sorted
> according to priority and there is no need to do any more sorting. The
> results returned are a collection of IP address so not sure what List to
> collection does. Would prefer backward compatible API unless there is a
real
> gain.
Are you saying it's returning a Collection right now? If it is, then it
should be returned as a List. MX records have an order, and if we put the
results in a Collection, it seems that we risk losing the ordering, doesn't
it?
> One general question. Do we ever need to do autoritative lookups for MX
> record ? Wouldn't that slow up.
I thought there was a conf option for whether to do authoritative lookups,
no?
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Looks good but a few minor things
- I don't think there is any need to change DNServer interface to return a
list instead of collection. The results obtained are already sorted
according to priority and there is no need to do any more sorting. The
results returned are a collection of IP address so not sure what List to
collection does. Would prefer backward compatible API unless there is a real
gain.
- 'PriorityClass' instead of 'priorityClass' for class name.
- Avoid wildcard import.
Will commit it later today unless someone gets to it before.
One general question. Do we ever need to do autoritative lookups for MX
record ? Wouldn't that slow up.
Harmeet
----- Original Message -----
From: "Serge Sozonoff" <se...@globalbeach.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Wednesday, January 15, 2003 6:05 AM
Subject: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make
use of higher level api
> Hi All,
>
> Attached is a patch to upgrade to DnsJava 1.3.1
> The Patch also adds DNS Server autodetect, simplifys some code and takes
> care of some TODO items.
>
> DnsJava brings several bug fixes, the ChangeLog can be found here though
for
> some reason it only includes changes up
> until version 1.3.0 (http://www.xbill.org/dnsjava/Changelog)
>
> As fare as DNS autodetect goes, currently, this works if the OS has a
> unix-like /etc/resolv.conf, or the system is Windows based with ipconfig
or
> winipcfg.
>
> I am a little mixed up with the exact way we intend to handle to 2.1
branch
> so this patch was made against HEAD.
>
> Thanks,
> Sergei
>
>
>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> Serge,
>
> Would you please revise your patch not to use the static dns class? The use
> of a static class in that fashion is OK for a standalone application, but
> I'd like to avoid that in a component architecture. There isn't a
> contractual guarantee that a component installed by some admin might not
> also try to use DnsJava.
Yup, good catch. That's why Avalon uses Inversion of Control, so that
components are given to the utilizers, so that static accessors are not
needed. :-D
(Nicola Ken, doing some coaching ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Danny Angus <da...@apache.org>.
> Go ahead and do it against the HEAD. If we decide to merge it into v2.1,
> we'll worry about it then. :-)
I'm running two instances of the HEAD one for my personal use and one for work, so I will be able to give you some independant (sort of) feedback.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
Would you please revise your patch not to use the static dns class? The use
of a static class in that fashion is OK for a standalone application, but
I'd like to avoid that in a component architecture. There isn't a
contractual guarantee that a component installed by some admin might not
also try to use DnsJava.
Go ahead and do it against the HEAD. If we decide to merge it into v2.1,
we'll worry about it then. :-)
--- Noel
-----Original Message-----
From: Serge Sozonoff [mailto:serge@globalbeach.com]
Sent: Wednesday, January 15, 2003 9:05
To: James Developers List
Subject: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,
Make use of higher level api
Hi All,
Attached is a patch to upgrade to DnsJava 1.3.1
The Patch also adds DNS Server autodetect, simplifys some code and takes
care of some TODO items.
DnsJava brings several bug fixes, the ChangeLog can be found here though for
some reason it only includes changes up
until version 1.3.0 (http://www.xbill.org/dnsjava/Changelog)
As fare as DNS autodetect goes, currently, this works if the OS has a
unix-like /etc/resolv.conf, or the system is Windows based with ipconfig or
winipcfg.
I am a little mixed up with the exact way we intend to handle to 2.1 branch
so this patch was made against HEAD.
Thanks,
Sergei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi All,
Attached is a patch to upgrade to DnsJava 1.3.1
The Patch also adds DNS Server autodetect, simplifys some code and takes
care of some TODO items.
DnsJava brings several bug fixes, the ChangeLog can be found here though for
some reason it only includes changes up
until version 1.3.0 (http://www.xbill.org/dnsjava/Changelog)
As fare as DNS autodetect goes, currently, this works if the OS has a
unix-like /etc/resolv.conf, or the system is Windows based with ipconfig or
winipcfg.
I am a little mixed up with the exact way we intend to handle to 2.1 branch
so this patch was made against HEAD.
Thanks,
Sergei
Re: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to neaten code in RemoteDelivery & more ....
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi,
> Do you want to look into doing those changes?
OK
Sergei
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Friday, January 03, 2003 9:47 PM
Subject: RE: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to
neaten code in RemoteDelivery & more ....
> Serge,
>
> From the sound of it, why don't we start by upgrading the v2.1 branch with
> the new DnsJava, and some of your updates, since it sounds from what you
are
> saying that it is all API compatible.
>
> Sounds as if we'd get some immediate benefits from it, and could get some
> good experience with it.
>
> Do you want to look into doing those changes?
>
> --- Noel
>
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: Thursday, January 02, 2003 10:00
> To: James Developers List
> Subject: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to
> neaten code in RemoteDelivery & more ....
>
>
> Hi,
>
> 1.
> The current release 1.3.1 of DnsJava fixes some bugs and also contains a
> feature to auto detect the dns servers of the OS on which it is running.
> "Currently, this works if either the appropriate properties are set, the
OS
> has a unix-like /etc/resolv.conf, or the system is Windows based with
> ipconfig or winipcfg"
> This is a nice to have that has been requested.
>
> 2.
> There is a higher level DnsJava API we could make use of to neaten up the
> code in RemoteDelivery.
>
> 3.
> It might be worth having a discussion of the impact DnsJava could have on
> the scalability of RemoteDelivery.
>
> The ExtendedResolver in DnsJava uses several threads to do concurrent
> lookups against the defined Dns servers. The first returned answer gets
> used. Currently there is a hard coded limit of max 10 threads in DnsJava
> which as far as I can tell we don't initialize to anything bigger in
JAMES.
> In theory this means that if RemoteDelivery is under heavy load things
could
> get held up on dns lookups.
>
> I am not familiar enough with the DNS implementation in JNDI so I am not
> sure how it works compared to DnsJava.
> I will take a look at this.
>
> I guess one of the main questions is, do we stick with DnsJava or do we
use
> the DNS service provider of the JNDI extension?
> If we are leaning towards heavy use of JRE 1.4+, we would have the benefit
> of the DNS service included.
>
> One could also argue that we could write a test using both options to see
> which is faster....
>
>
> Thanks,
> Serge
>
> ----- Original Message -----
> From: "Noel J. Bergman" <no...@devtech.com>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Wednesday, January 01, 2003 10:15 PM
> Subject: [V3] DNSJava / JNDI DNS Service Provider
>
>
> > Serge,
> >
> > > FYI, DnsJava currently does [discovery], we are just not using it that
> > way.
> > > One of the things I had thought about for v3 and RemoteDelivery was to
> > > clean up and do some work regarding DNS.
> >
> > Please submit a proposal. Depending upon the scope, perhaps it would
make
> > sense to roll some or all of that change into the v2 series as well.
> >
> > > I guess we will need a discussion as to the pros and cons for moving
to
> > the
> > > JNDI [DNS] Service provider. Maybe we make the DNS service pluggable?
> >
> > It already is pluggable, and should certainly stay that way.
> >
> > --- Noel
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Upgrade to JavaMail 1.3
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Serge Sozonoff" <se...@globalbeach.com>
> I propose that we upgrade to JavaMail 1.3 in order to benefit from the
many
> bug fixes this release has.
+1
I have done some simple testing(replace jar, send msgs) with Java Mail 1.3
and it seems to stand up.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to JavaMail 1.3
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I propose that we upgrade to JavaMail 1.3 in order to benefit from the
many
> bug fixes this release has.
On the list of things to do. Since I, personally, haven't tested it I was
going to wait until next week when I am in the office to test first. But
there is no reason why Danny, who has tested it, can't apply it to the CVS
right away.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Updating both branches
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > What is the appropriate method for updating both branches?
> Commit to one, commit to the other...
Well, OK. I was thinking that I would need to commit to one, and then merge
that commit into the other.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating both branches
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> +1 (yes, I'd apply [DnsJava update] to both branches)
>
>
> What is the appropriate method for updating both branches? I see that
> JavaMail was updated only in HEAD, and we want that in both branches, too.
> Plus, I also need to update KEYS and add README.html and HEADER.html to the
> CVS.
>
> --- Noel
Commit to one, commit to the other...
CVS's basic features lead to simple workflow. :)
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating both branches
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> I think change the HEAD and merge into the branch.
> or add to HEAD and then branch the new file with the same branch name.
> But thats just an informed guess, someone else may have a firmer grasp..
>
> d.
For binary files and most of the changes we're making now, we don't
really need to merge. As long as we can continue to do this, the
better. If we really get into this, I would suggest we push for a
release of HEAD as 2.2 or an early non-contentious 3.x release and
branch again for another stabilization.
But if you need to merge, here are two excerpts from a CVS guide:
--------------------------------------------------------------------------
Merging an entire branch
You can merge changes made on a branch into your working copy by giving
the -j branch flag to the update command. With one -j branch option it
merges the changes made between the point where the branch forked and
newest revision on that branch (into your working copy).
The -j stands for "join".
Consider this revision tree:
+-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+
!
!
! +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+---------+ +---------+
The branch 1.2.2 has been given the tag (symbolic name) R1fix. The
following example assumes that the module mod contains only one file, m.c.
$ cvs checkout mod # Retrieve the latest revision, 1.4
$ cvs update -j R1fix m.c # Merge all changes made on the branch,
# i.e. the changes between revision 1.2
# and 1.2.2.2, into your working copy
# of the file.
$ cvs commit -m "Included R1fix" # Create revision 1.5.
A conflict can result from a merge operation. If that happens, you
should resolve it before committing the new revision. See Conflicts
example.
The checkout command also supports the -j branch flag. The same effect
as above could be achieved with this:
$ cvs checkout -j R1fix mod
$ cvs commit -m "Included R1fix"
--------------------------------------------------------------------------
Merging from a branch several times
Continuing our example, the revision tree now looks like this:
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
! +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+---------+ +---------+
where the starred line represents the merge from the R1fix branch to the
main trunk, as just discussed.
Now suppose that development continues on the R1fix branch:
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
! +---------+ +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
+---------+ +---------+ +---------+
and then you want to merge those new changes onto the main trunk. If
you just use the cvs update -j R1fix m.c command again, CVS will attempt
to merge again the changes which you have already merged, which can have
undesirable side effects.
So instead you need to specify that you only want to merge the changes
on the branch which have not yet been merged into the trunk. To do that
you specify two -j options, and CVS merges the changes from the first
revision to the second revision. For example, in this case the simplest
way would be
cvs update -j 1.2.2.2 -j R1fix m.c # Merge changes from 1.2.2.2 to the
# head of the R1fix branch
The problem with this is that you need to specify the 1.2.2.2 revision
manually. A slightly better approach might be to use the date the last
merge was done:
cvs update -j R1fix:yesterday -j R1fix m.c
Better yet, tag the R1fix branch after every merge into the trunk, and
then use that tag for subsequent merges:
cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Updating both branches
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
OK. I can work it out, but if you have some sample CVS commands I'd prefer
not to experiment on our live CVS. :-)
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Tuesday, January 07, 2003 17:45
To: James Developers List
Subject: RE: Updating both branches
I think change the HEAD and merge into the branch.
or add to HEAD and then branch the new file with the same branch name.
But thats just an informed guess, someone else may have a firmer grasp..
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 07 January 2003 21:48
> To: James Developers List
> Subject: Updating both branches
>
>
> > +1 (yes, I'd apply [DnsJava update] to both branches)
>
> What is the appropriate method for updating both branches? I see that
> JavaMail was updated only in HEAD, and we want that in both branches, too.
> Plus, I also need to update KEYS and add README.html and
> HEADER.html to the
> CVS.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Updating both branches
Posted by Danny Angus <da...@apache.org>.
I think change the HEAD and merge into the branch.
or add to HEAD and then branch the new file with the same branch name.
But thats just an informed guess, someone else may have a firmer grasp..
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 07 January 2003 21:48
> To: James Developers List
> Subject: Updating both branches
>
>
> > +1 (yes, I'd apply [DnsJava update] to both branches)
>
> What is the appropriate method for updating both branches? I see that
> JavaMail was updated only in HEAD, and we want that in both branches, too.
> Plus, I also need to update KEYS and add README.html and
> HEADER.html to the
> CVS.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Updating both branches
Posted by "Noel J. Bergman" <no...@devtech.com>.
> +1 (yes, I'd apply [DnsJava update] to both branches)
What is the appropriate method for updating both branches? I see that
JavaMail was updated only in HEAD, and we want that in both branches, too.
Plus, I also need to update KEYS and add README.html and HEADER.html to the
CVS.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Upgrade to JavaMail 1.3
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Jason Webb" <jw...@inovem.com>
> We already use JavaMail 1.3 with James. JM 1.2 had way too many MIME bugs
in
> it.
> I've tested James (and our MLM code) with over 100K messages and found no
> serious problems with it. The test messages were taken from mbox archives
> off other mailing lists so have a variety of mail clients (and their
> encodings).
+1 (yes, I'd apply to both branches)
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to JavaMail 1.3
Posted by "Noel J. Bergman" <no...@devtech.com>.
None at all. I would expect them to be in both. Until we start working on
things that are specific to v3 (e.g., the Mailet API changes), there really
isn't much to branch. What is the best approach to get them into both?
Apply to v2.1 branch and merge into HEAD?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to JavaMail 1.3
Posted by Danny Angus <da...@apache.org>.
I have used it too, and no probs.
I can see no reason why these (javamail and dns) changes need be limited to
only the 2.1 branch and not applied to the HEAD too.
Can anyone?
d.
> We already use JavaMail 1.3 with James. JM 1.2 had way too many
> MIME bugs in
> it.
Yes hasn't it!
> I've tested James (and our MLM code) with over 100K messages and found no
> serious problems with it. The test messages were taken from mbox archives
> off other mailing lists so have a variety of mail clients (and their
> encodings).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to JavaMail 1.3
Posted by Jason Webb <jw...@inovem.com>.
We already use JavaMail 1.3 with James. JM 1.2 had way too many MIME bugs in
it.
I've tested James (and our MLM code) with over 100K messages and found no
serious problems with it. The test messages were taken from mbox archives
off other mailing lists so have a variety of mail clients (and their
encodings).
No worries :)
-- Jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Upgrade to JavaMail 1.3
Posted by Serge Sozonoff <se...@globalbeach.com>.
All,
I propose that we upgrade to JavaMail 1.3 in order to benefit from the many
bug fixes this release has.
We can do this for the 2.1 branch first.
Sergei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to neaten code in RemoteDelivery & more ....
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
>From the sound of it, why don't we start by upgrading the v2.1 branch with
the new DnsJava, and some of your updates, since it sounds from what you are
saying that it is all API compatible.
Sounds as if we'd get some immediate benefits from it, and could get some
good experience with it.
Do you want to look into doing those changes?
--- Noel
-----Original Message-----
From: Serge Sozonoff [mailto:serge@globalbeach.com]
Sent: Thursday, January 02, 2003 10:00
To: James Developers List
Subject: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to
neaten code in RemoteDelivery & more ....
Hi,
1.
The current release 1.3.1 of DnsJava fixes some bugs and also contains a
feature to auto detect the dns servers of the OS on which it is running.
"Currently, this works if either the appropriate properties are set, the OS
has a unix-like /etc/resolv.conf, or the system is Windows based with
ipconfig or winipcfg"
This is a nice to have that has been requested.
2.
There is a higher level DnsJava API we could make use of to neaten up the
code in RemoteDelivery.
3.
It might be worth having a discussion of the impact DnsJava could have on
the scalability of RemoteDelivery.
The ExtendedResolver in DnsJava uses several threads to do concurrent
lookups against the defined Dns servers. The first returned answer gets
used. Currently there is a hard coded limit of max 10 threads in DnsJava
which as far as I can tell we don't initialize to anything bigger in JAMES.
In theory this means that if RemoteDelivery is under heavy load things could
get held up on dns lookups.
I am not familiar enough with the DNS implementation in JNDI so I am not
sure how it works compared to DnsJava.
I will take a look at this.
I guess one of the main questions is, do we stick with DnsJava or do we use
the DNS service provider of the JNDI extension?
If we are leaning towards heavy use of JRE 1.4+, we would have the benefit
of the DNS service included.
One could also argue that we could write a test using both options to see
which is faster....
Thanks,
Serge
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Wednesday, January 01, 2003 10:15 PM
Subject: [V3] DNSJava / JNDI DNS Service Provider
> Serge,
>
> > FYI, DnsJava currently does [discovery], we are just not using it that
> way.
> > One of the things I had thought about for v3 and RemoteDelivery was to
> > clean up and do some work regarding DNS.
>
> Please submit a proposal. Depending upon the scope, perhaps it would make
> sense to roll some or all of that change into the v2 series as well.
>
> > I guess we will need a discussion as to the pros and cons for moving to
> the
> > JNDI [DNS] Service provider. Maybe we make the DNS service pluggable?
>
> It already is pluggable, and should certainly stay that way.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>