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]
