james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: RemoteDelivery vs sun and geronimo javamail implementation
Date Sat, 21 Jun 2008 06:58:30 GMT
On Fri, Jun 20, 2008 at 8:17 PM, David Jencks <david_jencks@yahoo.com> wrote:
> On Jun 20, 2008, at 11:40 AM, Stefano Bagnara wrote:
>> Having removed the CRLFOutputStream depedendency the only class having
>> real dependencies on SUN's javamail *implementation* (com.sun classes) is
>> the RemoteDelivery mailet.
>> Geronimo's implementation provides almost identical classes but of course
>> they are in their own package.
>> IMO it woul be cool to support geronimo's javamail as like sun's javamail
>> (we are ASF brothers :-) ), what can we do?
>> Change RemoteDelivery to check instanceof of both classes (and add
>> geronimo implementation to the build time depedencies)
>> Add a GeronimoRemoteDelivery identical to the RemoteDelivery but renaming
>> packages (same geronimo build time depedency).
>> Use reflection to invoke the methods we use so that we can support both
>> implementation with no build time dependencies.
>> We currently call transport.supportsExtension("8BITMIME") method once per
>> mail and SMTPAddressFailedException, SMTPAddressSucceededException and
>> SMTPSendFailedException mainly for better bounce handling/debugging/logging
>> purpose upon exception.
>> So we would have 1 reflection for each delivery attempt + possibly 3-4
>> reflections for each address failed upon delivery failure.
>> I would go with reflections.
>> Objections? Opinions?
> I don't know if it is worth it but you could define an interface, and two
> implementations that delegate to the two classes, and try to load each
> implementation and use the one that can be loaded.  Maybe this is your first
> or second suggestion?
> I lean (slightly) against reflection because it makes the dependencies less
> clear.
> If you do any of these it would be nice to make the (maven) dependency on
> javamail provided so neither implementation is pulled in automatically.
> I guess another possibility is to switch entirely to the geronimo
> implementation :-)

i would prefer to use the geronimo implementation :-)

but anyway: some of the utilities in there sounds like they'd be
useful more generally. maybe they could be factored into a separate
library for easier reuse.

- robert

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message