Peter Donald wrote: > > At 12:59 27/2/01 -0800, Federico Barbieri wrote: > >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. > > okay - I don't thikn it is any more. Entry's contain Objects rather than > Components and thus can follow any design pattern from > EJB/servlet/mailet/Portlet/other. >
ok then why the Container must be a Component? I can have a servlet that "contains" others parts like Cocoon, Turbine etc. Why should they be Component or at least be forced to use Components somewhere if they don't want to? > >> 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. > > Perhaps - I don't see it though because most of them are used together. I > would separate out "AvalonState" but no others ;) most of them are used together in Phoenix. It's not intrinsec in the container design the use or the need for components. I just don't think interfaces should enforce a relation for no reason. Classes and abstract classes should. Interfaces shouldn't. > > BTW could you use specific imports instead of glob imports. Especially in > the proposal. The reason is that it makes it easy to refactor - you can > search and replace the appropriate strings but with import globbing you > actually have to think ;) > My fault! I war trying to get it compilable fast... :-) Fede
