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: [email protected]
For additional commands, e-mail: [email protected]
