You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/11/30 19:31:39 UTC

[VOTE] ComponentUtil

The following snippet is supposed to describe how ComponentUtil was envisioned
to perform.  Unfortunately, Java does not pass primitives by reference, but
by value.

public class SimpleComponent implements Component, Initializable {
     final int m_mask;
     int m_state = 0;

     public SimpleComponent()
     {
        m_mask = ComponentUtil.getMask(this);
     }

     public void initialize () throws Exception
     {
        ComponentUtil.checkInitialized(m_state);

        //do stuff
     }
}


If we do not like this usage pattern, then we should choose once and for all
whether to provide it or not.


Include ComponentUtil?

Since it is broken and I really want to get Avalon Framework 4.1 out the door,
I vote -1, remove it.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VOTE] ComponentUtil

Posted by Berin Loritsch <bl...@apache.org>.

Peter Donald wrote:

> On Sat, 1 Dec 2001 05:31, Berin Loritsch wrote:
> 
> Well I think it is kinda nice but I can't see it being used widely enough to 
> be included in framework. Maybe it would be best to include it in excalibur 
> somewhere (maybe excalibur.util ?)

NO!  It needs to be in Framework to be effective.  A framework becomes more
effective when it provides tools to enforce the contracts that are declared by
the framework.  Honestly, just because _you_ wouldn't use it does not mean
that others would not.

> Put bluntly it is highly unlikely I would ever use it or recomend using it. 
> The main reason it assumes that the environment in whihc you are working has 
> 
> a) a dodgy container

This is likely to occur when developers create Components that act as containers
for other components.  You MUST test for this!

> b) evil clients who can get direct reference to component

You can never rule this out.  It is like saying we should get rid of file permissions
just because noone is *supposed* to be able to gain access to it in a
non-prescribed manner.  Just as UNIX as a platform is hostile to viruses,
Avalon needs to be Hostile to malcontent environments.  Ignoring a potential
hole because _you_ are not concerned with it is stupidity.  It will inevitable
come and bite you in the hind quarters sooner or later.  Period.

> Even if you manage to shore up all the holes the component can still be 
> fubared by another evil component going
> 
> synchronized( myComponent )
> {
>   while( 1 ) System.sleep(100000000);
> }

Look who's been writing C++ lately!  (while only responds to boolean values,
this won't compile) ;p

Seriously, you need to close up the holes you can.  Stuff that is beyond your
control, you have to prepare for, BUT don't leave open invitations and an unlocked
door just because someone can fit down your chimney.

> If (b) is the case you are protecting against then your container should 
> never hand out direct references but instead hand out references wrapped in 
> proxies (maybe by 1.4s dynamic proxy api.
> 
> Is there another use I am missing?

ENFORCING CONTRACTS!  Good engineering ALWAYS *explicitly* enforces their contracts.

> 
> 

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VOTE][Patch] ComponentUtil

Posted by Peter Donald <pe...@apache.org>.

On Sat, 1 Dec 2001 11:04, Michael McKibben wrote:
> One way to accomplish what you are trying to do is to make the state java
> object, e.g. ComponentState, that has instance methods for validating the
> component's state.
>
> Usage pattern would then be something like:
>
> // Checks what lifecycle interfaces are implemented and returns the
> // initial state
> private ComponentState state = new ComponentState(this);
>
> Thenthe  user would call the check methods for component state validation
>
> state.configure();
> state.initialize();
> state.start();
> state.stop();
> state.dispose();
>
> // invalid state, throws some type of IllegalStateException
> state.initialize();
>
> Anyway, just a thought. Another idea would be to make the state object
> opaque and passed into the static check methods of ComponentUtil. What do
> you think?

I like that better than inheritance ! ;)

-- 
Cheers,

Pete

----------------------------------------------------
"The only way to discover the limits of the possible 
is to go beyond them into the impossible." 
                             -Arthur C. Clarke
----------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VOTE][Patch] ComponentUtil

Posted by Berin Loritsch <bl...@apache.org>.

Leo Sutic wrote:

> Michael,
> 
> true. That would be even better and provide something similar to the
> impossible multiple inheritance that I would see as the optimal solution.
> 
> Could you implement & submit a patch - maybe we can get it into framework
> 4.2 or 4.1.1. Berin?


We can get it into FRAMEWORK 4.1.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PATCH/SUMBISSION] ComponentStateValidator (was RE: [VOTE][Patch] ComponentUtil)

Posted by Berin Loritsch <bl...@apache.org>.

Peter Donald wrote:

> Hi,
> 
> On Sun, 2 Dec 2001 08:11, Michael McKibben wrote:
> 
>>Okay, I've attached an implementation called ComponentStateValidator.java
>>that basically does what ComponentUtil and AbstractComponent does. I didn't
>>patch ComponentUtil because I noticed that it has been removed from the cvs
>>tree. Feel free to move/rename it to whatever makes sense.
>>
> 
> kool - added it into Excalibur projects until it stabilizes.


Keep it in Framework.  When it is ready, we release.


>>I was also thinking that maybe in the future this could be enhanced to
>>switch off the validation, for example a static debug flag initialized via
>>a property like
>>
> 
> That could work. WHats everyone think ?


It could work, BUT just how much overhead is there with bit-tests?


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>