Sky Torch wrote: > > Hello, > > i've digged through some avalon usage in cocoon2, have the following > questions. can someone drop some thoughts? > > 1. why there're 2 DefaultComponentManager class impl in framework and > excalibur pkgs, isn't it confusing to some extent ?
maybe so. We could change the name, deprecating the Default* version in Excalibur. I hate to do that flippantly. > 2. it seems to me Cocoon class in Cocoon2 is a "container" class that imbed > a component manager. in this scenario, is it supposed to handle all the > lifecycles of components? i.e. instantiate component and populate them into > component manager ? The Excalibur Component Manager is the container for all Components in the configuration file--or that are registered with it. The Cocoon class is a container for the sitemap manager, and has to manage that lifecycle. > 3. in component manager in excaliber pkg, what's difference btw > addComponent() and addComponentInstance() ? Notice that addComponent() takes a Class and addComponentInstance takes a Component. Basically addComponentInstance() is allowing the component manager to handle a Component that is explicitly created AND INITIALIZED so that clients of the Component manager can look it up. > 4. who's responsible to the life cycle of component manager and role > manager? it seems to me container is. True. In Cocoon's case, the Cocoon object is the container that manages the Component Manager and Role Manager. > 5. who does componentmanager.release() do? according to javadoc, it > "release" component back. what if i don't release it? is it going to > "locked", i.e. it's a impl of single thread model ? SingleThreaded COmponents in the Excalibur component manager are created using the Factory method. In other words, a new instance is created for every lookup. Releasing a Component allows the ComponentManager to return a component to a pool if it is Poolable, or apply the end of lifecycle stages for SingleThreaded components. The ThreadSafe componets have no action taken on them. Excalibur's Component Manager is written in such a way that it will always succeed. The Component pool for Poolable Components will expand temporarily to handle excessive requests for the Component. ThreadSafe components simply share the reference to the same Component, and SingleThreaded (default) components are created fresh for every request. In general it is best to release the used component when you don't need it any more. If you need it the entire time your component is alive, then release it in a dispose() method and implement Disposable. > 6. i see some benefit of using excalibur pkg. but if i don't use those > components, what's benefit of using framework pkg? i can basically define > similar interface and implement in my propriotary system and don't have to > spend time to dig into avalon framework apis. You can build your own version of the Eifel Tower as well--not too practical. Hopefully I will be done with my paper on Avalon soon, and can start incorporating it into the online docs. The difference between the Excalibur and Framework packages are many. First and formost, the Framework implementation is very simple, and assumes all components are ThreadSafe--not much more to it than a HashMap. The Excalibur version has a configuration language and automatic handling of pooling and factory methodologies. The Framework version is not a container, but the Excalibur version is. There are different semantics, so you may want to use Framework's component manager. The advantage of Excalibur's component manager is that it automatically handles a host of details for you. The disadvantage is that it is big and comprehensive. One thing is sure: both versions are fast, and lookup times vary only slightly between the two. > 7. what's component handler used for? i ran through some avalon src code, it > seems that lookup() -> role -> handler -> component within component > manager. i don't quite get why handler is being used ? The Handler is used to encapsulate the code that manages whether a Component is SingleThreaded, Poolable, or ThreadSafe. That way, we can avoid a bunch of if/then/else statements, and can be assured that the Component is being handled in a consistent manner throughout it's life. > 8. what's the concept of work interface? is it a real java interface or just > a concept in avalon component framework? The work interface is a real java interface. The distinction between the work interface and some other interface is it's purpose. The work interface is the one you actually use to do the work of the component. e.g. Cocoon's Parser interface. That interface describes the different methods that a client of that Component can use like parse(InputSource). It should not have any non-work related methods. The other interfaces like Component, Contextualizable, Composable are implemented by the Component class to address other concerns of the Component--but you do not use them to do the work of the Component. > thanks in advance. Your welcome in advance ;P --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
