You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Alex Blewitt <Al...@ioshq.com> on 2003/09/12 14:45:48 UTC
Status: JavaMail API implementation now at Alpha quality
I have submitted a patch [*] covering the majority of work that I have
done on implementing the JavaMail API. Importantly, this allows
developers to now instantiate the MimeMessage class, and for simple
(text formats) messages, the MimeMessage should be usable by those
implementing transports/stores.
There are some unimplemented features; it cannot yet handle multipart
messages, and there are issues with non-ASCII encodings at present.
Hopefully these issues will be ironed out with test cases that break
the API and thus can be fixed. I would otherwise personally raise a bug
to record each of these cases, but I am not sure this is within the
standard use of the bug tracking tool by the geronimo team.
I am off on holiday for a couple of weeks, and access is likely to be
sporadic; I won't be doing any coding in any case. I hope that this set
of code gives other developers the necessary base framework to continue
implementing JavaMail providers.
Regards,
Alex.
[*] http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-80
RE: Status: JavaMail API implementation now at Alpha quality
Posted by Danny Angus <da...@apache.org>.
> JavaMail is a poorly defined specification, which makes the role of the RI
> more critical not less. It has also been around forever achieving de-facto
> status and changing things runs the risk of making this implementation
> unusable.
In fact much of the actual code makes up the API, and not the RI.
It is very poorly designed, and part of it's poor design (too much code, too
few interfaces) is also what makes it so hard for 3rd parties like us to
make any alternative implementations.
> That you have not compared behaviour to the RI for a spec that is known to
> be ambiguous illustrates my concerns about your approach. All the unit
> testing in the world won't identify a problem in how you expect
> it to work.
Unfortunately Sun haven't factored all the concrete classes in JavaMail into
Interface and RI, the comparison will often not be with the behaviour of the
RI, but with the behaviour of Sun's own API.
d.
Re: Status: JavaMail API implementation ...
Posted by Elias Sinderson <el...@email.arc.nasa.gov>.
Alex,
You go and rock on with your bad self buddy. I think you're doing great
work and totally support your heroic efforts to implement a spec that is
not as clearly written as it should have been. Apologies for any grief
you've felt - hope it doesn't turn you off.
I absolutely agree with you that implementing to the spec takes
precedence over the RI, especially since the RI, as you said, has
demonstrable defects.
Regards,
Elias
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Alex Blewitt <Al...@ioshq.com>.
On Saturday, Sep 13, 2003, at 17:13 Europe/London, Jeremy Boynes wrote:
>> From: Alex.Blewitt@ioshq.com [mailto:Alex.Blewitt@ioshq.com]
>> Sent: Saturday, September 13, 2003 5:12 AM
>>>> b) a change was made to the impl of URLName.equals() that makes it
>>>> behave differently to the RI and which I explicitly asked Alex
>>>> not to make
>>
>> Actually, the change was /back/ to the original implementation, from
>> which
>> it was changed in the first place.
>
> Exactly, and when I changed it in the first place I explained to you
> then
> why the change was necessary.
We exchanged e-mails on the subject and were left in the knowledge that
the Sun implementation does not correctly implement equals as per the
JavaDoc. Thus, it was correct to fix the bug and implement it correctly.
>> The issue at stake is that the bug also exists in the Sun
>> implementation.
> The rules are simple:
> 1) Implement what the spec says
> 2) If the spec is ambiguous, do what the RI does
> 3) If you think the RI is wrong, live with it
The spec is not ambiguous; it is completely clear in java.lang.Object
how the equals method behaves. The RI is demonstrably buggy; the
implementation I provided is not. You re-introduced the bug breaking
what the spec says.
> JavaMail is a poorly defined specification, which makes the role of
> the RI
> more critical not less. It has also been around forever achieving
> de-facto
> status and changing things runs the risk of making this implementation
> unusable.
Now who's being melodramatic? It is simply a bug, and bugs get fixed
all the time. We are not chasing a movable set of bugs; we are
achieving a reimplementation with its own set of bugs, and hopefully,
its own set of fixes. The spec is the clear definition of what happens,
and Suns implementation can be used where the spec is vague or missing
on the subject. In this case, the spec is neither missing nor ambigous.
>>>> These may seem minor but they are symptomatic of a coding
>>>> approach that may lead to other deviations and I think the
>>>> entire patch should be reviewed in detail. If someone steps
>>>> up to do that then it may be appropriate to commit this to a
>>>> separate branch until done.
>>
>> Always nice not to be trusted :-)
>
> Trust is to be earned.
I have no issue with earning trust, and my code demonstrates what I am
putting into the project. I also have no fear in disagreeing with
people, and nor of code reviews by others -- several bugs I have
inadvertently introduced have been found (and fixed) by others on this
list.
I never said that I would be a perfect coder, but I did say that I was
conforming to the JavaMail spec. I took offence that you did not trust
that this was my goal.
>> I've tried to code extensive unit tests for the code in the JavaMail
>> API
>> to ensure that I do closely stick to the spec.
>
> That you have not compared behaviour to the RI for a spec that is
> known to
> be ambiguous illustrates my concerns about your approach. All the unit
> testing in the world won't identify a problem in how you expect it to
> work.
The spec is not ambiguous on this method, though, is it? Read the
JavaDoc, and come back if you have questions.
FWIW I am following a license that does not allow checking against the
RI; I am doing a full clean-room implementation according to the
JavaMail license. You may be testing using a different license, such as
the Sun Binary Code License, but I am not and therefore do not have the
luxury of being ale to test the RI.
> Again Alex, approach - you dump a patch on us and then disappear
> leaving
> others to clear up the mess. Show some thought for other members of the
> community.
You complain when I submit lots of little patches. I ask for advice on
the size of patches, both publicly and privately, to which I received
no response. You complain when I submit a large patch.
I am coding faster than patches being applied can keep up with. I have
raised this issue before, and am working within the current set of
constraints.
I also considered that other members of the community with which I have
been conversing about the JavaMail and JAF packages would like to work
with an alpha release of the JavaMail spec rather than me going on
holiday and not providing them for others' use. So I do consider my
work to be beneficial to the community at large, though perhaps not to
yourself personally.
>> I am of the opinion that the only number of patches people will be
>> happy
>> with me submitting is zero; it's not worked with detailed patches, and
>> it's not worked with one-size-fits-all approach.
>
> Number of bad patches: zero
> Number of good patches: unbounded
So, I can submit a large single patch as long as its good? Well, I've
done that with the last one then :-)
> If a 30 second skim of the patch raises concerns, if the patch needs
> to be
> tweaked so that it compiles, if the patched code fails the unit tests,
> then
> I'm going to classify it as bad.
Great! So it's a good patch then. It compiled, it ran, it passed the
unit tests -- at least on my machine. The fact that you believe a bug
should be emulated, whereas I believe it doesn't, is the only issue at
stake.
Alex.
RE: Status: JavaMail API implementation now at Alpha quality
Posted by Jeremy Boynes <je...@coredevelopers.net>.
> From: Alex.Blewitt@ioshq.com [mailto:Alex.Blewitt@ioshq.com]
> Sent: Saturday, September 13, 2003 5:12 AM
> > > b) a change was made to the impl of URLName.equals() that makes it
> > > behave differently to the RI and which I explicitly asked Alex
> > > not to make
>
> Actually, the change was /back/ to the original implementation, from which
> it was changed in the first place.
Exactly, and when I changed it in the first place I explained to you then
why the change was necessary.
<snip/>
> The issue at stake is that the bug also exists in the Sun RI. I believe
> that it is right the community should decide which is appropriate to use,
> and we can use that one instead; it isn't for two people to disagree and
> come up with an implementation.
>
> The absolute question is: what are we trying to achieve in the JavaMail
> API reimplementation? Copy it byte-for-byte, including any bugs that are
> present in the JavaMail implementation? Or provide something that behaves
> correctly as per the JavaDoc? My take on this is that we should implement
> to the spec, and not try to represent every bug in the RI, since the
> latter will be a moving target.
>
Leave out the melodrama.
The rules are simple:
1) Implement what the spec says
2) If the spec is ambiguous, do what the RI does
3) If you think the RI is wrong, live with it
JavaMail is a poorly defined specification, which makes the role of the RI
more critical not less. It has also been around forever achieving de-facto
status and changing things runs the risk of making this implementation
unusable.
> > > These may seem minor but they are symptomatic of a coding
> > > approach that may lead to other deviations and I think the
> > > entire patch should be reviewed in detail. If someone steps
> > > up to do that then it may be appropriate to commit this to a
> > > separate branch until done.
>
> Always nice not to be trusted :-)
Trust is to be earned.
>
> I've tried to code extensive unit tests for the code in the JavaMail API
> to ensure that I do closely stick to the spec, including feedback from
> others with JDiff about the implementation of the methods. I have always
> been very careful to implement the JavaMail APIs based on the JavaDoc, and
> I have not used the JavaMail binary at all during this process. Therefore,
> I believe the work I have been doing is very careful and considerate
> towards the specification, and I am upset by Jeremy's allegation above.
>
That you have not compared behaviour to the RI for a spec that is known to
be ambiguous illustrates my concerns about your approach. All the unit
testing in the world won't identify a problem in how you expect it to work.
> Seriously, the reason I hand't put that in before was because I was
> submitting lots of small patches with detailed messages about them. This
> was then slated by the cathedral, so instead I submitted an entire patch
> with my work so far before going on holiday. I had wanted to bring the
> discussion about the 'warts-and-all approach vs correct implementation
> from JavaDoc' before submitting it later, but it got subsumed in this
> approach.
>
Again Alex, approach - you dump a patch on us and then disappear leaving
others to clear up the mess. Show some thought for other members of the
community.
> I am of the opinion that the only number of patches people will be happy
> with me submitting is zero; it's not worked with detailed patches, and
> it's not worked with one-size-fits-all approach.
>
Number of bad patches: zero
Number of good patches: unbounded
If a 30 second skim of the patch raises concerns, if the patch needs to be
tweaked so that it compiles, if the patched code fails the unit tests, then
I'm going to classify it as bad.
--
Jeremy
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Tuesday, September 16, 2003, at 03:22 PM, Alex Blewitt wrote:
> On Tuesday, Sep 16, 2003, at 21:07 Europe/London, Matt Kurjanowicz
> wrote:
>
>> As far as packaging external classes, I think it very appropriate, as
>> long as we say *what* we are including. It's our implementation of
>> the
>> API, and as long as it's up to Spec, it doesn't matter what's going on
>> behind the scenes - that's just abstraction and is of no consequence
>> to
>> the end-user.
>
> If JavaMail is ever spun out to a different API, then the exceptions
> might need to be redressed (or at the least, packed with the JavaMail
> API). But whilst it's here, I don't see a problem.
That is the exact problem. People will want to use it as a standalone
without any other geronimo code. I personally don't think this code
belongs in Geronimo at all and should be moved to a James,
Jakarta-Commons, Commons or SourceForge.
>> One question I do have:
>> How would it be good to implement the
>> requestPasswordAuthentication(...)
>> method in the javax.mail.Store class? The javadoc says to prompt for
>> a
>> username and password in a fairly standard way, but how does that fit
>> in
>> to the Server? Would it be a good idea to use a standard System.out
>> and
>> System.in to read the username and password?
>
> This still isn't implemented yet -- I've yet to work on the password
> authentication parts. It's usually expected that the uid/password will
> be provided with the call to connect in the first place; if it is,
> then requestPasswordAuthentication will never be called. It's only
> called when there isn't one (or it's wrong).
>
> However, what would be good is finding whether we're running in a GUI
> -- can we use anything to detect if we are headless?
Authentication information should be gathered from JAAS. That is what
it is designed to do.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Sep 16, 2003, at 21:07 Europe/London, Matt Kurjanowicz
wrote:
> As far as packaging external classes, I think it very appropriate, as
> long as we say *what* we are including. It's our implementation of the
> API, and as long as it's up to Spec, it doesn't matter what's going on
> behind the scenes - that's just abstraction and is of no consequence to
> the end-user.
If JavaMail is ever spun out to a different API, then the exceptions
might need to be redressed (or at the least, packed with the JavaMail
API). But whilst it's here, I don't see a problem.
> One question I do have:
> How would it be good to implement the
> requestPasswordAuthentication(...)
> method in the javax.mail.Store class? The javadoc says to prompt for a
> username and password in a fairly standard way, but how does that fit
> in
> to the Server? Would it be a good idea to use a standard System.out
> and
> System.in to read the username and password?
This still isn't implemented yet -- I've yet to work on the password
authentication parts. It's usually expected that the uid/password will
be provided with the call to connect in the first place; if it is, then
requestPasswordAuthentication will never be called. It's only called
when there isn't one (or it's wrong).
However, what would be good is finding whether we're running in a GUI
-- can we use anything to detect if we are headless?
Alex.
RE: Status: JavaMail API implementation now at Alpha quality
Posted by Matt Kurjanowicz <mk...@cc.gatech.edu>.
Well, after reviewing the code, I think that it's up to spec. I've been
looking at it for a few days, and compared each class to the JavaDoc and
JavaMail API, and I think they all match well. As far as the .equals()
method is concerned, I leave that up to the rest of the community. I
don't have a personal preference, but I think blindly following the RI
is not always the way to go since we are implementing the *spec*, not
just a reimplementation of the Sun RI. If the current implementation is
up to Spec, then I think that we're OK.
As far as packaging external classes, I think it very appropriate, as
long as we say *what* we are including. It's our implementation of the
API, and as long as it's up to Spec, it doesn't matter what's going on
behind the scenes - that's just abstraction and is of no consequence to
the end-user.
One question I do have:
How would it be good to implement the requestPasswordAuthentication(...)
method in the javax.mail.Store class? The javadoc says to prompt for a
username and password in a fairly standard way, but how does that fit in
to the Server? Would it be a good idea to use a standard System.out and
System.in to read the username and password?
Just my 2cents.
-Matt
mkurjano at cc.gatech.edu
-----Original Message-----
From: Bill de hÓra [mailto:bill@dehora.net]
Sent: Tuesday, September 16, 2003 2:55 PM
To: geronimo-dev@incubator.apache.org
Subject: Re: Status: JavaMail API implementation now at Alpha quality
Alex Blewitt wrote:
> On Saturday, Sep 13, 2003, at 22:39 Europe/London, Danny Angus wrote:
>
>> 4/ We know from discussions regarding Tomcat that the behaviour of a
RI
>> itself forms "case law" and sets precedence about the expected
>> behaviour of
>> other implementations.
In the absence of clarity in the spec, yes. Is the spec on this
equals method unclear?
>> You are at liberty to "fix" it but this would then be a deviation
>> from the
>> API behavoiur which our user would have to be informed of, for the
>> sake of
>> their sanity if nothing else.
>
>
> The 'bug' is in the definition of the 'equals' method, which is
clearly
> defined in the Java language in the java.lang.Object class:
> [...]
> The implementation in the Sun JavaMail breaks this by not being
> transitive (that is, it is possible for the equals method to have
> a.equals(c) and b.equals(c), but not a.equals(b). The implementation I
> used had the advantage that (a) it was transitive, and that (b) the
> implementation of the method is more efficient for large numbers of
> subclasses.
Let's put aside the Object.equals contract and the RI code for a
second. The important question it seems to me, is this: is what's in
CVS now, compliant with the JavaMail *spec*?
If it is, leave it alone. If it's not, patch it.
> The only time a behavioural difference will be noted is if subclasses
> of the offending object (URLName) are created.
Again, what matters is whether this means anything with regard to
the *spec*.
The rest of this mail is technically offtopic.
> What I objected to was the implication "symptomatic of a coding
> approach that may lead to other deviations" as if I was against
working
> towards a fully compliant code. Granted, I may make mistakes in the
> implementation (and others have picked these out) but I am not working
> on a coding approach that throws this all out of the window.
Seeing as RMH kicked off some honest speaking earlier, here's my 2c
on all this malarky.
I'm not seeing peer review on this thread. not by a long shot. I
think Alex is catching some negative feedback that doesn't strike me
as clear, useful, or informative. I certainly wouldn't be sure what
to do to get better after sucking it up. People here, especially
those with commit and membership liberties can perhaps do better
than non-respond to (it seems to me) a fair question by citing the
poster as melodramatic, or claim patches are being dumped on them again.
Bill de hÓra
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Bill de hÓra <bi...@dehora.net>.
Adrian Jackson wrote:
> Trying to stay bug compatible with a reference implementation is a
> nightmare: it's like trying to write code that conforms to a spec you're
> not allowed to see that changes from version to version without
> notification.
Interop and platform neutrality is a nightmare sometimes. If the
last resort is bug compatability so be it, but it is a last resort.
> I guess the real question that our theoretical friends haven't been
> addressing is whether the implementation of the equals() method is
> actually something of any real practical importance.
Possibly not. Thrashing out a working approach for cases like these
is though. I expect this class of issue will arise a number of times
as Geronimo is developed. The problem always with systems is that
each individual case and compromise is often not of practical
importance but the collection of all cases and compromises makes for
a sort of cancer.
> Although some
> notoriously stupid bugs have been perpetuated by a refusal to fix them
> and potentially break code that relies on the bug in the first place
> (Java bug 4030718 springs to mind as an example).
My favorite example:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17021
:)
Bill de hÓra
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Adrian Jackson <Ad...@extenuating.com>.
Bill de hÓra wrote:
> [[[
> 1) Implement what the spec says
> 2) If the spec is ambiguous, talk to the spec lead
> 3) If you think the spec/lead is is wrong, do what the RI does
> 4) If the RI has a bug, file the bug, but stay bug compatible
> ]]]
Trying to stay bug compatible with a reference implementation is a
nightmare: it's like trying to write code that conforms to a spec you're
not allowed to see that changes from version to version without
notification.
I guess the real question that our theoretical friends haven't been
addressing is whether the implementation of the equals() method is
actually something of any real practical importance. Is there software
out there that's likely to run into the situation where the question of
whether the equals() method for URLName is transitive in certain cases
where different subclasses of URLName are compared becomes an issue? If
not, then I'd prefer to see a 'correct' implementation as proposed by
Alex. If it *is* an issue, and software is likely to depend on the
'bugged' RI, then Jeremy's version of the code is a lot more appealing -
practicality has to override theory at some point. Although some
notoriously stupid bugs have been perpetuated by a refusal to fix them
and potentially break code that relies on the bug in the first place
(Java bug 4030718 springs to mind as an example). And as has already
been suggested, ensure the bug in the RI has been reported to Sun.
But what do I know? I'm only a lurker round here. :)
Adrian
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Bill de hÓra <bi...@dehora.net>.
n. alex rupp wrote:
> If I were arguing your point, I'd just ask the spec lead for javamail--I
> imagine they'd be willing to give you some direction and perhaps give your
> argument some authority (failing that, they'd clarify this matter so people
> could shrug shoulders and move on).
Jeremy Boynes posted some rules:
[[[
The rules are simple:
1) Implement what the spec says
2) If the spec is ambiguous, do what the RI does
3) If you think the RI is wrong, live with it
]]]
which should be modified:
[[[
1) Implement what the spec says
2) If the spec is ambiguous, talk to the spec lead
3) If you think the spec/lead is is wrong, do what the RI does
4) If the RI has a bug, file the bug, but stay bug compatible
]]]
Bill de hÓra
Re: Status: JavaMail API implementation now at Alpha quality
Posted by "n. alex rupp" <ru...@umn.edu>.
Whoah . . .
Alex, is there a possibility that you could bring up your RI bugs with the
spec team for javamail? If you could get them to acknowledge it as a bug
(or perhaps track down one of the old spec leads), it might help you get out
of this argument without it erupting in flames.
If I were arguing your point, I'd just ask the spec lead for javamail--I
imagine they'd be willing to give you some direction and perhaps give your
argument some authority (failing that, they'd clarify this matter so people
could shrug shoulders and move on).
Best luck,
--
N. Alex Rupp (n_alex_rupp@users.sf.net)
----- Original Message -----
From: "Dain Sundstrom" <da...@coredevelopers.net>
To: <ge...@incubator.apache.org>
Sent: Tuesday, September 16, 2003 3:50 PM
Subject: Re: Status: JavaMail API implementation now at Alpha quality
On Tuesday, September 16, 2003, at 01:55 PM, Bill de h�ra wrote:
> Seeing as RMH kicked off some honest speaking earlier, here's my 2c on
> all this malarky.
>
> I'm not seeing peer review on this thread. not by a long shot. I think
> Alex is catching some negative feedback that doesn't strike me as
> clear, useful, or informative. I certainly wouldn't be sure what to do
> to get better after sucking it up. People here, especially those with
> commit and membership liberties can perhaps do better than
> non-respond to (it seems to me) a fair question by citing the poster
> as melodramatic, or claim patches are being dumped on them again.
I suggest you go back and read the Alex threads. The reason no one
wants to respond is they don't want to get into this exact kind of
pissing match. It is an extreme waste of time and almost none of the
threads come to a conclusion, and most end in a rant about how the big
bad committers are crushing his enthusiasm. Alex has already burned
out David Blevins and my self, and it looks like Jeremy is close to
giving up on working with him. After that I don't know who would be
willing to work with him, and since he has burned a lot of bridges
already I don't see him getting commit access anytime soon.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Tuesday, September 16, 2003, at 01:55 PM, Bill de hÓra wrote:
> Seeing as RMH kicked off some honest speaking earlier, here's my 2c on
> all this malarky.
>
> I'm not seeing peer review on this thread. not by a long shot. I think
> Alex is catching some negative feedback that doesn't strike me as
> clear, useful, or informative. I certainly wouldn't be sure what to do
> to get better after sucking it up. People here, especially those with
> commit and membership liberties can perhaps do better than
> non-respond to (it seems to me) a fair question by citing the poster
> as melodramatic, or claim patches are being dumped on them again.
I suggest you go back and read the Alex threads. The reason no one
wants to respond is they don't want to get into this exact kind of
pissing match. It is an extreme waste of time and almost none of the
threads come to a conclusion, and most end in a rant about how the big
bad committers are crushing his enthusiasm. Alex has already burned
out David Blevins and my self, and it looks like Jeremy is close to
giving up on working with him. After that I don't know who would be
willing to work with him, and since he has burned a lot of bridges
already I don't see him getting commit access anytime soon.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Sep 16, 2003, at 19:55 Europe/London, Bill de hÓra wrote:
> Alex Blewitt wrote:
>> On Saturday, Sep 13, 2003, at 22:39 Europe/London, Danny Angus wrote:
>>> 4/ We know from discussions regarding Tomcat that the behaviour of a
>>> RI
>>> itself forms "case law" and sets precedence about the expected
>>> behaviour of
>>> other implementations.
>
> In the absence of clarity in the spec, yes. Is the spec on this equals
> method unclear?
It's vague, for certain -- the document is at
http://java.sun.com/products/javamail/javadocs/javax/mail/
URLName.html#equals(java.lang.Object)
However, it overrides the Object API which puts behavioural constraints
on subclass' implementations, which they should honour.
>>> You are at liberty to "fix" it but this would then be a deviation
>>> from the
>>> API behavoiur which our user would have to be informed of, for the
>>> sake of
>>> their sanity if nothing else.
>> The 'bug' is in the definition of the 'equals' method, which is
>> clearly defined in the Java language in the java.lang.Object class:
>> [...]
>> The implementation in the Sun JavaMail breaks this by not being
>> transitive (that is, it is possible for the equals method to have
>> a.equals(c) and b.equals(c), but not a.equals(b). The implementation
>> I used had the advantage that (a) it was transitive, and that (b)
>> the implementation of the method is more efficient for large numbers
>> of subclasses.
>
> Let's put aside the Object.equals contract and the RI code for a
> second. The important question it seems to me, is this: is what's in
> CVS now, compliant with the JavaMail *spec*?
Both are compliant with the spec; one exhibits a bug. A test case
already exists that demonstrates the bug and the associated patch fixes
it.
> If it is, leave it alone. If it's not, patch it.
I do not believe that it is right to emulate bugs in JavaMail --
otherwise, where would we stop? I believe that the bug should be fixed;
but it's a bug introduced by another's opinion of how it should work.
>> The only time a behavioural difference will be noted is if subclasses
>> of the offending object (URLName) are created.
>
> Again, what matters is whether this means anything with regard to the
> *spec*.
What is the spec, though? The PDF document on the spec doesn't
explicitly mention it, and the URLName's documentation describes how
the behaviour of equals work, but does not explicitly re-state the
conditions from the superclass. However, the superclass' documentation
says that subclasses must implement the equals method in that fashion,
so a class that overrides it and does not provide transitivity will be
in violation of the contract.
It may well be a moot point since the JavaMail TCK is unlikely to test
transitivity of equals (otherwise they would have picked up the bug :-)
so either solution will pass spec compliance. But I still strongly
dislike the idea of leaving a known bug in an implementation,
especially when the test and fix is available.
Alex.
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Bill de hÓra <bi...@dehora.net>.
Alex Blewitt wrote:
> On Saturday, Sep 13, 2003, at 22:39 Europe/London, Danny Angus wrote:
>
>> 4/ We know from discussions regarding Tomcat that the behaviour of a RI
>> itself forms "case law" and sets precedence about the expected
>> behaviour of
>> other implementations.
In the absence of clarity in the spec, yes. Is the spec on this
equals method unclear?
>> You are at liberty to "fix" it but this would then be a deviation
>> from the
>> API behavoiur which our user would have to be informed of, for the
>> sake of
>> their sanity if nothing else.
>
>
> The 'bug' is in the definition of the 'equals' method, which is clearly
> defined in the Java language in the java.lang.Object class:
> [...]
> The implementation in the Sun JavaMail breaks this by not being
> transitive (that is, it is possible for the equals method to have
> a.equals(c) and b.equals(c), but not a.equals(b). The implementation I
> used had the advantage that (a) it was transitive, and that (b) the
> implementation of the method is more efficient for large numbers of
> subclasses.
Let's put aside the Object.equals contract and the RI code for a
second. The important question it seems to me, is this: is what's in
CVS now, compliant with the JavaMail *spec*?
If it is, leave it alone. If it's not, patch it.
> The only time a behavioural difference will be noted is if subclasses
> of the offending object (URLName) are created.
Again, what matters is whether this means anything with regard to
the *spec*.
The rest of this mail is technically offtopic.
> What I objected to was the implication "symptomatic of a coding
> approach that may lead to other deviations" as if I was against working
> towards a fully compliant code. Granted, I may make mistakes in the
> implementation (and others have picked these out) but I am not working
> on a coding approach that throws this all out of the window.
Seeing as RMH kicked off some honest speaking earlier, here's my 2c
on all this malarky.
I'm not seeing peer review on this thread. not by a long shot. I
think Alex is catching some negative feedback that doesn't strike me
as clear, useful, or informative. I certainly wouldn't be sure what
to do to get better after sucking it up. People here, especially
those with commit and membership liberties can perhaps do better
than non-respond to (it seems to me) a fair question by citing the
poster as melodramatic, or claim patches are being dumped on them again.
Bill de hÓra
Re: Status: JavaMail API implementation now at Alpha quality
Posted by Alex Blewitt <Al...@ioshq.com>.
On Saturday, Sep 13, 2003, at 22:39 Europe/London, Danny Angus wrote:
> 4/ We know from discussions regarding Tomcat that the behaviour of a RI
> itself forms "case law" and sets precedence about the expected
> behaviour of
> other implementations.
Can someone fill me in on the rest of this, or provide me pointers
towards it? I've not been involved with Tomcat's discussions/RI before.
> 5/ Any acceptable copy of the JavaMail API must comply with the
> published
> specification, being both the wordy specification and the javadocs. It
> must
> also exhibit substantially the same behaviour as Suns product, and any
> implementation must be consistent with the RI.
100% agree with this, with the caveat that 'any implementation must be
consistent with the RI' does not include bugs in the RI.
> Now Alex says..
>
>> The dependency is on the InvalidArgumentException and
>> NullArgumentException. I originally put those in since when they
>> become
>> internationalised, changes made to those classes will have immediate
>> benefit to the JavaMail API.
>
> Alex we (and you) have no jurisdiction to make any changes whasoever
> to the
> API, specifically including method signatures.
Completely agree, and I have been very careful to ensure compliance.
The method signature remains unchanged, since there are no declared
exception types -- it was a case of using IllegalArgumentException
instead of NullArgumentException (or vice versa). The latter extends
the former, which in turn extends RuntimeException, so has no effect on
the method signature and thus stays with compliance of the spec.
> What is acceptable is for the internal implementation of the expected
> behaviour to be implemented in any way we choose, but that any
> dependance
> not specified by the API should be satisfied internally and not
> apparent in
> any way to any user of the API.
Yes. NAE was a subtype of IAE, which is a subtype of RE which would be
what any user could expect from methods in an external class.
> That is to say we could use components from many sources, but our
> resulting
> mailapi.jar should be a direct replacement for Sun's one with no
> additional
> requirements.
Agree as well, though there's no reason why any necessary dependent
classes could not be bundled in the mailapi.jar file as required. Nor
does it have to be self-contained; for example, the mailapi explicitly
depends on (but does not contain) the activation framework. And
mailapi.jar depends on several other libraries provided by Java 1.4 ...
>> I do not believe that the specs package cannot include classes
>> outside of
>> the javax. namespace; indeed, the Sun RI ships with a whole bunch of
>> com.sun classes as is. There isn't any reason why JavaMail couldn't
>> ship
>> with an org.apache class or two instead.
>
> The API only consist of the javax.mail.* packages, and only depends
> upon
> java.* and javax.*
> The com.sun classes are the refrence implementation and though they
> depend
> upon the API the API does not depend upon them.
The JavaMail API does not (a) have to be self contained, and (b) cannot
depend on others. For convenience, outside of Geronimo, it should be
packaged in such a way that all dependent classes are part of the same
Jar file.
There are also com.sun classes in the mailapi.jar as well -- for
example, handlers for data types and so forth - so it is not the case
that the mailapi.jar is solely the API; it is the full API and some RI
code as well, with the remainder of the RI code (providers, transports
etc) provided in their own Jar(s).
>> The issue at stake is that the bug also exists in the Sun RI.
>
> Actually if it exists it is in the API not the RI.
Yes, my mistake -- it's in the core API class.
> You are at liberty to "fix" it but this would then be a deviation from
> the
> API behavoiur which our user would have to be informed of, for the
> sake of
> their sanity if nothing else.
The 'bug' is in the definition of the 'equals' method, which is clearly
defined in the Java language in the java.lang.Object class:
The JavaDoc states:
--- 8<---
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/
Object.html#equals(java.lang.Object)
Indicates whether some other object is "equal to" this one.
The equals method implements an equivalence relation on non-null
object references:
o It is reflexive: for any non-null reference value x, x.equals(x)
should return true.
o It is symmetric: for any non-null reference values x and y,
x.equals(y) should return true if and only if y.equals(x) returns true.
o It is transitive: for any non-null reference values x, y, and z, if
x.equals(y) returns true and y.equals(z) returns true, then x.equals(z)
should return true.
o It is consistent: for any non-null reference values x and y, multiple
invocations of x.equals(y) consistently return true or consistently
return false, provided no information used in equals comparisons on the
objects is modified.
For any non-null reference value x, x.equals(null) should return false.
--- 8< ---
The implementation in the Sun JavaMail breaks this by not being
transitive (that is, it is possible for the equals method to have
a.equals(c) and b.equals(c), but not a.equals(b). The implementation I
used had the advantage that (a) it was transitive, and that (b) the
implementation of the method is more efficient for large numbers of
subclasses.
The only time a behavioural difference will be noted is if subclasses
of the offending object (URLName) are created.
>> The absolute question is: what are we trying to achieve in the
>> JavaMail
>> API reimplementation? Copy it byte-for-byte, including any bugs that
>> are
>> present in the JavaMail implementation? Or provide something that
>> behaves
>> correctly as per the JavaDoc? My take on this is that we should
>> implement
>> to the spec, and not try to represent every bug in the RI, since the
>> latter will be a moving target.
>
> Well at least now you're beginning to realise why it is not a job to be
> undertaken lightly.
I never thought it was a job to be undertaken lightly :-) My aim was to
recreate the JavaMail implementation for Apache, and implement the
specifications as per the JavaMail specs. I was not aiming to recreate
every bug in Sun's JavaMail, with the result that there are undoubtedly
methods that work in a different manner between the two -- however, the
public API will conform to the specification.
>>>> These may seem minor but they are symptomatic of a coding
>>>> approach that may lead to other deviations and I think the
>>>> entire patch should be reviewed in detail. If someone steps
>>>> up to do that then it may be appropriate to commit this to a
>>>> separate branch until done.
>>
>> Always nice not to be trusted :-)
>
> This has little or nothing to do with trust, Apache projects are
> meritocracies and operate a system of peer review.
I agree, and this issue is one that did deserve to be discussed openly
on the mail review.
> You have allegedly made an error of judgement based upon an apparent
> difficulty in understanding what is the JavaMail API and what is it's
> implementation and what is appropriate for your work on each part.
> This
> has, quite rightly, been picked up by peer review and also quite
> rightly it
> has been suggested that the the rest of your patch be reviewed in
> detail in
> case the same assumtions are manifested elsewhere.
> We're here to do this thing correctly, whether or not that offends you.
I have no issues with the implementation, and have no feelings of code
ownership for what has been submitted. I am also, for the record,
firmly committed to complete compliance with the specification of both
JavaMail and any future code I am involved with a J2EE server.
What I objected to was the implication "symptomatic of a coding
approach that may lead to other deviations" as if I was against working
towards a fully compliant code. Granted, I may make mistakes in the
implementation (and others have picked these out) but I am not working
on a coding approach that throws this all out of the window.
>> I have always been very careful to implement the JavaMail APIs based
>> on the JavaDoc
>
> In which case why did you add a dependancy which doesn't exist there?
The dependencies are not part of the equation. There is nothing to say
the mailapi.jar can only contain javax.mail classes, which is your
assumption. You will note that Sun's mailapi.jar contains both the API
and RI code; all I was doing was the same in Geronimo. For when
JavaMail is extracted elsewhere, this class could easily be extracted
as well and/or replaced with a different implementation. TBH the sooner
that JavaMail becomes its own stand-alone module (along with the
activation framework) then the less likely these issues will occur.
I also did that within the keeping of the API; no method signatures
were harmed in the making of that method.
I hope this sorts out any possible confusion towards my last post(s) on
the subject, and that we can continue to use a correct implementation
of equals in the URLName class as per the Java specification.
Alex.
RE: Status: JavaMail API implementation now at Alpha quality
Posted by Danny Angus <da...@apache.org>.
Please can we be more precise when using the terms RI (Refrence
Implementation) and
API
The Javax.mail.* packages are the JavaMail API
The com.sun.* mail classes are the RI.
At the start of this I raised concerns about the nature of JavaMail and the
appropriateness of this operation. In the light of this development I'd like
to raise some of the points again.
1/ JavaMail is distibuted as API and RI by Sun for the convenience of it's
users.
2/ The API itself consists of many more concrete classes, and many fewer
Interfaces than most other J2EE API's.
3/ The concrete classes encapsulate a lot of RFC compliance code.
4/ We know from discussions regarding Tomcat that the behaviour of a RI
itself forms "case law" and sets precedence about the expected behaviour of
other implementations.
5/ Any acceptable copy of the JavaMail API must comply with the published
specification, being both the wordy specification and the javadocs. It must
also exhibit substantially the same behaviour as Suns product, and any
implementation must be consistent with the RI.
Now Alex says..
> The dependency is on the InvalidArgumentException and
> NullArgumentException. I originally put those in since when they become
> internationalised, changes made to those classes will have immediate
> benefit to the JavaMail API.
Alex we (and you) have no jurisdiction to make any changes whasoever to the
API, specifically including method signatures.
What is acceptable is for the internal implementation of the expected
behaviour to be implemented in any way we choose, but that any dependance
not specified by the API should be satisfied internally and not apparent in
any way to any user of the API.
That is to say we could use components from many sources, but our resulting
mailapi.jar should be a direct replacement for Sun's one with no additional
requirements.
> I do not believe that the specs package cannot include classes outside of
> the javax. namespace; indeed, the Sun RI ships with a whole bunch of
> com.sun classes as is. There isn't any reason why JavaMail couldn't ship
> with an org.apache class or two instead.
The API only consist of the javax.mail.* packages, and only depends upon
java.* and javax.*
The com.sun classes are the refrence implementation and though they depend
upon the API the API does not depend upon them.
> The issue at stake is that the bug also exists in the Sun RI.
Actually if it exists it is in the API not the RI.
You are at liberty to "fix" it but this would then be a deviation from the
API behavoiur which our user would have to be informed of, for the sake of
their sanity if nothing else.
> The absolute question is: what are we trying to achieve in the JavaMail
> API reimplementation? Copy it byte-for-byte, including any bugs that are
> present in the JavaMail implementation? Or provide something that behaves
> correctly as per the JavaDoc? My take on this is that we should implement
> to the spec, and not try to represent every bug in the RI, since the
> latter will be a moving target.
Well at least now you're beginning to realise why it is not a job to be
undertaken lightly.
> > > These may seem minor but they are symptomatic of a coding
> > > approach that may lead to other deviations and I think the
> > > entire patch should be reviewed in detail. If someone steps
> > > up to do that then it may be appropriate to commit this to a
> > > separate branch until done.
>
> Always nice not to be trusted :-)
This has little or nothing to do with trust, Apache projects are
meritocracies and operate a system of peer review.
You have allegedly made an error of judgement based upon an apparent
difficulty in understanding what is the JavaMail API and what is it's
implementation and what is appropriate for your work on each part. This
has, quite rightly, been picked up by peer review and also quite rightly it
has been suggested that the the rest of your patch be reviewed in detail in
case the same assumtions are manifested elsewhere.
We're here to do this thing correctly, whether or not that offends you.
> I have always been very careful to implement the JavaMail APIs based on
the JavaDoc
In which case why did you add a dependancy which doesn't exist there?
d.
RE: Status: JavaMail API implementation now at Alpha quality
Posted by Al...@ioshq.com.
Don't you just love free internet access at airports :-)
> > From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
> > Sent: Friday, September 12, 2003 11:04 PM
> > To: geronimo-dev@incubator.apache.org
> > Subject: RE: Status: JavaMail API implementation now at Alpha quality
> >
> > -1 for this patch because
> > a) there is a dependency on geronimo-common that is inappropriate
> > for a standalone spec module
The dependency is on the InvalidArgumentException and
NullArgumentException. I originally put those in since when they become
internationalised, changes made to those classes will have immediate
benefit to the JavaMail API.
They are fairly easily changed to throw IllegalArgumentException instead
(which is what they were originally).
I do not believe that the specs package cannot include classes outside of
the javax. namespace; indeed, the Sun RI ships with a whole bunch of
com.sun classes as is. There isn't any reason why JavaMail couldn't ship
with an org.apache class or two instead.
But this is a fairly trivial issue and could be resolved simply by moving
them back to java.lang.IAE.
> > b) a change was made to the impl of URLName.equals() that makes it
> > behave differently to the RI and which I explicitly asked Alex
> > not to make
Actually, the change was /back/ to the original implementation, from which
it was changed in the first place. The issue was in defining the equals
method as:
o instanceof URLName
instead of the more correct
o == null || o.getClass() != this.getClass()
I wrote and demonstrated a unit test to show that the equals method was
broken, (which may be why the unit test fails as above). Others may like
to try and implement the equals method differently, but the only one that
correctly passes the test case will be the getClass() variant.
Unfortunately, Josh Bloch gave the entire Java industry the impression
that using 'instanceof' is correct in his book 'Effective Java', which is
otherwise a very good Java book -- but fails dismally on the
implementation of equals method. All you have to do is look at the JavaDoc
for java.lang.Object to find out what it should do, and the instanceof
method fails two of the constraints required for a correct implementation
of equals.
The issue at stake is that the bug also exists in the Sun RI. I believe
that it is right the community should decide which is appropriate to use,
and we can use that one instead; it isn't for two people to disagree and
come up with an implementation.
The absolute question is: what are we trying to achieve in the JavaMail
API reimplementation? Copy it byte-for-byte, including any bugs that are
present in the JavaMail implementation? Or provide something that behaves
correctly as per the JavaDoc? My take on this is that we should implement
to the spec, and not try to represent every bug in the RI, since the
latter will be a moving target.
> > These may seem minor but they are symptomatic of a coding
> > approach that may lead to other deviations and I think the
> > entire patch should be reviewed in detail. If someone steps
> > up to do that then it may be appropriate to commit this to a
> > separate branch until done.
Always nice not to be trusted :-)
I've tried to code extensive unit tests for the code in the JavaMail API
to ensure that I do closely stick to the spec, including feedback from
others with JDiff about the implementation of the methods. I have always
been very careful to implement the JavaMail APIs based on the JavaDoc, and
I have not used the JavaMail binary at all during this process. Therefore,
I believe the work I have been doing is very careful and considerate
towards the specification, and I am upset by Jeremy's allegation above.
Seriously, the reason I hand't put that in before was because I was
submitting lots of small patches with detailed messages about them. This
was then slated by the cathedral, so instead I submitted an entire patch
with my work so far before going on holiday. I had wanted to bring the
discussion about the 'warts-and-all approach vs correct implementation
from JavaDoc' before submitting it later, but it got subsumed in this
approach.
I am of the opinion that the only number of patches people will be happy
with me submitting is zero; it's not worked with detailed patches, and
it's not worked with one-size-fits-all approach.
See you all after I return,
Alex.
/***************************************************************\
|* Alex Blewitt * Hug, and the world hugs with you *|
|* Alex.Blewitt@ioshq.com * *|
|* Mobile: +44 7966 158 647 * Spread a little happiness *|
\***************************************************************/
RE: Status: JavaMail API implementation now at Alpha quality
Posted by Jeremy Boynes <je...@coredevelopers.net>.
I checked the patch into branch javamail_030912 which is rooted at
specs/javamail.
Note that the raw patch places constants in the wrong directory and does
not include the changes needed to project.xml.
The branched version compiles but fails to unit test (on WinXP/Sun
JDK1.4.2) - that may be a good place to start.
This is an implementation of the JavaMail API, for which the spec is
vague - however, the RI has been around for years and should be used to
clarify any ambiguities (believe me, this is important).
Because this is a spec module, it should not have any dependency on
Geronimo-specific modules such as geronimo-common, or indeed on any
other Apache modules. We want the spec stuff to be independent.
As to other stuff, use your judgement. The two issues I described were
obvious from a quick scan of the patch file - I have not looked any
deeper than that and there may be more.
--
Jeremy
> -----Original Message-----
> From: Matt Kurjanowicz [mailto:mkurjano@cc.gatech.edu]
> Sent: Friday, September 12, 2003 8:26 PM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: Status: JavaMail API implementation now at Alpha quality
>
>
> I'll make the changes. I'll start with the two below, and if
> there's anything else that you think you would like changed,
> _please_ let me know. -Matt mkurjano at cc.gatech.edu
>
> -----Original Message-----
> From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
> Sent: Friday, September 12, 2003 11:04 PM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: Status: JavaMail API implementation now at Alpha quality
>
> -1 for this patch because
> a) there is a dependency on geronimo-common that is inappropriate
> for a standalone spec module
> b) a change was made to the impl of URLName.equals() that makes it
> behave differently to the RI and which I explicitly asked Alex
> not to make
>
> These may seem minor but they are symptomatic of a coding
> approach that may lead to other deviations and I think the
> entire patch should be reviewed in detail. If someone steps
> up to do that then it may be appropriate to commit this to a
> separate branch until done.
>
> --
> Jeremy
>
> > -----Original Message-----
> > From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> > Sent: Friday, September 12, 2003 5:46 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Status: JavaMail API implementation now at Alpha quality
> >
> >
> > I have submitted a patch [*] covering the majority of work
> > that I have
> > done on implementing the JavaMail API. Importantly, this allows
> > developers to now instantiate the MimeMessage class, and for simple
> > (text formats) messages, the MimeMessage should be usable by those
> > implementing transports/stores.
> >
> > There are some unimplemented features; it cannot yet handle
> multipart
> > messages, and there are issues with non-ASCII encodings at present.
> > Hopefully these issues will be ironed out with test cases
> that break
> > the API and thus can be fixed. I would otherwise personally
> > raise a bug
> > to record each of these cases, but I am not sure this is within the
> > standard use of the bug tracking tool by the geronimo team.
> >
> > I am off on holiday for a couple of weeks, and access is
> likely to be
> > sporadic; I won't be doing any coding in any case. I hope
> > that this set
> > of code gives other developers the necessary base framework
> > to continue
> > implementing JavaMail providers.
> >
> > Regards,
> >
> > Alex.
> >
> > [*] http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-80
> >
> >
>
>
RE: Status: JavaMail API implementation now at Alpha quality
Posted by Matt Kurjanowicz <mk...@cc.gatech.edu>.
I'll make the changes. I'll start with the two below, and if there's
anything else that you think you would like changed, _please_ let me
know.
-Matt
mkurjano at cc.gatech.edu
-----Original Message-----
From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
Sent: Friday, September 12, 2003 11:04 PM
To: geronimo-dev@incubator.apache.org
Subject: RE: Status: JavaMail API implementation now at Alpha quality
-1 for this patch because
a) there is a dependency on geronimo-common that is inappropriate
for a standalone spec module
b) a change was made to the impl of URLName.equals() that makes it
behave differently to the RI and which I explicitly asked Alex
not to make
These may seem minor but they are symptomatic of a coding approach that
may lead to other deviations and I think the entire patch should be
reviewed in detail. If someone steps up to do that then it may be
appropriate to commit this to a separate branch until done.
--
Jeremy
> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> Sent: Friday, September 12, 2003 5:46 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Status: JavaMail API implementation now at Alpha quality
>
>
> I have submitted a patch [*] covering the majority of work
> that I have
> done on implementing the JavaMail API. Importantly, this allows
> developers to now instantiate the MimeMessage class, and for simple
> (text formats) messages, the MimeMessage should be usable by those
> implementing transports/stores.
>
> There are some unimplemented features; it cannot yet handle multipart
> messages, and there are issues with non-ASCII encodings at present.
> Hopefully these issues will be ironed out with test cases that break
> the API and thus can be fixed. I would otherwise personally
> raise a bug
> to record each of these cases, but I am not sure this is within the
> standard use of the bug tracking tool by the geronimo team.
>
> I am off on holiday for a couple of weeks, and access is likely to be
> sporadic; I won't be doing any coding in any case. I hope
> that this set
> of code gives other developers the necessary base framework
> to continue
> implementing JavaMail providers.
>
> Regards,
>
> Alex.
>
> [*] http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-80
>
>
RE: Status: JavaMail API implementation now at Alpha quality
Posted by Jeremy Boynes <je...@coredevelopers.net>.
-1 for this patch because
a) there is a dependency on geronimo-common that is inappropriate
for a standalone spec module
b) a change was made to the impl of URLName.equals() that makes it
behave differently to the RI and which I explicitly asked Alex
not to make
These may seem minor but they are symptomatic of a coding approach that
may lead to other deviations and I think the entire patch should be
reviewed in detail. If someone steps up to do that then it may be
appropriate to commit this to a separate branch until done.
--
Jeremy
> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> Sent: Friday, September 12, 2003 5:46 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Status: JavaMail API implementation now at Alpha quality
>
>
> I have submitted a patch [*] covering the majority of work
> that I have
> done on implementing the JavaMail API. Importantly, this allows
> developers to now instantiate the MimeMessage class, and for simple
> (text formats) messages, the MimeMessage should be usable by those
> implementing transports/stores.
>
> There are some unimplemented features; it cannot yet handle multipart
> messages, and there are issues with non-ASCII encodings at present.
> Hopefully these issues will be ironed out with test cases that break
> the API and thus can be fixed. I would otherwise personally
> raise a bug
> to record each of these cases, but I am not sure this is within the
> standard use of the bug tracking tool by the geronimo team.
>
> I am off on holiday for a couple of weeks, and access is likely to be
> sporadic; I won't be doing any coding in any case. I hope
> that this set
> of code gives other developers the necessary base framework
> to continue
> implementing JavaMail providers.
>
> Regards,
>
> Alex.
>
> [*] http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-80
>
>