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 "Alan D. Cabrera" <li...@toolazydogs.com> on 2006/06/25 07:40:39 UTC
Re: [RTC] Removal of the javamail-transport code.
Rick McGuire wrote:
> Ok, on to the next phase of the javamail reorganization. This patch
>
> http://issues.apache.org/jira/browse/GERONIMO-2147
>
> is to remove the javamail-transport module and replace it with
> references to the javamail-providers-1.3.1 jar file.
> Rick
+1
BTW, do you think that this code is ready for the Apache James people to
start using? I noticed that they have sun specific classes in their server.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [RTC] Removal of the javamail-transport code.
Posted by Rick McGuire <ri...@gmail.com>.
Alan D. Cabrera wrote:
> Rick McGuire wrote:
>> Ok, on to the next phase of the javamail reorganization. This patch
>>
>> http://issues.apache.org/jira/browse/GERONIMO-2147
>>
>> is to remove the javamail-transport module and replace it with
>> references to the javamail-providers-1.3.1 jar file.
>> Rick
> +1
>
> BTW, do you think that this code is ready for the Apache James people
> to start using? I noticed that they have sun specific classes in
> their server.
I just did a quick scan of the code, and the only javamail sun class I
see used is com.sun.mail.handlers.message_rfc822, which the G. version
has an equivalent. The javamail api should be robust enough to use
(bugs not with standing, of course).
Rick
>
>
> Regards,
> Alan
>
>
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by Rick McGuire <ri...@gmail.com>.
Stefano Bagnara wrote:
> Alan D. Cabrera wrote:
>> Stefano Bagnara wrote:
>>> Alan D. Cabrera wrote:
>>>> Why would we need both?
>>>
>>> We don't need both at the same time.
>>> But:
>>> 1) I guess that geronimo-javamail is not as stable and feature
>>> complete as the sun-javamail.
>>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3
>>> compliant)
>>>
>>> So what I think we could do is adding the handling of geronimo
>>> specific stuff while keeping the default to sun.
>>> This way one could test it and find out the differences.
>>
>> 1) Maybe not as stable. What features do you think are missing?
>
> I've not checked geronimo smtp transport, Is there a feature list for
> current geronimo stmp implementation compared to sun smtp transport?
All answers below are for the latest version. The one that shipped in
Geronimo 1.0 did not support these.
>
> Does it support the quitwait?
yes
> bindaddress/port for sockets?
yes
> does it support appending further strings at the end of the MAIL
> command and the RCPT command (ORCPT, NOTIFY).
yes
> How does it compare in converting messages from 7bit to 8bit when
> sending to servers that supports 8bitmime, and from 8bit to 7bit when
> sending to servers that do not support 8bitmime?
I haven't implemented 8bitmime yet, as I've not really found a good
description for what needs to be done to support that. I don't think
it's a big issue, I just
need to understand what it means to support it.
>
> Stefano
>
> PS: About the 7bit<->8bit mime conversion I wrote some mail to the
> javamail interest and seems that they are buggy in the sun-javamail
> transport.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by Rick McGuire <ri...@gmail.com>.
Stefano Bagnara wrote:
> Alan D. Cabrera wrote:
>> Stefano Bagnara wrote:
>>> Alan D. Cabrera wrote:
>>>> Why would we need both?
>>>
>>> We don't need both at the same time.
>>> But:
>>> 1) I guess that geronimo-javamail is not as stable and feature
>>> complete as the sun-javamail.
>>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3
>>> compliant)
>>>
>>> So what I think we could do is adding the handling of geronimo
>>> specific stuff while keeping the default to sun.
>>> This way one could test it and find out the differences.
>>
>> 1) Maybe not as stable. What features do you think are missing?
>
> I've not checked geronimo smtp transport, Is there a feature list for
> current geronimo stmp implementation compared to sun smtp transport?
All answers below are for the latest version. The one that shipped in
Geronimo 1.0 did not support these.
>
> Does it support the quitwait?
yes
> bindaddress/port for sockets?
yes
> does it support appending further strings at the end of the MAIL
> command and the RCPT command (ORCPT, NOTIFY).
yes
> How does it compare in converting messages from 7bit to 8bit when
> sending to servers that supports 8bitmime, and from 8bit to 7bit when
> sending to servers that do not support 8bitmime?
I haven't implemented 8bitmime yet, as I've not really found a good
description for what needs to be done to support that. I don't think
it's a big issue, I just
need to understand what it means to support it.
>
> Stefano
>
> PS: About the 7bit<->8bit mime conversion I wrote some mail to the
> javamail interest and seems that they are buggy in the sun-javamail
> transport.
>
>
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by Stefano Bagnara <ap...@bago.org>.
Alan D. Cabrera wrote:
> Stefano Bagnara wrote:
>> Alan D. Cabrera wrote:
>>> Why would we need both?
>>
>> We don't need both at the same time.
>> But:
>> 1) I guess that geronimo-javamail is not as stable and feature
>> complete as the sun-javamail.
>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant)
>>
>> So what I think we could do is adding the handling of geronimo
>> specific stuff while keeping the default to sun.
>> This way one could test it and find out the differences.
>
> 1) Maybe not as stable. What features do you think are missing?
I've not checked geronimo smtp transport, Is there a feature list for
current geronimo stmp implementation compared to sun smtp transport?
Does it support the quitwait? bindaddress/port for sockets? does it
support appending further strings at the end of the MAIL command and the
RCPT command (ORCPT, NOTIFY).
How does it compare in converting messages from 7bit to 8bit when
sending to servers that supports 8bitmime, and from 8bit to 7bit when
sending to servers that do not support 8bitmime?
Stefano
PS: About the 7bit<->8bit mime conversion I wrote some mail to the
javamail interest and seems that they are buggy in the sun-javamail
transport.
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Rick McGuire wrote:
> Alan D. Cabrera wrote:
>> Rick McGuire wrote:
>>> Alan D. Cabrera wrote:
>>>> Stefano Bagnara wrote:
>>>>> Alan D. Cabrera wrote:
>>>>>> Why would we need both?
>>>>>
>>>>> We don't need both at the same time.
>>>>> But:
>>>>> 1) I guess that geronimo-javamail is not as stable and feature
>>>>> complete as the sun-javamail.
>>>>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3
>>>>> compliant)
>>>>>
>>>>> So what I think we could do is adding the handling of geronimo
>>>>> specific stuff while keeping the default to sun.
>>>>> This way one could test it and find out the differences.
>>>>
>>>> 1) Maybe not as stable. What features do you think are missing?
>>> The version that shipped with Geronimo 1.0 was missing a lot of
>>> features (threw unimplemented exceptions, etc.) as well as out right
>>> buggy in places. The version that just shipped with 1.1 should be
>>> complete (the APIs anyway). The version shipping with 1.1 only
>>> supports SMTP. However, the newly created javamail component
>>> (separate build tree) supports POP3, NNTP, and NNTP-POST. IMAP is
>>> in the works.
>>
>> So this build tree, do you mean trunk?
>
> There are multiple pieces to the javamail support. The first piece is
> the specs, which is in the specs build tree. In Geronimo 1.1, the
> SMTP provider that went with this was a module in Geronimo
> (javamail-transport). A couple weeks ago, I created a new javamail
> repository that contains all of the providers. This project also
> builds an uber-jar that contains the specs and the providers. The
> source for this is:
>
> https://svn.apache.org/repos/asf/geronimo/javamail/trunk
>
>
> One of the javamail changes I recently submitted for [RTC] review will
> remove the javamail-transport module from the Geronimo code tree, and
> replace it with a dependency on the javamail-providers jar file.
Thanks for the info Rick.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Rick McGuire wrote:
> Alan D. Cabrera wrote:
>> Rick McGuire wrote:
>>> Alan D. Cabrera wrote:
>>>> Stefano Bagnara wrote:
>>>>> Alan D. Cabrera wrote:
>>>>>> Why would we need both?
>>>>>
>>>>> We don't need both at the same time.
>>>>> But:
>>>>> 1) I guess that geronimo-javamail is not as stable and feature
>>>>> complete as the sun-javamail.
>>>>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3
>>>>> compliant)
>>>>>
>>>>> So what I think we could do is adding the handling of geronimo
>>>>> specific stuff while keeping the default to sun.
>>>>> This way one could test it and find out the differences.
>>>>
>>>> 1) Maybe not as stable. What features do you think are missing?
>>> The version that shipped with Geronimo 1.0 was missing a lot of
>>> features (threw unimplemented exceptions, etc.) as well as out right
>>> buggy in places. The version that just shipped with 1.1 should be
>>> complete (the APIs anyway). The version shipping with 1.1 only
>>> supports SMTP. However, the newly created javamail component
>>> (separate build tree) supports POP3, NNTP, and NNTP-POST. IMAP is
>>> in the works.
>>
>> So this build tree, do you mean trunk?
>
> There are multiple pieces to the javamail support. The first piece is
> the specs, which is in the specs build tree. In Geronimo 1.1, the
> SMTP provider that went with this was a module in Geronimo
> (javamail-transport). A couple weeks ago, I created a new javamail
> repository that contains all of the providers. This project also
> builds an uber-jar that contains the specs and the providers. The
> source for this is:
>
> https://svn.apache.org/repos/asf/geronimo/javamail/trunk
>
>
> One of the javamail changes I recently submitted for [RTC] review will
> remove the javamail-transport module from the Geronimo code tree, and
> replace it with a dependency on the javamail-providers jar file.
Thanks for the info Rick.
Regards,
Alan
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by Rick McGuire <ri...@gmail.com>.
Alan D. Cabrera wrote:
> Rick McGuire wrote:
>> Alan D. Cabrera wrote:
>>> Stefano Bagnara wrote:
>>>> Alan D. Cabrera wrote:
>>>>> Why would we need both?
>>>>
>>>> We don't need both at the same time.
>>>> But:
>>>> 1) I guess that geronimo-javamail is not as stable and feature
>>>> complete as the sun-javamail.
>>>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3
>>>> compliant)
>>>>
>>>> So what I think we could do is adding the handling of geronimo
>>>> specific stuff while keeping the default to sun.
>>>> This way one could test it and find out the differences.
>>>
>>> 1) Maybe not as stable. What features do you think are missing?
>> The version that shipped with Geronimo 1.0 was missing a lot of
>> features (threw unimplemented exceptions, etc.) as well as out right
>> buggy in places. The version that just shipped with 1.1 should be
>> complete (the APIs anyway). The version shipping with 1.1 only
>> supports SMTP. However, the newly created javamail component
>> (separate build tree) supports POP3, NNTP, and NNTP-POST. IMAP is in
>> the works.
>
> So this build tree, do you mean trunk?
There are multiple pieces to the javamail support. The first piece is
the specs, which is in the specs build tree. In Geronimo 1.1, the SMTP
provider that went with this was a module in Geronimo
(javamail-transport). A couple weeks ago, I created a new javamail
repository that contains all of the providers. This project also builds
an uber-jar that contains the specs and the providers. The source for
this is:
https://svn.apache.org/repos/asf/geronimo/javamail/trunk
One of the javamail changes I recently submitted for [RTC] review will
remove the javamail-transport module from the Geronimo code tree, and
replace it with a dependency on the javamail-providers jar file.
Rick
>
>
> Regards,
> Alan
>
>
>
>
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Rick McGuire wrote:
> Alan D. Cabrera wrote:
>> Stefano Bagnara wrote:
>>> Alan D. Cabrera wrote:
>>>> Why would we need both?
>>>
>>> We don't need both at the same time.
>>> But:
>>> 1) I guess that geronimo-javamail is not as stable and feature
>>> complete as the sun-javamail.
>>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3
>>> compliant)
>>>
>>> So what I think we could do is adding the handling of geronimo
>>> specific stuff while keeping the default to sun.
>>> This way one could test it and find out the differences.
>>
>> 1) Maybe not as stable. What features do you think are missing?
> The version that shipped with Geronimo 1.0 was missing a lot of
> features (threw unimplemented exceptions, etc.) as well as out right
> buggy in places. The version that just shipped with 1.1 should be
> complete (the APIs anyway). The version shipping with 1.1 only
> supports SMTP. However, the newly created javamail component
> (separate build tree) supports POP3, NNTP, and NNTP-POST. IMAP is in
> the works.
So this build tree, do you mean trunk?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Rick McGuire wrote:
> Alan D. Cabrera wrote:
>> Stefano Bagnara wrote:
>>> Alan D. Cabrera wrote:
>>>> Why would we need both?
>>>
>>> We don't need both at the same time.
>>> But:
>>> 1) I guess that geronimo-javamail is not as stable and feature
>>> complete as the sun-javamail.
>>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3
>>> compliant)
>>>
>>> So what I think we could do is adding the handling of geronimo
>>> specific stuff while keeping the default to sun.
>>> This way one could test it and find out the differences.
>>
>> 1) Maybe not as stable. What features do you think are missing?
> The version that shipped with Geronimo 1.0 was missing a lot of
> features (threw unimplemented exceptions, etc.) as well as out right
> buggy in places. The version that just shipped with 1.1 should be
> complete (the APIs anyway). The version shipping with 1.1 only
> supports SMTP. However, the newly created javamail component
> (separate build tree) supports POP3, NNTP, and NNTP-POST. IMAP is in
> the works.
So this build tree, do you mean trunk?
Regards,
Alan
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by Rick McGuire <ri...@gmail.com>.
Alan D. Cabrera wrote:
> Stefano Bagnara wrote:
>> Alan D. Cabrera wrote:
>>> Why would we need both?
>>
>> We don't need both at the same time.
>> But:
>> 1) I guess that geronimo-javamail is not as stable and feature
>> complete as the sun-javamail.
>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3
>> compliant)
>>
>> So what I think we could do is adding the handling of geronimo
>> specific stuff while keeping the default to sun.
>> This way one could test it and find out the differences.
>
> 1) Maybe not as stable. What features do you think are missing?
The version that shipped with Geronimo 1.0 was missing a lot of features
(threw unimplemented exceptions, etc.) as well as out right buggy in
places. The version that just shipped with 1.1 should be complete (the
APIs anyway). The version shipping with 1.1 only supports SMTP.
However, the newly created javamail component (separate build tree)
supports POP3, NNTP, and NNTP-POST. IMAP is in the works.
> 2) FYI, we're about to check in has JavaMail 1.4 as well.
>
>
> Regards,
> Alan
>
>
>
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by Stefano Bagnara <ap...@bago.org>.
Alan D. Cabrera wrote:
> Stefano Bagnara wrote:
>> Alan D. Cabrera wrote:
>>> Why would we need both?
>>
>> We don't need both at the same time.
>> But:
>> 1) I guess that geronimo-javamail is not as stable and feature
>> complete as the sun-javamail.
>> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant)
>>
>> So what I think we could do is adding the handling of geronimo
>> specific stuff while keeping the default to sun.
>> This way one could test it and find out the differences.
>
> 1) Maybe not as stable. What features do you think are missing?
I've not checked geronimo smtp transport, Is there a feature list for
current geronimo stmp implementation compared to sun smtp transport?
Does it support the quitwait? bindaddress/port for sockets? does it
support appending further strings at the end of the MAIL command and the
RCPT command (ORCPT, NOTIFY).
How does it compare in converting messages from 7bit to 8bit when
sending to servers that supports 8bitmime, and from 8bit to 7bit when
sending to servers that do not support 8bitmime?
Stefano
PS: About the 7bit<->8bit mime conversion I wrote some mail to the
javamail interest and seems that they are buggy in the sun-javamail
transport.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Stefano Bagnara wrote:
> Alan D. Cabrera wrote:
>> Why would we need both?
>
> We don't need both at the same time.
> But:
> 1) I guess that geronimo-javamail is not as stable and feature
> complete as the sun-javamail.
> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant)
>
> So what I think we could do is adding the handling of geronimo
> specific stuff while keeping the default to sun.
> This way one could test it and find out the differences.
1) Maybe not as stable. What features do you think are missing?
2) FYI, we're about to check in has JavaMail 1.4 as well.
Regards,
Alan
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Stefano Bagnara wrote:
> Alan D. Cabrera wrote:
>> Why would we need both?
>
> We don't need both at the same time.
> But:
> 1) I guess that geronimo-javamail is not as stable and feature
> complete as the sun-javamail.
> 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant)
>
> So what I think we could do is adding the handling of geronimo
> specific stuff while keeping the default to sun.
> This way one could test it and find out the differences.
1) Maybe not as stable. What features do you think are missing?
2) FYI, we're about to check in has JavaMail 1.4 as well.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by Stefano Bagnara <ap...@bago.org>.
Alan D. Cabrera wrote:
> Why would we need both?
We don't need both at the same time.
But:
1) I guess that geronimo-javamail is not as stable and feature complete
as the sun-javamail.
2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant)
So what I think we could do is adding the handling of geronimo specific
stuff while keeping the default to sun.
This way one could test it and find out the differences.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Why would we need both?
Regards,
Alan
Stefano Bagnara wrote:
> We currently have hardcoded "instanceof" to Sun classes and we use
> many of the "properties" specific to SUN smtp transport.
>
> Btw I see that the new geronimo javamail code is much more complete
> and supports many of the properties we use.
>
> What should we do?
> I would like to at least start including handling of geronimo specific
> exceptions (most times they are the same or very similar but
> repackaged) but I'm not sure it would be good to add both
> geronimo-javamail and sun-javamail jars to our distribution (or even
> to the source build dependencies)..
>
> Any idea?
>
> Alan D. Cabrera wrote:
>> Rick McGuire wrote:
>>> Ok, on to the next phase of the javamail reorganization. This patch
>>>
>>> http://issues.apache.org/jira/browse/GERONIMO-2147
>>>
>>> is to remove the javamail-transport module and replace it with
>>> references to the javamail-providers-1.3.1 jar file.
>>> Rick
>> +1
>>
>> BTW, do you think that this code is ready for the Apache James people
>> to start using? I noticed that they have sun specific classes in
>> their server.
>>
>>
>> Regards,
>> Alan
>
>
> ---------------------------------------------------------------------
> 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
geronimo javamail and James (Was: [RTC] Removal of the javamail-transport
code.)
Posted by Stefano Bagnara <ap...@bago.org>.
We currently have hardcoded "instanceof" to Sun classes and we use many
of the "properties" specific to SUN smtp transport.
Btw I see that the new geronimo javamail code is much more complete and
supports many of the properties we use.
What should we do?
I would like to at least start including handling of geronimo specific
exceptions (most times they are the same or very similar but repackaged)
but I'm not sure it would be good to add both geronimo-javamail and
sun-javamail jars to our distribution (or even to the source build
dependencies)..
Any idea?
Alan D. Cabrera wrote:
> Rick McGuire wrote:
>> Ok, on to the next phase of the javamail reorganization. This patch
>>
>> http://issues.apache.org/jira/browse/GERONIMO-2147
>>
>> is to remove the javamail-transport module and replace it with
>> references to the javamail-providers-1.3.1 jar file.
>> Rick
> +1
>
> BTW, do you think that this code is ready for the Apache James people to
> start using? I noticed that they have sun specific classes in their
> server.
>
>
> Regards,
> Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org