You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@felix.apache.org by dj...@apache.org on 2021/07/11 23:14:01 UTC

[felix-antora-site] 12/18: remove mosgi doc (unmaintained)

This is an automated email from the ASF dual-hosted git repository.

djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git

commit 32127876e8a3db618b0969334f70715acf0fab7e
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:47:51 2021 -0700

    remove mosgi doc (unmaintained)
---
 modules/ROOT/pages/documentation/subprojects.adoc  |   2 +-
 .../subprojects/mosgi-managed-osgi-framework.adoc  | 108 -------------
 .../mosgi-managed-osgi-framework/probeguide.adoc   | 180 ---------------------
 3 files changed, 1 insertion(+), 289 deletions(-)

diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 667865b..ce7c83c 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -124,7 +124,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
 * https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-obr-plugin.html[Maven OBR Plugin]
 * https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-osgi-plugin.html[Maven OSGi Plugin]
 * https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-scr-plugin.html[Maven SCR Plugin]
-* xref:documentation/subprojects/mosgi-managed-osgi-framework.adoc[MOSGi Managed OSGi framework]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/mosgi-managed-osgi-framework.html[MOSGi Managed OSGi framework]
 * xref:documentation/subprojects/apache-felix-osgi-core.adoc[OSGi Core]
 * xref:documentation/subprojects/apache-felix-script-console-plugin.adoc[Script Console Plugin]
 * xref:documentation/subprojects/apache-felix-serialization-framework.adoc[Serialization Framework]
