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 2006/01/03 17:57:42 UTC
Review/Help for Phoenix trunk upgrade (Noel?)
Hi all, expecially Noel,
I just finished re-upgrading my local copy to the phoenix in this branch:
https://svn.apache.org/repos/asf/avalon/cvs-migration-snapshot/avalon-phoenix/
I'm ready to commit build.xml changes and phoenix-bin but as many
libraries are changed maybe someone would like to test it before I
change the whole phoenix-bin folder.
What should I do?
Should I commit anyway and eventually we will revert the commit or
should I package my phoenix-bin and put somewhere so you can test it? I
also added a txt file with changes over the "clean" svn branch above.
Noel, this upgrade would allow me to fix the last issue I planned to fix
before the first alpha/beta of James 2.3.0 (classloader issues). If we
upgrade to phoenix-trunk I can remove all the specific code in our
Loader and leave this task to the container.
Can you update us on you plans?
This upgrade and the last 2 patches (CopyOnWriteProxy for mimemessages
and POP3handler using getRawInputStream instead if getInputStream) are
"critical" (more than most of the changes I made in past) so we probably
need to rerun a few tests before the release. I thought about moving
these issues to 3.0 but IMHO they are too critical to release 2.3.0
without them.
What other committers think?
About "tests" I felt free to commit the good starting work from Bernd
because it does not change our release cycle and helped me with the
CopyOnWriteProxy tests that I was writing. We will discuss how to handle
the ristretto/junit jar later! (IIRC latest news from Apache said that
we can ship MPL jars if there is full consensus by committers).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Review/Help for Phoenix trunk upgrade (Noel?)
Posted by Stefano Bagnara <ap...@bago.org>.
>> I'm ready to commit build.xml changes and phoenix-bin but as many
>> libraries are changed maybe someone would like to test it before I
>> change the whole phoenix-bin folder.
>
>> Should I commit anyway and eventually we will revert the commit
>
> Sure.
I just committed the new libraries and closed the last issue blocking
2.3.0 (JAMES-418).
I still have an issue with derby using dbfile for spoolrepository that I
exposed but I had no time to create a test as a proof of the bug. I will
try to do something about this.
I'm sorry I had no time to upgrade my personal server and test the
version currently in trunk but I preferred to share what I had now
because I'm not sure about my spare time in the next days/weeks: maybe
someone else will download the current version and run few tests.
Stefano
PS: I haven't copied the avalon-phoenix svn under james because I want
to be sure we stick to that release before. I don't know phoenix enough
to patch the source code so I think that moving phoenix sources under
james will not help james by now. BTW we can "clone" the source tree (as
reference?) if we decide to keep the updated phoenix.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Review/Help for Phoenix trunk upgrade (Noel?)
Posted by Stefano Bagnara <ap...@bago.org>.
>>>And perhaps work towards Committer status.
>>> :-)
>
> Well, having others doing the review-and-commit-job for me is quite
> convenient... ;-)
> Stefano, thank you again for picking this stuff up.
>
> Question: Should I create a new JIRA issue for every future patch or
> keep attaching to existing issue JAMES-427?
If you plan to upload many small patches I think it's better to leave
the issue "in progress" and to keep uploading the patch to the same issue.
If you plan to upload few big patches we can also create new issues.
Maybe a mix between the 2 approach is the best: I don't want to keep the
issue opened for years, so you should continue adding patches to that
issues by now and eventually we will close it for 2.3.0 release and
create a new one for the future.
I want to thank you again for your patch introducing unit testing: I
really feel better working with tests and I already started updating
them when possible!
PS: My patch for the "MAIL FROM SIZE" behaviour in the MAIL handler for
SMTPServer applied yesterday broke the mail size test that I just
updated (it's part of my last patch for the "CRLF.CRLF" issue). It does
make sense to me but feel free to review my fix.
>> It would be cool to have more people working on the sources!
>> I don't know much about but I remember that a few tests was already
>> present in the old "merger" branch. I'm not sure wether they can easily
>> ported to the current trunk or not, maybe Bernd would like to look at
>> them:
>> http://svn.apache.org/repos/asf/james/server/tags/pre-v2and3-merger-trunk/tests/
>>
>
> Oh, I didn't know that. I'll have a look.
I became a committer after the referenced merge and I don't know much
about previous code (proposals, tests, history).
I simply saw that folder a few months ago looking for the history of a
class prior to the merge.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Review/Help for Phoenix trunk upgrade (Noel?)
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Stefano Bagnara wrote:
>>>I thought about moving these issues to 3.0 but IMHO they are
>>>too critical to release 2.3.0 without them.
>>
>>And this is part of why I keep thinking that we should call this release
>>3.0.
>
>
> I'm still for 2.3.0 but I'm aware that this is a personal preference.
> I'm not -1 for a 3.0 versioning scheme.
> This latest changes are mostly bugfixes that should be invisibile to the
> users: they need "critical" changes in the code but I think that the
> version is a number for the users and not for developers and, as such, I
> feel 2.3.0 better reflects this release.
As a user I would expect major changes when jumping from 2.x to 3.0,
maybe accompanied by introduction of new features and incompatible
changes in APIs and config files. As long as this is not the case I
would stick with 2.3 to stay in sync with expectations.
>
> We have a few major steps beyond:
> - remove javamail dependency from Mailet API / James?
> - remove avalon dependency?
> - change the repository interfaces?
>
> I don't know wether we'll be able to implement one or more of them, but
> even if we add just one of them then we would need a major version, so I
> would avoid to start using only the first number of our product version :-)
>
>
>>>About "tests" I felt free to commit the good starting work from Bernd
>>
>>Given the volume of work we're getting from Bernd, I'd like to ask if he
>>would please submit a CLA. :-)
OK, no problem. :-)
>>And perhaps work towards Committer status.
>>:-)
Well, having others doing the review-and-commit-job for me is quite
convenient... ;-)
Stefano, thank you again for picking this stuff up.
Question: Should I create a new JIRA issue for every future patch or
keep attaching to existing issue JAMES-427?
>
>
> It would be cool to have more people working on the sources!
> I don't know much about but I remember that a few tests was already
> present in the old "merger" branch. I'm not sure wether they can easily
> ported to the current trunk or not, maybe Bernd would like to look at them:
> http://svn.apache.org/repos/asf/james/server/tags/pre-v2and3-merger-trunk/tests/
Oh, I didn't know that. I'll have a look.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Review/Help for Phoenix trunk upgrade (Noel?)
Posted by Stefano Bagnara <ap...@bago.org>.
> Yes, the copy-on-write behavior is the one that I am most concerned about
> from the perspective of performance and memory footprint.
About performance it is one more call for every mimemessage method to
read and 3 more calls (simple method calls) for every mimemessage write
methods. These is not reflection or other "slow" stuff.
About memory footprint the wrapper should be almnost invisible (it only
store a reference to the real mimemessage and a reference to a
referenceCounter. The referenceCounter simply introduce an "int" value.
I added tests to be sure that the real mimemessage is not duplicated
every time it's possible to know it's no more shared.
Anyway this is a critical bug fix so we can't trade it for performances:
The whole proxy has been introduced to make the fix as performant as
possible but the previous behaviour was wrong.
Maybe (I hadn't investigated on that) that the new proxy will help us in
some optimization elsewhere.
A minor performance improvement would be to create a third wrapped that
merge the features of MimeMessageWrapper and MimeMessageCopyOnWriteProxy
so that we don't need a double proxy for messages read from the
repositories. I did not run performance tests but I'm confident that the
performance loss is almost unrecognizable.
> I haven't looked,
> but it is an interesting question whether or not the Message-ID should be
> changed, too. But that really depends upon the nature of a change, and is
> entirely application semantic dependent.
Probably the best thing would be to change the message-id every time the
proxy detect the need for a new copy and create it.
> The recent change to SMTP and POP3 may also fix an older and relatively
> boring issue that a totally empty message, i.e., DATA<CR><LF>.<CR><LF> would
> not be supported. We'll have to test it.
I committed them to have a direct reference to the patch but I think we
should not ship the next version with this change. This, hopefully, fix
the issues but introduce a "serious" backward compatibility issue that
we avoided in past. This release is storage compliant with 2.2.0 if we
don't break this with that patch. My spare-time is almost finished but I
plan to look at the possible MimeMessageWrapper workaround to this
problem. Or maybe we should leave this patch in and simply check for the
ending CRLF in the mimemessagewrapper and eventually add it if missing.
>> I thought about moving these issues to 3.0 but IMHO they are
>> too critical to release 2.3.0 without them.
>
> And this is part of why I keep thinking that we should call this release
> 3.0.
I'm still for 2.3.0 but I'm aware that this is a personal preference.
I'm not -1 for a 3.0 versioning scheme.
This latest changes are mostly bugfixes that should be invisibile to the
users: they need "critical" changes in the code but I think that the
version is a number for the users and not for developers and, as such, I
feel 2.3.0 better reflects this release.
We have a few major steps beyond:
- remove javamail dependency from Mailet API / James?
- remove avalon dependency?
- change the repository interfaces?
I don't know wether we'll be able to implement one or more of them, but
even if we add just one of them then we would need a major version, so I
would avoid to start using only the first number of our product version :-)
>> About "tests" I felt free to commit the good starting work from Bernd
>
> Given the volume of work we're getting from Bernd, I'd like to ask if he
> would please submit a CLA. :-) And perhaps work towards Committer status.
> :-)
It would be cool to have more people working on the sources!
I don't know much about but I remember that a few tests was already
present in the old "merger" branch. I'm not sure wether they can easily
ported to the current trunk or not, maybe Bernd would like to look at them:
http://svn.apache.org/repos/asf/james/server/tags/pre-v2and3-merger-trunk/tests/
>> We will discuss how to handle the ristretto/junit jar later!
>> (IIRC latest news from Apache said that we can ship MPL jars
>> if there is full consensus by committers).
>
> We can run this by Cliff.
>
> --- Noel
Sorry, what/who is Cliff?
To complete my previous statement I think that if we limit the ristretto
usage to tests we can also avoid to include the libraries in our repository.
Developers could simply download the jar from the site (as we already do
with javamail and activation).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Review/Help for Phoenix trunk upgrade (Noel?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano,
> I just finished re-upgrading my local copy to the phoenix in this branch
>
https://svn.apache.org/repos/asf/avalon/cvs-migration-snapshot/avalon-phoeni
x/
I think that Peter Royal has a good basic point about keeping our own copy.
If we use his, or just the code from Avalon, we can maintain it under james
source control, although as a separate, entirely internal, project.
In your case, that would mean something like:
svn mkdir https://svn.apache.org/repos/asf/james/avalon-platform
svn mkdir https://svn.apache.org/repos/asf/james/avalon-platform/phoenix
svn cp \
https://svn.apache.org/repos/asf/avalon/cvs-migration-snapshot/avalon-phoe
nix/
https://svn.apache.org/repos/asf/james/avalon-platform/phoenix/trunk
Similar for any other Avalon components that we want to use that need to be
properly tagged for our releases.
According to Peter, "What I had sent was an older CVS checkout, the code in
the svn url above is a bit newer, but very similar." Can you check to see
what differences exist between the code you are now using, and Peter's? If
the consensus is that we should use what's in SVN, the above approach should
be OK.
> I'm ready to commit build.xml changes and phoenix-bin but as many
> libraries are changed maybe someone would like to test it before I
> change the whole phoenix-bin folder.
> Should I commit anyway and eventually we will revert the commit
Sure.
> this upgrade would allow me to fix the last issue I planned to fix
> before the first alpha/beta of James 2.3.0 (classloader issues). If
> we upgrade to phoenix-trunk I can remove all the specific code in our
> Loader and leave this task to the container.
OK
> Can you update us on you plans?
I've been tracking your changes, and figured that the short time it was
taking to get them into source control was well spent.
> This upgrade and the last 2 patches (CopyOnWriteProxy for mimemessages
> and POP3handler using getRawInputStream instead if getInputStream) are
> "critical"
Yes, the copy-on-write behavior is the one that I am most concerned about
from the perspective of performance and memory footprint. I haven't looked,
but it is an interesting question whether or not the Message-ID should be
changed, too. But that really depends upon the nature of a change, and is
entirely application semantic dependent.
The recent change to SMTP and POP3 may also fix an older and relatively
boring issue that a totally empty message, i.e., DATA<CR><LF>.<CR><LF> would
not be supported. We'll have to test it.
> I thought about moving these issues to 3.0 but IMHO they are
> too critical to release 2.3.0 without them.
And this is part of why I keep thinking that we should call this release
3.0.
> About "tests" I felt free to commit the good starting work from Bernd
Given the volume of work we're getting from Bernd, I'd like to ask if he
would please submit a CLA. :-) And perhaps work towards Committer status.
:-)
> We will discuss how to handle the ristretto/junit jar later!
> (IIRC latest news from Apache said that we can ship MPL jars
> if there is full consensus by committers).
We can run this by Cliff.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org