You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Alexis Agahi <al...@users.sf.net> on 2003/11/10 23:42:36 UTC
[Merlin] Internal MBeanServer component (or Cornerstone component?)
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Merlin] Internal MBeanServer component (or Cornerstone component?)
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Merlin] Internal MBeanServer component (or Cornerstone component?)
Posted by Alexis Agahi <al...@users.sf.net>.
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 ?
And of course both would be globally available in any components via
servicemanager?
huhu, Merlin is getting really cooler everyday!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Merlin] Internal MBeanServer component (or Cornerstone component?)
Posted by Stephen McConnell <mc...@apache.org>.
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>
Complementing the above will be a new block implementation (or possible
refactoring of the current block classes) to enable plug-in resolve
handling. The enhancements will enable finder oriented behaviour on a
block (i.e. similar to ECM style dynamic lookup). This ability is also
needed in one of the Turbine Fulcrum components and in Fortress style
applications. Basically the objective is provide "explicit", "finder"
and "factory" semantics as built in semantic models - but also enable
the plugging in of interceptors on any of these models.
I.e. the short answer is that the JMXMBeanServer would be a classic
component no different to any other component.
Stephen.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org