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: Not Mine
Date Thu, 19 Nov 2009 11:22:26 GMT
Hi,

This is a summary of the differences between Spring and Guice 
http://code.google.com/p/google-guice/wiki/SpringComparison

 From it: 'From our experience, most AOP frameworks are too powerful for 
most uses and don't carry their own conceptual weight. Guice builds 
method interception in at the core instead of as an afterthought.' 
Likewise with Platformed, but again, there is no directly comparable 
concept of binding in the style of guice. Although guice is great I 
still don't think it solves the underlying problem (its solves parts), 
this is only because solving the problem requires engineering 
discipline, not a framework. For example, if you annotate a method to do 
some before or after logging (how I suggested in the second mail, a 
sample is below), you are effectively binding a system policy to a 
component. That's wrong and is part of the point of the Spring design, 
I.e. the XML part describes system policy (guice still uses XML in some 
cases).

It is possible to take existing James classes and break them into 
smaller pieces which can be recomposed into many more combinations (the 
point of components?). I've looked briefly at the POPServer 
implementation and this could easily be broken down into smaller chunks, 
each doXXX could be separated off into its own class for instance I.e. 
the method becomes a component. If done like this they could now be 
re-used by spring, guice or mine.

I just received an email, thanks.

If the framework needs so much text to be explained....something that people is able to grasp
without reading pages of docs.

Sorry, my fault, too much/too little, I was thinking a bit out loud. You 
don't really need to know about the details of the framework.

You propose a new container framework using interfaces to be
implemented. in 2009 this is a bad practice, currently frameworks use
@annotations, AOP, agnostic (pojo) dependency injection. If we want an
interface based framework then Avalon does a damn good job here,
already.

The above statements should answer that, I am not asking you to use my 
interfaces, I am asking you structure James functionality in way that 
makes them usable in more systems.

You also will need a good understanding of other frameworks so to
publish a comparison and use common terms defining what makes your
framework special. What is the most similar framework around, what
does your framework do better? Does your framework try to solve
container issues (class loading, component isolation,
component reloading, deployment) or application assembly (dependency
injection, component configuration, service discovery/linking,
configuration)?

I do have pretty a good understanding of frameworks and the answer to 
this is mostly yes, but it misses the point, I am not trying to sell my 
framework. Back to the beginning, all components that contain logging 
code are flawed. At present my framework doesn't have this flaw, but 
that because it doesn't as yet have any flawed components (but it can 
support them). The problem is with components, take this example:

RIGHT:

class RealMethod{
    public void realMethod(){
       //No logging, just does something useful.
       ...
    }
}

//How some AOP frameworks implement cross cutting concerns.

class LoggingRealMethod extends RealMethod implements Loggable{
    public void realMethod(){
        //Before logging
        logger.log( ... );
        //The real method
        super.realMethod()
        //After logging
        logger.log( ... );
    }
}

//How my framework might use it

class RealMethodOperation extends RealMethod implements Operation{
    public void operate(){
       super.realMethod();
    }
}

WRONG:

class RealMethod{
    @LogBefore
    @LogAfter
    public void realMethod(){
       ...
    }
}

The problem of cross-cutting concerns cannot be solved with a framework 
alone, the components must really be designed with cross-cutting 
concerns in mind. Avalon did a very noble job of encouraging good 
component design (based on principles of the time), that's the point of 
a framework. The solution to the problem is engineering discipline, a 
deeper separation of concerns, simple as that. If you want to add 
logging in a declarative fashion, components can't contain their own 
logging code and should probably instead provide the framework 
information about its loggability (with annotations for example) that 
open up opportunities for the framework (well components of the 
framework) to monitor them.

I hope this clarifies my objectives, if done right, James could be 
suitable for many frameworks/projects. You might also want to ask 
questions such as does spring or guice support declarative logging? I 
suppose the answer is probably yes, if the components where designed 
appropriately. The only thing that makes the framework 'special' is that 
it encourages best practice in its approach to component design (like 
Avalon did). Common sense alone will tell you that declarative logging 
requires components with no internal logging code. Imagine doing away 
with if( logger.isLevelEnabled()) logger.level( "etc" ) and instead drop 
your component in a debugging system with a verbose logging policy or 
dropping a component into a production system with a minimal logging 
policy. Wouldn't that be sweet?

Regards,

Simon














---------------------------------------------------------------------
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