diff --git a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc b/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc
deleted file mode 100644
index 0e4b4a0..0000000
--- a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc
+++ /dev/null
@@ -1,108 +0,0 @@
-=  MOSGi Managed OSGi framework
-
-MOSGi enables the remote management of OSGi-compatible service gateways, using JMX.
-The framework is a reference architecture for end-to-end gateway management.
-It provides the following features:
-
-* relies on JMX management infrastructure (IP-based 	management),
-* provides two JMX agents: the standard Java 1.5 agent and a 	specific Java 1.4 lightweight embedded agent (MX4J agent deviation),
-* provides a way to deploy various probes on remote gateways,
-* provides a management console,
-* the graphical part of a probe (management console part) can 	be dynamically plugged in the management console and is dynamically 	downloaded.
-
-== Very fast QuickStart Guide
-
-Go into $FELIX_HOME/trunk/mosgi.doc and read Readme.txt.
-
-== General architecture
-
-The overall architecture is presented in the following picture :
-
-!MOSGiArchitecture.png!
-
-== How it works
-
-Managed OSGi gateways can install JMX probes from various repositories.
-A JMX probe is a standard OSGi bundle that registers an xref:#_mbean_definition[#MBean] component in the managed gateway's JMX agent.
-
-The management console (running in a standard OSGi framework) is connected to each gateway through the JMX remoting protocol.
-When it connects for the first time to a managed gateway, it asks for probes that are installed (i.e.
-all MBeans registered in the TabUI JMX domain).
-Then, for each MBean found, the management console asks for its graphical representation through a call to our standard API (component getUI() call).
-This call redirects to a bundle in the GUI probe repository that is installed by the management console.
-So the management console discovers at run-time the user interface it should use to supervise a specific remote gateway.
-
-Here is a description of different bundles that should be installed on both parts of the infrastructure (managed OSGi gateway and Management console).
-
-A managed OSGi gateway must host the following bundles :
-
-* JMX-MX4J Agent Service: provides a JMX agent.
-Either through a wrapper to jdk1.5 standard agent or through using a specific lightweight inner agent1 (originate from mx4j project).
-This agent service also declares a standard MBeanServer service interface..
-* JMX rmiregistry: wraps RMI registry life cycle.
-It's used by the JMX remoting infrastructure to register
-* JMX RMI connector: wraps a standard JMX remoting RMI connector
-* Remote Logger: notifies log informations
-
-A JMX Console is an OSGi framework also (for simplicity) which should host two bundles :
-
-* JMX Console: the graphical framework that will host graphical 	plugins
-* jmxconsole common tabs: tabs that are common to all gateways.
-For the moment it only concerns a tab that shows remote notification 	(it works whith remote logger)
-
-== OSGi/JMX MBean registration
-
-MOSGi installs JMX-MX4J agent at the gateways level.
-Any one can register an MBean to the JMX agent.
-The registration can be made in two ways.
-The direct code and the white board pattern.
-
-* In the direct code, one can register an MBean to the agent through the standard service interface : _javax.management.MBeanServer_
-
-Example:
-
- org.osgi.framework.ServiceReference sr == context.getServiceReference(javax.management.MBeanServer.class.getName());
- javax.management.MBeanServer mbs=(javax.management.MBeanServer)context.getService(sr);
- mbs.registerMBean(new MBeanImpl(), new ObjectName("Foo:FooName");
-
-Exemple of such code is uses in _mosgi.managedelements.bundlesprobes_ code in felix repository
-
-* In the whiteboard pattern, one can register an MBean through registering its interface to the framework as a service.
-If the interface name ends with MBean or if the interface is _javax.management.DynamicMBean_, the agent will automatically register the implementation as a standard MBean.
-The objectName of the MBean can either be defined at registration time with the _org.apache.felix.mosgi.jmx.agent.Constants.OBJECTNAME_ property name or automatically build through introspection.
-
-Example:
-
- java.util.Properties prop=new java.util.Properties();
- prop.add( org.apache.felix.mosgi.jmx.agent.Constants.OBJECTNAME, "Foo:FooName");
- context.registerService(test.FooMBean.class.getName(), new test.Foo(), prop);
-
-== Management Console
-
-The management console is a ad-hoc jmx compatible console.
-Its aim is not to be a concurrent to general purpose consoles like MX4J or JConsole but provides an ad-hoc user interface depending on the managed gateway.
-The console is based on a plugin framework.
-Each time the consol connects to a gateway it gets the list of available MBean.
-Then for each registered MBean it asks for specific local bundles for managing it.
-Each graphical bundle is integrated as a graphical tab in the management console.
-
-In the next screenshot, the gateway user has deployed 4 probes on the remote gateway : Remote Obr, Remote Bundle List, GNU/Linux and OSGi Plateform.!jmxconsoleGUI.png!
-
-In order to get these tabs, the gateway manager deploys the 4 probe bundles on the remote gateway and GUI tabs are automatically made available to the remote console.
-These bundles are :
-
-* ObrProbe : a probe that enables interaction with obr for 	bundle deployment
-* BundleProbe : a probe that enables the bundle life-cycle 	management
-* GNU-Linux : a probe that gets status from running host 	operating system
-* OSGi Platform : a probe that gets information from current 	running gateway
-
-These plugin are developed as simple examples and are available in felix repository.
-A xref:documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc[ProbeGuide] that  describes plugin integration is available.
-Plugin are dynamically removed and reinstalled each time you change your selected gateway.
-
-[discrete]
-==== MBean Definition
-
-An MBean is a Management Component for the JMX framework.
-It is made of an MBean interface and an implementation of it.
-The MBean interface is used to make remote management with the implementation.&nbsp;
diff --git a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc b/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc
deleted file mode 100644
index b491123..0000000
--- a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc
+++ /dev/null
@@ -1,180 +0,0 @@
-= Developing probes for MOSGi framework
-
-\{quote}
-
-\{quote} MOSGi is a management infrastructure for OSGi gateways remote management.
-The architecture relies on JMX management infrastructure and is classically build on a three layered system:
-
-!ManagementLayers.png!
-
-* The probe layer: are low layer 	elements that drive the gateway.
-They can either get information 	from the gateway (gateway status) or set information on it (install 	a bundle),
-* The Agent layer: there is one 	agent per gateway and is responsible for maintaining access to a 	list of available probes,
-* The Manager layer is the remote 	environment that can communicate with the agent to get information 	from the gateway through the probes
-
-There are various way to implements this architecture (CIM/Wbem, Snmp, JMX).
-We have choose to use the JMX proposal because it is standardized in the java virtual machine since jdk1.5.
-
-== JMX management infrastructure synthesis
-
-Sun JMX proposal defines the following elements :
-
-!JMXLayers.png!
-
-* The agent is the registry for 	probes called MBeans and is accessed through connectors.
-* MBeans are java objects that 	register themselves to the agent under some name
-* Connectors are end points were 	external managers can communicate with.
-There are currently two 	available connectors : an xml/http connector and a rmi based 	connector.
-We are using the rmi connector (JSR160).
-
-In the JMX world probes are represented as MBeans.
-They are java singleton object that declare a single interface to the agent.
-This interface is registered under a unique name within the agent namespace.
-The JMX namespace is structured as a domainname:mbeanname unique name.
-The following html page represents an example of this kind of namespace (we use the httpconnector connector with the agent to get this information).
-
-!jmxmx4jhtml.png!
-
-These are various mbeans deployed on a specific gateway.
-We can identify 4 columns : the mbean registered name (and domain), its implementation, a comment and a function to unregister it.
-
-Mbeans are component that declare a management interface that should have a syntactic name similar to the class they instrument.
-For instance the class foo.Test should implement a management interface whose name is foo.TestMBean.
-The registration mechanism associates a implementation (conform to the management interface) with an objectName (a unique identifier).
-The corresponding call is something like :aMbeanServer.register(aMBeanImplementation, anObjectName);.
-There are many kinds of MBeans (standard, dynamic, model and simple) but their description is out of the scope of this document.
-
-== MOSGi probe developpement
-
-Our management infrastructure proposes a framework for deploying standard mbean within OSGi gateways.
-It also embeds a reference to a graphical part (manager view) directly in the Mbean itself.
-Thus the management console is automatically populated with client part of the management system.
-
-=== Gateway probes
-
-These probes are developed in conformance to the following elements.
-
-* A probe must be registered under the domain TabUI.
-It means 	that they will have a corresponding tab in our management console.
-* A probe must implement a management interface conform to the 	JMX specification (ie : foo.LinuxProbe -\-> foo.LinuxProbeMBean)
-* The management interface must extend TabIfc (which declares a 	single method : getBundleName()).
-This methods returns an url were 	the management console should find a tab that can establish a 	management dialog with the probe.
-* The probe is made available as a standard OSGi Mbean that 	will make its registration during the bundleActivator start method.
-
-The following picture illustrates relations between these elements.
-
-!MOSGiProbeClasses.png!
-
-For instance a Probe that declares a single management function _int getValue()_;should provide the following interface:
-
- package foo;
- import insa.jmxconsole.gui.service.TabIfc;
- public interface ProbeMBean extends TabIfc {
-   public int getValue();
- }
-
-And the following class:
-
-----
-package foo;
-import org.osgi.framework.BundleActivator;
-import org.osgi.framework.BundleContext;
-import org.osgi.framework.ServiceReference;
-import insa.jmxconsole.gui.service.TabIfc;
-import javax.management.MBeanServer;
-public class Probe implements BundleActivator,ProbeMBean{
-  //////////////////////////////////////////
-  //   BundleActivator Interface          //
-  //////////////////////////////////////////
-  /* The probe lifecycle is linked to the bundle lifecycle */
-  public void start(BundleContext bc){
-    /* Here we register the Mbean within the agent */
-    ServiceReference sr = context.getServiceReference(MBeanServer.class.getName());
-    if (sr!=null){
-      MBeanServer server = (MbeanServer)this.bc.getService(sr);
-      server.registerMBean(this,  new ObjectName("TabUI:name=Probe");
-    }
-  }
-  public void stop(BundleContext bc){...}
-  ///////////////////////////
-  // Management interface  //
-  ///////////////////////////
-  public int getValue(){return 10;}
-
-  /* A getIfc function comes from RemoteIfc interface that enable the manager (remote console) to
-  a bundle that can communicate whith this probe from a remote URL */
-  public String getBundleName(){
-   return "http://somewhere/agraphicaltab.jar"
-  }
-}
-----
-
-Once the probe is made as a bundle it can be deployed on the remote gateway.
-Then a manager (management console) can ask communicate with the gateway agent to manage the probe.
-
-=== MOSGi JmxConsole architecture
-
-When a probe is deployed on a remote gateway it is manageable by standard management consoles like JConsole, MC4J...
-We have developed our own management console that is able to manage probe in a more dedicated approach.
-
-The management console is based on a plugin mechanism.
-Each plugin is represented as a tab and each tab manages a probe.
-The console is launched with two bundles.
-Remotegui.jar is the execution framework and remotecomponent.jar contains a sole remote logger service that gets remote notification from gateways.
-The screen represented the gateway status after it has been launched.!EmptyConsole.png!
-The left panel identifies connected gateways, The upper center panel is an container for tabs from managed gateways,
-
-The lower center panel contains the remote logger display that shows notifications from remote gateways.
-When the user selects a gateway (green flag) the console will do the following actions :
-
-. Ask all MBeans in the TabUI domain.
-. For each of these MBean, get the URL of bundle that provides 	the tab.
-This is done through the call to getBundleName( ) method in 	RemoteIfc interface.
-. Install the bundle on the gateway
-
-For instance if the user selects the green point he gets the following tabs.
-
-!TabbedConsole.png!
-
-4 probes have been deployed on the remote gateway and 4 graphical tabs have been installed.
-
-=== Graphical tab integration
-
-When developing a probe one shall provide a corresponding MOSGi tab.
-It should follow these guidelines.
-
-* It should be a bundle in order to be remotely installed on 	the console
-* It should implement Plugin interface with is the jmxconsole 	container interface specification.
-
-The plugin is mainly conform to the java beans specification development.
-The jmxconsole acts as a bean container and each tab is a bean in this infrastructure.
-This is the general architecture of a Tab class.!MOSGiConsoleTabClasses.png!
-
-The plugin interface has the following structure:
-
- package insa.jmxconsole.gui.service;
- import java.awt.Component;
- import java.beans.PropertyChangeListener;
- public interface Plugin extends PropertyChangeListener{
-   public String getName(); /* The name of the tab */
-   public Component getGUI(); /* This is called by the container to get the graphical component */
-   public void registerServicePlugin(); /* This is called by the framework when a new gateway is selected */
-   public void unregisterServicePlugin();
-   /* see before */
-   public String pluginLocation(); /* This a unique identifier of the plugin */
-     /* These are constants that enable communication between container and plugins. They are treated in the
-   propertyChange function brought by the javabean API */
-   public static final String NEW_NODE_SELECTED="newNodeSelected";
-   public static final String NEW_NODE_READY="newNodeReady";
-   public static final String NEW_NODE_CONNECTION="newNodeConnection";
-   public static final String EMPTY_NODE="emptyNode";
-   public static final String PLUGIN_ADDED="pluggin_added";
-   public static final String PLUGIN_REMOVED="pluggin_removed";
- }
-
-Implementation tabs are provided as open-source code.
-You can find various implementation of this interface in felix repository in the _mosgi.managedelements.xxx.tab_ elements.
-
-=== Function call sequence
-
-The next figure presents a function call sequence when using MOSGi framework.