org.omg.PortableInterceptor.ORBInitializerHolder Maven / Gradle / Ivy

package org.omg.PortableInterceptor;

/**
* org/omg/PortableInterceptor/ORBInitializerHolder.java .
* Generated by the IDL-to-Java compiler (portable), version "3.2"
* from /home/jenkins/agent/workspace/orb-release-build/omgapi/src/main/idl/Interceptors.idl
* Sunday, February 14, 2021 7:42:42 PM GMT
*/


/**
   * Facilitates interceptor registration and ORB initialization.
   * 
   * Interceptors are intended to be a means by which ORB services gain 
   * access to ORB processing, effectively becoming part of the ORB. 
   * Since Interceptors are part of the ORB, when ORB.init 
   * returns an ORB, the Interceptors shall have been registered. 
   * Interceptors cannot be registered on an ORB after it has been 
   * returned by a call to ORB.init.
   * 

   * An Interceptor is registered by registering an associated 
   * ORBInitializer object which implements the 
   * ORBInitializer interface. When an ORB is initializing, 
   * it shall call each registered ORBInitializer, passing it 
   * an ORBInitInfo object which is used to register its 
   * Interceptor.
   * 

   * Registering ORB Initializers in Java
   * 

   * ORBInitializers are registered via Java ORB properties.
   * 

   * The property names are of the form: 
   *   

   *     org.omg.PortableInterceptor.ORBInitializerClass.<Service>
   *   
   * where <Service> is the string name of a class 
   * which implements 
   *   
   *     org.omg.PortableInterceptor.ORBInitializer
   *   
   * To avoid name collisions, the reverse DNS name convention should be 
   * used. For example, if company X has three initializers, it could define 
   * the following properties: 
   * 
   *   
   *     org.omg.PortableInterceptor.ORBInitializerClass.com.x.Init1
   *   
   *   
   *     org.omg.PortableInterceptor.ORBInitializerClass.com.x.Init2
   *   
   *   
   *     org.omg.PortableInterceptor.ORBInitializerClass.com.x.Init3
   *   
   * 
   * During ORB.init, these ORB properties which begin with 
   * org.omg.PortableInterceptor.ORBInitializerClass shall be 
   * collected, the <Service> portion of each property 
   * shall be extracted, an object shall be instantiated with the 
   * <Service> string as its class name, and the 
   * pre_init and post_init methods shall be 
   * called on that object. If there are any exceptions, the ORB shall 
   * ignore them and proceed. 
   * 
   * Example
   * 

   * A client-side logging service written by company X, for example, may 
   * have the following ORBInitializer implementation: 
   * 
   * package com.x.logging;
   * 
   * import org.omg.PortableInterceptor.Interceptor; 
   * import org.omg.PortableInterceptor.ORBInitializer; 
   * import org.omg.PortableInterceptor.ORBInitInfo; 
   * 
   * public class LoggingService implements ORBInitializer { 
   *     void pre_init( ORBInitInfo info ) { 
   *         // Instantiate the Logging Service s Interceptor. 
   *         Interceptor interceptor = new LoggingInterceptor(); 
   *
   *         // Register the Logging Service s Interceptor. 
   *         info.add_client_request_interceptor( interceptor ); 
   *     } 
   * 
   *     void post_init( ORBInitInfo info ) { 
   *         // This service does not need two init points. 
   *     } 
   * } 
   * 
   * To run a program called MyApp using this logging 
   * service, the user could type: 
   *   

   *     java 
   *-Dorg.omg.PortableInterceptor.ORBInitializerClass.com.x.Logging.LoggingService 
   *     MyApp
   *   
   * 
   * Notes about Registering Interceptors
   * 

   * Request Interceptors are registered on a per-ORB basis. 
   * 

   * To achieve virtual per-object Interceptors, query the policies on the 
   * target from within the interception points to determine whether they 
   * should do any work. 
   * 

   * To achieve virtual per-POA Interceptors, instantiate each POA with a 
   * different ORB. While Interceptors may be ordered administratively, 
   * there is no concept of order with respect to the registration of 
   * Interceptors. Request Interceptors are concerned with service contexts. 
   * Service contexts have no order, so there is no purpose for request 
   * Interceptors to have an order. IOR Interceptors are concerned with 
   * tagged components. Tagged components also have no order, so there 
   * is no purpose for IOR Interceptors to have an order. 
   * 
   * Registration code should avoid using the ORB (i.e., calling 
   * ORB.init with the provided orb_id). Since 
   * registration occurs during ORB initialization, results of invocations 
   * on this ORB while it is in this state are undefined. 
   * 
   * @see ORBInitInfo
   */
public final class ORBInitializerHolder implements org.omg.CORBA.portable.Streamable
{
  public org.omg.PortableInterceptor.ORBInitializer value = null;

  public ORBInitializerHolder ()
  {
  }

  public ORBInitializerHolder (org.omg.PortableInterceptor.ORBInitializer initialValue)
  {
    value = initialValue;
  }

  public void _read (org.omg.CORBA.portable.InputStream i)
  {
    value = org.omg.PortableInterceptor.ORBInitializerHelper.read (i);
  }

  public void _write (org.omg.CORBA.portable.OutputStream o)
  {
    org.omg.PortableInterceptor.ORBInitializerHelper.write (o, value);
  }

  public org.omg.CORBA.TypeCode _type ()
  {
    return org.omg.PortableInterceptor.ORBInitializerHelper.type ();
  }

}