Re: [phoenix] RT: Kernel Services

[Peter Donald <do...@apache.org>]

On Sun, 30 Sep 2001 19:48, Mircea Toma wrote:
> > allow reuse but if it was in application space you could easily use
> > Jetty/Tomcat or whatever to run webapp, jtelnetd to run tlenet daemon or
> > whatever. And things become much easier (just drop .sar file into ./apps
> >to enable agent).
>
> Yes, that's cool but the kernel level interfaces have to be stable then.

yep ;)

> How do you see making a privileged .sar or block? ... "privileged" is more
> like "trusted"!

yes - thats sounds better.

> > Cons:
> > * Tighter binding between .sar and kernel
> > * Privlidged .sars may become bound to specific kernel implementations
>
> Not if the interfaces are well defined!

true - I don't think we are close enough to having standard yet.

> > - Where to we declare a dependency on Kernel services? Do we declare it
> > at Block level or at .sar level ? ie in blockinfo files or assembly
> > files?
>
> in blockinfo files as kernel-service?!

works for me !

> > - And thus where do we make the services available? in ComponentManager
> > or via BlockContext?
>
> ComponentManager would be the natural choice, kernel level services have
> roles and are also Component-s.

kool.

> > or some other form?
> > - Which Kernel components should we export?
>
> ConfigurationRepository?

Perhaps - the interface currently exposed isn't that useful atm. So it would 
nee reworking. I was planning to make make it possible for blocks to modify 
their own configuration via the BlockContext in the future.

Adding ConfigurationRepository would allow one block to manage multiple other 
Blocks configurations (some of which may be in different SAR).

> > as does MBeanServer,
>
> -1
>
> I see the MBeanServer and even the SystemManager outside the kernel.
> SystemManager can act as a facade to kernel services.

Thats one way of doing it. In which case the kernel would need to add in some 
naming services (JNDI) that is accessible. 

The one thing that makes me nervous about this is that would mean that Blocks 
would have to implement their own management interface. A while back someone 
suggested that we have the "manager" object/MBean sit side by side with real 
object (partially acting as a wrapper/adapter). By doing it this way we would 
not have to pollute real task with management stuff (ie all the extra 
getter/setter methods) that often increases surface area of object.

Anyways something to think about.

-- 
Cheers,

Pete

Duct tape is like the force.  It has a light side, and a dark side, and
it binds the universe together ...
                -- Carl Zwanzig

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

RE: [phoenix] RT: Kernel Services

[Stephen McConnell <mc...@osm.net>]

> > How do you see making a privileged .sar or block? ... 
> "privileged" is more like "trusted"!
> 
> yes - thats sounds better.

Trusted is the wrong term here - placing trust is something
is an action I may take following consideration of the risks 
implied by the action.  In this context the term "privileged" 
marks a block or sar as an entity which presents a different 
risk profile than a non-privileged entity. 

Cheers, Steve.

Stephen J. McConnell, OSM sarl
digital products for a global economy
http://www.osm.net
mailto:mcconnell@osm.net




---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org