Author: norman
Date: Mon Sep 10 23:08:08 2007
New Revision: 574478
URL: http://svn.apache.org/viewvc?rev=574478&view=rev
Log:
Update README to show the usage of DefaultSPF class
Modified:
james/jspf/trunk/README.txt
Modified: james/jspf/trunk/README.txt
URL:
http://svn.apache.org/viewvc/jam
Author: norman
Date: Mon Sep 10 23:01:41 2007
New Revision: 574474
URL: http://svn.apache.org/viewvc?rev=574474&view=rev
Log:
Correct visibility
Modified:
james/jspf/trunk/src/main/java/org/apache/james/jspf/SPF.java
james/jspf/trunk/src/main/java/org/apache/james/jspf/impl/DNSServic
Author: norman
Date: Mon Sep 10 22:47:53 2007
New Revision: 574466
URL: http://svn.apache.org/viewvc?rev=574466&view=rev
Log:
Remove empty packages ( Stefano seems to miss this..)
Removed:
james/jspf/trunk/src/main/java/org/apache/james/jspf/macro/
james/jspf/trunk/src/main/java/org/apach
On 9/10/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
> [] commons-logging
> [ +1 ] log4j
> [] java.util.logging
> [] plain file write (poor man's own framework)
> [] slf4j
> [] ... other ...
I don't see the need to use a wrapping log library and think log4j is
rather widely used. I'm reasonabl
Author: bago
Date: Mon Sep 10 15:39:04 2007
New Revision: 574394
URL: http://svn.apache.org/viewvc?rev=574394&view=rev
Log:
Move utils to core package (same afferent/efferent dependencies). 2 classes in
a package was too much fragmentation (all of the code depending on utils also
depends on core
Author: bago
Date: Mon Sep 10 15:32:52 2007
New Revision: 574391
URL: http://svn.apache.org/viewvc?rev=574391&view=rev
Log:
Move MacroData to core package (same afferent/efferent dependencies). A single
class in a package means too much fragmentation.
Removed:
james/jspf/trunk/src/main/java/
Author: bago
Date: Mon Sep 10 15:30:55 2007
New Revision: 574390
URL: http://svn.apache.org/viewvc?rev=574390&view=rev
Log:
Move MacroData to core package (same afferent/efferent dependencies). A single
class in a package means too much fragmentation.
Added:
james/jspf/trunk/src/main/java/or
Robert Burrell Donkin ha scritto:
> On 9/9/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
>> On 8/19/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Any idea how we can eliminate some of this extraneous garbage so
that the build report can be posted? Or should I just shut down the
>>
On 9/9/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> On 8/19/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
> > > Any idea how we can eliminate some of this extraneous garbage so
> > > that the build report can be posted? Or should I just shut down the
> > > nightly
> > > builds because
Author: bago
Date: Mon Sep 10 08:27:37 2007
New Revision: 574282
URL: http://svn.apache.org/viewvc?rev=574282&view=rev
Log:
Remove unused test class (including no tests)
Removed:
james/jspf/trunk/src/test/java/org/apache/james/jspf/dnsserver/DNSTestingServerTest.java
--
Author: bago
Date: Mon Sep 10 08:14:16 2007
New Revision: 574277
URL: http://svn.apache.org/viewvc?rev=574277&view=rev
Log:
Promoted public nested exception classes to top level classes.
Added:
james/jspf/trunk/src/main/java/org/apache/james/jspf/dns/TimeoutException.java
(with props)
Bernd Fondermann ha scritto:
> Stefano Bagnara wrote:
>> To summarize, currently here is my ordered list of preferences:
>> 1) JUL with a single rotating file configuration
>> 2) log4j
>
> I'd reverse the list, simply due to bad press jul received recently (I
> don't know it) and because I worked
Stefano Bagnara wrote:
Bernd Fondermann ha scritto:
Hi,
We need a proper Logging Framework integrated with the spring-deployment
module.
Currently, all logging is going to System.out.
I'd like to have at least log messages to go to a single file
'james.log' but also support the possibilty for
Stefano Bagnara wrote:
Bernd Fondermann ha scritto:
While commons-logging seems a good choice at first sight, after
thinking about it for a while, I now think we should go for the second
option.
I'm not sure I understand: our code already directly depends on both
Avalon-Framework-Loggers and C
Stefano Bagnara schrieb:
Bernd Fondermann ha scritto:
Hi,
We need a proper Logging Framework integrated with the spring-deployment
module.
Currently, all logging is going to System.out.
I'd like to have at least log messages to go to a single file
'james.log' but also support the possibilty
Bernd Fondermann ha scritto:
> While commons-logging seems a good choice at first sight, after
> thinking about it for a while, I now think we should go for the second
> option.
I'm not sure I understand: our code already directly depends on both
Avalon-Framework-Loggers and Common-Logging-Logger.
On 9/10/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
> Bernd Fondermann schrieb:
> > What I am asking is: What framework should be the default?
> >
> I think I would use commons-logging...
>
> bye
> Norman
I'd like to describe the different levels of indirection which are
present in James/Spring t
Bernd Fondermann ha scritto:
> Hi,
>
> We need a proper Logging Framework integrated with the spring-deployment
> module.
>
> Currently, all logging is going to System.out.
> I'd like to have at least log messages to go to a single file
> 'james.log' but also support the possibilty for current ph
On 9/10/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> What I am asking is: What framework should be the default?
>
> Here is a list:
> [] commons-logging
> [] log4j
> [] java.util.logging
> [] plain file write (poor man's own framework)
> [] slf4j
> [] ... other ...
I forgot one obviou
Bernd Fondermann schrieb:
Hi,
We need a proper Logging Framework integrated with the
spring-deployment module.
Currently, all logging is going to System.out.
I'd like to have at least log messages to go to a single file
'james.log' but also support the possibilty for current phoenix-like
be
Hi,
We need a proper Logging Framework integrated with the spring-deployment
module.
Currently, all logging is going to System.out.
I'd like to have at least log messages to go to a single file
'james.log' but also support the possibilty for current phoenix-like
behavior of multiple files.
Author: norman
Date: Mon Sep 10 00:32:52 2007
New Revision: 574156
URL: http://svn.apache.org/viewvc?rev=574156&view=rev
Log:
Remove the final declaration ( this was bad idea at all )
Modified:
james/jspf/trunk/src/main/java/org/apache/james/jspf/parser/RFC4408SPF1Parser.java
Modified:
jam
Bernd Fondermann schrieb:
On 9/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: norman
Date: Sat Sep 8 07:51:05 2007
New Revision: 573848
Rename the DefaultSPF1Parser to RFC4408SPF1Parser and declare it final (because its a
"RFC" implementation)
by-and-large, I w
On 9/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: norman
> Date: Sat Sep 8 07:51:05 2007
> New Revision: 573848
> Rename the DefaultSPF1Parser to RFC4408SPF1Parser and declare it final
> (because its a "RFC" implementation)
by-and-large, I would recommend to not declare classes
24 matches
Mail list logo