You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/03/18 09:27:20 UTC
Universal JNDI Directory in kernel
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
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Universal JNDI Directory in kernel
Posted by Peter Donald <do...@apache.org>.
Hi,
At 01:09 19/3/01 -0800, Paul Hammant wrote:
>I'm in favour of this as it will make dynamic access to services much
easier for a dynamic sar
>like Jesktop. If assembly xml could state for individual bars which
interfaces were published to
>the jndi tree, then it could, in part, address security concerns..?
I am not sure what exactly you are talking about here. Are you talking about
* management interface (JMX style)
* inter-application communication interfaces (in-process RMI)
Both of them will be possible/easier to do in this system ... however
neither are in my scope at the moment. There is two motivating factors for
this.
(1) distributable sars/configuration. This means sars won't have to be
unzipped/extracted.
(2) reduce control complexity and push all complexity into data model.
I want (1) to help projects like eas and also to stop me from spending ages
tracking down imaginary bugs (I spent 3 hours trying to detect a bug except
I forgot to delete original directory and thus the .sar was extracted once
and never updated ;]).
For (1) I was thinking about followin the Servlet2.3 model and having
listeners being able to handle application events. So the EAS project
could listen for the deploy event and then do all their magical extraction
of tomcat resources as they see fit. (Probably could provide an interface
to wrap around ant2 for this).
I want (2) because someone was modifing the kernel and kept complaining
about complexity ;)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Universal JNDI Directory in kernel
Posted by Peter Donald <do...@apache.org>.
At 08:19 19/3/01 -0500, Berin Loritsch wrote:
>> 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>
psychic ;)
>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.
thats one idea (thou the namespace may end up less than ideal from a
management point of view). However mainly it is because I could reuse the
JNDI implementations elsewhere and the JNDI spec provides for all the
things I need (ie events and attributes of context via DirContext). Besides
I understand JNDI so it should be easier ;)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Universal JNDI Directory in kernel
Posted by Berin Loritsch <bl...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Universal JNDI Directory in kernel
Posted by Paul Hammant <pa...@yahoo.com>.
Peter,
I'm in favour of this as it will make dynamic access to services much easier for a dynamic sar
like Jesktop. If assembly xml could state for individual bars which interfaces were published to
the jndi tree, then it could, in part, address security concerns..?
-PH
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Universal JNDI Directory in kernel
Posted by Peter Donald <do...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Universal JNDI Directory in kernel
Posted by Berin Loritsch <bl...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org