Stefano Bagnara ha scritto:
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
