james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Funnell <simonfunn...@googlemail.com>
Subject Re: Solution
Date Sat, 21 Nov 2009 19:54:17 GMT
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


Mime
View raw message