Am Sonntag, den 12.11.2006, 17:26 + schrieb robert burrell donkin:
> there an issue on evolution startup: StatusCommand is called before a
> mailbox has been selected. however, reading the specification at the
> bottom (cool), i don't think that status should act upon the selected
> mailbox at
On 11/12/06, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 11/8/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
> > So we'll wait for further news from you in the next weeks. Thank you for
> > the update.
>
> You are welcome :-)
Thanks again! I read the howto and it looks pretty straight forwa
Hi Noel.
See below...
Kind regards
Juergen
Von: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Jürgen Hoffmann wrote:
> I think Testing is very important.
So do I. That's why I added run-unit-tests to the dist target. And why I
added support for running specific tests during development --- so
Hi!
I don't think that it is an indicator of quality to have always 100% of
tests passing.
In other words: It's not a problem to create a lot of tests that pass.
There often are known bugs for a long time, some of them not even
documented anywhere.
It's all right to have open bugs in the issu
Am Samstag, den 11.11.2006, 01:02 +0100 schrieb Bernd Fondermann:
> > Except for one thing ... a build takes a few seconds, even from scratch, and
> > the unit tests take anywhere from 3 minutes on up, especially the very slow
> > IMAP-related tests.
>
> Slow tests are a unit test anti-pattern on
On 11/11/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Bernd suggested it specifically because he felt that Committers are not
running the tests before committing changes. I don't actually think that
has been a significant problem. Perhaps Bernd's suggestion was inspired by
the recent change I
On 11/13/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Hi!
IMO a failing test is as valuable as a passing one. Maybe even more
because it reminds us to do something.
I don't think that it is an indicator of quality to have always 100% of
tests passing.
My unit test 1x1 says: test runs h
On 11/11/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Bernd Fondermann wrote:
> Just out of curiosity, how is this done? Simply by going to the DB
> everytime?
>
> There is no management command for this, right?
We currently have 4 implementations of the DomainList service:
DomainList
|- JDBC
Hi Miroslav,
The server-dev list is excellent for discussing this, so I refrain
from commenting directly in JIRA.
On 11/11/06, Miroslav Nachev (JIRA) wrote:
Replacement of Avalon with something new, modern and perspective technology
-
Bernd Fondermann wrote:
On 11/11/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
The XMLDomainList is manageable but dynamic changes are not persisted.
There is no management code yes, but it should be feasible to add the
management bean and the relative remotemanager "extension" via the
Managea
Stefano Bagnara schrieb:
> Bernd Fondermann wrote:
>> On 11/11/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>>> The XMLDomainList is manageable but dynamic changes are not persisted.
>>>
>>> There is no management code yes, but it should be feasible to add the
>>> management bean and the relative
Bernd Fondermann wrote:
On 11/13/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Hi!
IMO a failing test is as valuable as a passing one. Maybe even more
because it reminds us to do something.
I don't think that it is an indicator of quality to have always 100% of
tests passing.
My unit t
[
http://issues.apache.org/jira/browse/JAMES-670?page=comments#action_12449335 ]
Stefano Bagnara commented on JAMES-670:
---
I see this feature changed more code than I thought.
I would prefer it to be contained in a different class, is it po
Stefano Bagnara schrieb:
>
>>> I don't consider slow tests as bad tests. They are just inappropriate
>>> for a ad hoc results. Even if they took an hour it's okay, but we need
>>> to find a way not to force people to run them all the time.
>>
>> Not agreed. According to my experience unit tests s
[
http://issues.apache.org/jira/browse/JAMES-670?page=comments#action_12449337 ]
Norman Maurer commented on JAMES-670:
-
Sure its possible.. I also thought about this before i did the changes.. But
remember that whould also need changes to as
[
http://issues.apache.org/jira/browse/JAMES-679?page=comments#action_12449339 ]
Stefano Bagnara commented on JAMES-679:
---
Ok to change the 10 with 0.
About the setProperty: I think this property belong to the container, so I
think we shoul
I think that it won't help us to create unit tests for the JVM ;-)
A similar test would not prevent us from using again InetAddress the
wrong way, so we don't need it.
If Noel investigated on it and made sure that we misused the InetAddress
cache it is enough for me: we *misused* the InetAddr
I think that the 2 features are overlapping and it would be much better
to expose the simpler in config.xml and leave the other in alternative
classes/packages.
I think that an overall "connections per ip" limit is better and enough
for most users and the "connections per service per ip" won't
Author: norman
Date: Mon Nov 13 04:35:50 2006
New Revision: 474281
URL: http://svn.apache.org/viewvc?view=rev&rev=474281
Log:
Create more junit tests for JunkScorehandler, create JunkScoreConfigUtil and
fix some bugs. Second part for JAMES-614
Added:
james/server/trunk/src/java/org/apache/j
Author: norman
Date: Mon Nov 13 04:37:51 2006
New Revision: 474282
URL: http://svn.apache.org/viewvc?view=rev&rev=474282
Log:
Fix format
Modified:
james/server/trunk/src/java/org/apache/james/util/junkscore/ComposedJunkScore.java
james/server/trunk/src/java/org/apache/james/util/junksco
Author: norman
Date: Mon Nov 13 04:38:51 2006
New Revision: 474283
URL: http://svn.apache.org/viewvc?view=rev&rev=474283
Log:
Fix tests(Sorry forgot it)
Modified:
james/server/trunk/src/test/org/apache/james/util/junkscore/JunkScoreConfigUtilTest.java
Modified:
james/server/trunk/src/test/
BTW... Which slow test ? It takes 46 Seconds here to run all tests .. So
whats the problem ?
If someone really still use a 686 with 66 MHz its time to upgrade the
hardware :-P
bye
Norman
Norman Maurer schrieb:
> Stefano Bagnara schrieb:
>
>
>
I don't consider slow tests as bad tests. Th
Author: norman
Date: Mon Nov 13 06:27:49 2006
New Revision: 474332
URL: http://svn.apache.org/viewvc?view=rev&rev=474332
Log:
Change tests to be junit 3.8.1 compatible. Thx to Stefano to pointin out
Modified:
james/server/trunk/src/test/org/apache/james/util/junkscore/ComposedJunkScoreTest.j
[EMAIL PROTECTED] wrote:
Author: norman
Date: Mon Nov 13 06:27:49 2006
New Revision: 474332
URL: http://svn.apache.org/viewvc?view=rev&rev=474332
Log:
Change tests to be junit 3.8.1 compatible. Thx to Stefano to pointin out
Well, let's thank again Continuum ;-)
I only read the failure notifica
Author: norman
Date: Mon Nov 13 07:17:36 2006
New Revision: 474366
URL: http://svn.apache.org/viewvc?view=rev&rev=474366
Log:
Some small code improvments
Modified:
james/server/trunk/src/java/org/apache/james/util/connection/ConnectionPerIpMap.java
james/server/trunk/src/java/org/apache
Am Montag, den 13.11.2006, 12:00 +0100 schrieb Bernd Fondermann:
> > IMO a failing test is as valuable as a passing one. Maybe even more
> > because it reminds us to do something.
>
> > I don't think that it is an indicator of quality to have always 100% of
> > tests passing.
>
> My unit test 1x
Am Montag, den 13.11.2006, 12:58 +0100 schrieb Stefano Bagnara:
> > But intended-to-fail failing tests obscures all
> > oops-something-bad-happened failing tests.
>
> Right. This is the BIG problem of failing tests.
Okay, but I don't think that not writing, not executing or inverting
them is be
ran into a few issues an unimplemented torque method (search) causing
searchcommand to fail with a null pointer. IMHO clearer to log and
return an empty array. (i'll post a patch.)
but this brings me to logging. most of james uses the avalon logging
framework. torquemailbox seems to use commons l
Improve reporting for unimplementation torquemailbox method
---
Key: JAMES-690
URL: http://issues.apache.org/jira/browse/JAMES-690
Project: James
Issue Type: Bug
Components: I
[ http://issues.apache.org/jira/browse/JAMES-690?page=all ]
Robert Burrell Donkin updated JAMES-690:
Attachment: james-torque-reporting.patch
Patch adds logging and return empty results to avoid null pointer from
unimplemented method
> Improve
The Imap code has been revamped by Joachim and in the mean time joachim
tried to isolate the avalon/phoenix code to wrappers to be used with
james while keeping the main code "avalon free".
It uses commons-logging and commons-configuration wrappers to
avalon-logger and avalon configurations.
Joachim Draeger wrote:
Am Montag, den 13.11.2006, 12:58 +0100 schrieb Stefano Bagnara:
But intended-to-fail failing tests obscures all
oops-something-bad-happened failing tests.
Right. This is the BIG problem of failing tests.
Okay, but I don't think that not writing, not executing or inver
Joachim Draeger wrote:
Am Montag, den 13.11.2006, 12:00 +0100 schrieb Bernd Fondermann:
IMO a failing test is as valuable as a passing one. Maybe even more
because it reminds us to do something.
I don't think that it is an indicator of quality to have always 100% of
tests passing.
My unit test
[ http://issues.apache.org/jira/browse/JAMES-688?page=all ]
Stefano Bagnara updated JAMES-688:
--
Component/s: (was: James Core)
Issue Type: New Feature (was: Improvement)
Fix Version/s: (was: 2.3.1-dev)
Removed the fix version,
chan
Search & Fix broken links on the new website
Key: JAMES-691
URL: http://issues.apache.org/jira/browse/JAMES-691
Project: James
Issue Type: Bug
Reporter: Stefano Bagnara
Assign
Hi Robert,
Am Montag, den 13.11.2006, 21:02 + schrieb robert burrell donkin:
> ran into a few issues an unimplemented torque method (search) causing
> searchcommand to fail with a null pointer. IMHO clearer to log and
> return an empty array. (i'll post a patch.)
That sounds like a good idea
Hi!
Am I hitting another controversy topic? ;-)
Example from ImapHandler.java
catch ( IOException e ) {
if ( getLogger().isErrorEnabled() ) {
StringBuffer exceptionBuffer =
new StringBuffer( 256 )
.append( "Cann
37 matches
Mail list logo
