Leif Mortenson wrote:
>
> Berin Loritsch wrote:
>>
>>There is a utility class in Excalibur's Scratchpad that will help you
>>out. I am not at the right computer, so I can't give the full
>>class name now. It should be ComponentValidator or something like
>>that.
>>
>>
> Thanks, yet the class is
> org.apache.avalon.excalibur.util.ComponentStateValidator. But if I am
> not mistaken. That is a class that can be used to track the state of a
> component that you make. It looks like you create an instance of the
> ComponentStateValidator in your component's constructor passing in the
> component's this reference. Then in each of your action methods, call
> the appropriate validator method.
> For example:
> public void compose(ComponentManager manager) throws ComponentException
> {
> m_validator.checkComposed();
>
> ...user code...
> }
>
> It appears that this is a utility class to help make it easier for the
> components to protect themself.
> The problem that I ran into was that the DefaultLogKitManager does not
> defend itself from containers which do not follow the contracts
> correctly. In my case, this was caused by me creating a container at the
> same time as I was trying to learn how to do so.
:). To answer your question of whether it is the responsibility of the
class to protect itself vs. the responsibility of the container--there is
no agreed upon method. I personally prefer all my code to be checked
explicitly. Peter, on the other hand, prefers the container to validate
all the contracts. There are consequences to both of these approaches.
In my approach, the Component itself is protected, and no matter what the
Container does--but at the cost of adding in the explicit checking code.
In Peter's approach, the Component is safe as long as the Container obeys
the lifecycle contracts--but if it's initialization is dependant on the
order of lifecycle contracts and the Component is used in a bad container,
it will malfunction.
It's a question of what do you make smart, and what are the tradeoffs.
Naturally, there is a slight performance hit when you place checking logic
in the component itself (very slight). The ComponentValidator class can
be used in either the Container or the Component (or both), and helps newcomers
learn the system better with fail-quick messages and helpful exceptions.
> What is the coding standard for Avalon code? Are cases like this
> considered a problem in the Avalon class? Or are they only required to
> not throw NullPointerExceptions etc if the contacts are followed exactly?
If any exception is thrown during the initialization of a Component, that
Component is no longer valid. If a valid component ever throws an exception
that is not part of the contract of the Component (like a NullPointerException),
then the Component is broken.
> I vote for making the Avalon classes as rugged as possible in cases like
> this. Esp the classes which new users are most likely to be having to
> access directly from their own containers.
I agree, but there are those who hold differing oppinions. In the end, you
must do what you feel is right. However, do listen to those who have different
oppinions from you, you might learn something.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
