Peter Donald wrote: >On Wed, 13 Feb 2002 21:04, Sylvain Wallez wrote: > >>Something that's missing in component management is some formal >>description of components : blockinfo provides block dependencies, but >>we could also have a formal description of the configuration of the >>component (I don't want to say XMLSchema because of it's heavy weight). >> >+100 > >We have talked about this before but no one ever got around to implementing >it ;) > Stuff that is not absolutely required often has a lower priority, even if it could make life easier... I'm sure one day we will need it, to provide non-technical users an easy way to assemble their application or server.
>>BTW, I know quite well CM/CS for having used it a lot in Cocoon and my >>projects, but not much Phoenix. It seems to me (and the current >>discussions enforce this feeling) there's a lot of redundancy both in >>concepts and code between Service/Block and Component >>interface/implementation. Moreover, looking at the "what-is-a-block" >>page, many of the given examples are what we have as components in Cocoon. >> >Yep. There are four main differences. > >* In Phoenix the container is considered god and enforces all the contracts. >It provides each block to other blocks only via a proxy and shutsdown the >proxy when block gets shutdown (eliminating dangling references). It also >only allows access to components if explicit dependencies are declared and >makes sure everythings gets called with correct ContextClassLoader and >ThreadGroup set etc. > >* In phoenix there is left emphasis on request based components and more on >persistent service components. ie You will never see any Block use >ComponentManager.release() because it does not make sense in the context but >I suspect at then end of each request a bunch of resources are released back >to Cocoons container. > Yes, mainly because they're not ThreadSafe. So, if I understand correctly, a block is implicitly considered as thread safe and doesn't use the lifestyle interfaces (ThreadSafe, SingleThreaded, etc). >* assembly in Phoenix is more complex and explicit. Except for the >environment.xml file most of this could be done in a lightweight fashion to >fit in with cocoon but no one has ever made time to do so ;) > >* Phoenix hosts multiple applications in different areas where ECM does a >single application - but may allow partial isolation via inheritance of ECM >etc > Apart the third point (no lifestyle interfaces because of implicit thread safety), the main difference I see lies in the usage context : blocks are managed by the phoenix kernel which provides them with a local CM where they can lookup their dependencies, while a component is managed by a (hierarchy of) CM that define a single application (or container, following Berin's proposal terminology) >> From what I can, see, a block can provide several services (but AFAICS, >>most of them provide only one), whereas a component implements only one >>role. Could you enlighten me on this or point me to relevant resources >>(other than the web site) ? >> > >Yep in Phoenix you can provide multiple services - usually different versions >of same sort of service but useful to different users. For instance a Block >may suppoort the FooService, ExtendedFooService and FooMBean - each of which >is used by different clients but has the same general idea > I guess this mean the block implements the 3 interfaces, or that these interfaces extend each other, right ? Thanks for your answers, Sylvain -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
