Alexis Agahi wrote:
On Tuesday 11 November 2003 00:44, Stephen McConnell wrote:
Alexis Agahi wrote:
Hi,
After some discussion a few weeks ago, someone (from Steve?) sugested that merlin could have a kernel service that could provide JMX manager for application.
Maybe merlin could use a JMX MBeanServer component ready to be composed by any service, and btw this component could be generic cornerstone-like component that could provide jmx implem abstraction?
I'm just reworking on the generic MBean deployer for merlin and I think it
should be nice to use the merlin MBeanServer instead of declaring my own.
What I have on paper is the addition of an <implementation> and <facilities> element to the <kernel> defintion. The <implementation> is the container of system facilities. These facilities will be exposed to the container internals and som cases will replace bootstrap services. For example, the logging system used during bootstrap may be redefined as part of <implementation> defintion. In conjuction with this defintion, the container established to handle implementation components will be supplied with the full container classloader. On completion of the deployment of the implementation, a second facilities container will be deployed.
<kernel>
<system>
<implementation>
<component name="urn:avalon:logging" type="org.apache.avalon.logging.DefaultLoggingManager"/>
<component name="urn:avalon:jmx" type="org.apache.avalon.jmx.StandardMBeanServer"/>
<component name="urn:avalon:iiop" type="org.apache.avalon.iiop.DefaultORBManager"/>
<!-- etc. -->
</implementation>
<facilities>
<!-- Extensions that are restricted to the API and SPI container classes including listeners, interceptors, and other container side add-ons -->
<component name="urn:avalon:jmx-manager" type="org.apache.avalon.jmx.DefaultApplianceListener"/>
</facilities>
</kernel>
Ok
So the difference the implementation & facility is that anyone could provide its own components as a facility (plugin like approach) for all running application, whereas implementations are internally-merlin-only components ?
Yes.
And of course both would be globally available in any components via servicemanager?
Umm, neither actually - at least not in terms of classic component services.
The components established under the implementation and features group are strictly internal container components. E.g. a logging manager is not exposed to a component - but logging manager loggers are. A jmxserver would not be exposed to compoents either - instead a listener would catch events and use meta data and meta info to dynamically build and register mbeans with the server. A security component could establish a JVM Subject under the context, etc.
The thing is that the only stuff common to the container and the components are the classes in the API (which basically means the framework, meta model, events, and standard java stuff). This eliminates the possibility of service X because X does not exist in the common classloader. However things like Principal, Subject, and any other standard Java class can be exposed.
What this means is that with the addition of security policies that differentiate from system and user scope - we significantly reduce concerns related to nasty components compromising the container. All this really means is that the export of services (e.g. via context) is completely explicit within the kernel definition. In effect - declarations within the <system> scope should be subject to rigerouse assesment wheras component declarations in user space can be much more liberal.
Cheers, Steve.
huhu, Merlin is getting really cooler everyday!--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
