cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: [RT] Simplifying component handling
Date Fri, 30 Dec 2005 22:05:23 GMT
Sylvain Wallez wrote:

>>
>> But I think it can even get easier:
>> 1. Let's just assume that every component is ThreadSafe - unless
>> otherwise stated - no need to declare the interface anymore. I think
>> apart from the interpreter most components are threadsafe or poolable
>> anyway.
>>   
>
>
> This is a huge change compared to the current behaviour, where no 
> interface means not threadsafe and not reusable. IMO, this change can 
> only happen if we completely move away from Avalon.

This is not the "safe" assumption, and can cause unexpected side-effects 
in user's code.  This is not a 2.x change.

>
>> 2. Let's remove support for pooled components - yes, seriously. Fiddling
>> with the pool sizes is really annoying. We have a working factory
>> approach for sitemap components, so why not simply use it overall? And
>> rewriting the remaining pooled components shouldn't be that hard. (I now
>> that we are proxying pooled components to simplify the lookup, but you
>> still have to configure pool sizes).
>>   
>
>
> +1 for generalizing the factory pattern. Cocoon spends way too much 
> time in checking Avalon's lifecycle interfaces and parsing 
> configuration objects.


Well, a better pool like the MPool package at D-Haven will help.  MPool 
is the managed pool that will shrink pool sizes at a slower rate, 
removing the need to think about pool sizes in general (i.e. no 
deferring back to factory method).

The big thing about Avalon based components is the startup time due to 
the configuration element parsing, etc.

Now, I will say that getting rid of component pooling will require a 
major overhaul of the Cocoon internals.

>
>> My final idea is to use even more magic (but it might be too much 
>> magic?):
>>
>> class MyComponent implements SOMETHING {
>>   protected final ClassA component_A;
>>   protected final ClassB component_B;
>> }
>> When the component is instantiated all instance variables prefixed with
>> "component_" are setup using some injection mechanism - or perhaps using
>> annotations?
>>   
>
>
> Hmm...
> - how do you unit test Cocoon without the container? By subclassing to 
> access the protected fields?
> - we can't strongly enforce the contract of subclasses by making some 
> fields private.
> - the naming convention weakens the strong typing of Java. What if you 
> write "conponent_A"? Chasing the NPE won't be easy...

Danger Will Robinson!
In addition to the reasons listed by Sylvain, you are deviating far into 
left field from what the average Java developer is used to.

>
>> Now, in the end I really want to write less code :)
>>   
>
>
> Use Ruby :-P
>
> Seriously, I agree that writing less code is good, but not at the 
> price of too black magic implying weaker contracts.


Agreed.  To achieve the goal of less code would require major overhauls 
of the entire system.


Mime
View raw message