What I don't like of the current approach is the static methods in the
DNSServer (class) called from around the rest of James.
DNSServer (interface) is the interface for our service. DSNServer
(class) is an implementation and should not be referenced/used around
the code: every other components that need to use
DNSServer(implementation) code should do that lookingup the DNSServer
service and calling non-static methods.
If we don't remove the static methods then I would prefer to move
towards the SPI approach and remove the hard-dependency between
DNSServer (class) and other james components.
Stefano
Steve Brewin wrote:
I thought we had already gone the spi approach, or at least had
considered it at one point. I thought there was some issue with
different results, but I don't remember any specifics.
It isn't clear from a quick search of http://www.dnsjava.org, but I believe
that the spi capability was added in v2. We first switched when it was at
v1.
Shame really, as we now have explicit dependencies on the dnsjava packages
and have added some workarounds in parts to accomodate the specifics of
dnsjava's behaviour. It would be good to revert to the SPI approach for V3,
but for V2 its too late and too hard to gauge how many workarounds would
need to be undone.
In terms of caching, is there a way we can make this configurable,
i.e., how does the dnsjava Cache get instantiated? Is it static, or
is there a singleton we create somewhere to handle this? If we
instantiate the singleton in the DNSServer, we could expose the cache
impl or limitations from the dnsserver conf block. I wonder how the
spi would instantiate it.
If we want specific issues with dnsjava fixing, such as a hardcoded cache
size, we could discuss it with them, maybe even offer a patch. They seem
responsive.
Cheers
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
