On Sat, Jun 21, 2008 at 2:29 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Fri, Jun 20, 2008 at 8:17 PM, David Jencks <[EMAIL PROTECTED]>
>> 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.
sorry: it was me who wasn't following (i was reading on my iPhone)
> 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.
ok
> 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.
yes: this is a JavaMail bug
i see now that the API has been badly designed and users are forced to
cast to sun specific class to obtain information that should be
available through the public interface
but does remote delivery really need to use javamail as it's SMTP client?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
