On Jul 12, 2006, at 5:15 PM, Stefano Bagnara wrote:
peter royal wrote:
On Jul 12, 2006, at 3:34 PM, Norman Maurer wrote:
anyone had get it to work to get the slf4j logs logged with
avalon ? I
know there is a wrapper. If it works like aspected we will maybe
switch
to slfj for jSPF ..
You'll
Stefano Bagnara wrote:
> That said you once said that we could deprecate things in a version and
> change them in the following one.
I seem to recall saying that is what a particular large vendor does, and I
wouldn't have much of an issue with it. But if a user raises a concern, I'd
support i
Noel J. Bergman wrote:
Sure: if we aggree that they should be removed then we should add a
"deprecate" tag in the current 2.3 release and remove them in our
trunk for the next release.
Have you noticed how slowly Sun *ever* removes deprecated code? I would remove
such optional pieces (matche
Hi,
Must say that I feel a little uncomfortable with this vote, as many of the
issues IMO needs more discussion/investigation before calling a vote, but I
will play along and vote.
Also there are issues I rather saw moving like: getting rid of JavaMail :-)
On Thursday 13 July 2006 16:48, Stef
Bernd Fondermann wrote:
On 7/13/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Hi all,
This is a test, I hope it will work because I don't see another simple
solution to move forward from the current stall.
It's a vote, not a test, isn't it? ;-)
It is a test because it is not an "official"
Noel J. Bergman wrote:
You might want to have some discussion on each item before calling for a
vote. In some of these cases, there may be alternatives to the choices you
listed.
Example votes
-1 or +1 are the only meaningful votes at the ASF.
I think I really well explained what was the g
PGP detached sigs for source links 404. to fix s/sources/source/
(i had intended to submit this change as a patch but the documentation on
building and changing the documentation seems a little out of date. i found
the site directory but it isn't clear whether the contents are generated)
- rober
> I don't see another simple solution to move forward from the current
stall.
What stall? We're certainly not going to design an API by voting first and
working second.
Meantime, we are making very fine progress on the protocol handler
revisions, which should clear the way to relatively easy sup
> Ok i finished my "reorganize" of the packages and classes.
I don't know that you took out the configuration of the pre and post
handlers. The configuration should be soft. Those are only two lines, and
should be put back in. We can always detect if we are missing something,
and log a message
Stefano wrote:
>> AvalonListserv.java (2 matches)
> AvalonListservManager.java (2 matches)
Obsolete and ready to deprecate, IMO.
>>> I love to remove code: can we remove those from trunk?
>>> Wait: deprecate != remove. I'm using AvalonListserv and
>> AvalonListservManager quite exten
You might want to have some discussion on each item before calling for a
vote. In some of these cases, there may be alternatives to the choices you
listed.
> Example votes
-1 or +1 are the only meaningful votes at the ASF.
> A. Deprecate phoenix
+1 But in what timeframe? I am in no rush. Pe
On 7/13/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Hi all,
This is a test, I hope it will work because I don't see another simple
solution to move forward from the current stall.
It's a vote, not a test, isn't it? ;-)
I'm starting this vote because I saw that there is a lot moving around
Stefano Bagnara wrote:
And now the bulk questions:
A. Deprecate phoenix
-0 in the short term (an year)
A1. Replace it with Plexus (http://plexus.codehaus.org/)
+0 Plexus seems to be actively developed (for maven2) and supports
avalon components and more (must be investigated).
A2. Repl
Ok i finished my "reorganize" of the packages and classes. I think now
the structur is more clearer and cleaner. So plz have a look before i
start mergin it in the current trunk.
thx
Norman
Am Donnerstag, den 13.07.2006, 13:20 +0200 schrieb Norman Maurer:
> Hi guys,
>
> i want to start with the
Author: norman
Date: Thu Jul 13 08:10:55 2006
New Revision: 421644
URL: http://svn.apache.org/viewvc?rev=421644&view=rev
Log:
Change config.xml to fit the handler reorganize
Modified:
james/server/sandbox/handlerapi/src/conf/james-config.xml
Modified: james/server/sandbox/handlerapi/src/conf
Hi all,
This is a test, I hope it will work because I don't see another simple
solution to move forward from the current stall.
I'm starting this vote because I saw that there is a lot moving around
this issue and we probably currently don't share a common idea, so it's
better to see what th
Author: norman
Date: Thu Jul 13 07:32:47 2006
New Revision: 421640
URL: http://svn.apache.org/viewvc?rev=421640&view=rev
Log:
Reorganize handlers
Removed:
james/server/sandbox/handlerapi/src/java/org/apache/james/smtpserver/VrfyCmdHandler.java
--
Author: norman
Date: Thu Jul 13 07:31:02 2006
New Revision: 421639
URL: http://svn.apache.org/viewvc?rev=421639&view=rev
Log:
Reorganize handlers
Removed:
james/server/sandbox/handlerapi/src/java/org/apache/james/smtpserver/basefilter/
james/server/sandbox/handlerapi/src/java/org/apache
Author: norman
Date: Thu Jul 13 07:11:04 2006
New Revision: 421637
URL: http://svn.apache.org/viewvc?rev=421637&view=rev
Log:
Reorganize handlers
Added:
james/server/sandbox/handlerapi/src/java/org/apache/james/smtpserver/core/filter/CoreFilterCmdHandlerLoader.java
- copied, changed fr
Author: norman
Date: Thu Jul 13 06:52:49 2006
New Revision: 421631
URL: http://svn.apache.org/viewvc?rev=421631&view=rev
Log:
Reorganize handlers
Added:
james/server/sandbox/handlerapi/src/java/org/apache/james/smtpserver/core/VrfyCmdHandler.java
- copied, changed from r420985,
james/
Author: norman
Date: Thu Jul 13 06:35:33 2006
New Revision: 421624
URL: http://svn.apache.org/viewvc?rev=421624&view=rev
Log:
More reorganize and rename
Added:
james/server/sandbox/handlerapi/src/java/org/apache/james/smtpserver/core/CoreCmdHandlerLoader.java
- copied, changed from r42
Author: norman
Date: Thu Jul 13 05:56:38 2006
New Revision: 421609
URL: http://svn.apache.org/viewvc?rev=421609&view=rev
Log:
Start to reorganize packages etc
Removed:
james/server/sandbox/handlerapi/src/java/org/apache/james/smtpserver/AuthCmdHandler.java
james/server/sandbox/handlerap
Author: norman
Date: Thu Jul 13 05:52:52 2006
New Revision: 421608
URL: http://svn.apache.org/viewvc?rev=421608&view=rev
Log:
Start to reorganize packages etc
Added:
james/server/sandbox/handlerapi/src/java/org/apache/james/smtpserver/CommandHandler.java
james/server/sandbox/handlerapi/
Author: norman
Date: Thu Jul 13 05:51:22 2006
New Revision: 421607
URL: http://svn.apache.org/viewvc?rev=421607&view=rev
Log:
Start to reorganize packages etc
Added:
james/server/sandbox/handlerapi/src/java/org/apache/james/smtpserver/core/AuthCmdHandler.java
- copied, changed from r42
Hi guys,
i want to start with the merge to trunk today. Anyone want me to change
package names or move classes before ? Anyway we could do this also
later.
bye
Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Am Donnerstag, den 13.07.2006, 10:43 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman wrote:
> >> I have a library using slf4j for logging and I want to use it inside my
> >> Avalon based application (Apache James).
> >
> > We should use java.util.logging, which is also what tomcat switched to
> >
Code review to @deprecate things we already know want to remove in 3.0
--
Key: JAMES-565
URL: http://issues.apache.org/jira/browse/JAMES-565
Project: James
Type: Task
Versions: 2.3.0b2
R
Vincenzo Gianferrari Pini wrote:
Stefano Bagnara wrote:
AvalonListserv.java (2 matches)
AvalonListservManager.java (2 matches)
Obsolete and ready to deprecate, IMO.
I love to remove code: can we remove those from trunk?
Wait: deprecate != remove. I'm using AvalonListserv and
AvalonLis
Stefano Bagnara wrote:
AvalonListserv.java (2 matches)
AvalonListservManager.java (2 matches)
Obsolete and ready to deprecate, IMO.
I love to remove code: can we remove those from trunk?
Wait: deprecate != remove. I'm using AvalonListserv and
AvalonListservManager quite extensively, an
Noel J. Bergman wrote:
I have a library using slf4j for logging and I want to use it inside my
Avalon based application (Apache James).
We should use java.util.logging, which is also what tomcat switched to
using. JULI should be entirely sufficient for our needs, and is the
standard API.
Noel J. Bergman wrote:
AbstractStorageQuota.java (2 matches)
I did that one. Needed it to get at the user repository info, which should be
replaced by JNDI and/or Mailet API enhancements.
Danny really wants to keep the Mailet API small and sweet, but maybe we should
look at some supplementa
Noel J. Bergman wrote:
Stefano Bagnara wrote:
init(Config) where Config contains a Context that in turn contains a
mean to retrieve services is just an obfuscated way to use the Avalon
serviceLocator pattern (service(ServiceManager s)).
Well, you can say obfuscated and I can say that it is th
32 matches
Mail list logo
