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.
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.
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.
> There is a _very_ good reason that the Component validation code
> *should* be in Framework. The most important reason is that Framework
> needs a mechanism to validate it's proper use. It helps newbies
> find out whether their Components will work properly. Also, by
> including such a validation, we can enforce our contracts better.
> Enforcing contracts is a _good_ and _proper_ method of engineering
> a system.
Enforcing contracts is good - when they need to be enforced. I don't go
through my servlet code and put things like
void init()
{
if( state >= INITIALIZED )
{
final String message = "Oh no the servlet container is stuffed";
throw new IllegalStateException( message );
}
}
public void destroy()
{
if( state != INITIALIZED )
{
final String message = "Oh no the servlet container is stuffed";
throw new IllegalStateException( message );
}
}
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.
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.
> 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.
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
