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 Sun, 22 Jun 2008 14:18:49 GMT
Stefano Bagnara ha scritto:
> 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

I'll give a try to the reflection based approach. I think it will anyway 
be better than something tied to sun's implementation, and I don't see 
any other simple solution, ATM.

any objection?


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

View raw message