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 Sun, 22 Jun 2008 15:07:39 GMT
On Sun, Jun 22, 2008 at 3:18 PM, Stefano Bagnara <apache@bago.org> wrote:
> 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
>>>>>> per
>>>>>> mail and SMTPAddressFailedException, SMTPAddressSucceededException
>>>>>> SMTPSendFailedException mainly for better bounce
>>>>>> handling/debugging/logging
>>>>>> purpose upon exception.
>>>>>> So we would have 1 reflection for each delivery attempt + possibly
>>>>>> 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?

sounds better than what we have so let's give it a go :-)

- 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