cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [RT] Simplifying component handling
Date Tue, 03 Jan 2006 10:09:12 GMT
Sorry, but I don't comment on this. Just one (final) question: are you
-1 on the changes?

Carsten

Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> 
>>Hmm, so why is ECM++ different from ECM (includes, JMX etc.)? With the
>>same argument we could just use ECM with the container integrations and
>>that's it.
>>  
> 
> 
> Oh yes, sure! And why not going back to the Director interface of the 
> good old Cocoon 1.0 times?
> 
> Seriously, ECM++ allowed us to add new features that we badly needed 
> such as xconf includes, and Spring bridge among others.
> 
> 
>>Now, I'm only talking about constructor injection, so if you're using it
>>you have a well defined life-cycle of that component as the constructor
>>is called before everything else. Mixing constructor injection with
>>other Avalon interfaces might cause confusion, yes. It's up to the
>>component writer to decide this and we can come up with nice
>>documentation telling everyone how to develop components.
> 
> 
> Muhuhuhahahahaha! Nice documentation!!!! C'mon...
> 
> 
>>I would suggest to either use constructor injectior or the Avalon interfaces but not
both at the same time.
>>  
> 
> 
> Great, I suggest the same by using the Spring bridge.
> 
> 
>>However, there is one exception: the lifestyle. As we can't agree on making everything
thread safe, I think the easiest way is to support ThreadSafe, Poolable etc. with constructor
injection as well - with the default still being single threaded.
>>With constructor injection we have a simple container which is able to serve POJOs
while remaining compatible. And we are one step further in a smooth migration path.
>>  
> 
> 
> Just use Spring: this is compatible, and allows to move away from Avalon 
> faster.
> 
> 
>>Setter injection is a different thing - I personally don't want to add it as things
imho get too complicated then (but if someone wants to do it, well, why not).
>>
>>And finally, Spring is cool and has nice features, but imho it has no
>>clean separation between a component writer and a component user when it
>>comes to configuration. In fact (as a teaser :) ), I'm thinking about
>>writing a new core for Cocoon based on Spring which supports annotations
>>and the avalon style configuration based on roles and xconf files. It's
>>not that hard to do, but the question right now is if it's worth it.
>>This could simply replace ECM++. But as we don't want to build on sand
>>again, I think this is out of question anyway....
>>  
> 
> 
> Hmm... Is it April 1st already?
> 
> 
>>Now, seriously, comming back to Gianugo's concern "adding features
>>blindly not because of architectural/design issues but because it's
>>tiresome to add 5 lines of code...": As I said, these changes make it
>>imho easier to work with Cocoon and provide a required migration path.
>>  
> 
> 
> I disagree: the migration path is to allow writing components *without 
> caring about Avalon*. Any mixed model is a complexification as it 
> requires to know both models and the interaction betwen them in mixed 
> model components. And a nice documentation is not the solution.
> 
> 
>>Imho, the best way would be to think about a new architecture/design for
>>a future Cocoon, build that and provide then migration paths. But the
>>last months have shown that we have currently no common understanding of
>>a future Cocoon - everyone has her own vision and plans. And as long as
>>we are in this situation, we can imho only try to do simple steps
>>forward and see where we will arrive.
>>  
> 
> 
> Right. And the simplest and most consistent step to go forward is IMO to 
> just use what's already there, providing a nice bridge to a rock-solid 
> container used by thousands of people.
> 
> Sylvain
> 


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message