Peter Donald wrote:
>
> 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.
<aside>I like how you answer my email before I send it :)</aside>
That's fine. If all you are talking about is a way for the kernel to manage
itself, and not make the Context available generally, then I don't have an
issue with that--although why use JNDI, when the same amount of work could
be applied toward something simpler--unless you are openning up the possibility
of a GUI configuration/reconfiguration scheme.
> The Block still becomes aware of Components/Configuration/Context through
> standard Avalon/Phoenix interfaces (ie
> BlockContex/ComponentManager/Configuration).
> Cheers,
Cool. as long as we aren't changing the existing patterns.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
