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 Simon Funnell <si...@googlemail.com> on 2009/11/21 05:10:07 UTC
Solution
Hi,
Aspectj is an example of how you could add logging to James components
later in the inheritance chain. Tools already exist, all you need to do
is accept this simple fact. If components have explicit logging
operations, they are flawed. Nothing do with me or anyone, its a just a
fact. The solution is to write methods without logging code, then add it
later with a decent aspect orientated framework or the like. Its really
that simple.
Are you not bored of explicitly writing logging code in every component?
All I am asking is for you to embrace best practice :) but I respect the
fact people have jobs as well and that this needs to be accounted for in
the development cycle.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Solution
Posted by Simon Funnell <si...@googlemail.com>.
Stefano Bagnara wrote:
> Please, take real code from James and show us the real refactoring you propose.
> There's no way we'll keep reading so big abstract discussions.
>
I don't think this is the right approach, forget about my framework and
declarative logging, its missing the point.
Instead leave things how they are create some high level documentation
that describes the roles and responsibilities of James components.
This documentation will highlight what needs to be done and is a perfect
basis for designing a set of interfaces.
Once a good set of interfaces in designed, then is the time to
migrate/implement things.
In this way, the current effort can continue as is and re-factoring when
it comes is much easier.
Nobody has to do anything at this stage (well very little), let me learn
more about James while I create some documentation.
If I misunderstand something, those who know James intimately can
correct me. This will be useful for everyone, including new users.
> I don't think that what I see here will reduce the time to write code.
> Extracting logging into special classes is a PITA most time. This will
> require big refactoring in order to allow an external class to log
> what you want to log.
That's the whole point, pluggability. Yes it takes longer to write
initially, but you don't (or very rarely) need to write it again, it
does save you time in the long run. You write your logging code once and
reuse it.
> So you have to write code thinking about what is
> needed for logging, and then later you have to apply logging.
Yes, but its worth the trouble, because its more flexible.
> IMHO
> this is a no go. But I'll be happy to change my mind when I see a damn
> clear code example.
>
Its not about logging alone, its all cross cutting concerns. I will help
document the James architecture and develop interfaces but I am not hacking.
> Checkout James trunk, take a module, refactor it the way you think it
> is "cool". Open a JIRA and attach your diff. Everyone here has more
> time for diffs/jira than for discussions.
>
Please don't ask me to code first and design later, I learnt not do that
a long time ago. (Wish I learnt it when I first heard the Tortoise and
Hare story though).
> You should better use your discussion time to create a website for
> your ideas and make your message documented in that website, so that
> people wanting to set the new standards will have something
> *organized* to read. If you want to set new standards you will need
> some clear code example that will convince anyone that it is the right
> direction.
>
This is probably true and I am sorry for confusing matters, but again
its not relevant. James components are not as reusable as they could be.
This is not a problem as such, things still work. And by the way, its
not my message. I am only stating facts.
> As a side note, I know many project using AspectJ, but none of them is
> using it for logging. I think there something to learn there.
>
AspectJ has its uses, but its not right for all cases.
At this stage I will repeat what I have said before, I think it is worth
working me on some documentation.
In this way I can add value without stalling the current effort.
James is more important than my framework at present, that can come later.
Regards,
Simon
> Stefano
>
> 2009/11/21 Simon Funnell <si...@googlemail.com>:
>
>> Hi,
>>
>> Sorry, I will keep it under 'Solution' for now.
>>
>> Norman Maurer wrote:
>>
>>> Im still not agree with you about that. Imho logging should be part of the
>>> "main code". And why is this any better then injecting the Logger like every
>>> other object. In trunk we even use JSR250 for that so every Franework which
>>> knows howto handle this Standards should just work...
>>>
>> If you want to have declarative logging and other wonderful such features,
>> you can't put it in explicitly. That's not my opinion, its a fact, a known
>> self evident fact, but its not all about logging. Components can still work
>> with standards, that's not a problem. There is one thing about standards to
>> note, not every one follows standards, because there are those that set the
>> standards (if you are ahead of the game then there is no one to follow, in
>> this case logic clearly states that you 'are' the standard). Why not have
>> James set the standards while still adhering to others, its not impossible,
>> in fact its easy, it just requires engineering discipline. For example,
>> Platformed is not just a bunch of code, it encourages good practice. It
>> defines six roles that would be useful to James and Tomcat (both of which I
>> use heavily). They are split into three groups of high, medium and low. The
>> two low level roles are 'engineer' and 'developer'. These roles define clear
>> responsibilities and while close in nature they do different things.
>> Engineers do lower level things and developers higher level. This
>> distinction is not made (or is not apparent to me) in James and it would
>> certainly benefit from making these distinctions (an improved
>> architecture/API). In Platformed for example, developers don't have to worry
>> about concurrency issues because the engineers solved the problem for them
>> 'once'. The engineers effectively create a structured development
>> environment that allows developers to focus on real world problems while
>> they take care of machine level problems. It's a proper separation of
>> concerns.
>>
>>>> Are you not bored of explicitly writing logging code in every component?
>>>>
>>>>
>>> Nope im not bored.
>>>
>> Ok, if you write less code it will take less time and you will earn more
>> money or if you have time left over, you can make it a better program. If
>> other people are doing it and you are not, they will probably get the
>> contract because they can get it done quicker. That said, money isn't
>> everything, its also fun making software. You have heard of the 'write once'
>> principle right? If you are writing logging code over and over again, you
>> probably need to understand something important. We designed computers with
>> software languages and they are very good at 'automating' things, like
>> automatically adding logging code to your software. You are manually doing a
>> task that can be automated!!! Is this not very obvious, its madness!? Sorry
>> to be sarcastic, I am a really nice guy but I can be a firebrand at times :)
>> it does bug me when software developers do not utilise software.
>>
>> I have been looking at the HeloCmdHandler and it is problematic because it
>> mixes principles(its active and passive). Passive components do not want
>> logging code within them, but its ok to put logging code in active ones. The
>> easiest way to do this is to use a good tool that solves the problem for
>> you, or create two classes where you usually create one (that reflect the
>> active and passive principles). The first class will have methods that
>> implement stages of processing flow (passive), then another class (or any
>> number of classes) can call the implemented methods in any order they like
>> (active). For example:
>>
>> //Passive
>> class ThreePageBook extends AbstractBook{
>>
>> public ThreePageBook (){}
>>
>> public void pageOne(){
>> ...
>> } public void pageTwo(){
>> ...
>> }
>> public void pageThree(){
>> ...
>> }
>> }
>>
>> abstract class AbstractReader{
>> private final Book book;
>>
>> public AbstractReader( Book theBook ){
>> book = theBook;
>> }
>>
>> public abstract void read():
>> }
>>
>> //Logging implementation - active
>> class LoggingReader extends AbstractReader{
>>
>> private final Logger logger;
>>
>> @Inject
>> public LoggingReader( Book theBook , Logger theLogger ){
>> super( theBook ); logger = theLogger;
>> }
>> @Override
>> public void read(){
>> logger.log( "About to read page " + book,getNextPageNumber() );
>> book.pageOne();
>> logger.log( "About to read page " + book,getNextPageNumber());
>> book.pageTwo();
>> logger.log( "Done reading page " + book,getLastPageNumber() );
>> book.pageThree();
>> logger.log( "Done reading page " + book,getLastPageNumber());
>> }
>> }
>>
>> //Non-logging implementation - active
>>
>> class NonLinearReader extends AbstractReader{
>>
>> @Inject
>> public NonLinearReader( Book theBook ){
>> super( theBook );
>> }
>> @Override
>> public void read(){
>> book.pageTwo();
>> book.pageThree();
>> book.pageOne(); }
>> }
>>
>> Guice is very good, but its not an architecture. Please let me help, I am
>> skilled, work very hard and I am available for the next six weeks so I can
>> dedicate myself to James. It should be obvious from the above that I am
>> offering practical, straight in front of your face, solutions, its easy to
>> add logging and the like after the functionality. Logging code doesn't need
>> to be removed, just put in the right place. It's a proper separation of
>> concerns, good component design.
>>
>> Although I code in languages from the bottom of the stack (nearly the
>> bottom, I have a novel understanding of machine code) to the top I am
>> usually employed as an architect so tend to produce interfaces (metaphysical
>> constructs) rather then implementations (physical constructs). Some places
>> automate the implementation process by generating and testing all the
>> various component arrangement combinations looking for successful
>> implementations, most implementations fail and are discarded and the ones
>> that are successful are usually a smallish number of specialist
>> implementations that between them solve all generalised cases (in principle
>> like one of those artificially intelligent chess programs looking ahead
>> through all possible combinations). They are basically programs that write
>> programs, very cool. But I digress.
>>
>> I think the way forward is documentation for the reasons given in the
>> previous email, I can add value without stalling the effort. I've known
>> cases where good documentation makes a success of bad software, powerful
>> stuff. Obviously you want both good documentation and good software. :) You
>> don't need to use AOP frameworks, its really about component design and
>> structuring the code in a more modular fashion.
>>
>> But there it ends. IMO a framework cannot provide an easy replacement
>> for the "debug" and "info" level where you want to log certain states
>> or events that may be of interest to the user.
>>
>>
>> This is half true, no framework cannot solve the problem alone, the
>> components have to solve it as well. They are two sides of the same coin.
>>
>> The root of the problem with James is that it implements its own internal
>> framework through inheritance, with things like AbstractJamesService.
>>
>> This is adding features before that should be added after. No framework can
>> provide an alternative, because its built in.
>>
>> For example, POP3Server doesn't need to know anything about the
>> AbstractJamesService, but it extends it.
>>
>> This is the wrong way round, it needs to be 'inverted'.
>>
>> The issue is architecture/API design.
>>
>> Regards,
>>
>> Simon
>>
>> P.S. I am sorry its long again.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Solution
Posted by Stefano Bagnara <ap...@bago.org>.
Please, take real code from James and show us the real refactoring you propose.
There's no way we'll keep reading so big abstract discussions.
I don't think that what I see here will reduce the time to write code.
Extracting logging into special classes is a PITA most time. This will
require big refactoring in order to allow an external class to log
what you want to log. So you have to write code thinking about what is
needed for logging, and then later you have to apply logging. IMHO
this is a no go. But I'll be happy to change my mind when I see a damn
clear code example.
Checkout James trunk, take a module, refactor it the way you think it
is "cool". Open a JIRA and attach your diff. Everyone here has more
time for diffs/jira than for discussions.
You should better use your discussion time to create a website for
your ideas and make your message documented in that website, so that
people wanting to set the new standards will have something
*organized* to read. If you want to set new standards you will need
some clear code example that will convince anyone that it is the right
direction.
As a side note, I know many project using AspectJ, but none of them is
using it for logging. I think there something to learn there.
Stefano
2009/11/21 Simon Funnell <si...@googlemail.com>:
> Hi,
>
> Sorry, I will keep it under 'Solution' for now.
>
> Norman Maurer wrote:
>>
>> Im still not agree with you about that. Imho logging should be part of the
>> "main code". And why is this any better then injecting the Logger like every
>> other object. In trunk we even use JSR250 for that so every Franework which
>> knows howto handle this Standards should just work...
>
> If you want to have declarative logging and other wonderful such features,
> you can't put it in explicitly. That's not my opinion, its a fact, a known
> self evident fact, but its not all about logging. Components can still work
> with standards, that's not a problem. There is one thing about standards to
> note, not every one follows standards, because there are those that set the
> standards (if you are ahead of the game then there is no one to follow, in
> this case logic clearly states that you 'are' the standard). Why not have
> James set the standards while still adhering to others, its not impossible,
> in fact its easy, it just requires engineering discipline. For example,
> Platformed is not just a bunch of code, it encourages good practice. It
> defines six roles that would be useful to James and Tomcat (both of which I
> use heavily). They are split into three groups of high, medium and low. The
> two low level roles are 'engineer' and 'developer'. These roles define clear
> responsibilities and while close in nature they do different things.
> Engineers do lower level things and developers higher level. This
> distinction is not made (or is not apparent to me) in James and it would
> certainly benefit from making these distinctions (an improved
> architecture/API). In Platformed for example, developers don't have to worry
> about concurrency issues because the engineers solved the problem for them
> 'once'. The engineers effectively create a structured development
> environment that allows developers to focus on real world problems while
> they take care of machine level problems. It's a proper separation of
> concerns.
>>>
>>> Are you not bored of explicitly writing logging code in every component?
>>>
>> Nope im not bored.
>
> Ok, if you write less code it will take less time and you will earn more
> money or if you have time left over, you can make it a better program. If
> other people are doing it and you are not, they will probably get the
> contract because they can get it done quicker. That said, money isn't
> everything, its also fun making software. You have heard of the 'write once'
> principle right? If you are writing logging code over and over again, you
> probably need to understand something important. We designed computers with
> software languages and they are very good at 'automating' things, like
> automatically adding logging code to your software. You are manually doing a
> task that can be automated!!! Is this not very obvious, its madness!? Sorry
> to be sarcastic, I am a really nice guy but I can be a firebrand at times :)
> it does bug me when software developers do not utilise software.
>
> I have been looking at the HeloCmdHandler and it is problematic because it
> mixes principles(its active and passive). Passive components do not want
> logging code within them, but its ok to put logging code in active ones. The
> easiest way to do this is to use a good tool that solves the problem for
> you, or create two classes where you usually create one (that reflect the
> active and passive principles). The first class will have methods that
> implement stages of processing flow (passive), then another class (or any
> number of classes) can call the implemented methods in any order they like
> (active). For example:
>
> //Passive
> class ThreePageBook extends AbstractBook{
>
> public ThreePageBook (){}
>
> public void pageOne(){
> ...
> } public void pageTwo(){
> ...
> }
> public void pageThree(){
> ...
> }
> }
>
> abstract class AbstractReader{
> private final Book book;
>
> public AbstractReader( Book theBook ){
> book = theBook;
> }
>
> public abstract void read():
> }
>
> //Logging implementation - active
> class LoggingReader extends AbstractReader{
>
> private final Logger logger;
>
> @Inject
> public LoggingReader( Book theBook , Logger theLogger ){
> super( theBook ); logger = theLogger;
> }
> @Override
> public void read(){
> logger.log( "About to read page " + book,getNextPageNumber() );
> book.pageOne();
> logger.log( "About to read page " + book,getNextPageNumber());
> book.pageTwo();
> logger.log( "Done reading page " + book,getLastPageNumber() );
> book.pageThree();
> logger.log( "Done reading page " + book,getLastPageNumber());
> }
> }
>
> //Non-logging implementation - active
>
> class NonLinearReader extends AbstractReader{
>
> @Inject
> public NonLinearReader( Book theBook ){
> super( theBook );
> }
> @Override
> public void read(){
> book.pageTwo();
> book.pageThree();
> book.pageOne(); }
> }
>
> Guice is very good, but its not an architecture. Please let me help, I am
> skilled, work very hard and I am available for the next six weeks so I can
> dedicate myself to James. It should be obvious from the above that I am
> offering practical, straight in front of your face, solutions, its easy to
> add logging and the like after the functionality. Logging code doesn't need
> to be removed, just put in the right place. It's a proper separation of
> concerns, good component design.
>
> Although I code in languages from the bottom of the stack (nearly the
> bottom, I have a novel understanding of machine code) to the top I am
> usually employed as an architect so tend to produce interfaces (metaphysical
> constructs) rather then implementations (physical constructs). Some places
> automate the implementation process by generating and testing all the
> various component arrangement combinations looking for successful
> implementations, most implementations fail and are discarded and the ones
> that are successful are usually a smallish number of specialist
> implementations that between them solve all generalised cases (in principle
> like one of those artificially intelligent chess programs looking ahead
> through all possible combinations). They are basically programs that write
> programs, very cool. But I digress.
>
> I think the way forward is documentation for the reasons given in the
> previous email, I can add value without stalling the effort. I've known
> cases where good documentation makes a success of bad software, powerful
> stuff. Obviously you want both good documentation and good software. :) You
> don't need to use AOP frameworks, its really about component design and
> structuring the code in a more modular fashion.
>
> But there it ends. IMO a framework cannot provide an easy replacement
> for the "debug" and "info" level where you want to log certain states
> or events that may be of interest to the user.
>
>
> This is half true, no framework cannot solve the problem alone, the
> components have to solve it as well. They are two sides of the same coin.
>
> The root of the problem with James is that it implements its own internal
> framework through inheritance, with things like AbstractJamesService.
>
> This is adding features before that should be added after. No framework can
> provide an alternative, because its built in.
>
> For example, POP3Server doesn't need to know anything about the
> AbstractJamesService, but it extends it.
>
> This is the wrong way round, it needs to be 'inverted'.
>
> The issue is architecture/API design.
>
> Regards,
>
> Simon
>
> P.S. I am sorry its long again.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Solution
Posted by Simon Funnell <si...@googlemail.com>.
Hi,
Sorry, I will keep it under 'Solution' for now.
Norman Maurer wrote:
>
> Im still not agree with you about that. Imho logging should be part of
> the "main code". And why is this any better then injecting the Logger
> like every other object. In trunk we even use JSR250 for that so every
> Franework which knows howto handle this Standards should just work...
If you want to have declarative logging and other wonderful such
features, you can't put it in explicitly. That's not my opinion, its a
fact, a known self evident fact, but its not all about logging.
Components can still work with standards, that's not a problem. There is
one thing about standards to note, not every one follows standards,
because there are those that set the standards (if you are ahead of the
game then there is no one to follow, in this case logic clearly states
that you 'are' the standard). Why not have James set the standards while
still adhering to others, its not impossible, in fact its easy, it just
requires engineering discipline. For example, Platformed is not just a
bunch of code, it encourages good practice. It defines six roles that
would be useful to James and Tomcat (both of which I use heavily). They
are split into three groups of high, medium and low. The two low level
roles are 'engineer' and 'developer'. These roles define clear
responsibilities and while close in nature they do different things.
Engineers do lower level things and developers higher level. This
distinction is not made (or is not apparent to me) in James and it would
certainly benefit from making these distinctions (an improved
architecture/API). In Platformed for example, developers don't have to
worry about concurrency issues because the engineers solved the problem
for them 'once'. The engineers effectively create a structured
development environment that allows developers to focus on real world
problems while they take care of machine level problems. It's a proper
separation of concerns.
>> Are you not bored of explicitly writing logging code in every component?
>>
> Nope im not bored.
Ok, if you write less code it will take less time and you will earn more
money or if you have time left over, you can make it a better program.
If other people are doing it and you are not, they will probably get the
contract because they can get it done quicker. That said, money isn't
everything, its also fun making software. You have heard of the 'write
once' principle right? If you are writing logging code over and over
again, you probably need to understand something important. We designed
computers with software languages and they are very good at 'automating'
things, like automatically adding logging code to your software. You are
manually doing a task that can be automated!!! Is this not very obvious,
its madness!? Sorry to be sarcastic, I am a really nice guy but I can be
a firebrand at times :) it does bug me when software developers do not
utilise software.
I have been looking at the HeloCmdHandler and it is problematic because
it mixes principles(its active and passive). Passive components do not
want logging code within them, but its ok to put logging code in active
ones. The easiest way to do this is to use a good tool that solves the
problem for you, or create two classes where you usually create one
(that reflect the active and passive principles). The first class will
have methods that implement stages of processing flow (passive), then
another class (or any number of classes) can call the implemented
methods in any order they like (active). For example:
//Passive
class ThreePageBook extends AbstractBook{
public ThreePageBook (){}
public void pageOne(){
...
}
public void pageTwo(){
...
}
public void pageThree(){
...
}
}
abstract class AbstractReader{
private final Book book;
public AbstractReader( Book theBook ){
book = theBook;
}
public abstract void read():
}
//Logging implementation - active
class LoggingReader extends AbstractReader{
private final Logger logger;
@Inject
public LoggingReader( Book theBook , Logger theLogger ){
super( theBook );
logger = theLogger;
}
@Override
public void read(){
logger.log( "About to read page " + book,getNextPageNumber() );
book.pageOne();
logger.log( "About to read page " + book,getNextPageNumber());
book.pageTwo();
logger.log( "Done reading page " + book,getLastPageNumber() );
book.pageThree();
logger.log( "Done reading page " + book,getLastPageNumber());
}
}
//Non-logging implementation - active
class NonLinearReader extends AbstractReader{
@Inject
public NonLinearReader( Book theBook ){
super( theBook );
}
@Override
public void read(){
book.pageTwo();
book.pageThree();
book.pageOne();
}
}
Guice is very good, but its not an architecture. Please let me help, I
am skilled, work very hard and I am available for the next six weeks so
I can dedicate myself to James. It should be obvious from the above that
I am offering practical, straight in front of your face, solutions, its
easy to add logging and the like after the functionality. Logging code
doesn't need to be removed, just put in the right place. It's a proper
separation of concerns, good component design.
Although I code in languages from the bottom of the stack (nearly the
bottom, I have a novel understanding of machine code) to the top I am
usually employed as an architect so tend to produce interfaces
(metaphysical constructs) rather then implementations (physical
constructs). Some places automate the implementation process by
generating and testing all the various component arrangement
combinations looking for successful implementations, most
implementations fail and are discarded and the ones that are successful
are usually a smallish number of specialist implementations that between
them solve all generalised cases (in principle like one of those
artificially intelligent chess programs looking ahead through all
possible combinations). They are basically programs that write programs,
very cool. But I digress.
I think the way forward is documentation for the reasons given in the
previous email, I can add value without stalling the effort. I've known
cases where good documentation makes a success of bad software, powerful
stuff. Obviously you want both good documentation and good software. :)
You don't need to use AOP frameworks, its really about component design
and structuring the code in a more modular fashion.
But there it ends. IMO a framework cannot provide an easy replacement
for the "debug" and "info" level where you want to log certain states
or events that may be of interest to the user.
This is half true, no framework cannot solve the problem alone, the
components have to solve it as well. They are two sides of the same coin.
The root of the problem with James is that it implements its own
internal framework through inheritance, with things like
AbstractJamesService.
This is adding features before that should be added after. No framework
can provide an alternative, because its built in.
For example, POP3Server doesn't need to know anything about the
AbstractJamesService, but it extends it.
This is the wrong way round, it needs to be 'inverted'.
The issue is architecture/API design.
Regards,
Simon
P.S. I am sorry its long again.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Solution
Posted by Norman Maurer <no...@googlemail.com>.
Comments inside...
Am 21.11.2009 um 05:10 schrieb Simon Funnell <simonfunnell@googlemail.com
>:
> Hi,
>
> Aspectj is an example of how you could add logging to James
> components later in the inheritance chain. Tools already exist, all
> you need to do is accept this simple fact. If components have
> explicit logging operations, they are flawed. Nothing do with me or
> anyone, its a just a fact. The solution is to write methods without
> logging code, then add it later with a decent aspect orientated
> framework or the like. Its really that simple.
Im still not agree with you about that. Imho logging should be part of
the "main code". And why is this any better then injecting the Logger
like every other object. In trunk we even use JSR250 for that so every
Franework which knows howto handle this Standards should just work...
> Are you not bored of explicitly writing logging code in every
> component?
>
Nope im not bored.
> All I am asking is for you to embrace best practice :) but I respect
> the fact people have jobs as well and that this needs to be
> accounted for in the development cycle.
>
> Regards,
>
> Simon
>
Bye
Norman
Ps: Why you change the subject of the Mail Everytime.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Solution
Posted by Markus Wiederkehr <ma...@gmail.com>.
On Sat, Nov 21, 2009 at 5:10 AM, Simon Funnell
<si...@googlemail.com> wrote:
> Hi,
>
> Aspectj is an example of how you could add logging to James components later
> in the inheritance chain. Tools already exist, all you need to do is accept
> this simple fact. If components have explicit logging operations, they are
> flawed. Nothing do with me or anyone, its a just a fact. The solution is to
> write methods without logging code, then add it later with a decent aspect
> orientated framework or the like. Its really that simple.
I think I'm with Norman and Stefano on this.
In my opinion AOP frameworks are great for separating concerns like
transactions or security. They are not so great when it comes to
logging.
Sure, an AOP framework could be used to replace the "trace" log level.
To log each time a method gets invoked, maybe including parameter
values, and each time a method returns, possibly including the return
value. A framework could also take care of logging exceptions as the
are thrown.
But there it ends. IMO a framework cannot provide an easy replacement
for the "debug" and "info" level where you want to log certain states
or events that may be of interest to the user.
So I guess if you want to convince us you have to start posting some
concrete code examples to illustrate what you mean (like Stefano
already suggested).
Regards,
Markus
PS: please don't start a new conversation each time you send a reply.
PPS: I tend to write overly long mails myself (I guess this is an
example) but I really think you should try to be more concise. Nobody
has the time or interest to read one 5k message after the other. I
admit I didn't.
> Are you not bored of explicitly writing logging code in every component?
>
> All I am asking is for you to embrace best practice :) but I respect the
> fact people have jobs as well and that this needs to be accounted for in the
> development cycle.
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org