> I'm not sure I would like to use phoenix-trunk: does any
> other project use it?
Does anyone use LOOM?
>From what Peter Royal told me, I understood that development on LOOM is
dead. And we don't have access to the code. I'd like to hear from Peter
regarding Loom vs Phoenix, but he seemed will
> > We also, in the last month:
> > - updated all of our libraries
> > (cornerstone/avalon/excalibur/dnsjava/javamail)
> > - updated phoenix (so as you can see we already "changed" the
> > container)
>
> For me, a container change *has a big impact* (specially
> because it is a partially "dead"
> Ok, my view is that we should release a firts and last alpha
> now and start the beta cycle :-)
I agree, but I don't think we should stop and wait for a release. We should
just move forward as much as possible and when someone with rights/knowledge
to do the release (probably Noel in mid octobe
Hi, I need know about the state of James V3.0, because I need a java IMAP
Server. Can I get the source for use/test/etc it? or It's very unstable?
In the subversion repository (http://svn.apache.org/repos/asf/james/server/)
there's only James 2, what's the subversion/cvs location for james3?
t
Awesome stuff. Glad someone was finally able to track that one down.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
On 9/7/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> I've just committed a patch I created today.
Ok, my view is that we should release a firts and last alpha now and start the
beta cycle :-)
Vincenzo
Stefano Bagnara wrote:
I thought the 2.3.0 release was coming up shortly?
You mean that it is the right time to put Loom in, just
before releasing the RCs for 2.3.0. Is it correct that your
Stefano Bagnara wrote:
Not totally true, as I think that some people (like myself)
has been thoroughly testing even in production the contents
of svn. Specially after Noel's work in May, which has been a
major (and potentially risky) update impacting the whole
system ... And James looked quite
> I thought the 2.3.0 release was coming up shortly?
>
> You mean that it is the right time to put Loom in, just
> before releasing the RCs for 2.3.0. Is it correct that your
> point is that real testing will be done with the RCs, not
> with the trunk?
>
> Cheers,
Let me explain what is the r
I've just committed a patch I created today.
The bug was both in file repositories and db repositories.
Db repositories never sleeps forever so you simply had 60 seconds delay when
the notification didn't work.
Adding a Thread.sleep(1000) after each notify() you can easily add evidence
to notific
> > The fact that has passed an year since the 2.2.0 does not
> mean we made
> > testing an year of tests on the current trunk. *real time* is not a
> > variable for trunk stability.
> >
>
> I thought the 2.3.0 release was coming up shortly?
>
> You mean that it is the right time to put Loom
Author: bago
Date: Wed Sep 7 08:43:55 2005
New Revision: 279353
URL: http://svn.apache.org/viewcvs?rev=279353&view=rev
Log:
Fix for repository locks/notification/synchronization.
I've done stress-test and test with Thread.sleep() after the notifications to
ensure it is working but this is delica
> Not totally true, as I think that some people (like myself)
> has been thoroughly testing even in production the contents
> of svn. Specially after Noel's work in May, which has been a
> major (and potentially risky) update impacting the whole
> system ... And James looked quite stable after
Stefano Bagnara wrote:
In general I prefer to do big changes just after a release,
not just before... which in any case would not make such a
difference if releases are made often.
WE ARE just after a release as we never released an alpha of 2.3.0 release
and the last release (2.2.0) was a fi
Not totally true, as I think that some people (like myself) has been thoroughly testing even in production the contents
of svn. Specially after Noel's work in May, which has been a major (and potentially risky) update impacting the whole
system ... And James looked quite stable after that.
Vinc
Hes Siemelink wrote:
Stefano Bagnara wrote:
On the whole it sounds like a good plan, but I would not do it for
the upcoming release.
Why?
It helps fixing current bugs (see classloader issues).
Since this change has impact on the entire product, there might be
more issues. It needs a to
> In general I prefer to do big changes just after a release,
> not just before... which in any case would not make such a
> difference if releases are made often.
WE ARE just after a release as we never released an alpha of 2.3.0 release
and the last release (2.2.0) was a final.
The fact that
Stefano Bagnara wrote:
On the whole it sounds like a good plan, but I would not do
it for the upcoming release.
Why?
It helps fixing current bugs (see classloader issues).
Since this change has impact on the entire product, there might be more
issues. It needs a to be tested thoroughly and
> >>I have now tried to downgrade to 2.2.0, and I cannot reproduce the
> >>effect there (only tried filerepositories on this version).
> >
> >This is strange because I experienced exactly the same
> identical issue.
> >
> I never such issue with file repositories in my company production
> syste
Stefano Bagnara wrote:
I have now tried to downgrade to 2.2.0, and I cannot
reproduce the effect there (only tried filerepositories on
this version).
This is strange because I experienced exactly the same identical issue.
I never such issue with file repositories in my company produ
You can start a subscription for an alternate address,
for example "[EMAIL PROTECTED]", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<[EMAIL PROTECTED]>
To stop subscription for this address, mail:
<[EMAIL PROTECTED]>
In both cases, I'll send a confirmatio
I at least cannot reproduce the behaviour, which lead to this patch any
longer.
I will do some more tests, and report if any anomalies occur.
--Søren
On Wednesday 07 September 2005 12:53, Stefano Bagnara wrote:
> I just committed my patch to AvalonMailRepository.
>
> IMHO this is a critical chan
The mail you send to [EMAIL PROTECTED] must be sent
from the address subscribed to the list.
You can check what is your address looking one of the mails header:
Return-Path:
<[EMAIL PROTECTED]>
Stefano
> Before asking the question, make sure I've tried to post anto
> the majordomo unsubscribe
Dear all,
Before asking the question, make sure I've tried to post anto the
majordomo unsubscribe address given at the bottom of emails using the
email I subscribed with ... But this is not working as I am still
getting the ML posts in my inbox !
Any other solutions ? I mean something that we can
I just committed my patch to AvalonMailRepository.
IMHO this is a critical change and we should test it a lot before the
release.
I'm now trying the same chages in the JDBCMailRepository to see if this
removes the "delay".
Stefano
> > I also tried using Derby/db on trunk, and saw "just" the del
Author: bago
Date: Wed Sep 7 03:38:57 2005
New Revision: 279294
URL: http://svn.apache.org/viewcvs?rev=279294&view=rev
Log:
Changed the notification/synchronization policy in AvalonMailRepository.
I've ran a stress-test and it worked better than before, but the stresstest
doesn't check correctne
> I have now tried to downgrade to 2.2.0, and I cannot
> reproduce the effect there (only tried filerepositories on
> this version).
This is strange because I experienced exactly the same identical issue.
> I also tried using Derby/db on trunk, and saw "just" the delay.
This is "known".
> I w
I have now tried to downgrade to 2.2.0, and I cannot reproduce the effect
there (only tried filerepositories on this version).
I also tried using Derby/db on trunk, and saw "just" the delay.
I will try out your patch.
--Søren
On Wednesday 07 September 2005 11:30, Stefano Bagnara wrote:
> > > C
> > Can you try downgrading to 2.2.0 and verify wether the
> issue is there
> > or not?
>
> Will do that today.
>
> > Can you try using db/derby to check wether the issue is
> there or not?
> >
>
> Sure.
I'm testing a patch to both JDBC and Avalon repositories.
It seems working better than b
> On the whole it sounds like a good plan, but I would not do
> it for the upcoming release.
Why?
It helps fixing current bugs (see classloader issues).
> And why is there a 1.0RC3 that hasn't seen development in six months?
> Will there be a 1.0 release at all?
Maybe no, but I would feel bett
Stefano Bagnara wrote:
Should we move to Loom?
I've tested it today and the changes I had to do in order to run inside Loom
have been:
1) remove all the spaces from XML: loom does not automatically remove spaces
so leaving the spaces in the config means misconfiguration.
This should be fixed..
> Again to me, if we get rid of the whitespace issue so we can
> basically use the same configuration file, this seems like a
> change worth discussing.
I think we should first discussing then try to make it work.
I don't want to loose time "hacking" loom and then stop against a -1.
I will work
On 9/7/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> I've already said this a lot of time: it will take A LOT of time to move
> away from avalon/cornerstone/excalibur. IMHO it would be really a big
> mistake to continue to think to that move as a near move. I'm almost sure
> that james will cont
On 9/7/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > > - I've not been able to run james in "Phoenix trunk"
> >
> > Peter Royal indicated that he would help us with any Phoenix
> > changes that we really needed.
>
> I'm not sure I would like to use phoenix-trunk: does any other project use
>
> > Should we move to Loom?
>
> Not if it means some of the things you noted. I am
> particularly not keen to start using more excalibur code
> instead of Jakarta Commons code.
IMHO this is not more dependency on excalibur code! We already using that
jar: using that class we could remove our d
I am with Noel on this. We should not do anything that means we get tied more
to Avalon/Excalibur.
On the other hand I liked the advantages a lot, as I have experienced massive
classloader problems with Phoenix, I do a lot of dynamic reloading of .sar's
and on Windows this leads to lost handles
> You move fast Stefano! I was about to commit my fix for it,
> when I ran into the SpoolManager issues.
> I will compare our fixes :-)
Feel free to overwrite my changes with yours! Mine has been a really fast
fix.
I will run my test against your code, eventually!
Stefano
PS: sorry, I've seen y
> > - I've not been able to run james in "Phoenix trunk"
>
> Peter Royal indicated that he would help us with any Phoenix
> changes that we really needed.
I'm not sure I would like to use phoenix-trunk: does any other project use
it?
I feel really better with loom. It just reported good errors
On Tuesday 06 September 2005 15:25, Stefano Bagnara wrote:
> > > I'm experiencing spooling issues with file repositories too.
> >
> > Well, I haven't until now :-(
>
> Can you try downgrading to 2.2.0 and verify wether the issue is there or
> not?
Will do that today.
> Can you try using db/derby
On Tuesday 06 September 2005 15:12, Stefano Bagnara wrote:
> > I am having trouble with the JamesSpoolManager in the trunk.
> > I experience mails hanging in the spool, it looks like the
> > offending piece of code is the return statement in line 418.
> > The reason I suspect that line is that I ca
You move fast Stefano! I was about to commit my fix for it, when I ran into
the SpoolManager issues.
I will compare our fixes :-)
--Søren
On Wednesday 07 September 2005 00:34, Stefano Bagnara (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/JAMES-413?page=all ]
>
> Stefano Bagnara res
40 matches
Mail list logo
