Peter Donald wrote:
On Mon, 3 Dec 2001 10:24, Berin Loritsch wrote:
Please, before moving code from one package to another, check
with everybody first. I usually have too much going on in the
weekends to respond, so give me till Monday at least!
It should never have been checked into framework proper to begin with.
Framework is a place for the lifecycle interfaces and essential utility
classes (ExceptionUtil and friends). More importantly it is meant to be
stable and well tested.
Yes it should have. Any framework needs to provide methods of validating
the contracts it declares. This is CORE to the framework.
The first cut of ComponentUtil didn't work in any shape or form and its
design was flawed. The second cut didn't even compile. So it could not be
considered stable or well tested and I don't even consider it an essential
utility class.
The second cut compiled and worked on my machine, and I could have sworn
that was in CVS when I had to leave the office on Friday.
And I completely disagree with you--it IS an essential utility class.
If you really think it belongs in framework then chuck it in a proposal
directory and then ask for a vote when it is ready.
With the last changes, it should be ready.
I hope you are not suggesting this is good programming practice? But you seem
to claim it is good programming practice for Avalon components? If the
container is stuffed then miscalling lifecycle methods is the least of your
worries.
You are comparing Apples and Oranges. The Servlet Container does not allow
you to make "mini-containers" inside the major one. However, Avalon Components
are able to be built in such a heirarchical manner. You have no direct control
over what kind of Container is going to hold the Avalon Components. Therefore,
because you cannot guarantee that your Component will be managed by
ExcaliburComponentManager or any of the OFFICIAL Avalon classes, you have to
enforce your contracts.
It is better to FAIL-EARLY than to wait and have some indesirable side effects
later. That will help the person writing the new Container code to do it
correctly
instead of having something that works 90% of the time, but not the remaining
10%.
If you are trying to claim that this sort of method is useful for security
then my response is; If an "evil" component has direct access to the object
then you have already lost the battle and your system is probably
alreadycompromised - protecting against this evil component messing with
lifecycle methods is the least of your worries.
Just as IoC is a tool in the hands of a developer to help enforce security
AND MINIMIZE RISK when security is breached, so is explicitly enforcing
contracts.
A non-well behaved Component will blindly accept Configuration objects from
the configure() method and be ripe for the exploiting. A well behaved Component
will detect this, and throw an exception.
Enforcing contracts should not be viewed as "optional",
and only if you use Excalibur. Enforcing Contracts is a core part
of any framework--and we should include the code that validates our
known contracts within Framework.
So write a base TestCase class that can use to test the container.
That only works if the person uses it. This works all the time.
and finally, Bit Tests are fast!
--
"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]>
