> From: Gonzalo Diethelm [mailto:[EMAIL PROTECTED]]
<snip/>
>
> class Foo implements LogEnabled, Configurable { ... }
>
> Now, I start by testing this class from a simple command line
> program. At this point:
>
> 1. Do I gain anything by having Foo implement LogEnabled and
> Configurable?
You do if you call the methods in the right order. That is why we
posted the order of the lifecycle methods.
>
> 2. Who will call the proper configure() method in the class?
> Does the class have to be put into a component manager? This
> seems to me to be the case, and if this is so, then it is kind of
> useless to have a component "living by itself", not as part of a
> component manager. Is this correct?
It needs a Container. A container is the code that manages the
instances of the component. The componentmanager is just the interface
used to get at the component you want. The ExcaliburComponentManager
combines the concepts of the CM and container into one class. There
are other containers available.
>
> 3. If the "component by itself" does indeed not make sense: the
> docos talk about running components as stand-alone programs (such
> as my test case). In this case, the test program is responsible
> for taking the component through the life cycle, right? In this
> case, and supposing the component will ONLY be run from a test
> program, is there any value at all in making this class a
> component and having it implement Configurable? I mean, someone
> will have to call the configure() method anyway; why not have the
> component call it itself when appropriate?
If you have no intention of using a component in a running system,
don't make it a component. You are right it does not make any sense.
However, you do want to make sure you don't confuse calling any old
object a component. If you want an object to read configuration
data from any source, and configure itself, then you shouldn't do it
through a component. Such a practice is called Subversion of Control,
and it is a nasty bug-in-waiting if you apply it to components.
Keep in mind that Excalibur has a testcase package that will read
configuration information that you can use in your tests. It will
also prepopulate a Logger, a Container, a Context, your Configuration
tree, and manage your components for you. All you have to do is
write the tests that exercise your component.
> The second scenario is running this business logic from a
> servlet-based application. Under this scenario, the user
> interface is handled with Struts; the user enters some data,
> clicks on a button, and a Struts Action class is reached. At
> this point, the Action class grabs the entered data and is ready
> to call the business logic component.
>
> 4. Is there any benefit in using a ComponentManager here? After
> all, the Action class could simply create an instance of Foo,
> pass the parameters and grab the result, right?
The process of creating and destroying a component can be costly.
Especially if you have to keep reading the same config data each time.
You also add unnecessary overhead to the garbage collector.
Cocoon is an example of a very powerful servlet built on Avalon
components.
It uses the ComponentManager to get the instances of the components
you need.
However, in JSP environments, you effectively have many different
servlets (each JSP is converted to a servlet). What you can do is to
bind the ComponentManager to JNDI, and have each Action or JSP get
the instance of the component from the CM in JNDI.
You still need the container because each component might have
what I call different lifestyles. One component could be ok with
being a Singleton (i.e. one instance for all clients to share),
while another requires a unique instance per thread. The container
takes care of instance management policies.
>
> 5. My understanding is that the ComponentManager at least would
> be helpful in providing some kind of pooling of components. If
> this is the case, would the ComponentManager be a Singleton? If
> yes, who instantiates it? Who ensures it really IS a singleton?
You do. Static accessors are the enemy of Inversion of Control.
You do want to ensure your components can't talk directly to their
container.
That said, you had a two pronged question. Is the ComponentManager
a singleton? The answer is it depends on the container. The
ComponentManager interface is an access mechanism. The Excalibur
ComponentManager is a combination of a container and a componentmanager.
It kind of grew without being properly designed. However many people
find it easy to get up and running with.
The real question is how do I ensure the container is a singleton?
In a servlet/webapp environment, you can use the approach I mentioned
above.
You have a master servlet whose responsibility is to set up the root
container, and bind it to the JNDI context. That servlet would be
auto-loaded with the highest precedence to ensure that the container
is set up.
The servlet would check to see if the container is already bound. If
not, it creates and binds the container. If it has been bound already,
the servlet does nothing.
>
>
> The Struts scenario is more than just an hypothetic example; it
> is EXACTLY the way we plan to build our applications. So, my
> last questions are:
>
> 6. Anybody is using Struts + Framework? Can anybody share
> comments, hints, caveats, etc.? For example, can you use LogKit
> on the Struts Action classes and on the Components, and have all
> output treated uniformly? Or does Struts REQUIRE using log4j?
I must admit ignorance on this point. I have looked at Struts in the
past, but never really had time to mess with it. If Struts uses
Commons Logging, then you can use LogKit in both scenarios.
>
> 7. Anybody can provide a real working example of the Struts +
> Framework combination?
No, but I can point you at Cocoon. It's a beast, but it does answer
some questions about using Framework in a servlet environment.
>
> Sorry if the questions seem basic or confused, and thanks in
> advance for any help.
>
No problem man.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
