Am Samstag, den 30.09.2006, 12:07 +0200 schrieb Bernd Fondermann: > > Doing some POJOification can't be bad but I don't consider it a blocker. > > How do you know HOW to decouple components when you don't know where to > > go? When you decouple it from something you have to couple it to another > > thing. Being a bit container dependent can make things clearer. > > Agreed. But the situation as it is now is, that the components are > heavily coupled with > a. phoenix lifecycle interfaces
What is the problem with them? In another container the Interface might be named Lifecycle and the methods activate() and deactive(). Just refactoring. The question is how the things done in configure/start/stop/initialize/dispose fit into other frameworks. > b. avalon configuration stuff Yes, some POJOification should be done here, too. Did we decide how to do this? IMO classes with only a few configuration options should carry their attributes + getters/setters themselves. More complicated configs should be moved to separate pure POJO beans. But maybe we should do this consistent. > c. avalon/phoenix ServiceManager AFAIK POJOification in progress, or even finished? > d. avalon logger (superclass) What do you suppose? I consider this as refactoring. :-) > e. verbose + redundant config in environment.xml, *.xinfo You mean assembly.xml? Is there a possibility to avoid that redundancy in Avalon? Apart from that I find them both quite readable. > This is bad (IMHO) even if you do _not_ want to change container. > For example, look at the unit tests and the setup() methods. much too > much has to be done there to execute a simple test. this is mock-up > hell ;-) I completely agree, but I don't consider this as a blocker for evaluating different containers or even try to wire some James stuff together in order to try it inside an OSGi bundle. > > We should examine other frameworks and evaluate how we can map our > > requirements. I start with OSGi. > > ok, this has to be done. are there any learnings or requirements already? - Gravity ServiceBinder seems to be quite useful - still don't know how the OSGi ConfigurationAdmin works and how it is fed. - didn't evaluate logging . how to replace the other avalon/cornerstone stuff. like ConnectionHandling/Pooling - evaluate if existing avalon code runs inside OSGi. For ConnectionHandling/Pooling Mina might be an option. Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
