You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/06/20 20:40:27 UTC
RemoteDelivery vs sun and geronimo javamail implementation
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?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Jun 22, 2008 at 3:18 PM, Stefano Bagnara <ap...@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 <da...@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?
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
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> Stefano Bagnara ha scritto:
>> Robert Burrell Donkin ha scritto:
>>> On Fri, Jun 20, 2008 at 8:17 PM, David Jencks
>>> <da...@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?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> Robert Burrell Donkin ha scritto:
>> On Fri, Jun 20, 2008 at 8:17 PM, David Jencks <da...@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
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sat, Jun 21, 2008 at 2:29 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> 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
This is always because javamail has been internded for MUA. The track
detailed delivery errors via callback interfaces and they don't need the
8BITMIME stuff (this is mainly an MTA feature).
> but does remote delivery really need to use javamail as it's SMTP client?
no. 1 year ago I wrote a MINA based deliverer, but I never had the time
to complete and test it. A similar change instead would require deep
testing, so in the mean time I think it would be good to fix the
hardcoded sun javamail dependency with something supporting both sun's
and geronimo implementations.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Jun 21, 2008 at 2:29 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Fri, Jun 20, 2008 at 8:17 PM, David Jencks <da...@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.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Fri, Jun 20, 2008 at 8:17 PM, David Jencks <da...@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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jun 20, 2008 at 8:17 PM, David Jencks <da...@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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by David Jencks <da...@yahoo.com>.
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 :-)
thanks
david jencks
>
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery vs sun and geronimo javamail implementation
Posted by Bernd Fondermann <be...@googlemail.com>.
On Fri, Jun 20, 2008 at 8:40 PM, Stefano Bagnara <ap...@bago.org> 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.
The reflection lookup could be done once for every call, on first-time
access, right? If so, I am +1.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org