At 10:01 26/2/01 -0800, Federico Barbieri wrote: >Peter Donald wrote: >> >> At 05:23 26/2/01 -0800, Federico Barbieri wrote: >> >It's a general rule it's better to have primitive than composite >> >packages... because they don't have dependencies and they enforce SOC. I >> >may like the avalon.pool interfaces but I don't want to inherit all >> >component contracts. This make perfect sense. >> >> The problem is that if you want to place anything in a CM then it needs to >> implement Component - which is why some people I talked to said either >> *everything* should implement component or *nothing* should implement >> component and the CM should deal with objects. Thats the main reason why >> Pool etal extend Component. > >not sure... being a Recyclabe doesn't imply being a component too... so >I can have a pool being a Component and working with the CM but I can >have a pool NOT implementing component as stand alone.
you can but it is for all purposes practically unusable. Under Avalon almost all components are shared via a ComponentManager. If we have to extend components trivially to implement Component then it is a PITA to use a CM. >The reason I want to clear this is simple... container is a desing >pattern that is exteremly useful in many situation, including phoenix >and its blocks, a servlet container and its servlet etc. If we can't >decouple container from component then a SE can't benefit of the >patterns since servlet ARE NOT components. This whould be a pity... I am not 100% clear what you are saying here but if it what I think you are saying then I have a different opinion. Whether something is a component or a container is completely a matter of perspective. From one perspective a object may be a component while from another it is a container. Take phoenix - It has a kernel (container) that hosts Applications (component). These applications (now looks like a Container) are in turn made of up of content-objects/Blocks (component). This Block (now a container) can host other things like mailets/servlets/ejbs/other (component again) etc. >Then does it make sense to have a clean container package component >unaware and a higher camelot package component aware? The container can >be small but it's reusable by all container, camelot is for component >oriented containers (phoenix etc.). It does in the long run - but now is not the time to do it I don't think. We haven't road tested camelot enough for it to be viable in alternate contexts. Once we see it tested out in a few other places then it may be something we could consider. We could break it down into install/deploy/container/info/registry sections. Of course this will be more further defined after use ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
