james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: RemoteDelivery vs sun and geronimo javamail implementation
Date Sat, 21 Jun 2008 15:29:17 GMT
Stefano Bagnara ha scritto:
> Robert Burrell Donkin ha scritto:
>> 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.
> 
> I'm not following.
> 
> The issue is that we use activation/javamail to connect to an smtp url. 
> javamail give us a Transport (an interface defined in the specification).
> In order to better catch errors and to support 8bitmime correctly we 
> have to deal with implementation details.
> 
> In the case of Sun's implementation we check for "instance of 
> com.sun.mail.smtp.SMTPTransport" while using geronimo we would need to 
> check for "org.apache.geronimo.javamail.transport.smtp.SMTPTransport".
> 
> The same applies to the 3 specific exceptions we receive: they all are 
> extensions of javax.mail.SendFailedException, but casting them to their 
> real class we get more accurate error reporting.
> 
> How can we factor this in a separate library?
> To do that we would need to specify our own protocol provider 
> (javamail.default.providers) wrapping to the right implementation, but 
> this does not make sense to me.
> 
> Furthermore I don't think we can create extensions for the 2 
> implementation to implement a new interface, because the classes are 
> created by javamail and not by us.

I have to add that geronimo javamail implementation binary has a java5 
class version, so we can't build james against geronimo stuff using java1.4.
Reflections would also solve this issue.

Stefano


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


Mime
View raw message