On Tue, 2002-12-10 at 18:50, Henning P. Schmiedehausen wrote:

> 
> Folks,
> 
> please. We do not try to build Avalon-light or an Avalon clone.
> Staring at foreign code and rebuilding every interface from another
> project will not help us.

I think John has gone the correct path in converting Fulcrum over to
just plain use Avalon.

> Compared to Avalon, Turbine is really lightweight and simple. 

Are you kidding? In what respect do you find Turbine more lightweight
and simple? I cannot think of a single example for which Turbine is
lighter or simpler. Can you give me any?

The entire lifecycle for Avalon components and containers is contained
in a ~60k JAR. All components are well defined and live out their
existance in a well defined manner. Nothing in Turbine 2.x is well
defined and nothing lives out its existance in a well defined manner.
The service code is one example of complete confusion and obscurity.
Torque, though I have not looked at it, began its lifecycle with a call
to Criteria. If that is not confusing and unintuitive I don't know what
is. The security service, the lifecycle of a request ... none of these
thing are clear. In a component framework like Avalon these entities are
forced, by the patterns inherent in the framework, to be clear.

Nothing in Turbine 2.x is clear. Period.

> I'll try
> to keep it that way. 

You want to keep it a completely and totally unintuitive mess?

> If we can use synergies with Avalon, fine. If
> not, well, if you need all the features of Avalon, why not use Avalon
> in the first place? We do not try to be an end-all, be-all solution
> which replaces all other web-application frameworks. We do not need to
> be "best-of-brand" in every category. We're not even trying to
> compete. :-)

Speak for yourself.

> I see logging for Turbine as a way to offer a centralized, easy to use
> and flexible facility for applications and services. All this does
> commons-logging in conjunction with log4j (or JDK 1.4) offer.
> 
> I'll keep this code simple, hardcoded and out of the lifecycle
> code. 

There is no doubt that logging is a fundamental aspect to an
application. In Avalon it's attached to each component and works fairly
well in that environment. In Turbine it definitely doesn't work well as
a service which is why it was removed as such in the turbine 3 code
base. At the very least if you're going to start making 2.x like 3.x use
the 3.x code.

> Reason: You'll end up with a mess like in the current Turbine. What if
> you want to log messages before your ServiceBroker/ComponentContainer
> has even started? 

Been discussed which is why it was removed as a service in 3.x.

> Remember the posting about the stratum message
> popping out of Stdout because of this. Logging is simply the second
> thing that we will set up right after startup (First thing is reading
> the conf because we need this for configuring the logging). That's it.
> 
>       Regards
>               Henning
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to