Peter Donald wrote:
>
> Hi,
>
> Ages ago a JNDI directory in the kernel was -1'ed but I think I have a good
> reason for it to be readded to Phoenix. The original kernel just stored
> Blocks in JNDI + a few token attributes IIRC. What I am proposing is a a
> more complete directory. So the kernel would host something like
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.
Remember that the Blocks and other components should still be accessed
by ComponentManager/ComponentSelector patterns.
>
> phoenix:/facilities/ConfigFacility
> phoenix:/facilities/PolicyFacility
> phoenix:/facilities/ThreadManagerFacility
> phoenix:/app1/blocks/block1/configuration-data
> phoenix:/app1/blocks/block1/instance
> phoenix:/app1/blocks/block1/meta-data
> phoenix:/app1/blocks/block1/some-other-random-bit-of-data
> phoenix:/app1/code/bars/foo.bar
> phoenix:/app1/code/support/baz.jar
> phoenix:/app1/config/server.xml
> phoenix:/app1/config/assembly.xml
> phoenix:/app1/context/directory
> etc.
>
> Of course the actual schema could be virtually anything however what is
> important is that there be a central access point for all this information.
> Currently the information is scattered around in a number of different
> places (ie ServerApplicationEntry, BlockEntry, in contexts, in component
> managers, in hashmaps).
>
> What would this effect ?
> - changes to DefaultServerApplication (change to use directory)
> - changes to DefaultKernel (change to use directory)
> - changes to DefaultSarDeployer (change to store data in directory)
> - changes to some facilities (change to retrieve data from directory)
> - create new ComponentManager that wrapped around a JNDI Context
> - it could be a PITA to code somethigns in kernel as we have
> org.apache.avalon.Context
>
> It would NOT effect any block interfaces or anything like that.
>
> It would also necessitate the addition of a new generic set of JNDI
> classes. Because we can not hijack the NamingManager I will create a
> Namespace class that serves the same purpose. Thus applications like Tomcat
> can still take over the JVM global NamingManager and we wouldn't effect it
> (and vice versa).
>
> If it does sound like a good idea we can work out a proper namespace
> segregation. However it may take a while to actually get implemented - it
> should be mostly m\painless though.
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
