Peter Donald wrote: > > 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. >
quite true... classes should implement all needed patterns as they wish, interfaces shouldn't overlap when it's not needed. take a look at container/camelot. container is component free, camelot uses both patterns for abstract classes and provide a solid ground for component and container aware app (phoenix etc.) > >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. I meant tomcat is a Component viewed from the kernel since implements Block. But its a container of servlets. Now servlet are not Component but still Tomcat should be a Container... that's way Container shouldn't be Component container. > > >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 ;) have a look and tell me... I think that separation make things clearer. Fede
