At 11:16 18/3/01 -0500, Berin Loritsch wrote:
>Remember the reasons that the JNDI was removed from the kernel:
>Complex security issues (you had to make sure that the blocks/apps could
>only see the things that were needed to be seen), and breaking the
>inversion of control pattern. The JNDI Context could be obtained from
>anywhere in the chain of objects--but the complexity of code required
>to manage the requesting Component's view would be insane. If you could
>limit it to the scope being different for each thread, you can better
>protect yourself. If you forced each component to authenticate itself,
>the you also could perform proper authorization. We tried to be too
>J2EE specific -- or imitating -- in our previous implementation.
Yep but unlike the previous situation in the new proposal the Blocks would
never see the JNDI Context. It is merely an implementation detail - another
kernel could be built that didn't use JNDI or directly used
DB/LDAP/whatever etc. The reason for this that it is becoming increasingly
difficult to follow execution in kernel. Data is placed in a position X at
stage Y and used at stage Z. If you don't have a good grasp it would be
difficult to follow that - centrallizing it simplifies the kernel somewhat.
The Block still becomes aware of Components/Configuration/Context through
standard Avalon/Phoenix interfaces (ie
BlockContex/ComponentManager/Configuration).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
