aboutsummaryrefslogtreecommitdiffstats
path: root/lib/orber/doc/src
diff options
context:
space:
mode:
Diffstat (limited to 'lib/orber/doc/src')
-rw-r--r--lib/orber/doc/src/CosNaming.xml71
-rw-r--r--lib/orber/doc/src/CosNaming_BindingIterator.xml99
-rw-r--r--lib/orber/doc/src/CosNaming_NamingContext.xml243
-rw-r--r--lib/orber/doc/src/CosNaming_NamingContextExt.xml102
-rw-r--r--lib/orber/doc/src/Makefile172
-rw-r--r--lib/orber/doc/src/Module_Interface.xml356
-rw-r--r--lib/orber/doc/src/Orber/InitialReference.java131
-rw-r--r--lib/orber/doc/src/Orber/Makefile71
-rw-r--r--lib/orber/doc/src/any.xml114
-rw-r--r--lib/orber/doc/src/book.xml49
-rw-r--r--lib/orber/doc/src/ch_contents.xml173
-rw-r--r--lib/orber/doc/src/ch_debugging.xml210
-rw-r--r--lib/orber/doc/src/ch_exceptions.xml238
-rw-r--r--lib/orber/doc/src/ch_idl_to_erlang_mapping.xml1504
-rw-r--r--lib/orber/doc/src/ch_ifr.xml50
-rw-r--r--lib/orber/doc/src/ch_install.xml1001
-rw-r--r--lib/orber/doc/src/ch_interceptors.xml278
-rw-r--r--lib/orber/doc/src/ch_introduction.xml145
-rw-r--r--lib/orber/doc/src/ch_naming_service.xml465
-rw-r--r--lib/orber/doc/src/ch_orber_kernel.xml103
-rw-r--r--lib/orber/doc/src/ch_orberweb.xml221
-rw-r--r--lib/orber/doc/src/ch_security.xml96
-rw-r--r--lib/orber/doc/src/ch_stubs.xml284
-rw-r--r--lib/orber/doc/src/corba.xml454
-rw-r--r--lib/orber/doc/src/corba_object.xml194
-rw-r--r--lib/orber/doc/src/dataframe1.gifbin21074 -> 0 bytes
-rw-r--r--lib/orber/doc/src/dataframe2.gifbin27848 -> 0 bytes
-rw-r--r--lib/orber/doc/src/dataframe3.gifbin30290 -> 0 bytes
-rw-r--r--lib/orber/doc/src/dataframe4.gifbin40114 -> 0 bytes
-rw-r--r--lib/orber/doc/src/dataframe5.gifbin11184 -> 0 bytes
-rw-r--r--lib/orber/doc/src/dataframe6.gifbin12331 -> 0 bytes
-rw-r--r--lib/orber/doc/src/dataframe7.gifbin12768 -> 0 bytes
-rw-r--r--lib/orber/doc/src/dataframe8.gifbin29939 -> 0 bytes
-rw-r--r--lib/orber/doc/src/dependent.gifbin1936 -> 0 bytes
-rw-r--r--lib/orber/doc/src/example_part.xml36
-rw-r--r--lib/orber/doc/src/firewall_nat.gifbin11939 -> 0 bytes
-rw-r--r--lib/orber/doc/src/fixed.xml160
-rw-r--r--lib/orber/doc/src/ifr_notes.txt53
-rw-r--r--lib/orber/doc/src/iiop.gifbin5899 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/GridBagEx.gifbin2453 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/OpenBookIcon.gifbin2241 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/blue-ball-small.gifbin255 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/blue-ball.gifbin925 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/class-index.gifbin1497 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/constructor-index.gifbin1711 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/constructors.gifbin1565 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/cyan-ball-small.gifbin255 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/cyan-ball.gifbin925 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/error-index.gifbin1438 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/exception-index.gifbin1707 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/green-ball-small.gifbin102 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/green-ball.gifbin886 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/interface-index.gifbin1648 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/magenta-ball-small.gifbin104 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/magenta-ball.gifbin896 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/method-index.gifbin1588 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/methods.gifbin1403 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/package-index.gifbin1607 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/red-ball-small.gifbin255 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/red-ball.gifbin527 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/variable-index.gifbin1576 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/variables.gifbin1380 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/yellow-ball-small.gifbin255 -> 0 bytes
-rw-r--r--lib/orber/doc/src/images/yellow-ball.gifbin925 -> 0 bytes
-rw-r--r--lib/orber/doc/src/interceptor_operations.gifbin14537 -> 0 bytes
-rw-r--r--lib/orber/doc/src/interceptors.xml284
-rw-r--r--lib/orber/doc/src/intro_part.xml41
-rw-r--r--lib/orber/doc/src/lname.xml166
-rw-r--r--lib/orber/doc/src/lname_component.xml113
-rw-r--r--lib/orber/doc/src/menuframe.gifbin12007 -> 0 bytes
-rw-r--r--lib/orber/doc/src/name.gifbin5015 -> 0 bytes
-rw-r--r--lib/orber/doc/src/notes.xml860
-rw-r--r--lib/orber/doc/src/orber.xml653
-rw-r--r--lib/orber/doc/src/orber_acl.xml107
-rw-r--r--lib/orber/doc/src/orber_diagnostics.xml81
-rw-r--r--lib/orber/doc/src/orber_ifr.xml1035
-rw-r--r--lib/orber/doc/src/orber_tc.xml259
-rw-r--r--lib/orber/doc/src/orbs.gifbin2817 -> 0 bytes
-rw-r--r--lib/orber/doc/src/part.xml49
-rw-r--r--lib/orber/doc/src/ref_man.xml53
-rw-r--r--lib/orber/doc/src/theORB.gifbin4706 -> 0 bytes
-rw-r--r--lib/orber/doc/src/tools_debugging_part.xml40
82 files changed, 0 insertions, 10814 deletions
diff --git a/lib/orber/doc/src/CosNaming.xml b/lib/orber/doc/src/CosNaming.xml
deleted file mode 100644
index 251e721df1..0000000000
--- a/lib/orber/doc/src/CosNaming.xml
+++ /dev/null
@@ -1,71 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>CosNaming</title>
- <prepared></prepared>
- <docno></docno>
- <checked></checked>
- <date>1997-06-10</date>
- <rev>A</rev>
- </header>
- <module>CosNaming</module>
- <modulesummary>The CosNaming service is a collection of interfaces that together define the naming service.</modulesummary>
- <description>
- <p>The naming service provides the principal mechanism for clients to find
- objects in an ORB based world. The naming service provides an initial naming
- context that functions as the root context for all names. Given this context
- clients can navigate in the name space. </p>
- <p>Types that are declared on the CosNaming level are:</p>
- <code type="none"><![CDATA[
-typedef string Istring;
-struct NameComponent {
- Istring id;
- Istring kind;
-};
-
-typedef sequence <NameComponent> Name;
-
-enum BindingType {nobject, ncontext};
-
-struct Binding {
- Name binding_name;
- BindingType binding_type;
-};
-
-typedef sequence <Binding> BindingList;
- ]]></code>
- <p>To get access to the record definitions for the structs use:</p>
- <code>-include_lib("orber/COSS/CosNaming.hrl").</code>
- <p>Names are not an ORB object but the can be structured in components as seen by
- the definition above. There are no requirements on names so the service can support
- many different conventions and standards.</p>
- <p>There are two different interfaces supported in the service:</p>
- <list type="bulleted">
- <item>NamingContext</item>
- <item>BindingIterator</item>
- </list>
- </description>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/CosNaming_BindingIterator.xml b/lib/orber/doc/src/CosNaming_BindingIterator.xml
deleted file mode 100644
index 69b0f42b22..0000000000
--- a/lib/orber/doc/src/CosNaming_BindingIterator.xml
+++ /dev/null
@@ -1,99 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year>
- <year>2016</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>CosNaming_BindingIterator</title>
- <prepared></prepared>
- <docno></docno>
- <checked></checked>
- <date>1997-06-10</date>
- <rev>A</rev>
- </header>
- <module>CosNaming_BindingIterator</module>
- <modulesummary>This interface supports iteration over a name binding list.</modulesummary>
- <description>
- <p>This interface allows a client to iterate over the Bindinglist it has been
- initiated with.</p>
- <p>The type <c>NameComponent</c> used below is defined as:</p>
- <code type="none">
- -record('CosNaming_NameComponent', {id, kind=""}).
- </code>
- <p><c>id</c> and <c>kind</c> are strings. </p>
- <p>The type <c>Binding</c> used below is defined as:</p>
- <code type="none">
- -record('CosNaming_Binding', {binding_name, binding_type}).
- </code>
- <p><c>binding_name</c> is a <c>Name = [NameComponent]</c> and
- <c>binding_type</c> is an enum which
- has the values <c>nobject</c> and <c>ncontext</c>.</p>
- <p>Both these records are defined in the file <c>CosNaming.hrl</c> and it
- is included with:</p>
- <code type="none">
- -include_lib("orber/COSS/CosNaming/CosNaming.hrl").
- </code>
- </description>
- <funcs>
- <func>
- <name>next_one(BindinIterator) -> Return</name>
- <fsummary>Return a binding</fsummary>
- <type>
- <v>BindingIterator = #objref</v>
- <v>Return = {bool(), Binding}</v>
- </type>
- <desc>
- <p>This operation returns the next binding and a boolean. The latter
- is set to true if the binding is valid otherwise false. If the boolean
- is false there are no more bindings to retrieve.</p>
- </desc>
- </func>
- <func>
- <name>next_n(BindinIterator, HowMany) -> Return</name>
- <fsummary>Return a binding list</fsummary>
- <type>
- <v>BindingIterator = #objref</v>
- <v>HowMany = int()</v>
- <v>BindingList = [Binding]</v>
- <v>Return = {bool(), BindingList}</v>
- </type>
- <desc>
- <p>This operation returns a binding list with at most HowMany bindings.
- If there are no more bindings it returns false otherwise true.</p>
- </desc>
- </func>
- <func>
- <name>destroy(BindingIterator) -> Return</name>
- <fsummary>Destroy the iterator object</fsummary>
- <type>
- <v>BindingIterator = #objref</v>
- <v>Return = ok</v>
- </type>
- <desc>
- <p>This operation destroys the binding iterator.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/CosNaming_NamingContext.xml b/lib/orber/doc/src/CosNaming_NamingContext.xml
deleted file mode 100644
index 4c83e6a240..0000000000
--- a/lib/orber/doc/src/CosNaming_NamingContext.xml
+++ /dev/null
@@ -1,243 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>CosNaming_NamingContext</title>
- <prepared></prepared>
- <docno></docno>
- <checked></checked>
- <date>1997-06-10</date>
- <rev>A</rev>
- </header>
- <module>CosNaming_NamingContext</module>
- <modulesummary>This interface supports different bind and access functions for names in a context.</modulesummary>
- <description>
- <p>This is the object that defines name scopes, names must be unique within a
- naming context. Objects may have multiple names and may exist in multiple
- naming contexts. Name context may be named in other contexts and cycles are
- permitted.</p>
- <p>The type <c>NameComponent</c> used below is defined as:</p>
- <code type="erl">-record('CosNaming_NameComponent', {id, kind=""}).</code>
- <p>where <c>id</c> and <c>kind</c> are strings. </p>
- <p>The type <c>Binding</c> used below is defined as:</p>
- <code type="erl">-record('CosNaming_Binding', {binding_name, binding_type}).</code>
- <p>where <c>binding_name</c> is a Name and <c>binding_type</c> is an enum which
- has the values <c>nobject</c> and <c>ncontext</c>.</p>
- <p>Both these records are defined in the file <c>CosNaming.hrl</c> and it
- is included with:</p>
- <code type="erl">-include_lib("orber/COSS/CosNaming/CosNaming.hrl").</code>
- <p>There are a number of exceptions that can be returned from functions in this
- interface.</p>
- <list type="bulleted">
- <item>
- <p>NotFound is defined as </p>
- <code type="erl">
--record('CosNaming_NamingContext_NotFound',
- {rest_of_name, why}).</code>
- </item>
- <item>
- <p>CannotProceed is defined as </p>
- <code type="erl">
--record('CosNaming_NamingContext_CannotProceed',
- {rest_of_name, cxt}).
- </code>
- </item>
- <item>
- <p>InvalidName is defined as </p>
- <code type="erl">
--record('CosNaming_NamingContext_InvalidName', {}).
- </code>
- </item>
- <item>
- <p>NotFound is defined as </p>
- <code type="erl">-record('CosNaming_NamingContext_NotFound', {}).</code>
- </item>
- <item>
- <p>AlreadyBound is defined as </p>
- <code type="erl">-record('CosNaming_NamingContext_AlreadyBound', {}).</code>
- </item>
- <item>
- <p>NotEmpty is defined as </p>
- <code type="erl">-record('CosNaming_NamingContext_NotEmpty', {}).</code>
- </item>
- </list>
- <p>These exceptions are defined in the file <c>CosNaming_NamingContext.hrl</c> and it
- is included with:</p>
- <code type="erl">
--include_lib("orber/COSS/CosNaming/CosNaming_NamingContext.hrl").
- </code>
- </description>
- <funcs>
- <func>
- <name>bind(NamingContext, Name, Object) -> Return</name>
- <fsummary>Bind a Name to an Object</fsummary>
- <type>
- <v>NameContext = #objref</v>
- <v>Name = [NameComponent]</v>
- <v>Object = #objref</v>
- <v>Return = ok</v>
- </type>
- <desc>
- <p>Creates a binding of a name and an object in the naming context.
- Naming contexts that are bound using <em>bind()</em> do not participate
- in name resolution.</p>
- </desc>
- </func>
- <func>
- <name>rebind(NamingContext, Name, Object) -> Return</name>
- <fsummary>Bind an Object to the Name even if the Name already is bound</fsummary>
- <type>
- <v>NamingContext = #objref</v>
- <v>Name = [NameComponent]</v>
- <v>Object = #objref</v>
- <v>Return = ok</v>
- </type>
- <desc>
- <p>Creates a binding of a name and an object in the naming context even
- if the name is already bound. Naming contexts that are bound using
- <em>rebind()</em> do not participate in name resolution.</p>
- </desc>
- </func>
- <func>
- <name>bind_context(NamingContext1, Name, NamingContex2) -> Return</name>
- <fsummary>Bind a Name to an NamingContext</fsummary>
- <type>
- <v>NamingContext1 = NamingContext2 =#objref</v>
- <v>Name = [NameComponent]</v>
- <v>Return = ok</v>
- </type>
- <desc>
- <p>The bind_context function creates a binding of a name and a naming context in
- the current context.
- Naming contexts that are bound using <em>bind_context()</em> participate
- in name resolution.</p>
- </desc>
- </func>
- <func>
- <name>rebind_context(NamingContext1, Name, NamingContex2) -> Return</name>
- <fsummary>Bind an NamingContext to the Name even if the Name already is bound</fsummary>
- <type>
- <v>NamingContext1 = NamingContext2 =#objref</v>
- <v>Name = [NameComponent]</v>
- <v>Return = ok</v>
- </type>
- <desc>
- <p>The rebind_context function creates a binding of a name and a naming context in
- the current context even if the name already is bound.
- Naming contexts that are bound using <em>rebind_context()</em> participate
- in name resolution.</p>
- </desc>
- </func>
- <func>
- <name>resolve(NamingContext, Name) -> Return</name>
- <fsummary>Retrieve an Object bound to Name</fsummary>
- <type>
- <v>NamingContext = #objref</v>
- <v>Name = [NameComponent]</v>
- <v>Return = Object</v>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>The resolve function is the way to retrieve an object bound to a name in
- the naming context. The given name must match exactly the bound name. The
- type of the object is not returned, clients are responsible for narrowing
- the object to the correct type.</p>
- </desc>
- </func>
- <func>
- <name>unbind(NamingContext, Name) -> Return</name>
- <fsummary>Remove the binding for a Name</fsummary>
- <type>
- <v>NamingContext = #objref</v>
- <v>Name = [NameComponent]</v>
- <v>Return = ok</v>
- </type>
- <desc>
- <p>The unbind operation removes a name binding from the naming context.</p>
- </desc>
- </func>
- <func>
- <name>new_context(NamingContext) -> Return</name>
- <fsummary>Create a new NamingContext</fsummary>
- <type>
- <v>NamingContext = #objref</v>
- <v>Return = #objref</v>
- </type>
- <desc>
- <p>The new_context operation creates a new naming context.</p>
- </desc>
- </func>
- <func>
- <name>bind_new_context(NamingContext, Name) -> Return</name>
- <fsummary>Create a new NamingContext and bind it to a Name</fsummary>
- <type>
- <v>NamingContext = #objref</v>
- <v>Name = [NameComponent]</v>
- <v>Return = #objref</v>
- </type>
- <desc>
- <p>The new_context operation creates a new naming context and binds it to
- Name in the current context.</p>
- </desc>
- </func>
- <func>
- <name>destroy(NamingContext) -> Return</name>
- <fsummary>Destroy a NamingContext</fsummary>
- <type>
- <v>NamingContext = #objref</v>
- <v>Return = ok</v>
- </type>
- <desc>
- <p>The destroy operation disposes the NamingContext object and removes it from the
- name server. The context must be empty e.g. not contain any bindings to be
- removed.</p>
- </desc>
- </func>
- <func>
- <name>list(NamingContext, HowMany) -> Return</name>
- <fsummary>List returns a all bindings in the context</fsummary>
- <type>
- <v>NamingContext = #objref</v>
- <v>HowMany = int()</v>
- <v>Return = {ok, BindingList, BindingIterator}</v>
- <v>BindingList = [Binding]</v>
- <v>BindingIterator = #objref</v>
- </type>
- <desc>
- <p>The list operation returns a BindingList with a number of bindings up-to
- HowMany from the context. It also returns a BindinIterator which can be used to
- step through the list. If the total number of existing bindings are less
- than, or equal to, the <c>HowMany</c> parameter a NIL object reference
- is returned.</p>
- <p></p>
- <note>
- <p>One must destroy the BindingIterator, unless it is a NIL object
- reference, by using 'BindingIterator':destroy(). Otherwise one can get
- dangling objects.</p>
- </note>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/CosNaming_NamingContextExt.xml b/lib/orber/doc/src/CosNaming_NamingContextExt.xml
deleted file mode 100644
index 2af3deadda..0000000000
--- a/lib/orber/doc/src/CosNaming_NamingContextExt.xml
+++ /dev/null
@@ -1,102 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>2000</year><year>2017</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>CosNaming_NamingContextExt</title>
- <prepared></prepared>
- <docno></docno>
- <checked></checked>
- <date>2000-08-16</date>
- <rev>A</rev>
- </header>
- <module>CosNaming_NamingContextExt</module>
- <modulesummary>This interface contains operation for converting a Name sequence to a string and back.</modulesummary>
- <description>
- <p>To get access to the record definitions for the structures use: <br></br>
-</p>
- <code type="erl">
--include_lib("orber/COSS/CosNaming/CosNaming.hrl").
- </code>
- <p>This module also exports the functions described in:</p>
- <list type="bulleted">
- <item>
- <p><seealso marker="CosNaming_NamingContext">CosNaming_NamingContext</seealso></p>
- </item>
- </list>
- </description>
- <funcs>
- <func>
- <name>to_string(NamingContext, Name) -> Return</name>
- <fsummary>Stringify a <c>Name</c>sequence to a string</fsummary>
- <type>
- <v>NameContext = #objref</v>
- <v>Name = [NameComponent]</v>
- <v>Return = string() | {'EXCEPTION', NamingContext::InvalidName{}}</v>
- </type>
- <desc>
- <p>Stringifies a <c>Name</c> sequence to a string.</p>
- </desc>
- </func>
- <func>
- <name>to_name(NamingContext, NameString) -> Return</name>
- <fsummary>Convert a stringified <c>Name</c>to a <c>Name</c>sequence</fsummary>
- <type>
- <v>NameContext = #objref</v>
- <v>NameString = string()</v>
- <v>Return = [NameComponent] | {'EXCEPTION', NamingContext::InvalidName{}}</v>
- </type>
- <desc>
- <p>Converts a stringified <c>Name</c> to a <c>Name</c> sequence.</p>
- </desc>
- </func>
- <func>
- <name>to_url(NamingContext, AddressString, NameString) -> Return</name>
- <fsummary>Return an URL string constructed from the given Address and Name strings</fsummary>
- <type>
- <v>NameContext = #objref</v>
- <v>Address = NameString = string()</v>
- <v>Return = URLString | {'EXCEPTION', NamingContext::InvalidName{}} | {'EXCEPTION', NamingContextExt::InvalidAddress{}}</v>
- </type>
- <desc>
- <p>This operation takes a <c>corbaloc</c> string and a stringified <c>Name</c>
- sequence as input and returns a fully formed URL string.</p>
- </desc>
- </func>
- <func>
- <name>resolve_str(NamingContext, NameString) -> Return</name>
- <fsummary>Return the object associated, if any, with the given name string</fsummary>
- <type>
- <v>NameContext = #objref</v>
- <v>NameString = string()</v>
- <v>Return = #objref | {'EXCEPTION', NamingContext::InvalidName{}} | {'EXCEPTION', NamingContext::NotFound{why, rest_of_name}} | {'EXCEPTION', NamingContext::CannotProceed{cxt, rest_of_name}}</v>
- </type>
- <desc>
- <p>This operation takes a stringified <c>Name</c> sequence as input and
- returns the associated, if any, object.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/Makefile b/lib/orber/doc/src/Makefile
deleted file mode 100644
index c77345f12b..0000000000
--- a/lib/orber/doc/src/Makefile
+++ /dev/null
@@ -1,172 +0,0 @@
-#
-# %CopyrightBegin%
-#
-# Copyright Ericsson AB 1997-2017. All Rights Reserved.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-#
-# %CopyrightEnd%
-#
-#
-include $(ERL_TOP)/make/target.mk
-include $(ERL_TOP)/make/$(TARGET)/otp.mk
-
-# ----------------------------------------------------
-# Application version
-# ----------------------------------------------------
-include ../../vsn.mk
-VSN=$(ORBER_VSN)
-APPLICATION=orber
-
-# ----------------------------------------------------
-# Release directory specification
-# ----------------------------------------------------
-RELSYSDIR = $(RELEASE_PATH)/lib/$(APPLICATION)-$(VSN)
-
-# ----------------------------------------------------
-# Target Specs
-# ----------------------------------------------------
-XML_APPLICATION_FILES = ref_man.xml
-XML_REF3_FILES = \
- any.xml \
- corba.xml \
- corba_object.xml \
- orber.xml \
- CosNaming.xml \
- CosNaming_NamingContext.xml \
- CosNaming_NamingContextExt.xml \
- CosNaming_BindingIterator.xml \
- lname.xml \
- lname_component.xml \
- orber_ifr.xml \
- orber_tc.xml \
- Module_Interface.xml \
- interceptors.xml \
- fixed.xml \
- orber_diagnostics.xml \
- orber_acl.xml
-
-XML_PART_FILES = \
- part.xml
-
-XML_CHAPTER_FILES = \
- ch_contents.xml \
- ch_introduction.xml \
- ch_orber_kernel.xml \
- ch_ifr.xml \
- ch_install.xml \
- ch_idl_to_erlang_mapping.xml \
- ch_naming_service.xml \
- ch_stubs.xml \
- ch_security.xml \
- notes.xml \
- ch_exceptions.xml \
- ch_interceptors.xml \
- ch_orberweb.xml \
- ch_debugging.xml
-
-BOOK_FILES = book.xml
-
-XML_FILES = $(BOOK_FILES) $(XML_APPLICATION_FILES) $(XML_REF3_FILES) \
- $(XML_PART_FILES) $(XML_CHAPTER_FILES)
-
-TECHNICAL_DESCR_FILES =
-
-GIF_FILES = \
- name.gif \
- orbs.gif \
- theORB.gif \
- iiop.gif \
- dependent.gif \
- interceptor_operations.gif \
- menuframe.gif \
- dataframe1.gif \
- dataframe2.gif \
- dataframe3.gif \
- dataframe4.gif \
- dataframe5.gif \
- dataframe6.gif \
- dataframe7.gif \
- dataframe8.gif \
- firewall_nat.gif
-
-# ----------------------------------------------------
-
-INTERNAL_HTML_FILES = $(TECHNICAL_DESCR_FILES:%.xml=$(HTMLDIR)/%.html)
-
-HTML_FILES = $(XML_APPLICATION_FILES:%.xml=$(HTMLDIR)/%.html) \
- $(XML_CHAPTER_FILES:%.xml=$(HTMLDIR)/%.html) \
- $(XML_PART_FILES:%.xml=$(HTMLDIR)/%.html)
-
-INFO_FILE = ../../info
-EXTRA_FILES = \
- $(DEFAULT_GIF_FILES) \
- $(DEFAULT_HTML_FILES) \
- $(XML_REF3_FILES:%.xml=$(HTMLDIR)/%.html)
-
-MAN3_FILES = $(XML_REF3_FILES:%.xml=$(MAN3DIR)/%.3)
-
-HTML_REF_MAN_FILE = $(HTMLDIR)/index.html
-
-TOP_PDF_FILE = $(PDFDIR)/$(APPLICATION)-$(VSN).pdf
-
-# ----------------------------------------------------
-# FLAGS
-# ----------------------------------------------------
-XML_FLAGS +=
-DVIPS_FLAGS +=
-
-# ----------------------------------------------------
-# Targets
-# ----------------------------------------------------
-$(HTMLDIR)/%.gif: %.gif
- $(INSTALL_DATA) $< $@
-
-
-docs: pdf html man
-
-$(TOP_PDF_FILE): $(XML_FILES)
-
-pdf: $(TOP_PDF_FILE)
-
-html: gifs $(HTML_REF_MAN_FILE)
-
-clean clean_docs:
- rm -rf $(HTMLDIR)/*
- rm -f $(MAN3DIR)/*
- rm -f $(TOP_PDF_FILE) $(TOP_PDF_FILE:%.pdf=%.fo)
- rm -f errs core *~
- rm -f $(JD_HTML) $(JD_PACK)
-
-man: $(MAN3_FILES)
-
-gifs: $(GIF_FILES:%=$(HTMLDIR)/%)
-
-debug opt:
-
-# ----------------------------------------------------
-# Release Target
-# ----------------------------------------------------
-include $(ERL_TOP)/make/otp_release_targets.mk
-
-release_docs_spec: docs
- $(INSTALL_DIR) "$(RELSYSDIR)/doc/pdf"
- $(INSTALL_DATA) $(TOP_PDF_FILE) "$(RELSYSDIR)/doc/pdf"
- $(INSTALL_DIR) "$(RELSYSDIR)/doc/html"
- $(INSTALL_DATA) $(HTMLDIR)/* \
- "$(RELSYSDIR)/doc/html"
- $(INSTALL_DATA) $(INFO_FILE) "$(RELSYSDIR)"
- $(INSTALL_DIR) "$(RELEASE_PATH)/man/man3"
- $(INSTALL_DATA) $(MAN3DIR)/* "$(RELEASE_PATH)/man/man3"
-
-release_spec:
diff --git a/lib/orber/doc/src/Module_Interface.xml b/lib/orber/doc/src/Module_Interface.xml
deleted file mode 100644
index a809bcf02f..0000000000
--- a/lib/orber/doc/src/Module_Interface.xml
+++ /dev/null
@@ -1,356 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1999</year>
- <year>2016</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>Module_Interface</title>
- <prepared></prepared>
- <docno></docno>
- <checked></checked>
- <date>1999-09-03</date>
- <rev>A</rev>
- </header>
- <module>Module_Interface</module>
- <modulesummary>Orber generated stubs/skeletons.</modulesummary>
- <description>
- <p>This module contains the stub/skeleton functions generated by IC.</p>
- <p>Starting a Orber server can be done in three ways:</p>
- <list type="bulleted">
- <item>Normal - when the server dies Orber forgets all knowledge of the server.</item>
- <item>Supervisor child - adding the configuration parameter <c>{sup_child, true}</c>
- the <c>oe_create_link/2</c> function returns <c>{ok, Pid, ObjRef}</c> which
- can be handled by the application <em>supervisor/stdlib-1.7</em> or later. </item>
- <item>Persistent object reference - adding the configuration parameters <c>{persistent, true}</c>
- and <c>{regname, {global, term()}}</c> Orber will remember the object reference until the
- server terminates with reason <em>normal</em> or <em>shutdown</em>. Hence,
- if the server is started as a <em>transient</em> supervisor child we do not
- receive a 'OBJECT_NOT_EXIST' exception when it has crashed and is being restarted.</item>
- </list>
- <p>The Orber stub can be used to start a <c>pseudo object</c>, which will create a non-server implementation.
- A pseudo object introduce some limitations:</p>
- <list type="bulleted">
- <item>The functions <c>oe_create_link/2</c> is equal to <c>oe_create/2</c>, i.e.,
- no link can or will be created.</item>
- <item>The <c>BIF:s self()</c> and <c>process_flag(trap_exit,true)</c> behaves incorrectly.</item>
- <item>The <c>IC</c> option <c>{{impl, "M::I"}, "other_impl"}</c> has no effect. The call-back
- functions must be implemented in a file called <c>M_I_impl.erl</c></item>
- <item>The <c>IC</c> option <c>from</c> has no effect. </item>
- <item>The call-back functions must be implemented as if the <c>IC</c> option
- <c>{this, "M::I"}</c> was used.</item>
- <item>Server <c>State</c> changes have no effect. The user can provide information via
- the <c>Env</c> start parameter and the State returned from <c>init/2</c> will be the State
- passed in following invocations.</item>
- <item>If a call-back function replies with the <c>Timeout</c> parameter set it have no effect.</item>
- <item>Operations defined as <c>oneway</c> are blocking until the operation replies.</item>
- <item>The option <c>{pseudo, true}</c> overrides all other start options.</item>
- <item>Only the functions, besides own definitions, <c>init/2</c> (called via oe_create*/2) and
- <c>terminate/2</c> (called via corba:dispose/1) must be implemented.</item>
- </list>
- <p>By adopting the rules for <c>pseudo</c> objects described above we can use <c>oe_create/2</c>
- to create <c>server</c> or <c>pseudo</c> objects, by excluding or including the
- option <c>{pseudo, true}</c>, without changing the call-back module.
- </p>
- <p>If you start a object without <c>{regname, RegName}</c> it can only be accessed through the returned object key.
- Started with a <c>{regname, RegName}</c> the name is registered locally or globally.
- </p>
- <warning>
- <p>To avoid flooding Orber with old object references start erlang using the flag
- <em>-orber objectkeys_gc_time Time</em>, which will remove all object references
- related to servers being dead for Time seconds. To avoid extra overhead, i.e., performing
- garbage collect if no persistent objects are started, the objectkeys_gc_time default value
- is <em>infinity</em>. For more information, see the orber and corba documentation.</p>
- </warning>
- </description>
- <funcs>
- <func>
- <name>Module_Interface:typeID() -> TypeId</name>
- <fsummary>Return the Type ID related to this stub/skeleton</fsummary>
- <type>
- <v>TypeId = string(), e.g., "IDL:Module/Interface:1.0"</v>
- </type>
- <desc>
- <p>Returns the Type ID related to this stub/skeleton</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface:oe_create() -> ObjRef</name>
- <fsummary>Start a Orber server.</fsummary>
- <type>
- <v>ObjRef = #object reference</v>
- </type>
- <desc>
- <p>Start a Orber server.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface:oe_create_link() -> ObjRef</name>
- <fsummary>Start a linked Orber server.</fsummary>
- <type>
- <v>ObjRef = #object reference</v>
- </type>
- <desc>
- <p>Start a linked Orber server.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface:oe_create(Env) -> ObjRef</name>
- <fsummary>Start a Orber server.</fsummary>
- <type>
- <v>Env = term()</v>
- <v>ObjRef = #object reference</v>
- </type>
- <desc>
- <p>Start a Orber server passing Env to <c>init/1</c>.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface:oe_create_link(Env) -> ObjRef</name>
- <fsummary>Start a linked Orber server.</fsummary>
- <type>
- <v>Env = term()</v>
- <v>ObjRef = #object reference</v>
- </type>
- <desc>
- <p>Start a linked Orber server passing Env to <c>init/1</c>.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface:oe_create(Env, Options) -> ObjRef</name>
- <fsummary>Start a Orber stub/skeleton</fsummary>
- <type>
- <v>Env = term()</v>
- <v>ObjRef = #object reference</v>
- <v>Options = [{sup_child, false} | {persistent, Bool} | {regname, RegName} | {pseudo, Bool} | {local_typecheck, Bool} | {survive_exit, Bool} | {create_options, [CreateOpts]}]</v>
- <v>Bool = true | false</v>
- <v>RegName = {global, term()} | {local, atom()}</v>
- <v>CreateOpts = {debug, [Dbg]} | {timeout, Time}</v>
- <v>Dbg = trace | log | statistics | {log_to_file, FileName}</v>
- </type>
- <desc>
- <p>Start a Orber server passing Env to <c>init/1</c>.</p>
- <p>If the option <c>{pseudo, true}</c> is used, all other options are overridden.
- As default, this option is set to false.</p>
- <p>This function cannot be used for starting a server as supervisor child.
- If started as <c>persistent</c>, the options <c>[{persistent, true}, {regname, {global, term()}}]</c> must be used and
- Orber will only forget the object reference if it terminates with reason <em>normal</em> or <em>shutdown</em>.</p>
- <p>The option <c>{local_typecheck, boolean()}</c>, which overrides the
- <seealso marker="ch_install#flags">Local Typechecking</seealso>
- environment flag, turns on or off typechecking. If activated,
- parameters, replies and raised exceptions will be checked to ensure that
- the data is correct, when invoking operations on CORBA Objects within
- the same Orber domain. Due to the extra overhead, this option
- <em>MAY ONLY</em> be used during testing and development.</p>
- <p><c>{survive_exit, boolean()}</c> overrides the
- <seealso marker="ch_install#flags">EXIT Tolerance</seealso>
- environment flag. If activated, the server will not terminate, even though
- the call-back module returns EXIT.</p>
- <p><c>Time</c> specifies how long time, in milliseconds, the server is allowed to
- spend initializing. For more information about the <c>Dbg</c> options,
- see the <c>sys</c> module.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface:oe_create_link(Env, Options) -> Return</name>
- <fsummary>Start a Orber stub/skeleton</fsummary>
- <type>
- <v>Env = term()</v>
- <v>Return = ObjRef | {ok, Pid, ObjRef}</v>
- <v>ObjRef = #object reference</v>
- <v>Options = [{sup_child, Bool} | {persistent, Bool} | {regname, RegName} | {pseudo, Bool} | {local_typecheck, Bool} | {survive_exit, Bool} | {create_options, [CreateOpts]}]</v>
- <v>Bool = true | false</v>
- <v>RegName = {global, term()} | {local, atom()}</v>
- <v>CreateOpts = {debug, [Dbg]} | {timeout, Time}</v>
- <v>Dbg = trace | log | statistics | {log_to_file, FileName}</v>
- <v></v>
- <v></v>
- <v></v>
- </type>
- <desc>
- <p>Start a linked Orber server passing Env to <c>init/1</c>.</p>
- <p>If the option <c>{pseudo, true}</c> is used, all other options are overridden and no link will be created.
- As default, this option is set to false.</p>
- <p>This function can be used for starting a server as persistent or supervisor child. At the moment
- <c>[{persistent, true}, {regname, {global, term()}}]</c> must be used to start
- a server as persistent, i.e., if a server died and is in the process of being restarted
- a call to the server will not raise <c>'OBJECT_NOT_EXIST'</c> exception.
- Orber will only forget the object reference if it terminates with reason <em>normal</em> or <em>shutdown</em>,
- hence, the server must be started as <em>transient</em> (for more information see the
- supervisor documentation).</p>
- <p>The options <c>{local_typecheck, boolean()}</c> and <c>{survive_exit, boolean()}</c>
- behaves in the same way as for <c>oe_create/2</c>.</p>
- <p><c>Time</c> specifies how long time, in milliseconds, the server is allowed to
- spend initializing. For more information about the <c>Dbg</c> options,
- see the <c>sys</c> module.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface:own_functions(ObjRef, Arg1, ..., ArgN) -> Reply</name>
- <name>Module_Interface:own_functions(ObjRef, Options, Arg1, ..., ArgN) -> Reply</name>
- <fsummary>User defined function which is not a part of Orber</fsummary>
- <type>
- <v>ObjRef = #object reference</v>
- <v>Options = [Option] | Timeout</v>
- <v>Option = {timeout, Timeout} | {context, [Context]}</v>
- <v>Timeout = infinity | integer(milliseconds)</v>
- <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
- <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
- <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
- <v>Interface = string()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = ssl_client_verify | ssl_client_depth | ssl_client_certfile | ssl_client_cacertfile |
- ssl_client_password | ssl_client_keyfile | ssl_client_ciphers | ssl_client_cachetimeout</v>
- <v>Value = allowed value associated with the given key</v>
- <v>ArgX = specified in the IDL-code.</v>
- <v>Reply = specified in the IDL-code.</v>
- </type>
- <desc>
- <p>The default value for the <c>Timeout</c> option is <c>infinity</c>.
- IPv4 or IPv6 addresses are accepted as local Interface.</p>
- <p>The <em>configuration</em> context is used to override the global
- SSL client side
- <seealso marker="ch_install#config">configuration</seealso>.</p>
- <p>To gain access to <c>#'IOP_ServiceContext'{}</c> record and the
- <c>?ORBER_GENERIC_CTX_ID</c> macro, you must add
- <c>-include_lib("orber/include/corba.hrl").</c> to your module.</p>
- </desc>
- </func>
- </funcs>
-
- <section>
- <title>CALLBACK FUNCTIONS</title>
- <p>The following functions should be exported from a <c>CORBA</c>
- callback module. Note, a complete template of the call-back module can
- be generated automatically by compiling the IDL-file with the IC option
- <c>{be,erl_template}</c>. One should also add
- the same compile options, for example <c>this</c> or <c>from</c>,
- used when generating the stub/skeleton modules.</p>
- </section>
- <funcs>
- <func>
- <name>Module_Interface_impl:init(Env) -> CallReply</name>
- <fsummary>User defined function which is not a part of Orber</fsummary>
- <type>
- <v>Env = term()</v>
- <v>CallReply = {ok, State} | {ok, State, Timeout} | ignore | {stop, StopReason}</v>
- <v>State = term()</v>
- <v>Timeout = int() >= 0 | infinity</v>
- <v>StopReason = term()</v>
- </type>
- <desc>
- <p>Whenever a new server is started, <em>init/1</em> is the first function called in the specified call-back module.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface_impl:terminate(Reason, State) -> ok</name>
- <fsummary>User defined function which is not a part of Orber</fsummary>
- <type>
- <v>Reason = term()</v>
- <v>State = term()</v>
- </type>
- <desc>
- <p>This call-back function is called whenever the server is about to terminate.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface_impl:code_change(OldVsn, State, Extra) -> CallReply</name>
- <fsummary>User defined function which is not a part of Orber</fsummary>
- <type>
- <v>OldVsn = undefined | term()</v>
- <v>State = term()</v>
- <v>Extra = term()</v>
- <v>CallReply = {ok, NewState}</v>
- <v>NewState = term()</v>
- </type>
- <desc>
- <p>Update the internal <c>State</c>.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface_impl:handle_info(Info, State) -> CallReply</name>
- <fsummary>User defined function which is not a part of Orber</fsummary>
- <type>
- <v>Info = term()</v>
- <v>State = term()</v>
- <v>CallReply = {noreply, State} | {noreply, State, Timeout} | {stop, StopReason, State}</v>
- <v>Timeout = int() >= 0 | infinity</v>
- <v>StopReason = normal | shutdown | term()</v>
- </type>
- <desc>
- <p>If the configuration parameter <em>{{handle_info, "Module::Interface"}, true}</em>
- is passed to IC and <em>process_flag(trap_exit,true)</em> is set in the <em>init()</em>
- call-back this function must be exported. </p>
- <note>
- <p>To be able to handle the <c>Timeout</c> option in <c>CallReply</c> in the call-back
- module the configuration parameter <em>{{handle_info, "Module::Interface"}, true}</em> must
- be passed to IC. </p>
- </note>
- </desc>
- </func>
- <func>
- <name>Module_Interface_impl:own_functions(State, Arg1, ..., ArgN) -> CallReply</name>
- <name>Module_Interface_impl:own_functions(This, State, Arg1, ..., ArgN) -> CallReply</name>
- <name>Module_Interface_impl:own_functions(This, From, State, Arg1, ..., ArgN) -> ExtCallReply</name>
- <name>Module_Interface_impl:own_functions(From, State, Arg1, ..., ArgN) -> ExtCallReply</name>
- <fsummary>User defined function which is not a part of Orber</fsummary>
- <type>
- <v>This = the servers #object reference</v>
- <v>State = term()</v>
- <v>ArgX = specified in the IDL-code.</v>
- <v>CallReply = {reply, Reply, State} | {reply, Reply, State, Timeout} | {stop, StopReason, Reply, State} | {stop, StopReason, State} | corba:raise(Exception)</v>
- <v>ExtCallReply = CallReply | corba:reply(From, Reply), {noreply, State} | corba:reply(From, Reply), {noreply, State, Timeout}</v>
- <v>Reply = specified in the IDL-code.</v>
- <v>Timeout = int() >= 0 | infinity</v>
- <v>StopReason = normal | shutdown | term()</v>
- </type>
- <desc>
- <p>All two-way functions must return one of the listed replies or raise any of
- the exceptions listed in the IDL code (i.e. raises(...)).
- If the IC compile options <em>this</em> and/or <em>from</em> are used,
- the implementation must accept the <em>This</em> and/or <em>From</em>
- parameters.</p>
- </desc>
- </func>
- <func>
- <name>Module_Interface_impl:own_functions(State, Arg1, ..., ArgN) -> CastReply</name>
- <name>Module_Interface_impl:own_functions(This, State, Arg1, ..., ArgN) -> CastReply</name>
- <fsummary>User defined function which is not a part of Orber</fsummary>
- <type>
- <v>This = the servers #object reference</v>
- <v>State = term()</v>
- <v>CastReply = {noreply, State} | {noreply, State, Timeout} | {stop, StopReason, State}</v>
- <v>ArgX = specified in the IDL-code.</v>
- <v>Reply = specified in the IDL-code.</v>
- <v>Timeout = int() >= 0 | infinity</v>
- <v>StopReason = normal | shutdown | term()</v>
- </type>
- <desc>
- <p>All one-way functions must return one of the listed replies.
- If the IC compile option <em>this</em> is used,
- the implementation must accept the <em>This</em> parameter.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/Orber/InitialReference.java b/lib/orber/doc/src/Orber/InitialReference.java
deleted file mode 100644
index 35a8c2437b..0000000000
--- a/lib/orber/doc/src/Orber/InitialReference.java
+++ /dev/null
@@ -1,131 +0,0 @@
-/*
- * %CopyrightBegin%
- *
- * Copyright Ericsson AB 1997-2016. All Rights Reserved.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- *
- * %CopyrightEnd%
- *
- */
-/**
- * InitialReference is a class which generates the INIT reference
- * which can be used by the InitialReferences interface.
- */
-package Orber;
-
-public class InitialReference
-{
-
- /**
- * Constructor.
- */
- public InitialReference(){;}
-
- /**
- * Returns the stringified objectreference to the initial reference server
- */
- public String stringified_ior(String host, int port)
- {
- String iorByteString;
- String profileData;
- String iorString;
-
- // byte_order followed by ' {"", [{0, '
- // char iorBytesFirstPart[] = {0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0};
- char iorBytesFirstPart[] = {0,0,0,0,0,0,0,32,73,68,76,58,79,114,98,101,114,47,73,110,105,116,105,97,108,82,101,102,101,114,101,110,99,101,115,58,49,46,48,0,0,0,0,1,0,0,0,0};
- // the objectkey "INIT
- char iorBytesLastPart[] = {0,0,0,4,73,78,73,84};
-
- // Fix the ProfileData struct.
- char pdPrefix[] = {0,1,0,0};
- char nullbyte[] = {0};
- profileData = new String(pdPrefix) + enc_ulong(host.length() + 1) + host + new String(nullbyte);
- profileData = align(profileData, 2);
- profileData += enc_ushort(port);
- profileData = align(profileData, 4);
- profileData += new String(iorBytesLastPart);
- // Fix the whole IOR
- iorByteString = new String(iorBytesFirstPart) + enc_ulong(profileData.length()) +
- profileData;
-
- // System.out.print("Start[" + profileData.length() + "]");
- // System.out.print("[");
- // for(int x = 0; x < iorByteString.length(); x++)
- // {
- // System.out.print((int) iorByteString.charAt(x) + ",");
- // }
- // System.out.println("]");
-
- iorString = createIOR(iorByteString);
- // System.out.println(iorString);
- return iorString;
- }
-
-
- private String enc_ushort(int s)
- {
- char byteArray[] = {(char) ((s >>> 8) & 0xFF),
- (char) ((s >>> 0) & 0xFF)};
-
- return new String(byteArray);
- }
-
- private String enc_ulong(int l)
- {
- char byteArray[] = {(char) ((l >>> 24) & 0xFF),
- (char) ((l >>> 16) & 0xFF),
- (char) ((l >>> 8) & 0xFF),
- (char) ((l >>> 0) & 0xFF)};
-
- return new String(byteArray);
-
- }
-
- private String createIOR(String bytes)
- {
- int i;
- StringBuffer sb = new StringBuffer("IOR:");
-
- for(i = 0; i < bytes.length(); i++)
- {
- int b = bytes.charAt(i);
- if(b<0) b+= 256;
- int n1 = b / 16;
- int n2 = b % 16;
- int c1 = (n1 < 10) ? ('0' + n1) : ('a' + (n1 - 10));
- int c2 = (n2 < 10) ? ('0' + n2) : ('a' + (n2 - 10));
- sb.append((char)c1);
- sb.append((char)c2);
- }
-
- return sb.toString();
- }
-
- private String align(String buffer, int alignment)
- {
- String s = buffer;
- char nullbyte[] = {0};
-
- int remainder = alignment - (buffer.length() % alignment);
- if (remainder == alignment) return s;
-
- for (int i = 0; i < remainder; i++)
- {
- s += new String(nullbyte);
- }
- return s;
- }
-
-
-}
diff --git a/lib/orber/doc/src/Orber/Makefile b/lib/orber/doc/src/Orber/Makefile
deleted file mode 100644
index 16a3994499..0000000000
--- a/lib/orber/doc/src/Orber/Makefile
+++ /dev/null
@@ -1,71 +0,0 @@
-#
-# %CopyrightBegin%
-#
-# Copyright Ericsson AB 1997-2016. All Rights Reserved.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-#
-# %CopyrightEnd%
-#
-#
-include $(ERL_TOP)/make/target.mk
-
-include $(ERL_TOP)/make/$(TARGET)/otp.mk
-
-# ----------------------------------------------------
-# Application version
-# ----------------------------------------------------
-include ../../vsn.mk
-VSN=$(ORBER_VSN)
-
-# ----------------------------------------------------
-# Release directory specification
-# ----------------------------------------------------
-RELSYSDIR = $(RELEASE_PATH)/lib/orber-$(VSN)
-
-#
-# JAVA macros
-#
-JAVA_CLASSES = \
- InitialReference
-
-JAVA_FILES= $(JAVA_CLASSES:%=%.java)
-
-CLASSPATH = ../..
-
-# ----------------------------------------------------
-# Flags
-# ----------------------------------------------------
-JAVA_OPTIONS =
-
-# ----------------------------------------------------
-# Make Rules
-# ----------------------------------------------------
-
-debug opt:
-
-clean:
-
-docs:
-
-# ----------------------------------------------------
-# Release Targets
-# ----------------------------------------------------
-include $(ERL_TOP)/make/otp_release_targets.mk
-
-release_spec: opt
- $(INSTALL_DIR) $(RELSYSDIR)/java_src/Orber
- $(INSTALL_DATA) $(JAVA_FILES) $(RELSYSDIR)/java_src/Orber
-
-release_docs_spec:
-
diff --git a/lib/orber/doc/src/any.xml b/lib/orber/doc/src/any.xml
deleted file mode 100644
index c94a2132d8..0000000000
--- a/lib/orber/doc/src/any.xml
+++ /dev/null
@@ -1,114 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1998</year><year>2017</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>any</title>
- <prepared></prepared>
- <docno></docno>
- <checked></checked>
- <date>1998-04-20</date>
- <rev>A</rev>
- </header>
- <module>any</module>
- <modulesummary>the corba any type</modulesummary>
- <description>
- <p>This module contains functions that gives an interface to the CORBA any type.</p>
- <p>Note that the <c>any</c> interface in orber does not contain a destroy
- function because the any type is represented as an Erlang record and
- therefor will be removed by the garbage collector when not in use.</p>
- <p>The type <c>TC</c> used below describes an IDL type and is a tuple according
- to the to the Erlang language mapping.</p>
- <p>The type <c>Any</c> used below is defined as:</p>
- <code type="erl">-record(any, {typecode, value}).</code>
- <p>where <c>typecode</c> is a TC tuple and <c>value</c> is an Erlang term of
- the type defined by the typecode field.</p>
- </description>
- <funcs>
- <func>
- <name>create() -> Result</name>
- <name>create(Typecode, Value) -> Result</name>
- <fsummary>Create an any record</fsummary>
- <type>
- <v>Typecode = TC</v>
- <v>Value = term()</v>
- <v>Result = Any</v>
- </type>
- <desc>
- <p>The create/0 function creates an empty any record and the create/2
- function creates an initialized record.</p>
- </desc>
- </func>
- <func>
- <name>set_typecode(A, Typecode) -> Result</name>
- <fsummary>Set the typecode field</fsummary>
- <type>
- <v>A = Any</v>
- <v>Typecode = TC</v>
- <v>Result = Any</v>
- </type>
- <desc>
- <p>This function sets the typecode of <em>A</em> and returns a
- new any record.</p>
- </desc>
- </func>
- <func>
- <name>get_typecode(A) -> Result</name>
- <fsummary>Fetch the typecode</fsummary>
- <type>
- <v>A = Any</v>
- <v>Result = TC</v>
- </type>
- <desc>
- <p>This function returns the typecode of <em>A</em>.</p>
- </desc>
- </func>
- <func>
- <name>set_value(A, Value) -> Result</name>
- <fsummary>Set the value field</fsummary>
- <type>
- <v>A = Any</v>
- <v>Value = term()</v>
- <v>Result = Any</v>
- </type>
- <desc>
- <p>This function sets the value of <em>A</em> and returns a
- new any record.</p>
- </desc>
- </func>
- <func>
- <name>get_value(A) -> Result</name>
- <fsummary>Fetch the value</fsummary>
- <type>
- <v>A = Any</v>
- <v>Result = term()</v>
- </type>
- <desc>
- <p>This function returns the value of <em>A</em>.
- </p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/book.xml b/lib/orber/doc/src/book.xml
deleted file mode 100644
index 81bd5a8f65..0000000000
--- a/lib/orber/doc/src/book.xml
+++ /dev/null
@@ -1,49 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE book SYSTEM "book.dtd">
-
-<book xmlns:xi="http://www.w3.org/2001/XInclude">
- <header titlestyle="normal">
- <copyright>
- <year>1997</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>orber</title>
- <prepared></prepared>
- <docno></docno>
- <date>1998-04-25</date>
- <rev>2.0</rev>
- </header>
- <insidecover>
- </insidecover>
- <pagetext>Orber</pagetext>
- <preamble>
- <contents level="2"></contents>
- </preamble>
- <parts lift="no">
- <xi:include href="part.xml"/>
- </parts>
- <applications>
- <xi:include href="ref_man.xml"/>
- </applications>
- <releasenotes>
- <xi:include href="notes.xml"/>
- </releasenotes>
- <listofterms></listofterms>
- <index></index>
-</book>
-
diff --git a/lib/orber/doc/src/ch_contents.xml b/lib/orber/doc/src/ch_contents.xml
deleted file mode 100644
index b783e63aee..0000000000
--- a/lib/orber/doc/src/ch_contents.xml
+++ /dev/null
@@ -1,173 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1999</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>The Orber Application</title>
- <prepared></prepared>
- <docno></docno>
- <date>1998-05-05</date>
- <rev>B</rev>
- <file>ch_contents.xml</file>
- </header>
-
- <section>
- <title>Content Overview</title>
- <p>The Orber documentation is divided into three sections:
- </p>
- <list type="bulleted">
- <item>
- <p>PART ONE - The User's Guide
- <br></br>
-Description of the Orber Application including IDL-to-Erlang
- language mapping, services and a small tutorial demonstrating
- the development of a simple service.</p>
- </item>
- <item>
- <p>PART TWO - Release Notes
- <br></br>
-A concise history of Orber.</p>
- </item>
- <item>
- <p>PART THREE - The Reference Manual
- <br></br>
- A quick reference guide, including a
- brief description, to all the functions available in Orber.</p>
- </item>
- </list>
- </section>
-
- <section>
- <title>Brief Description of the User's Guide</title>
- <p>The User's Guide contains the following parts:</p>
- <list type="bulleted">
- <item>
- <p>ORB kernel and IIOP support</p>
- </item>
- <item>
- <p>Interface Repository</p>
- </item>
- <item>
- <p>IDL to Erlang mapping</p>
- </item>
- <item>
- <p>CosNaming Service</p>
- </item>
- <item>
- <p>Resolving initial reference from Java or C++</p>
- </item>
- <item>
- <p>Tutorial - creating a simple service </p>
- </item>
- <item>
- <p>CORBA Exceptions </p>
- </item>
- <item>
- <p>Interceptors</p>
- </item>
- <item>
- <p>OrberWeb</p>
- </item>
- <item>
- <p>Debugging
- </p>
- </item>
- </list>
-
- <section>
- <title>ORB Kernel and IIOP Support</title>
- <p>The ORB kernel which has IIOP support will allow the creation
- of persistent server objects in Erlang. These objects can also
- be accessed via Erlang and Java environments. For the moment a
- Java enabled ORB is needed to generate Java from IDL to use
- Java server objects (this has been tested using OrbixWeb).</p>
- </section>
-
- <section>
- <title>Interface Repository</title>
- <p>The IFR is an interface repository used for some type-checking
- when coding/decoding IIOP. The IFR is capable of storing all
- interfaces and declarations of OMG IDL.</p>
- </section>
-
- <section>
- <title>IDL to Erlang Mapping</title>
- <p>The OMG IDL mapping for Erlang, which is necessary to access the
- functionality of Orber, is described, The mapping structure is
- included as the basic and the constructed OMG IDL types
- references, invocations and Erlang characteristics. An example is
- also provided.</p>
- </section>
-
- <section>
- <title>CosNaming Service</title>
- <p>Orber contains a CosNaming compliant service.</p>
- </section>
-
- <section>
- <title>Resolving Initial References from Java or C++</title>
- <p>A couple of classes are added to Orber to simplify initial
- reference access from Java or C++.
- </p>
- <p><em>Resolving initial reference from Java</em> <br></br>
- A class with only one method which returns an <term id="IOR"><termdef>Interoperable Object Reference</termdef></term>on the
- external string format to the INIT object (see "Interoperable
- Naming Service" specification).</p>
- <p><em>Resolving initial reference from C++</em> <br></br>
-
- A class (and header file) with only one method which returns
- an IOR on the external string format to the INIT object (see
- "Interoperable Naming Service" specification).</p>
- </section>
-
- <section>
- <title>Orber Stub/Skeleton</title>
- <p>An example which describes the API and behavior of Orber stubs and skeletons. </p>
- </section>
-
- <section>
- <title>CORBA Exceptions</title>
- <p>A listing of all system exceptions supported by Orber and how one should
- handle them. This chapter also describe how to generate user defined
- exceptions.</p>
- </section>
-
- <section>
- <title>Interceptors</title>
- <p>Descibes how to implement and activate interceptors.</p>
- </section>
-
- <section>
- <title>OrberWeb</title>
- <p>Offers the possibility to administrate and supervise Orber via a GUI.</p>
- </section>
-
- <section>
- <title>Debugging</title>
- <p>Describes how to use different tools when debugging and/or developing
- new applications using Orber. Also includes a FAQ, which deal with
- the most common mistakes when using Orber.
- </p>
- </section>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_debugging.xml b/lib/orber/doc/src/ch_debugging.xml
deleted file mode 100644
index debac4313e..0000000000
--- a/lib/orber/doc/src/ch_debugging.xml
+++ /dev/null
@@ -1,210 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>2001</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Debugging</title>
- <prepared></prepared>
- <docno></docno>
- <date>2001-11-29</date>
- <rev></rev>
- <file>ch_debugging.xml</file>
- </header>
-
- <section>
- <title>Tools and FAQ</title>
- <p>Persons who use Orber for the first time may find it hard to tell what goes
- wrong when trying to setup communication between an Orber-ORB and ORB:s supplied
- by another vendor or another Orber-ORB. The purpose of this chapter is to inform
- about the most common mistakes and what tools one can use to overcome these
- problems. </p>
-
- <section>
- <title>Tools</title>
- <p>To begin with, Orber can be configured to run in debug mode. There are four ways
- to set this parameter:</p>
- <list type="bulleted">
- <item><em>erl -orber orber_debug_level 10</em> - can be added to a start-script.</item>
- <item><em>corba:orb_init([{orber_debug_level, 10}])</em> - this operation must
- be invoked <em>before</em> starting Orber.</item>
- <item><em>orber:configure(orber_debug_level, 10)</em> - this operation can
- be invoked at any time.</item>
- <item><em>OrberWeb</em> - via the <c>Configuration</c> menu one can easily change
- the configuration. For more information, see the OrberWeb chapter in this
- User's Guide.</item>
- </list>
- <p>When Orber runs i debug mode, printouts will be generated if anything abnormal occurs
- (not necessarily an error). An error message typically looks like:</p>
- <code type="none">
-=ERROR REPORT==== 29-Nov-2001::14:09:55 ===
-=================== Orber =================
-[410] corba:common_create(orber_test_server, [{pseudo,truce}]);
-not a boolean(truce).
-===========================================
- </code>
- <p>In the example above, we tried to create an object with an incorrect option (i.e. should
- have been <c>{pseudo,true}</c>).</p>
- <p>If you are not able to solve the problem, you should include all generated reports when
- contacting support or using the erlang-questions mailing list.</p>
- <p>It is easy to forget to, for example, set all fields in a struct, which
- one may not discover when developing an application using Orber. When using
- a typed language, such faults would cause a compile time error. To avoid
- these mistakes, Orber allows the user to activate automatic typechecking
- of all local invocations of CORBA Objects. For this feature to be really
- useful, the user must create test suites which cover as much as
- possible. For example, invoking an operation with invalid or incorrect
- arguments should also be tested. This option can be activated for one object
- or all object via:</p>
- <list type="bulleted">
- <item><em>'MyModuyle_MyInterface':oe_create(Env, [{local_typecheck, true}])</em> -
- This approach will only activate, or deactivate, typechecking for
- the returned instance. Naturally, this option can also be passed
- to <c>oe_create_link/2</c>, <c>corba:create/4</c> and
- <c>corba:create_link/4</c>.</item>
- <item><em>erl -orber flags 2</em> - can be added to a start-script.
- All object invocations will be typechecked, unless overridden by the
- previous option.</item>
- <item><em>corba:orb_init([{flags, 16#0002}])</em> - this operation must
- be invoked <em>before</em> starting Orber. Behaves as the previous
- option.</item>
- </list>
- <p>If incorrect data is passed or returned, Orber uses the <c>error_logger</c>
- to generate logs, which can look like:</p>
- <code type="none">
-=ERROR REPORT==== 10-Jul-2002::12:36:09 ===
-========= Orber Typecheck Request =========
-Invoked......: MyModule_MyInterface:foo/1
-Typecode.....: [{tk_enum,"IDL:MyModule/enumerant:1.0",
- "enumerant",
- ["one","two"]}]
-Arguments....: [three]
-Result.......: {'EXCEPTION',{'MARSHAL',[],102,'COMPLETED_NO'}}
-===========================================
- </code>
- <p>Note, that the arity is equivalent to the IDL-file. In the example above,
- an undefined enumerant was used. In most cases, it is useful to set the
- configuration parameter <c>orber_debug_level 10</c> as well. Due to the
- extra overhead, this option <em>MAY ONLY</em> be used during testing and
- development.
- For more information, see also
- <seealso marker="ch_install#config">configuration settings</seealso>.</p>
- <p>It is also possible to trace all communication between an Orber-ORB and, for example,
- a Java-ORB, communicating via IIOP. All you need to do is to activate an
- <seealso marker="ch_interceptors">interceptor</seealso>. Normally, the users must
- implement the interceptor themselves, but for your convenience Orber includes three
- pre-compiled interceptors called <c>orber_iiop_tracer</c>,
- <c>orber_iiop_tracer_silent</c> and <c>orber_iiop_tracer_stealth</c>.</p>
- <warning>
- <p>Logging all traffic is <em>expensive</em>. Hence, only use the supplied
- interceptors during test and development.</p>
- </warning>
- <p>The <c>orber_iiop_tracer</c> and <c>orber_iiop_tracer_silent</c> interceptors
- uses the <c>error_logger</c> module to generate the logs. If the traffic
- is intense you probably want to write the reports to a log-file.
- This is done by, for example, invoking:</p>
- <code type="erl">
-erl> error_logger:tty(false).
-erl> error_logger:logfile({open, "/tmp/IIOPTrace"}).
- </code>
- <p>The <c>IIOPTrace</c> file will contain, if you use the <c>orber_iiop_tracer</c>
- interceptor, reports which looks like:</p>
- <code type="none">
-=INFO REPORT==== 13-Jul-2005::18:22:39 ===
-=============== new_out_connection =======
-Node : myNode@myHost
-From : 192.0.0.10:47987
-To : 192.0.0.20:4001
-==========================================
-
-=INFO REPORT==== 29-Nov-2001::15:26:28 ===
-=============== out_request ==============
-Connection: {"192.0.0.20",4001,"192.0.0.10",47987}
-Operation : resolve
-Parameters: [[{'CosNaming_NameComponent',
- "AIK","SwedishIcehockeyChampions"}]]
-Context : [{'IOP_ServiceContext',1,
- {'CONV_FRAME_CodeSetContext',65537,65801}}]
-==========================================
- </code>
- <p>The <c>orber_iiop_tracer_silent</c> will not log GIOP encoded data. To activate
- one the interceptors, you have two options:</p>
- <list type="bulleted">
- <item><em>erl -orber interceptors "{native,[orber_iiop_tracer]}"</em> - can be added to a start-script.</item>
- <item><em>corba:orb_init([{interceptors, {native, [orber_iiop_tracer_silent]}}])</em> - this operation must
- be invoked <em>before</em> starting Orber.</item>
- </list>
- <p>It is also possible to active and deactivate an interceptor during
- run-time, but this will only affect currently existing connections.
- For more information, consult Orber's Reference Manual regarding the
- operations <c>orber:activate_audit_trail/0/1</c> and
- <c>orber:activate_audit_trail/0/1.</c></p>
- </section>
-
- <section>
- <title>FAQ</title>
- <p><em>Q: When my client, typically written in C++ or Java, invoke narrow on an Orber object reference it fails?</em></p>
- <p>A: You must register your application in the IFR by invoking <c>oe_register()</c>.
- If the object was created by a COS-application, you must run install
- (e.g. <c>cosEventApp:install()</c>).</p>
- <p>A: Confirm, by consulting the IDL specifications, that the received object reference really
- inherit from the interface you are trying to narrow it to.</p>
- <br></br>
- <p><em>Q: I am trying to register my application in the IFR but it fails. Why?</em></p>
- <p>A: If one, or more, interface in your IDL-specification inherits from
- other interface(s), you must register them before registering your
- application. Note, this also apply when you inherit interfaces
- supported by a COS-application. Hence, they must be installed prior to
- registration of your application.</p>
- <br></br>
- <p><em>Q: I have a Orber client and server residing on two different Orber instances but I only get the 'OBJECT_NOT_EXIST' exception, even though I am sure that the object is still alive?</em></p>
- <p>A: If the two Orber-ORB's are not intended to be a part of multi-node ORB, make sure that the
- two Orber-ORB's have different <em>domain</em> names set (see
- <seealso marker="ch_install#config">configuration settings</seealso>). The easiest way
- to confirm this is to invoke <c>orber:info()</c> on each node.</p>
- <br></br>
- <p><em>Q: When I'm trying to install and/or start Orber it fails?</em></p>
- <p>A: Make sure that no other Orber-ORB is already running on the same node. If so,
- change the <c>iiop_port</c> configuration parameter (see
- <seealso marker="ch_install#config">configuration settings</seealso>).</p>
- <br></br>
- <p><em>Q: My Orber server is invoked via IIOP but Orber cannot marshal the reply?</em></p>
- <p>A: Consult your IDL file to confirm that your replies are of the correct
- type. If it is correct and the return type is, for example,
- a struct, make sure you have set every field in the struct. If
- you do not do that it will be set to the atom 'undefined', which
- most certainly is not correct.</p>
- <br></br>
- <p>A: Check that you handle <c>inout</c> and <c>out</c> parameters correctly
- (see the IDL specification). For example, a function which have one
- out-parameter and should return void, then your call-back module
- should return <c>{reply, {ok, OutParam}, State}</c>. Note, even though
- the return value is void (IDL) you must reply with ok.</p>
- <br></br>
- <p><em>Q: I cannot run Orber as a multi-node ORB?</em></p>
- <p>A: Make sure that the Erlang distribution have been started for each
- node and the <c>cookies</c> are correct. For more information,
- consult the <c>System Documentation</c></p>
- <br></br>
- </section>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_exceptions.xml b/lib/orber/doc/src/ch_exceptions.xml
deleted file mode 100644
index 17657d0d4a..0000000000
--- a/lib/orber/doc/src/ch_exceptions.xml
+++ /dev/null
@@ -1,238 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>2001</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>CORBA System and User Defined Exceptions</title>
- <prepared></prepared>
- <docno></docno>
- <date>2000-12-19</date>
- <rev></rev>
- <file>ch_exceptions.xml</file>
- </header>
-
- <section>
- <title>System Exceptions</title>
- <p><c>Orber</c>, or any other <c>ORB</c>, may raise a <c>System Exceptions</c>.
- These exceptions contain status- and minor-fields and may not appear in the
- operations raises exception IDL-definition.</p>
-
- <section>
- <title>Status Field</title>
- <p>The status field indicates if the request was completed or not and will be
- assigned one of the following Erlang atoms:</p>
- <table>
- <row>
- <cell align="center" valign="middle"><em>Status</em></cell>
- <cell align="center" valign="middle"><em>Description</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">'COMPLETED_YES'</cell>
- <cell align="left" valign="middle">The operation was invoked on the target object but an error occurred after the object replied. This occur, for example, if a server replies but Orber is not able to marshal and send the reply to the client ORB.</cell>
- </row>
- <row>
- <cell align="left" valign="middle">'COMPLETED_NO'</cell>
- <cell align="left" valign="middle">Orber failed to invoke the operation on the target object. This occur, for example, if the object no longer exists.</cell>
- </row>
- <row>
- <cell align="left" valign="middle">'COMPLETED_MAYBE'</cell>
- <cell align="left" valign="middle">Orber invoked the operation on the target object but an error occurred and it is impossible to decide if the request really reached the object or not.</cell>
- </row>
- <tcaption>System Exceptions Status</tcaption>
- </table>
- </section>
-
- <section>
- <title>Minor Field</title>
- <p>The minor field contains an integer (VMCID), which is related to a more
- specific reason why an invocation failed. The function
- <c>orber:exception_info/1</c> can be used to map the minor code to a string.
- Note, for VMCID:s not assigned by the OMG or Orber, the documentation
- for that particular ORB must be consulted.</p>
- </section>
-
- <section>
- <title>Supported System Exceptions</title>
- <p>The OMG CORBA specification defines the following exceptions:</p>
- <list type="bulleted">
- <item><em>'BAD_CONTEXT'</em> - if a request does not contain a correct
- context this exception is raised.</item>
- <item><em>'BAD_INV_ORDER'</em> - this exception indicates that operations
- has been invoked operations in the wrong order, which would cause,
- for example, a dead-lock.</item>
- <item><em>'BAD_OPERATION'</em> - raised if the target object exists, but
- that the invoked operation is not supported.</item>
- <item><em>'BAD_PARAM'</em> - is thrown if, for example, a parameter is out
- of range or otherwise considered illegal.</item>
- <item><em>'BAD_TYPECODE'</em> - if illegal type code is passed, for example,
- encapsulated in an any data type the <c>'BAD_TYPECODE'</c> exception
- will be raised.</item>
- <item><em>'BAD_QOS'</em> - raised whenever an object cannot support the
- required quality of service.</item>
- <item><em>'CODESET_INCOMPATIBLE'</em> - raised if two ORB's cannot
- communicate due to different representation of, for example,
- <c>char</c> and/or <c>wchar</c>.</item>
- <item><em>'COMM_FAILURE'</em> - raised if an ORB is unable to setup
- communication or it is lost while an operation is in progress.</item>
- <item><em>'DATA_CONVERSION'</em> - raised if an ORB cannot convert data
- received to the native representation. See also the
- <c>'CODESET_INCOMPATIBLE'</c> exception.</item>
- <item><em>'FREE_MEM'</em> - the ORB failed to free dynamic memory and
- failed.</item>
- <item><em>'IMP_LIMIT'</em> - an implementation limit was exceeded in the
- ORB at run time. A object factory may, for example, limit the
- number of object clients are allowed to create.</item>
- <item><em>'INTERNAL'</em> - an internal failure occurred in an ORB, which
- is unrecognized. You may consider contacting the ORB providers
- support.</item>
- <item><em>'INTF_REPOS'</em> - the ORB was not able to reach the interface
- repository, or some other failure relating to the interface
- repository is detected.</item>
- <item><em>'INITIALIZE'</em> - the ORB initialization failed due to, for
- example, network or configuration error.</item>
- <item><em>'INVALID_TRANSACTION'</em> - is raised if the request carried an
- invalid transaction context.</item>
- <item><em>'INV_FLAG'</em> - an invalid flag was passed to an operation,
- which caused, for example, a connection to be closed.</item>
- <item><em>'INV_IDENT'</em> - this exception indicates that an IDL
- identifier is incorrect.</item>
- <item><em>'INV_OBJREF'</em> - this exception is raised if an object
- reference is malformed or a nil reference (see
- also corba:create_nil_objref/0).</item>
- <item><em>'INV_POLICY'</em> - the invocation cannot be made due to an
- incompatibility between policy overrides that apply to the
- particular invocation.</item>
- <item><em>'MARSHAL'</em> - this exception may be raised by the client- or
- server-side when either ORB is unable to marshal/unmarshal requests or
- replies.</item>
- <item><em>'NO_IMPLEMENT'</em> - if the operation exists but no implementation
- exists, this exception is raised.</item>
- <item><em>'NO_MEMORY'</em> - the ORB has run out of memory.</item>
- <item><em>'NO_PERMISSION'</em> - the caller has insufficient privileges,
- such as, for example, bad <c>SSL</c> certificate.</item>
- <item><em>'NO_RESOURCES'</em> - a general platform resource limit
- exceeded.</item>
- <item><em>'NO_RESPONSE'</em> - no response available of a deferred
- synchronous request.</item>
- <item><em>'OBJ_ADAPTER'</em> - indicates administrative mismatch; the object
- adapter is not able to associate an object with the implementation
- repository.</item>
- <item><em>'OBJECT_NOT_EXIST'</em> - the object have been disposed or
- terminated; clients should remove all copies of the object reference
- and initiate desired recovery process.</item>
- <item><em>'PERSIST_STORE'</em> - the ORB was not able to establish a
- connection to its persistent storage or data contained in the
- the storage is corrupted.</item>
- <item><em>'REBIND'</em> - a request resulted in, for example, a
- <c>'LOCATION_FORWARD'</c> message; if the policies are incompatible
- this exception is raised.</item>
- <item><em>'TIMEOUT'</em> - raised if a request fail to complete within the
- given time-limit.</item>
- <item><em>'TRANSACTION_MODE'</em> - a transaction policy mismatch detected.</item>
- <item><em>'TRANSACTION_REQUIRED'</em> - a transaction is required for the
- invoked operation but the request contained no transaction context.</item>
- <item><em>'TRANSACTION_ROLLEDBACK'</em> - the transaction associated with
- the request has already been rolled back or will be.</item>
- <item><em>'TRANSACTION_UNAVAILABLE'</em> - no transaction context can be
- supplied since the ORB is unable to contact the Transaction
- Service.</item>
- <item><em>'TRANSIENT'</em> - the ORB could not determine the current status
- of an object since it could not be reached. The error may be
- temporary.</item>
- <item><em>'UNKNOWN'</em> - is thrown if an implementation throws a
- non-CORBA, or unrecognized, exception.</item>
- </list>
- </section>
- </section>
-
- <section>
- <title>User Defined Exceptions</title>
- <p>User exceptions is defined in IDL-files and is listed in operations raises
- exception listing. For example, if we have the following IDL code:</p>
- <code type="none">
-module MyModule {
-
- exception MyException {};
- exception MyExceptionMsg { string ExtraInfo; };
-
- interface MyInterface {
-
- void foo()
- raises(MyException);
-
- void bar()
- raises(MyException, MyExceptionMsg);
-
- void baz();
- };
-};
- </code>
- </section>
-
- <section>
- <title>Throwing Exceptions</title>
- <p>To be able to raise <c>MyException</c> or <c>MyExceptionMsg</c> exceptions,
- the generated <c>MyModule.hrl</c> must be included, and typical usage is:</p>
- <code type="erl">
--module('MyModule_MyInterface_impl').
--include("MyModule.hrl").
-
-bar(State) ->
- case TestingSomething of
- ok ->
- {reply, ok, State};
- {error, Reason} when list(Reason) ->
- corba:raise(#'MyModule_MyExceptionMsg'{'ExtraInfo' = Reason});
- error ->
- corba:raise(#'MyModule_MyException'{})
- end.
- </code>
- </section>
-
- <section>
- <title>Catching Exceptions</title>
- <p>Depending on which operation we invoke we must be able to handle:</p>
- <list type="bulleted">
- <item>foo - <c>MyException</c> or a system exception.</item>
- <item>bar - <c>MyException</c>, <c>MyExceptionMsg</c> or a system
- exception.</item>
- <item>baz - a system exception.</item>
- </list>
- <p>Catching and matching exceptions can bee done in different ways:</p>
- <code type="none">
- case catch 'MyModule_MyInterface':bar(MIReference) of
- ok ->
- %% The operation raised no exception.
- ok;
- {'EXCEPTION', #'MyModule_MyExceptionMsg'{'ExtraInfo' = Reason}} ->
- %% If we want to log the Reason we must extract 'ExtraInfo'.
- error_logger:error_msg("Operation 'bar' raised: ~p~n", [Reason]),
- ... do something ...;
- {'EXCEPTION', E} when record(E, 'OBJECT_NOT_EXIST') ->
- ... do something ...;
- {'EXCEPTION', E} ->
- ... do something ...
- end.
- </code>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml b/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml
deleted file mode 100644
index eaa88f24f1..0000000000
--- a/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml
+++ /dev/null
@@ -1,1504 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1997</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>OMG IDL to Erlang Mapping</title>
- <prepared></prepared>
- <docno></docno>
- <date>1998-10-10</date>
- <rev></rev>
- <file>ch_idl_to_erlang_mapping.xml</file>
- </header>
-
- <section>
- <title>OMG IDL to Erlang Mapping - Overview</title>
- <p>The purpose of OMG IDL, <em>Interface Definition Language</em>, mapping
- is to act as translator between platforms and languages. An IDL
- specification is supposed to describe data types, object types etc.</p>
- <p>CORBA is independent of the programming language used to construct
- clients or implementations. In order to use the ORB, it is
- necessary for programmers to know how to access ORB functionality
- from their programming languages. It translates different IDL constructs
- to a specific programming language. This chapter
- describes the mapping of OMG IDL constructs to the Erlang programming
- language.</p>
- </section>
-
- <section>
- <title>OMG IDL Mapping Elements</title>
- <p>A complete language mapping will allow the programmer to have
- access to all ORB functionality in a way that is convenient for
- a specified programming language.
- </p>
- <p>All mapping must define the following elements:
- </p>
- <list type="bulleted">
- <item>All OMG IDL basic and constructed types</item>
- <item>References to constants defined in OMG IDL</item>
- <item>References to objects defined in OMG IDL</item>
- <item>Invocations of operations, including passing of
- parameters and receiving of results</item>
- <item>Exceptions, including what happens when an operation
- raises an exception and how the exception parameters are
- accessed</item>
- <item>Access to attributes</item>
- <item>Signatures for operations defined by the ORB, such as
- dynamic invocation interface, the object adapters etc.</item>
- <item>Scopes;
- OMG IDL has several levels of scopes, which are mapped to Erlang's
- two scopes.</item>
- </list>
- </section>
-
- <section>
- <title>Getting Started</title>
- <p>To begin with, we should decide which type of objects (i.e. servers) we
- need and if two, or more, should export the same functionality. Let us
- assume that we want to create a system for DB (database) access for different
- kind of users. For example, anyone with a valid password may extract
- data, but only a few may update the DB. Usually, an application
- is defined within a <c>module</c>, and all global datatypes are defined
- on the top-level. To begin with we create a module and the interfaces we
- need:</p>
- <code type="none">
-// DB IDL
-#ifndef _DB_IDL_
-#define _DB_IDL_
-// A module is simply a container
-module DB {
-
- // An interface maps to a CORBA::Object.
- interface CommonUser {
-
- };
-
- // Inherit the Consumer interface
- interface Administrator : CommonUser {
-
- };
-
- interface Access {
-
- };
-
-};
-#endif </code>
- <p>Since the <c>Administrator</c> should be able to do the same things as the
- <c>CommonUser</c>, the previous inherits from the latter. The <c>Access</c>
- interface will grant access to the DB.
- Now we are ready to define the functionality and data types we need. But, this
- requires that we know a little bit more about the OMG IDL.</p>
- <note>
- <p>The OMG defines a set of reserved case insensitive key-words, which may
- <em>NOT</em> be used as identifiers (e.g. module name). For more
- information, see
- <seealso marker="#key_words">Reserved Compiler Names and Keywords</seealso></p>
- </note>
- </section>
-
- <section>
- <title>Basic OMG IDL Types</title>
- <p>The OMG IDL mapping is strongly typed and, even if you have a good knowledge
- of CORBA types, it is essential to read carefully the following mapping to
- Erlang types.</p>
- <p>The mapping of basic types is straightforward. Note that the
- OMG IDL double type is mapped to an Erlang float which does not
- support the full double value range.</p>
- <table>
- <row>
- <cell align="left" valign="middle">OMG IDL type</cell>
- <cell align="left" valign="middle">Erlang type</cell>
- <cell align="left" valign="middle">Note</cell>
- </row>
- <row>
- <cell align="left" valign="middle">float</cell>
- <cell align="left" valign="middle">Erlang float</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">double</cell>
- <cell align="left" valign="middle">Erlang float</cell>
- <cell align="left" valign="middle">value range not supported</cell>
- </row>
- <row>
- <cell align="left" valign="middle">short</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle">-2^15 .. 2^15-1</cell>
- </row>
- <row>
- <cell align="left" valign="middle">unsigned short</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle">0 .. 2^16-1</cell>
- </row>
- <row>
- <cell align="left" valign="middle">long</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle">-2^31 .. 2^31-1</cell>
- </row>
- <row>
- <cell align="left" valign="middle">unsigned long</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle">0 .. 2^32-1</cell>
- </row>
- <row>
- <cell align="left" valign="middle">long long</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle">-2^63 .. 2^63-1</cell>
- </row>
- <row>
- <cell align="left" valign="middle">unsigned long long</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle">0 .. 2^64-1</cell>
- </row>
- <row>
- <cell align="left" valign="middle">char</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle">ISO-8859-1</cell>
- </row>
- <row>
- <cell align="left" valign="middle">wchar</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle">UTF-16 (ISO-10646-1:1993)</cell>
- </row>
- <row>
- <cell align="left" valign="middle">boolean</cell>
- <cell align="left" valign="middle">Erlang atom</cell>
- <cell align="left" valign="middle">true/false</cell>
- </row>
- <row>
- <cell align="left" valign="middle">octet</cell>
- <cell align="left" valign="middle">Erlang integer</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">any</cell>
- <cell align="left" valign="middle">Erlang record</cell>
- <cell align="left" valign="middle">#any{typecode, value}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">long double</cell>
- <cell align="left" valign="middle">Not supported</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">Object</cell>
- <cell align="left" valign="middle">Orber object reference</cell>
- <cell align="left" valign="middle">Internal Representation</cell>
- </row>
- <row>
- <cell align="left" valign="middle">void</cell>
- <cell align="left" valign="middle">Erlang atom</cell>
- <cell align="left" valign="middle">ok</cell>
- </row>
- <tcaption>OMG IDL basic types</tcaption>
- </table>
- <p>The <c>any</c> value is written as a record with the field typecode which
- contains the <term id="Type Code"><termdef>Type Code is a full definition of a type </termdef></term>representation,
- <seealso marker="#tk_values">see also the Type Code table</seealso>,
- and the value field itself.</p>
- <p>Functions with return type <c>void</c> will return the atom <c>ok</c>.</p>
- </section>
-
- <section>
- <title>Template OMG IDL Types and Complex Declarators</title>
- <p>Constructed types all have native mappings as shown in the table
- below.</p>
- <table>
- <row>
- <cell align="left" valign="middle"><em>Type</em></cell>
- <cell align="left" valign="middle"><em>IDL code</em></cell>
- <cell align="left" valign="middle"><em>Maps to</em></cell>
- <cell align="left" valign="middle"><em>Erlang code</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>string</em></cell>
- <cell align="left" valign="middle">typedef string S; <br></br>
-void op(in S a);</cell>
- <cell align="left" valign="middle">Erlang string</cell>
- <cell align="left" valign="middle">ok = op(Obj, "Hello World"),</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>wstring</em></cell>
- <cell align="left" valign="middle">typedef wstring S; <br></br>
-void op(in S a);</cell>
- <cell align="left" valign="middle">Erlang list of Integers</cell>
- <cell align="left" valign="middle">ok = op(Obj, "Hello World"),</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>sequence</em></cell>
- <cell align="left" valign="middle">typedef sequence &lt;long, 3&gt; S; <br></br>
-void op(in S a);</cell>
- <cell align="left" valign="middle">Erlang list</cell>
- <cell align="left" valign="middle">ok = op(Obj, [1, 2, 3]),</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>array</em></cell>
- <cell align="left" valign="middle">typedef string S[2]; <br></br>
-void op(in S a);</cell>
- <cell align="left" valign="middle">Erlang tuple</cell>
- <cell align="left" valign="middle">ok = op(Obj, {"one", "two"}),</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>fixed</em></cell>
- <cell align="left" valign="middle">typedef fixed&lt;3,2> myFixed; <br></br>
-void op(in myFixed a);</cell>
- <cell align="left" valign="middle">Erlang tuple</cell>
- <cell align="left" valign="middle">MF = fixed:create(3, 2, 314), <br></br>
-ok = op(Obj, MF),</cell>
- </row>
- <tcaption>OMG IDL Template and Complex Declarators</tcaption>
- </table>
-
- <section>
- <title>String/WString Data Types</title>
- <p>A <c>string</c> consists of all possible 8-bit quantities except null.
- Most ORB:s uses, including Orber, the character set Latin-1 (ISO-8859-1).
- The <c>wstring</c> type is represented as a list of integers, where
- each integer represents a wide character. In this case Orber uses, as
- most other ORB:s, the UTF-16 (ISO-10646-1:1993) character set.</p>
- <p>When defining a a string or wstring they can be of limited length or
- null terminated:</p>
- <code type="none"><![CDATA[
-// Null terminated
-typedef string myString;
-typedef wstring myWString;
-// Maximum length 10
-typedef string<10> myString10;
-typedef wstring<10> myWString10;
- ]]></code>
- <p>If we want to define a char/string or wchar/wstring constant, we can
- use octal (\OOO - one, two or three octal digits),
- hexadecimal (\xHH - one or two hexadecimal digits) and unicode (\uHHHH -
- one, two, three or four hexadecimal digits.) representation as well.
- For example:</p>
- <code type="none">
-const string SwedensBestSoccerTeam = "\101" "\x49" "\u004B";
-const wstring SwedensBestHockeyTeam = L"\101\x49\u004B";
-const char aChar = '\u004B';
-const wchar aWchar = L'\u004C';
- </code>
- <p>Naturally, we can use <c>"Erlang"</c>, <c>L"Rocks"</c>, <c>'A'</c>
- and <c>L'A'</c> as well.</p>
- </section>
-
- <section>
- <title>Sequence Data Type</title>
- <p>A sequence can be defined to be of a maximum length or unbounded, and may
- contain Basic and Template types and scoped names:</p>
- <code type="none"><![CDATA[
-typedef sequence <short, 1> aShortSequence;
-typedef sequence <long> aLongSequence;
-typedef sequence <aLongSequence> anEvenLongerSequence;
- ]]></code>
- </section>
-
- <section>
- <title>Array Data Type</title>
- <p>Arrays are multidimensional, fixed-size arrays. The indices is language
- mapping specific, which is why one should not pass them as arguments
- to another ORB.</p>
- <code type="none">
-typedef long myMatrix[2][3];
- </code>
- </section>
-
- <section>
- <title>Fixed Data Type</title>
- <p>A Fixed Point literal consists of an integer part (decimal digits),
- decimal point and a fraction part (decimal digits),
- followed by a <c>D</c> or <c>d</c>. Either the integer part or the
- fraction part may be missing; the decimal point may be missing,
- but not d/D. The integer part must be a positive integer less than 32.
- The Fraction part must be a positive integer less than or equal to
- the Integer part.</p>
- <code type="none">
-const fixed myFixed1 = 3.14D;
-const fixed myFixed2 = .14D;
-const fixed myFixed3 = 0.14D;
-const fixed myFixed4 = 3.D;
-const fixed myFixed5 = 3D;
- </code>
- <p>It is also possible to use unary (+-) and binary (+-*/) operators:</p>
- <code type="none">
-const fixed myFixed6 = 3D + 0.14D;
-const fixed myFixed7 = -3.14D;
- </code>
- <p>The Fixed Point examples above are, so called, <em>anonymous</em>
- definitions. In later CORBA specifications these have been deprecated
- as function parameters or return values. Hence, we strongly recommend that
- you do not use them. Instead, you should use:</p>
- <code type="none"><![CDATA[
-typedef fixed<5,3> myFixed53;
-const myFixed53 myFixed53constant = 03.140d;
-typedef fixed<3,2> myFixed32;
-const myFixed32 myFixed32constant = 3.14d;
-
-myFixed53 foo(in myFixed32 MF); // OK
-void bar(in fixed<5,3> MF); // Illegal
- ]]></code>
- </section>
- <p>For more information, see <seealso marker="fixed">Fixed</seealso> in
- Orber's Reference Manual.</p>
- <p>Now we continue to work on our IDL specification. To begin with, we want
- to limit the size of the logon parameters (Id and password). Since the
- <c>UserID</c> and <c>Password</c> parameters, only will be used when
- invoking operations on the <c>Access</c> interface, we may choose to define
- them within the scope that interface. To keep it simple our DB will contain
- employee information. Hence, as the DB key we choose an integer
- (<c>EmployeeNo</c>).</p>
- <code type="none"><![CDATA[
-// DB IDL
-#ifndef _DB_IDL_
-#define _DB_IDL_
-module DB {
-
- typedef unsigned long EmployeeNo;
-
- interface CommonUser {
-
- any lookup(in EmployeeNo ENo);
-
- };
-
- interface Administrator : CommonUser {
-
- void delete(in EmployeeNo ENo);
-
- };
-
- interface Access {
-
- typedef string<10> UserID;
- typedef string<10> Password;
-
- CommonUser logon(in UserID ID, in Password PW);
-
- };
-
-};
-#endif ]]></code>
- <p>But what should, for example, the <c>lookup</c> operation return? One option
- is to use the <c>any</c> data type. But, depending on what kind of data it
- encapsulates, this datatype can be rather expensive to use. We might find a
- solution to our problems among the <c>Constructed</c> IDL types.</p>
- </section>
-
- <section>
- <title>Constructed OMG IDL Types</title>
- <p>Constructed types all have native mappings as shown in the table
- below.</p>
- <table>
- <row>
- <cell align="left" valign="middle"><em>Type</em></cell>
- <cell align="left" valign="middle"><em>IDL code</em></cell>
- <cell align="left" valign="middle"><em>Maps to</em></cell>
- <cell align="left" valign="middle"><em>Erlang code</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>struct</em></cell>
- <cell align="left" valign="middle">struct myStruct { <br></br>
-long a; <br></br>
-short b; <br></br>
-}; <br></br>
-void op(in myStruct a);</cell>
- <cell align="left" valign="middle">Erlang record</cell>
- <cell align="left" valign="middle">ok = op(Obj, #'myStruct'{a=300, b=127}),</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>union</em></cell>
- <cell align="left" valign="middle">union myUnion switch(long) { <br></br>
-case 1: long a; <br></br>
-}; <br></br>
-void op(in myUnion a);</cell>
- <cell align="left" valign="middle">Erlang record</cell>
- <cell align="left" valign="middle">ok = op(Obj, #'myUnion'{label=1, value=66}),</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>enum</em></cell>
- <cell align="left" valign="middle">enum myEnum {one, two}; <br></br>
-void op(in myEnum a);</cell>
- <cell align="left" valign="middle">Erlang atom</cell>
- <cell align="left" valign="middle">ok = op(Obj, one),</cell>
- </row>
- <tcaption>OMG IDL constructed types</tcaption>
- </table>
-
- <section>
- <title>Struct Data Type</title>
- <p>A <c>struct</c> may have Basic, Template, Scoped Names and Constructed
- types as members. By using forward declaration we can define a recursive struct:</p>
- <code type="none"><![CDATA[
-struct myStruct; // Forward declaration
-typedef sequence<myStruct> myStructSeq;
-struct myStruct {
- myStructSeq chain;
-};
-
-// Deprecated definition (anonymous) not supported by IC
-struct myStruct {
- sequence<myStruct> chain;
-};
- ]]></code>
- </section>
-
- <section>
- <title>Enum Data Type</title>
- <p>The maximum number of identifiers which may defined in an enumeration
- is 2&sup3;&sup2;. The order in which the identifiers are named in the
- specification of an enumeration defines the relative order of the
- identifiers.</p>
- </section>
-
- <section>
- <title>Union Data Type</title>
- <p>A <c>union</c> may consist of:</p>
- <list type="bulleted">
- <item>Identifier</item>
- <item>Switch - may be an integer, char, boolean, enum or scoped name.</item>
- <item>Body - with or without a <c>default</c> case; may appear at
- most once.</item>
- </list>
- <p>A case label must match the defined type of the discriminator, and may only
- contain a default case if the values given in the non-default labels do
- not cover the entire range of the union's discriminant type. For example:</p>
- <code type="none">
-// Illegal default; all cases covered by
-// non-default cases.
-union BooleanUnion switch(boolean) {
- case TRUE: long TrueValue;
- case FALSE: long FalseValue;
- default: long DefaultValue;
-};
-// OK
-union BooleanUnion2 switch(boolean) {
- case TRUE: long TrueValue;
- default: long DefaultValue;
-};
- </code>
- <p>It is not necessary to list all possible values of the union discriminator
- in the body. Hence, the value of a union is the value of the discriminator
- and, in given order, one of the following:</p>
- <list type="ordered">
- <item>If the discriminator match a label, explicitly listed in a
- case statement, the value must be of the same type.</item>
- <item>If the union contains a default label, the value must match the
- type of the default label.</item>
- <item>No value. Orber then inserts the Erlang atom <c>undefined</c>
- in the value field when receiving a union from an external
- ORB.</item>
- </list>
- <p>The above can be summed up to:</p>
- <code type="none">
-// If the discriminator equals 1 or 2 the value
-// is a long. Otherwise, the atom undefined.
-union LongUnion switch(long) {
- case 1:
- case 2: long TrueValue;
-};
-// If the discriminator equals 1 or 2 the value
-// is a long. Otherwise, a boolean.
-union LongUnion2 switch(long) {
- case 1:
- case 2: long TrueValue;
- default: boolean DefaultValue;
-};
- </code>
- <p>In the same way as structs, unions can be recursive if forward
- declaration is used (anonymous types is deprecated and not supported):</p>
- <code type="none"><![CDATA[
-// Forward declaration
-union myUnion;
-typedef sequence<myUnion>myUnionSeq;
-union myUnion switch (long) {
- case 1 : myUnionSeq chain;
- default: boolean DefaultValue;
-};
- ]]></code>
-
- <note>
- <p>Recursive types (union and struct) require Light IFR. I.e. the
- IC option {light_ifr, true} is used and that Orber is configured in such a way that
- Light IFR is activated. Recursive TypeCode is currently not supported, which is
- why these cannot be encapsulated in an any data type.</p>
- </note>
-
- </section>
- <warning>
- <p>Every field in, for example, a struct must be initiated. Otherwise
- it will be set to the atom <c>undefined</c>, which Orber cannot
- encode when communicating via IIOP. In the example above, invoking
- the operation with #'myStruct'{a=300} will fail (equal to
- #'myStruct'{a=300, b=undefined})</p>
- </warning>
- <p>Now we can continue to work on our IDL specification. To begin with, we should
- determine the return value of the <c>lookup</c> operation. Since the <c>any</c>
- type can be rather expensive we can use a <c>struct</c> or a <c>union</c> instead.
- If we intend to return the same information about a employee every time we can
- use a struct. Let us assume that the DB contains the name, address, employee
- number and department.</p>
- <code type="none"><![CDATA[
-// DB IDL
-#ifndef _DB_IDL_
-#define _DB_IDL_
-module DB {
-
- typedef unsigned long EmployeeNo;
-
- enum Department {Department1, Department2};
-
- struct employee {
- EmployeeNo No;
- string Name;
- string Address;
- Department Dpt;
- };
-
- typedef employee EmployeeData;
-
- interface CommonUser {
-
- EmployeeData lookup(in EmployeeNo ENo);
-
- };
-
- interface Administrator : CommonUser {
-
- void delete(in EmployeeNo ENo);
-
- };
-
- interface Access {
-
- typedef string<10> UserID;
- typedef string<10> Password;
-
- // Since Administrator inherits from CommonUser
- // the returned Object can be of either type.
- CommonUser logon(in UserID ID, in Password PW);
-
- };
-
-};
-#endif ]]></code>
- <p>We can also define exceptions (i.e. not system exception) thrown by
- each interface. Since exceptions are thoroughly described in the chapter
- <seealso marker="ch_exceptions">System and User Defined Exceptions</seealso>,
- we choose not to. Hence, we are now ready to compile our IDL-file by
- invoking:</p>
- <pre>
-$ <input>erlc DB.idl</input>
- </pre>
- <p>or:</p>
- <pre>
-$ <input>erl</input>
-Erlang (BEAM) emulator version 5.1.1 [threads:0]
-
-Eshell V5.1.1 (abort with ^G)
-1> <input>ic:gen('DB').</input>
-ok
-2> <input>halt().</input>
- </pre>
- <p>The next step is to implement our servers. But, to be able to do that,
- we need to know how we can access data type definitions. For example,
- since a struct is mapped to an Erlang record we must include an hrl-file
- in our callback module.</p>
- </section>
-
- <section>
- <title>Scoped Names and Generated Files</title>
-
- <section>
- <title>Scoped Names</title>
- <p>Within a scope all identifiers must be unique. The following kinds of
- definitions form scopes in the OMG IDL:</p>
- <list type="bulleted">
- <item><em>module</em></item>
- <item><em>interface</em></item>
- <item><em>operation</em></item>
- <item><em>valuetype</em></item>
- <item><em>struct</em></item>
- <item><em>union</em></item>
- <item><em>exception</em></item>
- </list>
- <p>For example, since enumerants do not form a scope, the following IDL code
- is not valid:</p>
- <code type="none">
-module MyModule {
- // 'two' is not unique
- enum MyEnum {one, two};
- enum MyOtherEnum {two, three};
-};
- </code>
- <p>But, since Erlang only has two levels of scope, <em>module</em> and
- <em>function</em>, the OMG IDL scope is mapped as follows:</p>
- <list type="bulleted">
- <item><em>Function Scope</em> - used for constants, operations and attributes.</item>
- <item><em>Erlang Module Scope</em> - the Erlang module scope
- handles the remaining OMG IDL scopes.</item>
- </list>
- <p>An Erlang module, corresponding to an IDL global name, is derived by
- converting occurrences of "::" to underscore, and eliminating
- the leading "::". Hence, accessing <c>MyEnum</c> from another module, one
- use <c>MyModule::MyEnum</c></p>
- <p>For example, an operation <c>foo</c> defined in interface <c>I</c>, which
- is defined in module <c>M</c>, would be written in IDL as <c>M::I::foo</c>
- and as <c>'M_I':foo</c> in Erlang - <c>foo</c> is the function
- name and <c>'M_I'</c> is the name of the Erlang module. Applying this
- knowledge to a stripped version of the DB.idl gives:</p>
- <code type="none"><![CDATA[
-// DB IDL
-#ifndef _DB_IDL_
-#define _DB_IDL_
-// ++ topmost scope ++
-// IC generates oe_XX.erl and oe_XX.hrl.
-// XX is equal to the name of the IDL-file.
-// Tips: create one IDL-file for each top module
-// and give the file the same name (DB.idl).
-// The oe_XX.erl module is used to register data
-// in the IFR.
-module DB {
-
- // ++ Module scope ++
- // To access 'EmployeeNo' from another scope, use:
- // DB::EmployeeNo, DB::Access etc.
- typedef unsigned long EmployeeNo;
-
- enum Department {Department1, Department2};
-
- // Definitions of this struct is contained in:
- // DB.hrl
- // Access functions exported by:
- // DB_employee.erl
- struct employee {
- ... CUT ...
- };
-
- typedef employee EmployeeData;
-
- ... CUT ...
-
- // If this interface should inherit an interface
- // in another module (e.g. OtherModule) use:
- // interface Access : OtherModule::OtherInterface
- interface Access {
-
- // ++ interface scope ++
- // Types within this scope is accessible via:
- // DB::Access::UserID
- // The Stub/Skeleton for this interface is
- // placed in the module:
- // DB_Access.erl
- typedef string<10> UserID;
- typedef string<10> Password;
-
- // Since Administrator inherits from CommonUser
- // the returned Object can be of either type.
- // This operation is exported from:
- // DB_Access.erl
- CommonUser logon(in UserID ID, in Password PW);
-
- };
-
-};
-#endif ]]></code>
- <p>Using underscores in IDL names can lead to ambiguities
- due to the name mapping described above. It is advisable to
- avoid the use of underscores in identifiers. For example, the following
- definition would generate two structures named <c>x_y_z</c>.</p>
- <code type="none">
-module x {
-
- struct y_z {
- ...
- };
-
- interface y {
-
- struct z {
- ...
- };
- };
-};
- </code>
- </section>
-
- <section>
- <title>Generated Files</title>
- <p>Several files can be generated for each scope.</p>
- <list type="bulleted">
- <item>An Erlang source code file (<c>.erl</c>) is generated
- for top level scope as well as the Erlang header file.</item>
- <item>An Erlang header file (<c>.hrl</c>) will be generated for
- each scope. The header file will contain record definitions
- for all <c>struct</c>, <c>union</c> and <c>exception</c>
- types in that scope.</item>
- <item>Modules that contain at least one constant definition,
- will produce Erlang source code files (<c>.erl</c>).
- That Erlang file will contain constant functions for
- that scope.
- Modules that contain no constant definitions are considered
- empty and no code will be produced for them, but only for
- their included modules/interfaces.</item>
- <item>Interfaces will produce Erlang source code files (<c>.erl</c>),
- this code will contain all operation stub code and implementation
- functions.</item>
- <item>In addition to the scope-related files, an Erlang source file will
- be generated for each definition of the types <c>struct</c>,
- <c>union</c> and <c>exception</c> (these are the types that
- will be represented in Erlang as records).
- This file will contain special access functions for that record.</item>
- <item>The top level scope will produce two files, one header file
- (<c>.hrl</c>) and one Erlang source file (<c>.erl</c>).
- These files are named as the IDL file, prefixed with <c>oe_</c>.</item>
- </list>
- <p>After compiling DB.idl, the following files have been generated:</p>
- <list type="bulleted">
- <item><c>oe_DB.hrl</c> and <c>oe_DB.erl</c> for the top scope level.</item>
- <item><c>DB.hrl</c> for the module <c>DB</c>.</item>
- <item><c>DB_Access.hrl</c> and <c>DB_Access.erl</c> for the interface
- <c>DB_Access</c>.</item>
- <item><c>DB_CommonUser.hrl</c> and <c>DB_CommonUser.erl</c> for the interface
- <c>DB_CommonUser</c>.</item>
- <item><c>DB_Administrator.hrl</c> and <c>DB_Administrator.erl</c> for the interface
- <c>DB_Administrator</c>.</item>
- <item><c>DB_employee.erl</c> for the structure <c>employee</c> in module
- <c>DB</c>.</item>
- </list>
- <p>Since the <c>employee</c> struct is defined in the top level scope,
- the Erlang record definition is found in <c>DB.hrl</c>. IC also generates
- stubs/skeletons (e.g. <c>DB_CommonUser.erl</c>) and access functions for
- some datatypes (e.g. <c>DB_employee.erl</c>). How the stubs/skeletons are
- used is thoroughly described in
- <seealso marker="ch_stubs">Stubs/Skeletons</seealso> and
- <seealso marker="Module_Interface">Module_Interface</seealso>.</p>
- </section>
- </section>
-
- <section>
- <title>Typecode, Identity and Name Access Functions</title>
- <p>As mentioned in a previous section, <c>struct</c>, <c>union</c> and
- <c>exception</c> types yield record definitions and access code
- for that record.
- For <c>struct</c>, <c>union</c>, <c>exception</c>, <c>array</c> and
- <c>sequence</c> types, a special file is generated that holds access
- functions for <c>TypeCode</c>, <c>Identity</c> and <c>Name</c>.
- These functions are put in the file corresponding to the scope where
- they are defined. For example, the module <c>DB_employee.erl</c>,
- representing the <c>employee</c> struct, exports the following functions:</p>
- <list type="bulleted">
- <item>tc/0 - returns the type code for the struct.</item>
- <item>id/0 - returns the IFR identity of the struct. In this case
- the returned value is <c>"IDL:DB/employee:1.0"</c>, but
- if the struct was defined in the scope of <c>CommonUser</c>,
- the result would be <c>"IDL:DB/CommonUser/employee:1.0"</c>.
- However, the user usually do not need to know the Id, just
- which Erlang module contains the correct Id.</item>
- <item>name/0 - returns the scoped name of the struct. The <c>employee</c>
- struct name is <c>"DB_employee"</c>.</item>
- </list>
- <p><term id="Type Codes"><termdef>Type codes give a complete description of the type including all its components and structure.</termdef></term>are, for example, used in <seealso marker="any">Any</seealso> values.
- Hence, we can encapsulate the <c>employee</c> struct in an <c>any</c>
- type by:</p>
- <code type="erl">
-%% Erlang code
-....
-AnEmployee = #'DB_employee'{'No' = 1,
- 'Name' = "Adam Ivan Kendall",
- 'Address' = "Rasunda, Solna",
- 'Dpt' = 'Department1'},
-EmployeeTC = 'DB_employee':tc(),
-EmployeeAny = any:create(EmployeeTC, AnEmployee),
-....
- </code>
- <p>For more information, see the
- <seealso marker="#tk_values">Type Code listing</seealso>.</p>
- </section>
-
- <section>
- <title>References to Constants</title>
- <p>Constants are generated as Erlang functions, and are accessed by a
- single function call. The functions are put in the file
- corresponding to the scope where they are defined. There is no
- need for an object to be started to access a constant.</p>
- <p>Example:</p>
- <code type="none">
-// m.idl
-module m {
- const float pi = 3.14;
-
- interface i {
- const float pi = 3.1415;
- };
-};
- </code>
- <p>Since the two constants are defined in different scopes, the IDL code
- above is valid, but not necessarily a good approach. After compiling
- <c>m.idl</c>, the constant definitions can be extracted by invoking:</p>
- <pre>
-$ <input>erlc m.idl</input>
-$ <input>erlc m.erl</input>
-$ <input>erl</input>
-Erlang (BEAM) emulator version 5.1.1 [threads:0]
-
-Eshell V5.1.1 (abort with ^G)
-1> <input>m:pi().</input>
-3.14
-2> <input>m_i:pi().</input>
-3.1415
-3> <input>halt().</input>
- </pre>
- </section>
-
- <section>
- <title>References to Objects Defined in OMG IDL</title>
- <p>Objects are accessed by object references. An object reference
- is an opaque Erlang term created and maintained by the ORB.</p>
- <p>Objects are implemented by providing implementations for all
- operations and attributes of the Object, <seealso marker="#op_impl">see operation implementation</seealso>.</p>
- </section>
-
- <section>
- <title>Exceptions</title>
- <p>Exceptions are handled as Erlang catch and throws. Exceptions
- are translated to messages over an IIOP bridge but converted
- back to a throw on the receiving side. Object implementations
- that invoke operations on other objects must be aware of the
- possibility of a non-local return. This includes invocation of
- ORB and IFR services. See also the
- <seealso marker="ch_exceptions">Exceptions</seealso> section.</p>
- <p>Exception parameters are mapped as an Erlang record and accessed
- as such.</p>
- <p>An object implementation that raises an exception will use the
- <c>corba:raise/1</c> function, passing the exception record as
- parameter.</p>
- </section>
-
- <section>
- <title>Access to Attributes</title>
- <p>Attributes are accessed through their access functions. An
- attribute implicitly defines the <c>_get</c> and <c>_set</c>
- operations. These operations are handled in the same way as
- normal operations. The <c>_get</c> operation is defined as a <c>readonly</c>
- attribute.</p>
- <code type="none">
-readonly attribute long RAttribute;
-attribute long RWAttribute;
- </code>
- <p>The <c>RAttribute</c> requires that you implement, in your call-back module,
- <c>_get_RAttribute</c>. For the <c>RWAttribute</c> it is necessary to implement
- <c>_get_RWAttribute</c> and <c>_set_RWAttribute</c>.</p>
- </section>
-
- <section>
- <title>Invocations of Operations</title>
- <marker id="op_impl"></marker>
- <p>A standard Erlang <c>gen_server</c> behavior is used for
- object implementation. The <c>gen_server</c> state is then
- used as the object internal state. Implementation of the object
- function is achieved by implementing its methods and attribute operations.
- These functions will usually have the internal state as their first parameter,
- followed by any <c>in</c> and <c>inout</c> parameters. </p>
- <p>Do not confuse the
- object internal state with its object reference. The object internal state is
- an Erlang term which has a format defined by the user.</p>
- <note>
- <p>It is not always the case that the internal state will be the first parameter, as stubs can use their own object reference as the first parameter (see the IC documentation).</p>
- </note>
- <p>A function call will invoke an operation. The first
- parameter of the function should be the object reference and then
- all <c>in</c> and <c>inout</c> parameters follow in the same
- order as specified in the IDL specification. The result will be a return value
- unless the function has <c>inout</c> or <c>out</c> parameters specified;
- in which case, a tuple of the return value, followed by the parameters will
- be returned.</p>
- <p>Example:</p>
- <code type="none">
-// IDL
-module m {
- interface i {
- readonly attribute long RAttribute;
- attribute long RWAttribute;
- long foo(in short a);
- long bar(in char c, inout string s, out long count);
- void baz(out long Id);
- };
-};
- </code>
- <p>Is used in Erlang as :</p>
- <code type="none">
-%% Erlang code
-....
-Obj = ... %% get object reference
-RAttr = m_i:'_get_RAttribute'(Obj),
-RWAttr = m_i:'_get_RWAttribute'(Obj),
-ok = m_i:'_set_RWAttribute'(Obj, Long),
-R1 = m_i:foo(Obj, 55),
-{R2, S, Count} = m_i:bar(Obj, $a, "hello"),
-....
- </code>
- <p>Note how the <c>inout</c> parameter is passed <em>and</em>
- returned. There is no way to use a single occurrence of a
- variable for this in Erlang. Also note, that <c>ok</c>, Orber's
- representation of the IDL-type <c>void</c>, must be returned by
- <c>baz</c> and <c>'_set_RWAttribute'</c>.
- These operations can be implemented in the call-back module as:</p>
- <code type="erl">
-'_set_RWAttribute'(State, Long) ->
- {reply, ok, State}.
-
-'_get_RWAttribute'(State) ->
- {reply, Long, State}.
-
-'_get_RAttribute'(State) ->
- {reply, Long, State}.
-
-foo(State, AShort) ->
- {reply, ALong, State}.
-
-bar(State, AShort, AString) ->
- {reply, {ALong, "MyString", ALong}, State}.
-
-baz(State) ->
- {reply, {ok, AId}, State}.
- </code>
- <p>The operations may require more arguments (depends on IC options used). For
- more information, see <seealso marker="ch_stubs">Stubs/Skeletons</seealso>
- and <seealso marker="Module_Interface">Module_Interface</seealso>.</p>
- <warning>
- <p>A function can also be defined to be <c>oneway</c>, i.e.
- asynchronous. But, since the behavior of a oneway operation is not
- defined in the OMG specifications (i.e. the behavior can differ depending on
- which other ORB Orber is communicating with), one should avoid using it.</p>
- </warning>
- </section>
-
- <section>
- <title>Implementing the DB Application</title>
- <p>Now we are ready to implement the call-back modules. There are three modules
- we must create:</p>
- <list type="bulleted">
- <item>DB_Access_impl.erl</item>
- <item>DB_CommonUser_impl.erl</item>
- <item>DB_Administrator_impl.erl</item>
- </list>
- <p>An easy way to accomplish that, is to use the IC backend <c>erl_template</c>,
- which will generate a complete call-back module. One should also add
- the same compile options, for example <c>this</c> or <c>from</c>,
- used when generating the stub/skeleton modules:</p>
- <code type="none">
-$> erlc +"{be,erl_template}" DB.idl
- </code>
- <p>We begin with implementing the <c>DB_Access_impl.erl</c> module, which,
- if we used <c>erl_template</c>, will look like the following. All we need
- to do is to add the logic to the <c>logon</c> operation.</p>
- <code type="erl"><![CDATA[
-%%----------------------------------------------------------------------
-%% <LICENSE>
-%%
-%% $Id$
-%%
-%%----------------------------------------------------------------------
-%% Module : DB_Access_impl.erl
-%%
-%% Source : /home/user/example/DB.idl
-%%
-%% Description :
-%%
-%% Creation date: 2005-05-20
-%%
-%%----------------------------------------------------------------------
--module('DB_Access_impl').
-
--export([logon/3]).
-
-%%----------------------------------------------------------------------
-%% Internal Exports
-%%----------------------------------------------------------------------
--export([init/1,
- terminate/2,
- code_change/3,
- handle_info/2]).
-
-%%----------------------------------------------------------------------
-%% Include Files
-%%----------------------------------------------------------------------
-
-
-%%----------------------------------------------------------------------
-%% Macros
-%%----------------------------------------------------------------------
-
-
-%%----------------------------------------------------------------------
-%% Records
-%%----------------------------------------------------------------------
--record(state, {}).
-
-%%======================================================================
-%% API Functions
-%%======================================================================
-%%----------------------------------------------------------------------
-%% Function : logon/3
-%% Arguments : State - term()
-%% ID = String()
-%% PW = String()
-%% Returns : ReturnValue = OE_Reply
-%% OE_Reply = Object_Ref()
-%% Raises :
-%% Description:
-%%----------------------------------------------------------------------
-logon(State, ID, PW) ->
- %% Check if the ID/PW is valid and what
- %% type of user it is (Common or Administrator).
- OE_Reply
- = case check_user(ID, PW) of
- {ok, administrator} ->
- 'DB_Administrator':oe_create();
- {ok, common} ->
- 'DB_CommonUser':oe_create();
- error ->
- %% Here we should throw an exception
- corba:raise(....)
- end,
- {reply, OE_Reply, State}.
-
-%%======================================================================
-%% Internal Functions
-%%======================================================================
-%%----------------------------------------------------------------------
-%% Function : init/1
-%% Arguments : Env = term()
-%% Returns : {ok, State} |
-%% {ok, State, Timeout} |
-%% ignore |
-%% {stop, Reason}
-%% Raises : -
-%% Description: Initiates the server
-%%----------------------------------------------------------------------
-init(_Env) ->
- {ok, #state{}}.
-
-
-%%----------------------------------------------------------------------
-%% Function : terminate/2
-%% Arguments : Reason = normal | shutdown | term()
-%% State = term()
-%% Returns : ok
-%% Raises : -
-%% Description: Invoked when the object is terminating.
-%%----------------------------------------------------------------------
-terminate(_Reason, _State) ->
- ok.
-
-
-%%----------------------------------------------------------------------
-%% Function : code_change/3
-%% Arguments : OldVsn = undefined | term()
-%% State = NewState = term()
-%% Extra = term()
-%% Returns : {ok, NewState}
-%% Raises : -
-%% Description: Invoked when the object should update its internal state
-%% due to code replacement.
-%%----------------------------------------------------------------------
-code_change(_OldVsn, State, _Extra) ->
- {ok, State}.
-
-
-%%----------------------------------------------------------------------
-%% Function : handle_info/2
-%% Arguments : Info = normal | shutdown | term()
-%% State = NewState = term()
-%% Returns : {noreply, NewState} |
-%% {noreply, NewState, Timeout} |
-%% {stop, Reason, NewState}
-%% Raises : -
-%% Description: Invoked when, for example, the server traps exits.
-%%----------------------------------------------------------------------
-handle_info(_Info, State) ->
- {noreply, State}.
- ]]></code>
- <p>Since <c>DB_Administrator</c> inherits from <c>DB_CommonUser</c>,
- we must implement <c>delete</c> in the <c>DB_Administrator_impl.erl</c>
- module, and <c>lookup</c> in <c>DB_Administrator_impl.erl</c><em>and</em><c>DB_CommonUser_impl.erl</c>. But wait, is that really necessary? Actually,
- it is not. We simple use the IC compile option <em>impl</em>:</p>
- <pre>
-$ <input>erlc +'{{impl, "DB::CommonUser"}, "DBUser_impl"}'\
- +'{{impl, "DB::Administrator"}, "DBUser_impl"}' DB.idl</input>
-$ <input>erlc *.erl</input>
- </pre>
- <p>Instead of creating, and not the least, maintaining two call-back modules,
- we only have to deal with <c>DBUser_impl.erl</c>. If we generated the
- templates, we simply rename <c>DB_Administrator_impl.erl</c> to
- <c>DBUser_impl.erl</c>. See also the
- <seealso marker="ch_exceptions">Exceptions</seealso> chapter.
- In the following example, only the implementation of the API functions
- are shown:</p>
- <code type="erl">
-%%======================================================================
-%% API Functions
-%%======================================================================
-%%----------------------------------------------------------------------
-%% Function : delete/2
-%% Arguments : State - term()
-%% ENo = unsigned_Long()
-%% Returns : ReturnValue = ok
-%% Raises :
-%% Description:
-%%----------------------------------------------------------------------
-delete(State, ENo) ->
- %% How we access the DB, for example mnesia, is not shown here.
- case delete_employee(No) of
- ok ->
- {reply, ok, State};
- error ->
- %% Here we should throw an exception if
- %% there is no match.
- corba:raise(....)
- end.
-
-%%----------------------------------------------------------------------
-%% Function : lookup/2
-%% Arguments : State - term()
-%% ENo = unsigned_Long()
-%% Returns : ReturnValue = OE_Reply
-%% OE_Reply = #'DB_employee'{No,Name,Address,Dpt}
-%% No = unsigned_Long()
-%% Name = String()
-%% Address = String()
-%% Dpt = Department
-%% Department = 'Department1' | 'Department2'
-%% Raises :
-%% Description:
-%%----------------------------------------------------------------------
-lookup(State, ENo) ->
- %% How we access the DB, for example mnesia, is not shown here.
- case lookup_employee(ENo) of
- %% We assume that we receive a 'DB_employee' struct
- {ok, Employee} ->
- OE_Reply = Employee,
- {reply, OE_Reply, State};
- error ->
- %% Here we should throw an exception if
- %% there is no match.
- corba:raise(....)
- end.
- </code>
- <p>After you have compiled both call-back modules, and implemented the missing
- functionality (e.g. lookup_employee/1), we can test our application:</p>
- <code type="none">
-%% Erlang code
-....
-%% Create an Access object
-Acc = 'DB_Access':oe_create(),
-
-%% Login is Common user and Administrator
-Adm = 'DB_Access':logon(A, "admin", "pw"),
-Com = 'DB_Access':logon(A, "comm", "pw"),
-
-%% Lookup existing employee
-Employee = 'DB_Administrator':lookup(Adm, 1),
-Employee = 'DB_CommonUser':lookup(Adm, 1),
-
-%% If we try the same using the DB_CommonUser interface
-%% it result in an exit since that operation is not exported.
-{'EXIT', _} = (catch 'DB_CommonUser':delete(Adm, 1)),
-
-%% Try to delete the employee via the CommonUser Object
-{'EXCEPTION', _} = (catch 'DB_Administrator':delete(Com, 1)),
-
-%% Invoke delete operation on the Administrator object
-ok = 'DB_Administrator':delete(Adm, 1),
-....
- </code>
- </section>
-
- <section>
- <title>Reserved Compiler Names and Keywords</title>
- <marker id="key_words"></marker>
- <p>The use of some names is strongly discouraged due to
- ambiguities. However, the use of some names is prohibited
- when using the Erlang mapping , as they are strictly reserved for IC.</p>
- <p>IC reserves all identifiers starting with <c>OE_</c> and <c>oe_</c>
- for internal use.</p>
- <p>Note also, that an identifier in IDL can contain alphabetic,
- digits and underscore characters, but the first character
- <em>must</em> be alphabetic.
- </p>
- <p>The OMG defines a set of reserved words, shown below, for use as keywords.
- These may <em>not</em> be used as, for example, identifiers. The keywords
- which are not in bold face was introduced in the OMG CORBA-3.0
- specification.</p>
- <table>
- <row>
- <cell align="left" valign="middle"><em>abstract</em></cell>
- <cell align="left" valign="middle"><em>exception</em></cell>
- <cell align="left" valign="middle"><em>inout</em></cell>
- <cell align="left" valign="middle">provides</cell>
- <cell align="left" valign="middle"><em>truncatable</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>any</em></cell>
- <cell align="left" valign="middle">emits</cell>
- <cell align="left" valign="middle"><em>interface</em></cell>
- <cell align="left" valign="middle"><em>public</em></cell>
- <cell align="left" valign="middle"><em>typedef</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>attribute</em></cell>
- <cell align="left" valign="middle"><em>enum</em></cell>
- <cell align="left" valign="middle"><em>local</em></cell>
- <cell align="left" valign="middle">publishes</cell>
- <cell align="left" valign="middle">typeid</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>boolean</em></cell>
- <cell align="left" valign="middle">eventtype</cell>
- <cell align="left" valign="middle"><em>long</em></cell>
- <cell align="left" valign="middle"><em>raises</em></cell>
- <cell align="left" valign="middle">typeprefix</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>case</em></cell>
- <cell align="left" valign="middle"><em>factory</em></cell>
- <cell align="left" valign="middle"><em>module</em></cell>
- <cell align="left" valign="middle"><em>readonly</em></cell>
- <cell align="left" valign="middle"><em>unsigned</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>char</em></cell>
- <cell align="left" valign="middle"><em>FALSE</em></cell>
- <cell align="left" valign="middle">multiple</cell>
- <cell align="left" valign="middle">setraises</cell>
- <cell align="left" valign="middle"><em>union</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">component</cell>
- <cell align="left" valign="middle">finder</cell>
- <cell align="left" valign="middle"><em>native</em></cell>
- <cell align="left" valign="middle"><em>sequence</em></cell>
- <cell align="left" valign="middle">uses</cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>const</em></cell>
- <cell align="left" valign="middle"><em>fixed</em></cell>
- <cell align="left" valign="middle"><em>Object</em></cell>
- <cell align="left" valign="middle"><em>short</em></cell>
- <cell align="left" valign="middle"><em>ValueBase</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">consumes</cell>
- <cell align="left" valign="middle"><em>float</em></cell>
- <cell align="left" valign="middle"><em>octet</em></cell>
- <cell align="left" valign="middle"><em>string</em></cell>
- <cell align="left" valign="middle"><em>valuetype</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>context</em></cell>
- <cell align="left" valign="middle">getraises</cell>
- <cell align="left" valign="middle"><em>oneway</em></cell>
- <cell align="left" valign="middle"><em>struct</em></cell>
- <cell align="left" valign="middle"><em>void</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>custom</em></cell>
- <cell align="left" valign="middle">home</cell>
- <cell align="left" valign="middle"><em>out</em></cell>
- <cell align="left" valign="middle"><em>supports</em></cell>
- <cell align="left" valign="middle"><em>wchar</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>default</em></cell>
- <cell align="left" valign="middle">import</cell>
- <cell align="left" valign="middle">primarykey</cell>
- <cell align="left" valign="middle"><em>switch</em></cell>
- <cell align="left" valign="middle"><em>wstring</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle"><em>double</em></cell>
- <cell align="left" valign="middle"><em>in</em></cell>
- <cell align="left" valign="middle"><em>private</em></cell>
- <cell align="left" valign="middle"><em>TRUE</em></cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <tcaption>OMG IDL keywords</tcaption>
- </table>
- <p>The keywords listed above must be written exactly as shown. Any usage
- of identifiers that collide with a keyword is illegal. For example,
- <em>long</em> is a valid keyword; <em>Long</em> and <em>LONG</em> are
- illegal as keywords and identifiers. But, since the OMG must be able
- to expand the IDL grammar, it is possible to use <em>Escaped Identifiers</em>. For example, it is not unlikely that <c>native</c>
- have been used in IDL-specifications as identifiers. One option is to
- change all occurrences to <c>myNative</c>. Usually, it is necessary
- to change programming language code that depends upon that IDL as well.
- Since Escaped Identifiers just disable type checking (i.e. if it is a reserved
- word or not) and leaves everything else unchanged, it is only necessary to
- update the IDL-specification. To escape an identifier, simply prefix it
- with <em>_</em>. The following IDL-code is illegal:</p>
- <code type="none">
-typedef string native;
-interface i {
- void foo(in native Arg);
- };
-};
- </code>
- <p>With Escaped Identifiers the code will look like:</p>
- <code type="none">
-typedef string _native;
-interface i {
- void foo(in _native Arg);
- };
-};
- </code>
- </section>
-
- <section>
- <title>Type Code Representation</title>
- <marker id="tk_values"></marker>
- <p>Type Codes are used in <c>any</c> values. To avoid mistakes, you should
- use access functions exported by the Data Types modules
- (e.g. struct, union etc) or the <seealso marker="orber_tc">orber_tc</seealso>
- module.</p>
- <table>
- <row>
- <cell align="left" valign="middle"><em>Type Code</em></cell>
- <cell align="left" valign="middle"><em>Example</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_null</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_void</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_short</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_long</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_longlong</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_ushort</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_ulong</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_ulonglong</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_float</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_double</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_boolean</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_char</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_wchar</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_octet</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_any</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_TypeCode</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">tk_Principal</cell>
- <cell align="left" valign="middle"></cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_objref, IFRId, Name}</cell>
- <cell align="left" valign="middle">{tk_objref, "IDL:M1\I1:1.0", "I1"}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_struct, IFRId, Name, [{ElemName, ElemTC}]}</cell>
- <cell align="left" valign="middle">{tk_struct, "IDL:M1\S1:1.0", "S1", [{"a", tk_long}, {"b", tk_char}]}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_union, IFRId, Name, DiscrTC, DefaultNr, [{Label, ElemName, ElemTC}]} <br></br>
-Note: DefaultNr tells which of tuples in the case list that is default, or -1 if no default</cell>
- <cell align="left" valign="middle">{tk_union, "IDL:U1:1.0", "U1", tk_long, 1, [{1, "a", tk_long}, {default, "b", tk_char}]}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_enum, IFRId, Name, [ElemName]}</cell>
- <cell align="left" valign="middle">{tk_enum, "IDL:E1:1.0", "E1", ["a1", "a2"]}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_string, Length}</cell>
- <cell align="left" valign="middle">{tk_string, 5}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_wstring, Length}</cell>
- <cell align="left" valign="middle">{tk_wstring, 7}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_fixed, Digits, Scale}</cell>
- <cell align="left" valign="middle">{tk_fixed, 3, 2}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_sequence, ElemTC, Length}</cell>
- <cell align="left" valign="middle">{tk_sequence, tk_long, 4}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_array, ElemTC, Length}</cell>
- <cell align="left" valign="middle">{tk_array, tk_char, 9}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_alias, IFRId, Name, TC}</cell>
- <cell align="left" valign="middle">{tk_alias, "IDL:T1:1.0", "T1", tk_short}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">{tk_except, IFRId, Name, [{ElemName, ElemTC}]}</cell>
- <cell align="left" valign="middle">{tk_except, "IDL:Exc1:1.0", "Exc1", [{"a", tk_long}, {"b", {tk_string, 0}}]}</cell>
- </row>
- <tcaption>Type Code tuples</tcaption>
- </table>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_ifr.xml b/lib/orber/doc/src/ch_ifr.xml
deleted file mode 100644
index 09302ab6cc..0000000000
--- a/lib/orber/doc/src/ch_ifr.xml
+++ /dev/null
@@ -1,50 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1999</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Interface Repository</title>
- <prepared></prepared>
- <docno></docno>
- <date>1998-10-10</date>
- <rev></rev>
- <file>ch_ifr.xml</file>
- </header>
-
- <section>
- <title>Interface Repository(IFR)</title>
- <p>The IFR is an interface repository built on the Mnesia
- application. Orber uses the IFR for some type-checking
- when coding/decoding IIOP. The IFR is capable of storing all
- interfaces and declarations of OMG IDL.
- </p>
- <p>The interface repository is mainly used for dynamical
- interfaces, and as none are currently supported this function
- is only really used for retrieving information about interfaces.</p>
- <p>Functions relating to the manipulation of the IFR including,
- initialization of the IFR, as well as, locating, creating and
- destroying initial references are detailed further in the Manual
- Pages.
- </p>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_install.xml b/lib/orber/doc/src/ch_install.xml
deleted file mode 100644
index 65faa91ccf..0000000000
--- a/lib/orber/doc/src/ch_install.xml
+++ /dev/null
@@ -1,1001 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1997</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Installing Orber</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>1998-09-28</date>
- <rev></rev>
- <file>ch_install.xml</file>
- </header>
-
- <section>
- <title>Installation Process </title>
- <p>This chapter describes how to install Orber in an Erlang
- Environment.</p>
-
- <section>
- <title>Preparation</title>
- <p>To begin with, you must decide if you want to run Orber as a:</p>
- <list type="bulleted">
- <item><em>Single node (non-distributed)</em> - all communication with other
- Orber instances and ORB's supplied by other vendors use the OMG
- GIOP protocol.</item>
- <item><em>Multi node (distributed)</em> - all Orber nodes, within the same
- <c>domain</c>, communicate via the Erlang distribution protocol.
- For all other Orber instances, i.e. not part of the same <c>domain</c>,
- and ORB's supplied by other vendors, the OMG GIOP protocol
- is used.</item>
- </list>
- <p>Which approach to use is highly implementation specific, but a few
- things you should consider:</p>
- <list type="bulleted">
- <item>All nodes within an Orber domain should have the same
- security level.</item>
- <item>If the capacity is greater than load (volume of traffic)
- a single-node Orber might be a good solution.</item>
- <item>In some cases the distributed system architecture requires a
- single-node <term id="Orber installation"><termdef>is the structure of the ORB or ORBs as defined during the install process is called the "installation".</termdef></term>.</item>
- <item>A multi-node Orber makes it possible to load balance
- and create a more fault tolerant system. The Objects
- can also have a uniform view if you use distributed
- Mnesia tables.</item>
- <item>Since the GIOP protocol creates a larger overhead than the
- Erlang distribution protocol, the performance will be better
- when communicating with Objects within the same Orber domain
- compared with inter ORB communication (GIOP).</item>
- </list>
- <p>You also have to decide if you want Orber to store internal data using
- <c>disc_copies</c> and/or <c>ram_copies</c>. Which storage type you should
- depends if/how you intend to use Mnesia in your application. If you
- intend to use <c>disc_copies</c> you must start with creating a Mnesia
- schema, which contain information about the location of the Erlang nodes
- where Orber is planned to be run. For more background information,
- see the Mnesia documentation.</p>
- <p>In some cases it is absolutely necessary to change the default configuration
- of Orber. For example, if two Orber-ORB's shall be able to communicate
- via GIOP, they must have a unique <c>domain</c> domain. Consult the
- <seealso marker="ch_install#config">configuration settings</seealso>
- section. If you encounter any problems; see the chapter about
- <em>Debugging</em> in this User's Guide.</p>
- </section>
-
- <section>
- <title>Jump Start Orber</title>
- <p>The easiest way to start Orber is to use <c>orber:jump_start(Port)</c>,
- which start a single-node ORB with (most likely) a unique
- domain (i.e. "IP-number:Port"). This function may only be used
- during development and testing. For any other situation, install and
- start Orber as described in the following sections.
- The listen port, i.e. iiop_port configuration parameter, is set to
- the supplied Port.</p>
- <warning>
- <p>How Orber is configured when using <c>orber:jump_start(Port)</c>
- may change at any time without warning. Hence, this operation must
- not be used in systems delivered to a customer.</p>
- </warning>
- </section>
-
- <section>
- <title>Install Single Node Orber</title>
- <p>Since a single node Orber communicate via the OMG GIOP protocol it is not
- necessary to start the Erlang distribution (i.e. using <c>-name/-sname</c>).</p>
- <p>If we use <c>ram_copies</c> there is no need for creating a disk based
- schema. Simply use:</p>
- <code type="erl">
-erl> mnesia:start().
-erl> corba:orb_init([{domain, "MyRAMSingleNodeORB"}]).
-erl> orber:install([node()], [{ifr_storage_type, ram_copies}]).
-erl> orber:start().
- </code>
- <p>If you installation requires <c>disc_copies</c> you must begin with
- creating a Mnesia schema. Otherwise, the installation is similar
- to a RAM installation:</p>
- <code type="erl">
-erl> mnesia:create_schema([node()]).
-erl> mnesia:start().
-erl> corba:orb_init([{domain, "MyDiskSingleNodeORB"}]).
-erl> orber:install([node()], [{ifr_storage_type, disc_copies},
- {nameservice_storage_type, disc_copies}]).
-erl> orber:start().
- </code>
- <p>You can still choose to store the IFR data as ram_copies, but then
- the data must be re-installed (i.e. invoke <c>orber:install/2</c>)
- if the node is restarted. Hence, since the IFR data is rather static
- you should use <c>disc_copies</c>. For more information see the
- <c>orber</c> section in the reference manual.</p>
- <p>If you do not need to change Orber's configuration you can skip
- <seealso marker="corba">orb_init/1</seealso>.
- But, you <em>should</em> at least set the IIOP timeout parameters.</p>
- </section>
-
- <section>
- <title>Install RAM Based Multi Node Orber</title>
- <p>Within a domain Orber uses the Erlang distribution protocol. Hence, you
- <em>must</em> start it first by, for example, using:</p>
- <code type="erl">
-hostA> erl -sname nodeA
- </code>
- <p>In this example, we assume that we want to use two nodes; <c>nodeA</c> and
- <c>nodeB</c>. Since Mnesia must know which other nodes should a part
- of the distribution we either need to add the Mnesia configuration
- parameter <c>extra_db_nodes</c> or use <c>mnesia:change_config/2</c>. To
- begin with, Mnesia must be started on all nodes before we can install
- Orber:</p>
- <code type="erl">
-nodeA@hostA> mnesia:start().
-nodeA@hostA> mnesia:change_config(extra_db_nodes,
- [nodeA@hostA, nodeB@hostB]).
- </code>
- <p>After that the above have been repeated on <c>nodeB</c> we must
- first make sure that both nodes will use the same domain name, then
- we can install Orber:</p>
- <code type="erl">
-nodeA@hostA> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]).
-nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB],
- [{ifr_storage_type, ram_copies}]).
-nodeA@hostA> orber:start().
- </code>
- <p>Note that you can only invoke <c>orber:install/1/2</c> on one of the
- nodes. Now we can start Orber on the other node:</p>
- <code type="erl">
-nodeB@hostB> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]).
-nodeB@hostB> orber:start().
- </code>
- </section>
-
- <section>
- <title>Install Disk Based Multi Node Orber</title>
- <p>As for RAM based multi-node Orber installations, the Erlang distribution
- must be started (e.g. erl -sname nodeA). The major difference is that
- when it is disk based a Mnesia schema must be created:</p>
- <code type="erl">
-nodeA@hostA> mnesia:create_schema([nodeA@hostA, nodeB@hostB]).
-nodeA@hostA> mnesia:start().
- </code>
- <p>In this example, we assume that we want to use two nodes; <c>nodeA</c> and
- <c>nodeB</c>. Since it is not possible to create a schema on more than
- one node. Hence, all we have to do is to start Mnesia (i.e. invoke
- <c>mnesia:start()</c>) on <c>nodeB</c>.</p>
- <p>After Mnesia have been started on all nodes, you must confirm that all
- nodes have the same domain name, then Orber is ready to be installed:</p>
- <code type="erl">
-nodeA@hostA> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]).
-nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB],
- [{ifr_storage_type, disc_copies}]).
-nodeA@hostA> orber:start().
- </code>
- <p>Note that you can only invoke <c>orber:install/1/2</c> on one of the
- nodes. Now we can start Orber on the other node:</p>
- <code type="erl">
-nodeB@hostB> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]).
-nodeB@hostB> orber:start().
- </code>
- </section>
-
- </section>
-
- <section>
- <title>Configuration</title>
- <marker id="config"></marker>
- <p>It is essential that one configure Orber properly, to avoid, for example,
- malicious attacks and automatically terminate IIOP connections no longer
- in use. An easy way to extract information about Orber's configuration
- parameters is to invoke the operation
- <seealso marker="orber">orber:info/1/2</seealso>.
- Orber offer the following configuration parameters:</p>
- <table>
- <row>
- <cell align="center" valign="middle"><em>Key</em></cell>
- <cell align="center" valign="middle"><em>Range</em></cell>
- <cell align="center" valign="middle"><em>Default</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">domain</cell>
- <cell align="left" valign="middle">string()</cell>
- <cell align="left" valign="middle">"ORBER"</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_port</cell>
- <cell align="left" valign="middle">integer() >= 0</cell>
- <cell align="left" valign="middle">4001</cell>
- </row>
- <row>
- <cell align="left" valign="middle">nat_iiop_port</cell>
- <cell align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</cell>
- <cell align="left" valign="middle">The same as <c>iiop_port</c></cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_out_ports</cell>
- <cell align="left" valign="middle">0 | {integer(),integer()}</cell>
- <cell align="left" valign="middle">0</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_out_ports_attempts</cell>
- <cell align="left" valign="middle">integer() > 0</cell>
- <cell align="left" valign="middle">1</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_out_ports_random</cell>
- <cell align="left" valign="middle">true | false</cell>
- <cell align="left" valign="middle">false</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_max_fragments</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_max_in_requests</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_max_in_connections</cell>
- <cell align="left" valign="middle">integer() > 0</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_backlog</cell>
- <cell align="left" valign="middle">integer() > 0</cell>
- <cell align="left" valign="middle">5</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_packet_size</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">ip_address</cell>
- <cell align="left" valign="middle">string() | {multiple, [string()]}</cell>
- <cell align="left" valign="middle">All interfaces</cell>
- </row>
- <row>
- <cell align="left" valign="middle">ip_address_local</cell>
- <cell align="left" valign="middle">string()</cell>
- <cell align="left" valign="middle">Defined by the underlying system</cell>
- </row>
- <row>
- <cell align="left" valign="middle">nat_ip_address</cell>
- <cell align="left" valign="middle">string() | {multiple, [string()]} | {local, string(), [{string(), string()}]}</cell>
- <cell align="left" valign="middle">The same as <c>ip_address</c></cell>
- </row>
- <row>
- <cell align="left" valign="middle">objectkeys_gc_time</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">giop_version</cell>
- <cell align="left" valign="middle">{1,0} | {1,1} | {1,2}</cell>
- <cell align="left" valign="middle">{1,1}</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_setup_connection_timeout</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_connection_timeout</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_in_connection_timeout</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_out_keepalive</cell>
- <cell align="left" valign="middle">true | false</cell>
- <cell align="left" valign="middle">false</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_in_keepalive</cell>
- <cell align="left" valign="middle">true | false</cell>
- <cell align="left" valign="middle">false</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_timeout</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">interceptors</cell>
- <cell align="left" valign="middle">{native, [atom()]}</cell>
- <cell align="left" valign="middle">-</cell>
- </row>
- <row>
- <cell align="left" valign="middle">local_interceptors</cell>
- <cell align="left" valign="middle">{native, [atom()]}</cell>
- <cell align="left" valign="middle">-</cell>
- </row>
- <row>
- <cell align="left" valign="middle">orbInitRef</cell>
- <cell align="left" valign="middle">[string()] | undefined</cell>
- <cell align="left" valign="middle">undefined</cell>
- </row>
- <row>
- <cell align="left" valign="middle">orbDefaultInitRef</cell>
- <cell align="left" valign="middle">string() | undefined</cell>
- <cell align="left" valign="middle">undefined</cell>
- </row>
- <row>
- <cell align="left" valign="middle">orber_debug_level</cell>
- <cell align="left" valign="middle">0 - 10</cell>
- <cell align="left" valign="middle">0</cell>
- </row>
- <row>
- <cell align="left" valign="middle">flags</cell>
- <cell align="left" valign="middle">integer() >= 0</cell>
- <cell align="left" valign="middle">0</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_acl</cell>
- <cell align="left" valign="middle">[{atom(), string()}] | [{atom(), string(), [string()]}]</cell>
- <cell align="left" valign="middle">[]</cell>
- </row>
- <row>
- <cell align="left" valign="middle">secure</cell>
- <cell align="left" valign="middle">no | ssl</cell>
- <cell align="left" valign="middle">no</cell>
- </row>
- <row>
- <cell align="left" valign="middle">ssl_generation</cell>
- <cell align="left" valign="middle">2 | 3</cell>
- <cell align="left" valign="middle">2</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_ssl_port</cell>
- <cell align="left" valign="middle">integer() >= 0</cell>
- <cell align="left" valign="middle">4002</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_ssl_accept_timeout</cell>
- <cell align="left" valign="middle">integer() > 0 | infinity</cell>
- <cell align="left" valign="middle">infinity</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_ssl_backlog</cell>
- <cell align="left" valign="middle">integer() > 0</cell>
- <cell align="left" valign="middle">5</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_ssl_ip_address_local</cell>
- <cell align="left" valign="middle">string()</cell>
- <cell align="left" valign="middle">Defined by the underlying system</cell>
- </row>
- <row>
- <cell align="left" valign="middle">nat_iiop_ssl_port</cell>
- <cell align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</cell>
- <cell align="left" valign="middle">The same as <c>iiop_ssl_port</c></cell>
- </row>
- <row>
- <cell align="left" valign="middle">ssl_server_options</cell>
- <cell align="left" valign="middle">list()</cell>
- <cell align="left" valign="middle">See the <seealso marker="ssl:ssl">SSL application</seealso>
- for valid options.</cell>
- </row>
- <row>
- <cell align="left" valign="middle">ssl_client_options</cell>
- <cell align="left" valign="middle">list()</cell>
- <cell align="left" valign="middle">See the <seealso marker="ssl:ssl">SSL application</seealso>
- for valid options.</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_ssl_out_keepalive</cell>
- <cell align="left" valign="middle">true | false</cell>
- <cell align="left" valign="middle">false</cell>
- </row>
- <row>
- <cell align="left" valign="middle">iiop_ssl_in_keepalive</cell>
- <cell align="left" valign="middle">true | false</cell>
- <cell align="left" valign="middle">false</cell>
- </row>
- <tcaption>Orber Configuration Parameters</tcaption>
- </table>
- <br></br>
- <br></br>
- <p><em>Comments on the table 'Orber Configuration Parameters':</em></p>
- <taglist>
- <tag><em>domain</em></tag>
- <item>Since Orber domains, they are supposed to communicate via IIOP,
- <em>MUST</em> have unique names, communication will
- fail if two domains have the same name. The domain name <em>MAY NOT</em>
- contain <c>^G</c> (i.e. <c>\007</c>).</item>
- <tag><em>iiop_port</em></tag>
- <item>If set to 0 the OS will pick any vacant port.
- <br></br>
-<em>Note:</em>On a UNIX system it is preferable to
- have a IIOP port higher than 1023, since it is not recommended to
- run Erlang as a root user.</item>
- <tag><em>nat_iiop_port</em></tag>
- <item>The value is either an integer or <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>. See also
- <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
- <tag><em>iiop_out_ports</em></tag>
- <item>When set to 0 any available port will be used.
- If a range is specified, Orber will only
- use the local ports within the interval when trying to connect to
- another ORB (Orber acts as a client ORB). If all ports are in use
- communication will fail. Hence, it is <em>absolutely necessary</em> to
- set <c>iiop_connection_timeout</c> as well. Otherwise, connections
- no longer in use will block further communication. If one use, for
- example, <c>erl -orber iiop_out_ports "{5000,5020}"</c>, Orber
- will only use port 5000 to 5020 when connecting.
- If communicating via SSL, make sure you use a version that supports
- the local <c>{port, Port}</c> option. See also
- <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
- <tag><em>iiop_out_ports_random</em></tag>
- <item>Requires that <c>iiop_out_ports</c> define a port range. If that is the
- case Orber will select a port randomly from that sequence.</item>
- <tag><em>iiop_out_ports_attempts</em></tag>
- <item>Requires that <c>iiop_out_ports</c> define a port range. If so Orber will
- accept a number of timeouts, defined by this parameter, when trying to connect
- to another ORB.</item>
- <tag><em>iiop_max_fragments</em></tag>
- <item>Limits the number of IIOP fragments allowed per request.</item>
- <tag><em>iiop_max_in_requests</em></tag>
- <item>Limits the number of concurrent incoming requests per incoming connection.</item>
- <tag><em>iiop_max_in_connections</em></tag>
- <item>Limits the number of concurrent incoming connections.</item>
- <tag><em>iiop_backlog</em></tag>
- <item>Defines the maximum length the queue of pending incoming
- connections may grow to.</item>
- <tag><em>iiop_packet_size</em></tag>
- <item>Defines the maximum size of incoming requests.
- If this limit is exceeded, the connection is closed.</item>
- <tag><em>ip_address</em></tag>
- <item>This option is used if orber only should
- listen on a specific ip interface on a multi-interface host or if
- exported IOR:s should contain multiple components. The value is
- the IPv4 or IPv6 address as a string or <c>{multiple, IPList}</c>.
- The latter requires that the object is available via the all IP addresses
- found in the list.</item>
- <tag><em>ip_address_local</em></tag>
- <item>This option defines the default local interface Orber will
- use when connecting to another ORB via IIOP, i.e., Orber act as the
- client side ORB. The value is a IPv4 or IPv6 address as a string.
- It is possible to override <c>ip_address_local</c> by defining
- <c>iiop_acl</c> or passing the Orber generic <c>interface</c> Context.
- If this option is not used, the underlying OS will choose which interface to
- use. For more information, see the
- <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
- section.</item>
- <tag><em>nat_ip_address</em></tag>
- <item>The value is the ip address as
- a string (IPv4 or IPv6), <c>{multiple, IPList}</c> or
- <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c>. See also
- <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
- <tag><em>objectkeys_gc_time</em></tag>
- <item>This option should be set if objects are started
- using the option <c>{persistent, true}</c>.
- The value is <c>integer()</c> seconds.</item>
- <tag><em>giop_version</em></tag>
- <item>Defines the default GIOP protocol version.</item>
- <tag><em>iiop_setup_connection_timeout</em></tag>
- <item>The value is an integer (seconds) or the atom infinity.
- This option is only valid for client-side
- connections. If this option is set, attempts to connect to other ORB's
- will timeout after the given time limit. Note, if the time limit is large
- the TCP protocol may timeout before the supplied value.</item>
- <tag><em>iiop_connection_timeout</em></tag>
- <item>The value is an integer (timeout in seconds between 0 and 1000000)
- or the atom infinity. This option is only valid for client object
- connections, i.e., will have no effect on server connections. Setting this
- option will cause client connections to be terminated, if and only if,
- there are no pending requests. If there are a client still waiting for
- a reply, Orber will try again after the given seconds have passed. The main
- purpose for this option is to reduce the number of open connections; it is,
- for example, not necessary to keep a connection, only used once a day,
- open at all time.</item>
- <tag><em>iiop_in_connection_timeout</em></tag>
- <item>The same as for <c>iiop_connection_timeout</c>. The only difference is
- that this option only affects incoming connections (i.e. Orber act as
- server-side ORB).</item>
- <tag><em>iiop_out_keepalive</em></tag>
- <item>Enables periodic transmission on a connected socket, when no other
- data is being exchanged. If the other end does not respond, the
- connection is considered broken and will be terminated.
- When enabled the SO_KEEPALIVE socket level option is set.</item>
- <tag><em>iiop_in_keepalive</em></tag>
- <item>The same as for <c>iiop_out_keepalive</c>. The only difference is
- that this option only affects incoming connections.</item>
- <tag><em>iiop_timeout</em></tag>
- <item>The value is an integer (timeout in seconds between 0 and 1000000)
- or the atom infinity. This option is only valid on the client side.
- Setting this option, cause all intra-ORB requests to timeout and
- raise a system exception, e.g. <c>TIMEOUT</c>, if no replies are delivered
- within the given time limit.</item>
- <tag><em>interceptors</em></tag>
- <item>If one set this parameter, e.g.,
- <c>erl -orber interceptors "{native, ['myInterceptor']}"</c>,
- Orber will use the supplied interceptor(s) for all inter-ORB
- communication. <c>'myInterceptor'</c> is the module name of the
- interceptor. For more information, see the interceptor chapter
- in the User's Guide and the Reference Manual.</item>
- <tag><em>local_interceptors</em></tag>
- <item>If defined, its value will be
- used when activating local interceptors via
- <seealso marker="ch_install#flags">Orber Environment Flags</seealso>.
- If not defined, but the flag is set, Orber will use the value of
- the <c>interceptors</c> parameter.</item>
- <tag><em>orbInitRef</em></tag>
- <item>Setting this option, e.g.,
- <c>erl -orber orbInitRef [\"NameService=corbaloc::host.com/NameService\"]</c>,
- will alter the location from where <c>corba:resolve_initial_references(Key)</c>
- tries to find an object matching the given Key. The keys will also appear when
- invoking <c>corba:list_initial_services()</c>. This variable overrides
- <c>orbDefaultInitRef</c></item>
- <tag><em>orbDefaultInitRef</em></tag>
- <item>If a matching Key for <c>orbInitRef</c> is not
- found, and this variable is set, it determines the location from where
- <c>orber:resolve_initial_references(Key)</c> tries to find an object
- matching the given Key. Usage:
- <c>erl -orber orbDefaultInitRef \"corbaloc::host.com\"</c>.</item>
- <tag><em>orber_debug_level</em></tag>
- <item>The range is 0 to 10.
- Using level 10 is the most verbose configuration.
- This option will generate reports, using the <c>error_logger</c>,
- for abnormal situations. It is not recommended to use this option
- for delivered systems since some of the reports is not to be considered
- as errors. The main purpose is to assist during development.</item>
- <tag><em>flags</em></tag>
- <item>No flags are activated in the default case.
- The available configuration settings are described in
- <seealso marker="ch_install#flags">Orber Environment Flags</seealso>.</item>
- <tag><em>iiop_acl</em></tag>
- <item>This option must be activated by setting
- <seealso marker="ch_install#flags">Orber Environment Flags</seealso> parameter.
- The value of this parameter shall be a list of <c>[{Direction, Filter}]</c>
- and/or <c>[{Direction, Filter, [Interfaces]}]</c>. The <c>Direction</c>,
- <c>tcp_in</c>, <c>ssl_in</c>, <c>tcp_out</c> or <c>ssl_out</c>, determines if
- the Access Control List (ACL) applies to incoming or outgoing connections
- and IIOP or IIOP over SSL. The <c>Filter</c> uses a extended format of
- Classless Inter Domain Routing (CIDR). For example, <c>"123.123.123.10"</c> limits
- the connection to that particular host, while <c>"123.123.123.10/17"</c> allows
- connections to or from any host equal to the 17 most significant bits. Orber
- also allow the user to specify a certain port or port range, for example,
- <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c>
- respectively. IPv4 or none compressed IPv6 strings are accepted. <br></br>
-
- The list of <c>Interfaces</c>, IPv4 or IPv6 strings, may only contain
- <em>one</em> address for outgoing connections. For incoming connections,
- the <c>Interfaces</c> list may contain several IP strings. If set for
- outgoing connections, and access is granted, Orber will use that local
- interface when connecting to the server-side ORB. For incoming connections,
- the client-side ORB is required to use one of the listed interfaces locally.
- If it fail to do so, access will be denied. The module
- <seealso marker="orber_acl">orber_acl</seealso> provides operations for
- evaluating the access control for filters and addresses. See also the
- <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
- and
- <seealso marker="ch_install#firewall">Firewall Configuration</seealso>
- chapters.</item>
- <tag><em>secure</em></tag>
- <item>Determines the security mode Orber will use, which is either
- <c>no</c> if it is an insecure domain or the type of security
- mechanism used. Currently, per default, Orber is compliant with
- <c>CSIv1</c> level 0, which means IIOP via SSL/TLS.
- The security chapter later in this manual describes how to get security
- in Orber and how the options are used.</item>
- <tag><em>ssl_generation</em></tag>
- <item>Defines which SSL version, i.e. available API, is installed. The
- default value, <c>2</c>, refers to SSL-3.1 or later, but earlier than SSL-4.0.
- If set to <c>3</c> SSL-4.0, or later, must be available. Currently it not possible
- to use <c>1</c>, it is only reserved for future use.</item>
- <tag><em>iiop_ssl_port</em></tag>
- <item>If set, the value must be an
- integer greater than zero and not equal to <em>iiop_port</em>.</item>
- <tag><em>iiop_ssl_accept_timeout</em></tag>
- <item>The value is an integer (timeout in seconds) or the atom infinity and
- determine how long the SSL handshake may take. This option should
- be set to avoid if a client never initiate the handshake.</item>
- <tag><em>iiop_ssl_backlog</em></tag>
- <item>Defines the maximum length the queue of pending incoming
- connections may grow to.</item>
- <tag><em>iiop_ssl_ip_address_local</em></tag>
- <item>This option defines the default local interface Orber will
- use when connecting to another ORB via IIOP SSL, i.e., Orber act as the
- client side ORB. The value is a IPv4 or IPv6 address as a string.
- It is possible to override <c>iiop_ssl_ip_address_local</c> by defining
- <c>iiop_acl</c> or passing the Orber generic <c>interface</c> Context.
- If this option is not used, the underlying OS will choose which interface to
- use. For more information, see the
- <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
- section.</item>
- <tag><em>nat_iiop_ssl_port</em></tag>
- <item>If set, the value must be an integer greater than zero or
- <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>. See also
- <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
- <tag><em>ssl_server_options</em></tag>
- <item>A list of the SSL options when Orber is the server.
- In general it's just to remove the 'ssl_server_' prefix from the old options,
- i.e. <c>ssl_server_verify</c> will just be <c>verify</c> in this option list.
- See the <seealso marker="ssl:ssl">SSL application</seealso> for the correct list of possible
- options and their values.
- </item>
- <tag><em>ssl_client_options</em></tag>
- <item>A list of the SSL options when Orber is the client.
- In general it's just to remove the <c>ssl_client_</c> prefix from the old options,
- i.e. <c>ssl_client_depth</c> will just be <c>depth</c> in this option list.
- See the <seealso marker="ssl:ssl">SSL application</seealso> for the correct list of possible
- options and their values.
- </item>
- <tag><em>iiop_ssl_out_keepalive</em></tag>
- <item>Enables periodic transmission on a connected socket, when no other
- data is being exchanged. If the other end does not respond, the
- connection is considered broken and will be terminated.
- When enabled the SO_KEEPALIVE socket level option is set. Requires that
- the installed SSL version support the <em>keepalive</em> option
- and that the <em>ssl_generation</em> points to this version.</item>
- <tag><em>iiop_ssl_in_keepalive</em></tag>
- <item>The same as for <c>iiop_ssl_out_keepalive</c>. The only difference is
- that this option only affects incoming connections.</item>
- </taglist>
- <p>It is possible to invoke operations using the extra timeout parameter:</p>
- <pre>
-erl> module_interface:function(ObjRef, Timeout, ..Arguments..).
-erl> module_interface:function(ObjRef, [{timeout, Timeout}], ..Arguments..).
-erl> module_interface:function(ObjRef, ..Arguments..). </pre>
- <p>The extra Timeout argument will override the configuration parameter
- <c>iiop_timeout</c>. It is, however, not possible to use <c>infinity</c>
- to override the Timeout parameter. The Timeout option is also valid for
- objects which resides within the same <term id="Orber domain"><termdef>A domain containing several Erlang nodes, which are communicating by using the Erlang internal format. An Orber domain looks as one ORB from the environment.</termdef></term>.</p>
- <p>The <c>iiop_setup_connection_timeout</c>, <c>iiop_timeout</c>,
- <c>iiop_connection_timeout</c> and <c>iiop_in_connection_timeout</c>
- variables should be used. The specified values is implementation specific,
- i.e., WAN or LAN, but they should range from
- <c>iiop_setup_connection_timeout</c> to <c>iiop_connection_timeout</c>.</p>
- <p>To change these settings in the configuration file, the
- <c>-config</c> flag must be added to the erl command. See the
- Reference Manual
- <em>config(4)</em> for further information. The values can also
- be sent separately as
- options to the Erlang node when it is started, see the Reference
- Manual
- <em>erl(1)</em> for further information. </p>
-
- <section>
- <marker id="flags"></marker>
- <title>Orber Environment Flags</title>
- <p>The <c>Environment Flags</c> allows the user to activate debugging
- facilities or change Orber's behavior. The latter may result in that
- Orber is no longer compliant with the OMG standard, which may be necessary
- when communicating with a non-compliant ORB.</p>
- <table>
- <row>
- <cell align="left" valign="middle"><em>Hexadecimal Value</em></cell>
- <cell align="left" valign="middle"><em>OMG Compliant</em></cell>
- <cell align="left" valign="middle"><em>Description</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">0001</cell>
- <cell align="left" valign="middle">no</cell>
- <cell align="left" valign="middle">Exclude CodeSet Component</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0002</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Local Typechecking</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0004</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Use Host Name in IOR</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0008</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Enable NAT</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0020</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Local Interceptors</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0080</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Light IFR</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0100</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Use IPv6</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0200</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">EXIT Tolerance</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0400</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Enable Incoming ACL</cell>
- </row>
- <row>
- <cell align="left" valign="middle">0800</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Enable Outgoing ACL</cell>
- </row>
- <row>
- <cell align="left" valign="middle">1000</cell>
- <cell align="left" valign="middle">yes</cell>
- <cell align="left" valign="middle">Use Current Interface in IOR</cell>
- </row>
- <tcaption>Orber Environment Flags</tcaption>
- </table>
- <p>Any combination of the flags above may be used and changes the
- behavior as follows:</p>
- <list type="bulleted">
- <item><em>Exclude CodeSet Component</em> - instruct Orber to exclude
- the CodeSet component in exported IOR:s. When activated, no
- negotiating regarding character and wide character conversions
- between the client and the server will occur. This flag will,
- most likely, cause problems if your IDL specification contains
- the data types wchar and/or wstring.</item>
- <item><em>Local Typechecking</em> -
- If activated, parameters, replies and raised exceptions
- will be checked to ensure that the data is correct. If an error
- occurs, the <c>error_logger</c> is used to generate reports.
- One <em>MAY NOT</em> use this option for delivered systems due
- to the extra overhead. Since this option activates typechecking
- for all objects generated on the target node, it is also possible
- to use the option <c>{local_typecheck, boolean()}</c>, when
- invoking <c>oe_create/2</c>, <c>oe_create_link/2</c>,
- <c>corba:create/4</c> or <c>corba:create_link/4</c>, to override
- the configuration parameter.</item>
- <item><em>Use Host Name in IOR</em> - normally Orber inserts the IP-number
- in IOR:s when they are exported. In some cases, this will cause
- the clients to open two connections instead of one.</item>
- <item><em>Enable NAT</em> - if this flag is set, it is possible to use
- the NAT (Network Address Translation) configuration parameters
- (<c>nat_iiop_port</c>, <c>nat_iiop_ssl_port</c> and
- <c>nat_ip_address</c>).</item>
- <item><em>Local Interceptors</em> - use interceptors for local
- invocations.</item>
- <item><em>Light IFR</em> - if the IFR is not explicitly used and this
- flag is set, Orber will use a minimal IFR to reduce memory usage
- and installation time.</item>
- <item><em>Use IPv6</em> - when this option is activated, Orber will use
- <c>IPv6</c> for inter-ORB communication.</item>
- <item><em>EXIT Tolerance</em> - servers will survive even though the
- call-back module caused an EXIT.</item>
- <item><em>Enable Incoming ACL</em> - activates access control for incoming
- connections.</item>
- <item><em>Enable Outgoing ACL</em> - activates access control for outgoing
- connections.</item>
- <item><em>Use Current Interface in IOR</em> - when set, Orber will add
- the interface the request came via to exported local IOR:s.</item>
- </list>
- <p>Invoking the operation
- <seealso marker="orber">orber:info/1/2</seealso> will display the currently
- set flags in a readable way.</p>
- </section>
- </section>
-
- <section>
- <title>Firewall Configuration</title>
- <marker id="firewall"></marker>
- <p>Firewalls are used to protect objects from clients in other networks or
- sub-networks, but also to restrict which hosts internal objects may connect to
- (i.e. <c>inbound protection</c> and <c>outbound protection</c>). A firewall
- can limit access based on:</p>
- <list type="bulleted">
- <item><em>Transport Level</em> - performs access control decisions based on
- address information in TCP headers.</item>
- <item><em>Application Level</em> - understands GIOP messages and the specific
- transport level inter-ORB Protocol supported e.g. IIOP.</item>
- </list>
- <p>This section describes how to configure a <c>Transport Level</c> firewall. It
- must have prior knowledge of the source to destination mappings, and
- conceptually has a configuration table containing tuples of the form:
- <c>({inhost:inport}, {outhost:outport})</c>. If there are no port restrictions
- it is rather easy to configure the firewall. Otherwise, we must consider the
- following alternatives:</p>
- <list type="bulleted">
- <item><em>Incoming Requests</em> - Orber only uses the port-numbers specified
- by the configuration parameters <em>iiop_port</em> and
- <em>iiop_ssl_port</em>. Other ORB's may use several ports but it should
- be possible to change this behavior. Consult the other ORBs
- documentation.</item>
- <item><em>Outgoing Requests</em> - Most ORB's, Orber included,
- ask the OS to supply a vacant local port when connecting to the
- server-side ORB. It is possible to change this behavior when using
- Orber (i.e. set the configuration parameter <em>iiop_out_ports</em>).</item>
- </list>
- <warning>
- <p>Using the option <c>iiop_out_ports</c> may result in that Orber runs out of
- valid ports numbers. For example, other applications may steal some of the
- ports or the number of concurrent outgoing connections to other ORBs may be
- higher than expected. To reduce, but not eliminate, the risk you should use
- <c>iiop_connection_timeout</c>.</p>
- </warning>
- <p>Firewall configuration example:</p>
- <pre>
-# "Plain" IIOP
-To: Orber-IPNo:(iiop_port) From: ORB-IPNo:X
-To: ORB-IPNo:Z From: Orber-IPNo:(iiop_out_ports | Any Port)
-
-# IIOP via SSL
-To: Orber-IPNo:(iiop_port) From: ORB-IPNo:X
-To: Orber-IPNo:(iiop_ssl_port) From: ORB-IPNo:Y
-To: ORB-IPNo:Z From: Orber-IPNo:(iiop_out_ports | Any Port)
- </pre>
- <p>If the communication take place via a
- <seealso marker="ch_install#firewall_nat">TCP Firewall with NAT</seealso>
- (Network Address Translation), we must activate this behavior and define
- the external address and/or ports.</p>
- <marker id="firewall_nat"></marker>
- <image file="firewall_nat.gif">
- <icaption>
-TCP Firewall With NAT</icaption>
- </image>
- <p>Using NAT makes it possible to use different host data for different network
- domains. This way we can share Internet Protocol address resources or
- obscure resources. To enable this feature the
- <seealso marker="ch_install#flags">Enable NAT</seealso> flag must be set and
- <c>nat_iiop_port</c>, <c>nat_iiop_ssl_port</c> and <c>nat_ip_address</c>
- configured, which maps to <c>iiop_port</c>, <c>iiop_ssl_port</c> and
- <c>ip_address</c> respectively. Hence, the firewall must be configured to
- translate the external to the internal representation correctly. If these NAT parameters
- are assigned a single port number or IP address, only those will be used when
- an IOR is exported to another ORB. When <c>ip_address</c> is set to
- <c>{multiple, [IPAddress]}</c>, <c>nat_ip_address</c> should be configured in the same
- way, so that each NAT IP address can be translated to a valid address by the firewall.
- If objects are supposed to be accessible via different interfaces and port, see also
- <seealso marker="ch_install#interfaces">Interface Configuration</seealso>,
- the options <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c> and/or
- <c>{local, DefaultNATPort, [{Port, NATPort}]}</c> shall be used. The default NAT IP address
- and port, should be translated to the value of <c>ip_address_local</c> and the default
- listen port by the firewall. If the IP address and/or port is not found in the list,
- the default values will be inserted in the IOR. The firewall must be able to translate
- these correctly.</p>
- <p>If it is necessary to limit the access to an ORB within a secure network,
- but other applications running on the same host may not be blocked out,
- one can use a <em>Application Level</em> firewall or Orber Access Control
- List (ACL). The latter makes it possible for the user to define which hosts
- may communicate, either as server or client, with Orber. This is achieved by
- defining the configuration parameter
- <seealso marker="ch_install#config">iiop_acl</seealso>. The Classless Inter
- Domain Routing (CIDR) <c>Filter</c> determines which peer interfaces and
- ports the other ORB may use.</p>
- <table>
- <row>
- <cell align="left" valign="middle"><em>Filter</em></cell>
- <cell align="left" valign="middle"><em>Peer Interface(s)</em></cell>
- <cell align="left" valign="middle"><em>Peer Port(s)</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">"10.1.1.1"</cell>
- <cell align="left" valign="middle">10.1.1.1</cell>
- <cell align="left" valign="middle">any</cell>
- </row>
- <row>
- <cell align="left" valign="middle">"10.1.1.1/8"</cell>
- <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
- <cell align="left" valign="middle">any</cell>
- </row>
- <row>
- <cell align="left" valign="middle">"10.1.1.1/8#4001"</cell>
- <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
- <cell align="left" valign="middle">4001</cell>
- </row>
- <row>
- <cell align="left" valign="middle">"10.1.1.1/8#4001/5001"</cell>
- <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
- <cell align="left" valign="middle">4001-5001</cell>
- </row>
- <tcaption>Orber ACL Filters</tcaption>
- </table>
- <p>Orber ACL, also allows the user to define which local interface(s) may be used,
- but will not detect <c>spoofing</c>. The operation
- <seealso marker="orber_acl">orber_acl:match/2/3</seealso> makes it easy to
- verify whether access would be granted or not. For example, if Orber would
- be started with the ACL <c>[{tcp_out, "10.1.1.1/8#4001/5001"}]</c>, then
- <c>orber_acl:match/2</c> would behave as follows:</p>
- <code type="erl">
-erl> orber_acl:match({11,1,1,1}, tcp_out).
-false
-
-erl> orber_acl:match({10,1,1,1}, tcp_out).
-true
-
-erl> orber_acl:match({11,1,1,1}, tcp_out, true).
-{false,[],0}
-
-erl> orber_acl:match({10,1,1,1}, tcp_out, true).
-{true,[],{4001,5001}}
- </code>
- <p>Only if the returned boolean is true the extra return values makes a
- difference. In the example above, <c>{true,[],{4001,5001}}</c> means that
- Orber may connect to <c>"10.1.1.1"</c>, using any local interface,
- if the server-side ORB listens for incoming connect requests on a port
- within the range 4001-5001. Note, invoking the <c>orber_acl:match/2/3</c>
- operation, will not result in a connect attempt by Orber. The reason for
- this, is that this function may be used on a live node as well as in test
- environment. Hence, if a local interface is currently not available or no
- server-side ORB available via the given host/port(s), will not be detected
- by Orber.</p>
- </section>
-
- <section>
- <title>Interface Configuration</title>
- <marker id="interfaces"></marker>
- <p>In many cases it is sufficient to simply configure the underlying OS which
- local interfaces shall be used for all applications. But, in some cases
- it is required, due to, for example, the firewall configuration, that different
- local interfaces are used for different applications. Some times, it is even
- necessary to use a specific interface for a single CORBA object. This section
- describe how one can alter this in different ways.</p>
- <p>The default behavior is that Orber lets the OS configuration decide which interface
- will be added in IOR:s exported to another ORB and the local interface used
- when connecting to another ORB (Orber act as client side ORB). The latter can be
- overridden by setting the configuration parameters <c>iiop_ssl_ip_address_local</c>
- and/or <c>ip_address_local</c>, which will affect IIOP via SSL and IIOP
- respectively. These parameters can be overridden by using the Orber generic
- <c>interface</c> Context or defining an ACL (Access Control List). The latter
- always takes precedence if a local interface is included (e.g.
- <c>[{tcp_out, "10.0.0.0/8", ["10.0.0.1"]}]</c>). If the interface is excluded
- (e.g. <c>[{tcp_out, "10.0.0.0/8"}]</c>), the interface chosen will, in the following
- order, be determined by
- <c>#'IOP_ServiceContext'{}</c>, <c>ip_address_local/iiop_ssl_ip_address_local</c> or
- the configuration of the underlying system.</p>
- <p>Adding the interface context, for generated stubs/skeletons, is done in the
- following way:</p>
- <code type="erl">
-Ctx = #'IOP_ServiceContext'{context_id = ?ORBER_GENERIC_CTX_ID,
- context_data = {interface, "10.0.0.1"}},
-'CosNaming_NamingContext':resolve(NS, [{context, [Ctx]}], Name),
- </code>
- <p>It is also possible to add the context to
- <c>corba:string_to_object/2, corba:resolve_initial_references/2, corba:resolve_initial_references_remote/3, corba:list_initial_services_remote/2, corba_object:not_existent/2, corba_object:non_existent/2</c> and <c>corba_object:is_a/3</c>.
- The operations exported by <c>corba_object</c> are affected
- if the supplied IOR is external. The function <c>corba:string_to_object/2</c>
- might require the interface context if a <c>corbaloc</c> or a <c>corbaloc</c>
- string is passed (See the
- <seealso marker="ch_naming_service#interop_ns">INS</seealso> chapter),
- while <c>corba:resolve_initial_references_remote/3</c> and
- <c>corba:list_initial_services_remote/2</c> always connect to another ORB and
- it might be necessary to add the context.
- The remaining <c>corba</c> operations are affected if calls are re-directed
- by setting the <c>orbInitRef</c> and/or <c>orbDefaultInitRef</c> configuration
- parameters. For more information, see the Reference Manual for each module.</p>
- <p>Configuring which interface(s) that shall be used when exporting an IOR to
- another ORB, is determined by <c>nat_ip_address</c>, setting the flag
- <seealso marker="ch_install#flags">16#1000</seealso>
- and <c>ip_address</c>, in that order. Orber listens for incoming connections
- either via all interfaces or the interface defined by <c>ip_address</c>. It is
- also possible to add and remove extra listen interfaces by using
- <c>orber:add_listen_interface/2/3</c> and <c>orber:remove_listen_interface/1</c>.
- In this case one should set the 16#1000 flag and, if necessary, set the
- configuration parameters
- <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c> and/or
- <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>.</p>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_interceptors.xml b/lib/orber/doc/src/ch_interceptors.xml
deleted file mode 100644
index 4a9f8e69ca..0000000000
--- a/lib/orber/doc/src/ch_interceptors.xml
+++ /dev/null
@@ -1,278 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>2001</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Orber Interceptors</title>
- <prepared>Nick</prepared>
- <docno></docno>
- <date>2001-08-16</date>
- <rev></rev>
- <file>ch_interceptors.xml</file>
- </header>
-
- <section>
- <title>Using Interceptors</title>
- <p>For Inter-ORB communication, e.g., via <c>IIOP</c>, it is possible
- to intercept requests and replies. To be able to use <c>Interceptors</c>
- Orber the configuration parameter <c>interceptors</c> must be defined.</p>
-
- <section>
- <title>Configure Orber to Use Interceptors</title>
- <p>The configuration parameter <c>interceptors</c> must be defined, e.g.,
- as command line option:</p>
- <code type="none">
-erl -orber interceptors "{native, ['myInterceptor']}"
- </code>
- <p>It is possible to use more than one interceptor; simply add them to the
- list and they will be invoked in the same order as they appear in the list.</p>
- <p>One can also active and deactivate an interceptor during
- run-time, but this will only affect currently existing connections.
- For more information, consult Orber's Reference Manual regarding the
- operations <c>orber:activate_audit_trail/0/1</c> and
- <c>orber:activate_audit_trail/0/1.</c></p>
- </section>
-
- <section>
- <title>Creating Interceptors</title>
- <p>Each supplied interceptor <em>must</em> export the following functions:</p>
- <list type="bulleted">
- <item><em>new_out_connection/3/5</em> - one of these operations is called when
- a client application calls an object residing on remote ORB.
- If an interceptor exports both versions, arity 3 and 5, which
- operation that will be invoked is Orber internal.</item>
- <item><em>new_in_connection/3/5</em> - one of these operations is invoked
- when a client side ORB tries to set up a connection to the target ORB.
- If an interceptor exports both versions, arity 3 and 5, which
- operation that will be invoked is Orber internal.</item>
- <item><em>out_request/6</em> - supplies all request data on the client side
- ORB.</item>
- <item><em>out_request_encoded/6</em> - similar to <c>out_request</c>
- but the request body is encode.</item>
- <item><em>in_request_encoded/6</em> - after a new request arrives at the
- target ORB the request data is passed to the interceptor in
- encoded format.</item>
- <item><em>in_request/6</em> - prior to invoking the operation on the
- target object, the interceptor <c>in_request</c> is called.</item>
- <item><em>out_reply/6</em> - after the target object replied the
- <c>out_reply</c> operation is called with the result of the object
- invocation.</item>
- <item><em>out_reply_encoded/6</em> - before sending a reply back to the
- client side ORB this operation is called with the result in
- encoded format.</item>
- <item><em>in_reply_encoded/6</em> - after the client side ORB receives
- a reply this function is called with the reply in encoded
- format.</item>
- <item><em>in_reply/6</em> - before delivering the reply to the client
- this operation is invoked.</item>
- <item><em>closed_in_connection/1</em> - when a connection is terminated
- on the client side this function is called.</item>
- <item><em>closed_out_connection/1</em> - if an outgoing connection is
- terminated this operation will be invoked.</item>
- </list>
- <p>The operations <c>new_out_connection</c>, <c>new_in_connection</c>,
- <c>closed_in_connection</c> and <c>closed_out_connection</c> operations
- are only invoked <em>once</em> per connection. The remaining operations
- are called, as shown below, for every Request/Reply to/from remote
- CORBA Objects.</p>
- <marker id="interceptor_operations"></marker>
- <image file="interceptor_operations.gif">
- <icaption>
-The Invocation Order of Interceptor Functions.</icaption>
- </image>
- </section>
- </section>
-
- <section>
- <title>Interceptor Example</title>
- <p>Assume we want to create a simple access service which purpose is to:</p>
- <list type="bulleted">
- <item>Only allow incoming request from ORB's residing on a certain set of
- nodes.</item>
- <item>Restrict the objects any client may invoke operations on.</item>
- <item>Only allow outgoing requests to call a limited set of external
- ORB's.</item>
- <item>Add a checksum to each binary request/reply body.</item>
- </list>
- <p>To restricts the access we use a <c>protected</c> and <c>named</c> ets-table
- holding all information. How the ets-table is initiated and maintained
- is implementation specific, but it contain
- <c>{Node, ObjectTable, ChecksumModule}</c> where <c>Node</c> is used as
- ets-key, <c>ObjectTable</c> is a reference to another ets-table in which
- we store which objects the clients are allowed to invoke operations on
- and <c>ChecksumModule</c> determines which module we should use to handle
- the checksums. </p>
- <code type="erl">
-new_in_connection(Arg, Host, Port) ->
- %% Since we only use one interceptor we do not care about the
- %% input Arg since it is set do undefined by Orber.
- case ets:lookup(in_access_table, Host) of
- [] ->
- %% We may want to log the Host/Port to see if someone tried
- %% to hack in to our system.
- exit("Access not granted");
- [{Host, ObjTable, ChecksumModule}] ->
- {ObjTable, ChecksumModule}
- end.
- </code>
- <p>The returned tuple, i.e., {ObjTable, ChecksumModule}, will be passed
- as the first argument whenever invoking one of the interceptor functions.
- Unless the connection attempt did not fail we are now ready for receiving
- requests from the client side ORB.</p>
- <p>When a new request comes in the first interceptor function to be invoked is
- <c>in_request_encoded</c>. We will remove the checksum from the coded
- request body in the following way:</p>
- <code type="erl">
-in_request_encoded({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
- NewBin = ChecksumModule:remove_checksum(Bin),
- {NewBin, Extra}.
- </code>
- <p>If the checksum check fails the <c>ChecksumModule</c> should invoke exit/1.
- But if the check succeeded we are now ready to check if the client-ORB
- objects are allowed to invoke operations on the target object. Please note,
- it is possible to run both checks in <c>in_request_encoded</c>. Please
- note, the checksum calculation must be relatively fast to ensure a
- good throughput.</p>
- <p>If we want to we can restrict any clients to only use a subset of operations
- exported by a server:</p>
- <code type="erl">
-in_request({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Params, Extra) ->
- case ets:lookup(ObjTable, {ObjKey, Op}) of
- [] ->
- exit("Client tried to invoke illegal operation");
- [SomeData] ->
- {Params, Extra}
- end.
- </code>
- <p>At this point Orber are now ready to invoke the operation on the target
- object. Since we do not care about what the reply is the <c>out_reply</c>
- function do nothing, i.e.:</p>
- <code type="erl">
-out_reply(_, _, _, _, Reply, Extra) ->
- {Reply, Extra}.
- </code>
- <p>If the client side ORB expects a checksum to be added to the reply we
- add it by using:</p>
- <code type="erl">
-out_reply_encoded({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
- NewBin = ChecksumModule:add_checksum(Bin),
- {NewBin, Extra}.
- </code>
- <warning>
- <p>If we manipulate the binary as above the behavior <em>must</em>
- be <c>Bin == remove_checksum(add_checksum(Bin))</c>.</p>
- </warning>
- <p>For outgoing requests the principle is the same. Hence, it is not further
- described here. The complete interceptor module would look like:</p>
- <code type="erl">
--module(myInterceptor).
-
-%% Interceptor functions.
--export([new_out_connection/3,
- new_in_connection/3,
- closed_in_connection/1,
- closed_out_connection/1,
- in_request_encoded/6,
- in_reply_encoded/6,
- out_reply_encoded/6,
- out_request_encoded/6,
- in_request/6,
- in_reply/6,
- out_reply/6,
- out_request/6]).
-
-new_in_connection(Arg, Host, Port) ->
- %% Since we only use one interceptor we do not care about the
- %% input Arg since it is set do undefined by Orber.
- case ets:lookup(in_access_table, Host) of
- [] ->
- %% We may want to log the Host/Port to see if someone tried
- %% to hack in to our system.
- exit("Access not granted");
- [{Host, ObjTable, ChecksumModule}] ->
- {ObjTable, ChecksumModule}
- end.
-
-new_out_connection(Arg, Host, Port) ->
- case ets:lookup(out_access_table, Host) of
- [] ->
- exit("Access not granted");
- [{Host, ObjTable, ChecksumModule}] ->
- {ObjTable, ChecksumModule}
- end.
-
-in_request_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
- NewBin = ChecksumModule:remove_checksum(Bin),
- {NewBin, Extra}.
-
-in_request({ObjTable, _}, ObjKey, Ctx, Op, Params, Extra) ->
- case ets:lookup(ObjTable, {ObjKey, Op}) of
- [] ->
- exit("Client tried to invoke illegal operation");
- [SomeData] ->
- {Params, Extra}
- end.
-
-out_reply(_, _, _, _, Reply, Extra) ->
- {Reply, Extra}.
-
-out_reply_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
- NewBin = ChecksumModule:add_checksum(Bin),
- {NewBin, Extra}.
-
-out_request({ObjTable, _}, ObjKey, Ctx, Op, Params, Extra) ->
- case ets:lookup(ObjTable, {ObjKey, Op}) of
- [] ->
- exit("Client tried to invoke illegal operation");
- [SomeData] ->
- {Params, Extra}
- end.
-
-out_request_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
- NewBin = ChecksumModule:add_checksum(Bin),
- {NewBin, Extra}.
-
-in_reply_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
- NewBin = ChecksumModule:remove_checksum(Bin),
- {NewBin, Extra}.
-
-in_reply(_, _, _, _, Reply, Extra) ->
- {Reply, Extra}.
-
-closed_in_connection(Arg) ->
- %% Nothing to clean up.
- Arg.
-
-closed_out_connection(Arg) ->
- %% Nothing to clean up.
- Arg.
- </code>
- <note>
- <p>One can also use interceptors for debugging purposes, e.g.,
- print which objects and operations are invoked with which arguments
- and the outcome of the operation. In conjunction with the configuration
- parameter <c>orber_debug_level</c> it is rather easy to find out what
- went wrong or just to log the traffic. </p>
- </note>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_introduction.xml b/lib/orber/doc/src/ch_introduction.xml
deleted file mode 100644
index f04fedd0a7..0000000000
--- a/lib/orber/doc/src/ch_introduction.xml
+++ /dev/null
@@ -1,145 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1999</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Introduction to Orber</title>
- <prepared>Megan Lynch</prepared>
- <docno></docno>
- <date>1998-09-21</date>
- <rev></rev>
- <file>ch_introduction.xml</file>
- </header>
-
- <section>
- <title>Overview</title>
- <p>The Orber application is a CORBA compliant Object Request Brokers
- (ORB), which provides CORBA functionality in an Erlang
- environment. Essentially, the ORB channels communication or
- transactions between nodes in a
- heterogeneous environment.
- </p>
- <p><term id="CORBA"><termdef>Common Object Request Broker Architecture is a common communication standard developed by the OMG (Object Management Group)</termdef></term>(Common Object Request Broker
- Architecture) provides an interface definition language allowing
- efficient system integration and also supplies standard
- specifications for some services.
- </p>
- <p>The Orber application contains the following parts:</p>
- <list type="bulleted">
- <item>
- <p>ORB kernel and IIOP support</p>
- </item>
- <item>
- <p>Interface Repository</p>
- </item>
- <item>
- <p>Interface Definition Language Mapping for Erlang</p>
- </item>
- <item>
- <p>CosNaming Service</p>
- </item>
- </list>
-
- <section>
- <title>Benefits</title>
- <p>Orber provides CORBA functionality in an Erlang environment that enables:
- </p>
- <list type="bulleted">
- <item>
- <p><em>Platform interoperability and transparency</em></p>
- <p>Orber enables communication between
- OTP applications or Erlang environment applications and
- other platforms; for example, Windows NT, Solaris
- etc, allowing platform transparency. This is especially helpful in situations where there
- are many users with different platforms. For example,
- booking airline tickets would require the airline database
- and hundreds of travel agents (who may not have the same
- platform) to book seats on flights. </p>
- </item>
- <item>
- <p><em>Application level interoperability and transparency</em></p>
- <p>As Orber is a CORBA compliant application, its purpose is
- to provide interoperability and transparency on the application
- level.
- Orber simplifies the distributed system software by defining the
- environment as objects, which in effect, views
- everything as identical regardless of programming
- languages. <br></br>
- Previously, time-consuming programming was
- required to facilitate communication between different languages.
- However, with CORBA compliant Orber the Application
- Programmer is relieved of this task. This makes
- communication on an application level relatively transparent to the user.</p>
- </item>
- </list>
- </section>
-
- <section>
- <title>Purpose and Dependencies</title>
- <p>The system architecture and OTP dependencies of Orber are illustrated in figure 1 below:</p>
- <marker id="dependent"></marker>
- <image file="dependent.gif">
- <icaption>
-Figure 1: Orber Dependencies and Structure.</icaption>
- </image>
- <p>Orber is dependent on Mnesia (see the Mnesia
- documentation) - an Erlang database management application
- used to store object information.</p>
- <note>
- <p>Although Orber does not have a run-time
- application dependency to IC (an <term id="IDL"><termdef>Interface Definition Language - IDL is the OMG specified interface definition language, used to define the CORBA object interfaces.</termdef></term>compiler for
- Erlang), it is necessary when building
- services and applications. See the IC documentation for
- further details.</p>
- </note>
- <marker id="orbs"></marker>
- <image file="orbs.gif">
- <icaption>
-Figure 2: ORB interface between Java and Erlang Environment Nodes.</icaption>
- </image>
- <p>This simplified illustration in figure 2 demonstrates how Orber can facilitate communication in a heterogeneous environment. The Erlang Nodes running
- OTP and the other Node running applications written in Java can
- communicate via an <term id="ORB"><termdef>Object Request Broker - ORB open software bus architecture specified by the OMG which allows object components to communicate in a heterogeneous environment.</termdef></term>(Object Request Broker). Using
- Orber means that CORBA functions can be used to achieve this
- communication.
- </p>
- <p>For example, if one of the above nodes requests an object, it does not
- need to know if that object is located on the same, or
- different, Erlang or Java nodes. The ORB will channel the
- information creating platform and application transparency for
- the user.
- </p>
- </section>
-
- <section>
- <title>Prerequisites</title>
- <p>To fully understand the concepts presented in the
- documentation, it is recommended that the user is familiar
- with distributed programming and CORBA (Common Object Request
- Broker Architecture).
- </p>
- <p>Recommended reading includes <em>Open Telecom Platform Documentation Set</em> and <em>Concurrent Programming in Erlang</em>.
- </p>
- </section>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_naming_service.xml b/lib/orber/doc/src/ch_naming_service.xml
deleted file mode 100644
index 991402ae86..0000000000
--- a/lib/orber/doc/src/ch_naming_service.xml
+++ /dev/null
@@ -1,465 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1997</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>CosNaming Service</title>
- <prepared></prepared>
- <docno></docno>
- <date>1998-10-10</date>
- <rev></rev>
- <file>ch_naming_service.xml</file>
- </header>
-
- <section>
- <title>Overview of the CosNaming Service</title>
- <p>The CosNaming Service is a service developed to help users and
- programmers identify objects by human readable names rather than by a
- reference. By binding a name to a naming context (another object), a
- contextual reference is formed. This is helpful when navigating in the
- object space. In addition, identifying objects by name allows you to evolve
- and/or relocate objects without client code modification.</p>
- <p>The CosNaming service has some concepts that are important:</p>
- <list type="bulleted">
- <item>
- <p><em>name binding</em> - a name to object association.</p>
- </item>
- <item>
- <p><em>naming context</em> - is an object that contains a set of
- name bindings in which each name is unique. Different names can be
- bound to the same object.
- </p>
- </item>
- <item>
- <p><em>to bind a name</em> - is to create a name binding in a given
- context.</p>
- </item>
- <item>
- <p><em>to resolve a name</em> - is to determine the object associated
- with the name in a given context.</p>
- </item>
- </list>
- <p>A name is always resolved in a context, there no absolute names exist.
- Because a context is like any other object, it can also be bound to
- a name
- in a naming context.
- This will result in a naming graph (a directed graph with notes and
- labeled edges). The graph allows more complex names to refer to an
- object. Given a context, you can use a sequence to reference an object.
- This sequence is henceforth referred to as <em>name</em> and the
- individual
- elements in the sequence as <em>name components</em>. All but the
- last name component are bound to naming contexts.
- </p>
- <p>The diagram in figure 1 illustrates how the Naming Service provides a
- contextual relationship between objects, NamingContexts and
- NameBindings to create an object locality, as the
- object itself, has no name.
- </p>
- <marker id="name"></marker>
- <image file="name.gif">
- <icaption>
-Figure 1: Contextual object relationships using the Naming Service.</icaption>
- </image>
- <p>The naming contexts provide a directory of contextual
- reference and naming for objects (an object can appear to
- have more than one name).
- </p>
- <p>In figure 1 the object to the right can either be
- called <c>alpha</c> from one context or <c>gamma</c> from another.
- </p>
- <p>The Naming Service has an initial naming context, which is shown
- in the diagram as the top-most object in the naming graph.
- It has two names <c>beta</c> and <c>epsilon</c>, which are bound to other
- naming contexts. The initial naming context is a well known location
- used to share a common name space between multiple programs.
- You can traverse the naming graph until you reach a name, which is
- bound to an object, which is not a naming context.
- </p>
- <p>We recommend reading <em>chapter 12, CORBA Fundamentals and Programming</em>, for detailed information regarding the
- Naming Service. </p>
- </section>
-
- <section>
- <title>The Basic Use-cases of the Naming Service</title>
- <p>The basic use-cases of the Naming Service are:
- </p>
- <list type="bulleted">
- <item>Fetch initial reference to the naming service.</item>
- <item>Creating a naming context.</item>
- <item>Binding and unbinding names to objects.</item>
- <item>Resolving a name to an object.</item>
- <item>Listing the bindings of a naming context.</item>
- <item>Destroying a naming context.</item>
- </list>
-
- <section>
- <title>Fetch Initial Reference to the Naming Service</title>
- <p>In order to use the naming service you have to fetch an
- initial reference to it. This is done with:</p>
- <code type="erl">
-NS = corba:resolve_initial_references("NameService").
- </code>
- <note>
- <p>NS in the other use-cases refers to this initial reference.</p>
- </note>
- </section>
-
- <section>
- <title>Creating a Naming Context</title>
- <p>There are two functions for creating a naming context.
- The first function, which only creates a naming context object is:</p>
- <code type="erl">
-NC = 'CosNaming_NamingContext':new_context(NS).
- </code>
- <p>The other function creates a naming context and binds it to a name in
- an already existing naming context (the initial context in this
- example):
- </p>
- <code type="erl">
-NC = 'CosNaming_NamingContext':bind_new_context(NS, lname:new(["new"])).
- </code>
- </section>
-
- <section>
- <title>Binding and Unbinding Names to Objects</title>
- <p>The following steps illustrate how to bind/unbind an object reference
- to/from a name. For the example below, assume that the NamingContexts
- in the path are already bound to the name <c>/workgroup/services</c>,
- and that reference to the services context are in the variable
- <c>Sc</c>.</p>
- <list type="ordered">
- <item>
- <p>Use the naming library functions to create a name</p>
- <code type="erl">
-Name = lname:new(["object"]).
- </code>
- </item>
- <item>
- <p>Use CosNaming::NamingContext::bind() to bind a name to an object</p>
- <code type="erl">
-'CosNaming_NamingContext':bind(Sc, Name, Object).
- </code>
- </item>
- <item>
- <p>Use CosNaming::NamingContext::unbind() to remove the NameBinding from an object</p>
- <code type="erl">
-'CosNaming_NamingContext':unbind(Sc, Name).
- </code>
- </item>
- </list>
- <note>
- <p>Objects can have more than one name, to indicate different paths to
- the same object.</p>
- </note>
- </section>
-
- <section>
- <title>Resolving a Name to an Object</title>
- <p>The following steps show how to retrieve the object reference to the service context
- above (/workgroup/services). </p>
- <list type="ordered">
- <item>
- <p>Use the naming library functions to create a name path:</p>
- <code type="erl">
-Name = lname:new(["workgroup", "services"]).
- </code>
- </item>
- <item>
- <p>Use CosNaming::NamingContext::resolve() to to resolve the name to an object</p>
- <code type="erl">
-Sc = 'CosNaming_NamingContext':resolve(NS, Name).
- </code>
- </item>
- </list>
- <p>An alternative is to use:</p>
- <code type="erl">
-Sc = corba:string_to_object("corbaname:rir:/NameService#workgroup/services/").
- </code>
- <p>The <c>corbaname</c> schema is described further in the Interoperable
- Naming Service section.</p>
- </section>
-
- <section>
- <title>Listing the Bindings in a NamingContext</title>
- <list type="ordered">
- <item>
- <p>Use CosNaming::NamingContext::list() to list all the bindings in a context</p>
- <p>The following code retrieves and lists up to 10 bindings from a context.</p>
- <code type="erl">
-{BList, BIterator} = 'CosNaming_NamingContext':list(Sc, 10).
-
-lists:foreach(fun({{Id, Kind},BindingType}) -> case BindingType of
- nobject ->
- io:format("id: %s, kind: %s, type: object~n", [Id, Kind]);
- _ ->
- io:format("id: %s, kind: %s, type: ncontext~n", [Id, Kind])
- end end,
- Blist).
- </code>
- </item>
- </list>
- <note>
- <p>Normally a <term id="BindingIterator"><termdef>The binding iterator (Like a book mark) indicates which objects have been read from the list.</termdef></term>is helpful in situations where you have a large number of objects
- in a list, as the programmer then can traverse it more easily.
- In Erlang it is not needed, because lists are easily handled in the
- language itself.</p>
- </note>
- <warning>
- <p>Remember that the BindingIterator (BIterator in the example) is an object and therefore
- <em>must be removed</em> otherwise dangling processes will occur.
- Use <c>CosNaming::BindingIterator::destroy()</c> to remove it.</p>
- </warning>
- <code type="erl">
-'CosNaming_NamingContext':destroy(BIterator).
- </code>
- </section>
-
- <section>
- <title>Destroying a Naming Context</title>
- <p>The naming contexts are persistent and must be explicitly removed.
- (they are also removed if all Orber nodes in the domain are stopped).</p>
- <list type="ordered">
- <item>
- <p>Use CosNaming::NamingContext::destroy() to remove a NamingContext</p>
- <code type="erl">
-'CosNaming_NamingContext':destroy(Sc).
- </code>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Interoperable Naming Service</title>
- <marker id="interop_ns"></marker>
- <p>The OMG specifies URL schemes, which represent a CORBA object and a CORBA object
- bound in a NamingContext, for resolving references from other ORB:s. As of today,
- three schemes are defined:</p>
- <list type="bulleted">
- <item>IOR</item>
- <item>corbaloc</item>
- <item>corbaname</item>
- </list>
-
- <section>
- <title>IOR</title>
- <p>A stringified IOR is a valid URL format but difficult for humans to handle
- through non-electronic means. This URL format does not depend on a specific
- Name Service and, thus, is robust and insulates the client from the encapsulated
- transport information and object key used to reference the object.</p>
- </section>
-
- <section>
- <title>corbaloc</title>
- <p>The notation of this scheme is similar to the more well known URL <c>HTTP</c>, and
- the full <c>corbaloc</c> BNF is:</p>
- <code type="none"><![CDATA[
-<corbaloc> = "corbaloc:"<obj_addr_list>["/"<key_string>]
-<obj_addr_list> = [<obj_addr>","]*<obj_addr>
-<obj_addr> = <prot_addr> | <future_prot_addr>
-<prot_addr> = <rir_prot_addr> | <iiop_prot_addr>
-<rir_prot_addr> = <rir_prot_token>":"
-<rir_prot_token> = rir
-<future_prot_addr> = <future_prot_id><future_prot_addr>
-<future_prot_id> = <future_prot_token>":"
-<iiop_prot_addr> = <iiop_id><iiop_addr>
-<iiop_id> = <iiop_default> | <iiop_prot_token>":"
-<iiop_default> = ":"
-<iiop_prot_token> = "iiop"
-<iiop_addr> = <version><host>[":"<port>]
-<host> = <DNS-style Host Name> | <ip_v4_address> | "["<ip_v6_address>"]"
-<version> = <major>"."<minor>"@" | empty_string
-<port> = number
-<major> = number
-<minor> = number
-<DNS-style Host Name> = string
-<ip_v4_address> = string
-<ip_v6_address> = string
-<key_string> = for example NameService
- ]]></code>
- <p>The <c>corbaloc</c> scheme consists of 3 parts:</p>
- <list type="bulleted">
- <item>Protocol - as of today <c>iiop</c> or <c>rir</c> is supported.
- Using <c>rir</c> means that we will resolve the given Key locally, i.e.,
- the same as using <c>corba:resolve_initial_references("NameService").</c></item>
- <item>IIOP address - this address can be divided into <c>Version</c>, <c>Host</c>
- and <c>Port</c>. If the version or port are left out they will be set to the default
- values <c>1.0</c> and <c>2809</c> respectively.</item>
- <item>KeyString - an object key, e.g., "NameService". If no Key is
- supplied the default value "NameService" will be used.</item>
- </list>
- <p>A <c>corbaloc</c> can be passed used together with
- <c>corba:string_to_object("corbaloc::[email protected]:4001/NameService")</c> or set as the
- configuration variables <c>orbInitilRef</c> or <c>orbDefaultInitilRef</c> and calling
- <c>corba:resolve_initial_references("NameService")</c>. For more information see the Orber
- installation chapter. <c>corbaloc</c> can also be used together with <c>corbaname</c>
- to gain an easy access to a Name Service.</p>
- <p>Currently, the OMG defines a set of reserved keys and the type of object,
- listed below, they should be associated with. The <c>NameService</c>
- key may <em>not</em> be changed in Orber. If you want to add one of the
- reserved keys as an initial service, simply use:</p>
- <code type="erl">
-1> Factory = cosNotificationApp:start_global_factory().
-2> corba:add_initial_service("NotificationService", Factory).
- </code>
- <p>This object can then be easily resolved by any other ORB, supporting
- the Interoperable Naming Service, by using:</p>
- <code type="erl">
-3> NF = corba:string_to_object("corbaloc::[email protected]:4001/NotificationService").
- </code>
- <table>
- <row>
- <cell align="center" valign="middle"><em>String Name</em></cell>
- <cell align="center" valign="middle"><em>Object Type</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">RootPOA</cell>
- <cell align="left" valign="middle">PortableServer::POA</cell>
- </row>
- <row>
- <cell align="left" valign="middle">POACurrent</cell>
- <cell align="left" valign="middle">PortableServer::Current</cell>
- </row>
- <row>
- <cell align="left" valign="middle">InterfaceRepository</cell>
- <cell align="left" valign="middle">CORBA::Repository</cell>
- </row>
- <row>
- <cell align="left" valign="middle">NameService</cell>
- <cell align="left" valign="middle">CosNaming::NamingContext</cell>
- </row>
- <row>
- <cell align="left" valign="middle">TradingService</cell>
- <cell align="left" valign="middle">CosTrading::Lookup</cell>
- </row>
- <row>
- <cell align="left" valign="middle">SecurityCurrent</cell>
- <cell align="left" valign="middle">SecurityLevel1::Current/SecurityLevel2::Current</cell>
- </row>
- <row>
- <cell align="left" valign="middle">TransactionCurrent</cell>
- <cell align="left" valign="middle">CosTransaction::Current</cell>
- </row>
- <row>
- <cell align="left" valign="middle">DynAnyFactory</cell>
- <cell align="left" valign="middle">DynamicAny::DynAnyFactory</cell>
- </row>
- <row>
- <cell align="left" valign="middle">ORBPolicyManager</cell>
- <cell align="left" valign="middle">CORBA::PolicyManager</cell>
- </row>
- <row>
- <cell align="left" valign="middle">PolicyCurrent</cell>
- <cell align="left" valign="middle">CORBA::PolicyCurrent</cell>
- </row>
- <row>
- <cell align="left" valign="middle">NotificationService</cell>
- <cell align="left" valign="middle">CosNotifyChannelAdmin::EventChannelFactory</cell>
- </row>
- <row>
- <cell align="left" valign="middle">TypedNotificationService</cell>
- <cell align="left" valign="middle">CosTypedNotifyChannelAdmin::TypedEventChannelFactory</cell>
- </row>
- <row>
- <cell align="left" valign="middle">CodecFactory</cell>
- <cell align="left" valign="middle">IOP::CodecFactory</cell>
- </row>
- <row>
- <cell align="left" valign="middle">PICurrent</cell>
- <cell align="left" valign="middle">PortableInterceptors::Current</cell>
- </row>
- <tcaption>Currently reserved key strings</tcaption>
- </table>
- </section>
-
- <section>
- <title>corbaname</title>
- <p>The <c>corbaname</c> URL scheme is an extension of the <c>corbaloc</c> scheme, and
- the full <c>corbaname</c> BNF is:</p>
- <code type="none"><![CDATA[
-<corbaname> = "corbaname:"<obj_addr_list>["/"<key_string>]["#"<string_name>]
-<obj_addr_list> = as described above.
-<key_string> = as described above.
- ]]></code>
- <p>The <c>string_name</c>, concatenated to the <c>corbaloc</c> string, identifies
- a binding in a naming context. A name component consists of two parts, i.e.,
- <c>id</c> and <c>kind</c>, which is represented as follows:</p>
- <table>
- <row>
- <cell align="center" valign="middle"><em>String Name</em></cell>
- <cell align="center" valign="middle"><em>Name Sequence</em></cell>
- <cell align="center" valign="middle"><em>Comment</em></cell>
- </row>
- <row>
- <cell align="left" valign="middle">"id1/./id3.kind3"</cell>
- <cell align="left" valign="middle">[{"id1",""},{"",""},{"id3","kind3"}]</cell>
- <cell align="left" valign="middle">The first component has no kind defined while the second component's both fields are empty.</cell>
- </row>
- <row>
- <cell align="left" valign="middle">"id1//id3.kind3"</cell>
- <cell align="left" valign="middle">ERROR</cell>
- <cell align="left" valign="middle">Not allowed, must insert a '.' between the '//'.</cell>
- </row>
- <row>
- <cell align="left" valign="middle">"id1.kind1/."</cell>
- <cell align="left" valign="middle">[{"id1","kind1"},{"",""}]</cell>
- <cell align="left" valign="middle">The first component's fields are both set while the second component's both fields are empty.</cell>
- </row>
- <row>
- <cell align="left" valign="middle">"id1.kind1/id2."</cell>
- <cell align="left" valign="middle">ERROR</cell>
- <cell align="left" valign="middle">An Id with a trailing '.' is not allowed.</cell>
- </row>
- <row>
- <cell align="left" valign="middle">"i\\/d1/i\\.d2"</cell>
- <cell align="left" valign="middle">[{"i/d1",""},{"i.d2",""}]</cell>
- <cell align="left" valign="middle">Since '.' and '/' are used to separate the components, these tokens must be escaped to be correctly converted.</cell>
- </row>
- <tcaption>Stringified Name representation</tcaption>
- </table>
- <p>After creating a stringified Name we can either use:</p>
- <code type="erl">
-NameStr = "org.erlang",
-NS = corba:resolve_initial_references("NameService"),
-Obj = 'CosNaming_NamingContextExt':resolve_str(NS, NameStr),
- </code>
- <p>or concatenate the Name String using:</p>
- <code type="erl">
-NameStr = "Swedish/Soccer/Champions",
-Address = "corbaname:iiop:[email protected]:2000/NameService",
-NS = corba:resolve_initial_references("NameService"),
-URLStr = 'CosNaming_NamingContextExt':to_url(NS, Address, NameStr),
-Obj = corba:string_to_object(URLStr),
- </code>
- <p>Using the first alternative, the configuration variables <c>orbInitilRef</c> and
- <c>orbDefaultInitilRef</c>, will determine which other ORB's or the local
- Name Service Orber will try to resolve the given string from. The second
- alternative allows us to override any settings of the configuration variables.</p>
- <p>The function <c>to_url/3</c> will perform any necessary escapes compliant with
- IETF/RFC 2396. US-ASCII alphanumeric characters and
- <c><![CDATA["," | "/" | ":" | "?" | "@" | "&" | "=" | "+" | "$" | ";" | "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"]]></c>
- are not escaped.</p>
- </section>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_orber_kernel.xml b/lib/orber/doc/src/ch_orber_kernel.xml
deleted file mode 100644
index 396e1360fd..0000000000
--- a/lib/orber/doc/src/ch_orber_kernel.xml
+++ /dev/null
@@ -1,103 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1999</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>The Orber Application</title>
- <prepared></prepared>
- <docno></docno>
- <date>1998-10-05</date>
- <rev></rev>
- <file>ch_orber_kernel.xml</file>
- </header>
-
- <section>
- <title>ORB Kernel and IIOP </title>
- <p>This chapter gives a brief overview of the ORB and its relation
- to objects in a distributed environment and the usage of Domains
- in Orber.
- Also Internet-Inter ORB Protocol (<term id="IIOP"><termdef>Internet-Inter ORB Protocol</termdef></term>) is discussed and how this
- protocol facilitates communication between ORBs to
- allow the accessory of persistent server objects in Erlang. </p>
- </section>
-
- <section>
- <title>The Object Request Broker (ORB)</title>
- <p>An ORB kernel can be best described as the middle-ware, which
- creates relationships between clients and servers, but is
- defined by its interfaces. This allows transparency for the
- user, as they do not have to be aware of where the requested
- object is located. Thus, the programmer can work with any other
- platform provided that an IDL mapping and interfaces exist.
- </p>
- <p>The IDL mapping which is described in a later chapter is the
- translator between other platforms, and languages. However, it
- is the ORB, which provides objects with a structure by which
- they can communicate with other objects.
- </p>
- <p>ORBs intercept and direct messages from one object, pass this
- message using IIOP to another ORB, which then directs the
- message to the indicated object.
- </p>
- <p>An ORB is the base on which interfaces, communication stubs
- and mapping can be built to enable communication between
- objects. Orber uses <term id="domains"><termdef>A domain allows a more efficient communication protocol to be used between objects not on the same node without the need of an ORB</termdef></term>to group objects of different nodes
- </p>
- <p>How the ORB provides communication is shown very simply in figure 1 below: </p>
- <marker id="theORB"></marker>
- <image file="theORB.gif">
- <icaption>
-Figure 1: How the Object Request Broker works.</icaption>
- </image>
- <p>The domain in Orber gives an extra aspect to the distributed object
- environment as each domain has one ORB, but it is distributed over
- a number of object in different nodes. The domain binds objects on
- nodes more closely than distributed objects in different domains. The
- advantage of a domain is that a faster communication exists between
- nodes and objects of the same domain. An internal communication protocol
- (other than IIOP) allows a
- more efficient communication between these objects. </p>
- <note>
- <p>Unlike objects, domains can only have one name
- so that no communication ambiguities exist between domains.</p>
- </note>
- </section>
-
- <section>
- <title>Internet Inter-Object Protocol (IIOP)</title>
- <p>IIOP is a communication protocol developed by the OMG to
- facilitate communication in a distributed object-oriented
- environment.
- </p>
- <p>Figure 2 below demonstrates how IIOP works between objects:</p>
- <marker id="iiop"></marker>
- <image file="iiop.gif">
- <icaption>
-Figure 2: IIOP communication between domains and objects.</icaption>
- </image>
- <note>
- <p>Within the Orber domains the objects communicate without
- using the IIOP. However, the user is unaware of the difference in protocols, as this difference is not visible. </p>
- </note>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_orberweb.xml b/lib/orber/doc/src/ch_orberweb.xml
deleted file mode 100644
index c9dcc382e6..0000000000
--- a/lib/orber/doc/src/ch_orberweb.xml
+++ /dev/null
@@ -1,221 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>2001</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>OrberWeb</title>
- <prepared>Nick</prepared>
- <docno></docno>
- <date>2001-11-22</date>
- <rev></rev>
- <file>ch_orberweb.xml</file>
- </header>
-
- <section>
- <title>Using OrberWeb</title>
- <p><c>OrberWeb</c> is intended to make things easier when developing and
- testing applications using <c>Orber</c>. The user is able to interact
- with <c>Orber</c> via a GUI by using a web browser.</p>
- <p><c>OrberWeb</c> requires that the application <c>WebTool</c> is available and
- started on at least one node; if so <c>OrberWeb</c> can usually be used to
- to access <c>Orber</c> nodes supporting the Interoperable Naming
- Service. How to start OrberWeb is described in
- <seealso marker="ch_orberweb#startorberweb">Starting OrberWeb</seealso></p>
- <p>The <c>OrberWeb</c> GUI consists of a <em>Menu Frame</em> and a
- <em>Data Frames</em>.</p>
-
- <section>
- <title>The Menu Frame</title>
- <p>The menu frame consists of:</p>
- <list type="bulleted">
- <item><em>Node List</em> - which node to access.</item>
- <item><em>Configuration</em> - see how Orber on the current node is configured.</item>
- <item><em>Name Service</em> - browse the NameService and add/remove a Context/Object.</item>
- <item><em>IFR Types</em> - see which types are registered in IFR.</item>
- <item><em>Create Object</em> - create a new object and, possibly, store it in the NameService.</item>
- </list>
- <p></p>
- <marker id="menuframe"></marker>
- <image file="menuframe.gif">
- <icaption>The Menu Frame.</icaption>
- </image>
- <p>Which nodes we can access is determined by what is returned when invoking <c>[node()|nodes()]</c>.
- If you cannot see a desired node in the list, you have to call <c>net_adm:ping(Node)</c>.
- But this requires that the node is started with the distribution switched on
- (e.g. <c>erl -sname myNode</c>); this also goes for the node <c>OrberWeb</c> is running on.</p>
- </section>
-
- <section>
- <title>The Configuration Data Frame</title>
- <p>When accessing the <em>Configuration</em> page OrberWeb presents a table containing the
- <seealso marker="ch_install#config">configuration settings</seealso> for the target node.</p>
- <p></p>
- <marker id="dataframe3"></marker>
- <image file="dataframe3.gif">
- <icaption>Configuration Settings.</icaption>
- </image>
- <p>It is also possible to change those configuration parameters which can be changed when Orber
- is already started. The Key-Value pairs is given as a list of tuples, e.g.,
- <em>[{orber_debug_level, 5}, {iiop_timeout, 60}, {giop_version, {1,2}}]</em>. If one tries to update a parameter
- which may not be changed an error message will be displayed.</p>
- </section>
-
- <section>
- <title>The IFR Data Frame</title>
- <p>All types registered in the IFR (Interface Repository) which have an associated IFR-id
- can be viewed via the IFR Data Frame. This gives the user an easy way to confirm that
- all necessary IDL-specifications have been properly registered. All available types are
- listed when choosing <c>IFR Types</c> in the menu frame:</p>
- <p></p>
- <marker id="dataframe1"></marker>
- <image file="dataframe1.gif">
- <icaption>Select Type.</icaption>
- </image>
- <p>After selecting a type all definitions of that particular type will be displayed. If no such
- bindings exists the table will be empty.</p>
- <p>Since Orber adds definitions to the IFR when it is installed (e.g. CosNaming), not only
- types defined by the user will show up in the table. In the figure below you find the
- the NameService exceptions listed.</p>
- <p></p>
- <marker id="dataframe2"></marker>
- <image file="dataframe2.gif">
- <icaption>List Registered Exceptions.</icaption>
- </image>
- </section>
-
- <section>
- <title>The NameService Data Frame</title>
- <p>The NameService main purpose is to make possible to bind object references, which
- can client applications can resolve and invoke operations on. Initially, the NameService
- is empty. The most common scenario, is that user applications create Contexts and add objects
- in the NameService. OrberWeb allows the user to do the very same thing.</p>
- <p>When referencing an object or context you must use stringified NameComponents.
- For more information see the <seealso marker="ch_naming_service">Interoperable Naming Service</seealso>.
- In the following example we will use the string <em>org/erlang/TheObjectName</em>, where
- <em>org</em> and <em>erlang</em> will be contexts and <em>TheObjectName</em>
- the name the object will be bound to.</p>
- <p>Since the NameService is empty in the beginning, the only thing we can do is creating
- a new context. Simply write <em>org</em> in the input field and press <c>New Context</c>.
- If OrberWeb was able to create the context or not, is shown in the completion message.
- If successful, just press the <c>Go Back</c> button. Now, a link named <em>org</em> should
- be listed in the table. In the right column the context type is displayed. Contexts are
- associated with <em>ncontext</em> and objects with <em>nobject</em>.</p>
- <p></p>
- <marker id="dataframe5"></marker>
- <image file="dataframe5.gif">
- <icaption>Add a New Context.</icaption>
- </image>
- <p>To create the next level context (i.e. erlang), simply follow the link and repeat the procedure.
- If done correctly, a table containing the same data as the following figure should be the result
- if you follow the <em>erlang</em> link. Note, that the path is displayed in the yellow
- field.</p>
- <p></p>
- <p>If a context does not contain any sub-contexts or object bindings, it is possible to
- delete the context. If these requirements are met, a <c>Delete Context</c> button will appear.
- A completion status message will be displayed after deleting the context.</p>
- <p></p>
- <marker id="dataframe6"></marker>
- <image file="dataframe6.gif">
- <icaption>Delete Context.</icaption>
- </image>
- <p>Now it is possible to bind an object using the complete name string. To find out how this is
- done using OrberWeb see <seealso marker="ch_orberweb#create">Object Creation</seealso>.
- For now, we will just assume that an object have been created and bound as <em>TheObjectName</em>. </p>
- <p></p>
- <marker id="dataframe7"></marker>
- <image file="dataframe7.gif">
- <icaption>Object Stored in the NameService.</icaption>
- </image>
- <p>If you follow the <em>TheObjectName</em> link, data about the bound object will be
- presented. Note, depending on which type of object it is, the information given differs.
- It would, for example, not be possible to display a Pid for all types of objects since
- it might reside on a Java-ORB. In the figure below a CosNotification FilterFactory have
- been bound under the name <em>org/erlang/TheObjectName</em>.</p>
- <p></p>
- <marker id="dataframe8"></marker>
- <image file="dataframe8.gif">
- <icaption>Object Data.</icaption>
- </image>
- <p>OrberWeb also makes it possible to remove a binding and dispose the associated object.
- Pressing <em>Unbind</em> the binding will be removed but the object will still exist.
- But, if the <em>Unbind and Dispose</em> button is pressed, the binding will be removed
- and the object terminated.</p>
- </section>
-
- <section>
- <title>The Object Creation Data Frame</title>
- <marker id="create"></marker>
- <p>This part makes it possible to create a new object and, if wanted, store it the
- NameService.</p>
- <p></p>
- <marker id="dataframe4"></marker>
- <image file="dataframe4.gif">
- <icaption>Create a New Object.</icaption>
- </image>
- <list type="bulleted">
- <item><em>Module</em> - simply type the name of the module of the object type
- you want to create. If the module begins with a capital letter, we normally must
- write <c>'Module_Interface'</c>. But, when using OrberWeb, you shall <em>NOT</em>.
- Since we cannot create linked objects this is not an option.</item>
- <item><em>Arguments</em> - the supplied arguments must be written as a single Erlang term.
- That is, as a list or tuple containing other Erlang terms. The arguments will be
- passed to the <c>init</c> function of the object. It is, however, not possible
- to use Erlang records. If OrberWeb is not able to parse the arguments, an error message
- will be displayed. If left empty, an empty list will be passed.</item>
- <item><em>Options</em> - the options can be the ones listed under
- <seealso marker="Module_Interface">Module_Interface</seealso> in Orber's Reference manual.
- Hence, they are not further described here. But, as an example, in the figure above
- we started the object as globally registered. If no options supplied the object
- will be started as default.</item>
- <item><em>Name String</em> - if left empty the object will <em>not</em> be registered in the
- NameService. Hence, it is important that you can access the object in another way,
- otherwise a zombie process is created. In the previous section we used the name string
- <em>org/erlang/TheObjectName</em>. If we choose the same name here, the listed contexts
- (i.e. <em>org</em> and <em>erlang</em>) must be created <em>before</em> we can create
- and bind the object to <em>TheObjectName</em>. If this requirement is not met, OrberWeb
- cannot bind the object. Hence, the object will be terminated and an error message
- displayed.</item>
- <item><em>Operation to use</em> - which option choosed will determine the behavior of OrberWeb.
- If you choose <em>bind</em> and a binding already exists an error message will be
- displayed and the newly started object terminated. But if you choose <em>rebind</em>
- any existing binding will over-written.</item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Starting OrberWeb</title>
- <marker id="startorberweb"></marker>
- <p>You may choose to start OrberWeb on node, on which Orber is running or not. But
- the Erlang distribution must be started (e.g. by using -sname aNodeName). Now, all
- you have to do is to invoke:</p>
- <code type="none">
-erl> webtool:start().
-WebTool is available at http://localhost:8888/
-Or http://127.0.0.1:8888/
- </code>
- <p>Type one of the URL:s in your web-browser. If you want to access the WebTool application
- from different machine, just replace <c>localhost</c> with its name. For more information,
- see the WebTool documentation.</p>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_security.xml b/lib/orber/doc/src/ch_security.xml
deleted file mode 100644
index 151e417079..0000000000
--- a/lib/orber/doc/src/ch_security.xml
+++ /dev/null
@@ -1,96 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1999</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>How to use security in Orber</title>
- <prepared></prepared>
- <docno></docno>
- <date>1999-09-01</date>
- <rev></rev>
- <file>ch_security.xml</file>
- </header>
-
- <section>
- <title>Security in Orber</title>
-
- <section>
- <title>Introduction</title>
- <p>Orber SSL provides authentication, privacy and integrity for your
- Erlang applications. Based on the Secure Sockets Layer protocol, the
- Orber SSL ensures that your Orber clients and servers can
- communicate securely over any network.
- This is done by tunneling IIOP through an SSL connection. To get
- the node secure you will also need to have a firewall which
- only lets through connections to certain ports.</p>
- </section>
-
- <section>
- <title>Enable Usage of Secure Connections</title>
- <p>To enable a secure Orber domain you have to set the configuration variable
- <em>secure</em> which currently only can have one of two values;
- <em>no</em> if no security for IIOP should be used and <em>ssl</em> if
- secure connections is needed (<em>ssl</em> is currently the only supported
- security mechanism).</p>
- <p>The default is no security.</p>
- </section>
-
- <section>
- <title>Configurations when Orber is Used on the Server Side</title>
- <p>There is a variable to conficure Orber's SSL behavior on the server side.</p>
- <list type="bulleted">
- <item><em>ssl_server_options</em> - which is a list of options to ssl.
- See the <seealso marker="ssl:ssl">SSL</seealso> application for further
- descriptions on these options.</item>
- </list>
- <p>There also exist an API function for accessing the value of this variable:</p>
- <list type="bulleted">
- <item>orber:ssl_server_options/0</item>
- </list>
- </section>
-
- <section>
- <title>Configurations when Orber is Used on the Client Side</title>
- <p>When the Orber enabled application is the client side in the secure connection the
- different configurations can be set per client process instead and not for the whole domain
- as for incoming calls.</p>
- <p>There is a variable to set default values for the domain but they can be changed
- per client process.</p>
- <list type="bulleted">
- <item><em>ssl_client_options</em> - which is a list of options to ssl.
- See the <seealso marker="ssl:ssl">SSL</seealso> application for further
- descriptions on these options.</item>
- </list>
- <p>There also exist two API functions for accessing and changing the values of this
- variable in the client processes.</p>
- <p>Access function:</p>
- <list type="bulleted">
- <item>orber:ssl_client_options/0</item>
- </list>
- <p>Modify function:</p>
- <list type="bulleted">
- <item>orber:set_ssl_client_options/1</item>
- </list>
- </section>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_stubs.xml b/lib/orber/doc/src/ch_stubs.xml
deleted file mode 100644
index 9290c127f9..0000000000
--- a/lib/orber/doc/src/ch_stubs.xml
+++ /dev/null
@@ -1,284 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1999</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Orber Stubs/Skeletons</title>
- <prepared></prepared>
- <docno></docno>
- <date>1999-09-03</date>
- <rev>A</rev>
- <file>ch_stubs.xml</file>
- </header>
-
- <section>
- <title>Orber Stubs and Skeletons Description</title>
- <p>This example describes the API and behavior of Orber stubs and skeletons.
- </p>
-
- <section>
- <title>Server Start</title>
- <p>Orber servers can be started in several ways. The chosen start functions determines
- how the server can be accessed and its behavior.
- </p>
- <p>Using <c>Module_Interface:oe_create()</c> or <c>oe_create_link()</c>:
- </p>
- <list type="bulleted">
- <item>No initial data can be passed.</item>
- <item>Cannot be used as a supervisor child start function.</item>
- <item>Only accessible through the object reference returned by the start function.
- The object reference is no longer valid if the server dies and is restarted.</item>
- </list>
- <p>Using <c>Module_Interface:oe_create(Env)</c> or <c>oe_create_link(Env)</c>:</p>
- <list type="bulleted">
- <item>Initial data can be passed using <c>Env</c>.</item>
- <item>Cannot be used as a supervisor child start function.</item>
- <item>Only accessible through the object reference returned by the start function.
- The object reference is no longer valid if the server dies and is restarted.</item>
- </list>
- <p>Using <c>Module_Interface:oe_create(Env, Options)</c>:</p>
- <list type="bulleted">
- <item>Initial data can be passed using <c>Env</c>.</item>
- <item>Cannot be used as a supervisor child start function.</item>
- <item>Accessible through the object reference returned by the start function. If the option
- <c>{regname, RegName}</c> is used the object reference stays valid even if the
- server has been restarted.</item>
- <item>If the options <c>{persistent, true}</c> and <c>{regname, {global, Name}}</c> is used,
- the result from an object invocation will be the exception 'OBJECT_NOT_EXIST'
- only if the object has terminated with reason
- <c>normal</c> or <c>shutdown</c>. If the object is in the process of restarting, the result
- will be <c>{error, Reason}</c> or a system exception is raised.</item>
- <item>The option <c>{pseudo, true}</c> makes it possible to start create non-server objects.
- There are, however, some limitations, which are further described in the
- <c>Pseudo objects</c> section.</item>
- </list>
- <p>Using <c>Module_Interface:oe_create_link(Env, Options)</c>:</p>
- <list type="bulleted">
- <item>Initial data can be passed using <c>Env</c>.</item>
- <item>Can be used as a supervisor child start function if the option <c>{sup_child, true}</c> used.</item>
- <item>Accessible through the object reference returned by the start function. If the option
- <c>{regname, RegName}</c> is used the object reference stays valid even if the
- server has been restarted.</item>
- <item>If the options <c>{persistent, true}</c> and <c>{regname, {global, Name}}</c> is used,
- the result from an object invocation will be the exception 'OBJECT_NOT_EXIST'
- only if the object has terminated with reason
- <c>normal</c> or <c>shutdown</c>. If the object is in the process of restarting, the result
- will be <c>{error, Reason}</c> or a system exception is raised.</item>
- <item>For starting a server as a supervisor child you should use the options
- <c>[{persistent, true}, {regname, {global, Name}}, {sup_child, true}]</c> and of type <em>transient</em>.
- This configuration allows you to delegate restarts to the supervisor and still be able to
- use the same object reference and be able to see if the server is permanently terminated.
- Please note you must use <em>supervisor/stdlib-1.7</em> or later and that the it returns
- <c>{ok, Pid, Object}</c> instead of just <c>Object</c>.</item>
- <item>Using the option <c>{pseudo, true}</c> have the same effect as using
- <c>oe_create/2</c>.</item>
- </list>
- <warning>
- <p>To avoid flooding Orber with old object references start erlang using the flag
- <em>-orber objectkeys_gc_time Time</em>, which will remove all object references
- related to servers being dead for Time seconds. To avoid extra overhead, i.e., performing
- garbage collect if no persistent objects are started, the objectkeys_gc_time default value
- is <em>infinity</em>. For more information, see the orber and corba documentation.</p>
- </warning>
- <warning>
- <p>Orber still allow <c>oe_create(Env, {Type,RegName})</c> and <c>oe_create_link(Env, {Type,RegName})</c> to be used,
- but may not in future releases.</p>
- </warning>
- </section>
-
- <section>
- <title>Pseudo Objects</title>
- <p>This section describes Orber pseudo objects.
- </p>
- <p>The Orber stub can be used to start a <c>pseudo object</c>, which will create a non-server implementation.
- A pseudo object introduce some limitations:</p>
- <list type="bulleted">
- <item>The functions <c>oe_create_link/2</c> is equal to <c>oe_create/2</c>, i.e.,
- no link can or will be created.</item>
- <item>The <c>BIF:s self()</c> and <c>process_flag(trap_exit,true)</c> behaves incorrectly.</item>
- <item>The <c>IC</c> option <c>{{impl, "M::I"}, "other_impl"}</c> has no effect. The call-back
- functions must be implemented in a file called <c>M_I_impl.erl</c></item>
- <item>The call-back functions must be implemented as if the <c>IC</c> option
- <c>{this, "M::I"}</c> was used.</item>
- <item>The gen_server <c>State</c> changes have no effect. The user can provide information via
- the <c>Env</c> start parameter and the State returned from <c>init/2</c> will be the State
- passed in following invocations.</item>
- <item>The server reply <c>Timeout</c> has no effect.</item>
- <item>The compile option <c>from</c> has no effect.</item>
- <item>The option <c>{pseudo, true}</c> overrides all other start options.</item>
- <item>Only the functions, besides own definitions, <c>init/2</c> (called via oe_create*/2) and
- <c>terminate/2</c> (called via corba:dispose/1) must be implemented.</item>
- </list>
- <p>By adopting the rules for <c>pseudo</c> objects described above we can use <c>oe_create/2</c>
- to create <c>server</c> or <c>pseudo</c> objects, by excluding or including the
- option <c>{pseudo, true}</c>, without changing the call-back module.</p>
- <p>To create a pseudo object do the following:</p>
- <code type="none">
-fingolfin 127> erl
-Erlang (BEAM) emulator version 4.9
-
-Eshell V4.9 (abort with ^G)
-1> ic:gen(myDefinition, [{this, "MyModule::MyInterface"}]).
-Erlang IDL compiler version 20
-ok
-2> make:all().
-Recompile: oe_MyDefinition
-Recompile: MyModule_MyInterface
-Recompile: MyModule_MyInterface_impl
-up_to_date
-3> PseudoObj = MyModule_MyInterface:oe_create(Env, [{pseudo, true}]).
- </code>
- <p>The call-back functions must be implemented as <c>MyFunction(OE_THIS, State, Args)</c>,
- and called by <c>MyModule_MyInterface:MyFunction(PseudoObj, Args)</c>.</p>
- </section>
-
- <section>
- <title>Call-back Module</title>
- <p>This section provides an example of how a call-back module may be implemented.</p>
- <note>
- <p>Arguments and Replies are determined by the IDL-code and, hence, not
- further described here.</p>
- </note>
- <code type="erl">
-%%%-----------------------------------------------------------
-%%% File : Module_Interface_impl.erl
-%%% Author :
-%%% Purpose :
-%%% Created :
-%%%-----------------------------------------------------------
-
--module('Module_Interface_impl').
-
-%%--------------- INCLUDES -----------------------------------
--include_lib("orber/include/corba.hrl").
--include_lib(".. ..").
-
-%%--------------- EXPORTS-------------------------------------
-%% Arity depends on IC configuration parameters and the IDL
-%% specification.
--export([own_function/X]).
-
-
-%%--------------- gen_server specific ------------------------
--export([init/1, terminate/2, code_change/3, handle_info/2]).
-
-%%------------------------------------------------------------
-%% function : server specific
-%%------------------------------------------------------------
-init(InitialData) ->
- %% 'trap_exit' optional (have no effect if pseudo object).
- process_flag(trap_exit,true),
-
- %%--- Possible replies ---
- %% Reply and await next request
- {ok, State}.
-
- %% Reply and if no more requests within Time the special
- %% timeout message should be handled in the
- %% Module_Interface_impl:handle_info/2 call-back function (use the
- %% IC option {{handle_info, "Module::Interface"}, true}).
- {ok, State, Timeout}
-
- %% Return ignore in order to inform the parent, especially if it is a
- %% supervisor, that the server, as an example, did not start in
- %% accordance with the configuration data.
- ignore
- %% If the initializing procedure fails, the reason
- %% is supplied as StopReason.
- {stop, StopReason}
-
-terminate(Reason, State) ->
- ok.
-
-code_change(OldVsn, State, Extra) ->
- {ok, NewState}.
-
-%% If use IC option {{handle_info, "Module::Interface"}, true}.
-%% (have no effect if pseudo object).
-handle_info(Info, State) ->
- %%--- Possible replies ---
- %% Await the next invocation.
- {noreply, State}.
- %% Stop with Reason.
- {stop, Reason, State}.
-
-%%--- two-way ------------------------------------------------
-%% If use IC option {this, "Module:Interface"}
-%% (Required for pseudo objects)
-own_function(This, State, .. Arguments ..) ->
-%% IC options this and from
-own_function(This, From, State, .. Arguments ..) ->
-%% IC option from
-own_function(From, State, .. Arguments ..) ->
- %% Send explicit reply to client.
- corba:reply(From, Reply),
- %%--- Possible replies ---
- {noreply, State}
- {noreply, State, Timeout}
-
-
-%% If not use IC option {this, "Module:Interface"}
-own_function(State, .. Arguments ..) ->
- %%--- Possible replies ---
- %% Reply and await next request
- {reply, Reply, State}
-
- %% Reply and if no more requests within Time the special
- %% timeout message should be handled in the
- %% Module_Interface_impl:handle_info/2 call-back function (use the
- %% IC option {{handle_info, "Module::Interface"}, true}).
- {reply, Reply, State, Timeout}
-
- %% Stop the server and send Reply to invoking object.
- {stop, StopReason, Reply, State}
-
- %% Stop the server and send no reply to invoking object.
- {stop, StopReason, State}
-
- %% Raise exception. Any changes to the internal State is lost.
- corba:raise(Exception).
-
-%%--- one-way ------------------------------------------------
-%% If use IC option {this, "Module:Interface"}
-%% (Required for pseudo objects)
-own_function(This, State, .. Arguments ..) ->
-
-%% If not use IC option {this, "Module:Interface"}
-own_function(State, .. Arguments ..) ->
- %%--- Possible results ---
- {noreply, State}
-
- %% Release and if no more requests within Time the special
- %% timeout message should be handled in the
- %% Module_Interface_impl:handle_info/2 call-back function (use the
- %% IC option {{handle_info, "Module::Interface"}, true}).
- {noreply, State, Timeout}
-
- %% Stop the server with StopReason.
- {stop, StopReason, State}
-
-%%--------------- END OF MODULE ------------------------------
- </code>
- </section>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/corba.xml b/lib/orber/doc/src/corba.xml
deleted file mode 100644
index fbfb55f2f2..0000000000
--- a/lib/orber/doc/src/corba.xml
+++ /dev/null
@@ -1,454 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>corba</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>1997-06-10</date>
- <rev>A</rev>
- </header>
- <module>corba</module>
- <modulesummary>The functions on CORBA module level</modulesummary>
- <description>
- <p>This module contains functions that are specified on the CORBA module
- level. It also contains some functions for creating and disposing
- objects.</p>
- </description>
- <funcs>
- <func>
- <name>create(Module, TypeID) -> Object</name>
- <name>create(Module, TypeID, Env) -> Object</name>
- <name>create(Module, TypeID, Env, Optons1) -> Object</name>
- <name>create_link(Module, TypeID) -> Object</name>
- <name>create_link(Module, TypeID, Env) -> Object</name>
- <name>create_link(Module, TypeID, Env, Options2) -> Reply</name>
- <fsummary>Create and start a new server object</fsummary>
- <type>
- <v>Module = atom()</v>
- <v>TypeID = string()</v>
- <v>Env = term()</v>
- <v>Options1 = [{persistent, Bool} | {regname, RegName} | {local_typecheck, Bool}]</v>
- <v>Options2 = [{sup_child, Bool} | {persistent, Bool} | {regname, RegName} | {pseudo, Bool} | {local_typecheck, Bool}]</v>
- <v>RegName = {local, atom()} | {global, term()}</v>
- <v>Reply = #objref | {ok, Pid, #objref}</v>
- <v>Bool = true | false</v>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>These functions start a new server object. If you start it
- without <em>RegName</em> it can only be accessed through the
- returned object key. Started with a <em>RegName</em> the name is
- registered locally or globally. </p>
- <p><em>TypeID</em> is the repository ID of the server object type and
- could for example look like "IDL:StackModule/Stack:1.0". </p>
- <p><em>Module</em> is the name of the interface API module. </p>
- <p><em>Env</em> is the arguments passed which will be passed to the
- implementations <em>init</em> call-back function.</p>
- <p>A server started with create/2, create/3 or create/4 does not care
- about the parent, which means that the parent is not handled
- explicitly in the generic process part. </p>
- <p>A server started with create_link2, create_link/3 or create_link/4
- is initially linked to the caller, the parent, and it will
- terminate whenever the parent process terminates, and with the same
- reason as the parent. If the server traps exits, the terminate/2
- call-back function is called in order to clean up before the
- termination. These functions should be used if the server is a
- worker in a supervision tree.</p>
- <p>If you use the option <c>{sup_child, true}</c> create_link/4 will return
- <c>{ok, Pid, #objref}</c>, otherwise <c>#objref</c>, and make it possible
- to start a server as a supervisor child (stdlib-1.7 or later).</p>
- <p>If you use the option <c>{persistent, true}</c> you also must use the option
- <c>{regname, {global, Name}}</c>. This combination makes it possible to tell
- the difference between a server permanently terminated or in the process of restarting.</p>
- <p>The option <c>{pseudo, true}</c>, allow us to create an object which is not a
- server. Using <c>{pseudo, true}</c> overrides all other start options.
- For more information see section <c>Module_Interface</c>.</p>
- <p>If a server is started using the option <c>{persistent, true}</c> the object key
- will not be removed unless it terminates with reason <em>normal</em> or <em>shutdown</em>.
- Hence, if persistent servers is used as supervisor children they should be <em>transient</em>
- and the <em>objectkeys_gc_time</em> should be modified (default equals <c>infinity</c>).</p>
- <p>The option <c>{local_typecheck, boolean()}</c>, which overrides the
- <seealso marker="ch_install#flags">Local Typechecking</seealso>
- environment flag, turns on or off typechecking. If activated,
- parameters, replies and raised exceptions will be checked to ensure that
- the data is correct, when invoking operations on CORBA Objects within
- the same Orber domain. Due to the extra overhead, this option
- <em>MAY ONLY</em> be used during testing and development.</p>
- <code type="none">
-Example:
-
- corba:create('StackModule_Stack', "IDL:StackModule/Stack:1.0", {10, test})
- </code>
- </desc>
- </func>
- <func>
- <name>dispose(Object) -> ok</name>
- <fsummary>Stop a server object</fsummary>
- <type>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>This function is used for terminating the execution of a
- server object. Invoking this operation on a NIL object reference,
- e.g., the return value of <c>corba:create_nil_objref/0</c>, always
- return ok. For valid object references, invoking this operation
- more than once, will result in a system exception.</p>
- </desc>
- </func>
- <func>
- <name>create_nil_objref() -> Object</name>
- <fsummary>Stop a server object</fsummary>
- <type>
- <v>Object = #objref representing NIL.</v>
- </type>
- <desc>
- <p>Creates an object reference that represents the NIL value.
- Attempts to invoke operations using the returned object reference
- will return a system exception.</p>
- </desc>
- </func>
- <func>
- <name>create_subobject_key(Object, Key) -> Result</name>
- <fsummary>Add an Erlang term to a private key field</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>Key = term()</v>
- <v>Result = #objref</v>
- </type>
- <desc>
- <p>This function is used to create a subobject in a server object.
- It can for example be useful when one wants unique access to
- separate rows in a mnesia or an ETS table. The <em>Result</em> is
- an object reference that will be seen as a unique reference to
- the outside world but will access the same server object where one
- can use the <em>get_subobject_key/1</em> function to get the private
- key value.</p>
- <p><em>Key</em> is stored in the object reference <em>Object</em>.
- If it is a binary it will be stored as is and otherwise it is
- converted to a binary before storage.</p>
- </desc>
- </func>
- <func>
- <name>get_subobject_key(Object) -> Result</name>
- <fsummary>Fetch the contents of the private key field</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>Result = #binary</v>
- </type>
- <desc>
- <p>This function is used to fetch a subobject key from the object
- reference <em>Object</em>. The result is a always a binary, if it
- was an Erlang term that was stored with <em>create_subobject_key/2</em>
- one can to do <em>binary_to_term/1</em> to get the real value. </p>
- </desc>
- </func>
- <func>
- <name>get_pid(Object) -> Result</name>
- <fsummary>Get the process id from an object key</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>Result = #pid | {error, Reason} | {'EXCEPTION',E}</v>
- </type>
- <desc>
- <p>This function is to get the process id from an object, which is a
- must when CORBA objects is started/handled in a supervisor tree.
- The function will throw exceptions if the key is not found or
- some other error occurs.</p>
- </desc>
- </func>
- <func>
- <name>raise(Exception)</name>
- <fsummary>Generate an Erlang throw</fsummary>
- <type>
- <v>Exception = record()</v>
- </type>
- <desc>
- <p>This function is used for raising corba exceptions as an
- Erlang user generated exit signal. It will throw the tuple
- <c>{'EXCEPTION', </c><em>Exception</em><c>}</c>.</p>
- </desc>
- </func>
- <func>
- <name>reply(To, Reply) -> true</name>
- <fsummary>Send explicit reply to client</fsummary>
- <type>
- <v>To = client reference</v>
- <v>Reply = IDL type</v>
- </type>
- <desc>
- <p>This function can be used by a CORBA object to explicitly send
- a reply to a client that invoked a two-way operation. If this operation
- is used, it is <em>not</em> possible to return a reply in the call-back
- module.
- <br></br>
-<em>To</em> must be the <em>From</em> argument provided to the
- callback function, which requires that the IC option <em>from</em>
- was used when compiling the IDL-file.</p>
- </desc>
- </func>
- <func>
- <name>resolve_initial_references(ObjectId) -> Object</name>
- <name>resolve_initial_references(ObjectId, Contexts) -> Object</name>
- <fsummary>Return the object reference for the given object id</fsummary>
- <type>
- <v>ObjectId = string()</v>
- <v>Contexts = [Context]</v>
- <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
- <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
- <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
- <v>Interface = string()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = ssl_client_options</v>
- <v>Value = allowed value associated with the given key</v>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>This function returns the object reference associated with the given
- object id. Initially, only <c>"NameService"</c> is available. To add or remove
- services use <c>add_initial_service/2</c> or <c>remove_initial_service/1</c>.</p>
- <p>The <em>configuration</em> context is used to override the global
- SSL client side
- <seealso marker="ch_install#config">configuration</seealso>.</p>
- </desc>
- </func>
- <func>
- <name>add_initial_service(ObjectId, Object) -> boolean()</name>
- <fsummary>Add a new initial service and associate it with the given id</fsummary>
- <type>
- <v>ObjectId = string()</v>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>This operation allows us to add initial services, which can be accessed by
- using <c>resolve_initial_references/1</c> or the <c>corbaloc</c> schema.
- If using an Id defined by the OMG, the given object must be of the
- correct type; for more information see the
- <seealso marker="ch_naming_service#interop_ns">Interoperable Naming Service</seealso>.
- Returns <c>false</c> if the given id already exists.</p>
- </desc>
- </func>
- <func>
- <name>remove_initial_service(ObjectId) -> boolean()</name>
- <fsummary>Remove association between the given id and service</fsummary>
- <type>
- <v>ObjectId = string()</v>
- </type>
- <desc>
- <p>If we don not want a certain service to be accessible, invoking this function
- will remove the association. Returns <c>true</c> if able to terminate the
- binding. If no such binding existed <c>false</c> is returned.</p>
- </desc>
- </func>
- <func>
- <name>list_initial_services() -> [ObjectId]</name>
- <fsummary>Return a list of supported object id's</fsummary>
- <type>
- <v>ObjectId = string()</v>
- </type>
- <desc>
- <p>This function returns a list of allowed object id's.</p>
- </desc>
- </func>
- <func>
- <name>resolve_initial_references_remote(ObjectId, Address) -> Object</name>
- <name>resolve_initial_references_remote(ObjectId, Address, Contexts) -> Object</name>
- <fsummary>Return the object reference for the given object id</fsummary>
- <type>
- <v>ObjectId = string()</v>
- <v>Address = [RemoteModifier]</v>
- <v>RemoteModifier = string()</v>
- <v>Contexts = [Context]</v>
- <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
- <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
- <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
- <v>Interface = string()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = ssl_client_options</v>
- <v>Value = allowed value associated with the given key</v>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>This function returns the object reference for the object id asked
- for.
- The remote modifier string has the following format:
- <c>"iiop://"&lt;host&gt;":"&lt;port&gt;</c> where <c>&lt;host&gt; = &lt;DNS hostname&gt; |
- &lt;IPv4 address&gt; | "["&lt;IPv6 address&gt;"]"</c>.
- </p>
- <p>The <em>configuration</em> context is used to override the global
- SSL client side
- <seealso marker="ch_install#config">configuration</seealso>.</p>
- <warning>
- <p>This operation is not supported by most ORB's. Hence, use
- <c>corba:string_to_object/1</c> instead.</p>
- </warning>
- </desc>
- </func>
- <func>
- <name>list_initial_services_remote(Address) -> [ObjectId]</name>
- <name>list_initial_services_remote(Address, Contexts) -> [ObjectId]</name>
- <fsummary>Return a list of supported object id's</fsummary>
- <type>
- <v>Address = [RemoteModifier]</v>
- <v>RemoteModifier = string()</v>
- <v>Contexts = [Context]</v>
- <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
- <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
- <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
- <v>Interface = string()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = ssl_client_options</v>
- <v>Value = allowed value associated with the given key</v>
- <v>ObjectId = string()</v>
- </type>
- <desc>
- <p>This function returns a list of allowed object id's.
- The remote modifier string has the following format:
- <c>"iiop://"&lt;host&gt;":"&lt;port&gt;</c> where <c>&lt;host&gt; = &lt;DNS hostname&gt; |
- &lt;IPv4 address&gt; | "["&lt;IPv6 address&gt;"]"</c>.
- </p>
- <p>The <em>configuration</em> context is used to override the global
- SSL client side
- <seealso marker="ch_install#config">configuration</seealso>.</p>
- <warning>
- <p>This operation is not supported by most ORB's. Hence, avoid
- using it.</p>
- </warning>
- </desc>
- </func>
- <func>
- <name>object_to_string(Object) -> IOR_string</name>
- <fsummary>Convert the object reference to the external string representation</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>IOR_string = string()</v>
- </type>
- <desc>
- <p>This function returns the object reference as the external string
- representation of an IOR.</p>
- </desc>
- </func>
- <func>
- <name>string_to_object(IOR_string) -> Object</name>
- <name>string_to_object(IOR_string, Contexts) -> Object</name>
- <fsummary>Convert the external string representation to an object reference</fsummary>
- <type>
- <v>IOR_string = string()</v>
- <v>Contexts = [Context]</v>
- <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
- <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
- <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
- <v>Interface = string()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = ssl_client_options</v>
- <v>Value = allowed value associated with the given key</v>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>This function takes a <c>corbaname</c>, <c>corbaloc</c> or an IOR on the
- external string representation and returns the object reference.</p>
- <p>To lookup the NameService reference, simply use:</p>
- <code>corbaloc:iiop:[email protected]:4001/NameService</code>
- <p>We can also resolve an object from the NameService by using:</p>
- <code>corbaname:iiop:[email protected]:4001/NameService#org/Erlang/MyObj</code>
- <p>To lookup the NameService reference with an IPv6 address, simply use:</p>
- <code>corbaloc:iiop:1.2@[FEC1:0:3:0:0312:44AF:FAB1:3D01]:4001/NameService</code>
- <p>For more information about <c>corbaname</c> and <c>corbaloc</c>, see
- the User's Guide (Interoperable Naming Service).</p>
- <p>The <em>configuration</em> context is used to override the global
- SSL client side
- <seealso marker="ch_install#config">configuration</seealso>.</p>
- <p>How to handle the interface context is further described in the User's Guide.</p>
- </desc>
- </func>
- <func>
- <name>print_object(Data [, Type]) -> ok | {'EXCEPTION', E} | {'EXIT', R} | string()</name>
- <fsummary>Print the supplied object</fsummary>
- <type>
- <v>Data = IOR_string | #objref (local or external) | corbaloc/corbaname string</v>
- <v>Type = IoDevice | error_report | {error_report, Reason} | info_msg | {info_msg, Comment} | string</v>
- <v>IoDevice = see the io-module</v>
- <v>Reason = Comment = string()</v>
- </type>
- <desc>
- <p>The object represented by the supplied data is dissected and presented
- in a more readable form. The Type parameter is optional; if not supplied
- standard output is used. For <c>error_report</c> and <c>info_msg</c>
- the <c>error_logger</c> module is used, with or without Reason or Comment.
- If the atom <c>string</c> is supplied this function will return a flat
- list. The <c>IoDevice</c> is passed to the operation <c>io:format/2</c>.</p>
- <p>If the supplied object is a local reference, the output is equivalent
- to an object exported from the node this function is invoked on.</p>
- </desc>
- </func>
- <func>
- <name>add_alternate_iiop_address(Object, Host, Port) -> NewObject | {'EXCEPTION', E}</name>
- <fsummary>Add ALTERNATE_IIOP_ADDRESS component to the supplied local object</fsummary>
- <type>
- <v>Object = NewObject = local #objref</v>
- <v>Host = string()</v>
- <v>Port = integer()</v>
- </type>
- <desc>
- <p>This operation creates a new instance of the supplied object
- containing an ALTERNATE_IIOP_ADDRESS component. Only the new instance
- contains the new component. When this object is passed to another
- ORB, which supports the ALTERNATE_IIOP_ADDRESS, requests will be routed
- to the alternate address if it is not possible to communicate with
- the main address.</p>
- <p>The ALTERNATE_IIOP_ADDRESS component requires that IIOP-1.2 is used.
- Hence, make sure both Orber and the other ORB is correctly configured.</p>
- <p></p>
- <note>
- <p>Make sure that the given <c>Object</c> is accessible via the
- alternate Host/port. For example, if the object is correctly started as
- <c>local</c> or <c>pseudo</c>, the object should be available on all
- nodes within a multi-node Orber installation. Since only one instance
- exists for other object types, it will not be possible to access it
- if the node it was started on terminates.</p>
- </note>
- </desc>
- </func>
- <func>
- <name>orb_init(KeyValueList) -> ok | {'EXIT', Reason}</name>
- <fsummary>Configure Orber before starting it</fsummary>
- <type>
- <v>KeyValueList = [{Key, Value}]</v>
- <v>Key = any key listed in the configuration chapter</v>
- <v>Value = allowed value associated with the given key</v>
- </type>
- <desc>
- <p>This function allows the user to configure Orber in, for example,
- an Erlang shell. Orber may <em>NOT</em> be started prior to invoking
- this operation. For more information, see
- <seealso marker="ch_install#config">configuration settings</seealso>
- in the User's Guide.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/corba_object.xml b/lib/orber/doc/src/corba_object.xml
deleted file mode 100644
index 09a4b0bc3c..0000000000
--- a/lib/orber/doc/src/corba_object.xml
+++ /dev/null
@@ -1,194 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year>
- <year>2016</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>corba_object</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>1997-11-10</date>
- <rev>A</rev>
- </header>
- <module>corba_object</module>
- <modulesummary>The CORBA Object interface functions</modulesummary>
- <description>
- <p>This module contains the CORBA Object interface functions that can be
- called for all objects.</p>
- </description>
- <funcs>
- <func>
- <name>get_interface(Object) -> InterfaceDef</name>
- <fsummary>Fetch the interface description</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>InterfaceDef = term()</v>
- </type>
- <desc>
- <p>This function returns the full interface description for an object.</p>
- </desc>
- </func>
- <func>
- <name>is_nil(Object) -> boolean()</name>
- <fsummary>Return true, if the given object is a NIL object reference, otherwise false</fsummary>
- <type>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>This function checks if the object reference has a nil object value,
- which denotes no object. It is the reference that is tested and no
- object implementation is involved in the test. </p>
- </desc>
- </func>
- <func>
- <name>is_a(Object, Logical_type_id) -> Return</name>
- <name>is_a(Object, Logical_type_id, Contexts) -> Return</name>
- <fsummary>Return true if the target object is an, or inherit from, object of the given type</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>Logical_type_id = string()</v>
- <v>Contexts = [Context]</v>
- <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
- <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
- <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
- <v>Interface = string()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = ssl_client_options</v>
- <v>Value = allowed value associated with the given key</v>
- <v>Return = boolean() | {'EXCEPTION', E}</v>
- </type>
- <desc>
- <p>The <em>Logical_type_id</em> is a string that is a share type
- identifier (repository id). The function returns true if the object
- is an instance of that type or an ancestor of the "most derived"
- type of that object.</p>
- <p>The <em>configuration</em> context is used to override the global
- SSL client side
- <seealso marker="ch_install#config">configuration</seealso>.</p>
- <p>Note: Other ORB suppliers may not support this function completely
- according to the OMG specification. Thus, a <em>is_a</em> call may
- raise an exception or respond unpredictable if the Object is
- located on a remote node.</p>
- </desc>
- </func>
- <func>
- <name>is_remote(Object) -> boolean()</name>
- <fsummary>Determine whether or not an object reference is remote</fsummary>
- <type>
- <v>Object = #objref</v>
- </type>
- <desc>
- <p>This function returns true if an object reference is remote
- otherwise false. </p>
- </desc>
- </func>
- <func>
- <name>non_existent(Object) -> Return</name>
- <name>non_existent(Object, Contexts) -> Return</name>
- <fsummary>Return false if the target object do not exist, otherwise true</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>Contexts = [Context]</v>
- <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
- <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
- <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
- <v>Interface = string()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = ssl_client_options</v>
- <v>Value = allowed value associated with the given key</v>
- <v>Return = boolean() | {'EXCEPTION', E}</v>
- </type>
- <desc>
- <p>This function can be used to test if the object has been destroyed.
- It does this without invoking any application level code. The ORB
- returns true if it knows that the object is destroyed otherwise
- false.</p>
- <p>The <em>configuration</em> context is used to override the global
- SSL client side
- <seealso marker="ch_install#config">configuration</seealso>.</p>
- <p>Note: The OMG have specified two different operators, <c>_not_existent</c> (CORBA version 2.0 and 2.2) and
- <c>_non_existent</c> (CORBA version 2.3), to be used for this function. It is not mandatory to support
- both versions. Thus, a <em>non_existent</em> call may raise an exception or respond unpredictable
- if the Object is located on a remote node. Depending on which version, ORB:s you intend to
- communicate with supports, you can either use this function or <c>not_existent/1</c>.</p>
- </desc>
- </func>
- <func>
- <name>not_existent(Object) -> Return</name>
- <name>not_existent(Object, Contexts) -> Return</name>
- <fsummary>Return false if the target object do not exist, otherwise true</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>Contexts = [Context]</v>
- <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
- <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
- <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
- <v>Interface = string()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = ssl_client_options</v>
- <v>Value = allowed value associated with the given key</v>
- <v>Return = boolean() | {'EXCEPTION', E}</v>
- </type>
- <desc>
- <p>This function is implemented due to Interoperable purposes. Behaves as
- <c>non_existent</c> except the operator <c>_not_existent</c> is used when
- communicating with other ORB:s.</p>
- <p>The <em>configuration</em> context is used to override the global
- SSL client side
- <seealso marker="ch_install#config">configuration</seealso>.</p>
- </desc>
- </func>
- <func>
- <name>is_equivalent(Object, OtherObject) -> boolean()</name>
- <fsummary>Return true if the target object and the supplied object easily can be determined to be equal, otherwise false</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>OtherObject = #objref</v>
- </type>
- <desc>
- <p>This function is used to determine if two object references are
- equivalent so far the ORB easily can determine. It returns
- <em>true</em> if the target object reference is equal to the
- other object reference and <em>false</em> otherwise.</p>
- </desc>
- </func>
- <func>
- <name>hash(Object, Maximum) -> int()</name>
- <fsummary>Return a hash value based on the target object</fsummary>
- <type>
- <v>Object = #objref</v>
- <v>Maximum = int()</v>
- </type>
- <desc>
- <p>This function returns a hash value based on the object reference
- that not will change during the lifetime of the object.
- The <em>Maximum</em> parameter denotes the upper bound of the value.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/dataframe1.gif b/lib/orber/doc/src/dataframe1.gif
deleted file mode 100644
index 21bd0afbc5..0000000000
--- a/lib/orber/doc/src/dataframe1.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/dataframe2.gif b/lib/orber/doc/src/dataframe2.gif
deleted file mode 100644
index 26778932b4..0000000000
--- a/lib/orber/doc/src/dataframe2.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/dataframe3.gif b/lib/orber/doc/src/dataframe3.gif
deleted file mode 100644
index db8ffef7d1..0000000000
--- a/lib/orber/doc/src/dataframe3.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/dataframe4.gif b/lib/orber/doc/src/dataframe4.gif
deleted file mode 100644
index f64c7f3733..0000000000
--- a/lib/orber/doc/src/dataframe4.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/dataframe5.gif b/lib/orber/doc/src/dataframe5.gif
deleted file mode 100644
index 80e17945a2..0000000000
--- a/lib/orber/doc/src/dataframe5.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/dataframe6.gif b/lib/orber/doc/src/dataframe6.gif
deleted file mode 100644
index fb1c5d7827..0000000000
--- a/lib/orber/doc/src/dataframe6.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/dataframe7.gif b/lib/orber/doc/src/dataframe7.gif
deleted file mode 100644
index 1e18078f0a..0000000000
--- a/lib/orber/doc/src/dataframe7.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/dataframe8.gif b/lib/orber/doc/src/dataframe8.gif
deleted file mode 100644
index ef95c9a11f..0000000000
--- a/lib/orber/doc/src/dataframe8.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/dependent.gif b/lib/orber/doc/src/dependent.gif
deleted file mode 100644
index c65c427421..0000000000
--- a/lib/orber/doc/src/dependent.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/example_part.xml b/lib/orber/doc/src/example_part.xml
deleted file mode 100644
index 61c9524cc3..0000000000
--- a/lib/orber/doc/src/example_part.xml
+++ /dev/null
@@ -1,36 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE part SYSTEM "part.dtd">
-
-<part>
- <header>
- <copyright>
- <year>2002</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Service Implementation</title>
- <prepared>Niclas Eklund</prepared>
- <docno></docno>
- <date>2002-06-25</date>
- <rev>A</rev>
- </header>
- <description>
- <p>This chapter describe how to implement Orber based CORBA services.</p>
- </description>
- <include file="ch_stubs"></include>
-</part>
-
diff --git a/lib/orber/doc/src/firewall_nat.gif b/lib/orber/doc/src/firewall_nat.gif
deleted file mode 100644
index 3a80aac724..0000000000
--- a/lib/orber/doc/src/firewall_nat.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/fixed.xml b/lib/orber/doc/src/fixed.xml
deleted file mode 100644
index ef4d1bd604..0000000000
--- a/lib/orber/doc/src/fixed.xml
+++ /dev/null
@@ -1,160 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>2002</year><year>2017</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>fixed</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>2002-05-22</date>
- <rev>A</rev>
- </header>
- <module>fixed</module>
- <modulesummary>the corba fixed type</modulesummary>
- <description>
- <p>This module contains functions that gives an interface to the CORBA fixed type.</p>
- <p>The type <c>Fixed</c> used below is defined as:</p>
- <code type="erl">
--record(fixed, {digits, scale, value}).
- </code>
- <p>where <c>digits</c> is the total amount of digits it consists of and
- <c>scale</c> is the number of fractional digits. The <c>value</c> field
- contains the actual Fixed value represented as an integer. The limitations
- of each field are:</p>
- <list type="bulleted">
- <item>Digits - integer(), -1 > Digits &lt; 32</item>
- <item>Scale - integer(), -1 > Scale =&lt; Digits</item>
- <item>Value - integer(), range (31 digits): &plusmn;9999999999999999999999999999999</item>
- </list>
- <p>Since the Value part is represented by an integer, it is vital that the
- Digits and Scale values are correct. This also means that trailing zeros
- cannot be left out in some cases:</p>
- <list type="bulleted">
- <item>fixed&lt;5,3> eq. 03.140d eq. 3140</item>
- <item>fixed&lt;3,2> eq. 3.14d eq. 314</item>
- </list>
- <p>Leading zeros can be left out.</p>
- <p>For your convenience, this module exports functions which handle
- unary (<c>-</c>) and binary (<c>+-*/</c>) operations legal for the Fixed type.
- Since a unary <c>+</c> have no effect, this module do not export such a
- function. Any of the binary operations may cause an overflow (i.e. more than
- 31 significant digits; leading and trailing zeros are not considered
- significant). If this is the case, the Digit and Scale values are adjusted
- and the Value truncated (no rounding performed). This behavior is
- compliant with the OMG CORBA specification. Each binary operation have
- the following upper bounds:</p>
- <list type="bulleted">
- <item><em>Fixed1 + Fixed2</em> - <c><![CDATA[fixed<max(d1-s1,d2-s2) + max(s1,s2) + 1, max(s1,s2)>]]></c></item>
- <item><em>Fixed1 - Fixed2</em> - <c><![CDATA[fixed<max(d1-s1,d2-s2) + max(s1,s2) + 1, max(s1,s2)>]]></c></item>
- <item><em>Fixed1 * Fixed2</em> - <c><![CDATA[fixed<d1+d2, s1+s2>]]></c></item>
- <item><em>Fixed1 / Fixed2</em> - <c><![CDATA[fixed<(d1-s1+s2) + Sinf ,Sinf >]]></c></item>
- </list>
- <p>A quotient may have an arbitrary number of decimal places, which is
- denoted by a scale of Sinf.</p>
- </description>
- <funcs>
- <func>
- <name>create(Digits, Scale, Value) -> Result</name>
- <fsummary>Create a fixed type</fsummary>
- <type>
- <v>Result = Fixed Type | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- </type>
- <desc>
- <p>This function creates a new instance of a <c>Fixed Type</c>. If
- the limitations is not fulfilled (e.g. overflow) an exception is
- raised.</p>
- </desc>
- </func>
- <func>
- <name>get_typecode(Fixed) -> Result</name>
- <fsummary>Create TypeCode representing the supplied fixed type</fsummary>
- <type>
- <v>Result = TypeCode | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- </type>
- <desc>
- <p>Returns the TypeCode which represents the supplied Fixed type.
- If the parameter is not of the correct type, an exception is raised.</p>
- </desc>
- </func>
- <func>
- <name>add(Fixed1, Fixed2) -> Result</name>
- <fsummary>Add the supplied Fixed types</fsummary>
- <type>
- <v>Result = Fixed1 + Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- </type>
- <desc>
- <p>Performs a Fixed type addition.
- If the parameters are not of the correct type, an exception is raised.</p>
- </desc>
- </func>
- <func>
- <name>subtract(Fixed1, Fixed2) -> Result</name>
- <fsummary>Subtract Fixed2 from Fixed1</fsummary>
- <type>
- <v>Result = Fixed1 - Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- </type>
- <desc>
- <p>Performs a Fixed type subtraction.
- If the parameters are not of the correct type, an exception is raised.</p>
- </desc>
- </func>
- <func>
- <name>multiply(Fixed1, Fixed2) -> Result</name>
- <fsummary>Multiply Fixed1 with Fixed2</fsummary>
- <type>
- <v>Result = Fixed1 * Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- </type>
- <desc>
- <p>Performs a Fixed type multiplication.
- If the parameters are not of the correct type, an exception is raised.</p>
- </desc>
- </func>
- <func>
- <name>divide(Fixed1, Fixed2) -> Result</name>
- <fsummary>Divide Fixed1 with Fixed2</fsummary>
- <type>
- <v>Result = Fixed1 / Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- </type>
- <desc>
- <p>Performs a Fixed type division.
- If the parameters are not of the correct type, an exception is raised.</p>
- </desc>
- </func>
- <func>
- <name>unary_minus(Fixed) -> Result</name>
- <fsummary>Negate the supplied Fixed Type</fsummary>
- <type>
- <v>Result = -Fixed | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- </type>
- <desc>
- <p>Negates the supplied Fixed type.
- If the parameter is not of the correct type, an exception is raised.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/ifr_notes.txt b/lib/orber/doc/src/ifr_notes.txt
deleted file mode 100644
index 54f79be8cd..0000000000
--- a/lib/orber/doc/src/ifr_notes.txt
+++ /dev/null
@@ -1,53 +0,0 @@
--*-Mode: Outline;-*-
-
-* Transactions.
- Transaction handling (or the use of mnesia:async_dirty) is not very
- good at error checking. Code to handle errors from transactions must
- be added. Right now it is not possible to mix atomic transactions
- with dirty 'transactions' (i.e. async_dirty) and still check the
- results consistently. This must be fixed if we are to read with
- async_dirty instead of transaction, since we still want to do all
- the writes with transaction and not async_dirty.
- (This point might be moot. Simple reads are now done with
- mnesia:dirty_read/1 outside of transactions).
-
-* Unresolved issues.
- There are some places in the source code marked with '***' where the
- code should be verified. It mostly concerns minor unresolved
- unclarities in the specification.
-
-** orber_ifr_contained.erl
- In move/4 there is a call to orber_ifr_contained:lookup_name/5. The
- third argument, Levels_to_search, is set to -1, which means search
- all contained objects. This is probably correct.
-
-** orber_ifr_interfacedef.erl
- The function describe_interface/1 describes the interface without
- its inherited interfaces. It is not clear whether this is correct or
- not. It is possible to get a description of the inherited interfaces
- by mapping describe_interface/1 on the list if interfaces returned
- by get_base_interfaces/1. Also, since the structs
- InterfaceDescription and FullInterfaceDescription both have a field
- named base_interfaces, it is possible to get a description of the
- inherited attributes by examining that field and applying a describe
- function.
-
-** orber_ifr_orb.erl
- create_union_tc/4 sets the fifth element in the typecode tuple to
- -1, meaning no default case.
-
-** orber_ifr_repository.erl
- The PrimitiveDef with kind pk_objref has an empty Id and an empty
- Name. This is perhaps not correct.
-
-** orber_ifr_typecode.erl
- None of the functions in this module are fully implemented and they
- should not be used.
-
-** orber_ifr_uniondef.erl
-*** '_set_members'/2
- What should the value of the discriminator-typecode be when updating
- the type attribute? (CORBA 2.0, p 6-20). For now we just leave it
- unchanged, but this is perhaps not the right thing to do.
-
-* Exceptions should give more information about the failure.
diff --git a/lib/orber/doc/src/iiop.gif b/lib/orber/doc/src/iiop.gif
deleted file mode 100644
index d2f2fd128c..0000000000
--- a/lib/orber/doc/src/iiop.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/GridBagEx.gif b/lib/orber/doc/src/images/GridBagEx.gif
deleted file mode 100644
index 16c326d88c..0000000000
--- a/lib/orber/doc/src/images/GridBagEx.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/OpenBookIcon.gif b/lib/orber/doc/src/images/OpenBookIcon.gif
deleted file mode 100644
index 86384f7733..0000000000
--- a/lib/orber/doc/src/images/OpenBookIcon.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/blue-ball-small.gif b/lib/orber/doc/src/images/blue-ball-small.gif
deleted file mode 100644
index d4c5cde5b0..0000000000
--- a/lib/orber/doc/src/images/blue-ball-small.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/blue-ball.gif b/lib/orber/doc/src/images/blue-ball.gif
deleted file mode 100644
index edc29b786c..0000000000
--- a/lib/orber/doc/src/images/blue-ball.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/class-index.gif b/lib/orber/doc/src/images/class-index.gif
deleted file mode 100644
index 7f276bcb24..0000000000
--- a/lib/orber/doc/src/images/class-index.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/constructor-index.gif b/lib/orber/doc/src/images/constructor-index.gif
deleted file mode 100644
index 435cac4238..0000000000
--- a/lib/orber/doc/src/images/constructor-index.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/constructors.gif b/lib/orber/doc/src/images/constructors.gif
deleted file mode 100644
index d1a6ae507c..0000000000
--- a/lib/orber/doc/src/images/constructors.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/cyan-ball-small.gif b/lib/orber/doc/src/images/cyan-ball-small.gif
deleted file mode 100644
index 7f74357443..0000000000
--- a/lib/orber/doc/src/images/cyan-ball-small.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/cyan-ball.gif b/lib/orber/doc/src/images/cyan-ball.gif
deleted file mode 100644
index 97ca1f2b6e..0000000000
--- a/lib/orber/doc/src/images/cyan-ball.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/error-index.gif b/lib/orber/doc/src/images/error-index.gif
deleted file mode 100644
index 22835ff8c6..0000000000
--- a/lib/orber/doc/src/images/error-index.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/exception-index.gif b/lib/orber/doc/src/images/exception-index.gif
deleted file mode 100644
index e3830d9c52..0000000000
--- a/lib/orber/doc/src/images/exception-index.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/green-ball-small.gif b/lib/orber/doc/src/images/green-ball-small.gif
deleted file mode 100644
index 17fea5b32b..0000000000
--- a/lib/orber/doc/src/images/green-ball-small.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/green-ball.gif b/lib/orber/doc/src/images/green-ball.gif
deleted file mode 100644
index 71e1b2ec2d..0000000000
--- a/lib/orber/doc/src/images/green-ball.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/interface-index.gif b/lib/orber/doc/src/images/interface-index.gif
deleted file mode 100644
index bf93dda9e3..0000000000
--- a/lib/orber/doc/src/images/interface-index.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/magenta-ball-small.gif b/lib/orber/doc/src/images/magenta-ball-small.gif
deleted file mode 100644
index bd0584b3c6..0000000000
--- a/lib/orber/doc/src/images/magenta-ball-small.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/magenta-ball.gif b/lib/orber/doc/src/images/magenta-ball.gif
deleted file mode 100644
index 5da03b84d2..0000000000
--- a/lib/orber/doc/src/images/magenta-ball.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/method-index.gif b/lib/orber/doc/src/images/method-index.gif
deleted file mode 100644
index a05e705116..0000000000
--- a/lib/orber/doc/src/images/method-index.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/methods.gif b/lib/orber/doc/src/images/methods.gif
deleted file mode 100644
index 949e01b8a3..0000000000
--- a/lib/orber/doc/src/images/methods.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/package-index.gif b/lib/orber/doc/src/images/package-index.gif
deleted file mode 100644
index f894d4210d..0000000000
--- a/lib/orber/doc/src/images/package-index.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/red-ball-small.gif b/lib/orber/doc/src/images/red-ball-small.gif
deleted file mode 100644
index f6b3c372ca..0000000000
--- a/lib/orber/doc/src/images/red-ball-small.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/red-ball.gif b/lib/orber/doc/src/images/red-ball.gif
deleted file mode 100644
index dca9296014..0000000000
--- a/lib/orber/doc/src/images/red-ball.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/variable-index.gif b/lib/orber/doc/src/images/variable-index.gif
deleted file mode 100644
index 65cc029e72..0000000000
--- a/lib/orber/doc/src/images/variable-index.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/variables.gif b/lib/orber/doc/src/images/variables.gif
deleted file mode 100644
index e8a735399a..0000000000
--- a/lib/orber/doc/src/images/variables.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/yellow-ball-small.gif b/lib/orber/doc/src/images/yellow-ball-small.gif
deleted file mode 100644
index 8e5f57cdfc..0000000000
--- a/lib/orber/doc/src/images/yellow-ball-small.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/images/yellow-ball.gif b/lib/orber/doc/src/images/yellow-ball.gif
deleted file mode 100644
index 2b8c0bb3d6..0000000000
--- a/lib/orber/doc/src/images/yellow-ball.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/interceptor_operations.gif b/lib/orber/doc/src/interceptor_operations.gif
deleted file mode 100644
index cd72f7fcb7..0000000000
--- a/lib/orber/doc/src/interceptor_operations.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/interceptors.xml b/lib/orber/doc/src/interceptors.xml
deleted file mode 100644
index 0aade8ffb4..0000000000
--- a/lib/orber/doc/src/interceptors.xml
+++ /dev/null
@@ -1,284 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>2001</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>interceptors</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>1999-09-03</date>
- <rev>A</rev>
- </header>
- <module>interceptors</module>
- <modulesummary>Describe the functions which must be exported by any supplied Orber native interceptor.</modulesummary>
- <description>
- <p>This module contains the mandatory functions for user supplied native
- interceptors and their intended behavior. See also the User's Guide.</p>
- <warning>
- <p>Using <c>Interceptors</c> may reduce the through-put significantly
- if the supplied interceptors invoke expensive operations. Hence,
- one should always supply interceptors which cause as little overhead
- as possible.</p>
- </warning>
- <warning>
- <p>It is possible to alter the <c>Data</c>, <c>Bin</c> and <c>Args</c>
- parameter for the <c>in_reply</c> and <c>out_reply</c>,
- <c>in_reply_encoded</c>, <c>in_request_encoded</c>,
- <c>out_reply_encoded</c> and <c>out_request_encoded</c>,
- <c>in_request</c> and <c>out_request</c> respectively. But,
- if it is done incorrectly, the consequences can be serious.</p>
- </warning>
- <note>
- <p>The <c>Extra</c> parameter is set to 'undefined' by Orber when calling
- the first interceptor and may be set to any Erlang term. If an
- interceptor change this parameter it will be passed on to the next
- interceptor in the list uninterpreted.</p>
- </note>
- <note>
- <p>The <c>Ref</c> parameter is set to 'undefined' by Orber when calling
- <c>new_in_connection</c> or <c>new_out_connection</c> using
- the first interceptor. The user supplied interceptor may set <c>NewRef</c>
- to any Erlang term. If an interceptor change this parameter it will be
- passed on to the next interceptor in the list uninterpreted.</p>
- </note>
- </description>
- <funcs>
- <func>
- <name>new_in_connection(Ref, PeerHost, PeerPort) -> NewRef</name>
- <name>new_in_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef</name>
- <fsummary>Invoke when a new client ORB wants to setup a connection</fsummary>
- <type>
- <v>Ref = term() | undefined</v>
- <v>PeerHost = SocketHost = string(), e.g., "myHost@myServer" or "192.0.0.10"</v>
- <v>PeerPort = SocketPort = integer()</v>
- <v>NewRef = term() | {'EXIT', Reason}</v>
- </type>
- <desc>
- <p>When a new connection is requested by a client side ORB this operation
- is invoked. If more than one interceptor is supplied, e.g.,
- <c>{native, ['myInterceptor1', 'myInterceptor2']}</c>, the return value
- from 'myInterceptor1' is passed to 'myInterceptor2' as <c>Ref</c>.
- Initially, Orber uses the atom 'undefined' as <c>Ref</c> parameter
- when calling the first interceptor. The return value from the last
- interceptor, in the example above 'myInterceptor2', is passed
- to all other functions exported by the interceptors. Hence,
- the <c>Ref</c> parameter can, for example, be used as a unique
- identifier to mnesia or ets where information/restrictions for
- this connection is stored.</p>
- <p>The PeerHost and PeerPort variables supplied data of
- the client ORB which requested a new connection. SocketHost
- and SocketPort are the local interface and port the client
- connected to.</p>
- <p>If, for some reason, we do not allow the client ORB to connect
- simply invoke <c>exit(Reason)</c>.</p>
- </desc>
- </func>
- <func>
- <name>new_out_connection(Ref, PeerHost, PeerPort) -> NewRef</name>
- <name>new_out_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef</name>
- <fsummary>Invoke when setting up a new connection to a server side ORB</fsummary>
- <type>
- <v>Ref = term() | undefined</v>
- <v>PeerHost = SocketHost = string(), e.g., "myHost@myServer" or "192.0.0.10"</v>
- <v>PeerPort = SocketPort = integer()</v>
- <v>NewRef = term() | {'EXIT', Reason}</v>
- </type>
- <desc>
- <p>When a new connection is set up this function is invoked. Behaves
- just like <c>new_in_connection</c>; the only difference is that
- the PeerHost and PeerPort variables identifies the target ORB's bootstrap
- data and SocketHost and SocketPort are the local interface and port
- the client ORB connected via.</p>
- </desc>
- </func>
- <func>
- <name>closed_in_connection(Ref) -> NewRef</name>
- <fsummary>Invoke when an existing connection to a client side ORB have been terminated</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>NewRef = term()</v>
- </type>
- <desc>
- <p>When an existing connection is terminated this operation is invoked.
- The main purpose of this function is to make it possible for a user
- to clean up all data associated with the associated connection.</p>
- <p>The input parameter <c>Ref</c> is the return value from
- <c>new_in_connection/3</c>.</p>
- </desc>
- </func>
- <func>
- <name>closed_out_connection(Ref) -> NewRef</name>
- <fsummary>Invoke when an existing connection to a server side ORB have been terminated</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>NewRef = term()</v>
- </type>
- <desc>
- <p>When an existing connection is terminated this operation is invoked.
- The main purpose of this function is to make it possible for a user
- to clean up all data associated with the associated connection.</p>
- <p>The input parameter <c>Ref</c> is the return value from
- <c>new_out_connection/3</c>.</p>
- </desc>
- </func>
- <func>
- <name>in_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply</name>
- <fsummary>Invoke when replies arrives at the client side ORB</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>Obj = #objref</v>
- <v>Ctx = [#'IOP_ServiceContext'{}]</v>
- <v>Op = atom()</v>
- <v>Data = [Result, OutParameter1, ..., OutPramaterN]</v>
- <v>Reply = {NewData, NewExtra}</v>
- </type>
- <desc>
- <p>When replies are delivered from the server side ORB to the client side
- ORB this operation is invoked. The <c>Data</c> parameter is a list in which
- the first element is the return value value from the target object and
- the rest is a all parameters defined as <c>out</c> or <c>inout</c> in
- the IDL-specification.</p>
- </desc>
- </func>
- <func>
- <name>in_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name>
- <fsummary>Invoke when replies arrives at the client side ORB with undecoded reply body</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>Obj = #objref</v>
- <v>Ctx = [#'IOP_ServiceContext'{}]</v>
- <v>Op = atom()</v>
- <v>Bin = #binary</v>
- <v>Reply = {NewBin, NewExtra}</v>
- </type>
- <desc>
- <p>When replies are delivered from the server side ORB to the client side
- ORB this operation is invoked. The <c>Bin</c> parameter is the reply
- body still uncoded.</p>
- </desc>
- </func>
- <func>
- <name>in_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply</name>
- <fsummary>Invoke when requests arrive at the server side ORB</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>Obj = #objref</v>
- <v>Ctx = [#'IOP_ServiceContext'{}]</v>
- <v>Op = atom()</v>
- <v>Args = [Argument] - defined in the IDL-specification</v>
- <v>Reply = {NewArgs, NewExtra}</v>
- </type>
- <desc>
- <p>When a new request arrives at the server side ORB this operation is
- invoked.</p>
- </desc>
- </func>
- <func>
- <name>in_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name>
- <fsummary>Invoke when requests arrive at the server side ORB with undecoded request body</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>Obj = #objref</v>
- <v>Ctx = [#'IOP_ServiceContext'{}]</v>
- <v>Op = atom()</v>
- <v>Bin = #binary</v>
- <v>Reply = {NewBin, NewExtra}</v>
- </type>
- <desc>
- <p>When a new request arrives at the server side ORB this operation is
- invoked before decoding the request body.</p>
- </desc>
- </func>
- <func>
- <name>out_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply</name>
- <fsummary>Invoke after the target object replied</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>Obj = #objref</v>
- <v>Ctx = [#'IOP_ServiceContext'{}]</v>
- <v>Op = atom()</v>
- <v>Data = [Result, OutParameter1, ..., OutPramaterN]</v>
- <v>Reply = {NewData, NewExtra}</v>
- </type>
- <desc>
- <p>After the target object have been invoked this operation is invoked
- with the result. The <c>Data</c> parameter is a list in which
- the first element is the return value value from the target object and
- the rest is a all parameters defined as <c>out</c> or <c>inout</c> in
- the IDL-specification.</p>
- </desc>
- </func>
- <func>
- <name>out_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name>
- <fsummary>Invoke after the target object replied with the reply encoded</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>Obj = #objref</v>
- <v>Ctx = [#'IOP_ServiceContext'{}]</v>
- <v>Op = atom()</v>
- <v>Bin = #binary</v>
- <v>Reply = {NewBin, NewExtra}</v>
- </type>
- <desc>
- <p>This operation is similar to <c>out_reply</c>; the only difference is
- that the reply body have been encoded.</p>
- </desc>
- </func>
- <func>
- <name>out_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply</name>
- <fsummary>Invoke on the client side ORB before encoding and sending the request</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>Obj = #objref</v>
- <v>Ctx = [#'IOP_ServiceContext'{}]</v>
- <v>Op = atom()</v>
- <v>Args = [Argument] - defined in the IDL-specification</v>
- <v>Reply = {NewArgs, NewExtra}</v>
- </type>
- <desc>
- <p>Before a request is sent to the server side ORB, <c>out_request</c> is
- invoked.</p>
- </desc>
- </func>
- <func>
- <name>out_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name>
- <fsummary>Invoke on the client side ORB before sending the request</fsummary>
- <type>
- <v>Ref = term()</v>
- <v>Obj = #objref</v>
- <v>Ctx = [#'IOP_ServiceContext'{}]</v>
- <v>Op = atom()</v>
- <v>Bin = #binary</v>
- <v>Reply = {NewBin, NewExtra}</v>
- </type>
- <desc>
- <p>This operation is similar to <c>out_request</c>; the only
- difference is that the request body have been encoded.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/intro_part.xml b/lib/orber/doc/src/intro_part.xml
deleted file mode 100644
index 7e5520e42e..0000000000
--- a/lib/orber/doc/src/intro_part.xml
+++ /dev/null
@@ -1,41 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE part SYSTEM "part.dtd">
-
-<part>
- <header>
- <copyright>
- <year>2002</year>
- <year>2016</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>Introduction to Orber and the IFR</title>
- <prepared>Niclas Eklund</prepared>
- <docno></docno>
- <date>2002-06-25</date>
- <rev>A</rev>
- </header>
- <description>
- <p>This chapter contains an introduction to Orber and the IFR
- (Interface Repository).</p>
- </description>
- <include file="ch_introduction"></include>
- <include file="ch_orber_kernel"></include>
- <include file="ch_ifr"></include>
-</part>
-
diff --git a/lib/orber/doc/src/lname.xml b/lib/orber/doc/src/lname.xml
deleted file mode 100644
index c0c9be1a85..0000000000
--- a/lib/orber/doc/src/lname.xml
+++ /dev/null
@@ -1,166 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>lname</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>1997-06-10</date>
- <rev>A</rev>
- </header>
- <module>lname</module>
- <modulesummary>Interface that supports the name pseudo-objects.</modulesummary>
- <description>
- <p>This interface is a part of the names library which is used to hide the
- representation of names. In Orbers Erlang mapping the pseudo-object names
- and the real IDL names have the same representation but it is desirable that
- the clients uses the names library so they will not be dependent of the representation.
- The lname interface supports handling of names e.g. adding and removing name
- components.</p>
- <p>Note that the lname interface in orber does not contain a destroy function because
- the Names are represented as standard Erlang lists and therefor will be removed
- by the garbage collector when not in use.</p>
- <p>The type <c>NameComponent</c> used below is defined as:</p>
- <code type="erl">
--record('CosNaming_NameComponent', {id, kind=""}).
- </code>
- <p><c>id</c> and <c>kind</c> are strings. </p>
- <p>The record is defined in the file <c>CosNaming.hrl</c> and it
- is included with:</p>
- <code type="erl">
--include_lib("orber/COSS/CosNaming/CosNaming.hrl").
- </code>
- </description>
- <funcs>
- <func>
- <name>create() -> Return</name>
- <fsummary>Create a new name</fsummary>
- <type>
- <v>Return = [NameComponent]</v>
- </type>
- <desc>
- <p>This function returns a new name.</p>
- </desc>
- </func>
- <func>
- <name>insert_component(Name, N, NameComponent) -> Return</name>
- <fsummary>Insert a new name component in a name</fsummary>
- <type>
- <v>Name = [NameComponent]</v>
- <v>N = int()</v>
- <v>Return = Name</v>
- </type>
- <desc>
- <p>This function returns a name where the new name component has been inserted as
- component <c>N</c> in Name.</p>
- </desc>
- </func>
- <func>
- <name>get_component(Name, N) -> Return</name>
- <fsummary>Get a name component from a name</fsummary>
- <type>
- <v>Name = [NameComponent]</v>
- <v>N = int()</v>
- <v>Return = NameComponent</v>
- </type>
- <desc>
- <p>This function returns the <c>N:th</c> name component in Name.</p>
- </desc>
- </func>
- <func>
- <name>delete_component(Name, N) -> Return</name>
- <fsummary>Delete a name component from a name</fsummary>
- <type>
- <v>Name = [NameComponent]</v>
- <v>N = int()</v>
- <v>Return = Name</v>
- </type>
- <desc>
- <p>This function deletes the <c>N:th</c> name component from Name and returns
- the new name.</p>
- </desc>
- </func>
- <func>
- <name>num_component(Name) -> Return</name>
- <fsummary>Count the number of name components in a name</fsummary>
- <type>
- <v>Name = [NameComponent]</v>
- <v>Return = int()</v>
- </type>
- <desc>
- <p>This function returns a the number of name components in Name.</p>
- </desc>
- </func>
- <func>
- <name>equal(Name1, Name2) -> Return</name>
- <fsummary>Test if two names are equal</fsummary>
- <type>
- <v>Name1 = Name2 = [NameComponent]</v>
- <v>Return = bool()</v>
- </type>
- <desc>
- <p>This function returns true if the two names are equal and false otherwise.</p>
- </desc>
- </func>
- <func>
- <name>less_than(Name1, Name2) -> Return</name>
- <fsummary>Test if one name is lesser than the other</fsummary>
- <type>
- <v>Name1 = Name2 = [NameComponent]</v>
- <v>Return = bool()</v>
- </type>
- <desc>
- <p>This function returns true if Name1 are lesser than Name2 and false otherwise.</p>
- </desc>
- </func>
- <func>
- <name>to_idl_form(Name) -> Return</name>
- <fsummary>Transform a pseudo name to an IDL name</fsummary>
- <type>
- <v>Name = [NameComponent]</v>
- <v>Return = Name</v>
- </type>
- <desc>
- <p>This function just checks if Name is a correct IDL name before returning it
- because the name representation is the same for pseudo and IDL names in orber.</p>
- </desc>
- </func>
- <func>
- <name>from_idl_form(Name) -> Return</name>
- <fsummary>Transform an IDL name to a pseudo name</fsummary>
- <type>
- <v>Name = [NameComponent]</v>
- <v>Return = Name</v>
- </type>
- <desc>
- <p>This function just returns the Name because the name representation is the
- same for pseudo and IDL names in orber.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/lname_component.xml b/lib/orber/doc/src/lname_component.xml
deleted file mode 100644
index 8b8001c0fb..0000000000
--- a/lib/orber/doc/src/lname_component.xml
+++ /dev/null
@@ -1,113 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year><year>2017</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>lname_component</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>1997-06-10</date>
- <rev>A</rev>
- </header>
- <module>lname_component</module>
- <modulesummary>Interface that supports the name pseudo-objects.</modulesummary>
- <description>
- <p>This interface is a part of the name library, which is used to hide the
- representation of names. In Orbers Erlang mapping the pseudo-object names
- and the real IDL names have the same representation but it is desirable that
- the clients uses the names library so they will not be dependent of the representation.
- The lname_component interface supports handling of name components e.g. set and get
- of the struct members.</p>
- <p>Note that the lname_component interface in orber does not contain a destroy
- function because the NameComponents are represented as Erlang records and
- therefor will be removed by the garbage collector when not in use.</p>
- <p>The type <c>NameComponent</c> used below is defined as:</p>
- <code type="erl">
--record('CosNaming_NameComponent', {id, kind=""}).
- </code>
- <p><c>id</c> and <c>kind</c> are strings. </p>
- <p>The record is defined in the file <c>CosNaming.hrl</c> and it
- is included with:</p>
- <code type="erl">
--include_lib("orber/COSS/CosNaming/CosNaming.hrl").
- </code>
- </description>
- <funcs>
- <func>
- <name>create() -> Return</name>
- <fsummary>Create a new name component</fsummary>
- <type>
- <v>Return = NameComponent</v>
- </type>
- <desc>
- <p>This function returns a new name component.</p>
- </desc>
- </func>
- <func>
- <name>get_id(NameComponent) -> Return</name>
- <fsummary>Get the id field of a name component</fsummary>
- <type>
- <v>Return = string()</v>
- </type>
- <desc>
- <p>This function returns the id string of a name component.</p>
- </desc>
- </func>
- <func>
- <name>set_id(NameComponent, Id) -> Return</name>
- <fsummary>Set the id field of a name component</fsummary>
- <type>
- <v>Id = string()</v>
- <v>Return = NameComponent</v>
- </type>
- <desc>
- <p>This function sets the id string of a name component and returns the component.</p>
- </desc>
- </func>
- <func>
- <name>get_kind(NameComponent) -> Return</name>
- <fsummary>Get the kind field of a name component</fsummary>
- <type>
- <v>Return = string()</v>
- </type>
- <desc>
- <p>This function returns the id string of a name component.</p>
- </desc>
- </func>
- <func>
- <name>set_kind(NameComponent, Kind) -> Return</name>
- <fsummary>Set the kind field of a name component</fsummary>
- <type>
- <v>Kind = string()</v>
- <v>Return = NameComponent</v>
- </type>
- <desc>
- <p>This function sets the kind string of a name component and returns the component.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/menuframe.gif b/lib/orber/doc/src/menuframe.gif
deleted file mode 100644
index 57a437e6b0..0000000000
--- a/lib/orber/doc/src/menuframe.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/name.gif b/lib/orber/doc/src/name.gif
deleted file mode 100644
index d2df460092..0000000000
--- a/lib/orber/doc/src/name.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/notes.xml b/lib/orber/doc/src/notes.xml
deleted file mode 100644
index 35da4f73da..0000000000
--- a/lib/orber/doc/src/notes.xml
+++ /dev/null
@@ -1,860 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
- <header>
- <copyright>
- <year>1997</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Orber Release Notes</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>99-02-12</date>
- <rev>A</rev>
- <file>notes.xml</file>
- </header>
-
- <section><title>Orber 3.8.4</title>
-
- <section><title>Fixed Bugs and Malfunctions</title>
- <list>
- <item>
- <p> Removed all old unused files in the documentation.
- </p>
- <p>
- Own Id: OTP-14475 Aux Id: ERL-409, PR-1493 </p>
- </item>
- <item>
- <p> Removed the man warnings by using the code tag
- instead of c tag. </p>
- <p>
- Own Id: OTP-14673</p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.8.3</title>
-
- <section><title>Improvements and New Features</title>
- <list>
- <item>
- <p>
- Fix some dialyzer warnings</p>
- <p>
- Own Id: OTP-14006</p>
- </item>
- </list>
- </section>
-
- </section>
-
- <section><title>Orber 3.8.2</title>
-
- <section><title>Improvements and New Features</title>
- <list>
- <item>
- <p>
- Internal changes</p>
- <p>
- Own Id: OTP-13551</p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.8.1</title>
-
- <section><title>Improvements and New Features</title>
- <list>
- <item>
- <p> Suppress Dialyzer warnings. </p>
- <p>
- Own Id: OTP-12862</p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.8</title>
-
- <section><title>Improvements and New Features</title>
- <list>
- <item>
- <p> Remove the usage of erlang:now() from all Corba
- applications and use the new rand module instead of
- random. </p>
- <p>
- Own Id: OTP-12687</p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.7.1</title>
-
- <section><title>Fixed Bugs and Malfunctions</title>
- <list>
- <item>
- <p> Fixed problem with IPv6 addresses in Service Context
- when orber is default configured for IPv4. </p>
- <p>
- Own Id: OTP-12193</p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.7</title>
-
- <section><title>Fixed Bugs and Malfunctions</title>
- <list>
- <item>
- <p> The following functions have been corrected so they
- work properly with IPv6 addresses. </p> <list>
- <item><c>corba:resolve_initial_references_remote/2/3</c></item>
- <item><c>corba:list_initial_references_remote/1/2</c></item>
- <item><c>corba:string_to_object/1/2</c></item> </list>
- <p>
- Own Id: OTP-12016</p>
- </item>
- <item>
- <p> A couple of macros were malformed, missing commas:
- PROFILEBODY_1_1_TYPEDEF and PROFILEBODY_1_2_TYPEDEF.
- Thanks to Vlad Dumitrescu. </p>
- <p>
- Own Id: OTP-12062</p>
- </item>
- </list>
- </section>
-
-
- <section><title>Improvements and New Features</title>
- <list>
- <item>
- <p> It is now possible to add listen interfaces for IPv6
- when orber is default configured for IPv4 and the other
- way around. For more information, consult the User's
- Guide and the orber module Reference Manual. </p>
- <p>
- Own Id: OTP-12007</p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.6.27</title>
-
- <section><title>Fixed Bugs and Malfunctions</title>
- <list>
- <item>
- <p>
- Some local implementations of removing the last element
- from a list are replaced by <c>lists:droplast/1</c>. Note
- that this requires at least <c>stdlib-2.0</c>, which is
- the stdlib version delivered in OTP 17.0. (Thanks to Hans
- Svensson)</p>
- <p>
- Own Id: OTP-11678</p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.6.26.1</title>
-
- <section><title>Improvements and New Features</title>
- <list>
- <item>
- <p> Postscript files no longer needed for the generation
- of PDF files have been removed. </p>
- <p>
- Own Id: OTP-11016</p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.6.26</title>
-
- <section><title>Fixed Bugs and Malfunctions</title>
- <list>
- <item>
- <p>
- Fix bug in corbaloc/corbaname over ssl.</p>
- <p>
- Own Id: OTP-10675</p>
- </item>
- </list>
- </section>
-
- </section>
-
- <section><title>Orber 3.6.25</title>
-
- <section><title>Improvements and New Features</title>
- <list>
- <item>
- <p> Some examples overflowing the width of PDF pages have
- been corrected. </p>
- <p>
- Own Id: OTP-10665</p>
- </item>
- </list>
- </section>
-
- <section><title>Known Bugs and Problems</title>
- <list>
- <item>
- <p>
- Own Id: OTP-10675 Aux Id: seq12154
- </p>
- </item>
- </list>
- </section>
-</section>
-
-<section><title>Orber 3.6.24</title>
-
- <section><title>Fixed Bugs and Malfunctions</title>
- <list>
- <item>
- <p>
- Fix number of arguments in orber dbg printout</p>
- <p>
- Own Id: OTP-9887</p>
- </item>
- <item>
- <p> The descriptions of <c>ssl_server_options</c> and
- <c>ssl_client_options</c> are corrected.<br/> Seq. Id:
- seq12018 </p>
- <p>
- Own Id: OTP-9966 Aux Id: OTP-9773 </p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.6.23</title>
-
- <section><title>Fixed Bugs and Malfunctions</title>
- <list>
- <item>
- <p> Remove usage of ssl:seed/1 in orber test cases. </p>
- <p>
- Own Id: OTP-9728</p>
- </item>
- </list>
- </section>
-
-
- <section><title>Improvements and New Features</title>
- <list>
- <item>
- <p>Erlang/OTP can now be built using parallel make if you
- limit the number of jobs, for instance using '<c>make
- -j6</c>' or '<c>make -j10</c>'. '<c>make -j</c>' does not
- work at the moment because of some missing
- dependencies.</p>
- <p>
- Own Id: OTP-9451</p>
- </item>
- <item>
- <p> The SSL option handling has been changed. There are
- now two new orber options <c>ssl_server_options</c> and
- <c>ssl_client_options</c> which takes a list of options
- to the socket. </p> <p> The old options are now
- deprecated and removed from the documentation but they
- can still be used for backward compatibility as long as
- the two new options not are used. </p> <p> If
- <c>ssl_server_options</c> and <c>ssl_client_options</c>
- contain an TCP option that <c>orber</c> needs to set to a
- specific value it will be skipped and a warning will be
- written to the error_log. </p>
- <p>
- Own Id: OTP-9773 Aux Id: seq11932 </p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section><title>Orber 3.6.22</title>
-
- <section><title>Fixed Bugs and Malfunctions</title>
- <list>
- <item>
- <p> XML files have been corrected. </p>
- <p>
- Own Id: OTP-9550 Aux Id: OTP-9541 </p>
- </item>
- </list>
- </section>
-
-</section>
-
-<section>
- <title>Orber 3.6.21</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>
- Eliminated Dialyzer warnings.</p>
- <p>
- Own Id: OTP-9326 Aux Id:</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.20</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>
- Eliminated Dialyzer warnings when using exit or throw.</p>
- <p>
- Own Id: OTP-9050 Aux Id:</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.19</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>
- Partial support for recursive structs and unions.
- Only available for the erl_corba backend and requires
- that Light IFR is used. I.e. the IC option {light_ifr, true}
- and that Orber is configured in such a way that Light IFR
- is activated. Recursive TypeCode is currently not supported.</p>
- <p>
- Own Id: OTP-8868 Aux Id: seq11633</p>
- </item>
- </list>
- </section>
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>The SSL option {ssl_imp, old} was not used if ssl_generation was
- set to 2. Only R14B was affected by this.</p>
- <p>Own Id: OTP-8994 Aux Id: seq11747</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.18</title>
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>A corbaloc http string could return an EXIT message, instead
- of a system exception, if the HTTP server closed the socket
- without returning a complete message. I.e. header and a body
- containing a stringified IOR.</p>
- <p>Own Id: OTP-8900 Aux Id: seq11704</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.17</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>
- Eliminated warnings for auto-imported BIF clashes.</p>
- <p>
- Own Id: OTP-8840</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.16</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>
- Test suites published.</p>
- <p>
- Own Id: OTP-8543O Aux Id:</p>
- </item>
- </list>
- </section>
-
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>Added missing trailing bracket to define in hrl-file.</p>
- <p>Own Id: OTP-8489 Aux Id:</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.15</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>
- Added the configuration parameters iiop_out_ports_attempts and
- iiop_out_ports_random.</p>
- <p>
- Own Id: OTP-8448 Aux Id: seq11498</p>
- </item>
- <item>
- <p>
- Removed obsolete SSL dependency.</p>
- <p>
- Own Id: OTP-8374 Aux Id:</p>
- </item>
- <item>
- <p>
- Removed the usage of the codeinclude tag in the documentation.</p>
- <p>
- Own Id: OTP-8409 Aux Id:</p>
- </item>
- </list>
- </section>
-
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>Removed superfluous VT in the documentation.</p>
- <p>Own Id: OTP-8353 Aux Id:</p>
- </item>
- <item>
- <p>Removed superfluous backslash in the documentation.</p>
- <p>Own Id: OTP-8354 Aux Id:</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.14</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>
- The documentation is now built with open source tools (xsltproc and fop)
- that exists on most platforms. One visible change is that the frames are removed.</p>
- <p>
- Own Id: OTP-8201 Aux Id:</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.13</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Obsolete guards, e.g. record vs is_record, has been changed
- to avoid compiler warnings.</p>
- <p>Own Id: OTP-7987</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.12</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Only the source instance of InitialReference.java is now
- included. Users are adviced to use the Interoperable
- Naming Service (INS) instead. INS is a part of the OMG
- standard specification.</p>
- <p>*** POTENTIAL INCOMPATIBILITY ***</p>
- <p>Own Id: OTP-7906 Aux Id: seq11243</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.11</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Updated file headers.</p>
- <p>Own Id: OTP-7837</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.10</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Documentation source included in open source releases.</p>
- <p>Own Id: OTP-7595</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.9</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Updated file headers.</p>
- <p>Own Id: OTP-7011</p>
- </item>
- <item>
- <p>Now compliant with the new behavior of stdlib.</p>
- <p>Own Id: OTP-7030 Aux Id: seq10827</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.8</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>When a local port range has been defined (i.e. iiop_out_ports),
- Orber set the socket option reuseaddr to true and after one
- timed out connection attempt no other port in the given range
- is used for that particular connect attempt.</p>
- <p>Own Id: OTP-6844 Aux Id: </p>
- </item>
- <item>
- <p>Possible to override global SSL parameters when using
- local interfaces.</p>
- <p>Own Id: OTP-6869 Aux Id: seq10742</p>
- </item>
- </list>
- </section>
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>The parameter ssl_client_ciphers was used on the server side as well
- instead of ssl_server_ciphers.</p>
- <p>Own Id: OTP-6868 Aux Id:</p>
- </item>
- <item>
- <p>The configuration parameter iiop_max_in_requests was ignored, until
- the first incoming request arrived, if iiop_packet_size was set.</p>
- <p>Own Id: OTP-6912 Aux Id:</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.7</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>The documentation source has been converted from SGML to XML.</p>
- <p>Own Id: OTP-6754 Aux Id: </p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.6</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>It is now possible to configure incoming connections which
- overrides some global configuration parameters. See
- orber:add_listen_interface/2/3.</p>
- <p>Own Id: OTP-6696 Aux Id: </p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.5</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Removed some unused code.</p>
- <p>Own Id: OTP-6527 Aux Id: </p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.4</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Orber can now be configured so that different NAT parameters
- can be specified for different interfaces.</p>
- <p>Own Id: OTP-6165 Aux Id: </p>
- </item>
- <item>
- <p>It is now possible to set the keepalive option for incoming
- and outgoing IIOP connections. For more information, see the
- Configuration chapter in the User's Guide.</p>
- <p>Own Id: OTP-6370 Aux Id: seq10532</p>
- </item>
- <item>
- <p>The new function orber:close_connection/1/2 allows a client
- to close connections to an object residing on a remote ORB.</p>
- <p>Own Id: OTP-6371 Aux Id: seq10532</p>
- </item>
- <item>
- <p>Orber now use the SSL two-phase accept strategy to avoid
- that new incoming connections via SSL are not blocked
- by a previous connect attempt that never initiated the
- SSL handshake. Note, the configuration parameter
- iiop_ssl_accept_timeout should be set (default infinity).
- For more information, see the Configuration chapter in the
- User's Guide. If Orber is started in secure mode, the
- installed SSL version must support ssl:ssl_accept/1/2 and
- ssl:transport_accept/1/2.</p>
- <p>Own Id: OTP-6372 Aux Id: seq10105</p>
- </item>
- </list>
- </section>
-
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>The operation orber_ifr:contents/2 could only handle dk_All.</p>
- <p>Own Id: OTP-6385 Aux Id:</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.3</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>When installing Orber it is now possible to set the priority
- for Orber internal Mnesia tables. For more information, see the
- Reference Manual regarding orber:install/2.</p>
- <p>Own Id: OTP-5907 Aux Id: seq10156</p>
- </item>
- <item>
- <p>The operation corba_object:is_a/2/3 now only connect to a remote
- ORB if necessary (i.e. the target object inherits from objects
- associated with the given IFR id).</p>
- <p>Own Id: OTP-5908</p>
- </item>
- </list>
- </section>
-
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>The operation corba_object:is_remote/1 always returned
- true, which was introduced in orber-3.2.10.</p>
- <p>Own Id: OTP-5909</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.2</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Native interceptors may now export new_in_connection and
- new_out_connection operations with arity 5. If this is the
- case, information about the local interface and port is
- passed to the interceptor. Orber's built in interceptors
- have been changed to include this information as well.</p>
- <p>Own Id: OTP-5671</p>
- </item>
- </list>
- </section>
-
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>In some cases, e.g. incorrect GIOP headers or a CancelRequest
- containing a non-existing RequestId, the incoming connection
- would be terminated.</p>
- <p>Own Id: OTP-5672 Aux Id: seq10037</p>
- </item>
- <item>
- <p>If combining the 'Use Current Interface in IOR' and
- 'Use IPv6' flags, exported IOR:s contained an incorrect
- host address.</p>
- <p>Own Id: OTP-5673</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6.1</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>Reduced overhead when using outgoing ACL with a local interface
- defined.</p>
- <p>Own Id: OTP-5659</p>
- </item>
- <item>
- <p>Added guards to ensure that, when so required, a list
- of IOP_ServiceContext's is passed instead of, for example,
- just the context record.</p>
- <p>Own Id: OTP-5660</p>
- </item>
- </list>
- </section>
-
- <section>
- <title>Fixed Bugs and Malfunctions</title>
- <list type="bulleted">
- <item>
- <p>The documentation referred to two different context definitions,
- the incorrect ServiceContext and the correct IOP_ServiceContext.
- The hrl file PATH/include/corba.hrl also contained the incorrect
- record definition. This has now been updated so that only
- IOP_ServiceContext is used and referred to.</p>
- <p>Own Id: OTP-5658</p>
- </item>
- </list>
- </section>
- </section>
-
- <section>
- <title>Orber 3.6</title>
-
- <section>
- <title>Improvements and New Features</title>
- <list type="bulleted">
- <item>
- <p>It is now possible to define a Access Control List (ACL),
- which limits the host and ports Orber may connect to or
- accept connections from.</p>
- <p>Own Id: OTP-5567</p>
- </item>
- <item>
- <p>It is now possible to add, and remove, listen interfaces.
- For more information, consult the User's Guide and the
- orber module Reference Manual.</p>
- <p>Own Id: OTP-5568</p>
- </item>
- <item>
- <p>It is now possible to activate and deactivate Audit/Trail
- logging. One of the three built in interceptors will be used
- depending on the requested verbosity.</p>
- <p>Own Id: OTP-5569</p>
- </item>
- <item>
- <p>It is now possible to configure Orber to add the interface,
- to exported local IOR:s, a Request came via.</p>
- <p>Own Id: OTP-5570</p>
- </item>
- <item>
- <p>It is now possible to instruct Orber which local interface an outgoing Request
- shall be sent via. To accomplish this the Orber generic context must be
- added added to each invocation.</p>
- <p>Own Id: OTP-5571</p>
- </item>
- <item>
- <p>It is now possible to define a default local interface,
- which Orber will use when connecting to another ORB.</p>
- <p>Own Id: OTP-5583</p>
- </item>
- </list>
- </section>
- </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/orber.xml b/lib/orber/doc/src/orber.xml
deleted file mode 100644
index d8c6936515..0000000000
--- a/lib/orber/doc/src/orber.xml
+++ /dev/null
@@ -1,653 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>orber</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>1997-06-10</date>
- <rev>A</rev>
- </header>
- <module>orber</module>
- <modulesummary>The main module of the Orber application</modulesummary>
- <description>
- <p>This module contains the functions for starting and stopping the
- application. It also has some utility functions to get some of
- the configuration information from running application.</p>
- </description>
- <funcs>
- <func>
- <name>start() -> ok</name>
- <name>start(Type) -> ok</name>
- <fsummary>Start the Orber application</fsummary>
- <type>
- <v>Type = temporary | permanent</v>
- </type>
- <desc>
- <p>Starts the Orber application (it also starts mnesia if it is not running).
- Which <c>Type</c> parameter is supplied determines the behavior. If not
- supplied Orber is started as <c>temporary</c>.
- See the Reference Manual <em>application(3)</em> for further information. </p>
- </desc>
- </func>
- <func>
- <name>jump_start(Attributes) -> ok | {'EXIT', Reason}</name>
- <fsummary>Start the Orber application during tests</fsummary>
- <type>
- <v>Attributes = Port | Options</v>
- <v>Port = integer()</v>
- <v>Options = [{Key, Value}]</v>
- <v>Key = any key listed in the configuration chapter</v>
- <v>Value = allowed value associated with the given key</v>
- </type>
- <desc>
- <p>Installs and starts the Orber and the Mnesia applications with the configuration
- parameters <c>domain</c> and <c>iiop_port</c> set to <c>"IP-number:Port"</c>
- and the supplied Port respectively. Theses settings are in most cases
- sufficient to ensure that no clash with any other Orber instance occur.
- If this operation fails, check if the listen port (iiop_port) is already
- in use. This function <em>MAY ONLY</em> be used during development and
- tests; how Orber is configured when using this operation may change
- at any time without warning.</p>
- </desc>
- </func>
- <func>
- <name>stop() -> ok</name>
- <fsummary>Stop the Orber application</fsummary>
- <desc>
- <p>Stops the Orber application.</p>
- </desc>
- </func>
- <func>
- <name>info() -> ok</name>
- <name>info(IoType) -> ok | {'EXIT', Reason} | string()</name>
- <fsummary>Generate Info Report, which contain Orber's configuration settings</fsummary>
- <type>
- <v>IoType = info_msg | string | io | {io, IoDevice}</v>
- </type>
- <desc>
- <p>Generates an Info Report, which contain Orber's configuration settings.
- If no <c>IoType</c> is supplied, <c>info_msg</c> is used (see the
- error_logger documentation). When the atom string is supplied this
- function will return a flat list. For <c>io</c> and <c>{io, IoDevice}</c>,
- <c>io:format/1</c> and <c>io:format/3</c> is used respectively.</p>
- </desc>
- </func>
- <func>
- <name>exception_info(Exception) -> {ok, string()} | {error, Reason}</name>
- <fsummary>Return a printable string, which describes the supplied exception</fsummary>
- <desc>
- <p>Returns a printable string, which describes the supplied exception
- in greater detail. Note, this function is mainly intended for
- system exceptions.</p>
- </desc>
- </func>
- <func>
- <name>is_system_exception(Exception) -> true | false</name>
- <fsummary>Return true if the supplied exception is a system defined exception otherwise false</fsummary>
- <desc>
- <p>Returns true if the supplied exception is a system defined
- exception, otherwise false.</p>
- </desc>
- </func>
- <func>
- <name>get_tables() -> [Tables]</name>
- <fsummary>Get the Mnesia tables Orber uses.</fsummary>
- <desc>
- <p>Returns a list of the Orber specific Mnesia tables. This list is
- required to restore Mnesia if it has been partitioned.</p>
- </desc>
- </func>
- <func>
- <name>get_ORBInitRef() -> string() | undefined</name>
- <fsummary>Get the initial reference address.</fsummary>
- <desc>
- <p>This function returns undefined if we will resolve references locally,
- otherwise a string describing which host we will contact if the Key given
- to <c>corba:resolve_initial_references/1</c> matches the Key set
- in this configuration variable. For more information
- see the user's guide.</p>
- </desc>
- </func>
- <func>
- <name>get_ORBDefaultInitRef() -> string() | undefined</name>
- <fsummary>Get the initial reference address.</fsummary>
- <desc>
- <p>This function returns undefined if we will resolve references locally,
- otherwise a string describing which host, or hosts, from which we
- will try to resolve the Key given to
- <c>corba:resolve_initial_references/1</c>. For more information
- see the user's guide.</p>
- </desc>
- </func>
- <func>
- <name>domain() -> string()</name>
- <fsummary>Display the Orber domain name</fsummary>
- <desc>
- <p>This function returns the domain name of the current Orber domain
- as a string.</p>
- </desc>
- </func>
- <func>
- <name>iiop_port() -> int()</name>
- <fsummary>Display the IIOP port number</fsummary>
- <desc>
- <p>This function returns the port-number, which is used by the IIOP
- protocol. It can be configured by setting the application variable
- <em>iiop_port</em>, if it is not set it will have the default number
- 4001.</p>
- </desc>
- </func>
- <func>
- <name>iiop_out_ports() -> 0 | {Min, Max}</name>
- <fsummary>Display the ports Orber may use when connecting to another ORB</fsummary>
- <desc>
- <p>The return value of this operation is what the configuration
- parameter <seealso marker="ch_install#config">iiop_out_ports</seealso>
- has been set to.</p>
- </desc>
- </func>
-
- <func>
- <name>iiop_out_ports_random() -> true | false</name>
- <fsummary>Determine if Orber should select local ports randomly</fsummary>
- <desc>
- <p>Return the value of the configuration parameter
- <seealso marker="ch_install#config">iiop_out_ports_random</seealso>.</p>
- </desc>
- </func>
-
- <func>
- <name>iiop_out_ports_attempts() -> int()</name>
- <fsummary>Display if Orber should accept more than one timeout connecting to another ORB</fsummary>
- <desc>
- <p>Return the value of the configuration parameter
- <seealso marker="ch_install#config">iiop_out_ports_attempts</seealso>.</p>
- </desc>
- </func>
-
-
- <func>
- <name>iiop_ssl_port() -> int()</name>
- <fsummary>Display the IIOP port number used for secure connections</fsummary>
- <desc>
- <p>This function returns the port-number, which is used by the secure IIOP
- protocol. It can be configured by setting the application variable
- <em>iiop_ssl_port</em>, if it is not set it will have the default number
- 4002 if Orber is to configured to run in secure mode. Otherwise it returns -1.</p>
- </desc>
- </func>
- <func>
- <name>iiop_timeout() -> int() (milliseconds)</name>
- <fsummary>Display the IIOP timeout value</fsummary>
- <desc>
- <p>This function returns the timeout value after which outgoing IIOP requests terminate.
- It can be configured by setting the application variable
- <em>iiop_timeout TimeVal (seconds)</em>, if it is not set it will have the default value
- <em>infinity</em>. If a request times out a system exception, e.g.
- <em>TIMEOUT</em>, is raised.</p>
- <p>Note: the iiop_timeout configuration parameter (TimeVal) may only range between 0 and 1000000 seconds.
- Otherwise, the default value is used.</p>
- <p>Note: Earlier IC versions required that the compile option <c>{timeout,"module::interface"}</c>,
- was used, which allow the user to add an extra timeout parameter, e.g.,
- <c>module_interface:function(ObjRef, Timeout, ... Arguments ...)</c> or
- <c>module_interface:function(ObjRef, [{timeout, Timeout}], ... Arguments ...)</c>,
- instead of <c>module_interface:function(ObjRef, ... Arguments ...)</c>.
- This is no longer the case and if the extra Timeout is used,
- argument will override the configuration parameter <c>iiop_timeout</c>.
- It is, however, not possible
- to use <c>infinity</c> to override the Timeout parameter. The Timeout
- option is also valid for objects which resides within the same Orber domain.</p>
- </desc>
- </func>
- <func>
- <name>iiop_connection_timeout() -> int() (milliseconds)</name>
- <fsummary>Display the IIOP connection timeout value</fsummary>
- <desc>
- <p>This function returns the timeout value after which outgoing IIOP connections terminate.
- It can be configured by setting the application variable
- <em>iiop_connection_timeout TimeVal (seconds)</em>, if it is not set it will have the default value
- <em>infinity</em>. The connection will not be terminated if there are
- pending requests.</p>
- <p>Note: the iiop_connection_timeout configuration parameter (TimeVal) may only range between 0 and 1000000 seconds.
- Otherwise, the default value is used.</p>
- </desc>
- </func>
- <func>
- <name>iiop_connections() -> Result</name>
- <name>iiop_connections(Direction) -> Result</name>
- <fsummary>List all existing connections to/from other ORB's</fsummary>
- <type>
- <v>Direction = in | out | inout</v>
- <v>Result = [{Host, Port}] | [{Host, Port, Interface}] | {'EXIT',Reason}</v>
- <v>Host = string()</v>
- <v>Port = integer()</v>
- <v>Interface = string()</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>The list returned by this operation contain tuples of remote hosts/ports
- Orber is currently connected to. If no Direction is not supplied, both
- incoming and outgoing connections are included.</p>
- <p>If a specific local interface has been defined for the connection,
- this will be added to the returned tuple.</p>
- </desc>
- </func>
- <func>
- <name>iiop_connections_pending() -> Result</name>
- <fsummary>List all connections to another ORB currently being set up</fsummary>
- <type>
- <v>Result = [{Host, Port}] | [{Host, Port, Interface}] | {'EXIT',Reason}</v>
- <v>Host = string()</v>
- <v>Port = integer()</v>
- <v>Interface = string()</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>In some cases a connection attempt (i.e. trying to communicate with
- another ORB) may block due to a number of reasons. This operation
- allows the user to check if this is the case. The returned list
- contain tuples of remote hosts/ports. Normally, the list is empty.</p>
- <p>If a specific local interface has been defined for the connection,
- this will be added to the returned tuple.</p>
- </desc>
- </func>
- <func>
- <name>iiop_in_connection_timeout() -> int() (milliseconds)</name>
- <fsummary>Display the IIOP connection timeout value for incoming connections</fsummary>
- <desc>
- <p>This function returns the timeout value after which incoming IIOP
- connections terminate. It can be configured by setting the application
- variable <em>iiop_in_connection_timeout TimeVal (seconds)</em>, if it is
- not set it will have the default value <em>infinity</em>. The connection
- will not be terminated if there are pending requests.</p>
- <p>Note: the iiop_in_connection_timeout configuration parameter (TimeVal) may
- only range between 0 and 1000000 seconds. Otherwise, the default value is
- used.</p>
- </desc>
- </func>
- <func>
- <name>iiop_acl() -> Result</name>
- <fsummary>Return the ACL configuration</fsummary>
- <type>
- <v>Result = [{Direction, Filter}] | [{Direction, Filter, [Interface]}]</v>
- <v>Direction = tcp_in | ssl_in | tcp_out | ssl_out</v>
- <v>Filter = string()</v>
- <v>Interface = string()</v>
- </type>
- <desc>
- <p>Returns the ACL configuration. The <c>Filter</c> uses a extended format of
- Classless Inter Domain Routing (CIDR). For example, <c>"123.123.123.10"</c> limits
- the connection to that particular host, while <c>"123.123.123.10/17"</c> allows
- connections to or from any host equal to the 17 most significant bits. Orber
- also allow the user to specify a certain port or port range, for example,
- <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c>
- respectively. IPv4 or none compressed IPv6 strings are accepted. <br></br>
-
- The list of <c>Interfaces</c>, IPv4 or IPv6 strings, are currently only used
- for outgoing connections and may only contain <em>one</em> address. If set and
- access is granted, Orber will use that local interface when connecting to the
- other ORB. The module <seealso marker="orber_acl">orber_acl</seealso>
- provides operations for evaluating the access control for filters and addresses.</p>
- </desc>
- </func>
- <func>
- <name>activate_audit_trail() -> Result</name>
- <name>activate_audit_trail(Verbosity) -> Result</name>
- <fsummary>Activate IIOP audit/trail</fsummary>
- <type>
- <v>Verbosity = stealth | normal | verbose</v>
- <v>Result = ok | {error, Reason}</v>
- <v>Reason = string()</v>
- </type>
- <desc>
- <p>Activates audit/trail for all existing incoming and outgoing IIOP
- connections. The <c>Verbosity</c> parameter, <c>stealth</c>,
- <c>normal</c> or <c>verbose</c>, determines which of the built in
- interceptors is used (<c>orber_iiop_tracer_stealth</c>,
- <c>orber_iiop_tracer_silent</c> or <c>orber_iiop_tracer</c> respectively).
- If no verbosity level is supplied, then the <c>normal</c> will be used.</p>
- <p>In case Orber is configured to use other interceptors, the audit/trail
- interceptors will simply be added to that list.</p>
- </desc>
- </func>
- <func>
- <name>deactivate_audit_trail() -> Result</name>
- <fsummary>Deactivate IIOP audit/trail</fsummary>
- <type>
- <v>Result = ok | {error, Reason}</v>
- <v>Reason = string()</v>
- </type>
- <desc>
- <p>Deactivates audit/trail for all existing incoming and outgoing IIOP
- connections. In case Orber is configured to use other interceptors,
- those will still be used.</p>
- </desc>
- </func>
- <func>
- <name>add_listen_interface(IP, Type) -> Result</name>
- <name>add_listen_interface(IP, Type, Port) -> Result</name>
- <name>add_listen_interface(IP, Type, ConfigurationParameters) -> Result</name>
- <fsummary>Add a new listen process for incoming connection</fsummary>
- <type>
- <v>IP = string</v>
- <v>Type = normal | ssl</v>
- <v>Port = integer() > 0</v>
- <v>ConfigurationParameters = [{Key, Value}]</v>
- <v>Key = flags | ip_family | iiop_in_connection_timeout | iiop_max_fragments | iiop_max_in_requests | interceptors | iiop_port | iiop_ssl_port | ssl_server_options</v>
- <v>Value = as described in the User's Guide or below</v>
- <v>Result = {ok, Ref} | {error, Reason} | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- <v>Ref = #Ref</v>
- <v>Reason = string()</v>
- </type>
- <desc>
- <p>Create a new process that handle requests for creating a new incoming
- IIOP connection via the given interface and port. If the latter is
- excluded, Orber will use the value of the <c>iiop_port</c> or
- <c>iiop_ssl_port</c> configuration parameters.
- The <c>Type</c> parameter determines if it is
- supposed to be IIOP or IIOP via SSL. If successful, the returned
- <c>#Ref</c> shall be passed to <c>orber:remove_listen_interface/1</c>
- when the connection shall be terminated.</p>
- <p>It is also possible to supply configuration parameters that override
- the global configuration. The <em>iiop_in_connection_timeout</em>,
- <em>iiop_max_fragments</em>, <em>iiop_max_in_requests</em> and
- <em>interceptors</em> parameters simply overrides the global
- counterparts (See the
- <seealso marker="ch_install#config">Configuration</seealso> chapter
- in the User's Guide).
- But for the following parameters there are a few restrictions:</p>
- <list type="bulleted">
- <item><em>flags</em> - currently it is only possible to override the global
- setting for the <c>Use Current Interface in IOR</c> and
- <c>Exclude CodeSet Component</c> flags.</item>
- <item><em>ip_family</em> - can be set to <c>inet</c> or <c>inet6</c> and is
- used to get a listen interface that uses another IP version than the default
- set with flags at startup.</item>
- <item><em>iiop_port</em> - requires that <c>Use Current Interface in IOR</c>
- is activated and the supplied <c>Type</c> is <c>normal</c>. If so,
- exported IOR:s will contain the IIOP port defined by this configuration
- parameter. Otherwise, the global setting will be used.</item>
- <item><em>iiop_ssl_port</em> - almost equivalent to <c>iiop_port</c>.
- The difference is that <c>Type</c> shall be <c>ssl</c> and that
- exported IOR:s will contain the IIOP via SSL port defined by this configuration
- parameter.</item>
- </list>
- <p>If it is not possible to add a listener based on the supplied interface
- and port, the error message is one of the ones described in <c>inet</c>
- and/or <c>ssl</c> documentation.</p>
- </desc>
- </func>
- <func>
- <name>remove_listen_interface(Ref) -> ok</name>
- <fsummary>Terminate listen process for incoming connection</fsummary>
- <type>
- <v>Ref = #Ref</v>
- </type>
- <desc>
- <p>Terminates the listen process, associated with the supplied <c>#Ref</c>,
- for incoming a connection. The Ref parameter is the return value from
- the <c>orber:add_listen_interface/2/3</c> operation. When terminating
- the connection, all associated requests will not deliver a reply to
- the clients.</p>
- </desc>
- </func>
- <func>
- <name>close_connection(Connection) -> Result</name>
- <name>close_connection(Connection, Interface) -> Result</name>
- <fsummary>Terminate outgoing connection(s)</fsummary>
- <type>
- <v>Connection = Object | [{Host, Port}]</v>
- <v>Object = #objref (external)</v>
- <v>Host = string()</v>
- <v>Port = string()</v>
- <v>Interface = string()</v>
- <v>Result = ok | {'EXCEPTION', #'BAD_PARAM'{}}</v>
- </type>
- <desc>
- <p>Will try to close all outgoing connections to the host/port combinations
- found in the supplied object reference or the given list of hosts/ports.
- If a <c>#'IOP_ServiceContext'{}</c> containing a local interface has been
- used when communicating with the remote object
- (see also <seealso marker="Module_Interface">Module_Interface</seealso>),
- that interface shall be passed as the second argument. Otherwise, connections
- via the default local interface, will be terminated.</p>
- <p></p>
- <note>
- <p>Since several clients maybe communicates via the same connection,
- they will be affected when invoking this operation. Other clients may
- re-create the connection by invoking an operation on the target object.</p>
- </note>
- </desc>
- </func>
- <func>
- <name>secure() -> no | ssl</name>
- <fsummary>Display the security mode Orber is running in</fsummary>
- <desc>
- <p>This function returns the security mode Orber is running in, which is either no if it is an
- insecure domain or the type of security mechanism used. For the moment the only security
- mechanism is ssl. This is configured by setting the application variable
- <em>secure</em>.</p>
- </desc>
- </func>
- <func>
- <name>ssl_server_options() -> list()</name>
- <fsummary>Display the SSL server options</fsummary>
- <desc>
- <p>This function returns the list of SSL options set for the Orber domain as server.
- This is configured by setting the application variable
- <em>ssl_server_options</em>.</p>
- </desc>
- </func>
- <func>
- <name>ssl_client_options() -> list()</name>
- <fsummary>Display the SSL client options</fsummary>
- <desc>
- <p>This function returns the list of SSL options used in outgoing calls in the current process.
- The default value is configured by setting the application variable
- <em>ssl_client_options</em>.</p>
- </desc>
- </func>
- <func>
- <name>set_ssl_client_options(Options) -> ok</name>
- <fsummary>Set the SSL options for the client</fsummary>
- <type>
- <v>Options = list()</v>
- </type>
- <desc>
- <p>This function takes a list of SSL options as parameter and sets
- it for the current process.</p>
- </desc>
- </func>
- <func>
- <name>objectkeys_gc_time() -> int() (seconds)</name>
- <fsummary>Display the Object Keys GC time value</fsummary>
- <desc>
- <p>This function returns the timeout value after which after which terminated object keys,
- related to servers started with the configuration parameter <c>{persistent, true}</c>,
- will be removed.
- It can be configured by setting the application variable <em>objectkeys_gc_time TimeVal (seconds)</em>,
- if it is not set it will have the default value <em>infinity</em>. </p>
- <p>Objects terminating with reason <em>normal</em> or <em>shutdown</em> are removed automatically.</p>
- <p>Note: the objectkeys_gc_time configuration parameter (TimeVal) may only range between 0 and 1000000 seconds.
- Otherwise, the default value is used.</p>
- </desc>
- </func>
- <func>
- <name>orber_nodes() -> RetVal</name>
- <fsummary>Displays which nodes that this orber domain consist of.</fsummary>
- <type>
- <v>RetVal = [node()]</v>
- </type>
- <desc>
- <p>This function returns the list of node names that this orber
- domain consists of. </p>
- </desc>
- </func>
- <func>
- <name>install(NodeList) -> ok</name>
- <name>install(NodeList, Options) -> ok</name>
- <fsummary>Install the Orber application</fsummary>
- <type>
- <v>NodeList = [node()]</v>
- <v>Options = [Option]</v>
- <v>Option = {install_timeout, Timeout} | {ifr_storage_type, TableType} | {nameservice_storage_type, TableType} | {initialreferences_storage_type, TableType} | {load_order, Priority}</v>
- <v>Timeout = infinity | integer()</v>
- <v>TableType = disc_copies | ram_copies</v>
- <v>Priority = integer()</v>
- </type>
- <desc>
- <p>This function installs all the necessary mnesia tables and
- load default data in some of them. If one or more Orber tables
- already exists the installation fails. The function
- <em>uninstall</em> may be used, if it is safe, i.e., no other
- application is running Orber.</p>
- <p>Preconditions:</p>
- <list type="bulleted">
- <item>a mnesia schema must exist before the installation</item>
- <item>mnesia is running on the other nodes if the new installation
- shall be a multi node domain</item>
- </list>
- <p>Mnesia will be started by the function if it is not already running on
- the installation node and if it was started it will be stopped
- afterwards.</p>
- <p>The options that can be sent to the installation program is:</p>
- <list type="bulleted">
- <item><c>{install_timeout, Timeout}</c> - this timeout is how long we
- will wait for the tables to be created. The Timeout value can be
- <em>infinity</em> or an integer number in milliseconds.
- Default is infinity.</item>
- <item><c>{ifr_storage_type, TableType}</c> - this option sets the
- type of tables used for the interface repository.
- The TableType can be disc_copies or ram_copies. Default is
- disc_copies.</item>
- <item><c>{initialreferences_storage_type, TableType}</c> - this option
- sets the type of table used for storing initial references.
- The TableType can be disc_copies or ram_copies. Default is
- ram_copies.</item>
- <item><c>{nameservice_storage_type, TableType}</c> - the default
- behavior of Orber is to install the NameService as ram_copies.
- This option makes it possible to change this to disc_copies. But
- the user should be aware of that if a node is restarted, all
- local object references stored in the NameService is not valid.
- Hence, you cannot switch to disc_copies and expect exactly the same
- behavior as before.</item>
- <item><c>{load_order, Priority}</c> - per default the priority is set to 0.
- Using this option it will change the priority of in which order
- Mnesia will load Orber internal tables. For more information,
- consult the Mnesia documentation.</item>
- </list>
- </desc>
- </func>
- <func>
- <name>uninstall() -> ok</name>
- <fsummary>Uninstall the Orber application</fsummary>
- <desc>
- <p>This function stops the Orber application, terminates all server
- objects and removes all Orber related mnesia tables.</p>
- <p>Note: Since other applications may be running on the same node
- using mnesia <em>uninstall</em> will not stop the mnesia application.</p>
- </desc>
- </func>
- <func>
- <name>add_node(Node, Options) -> RetVal</name>
- <fsummary>Add a new node to a group of Orber nodes.</fsummary>
- <type>
- <v>Node = node()</v>
- <v>Options = IFRStorageType | [KeyValue] </v>
- <v>IFRStorageType = StorageType</v>
- <v>StorageType = disc_copies | ram_copies</v>
- <v>KeyValue = {ifr_storage_type, StorageType} | {initialreferences_storage_type, StorageType} | {nameservice_storage_type, StorageType} | {type, Type} </v>
- <v>Type = temporary | permanent</v>
- <v>RetVal = ok | exit()</v>
- </type>
- <desc>
- <p>This function add given node to a existing Orber node group and starts
- Orber on the new node. <c>orber:add_node</c> is called from a member in the Orber
- node group.</p>
- <p>Preconditions for new node:</p>
- <list type="bulleted">
- <item>Erlang started on the new node using the option <c>-mnesia extra_db_nodes</c>, e.g.,
- <c>erl -sname new_node_name -mnesia extra_db_nodes ConnectToNodes_List</c></item>
- <item>The new node's <c>domain</c> name is the same for the nodes we want to connect to.</item>
- <item>Mnesia is running on the new node (no new schema created).</item>
- <item>If the new node will use <c>disc_copies</c> the schema type must be changed using:
- <c>mnesia:change_table_copy_type(schema, node(), disc_copies).</c></item>
- </list>
- <p>Orber will be started by the function on the new node.</p>
- <p>Fails if:</p>
- <list type="bulleted">
- <item>Orber already installed on given node.</item>
- <item>Mnesia not started as described above on the new node.</item>
- <item>Impossible to copy data in Mnesia tables to the new node.</item>
- <item>Not able to start Orber on the new node, due to, for example, the
- <c>iiop_port</c> is already in use.</item>
- </list>
- <p>The function do not remove already copied tables after a failure.
- Use <c>orber:remove_node</c> to remove these tables.</p>
- </desc>
- </func>
- <func>
- <name>remove_node(Node) -> RetVal</name>
- <fsummary>Removes a node from a group of Orber nodes.</fsummary>
- <type>
- <v>Node = node()</v>
- <v>RetVal = ok | exit()</v>
- </type>
- <desc>
- <p>This function removes given node from a Orber node group. The Mnesia
- application is not stopped.</p>
- </desc>
- </func>
- <func>
- <name>configure(Key, Value) -> ok | {'EXIT', Reason}</name>
- <fsummary>Change Orber configuration.</fsummary>
- <type>
- <v>Key = orbDefaultInitRef | orbInitRef | giop_version | iiop_timeout | iiop_connection_timeout | iiop_setup_connection_timeout | iiop_in_connection_timeout | objectkeys_gc_time | orber_debug_level</v>
- <v>Value = allowed value associated with the given key</v>
- </type>
- <desc>
- <p>This function allows the user to configure Orber in, for example,
- an Erlang shell. It is possible to invoke <c>configure</c> at any time
- the keys specified above.</p>
- <p>Any other key must be set before installing and starting Orber.</p>
- <p>Trying to change the configuration in any other way is <em>NOT</em>
- allowed since it may affect the behavior of Orber.</p>
- <p>For more information regarding allowed values, see
- <seealso marker="ch_install#config">configuration settings</seealso>
- in the User's Guide.</p>
- <p></p>
- <note>
- <p>Configuring the IIOP timeout values will not affect already
- existing connections. If you want a guaranteed uniform behavior, you
- must set these parameters from the start.</p>
- </note>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/orber_acl.xml b/lib/orber/doc/src/orber_acl.xml
deleted file mode 100644
index 5feda83ef6..0000000000
--- a/lib/orber/doc/src/orber_acl.xml
+++ /dev/null
@@ -1,107 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>2005</year>
- <year>2016</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>orber_acl</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>2005-05-19</date>
- <rev>A</rev>
- </header>
- <module>orber_acl</module>
- <modulesummary>Orber ACL operations</modulesummary>
- <description>
- <p>This module contains functions intended for analyzing Access
- Control List (ACL) filters. The filters uses a extended format of
- Classless Inter Domain Routing (CIDR).
- For example, <c>"123.123.123.10"</c> limits
- the connection to that particular host, while <c>"123.123.123.10/17"</c> allows
- connections to or from any host equal to the 17 most significant bits. Orber
- also allow the user to specify a certain port or port range, for example,
- <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c>
- respectively. IPv4 or none compressed IPv6 strings are accepted.</p>
- </description>
- <funcs>
- <func>
- <name>match(IP, Direction) -> boolean()</name>
- <name>match(IP, Direction, GetInfo) -> Reply</name>
- <fsummary>Verify if the IP address versus the current configuration</fsummary>
- <type>
- <v>IP = tuple() | [integer()]</v>
- <v>Direction = tcp_in | ssl_in | tcp_out | ssl_out</v>
- <v>GetInfo = boolean()</v>
- <v>Reply = boolean() | {boolean(), [Interface], PortInfo}</v>
- <v>Interface = string()</v>
- <v>PortInfo = integer() | {integer(), integer()}</v>
- </type>
- <desc>
- <p>If <c>GetInfo</c> is not supplied or set to false, this operation returns
- a boolean which tells if the IPv4 or IPv6 address would pass the ACL
- filter, defined by the <c>iiop_acl</c> configuration parameter, or not.
- When <c>GetInfo</c> is set to true, a tuple which, besides the boolean
- that tells if access was granted, also include the defined
- interfaces and port(s). This operation requires that Orber is running and
- can be used on a live node to determine if Orber has been properly configured.</p>
- </desc>
- </func>
- <func>
- <name>verify(IP, Filter, Family) -> Reply</name>
- <fsummary>Verify if the IP address versus the Filter</fsummary>
- <type>
- <v>IP = string()</v>
- <v>Filter = string()</v>
- <v>Family = inet | inet6</v>
- <v>Reply = true | {false, From, To} | {error, string()}</v>
- <v>From = string()</v>
- <v>To = string()</v>
- </type>
- <desc>
- <p>This operation returns true if the IPv4 or IPv6 address would pass the
- supplied ACL. If that is not the case, a tuple containing the accepted range
- is returned. This operation should only be used for test purposes.</p>
- </desc>
- </func>
- <func>
- <name>range(Filter, Family) -> Reply</name>
- <fsummary>Get range of Filter</fsummary>
- <type>
- <v>Filter = string()</v>
- <v>Family = inet | inet6</v>
- <v>Reply = {ok, From, To} | {error, string()}</v>
- <v>From = string()</v>
- <v>To = string()</v>
- </type>
- <desc>
- <p>Returns the range of accepted IP addresses based on the supplied filter.
- This operation should only be used for test purposes.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/orber_diagnostics.xml b/lib/orber/doc/src/orber_diagnostics.xml
deleted file mode 100644
index 3aad304535..0000000000
--- a/lib/orber/doc/src/orber_diagnostics.xml
+++ /dev/null
@@ -1,81 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>2003</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>orber_diagnostics</title>
- <prepared></prepared>
- <responsible></responsible>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>2003-04-17</date>
- <rev>A</rev>
- </header>
- <module>orber_diagnostics</module>
- <modulesummary>Diagnostics API for Orber</modulesummary>
- <description>
- <p>This module contains functions which makes it possible to run simple
- tests.</p>
- <p></p>
- <warning>
- <p>Functions exported by this module may only be used during
- test and development phase.</p>
- </warning>
- </description>
- <funcs>
- <func>
- <name>nameservice() -> Result</name>
- <name>nameservice(Flags) -> Result</name>
- <fsummary>Display all objects stored in the Name Service</fsummary>
- <type>
- <v>Flags = integer()</v>
- <v>Result = ok | {'EXCEPTION', E}</v>
- </type>
- <desc>
- <p>Displays all objects stored in the NameService. Existent checks are, per
- default, also performed on all local objects. This can also be activated
- for external objects by setting the flag <c>16#01</c>. The displayed
- information is the stringified Name described in
- <seealso marker="CosNaming_NamingContextExt">CosNaming_NamingContextExt</seealso>,
- non existent status (true | false | external | undefined) and the IFR-Id:</p>
- <code type="none">
-host/
-host/resources/
-host/resources/MyObj/ [false] IDL:MyMod/MyIntf:1.0 </code>
- </desc>
- </func>
- <func>
- <name>missing_modules() -> Count</name>
- <fsummary>Echo missing modules required by Orber</fsummary>
- <type>
- <v>Count = integer()</v>
- </type>
- <desc>
- <p>This operation list missing modules generated by IC and required by
- Orber. Requires that all API:s are registered in the IFR.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/orber_ifr.xml b/lib/orber/doc/src/orber_ifr.xml
deleted file mode 100644
index a667d7d9e4..0000000000
--- a/lib/orber/doc/src/orber_ifr.xml
+++ /dev/null
@@ -1,1035 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1997</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>orber_ifr</title>
- <prepared></prepared>
- <docno></docno>
- <approved></approved>
- <checked></checked>
- <date>1997-10-13</date>
- <rev>A</rev>
- </header>
- <module>orber_ifr</module>
- <modulesummary>The Interface Repository stores representations of IDL information</modulesummary>
- <description>
- <p>This module contains functions for managing the Interface
- Repository (IFR). This documentation should be used in conjunction
- with the documentation in chapter 6 of <term id="CORBA"></term>2.3.
- Whenever the term IFR object is used in this manual page, it
- refers to a pseudo object used only for interaction with the IFR
- rather than a CORBA object.</p>
- </description>
-
- <section>
- <title>Initialization of the IFR</title>
- <p>The following functions are used to initialize the Interface
- Repository and to obtain the initial reference to the
- repository.</p>
- </section>
- <funcs>
- <func>
- <name>init(Nodes,Timeout) -> ok</name>
- <fsummary>Intialize the IFR</fsummary>
- <type>
- <v>Nodes = list()</v>
- <v>Timeout = integer() | infinity</v>
- </type>
- <desc>
- <p>This function should be called to initialize the IFR. It
- creates the necessary mnesia-tables. A mnesia schema should
- exist, and mnesia must be running.</p>
- </desc>
- </func>
- <func>
- <name>find_repository() -> #IFR_Repository_objref</name>
- <fsummary>Find the IFR object reference for the Repository</fsummary>
- <desc>
- <p>Find the IFR object reference for the Repository. This
- reference should be used when adding objects to the IFR, and
- when extracting information from the IFR.
- The first time this function is called, it will create the
- repository and all the primitive definitions.</p>
- </desc>
- </func>
- </funcs>
-
- <section>
- <title>General methods</title>
- <p>The following functions are the methods of the IFR. The first
- argument is always an #IFR_objref, i.e. the IFR (pseudo)object
- on which to apply this method. These functions are useful when
- the type of IFR object is not know, but they are somewhat slower
- than the specific functions listed below which only accept a
- particular type of IFR object as the first argument.</p>
- </section>
- <funcs>
- <func>
- <name>get_def_kind(Objref) -> Return</name>
- <fsummary>Return the definition kind of the IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Return = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind. Returns the definition
- kind of the IFR object.</p>
- </desc>
- </func>
- <func>
- <name>destroy(Objref) -> Return</name>
- <fsummary>Destroy, except IRObject, Contained and Container, target object and its contents</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Return = tuple()</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind except IRObject,
- Contained and Container. Destroys that object and its
- contents (if any). Returns whatever mnesia:transaction
- returns.</p>
- </desc>
- </func>
- <func>
- <name>get_id(Objref) -> Return</name>
- <fsummary>Return the target object's repository id</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Return = string()</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Returns the repository id of that object.</p>
- </desc>
- </func>
- <func>
- <name>set_id(Objref,Id) -> ok</name>
- <fsummary>Set the target object's repository id</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Id = string()</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Sets the repository id of that object.</p>
- </desc>
- </func>
- <func>
- <name>get_name(Objref) -> Return</name>
- <fsummary>Return the name of the target object</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Return = string()</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Returns the name of that object.</p>
- </desc>
- </func>
- <func>
- <name>set_name(Objref,Name) -> ok</name>
- <fsummary>Set given name to target object</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Name = string()</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Sets the name of that object.</p>
- </desc>
- </func>
- <func>
- <name>get_version(Objref) -> Return</name>
- <fsummary>Return the version of the target object</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Return = string()</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Returns the version of that object.</p>
- </desc>
- </func>
- <func>
- <name>set_version(Objref,Version) -> ok</name>
- <fsummary>Set given version of the target object</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Version = string()</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Sets the version of that object.</p>
- </desc>
- </func>
- <func>
- <name>get_defined_in(Objref) -> Return</name>
- <fsummary>Return the Container the target object is contained in</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Return = #IFR_Container_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Returns the Container object that the object is
- defined in.</p>
- </desc>
- </func>
- <func>
- <name>get_absolute_name(Objref) -> Return</name>
- <fsummary>Return the absolute name of the target object</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Return = string()</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Returns the absolute (scoped) name of that
- object.</p>
- </desc>
- </func>
- <func>
- <name>get_containing_repository(Objref) -> Return</name>
- <fsummary>Get the most derived Contained object associated with the target object</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Return = #IFR_Repository_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Returns the Repository that is eventually reached
- by recursively following the object's defined_in attribute.</p>
- </desc>
- </func>
- <func>
- <name>describe(Objref) -> Return</name>
- <fsummary>Return a tuple which describe the target object</fsummary>
- <type>
- <v>Objref = #IFR_object</v>
- <v>Return = tuple() (a contained_description record) | {exception, _}</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. Returns a tuple describing the object.</p>
- </desc>
- </func>
- <func>
- <name>move(Objref,New_container,New_name,New_version) -> Return</name>
- <fsummary>Move the target object from its current location to given Container, name and version</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>New_container = #IFR_Container_objref</v>
- <v>New_name = string()</v>
- <v>New_version = string()</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Contained. New_container is an IFR object of any kind that
- inherits from Container. Removes Objref from its current
- Container, and adds it to New_container. The name attribute
- is changed to New_name and the version attribute is changed
- to New_version.</p>
- </desc>
- </func>
- <func>
- <name>lookup(Objref,Search_name) -> Return</name>
- <fsummary>Return the IFR object identified by the given name</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Search_name = string()</v>
- <v>Return = #IFR_object</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Returns an IFR object identified by search_name
- (a scoped name).</p>
- </desc>
- </func>
- <func>
- <name>contents(Objref,Limit_type,Exclude_inherited) -> Return</name>
- <fsummary>Return the content of the target object limited by the given constraints</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v>
- <v>Exclude_inherited = atom() (true or false)</v>
- <v>Return = list() (a list of IFR#_objects)</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Returns the contents of that IFR object.</p>
- </desc>
- </func>
- <func>
- <name>lookup_name(Objref,Search_name,Levels_to_search, Limit_type, Exclude_inherited) -> Return</name>
- <fsummary>Return a list of IFR objects matching the given name</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Search_name = string()</v>
- <v>Levels_to_search = integer()</v>
- <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v>
- <v>Exclude_inherited = atom() (true or false)</v>
- <v>Return = list() (a list of #IFR_objects)</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Returns a list of #IFR_objects with an id
- matching Search_name.</p>
- </desc>
- </func>
- <func>
- <name>describe_contents(Objref, Limit_type, Exclude_inherited, Max_returned_objs) -> Return</name>
- <fsummary>Return a list of descriptions of the IFR objects contained by the target Container object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v>
- <v>Exclude_inherited = atom() (true or false)</v>
- <v>Return = list() (a list of tuples (contained_description records) | {exception, _}</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Returns a list of descriptions of the IFR objects
- in this Container's contents.</p>
- </desc>
- </func>
- <func>
- <name>create_module(Objref,Id,Name,Version) -> Return</name>
- <fsummary>Create an IFR object of given type</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Return = #IFR_ModuleDef_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Creates an IFR object of the type ModuleDef.</p>
- </desc>
- </func>
- <func>
- <name>create_constant(Objref,Id,Name,Version,Type,Value) -> Return</name>
- <fsummary>Create a ConstantDef IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Type = #IFR_IDLType_objref</v>
- <v>Value = any()</v>
- <v>Return = #IFR_ConstantDef_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Creates an IFR object of the type ConstantDef.</p>
- </desc>
- </func>
- <func>
- <name>create_struct(Objref,Id,Name,Version,Members) -> Return</name>
- <fsummary>Create a StructDef IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Members = list() (list of structmember records)</v>
- <v>Return = #IFR_StructDef_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Creates an IFR object of the type StructDef.</p>
- </desc>
- </func>
- <func>
- <name>create_union(Objref,Id,Name,Version,Discriminator_type,Members) -> Return</name>
- <fsummary>Create a UnionDef IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Discriminator_type = #IFR_IDLType_Objref</v>
- <v>Members = list() (list of unionmember records)</v>
- <v>Return = #IFR_UnionDef_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Creates an IFR object of the type UnionDef.</p>
- </desc>
- </func>
- <func>
- <name>create_enum(Objref,Id,Name,Version,Members) -> Return</name>
- <fsummary>Create a EnumDef IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Members = list() (list of strings)</v>
- <v>Return = #IFR_EnumDef_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Creates an IFR object of the type EnumDef.</p>
- </desc>
- </func>
- <func>
- <name>create_alias(Objref,Id,Name,Version,Original_type) -> Return</name>
- <fsummary>Create a AliasDef IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Original_type = #IFR_IDLType_Objref</v>
- <v>Return = #IFR_AliasDef_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Creates an IFR object of the type AliasDef.</p>
- </desc>
- </func>
- <func>
- <name>create_interface(Objref,Id,Name,Version,Base_interfaces) -> Return</name>
- <fsummary>Create a InterfaceDef IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Base_interfaces = list() (a list of IFR_InterfaceDef_objrefs that this interface inherits from</v>
- <v>Return = #IFR_InterfaceDef_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Creates an IFR object of the type InterfaceDef.</p>
- </desc>
- </func>
- <func>
- <name>create_exception(Objref,Id,Name,Version,Members) -> Return</name>
- <fsummary>Create a ExceptionDef IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Members = list() (list of structmember records)</v>
- <v>Return = #IFR_ExceptionDef_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- Container. Creates an IFR object of the type ExceptionDef.</p>
- </desc>
- </func>
- <func>
- <name>get_type(Objref) -> Return</name>
- <fsummary>Return the typecode of the target object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Return = tuple() (a typecode tuple)</v>
- </type>
- <desc>
- <p>Objref is an IFR object of any kind that inherits from
- IDLType or an IFR object of the kind ConstantDef,
- ExceptionDef or AttributeDef. Returns the typecode of the
- IFR object.</p>
- </desc>
- </func>
- <func>
- <name>lookup_id(Objref,Search_id) -> Return</name>
- <fsummary>Return the IFR object matching the given id</fsummary>
- <type>
- <v>Objref = #IFR_Repository_objref</v>
- <v>Search_id = string()</v>
- <v>Return = #IFR_objref</v>
- </type>
- <desc>
- <p>Returns an IFR object matching the Search_id.</p>
- </desc>
- </func>
- <func>
- <name>get_primitive(Objref,Kind) -> Return</name>
- <fsummary>Return a PrimitiveDef of the specified kind</fsummary>
- <type>
- <v>Objref = #IFR_Repository_objref</v>
- <v>Kind = atom() (one of pk_null, pk_void, pk_short, pk_long, pk_ushort, pk_ulong, pk_float, pk_double, pk_boolean, pk_char, pk_octet, pk_any, pk_TypeCode, pk_Principal, pk_string, pk_wstring, pk_fixed, pk_objref)</v>
- <v>Return = #IFR_PrimitiveDef_objref</v>
- </type>
- <desc>
- <p>Returns a PrimitiveDef of the specified kind.</p>
- </desc>
- </func>
- <func>
- <name>create_string(Objref,Bound) -> Return</name>
- <fsummary>Create an IFR objref of the type StringDef</fsummary>
- <type>
- <v>Objref = #IFR_Repository_objref</v>
- <v>Bound = integer() (unsigned long /= 0)</v>
- <v>Return = #IFR_StringDef_objref</v>
- </type>
- <desc>
- <p>Creates an IFR objref of the type StringDef.</p>
- </desc>
- </func>
- <func>
- <name>create_wstring(Objref,Bound) -> Return</name>
- <fsummary>Create an IFR objref of the type WstringDef</fsummary>
- <type>
- <v>Objref = #IFR_Repository_objref</v>
- <v>Bound = integer() (unsigned long /= 0)</v>
- <v>Return = #IFR_WstringDef_objref</v>
- </type>
- <desc>
- <p>Creates an IFR objref of the type WstringDef.</p>
- </desc>
- </func>
- <func>
- <name>create_fixed(Objref,Digits,Scale) -> Return</name>
- <fsummary>Create an IFR objref of the type FixedDef</fsummary>
- <type>
- <v>Objref = #IFR_Repository_objref</v>
- <v>Digits = Scale = integer()</v>
- <v>Return = #IFR_FixedDef_objref</v>
- </type>
- <desc>
- <p>Creates an IFR objref of the type FixedDef.</p>
- </desc>
- </func>
- <func>
- <name>create_sequence(Objref,Bound,Element_type) -> Return</name>
- <fsummary>Create an IFR objref of the type SequenceDef</fsummary>
- <type>
- <v>Objref = #IFR_Repository_objref</v>
- <v>Bound = integer() (unsigned long)</v>
- <v>Element_type = #IFR_IDLType_objref</v>
- <v>Return = #IFR_SequenceDef_objref</v>
- </type>
- <desc>
- <p>Creates an IFR objref of the type SequenceDef.</p>
- </desc>
- </func>
- <func>
- <name>create_array(Objref,Length,Element_type) -> Return</name>
- <fsummary>Create an IFR objref of the type ArrayDef</fsummary>
- <type>
- <v>Objref = #IFR_Repository_objref</v>
- <v>Bound = integer() (unsigned long)</v>
- <v>Element_type = #IFR_IDLType_objref</v>
- <v>Return = #IFR_ArrayDef_objref</v>
- </type>
- <desc>
- <p>Creates an IFR objref of the type ArrayDef.</p>
- </desc>
- </func>
- <func>
- <name>create_idltype(Objref,Typecode) -> Return</name>
- <fsummary>Create an IFR objref of the type IDLType</fsummary>
- <type>
- <v>Objref = #IFR_Repository_objref</v>
- <v>Typecode = tuple() (a typecode tuple)</v>
- <v>Return = #IFR_IDLType_objref</v>
- </type>
- <desc>
- <p>Creates an IFR objref of the type IDLType.</p>
- </desc>
- </func>
- <func>
- <name>get_type_def(Objref) -> Return</name>
- <fsummary>Return an IFR object of the type IDLType describing the type of the target object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Return = #IFR_IDLType_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object of the kind ConstantDef or
- AttributeDef. Returns an IFR object of the type IDLType
- describing the type of the IFR object.</p>
- </desc>
- </func>
- <func>
- <name>set_type_def(Objref,TypeDef) -> Return</name>
- <fsummary>Set given TypeDef of the target object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>TypeDef = #IFR_IDLType_objref</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Objref is an IFR object of the kind ConstantDef or
- AttributeDef. Sets the type_def of the IFR Object.</p>
- </desc>
- </func>
- <func>
- <name>get_value(Objref) -> Return</name>
- <fsummary>Return the value attribute of the target ConstantDef object</fsummary>
- <type>
- <v>Objref = #IFR_ConstantDef_objref</v>
- <v>Return = any()</v>
- </type>
- <desc>
- <p>Returns the value attribute of an IFR Object of the type ConstantDef.</p>
- </desc>
- </func>
- <func>
- <name>set_value(Objref,Value) -> Return</name>
- <fsummary>Set the value attribute of the target ConstantDef object</fsummary>
- <type>
- <v>Objref = #IFR_ConstantDef_objref</v>
- <v>Value = any()</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Sets the value attribute of an IFR Object of the type ConstantDef.</p>
- </desc>
- </func>
- <func>
- <name>get_members(Objref) -> Return</name>
- <fsummary>Return the members of the target object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Return = list()</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind StructDef, UnionDef,
- EnumDef or ExceptionDef.
- For StructDef, UnionDef and ExceptionDef: Returns a list of
- structmember records that are the constituent parts of the
- object.
- For EnumDef: Returns a list of strings describing the
- enumerations.</p>
- </desc>
- </func>
- <func>
- <name>set_members(Objref,Members) -> Return</name>
- <fsummary>Set the members attribute of the target object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Members = list()</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind StructDef, UnionDef,
- EnumDef or ExceptionDef.
- For StructDef, UnionDef and ExceptionDef: Members is a list
- of structmember records.
- For EnumDef: Members is a list of strings describing the
- enumerations.
- Sets the members attribute, which are the constituent parts of the
- exception.</p>
- </desc>
- </func>
- <func>
- <name>get_discriminator_type(Objref) -> Return</name>
- <fsummary>Get the discriminator typecode of the target object</fsummary>
- <type>
- <v>Objref = #IFR_UnionDef_objref</v>
- <v>Return = tuple() (a typecode tuple)</v>
- </type>
- <desc>
- <p>Returns the discriminator typecode of an IFR object of the type
- UnionDef.</p>
- </desc>
- </func>
- <func>
- <name>get_discriminator_type_def(Objref) -> Return</name>
- <fsummary>Return IDLType object describing the discriminator type of the target object</fsummary>
- <type>
- <v>Objref = #IFR_UnionDef_objref</v>
- <v>Return = #IFR_IDLType_objref</v>
- </type>
- <desc>
- <p>Returns an IFR object of the type IDLType describing the
- discriminator type of an IFR object of the type UnionDef.</p>
- </desc>
- </func>
- <func>
- <name>set_discriminator_type_def(Objref,TypeDef) -> Return</name>
- <fsummary>Set the attribute discriminator_type_def for the target object to the given TypeDef</fsummary>
- <type>
- <v>Objref = #IFR_UnionDef_objref</v>
- <v>Return = #IFR_IDLType_objref</v>
- </type>
- <desc>
- <p>Sets the attribute discriminator_type_def, an IFR object of
- the type IDLType describing the discriminator type of an IFR
- object of the type UnionDef.</p>
- </desc>
- </func>
- <func>
- <name>get_original_type_def(Objref) -> Return</name>
- <fsummary>Return an IFR object of the type IDLType describing the original type</fsummary>
- <type>
- <v>Objref = #IFR_AliasDef_objref</v>
- <v>Return = #IFR_IDLType_objref</v>
- </type>
- <desc>
- <p>Returns an IFR object of the type IDLType describing the
- original type.</p>
- </desc>
- </func>
- <func>
- <name>set_original_type_def(Objref,TypeDef) -> Return</name>
- <fsummary>Set the original_type_def attribute which describes the original type</fsummary>
- <type>
- <v>Objref = #IFR_AliasDef_objref</v>
- <v>Typedef = #IFR_IDLType_objref</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Sets the original_type_def attribute which describes the
- original type.</p>
- </desc>
- </func>
- <func>
- <name>get_kind(Objref) -> Return</name>
- <fsummary>Return an atom describing the primitive type</fsummary>
- <type>
- <v>Objref = #IFR_PrimitiveDef_objref</v>
- <v>Return = atom()</v>
- </type>
- <desc>
- <p>Returns an atom describing the primitive type (See CORBA 2.0
- p 6-21).</p>
- </desc>
- </func>
- <func>
- <name>get_bound(Objref) -> Return</name>
- <fsummary>Get the maximum size of the target object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Return = integer (unsigned long)</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind StringDef or SequenceDef.
- For StringDef: returns the maximum number of characters in
- the string.
- For SequenceDef: Returns the maximum number of elements in
- the sequence. Zero indicates an unbounded sequence.</p>
- </desc>
- </func>
- <func>
- <name>set_bound(Objref,Bound) -> Return</name>
- <fsummary>Set the maximum size of the target object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Bound = integer (unsigned long)</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind StringDef or SequenceDef.
- For StringDef: Sets the maximum number of characters in the
- string. Bound must not be zero.
- For SequenceDef: Sets the maximum number of elements in the
- sequence. Zero indicates an unbounded sequence.</p>
- </desc>
- </func>
- <func>
- <name>get_element_type(Objref) -> Return</name>
- <fsummary>Return the typecode of the elements in the IFR object</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Return = tuple() (a typecode tuple)</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind SequenceDef or ArrayDef.
- Returns the typecode of the elements in the IFR object.</p>
- </desc>
- </func>
- <func>
- <name>get_element_type_def(Objref) -> Return</name>
- <fsummary>Return an IFR object of the type IDLType describing the type of the elements in Objref</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Return = #IFR_IDLType_objref</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind SequenceDef or ArrayDef.
- Returns an IFR object of the type IDLType describing the
- type of the elements in Objref.</p>
- </desc>
- </func>
- <func>
- <name>set_element_type_def(Objref,TypeDef) -> Return</name>
- <fsummary>Set the element_type_def attribute of the target object to the given TypeDef</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>TypeDef = #IFR_IDLType_objref</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind SequenceDef or ArrayDef.
- Sets the element_type_def attribute, an IFR object of the
- type IDLType describing the type of the elements in Objref.</p>
- </desc>
- </func>
- <func>
- <name>get_length(Objref) -> Return</name>
- <fsummary>Return the number of elements in the array</fsummary>
- <type>
- <v>Objref = #IFR_ArrayDef_objref</v>
- <v>Return = integer() (unsigned long)</v>
- </type>
- <desc>
- <p>Returns the number of elements in the array.</p>
- </desc>
- </func>
- <func>
- <name>set_length(Objref,Length) -> Return</name>
- <fsummary>Set the number of elements in the array</fsummary>
- <type>
- <v>Objref = #IFR_ArrayDef_objref</v>
- <v>Length = integer() (unsigned long)</v>
- </type>
- <desc>
- <p>Sets the number of elements in the array.</p>
- </desc>
- </func>
- <func>
- <name>get_mode(Objref) -> Return</name>
- <fsummary>Get the mode of the target object (AttributeDef or OperationDef)</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Return = atom()</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind AttributeDef or OperationDef.
- For AttributeDef: Return is an atom ('ATTR_NORMAL' or
- 'ATTR_READONLY') specifying the read/write access for this
- attribute.
- For OperationDef: Return is an atom ('OP_NORMAL' or
- 'OP_ONEWAY') specifying the mode of the operation.</p>
- </desc>
- </func>
- <func>
- <name>set_mode(Objref,Mode) -> Return</name>
- <fsummary>Set the mode of the target object (AttributeDef or OperationDef) to the given mode</fsummary>
- <type>
- <v>Objref = #IFR_objref</v>
- <v>Mode = atom()</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Objref is an IFR object the kind AttributeDef or OperationDef.
- For AttributeDef: Sets the read/write access for this
- attribute. Mode is an atom ('ATTR_NORMAL' or
- 'ATTR_READONLY').
- For OperationDef: Sets the mode of the operation. Mode is an
- atom ('OP_NORMAL' or 'OP_ONEWAY').</p>
- </desc>
- </func>
- <func>
- <name>get_result(Objref) -> Return</name>
- <fsummary>Return typecode describing the type of the value returned by the operation</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>Return = tuple() (a typecode tuple)</v>
- </type>
- <desc>
- <p>Returns a typecode describing the type of the value returned by the
- operation.</p>
- </desc>
- </func>
- <func>
- <name>get_result_def(Objref) -> Return</name>
- <fsummary>Return an IFR object of the type IDLType describing the type of the result</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>Return = #IFR_IDLType_objref</v>
- </type>
- <desc>
- <p>Returns an IFR object of the type IDLType describing the type of the
- result.</p>
- </desc>
- </func>
- <func>
- <name>set_result_def(Objref,ResultDef) -> Return</name>
- <fsummary>Set the type_def attribute of the target object to the given ResultDef</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>ResultDef = #IFR_IDLType_objref</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Sets the type_def attribute, an IFR Object of the type IDLType
- describing the result.</p>
- </desc>
- </func>
- <func>
- <name>get_params(Objref) -> Return</name>
- <fsummary>Return a list of parameter description records describing the parameters of the target OperationDef</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>Return = list() (list of parameter description records)</v>
- </type>
- <desc>
- <p>Returns a list of parameter description records, which describes the
- parameters of the OperationDef.</p>
- </desc>
- </func>
- <func>
- <name>set_params(Objref,Params) -> Return</name>
- <fsummary>Set the params attribute of the target object to the given parameter description records</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>Params = list() (list of parameter description records)</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Sets the params attribute, a list of parameter description records.</p>
- </desc>
- </func>
- <func>
- <name>get_contexts(Objref) -> Return</name>
- <fsummary>Return a list of context identifiers for the operation</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>Return = list() (list of strings)</v>
- </type>
- <desc>
- <p>Returns a list of context identifiers for the operation.</p>
- </desc>
- </func>
- <func>
- <name>set_contexts(Objref,Contexts) -> Return</name>
- <fsummary>Set the context attribute for the operation</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>Contexts = list() (list of strings)</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Sets the context attribute for the operation.</p>
- </desc>
- </func>
- <func>
- <name>get_exceptions(Objref) -> Return</name>
- <fsummary>Return a list of exception types that can be raised by the target object</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>Return = list() (list of #IFR_ExceptionDef_objrefs)</v>
- </type>
- <desc>
- <p>Returns a list of exception types that can be raised by this
- operation.</p>
- </desc>
- </func>
- <func>
- <name>set_exceptions(Objref,Exceptions) -> Return</name>
- <fsummary>Set the exceptions attribute for the target object</fsummary>
- <type>
- <v>Objref = #IFR_OperationDef_objref</v>
- <v>Exceptions = list() (list of #IFR_ExceptionDef_objrefs)</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Sets the exceptions attribute for this operation.</p>
- </desc>
- </func>
- <func>
- <name>get_base_interfaces(Objref) -> Return</name>
- <fsummary>Return a list of InterfaceDefs from which the target InterfaceDef object inherit</fsummary>
- <type>
- <v>Objref = #IFR_InterfaceDef_objref</v>
- <v>Return = list() (list of #IFR_InterfaceDef_objrefs)</v>
- </type>
- <desc>
- <p>Returns a list of InterfaceDefs from which this InterfaceDef inherits.</p>
- </desc>
- </func>
- <func>
- <name>set_base_interfaces(Objref,BaseInterfaces) -> Return</name>
- <fsummary>Set the BaseInterfaces attribute</fsummary>
- <type>
- <v>Objref = #IFR_InterfaceDef_objref</v>
- <v>BaseInterfaces = list() (list of #IFR_InterfaceDef_objrefs)</v>
- <v>Return = ok | {exception, _}</v>
- </type>
- <desc>
- <p>Sets the BaseInterfaces attribute.</p>
- </desc>
- </func>
- <func>
- <name>is_a(Objref,Interface_id) -> Return</name>
- <fsummary>Return a boolean if the target InterfaceDef match or inherit from the given id</fsummary>
- <type>
- <v>Objref = #IFR_InterfaceDef_objref</v>
- <v>Interface_id = #IFR_InterfaceDef_objref</v>
- <v>Return = atom() (true or false)</v>
- </type>
- <desc>
- <p>Returns true if the InterfaceDef either is identical to or
- inherits from Interface_id.</p>
- </desc>
- </func>
- <func>
- <name>describe_interface(Objref) -> Return</name>
- <fsummary>Return a full inter face description record describing the InterfaceDef</fsummary>
- <type>
- <v>Objref = #IFR_InterfaceDef_objref</v>
- <v>Return = tuple() (a fullinterfacedescription record)</v>
- </type>
- <desc>
- <p>Returns a full inter face description record describing the InterfaceDef.</p>
- </desc>
- </func>
- <func>
- <name>create_attribute(Objref,Id,Name,Version,Type,Mode) -> Return</name>
- <fsummary>Create an IFR object of the type AttributeDef contained in the target InterfaceDef object</fsummary>
- <type>
- <v>Objref = #IFR_InterfaceDef_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Type = #IFR_IDLType_objref</v>
- <v>Mode = atom() ('ATTR_NORMAL' or 'ATTR_READONLY')</v>
- <v>Return = #IFR_AttributeDef_objref</v>
- </type>
- <desc>
- <p>Creates an IFR object of the type AttributeDef contained in this
- InterfaceDef.</p>
- </desc>
- </func>
- <func>
- <name>create_operation(Objref,Id,Name,Version,Result,Mode,Params, Exceptions,Contexts) -> Return</name>
- <fsummary>Create an IFR object of the type OperationDef contained in the target InterfaceDef object</fsummary>
- <type>
- <v>Objref = #IFR_InterfaceDef_objref</v>
- <v>Id = string()</v>
- <v>Name = string()</v>
- <v>Version = string()</v>
- <v>Result = #IFR_IDLType_objref</v>
- <v>Mode = atom() ('OP_NORMAL' or 'OP_ONEWAY')</v>
- <v>Params = list() (list of parameter description records)</v>
- <v>Exceptions = list() (list of #IFR_ExceptionDef_objrefs)</v>
- <v>Contexts = list() (list of strings)</v>
- <v>Return = #IFR_OperationDef_objref</v>
- </type>
- <desc>
- <p>Creates an IFR object of the type OperationDef contained in this
- InterfaceDef.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/orber_tc.xml b/lib/orber/doc/src/orber_tc.xml
deleted file mode 100644
index 0cab8a5e4b..0000000000
--- a/lib/orber/doc/src/orber_tc.xml
+++ /dev/null
@@ -1,259 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>1998</year>
- <year>2016</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>orber_tc</title>
- <prepared>Lars Thors&eacute;n</prepared>
- <responsible>Lars Thors&eacute;n</responsible>
- <docno></docno>
- <approved>Lars Thors&eacute;n</approved>
- <checked></checked>
- <date>1998-04-20</date>
- <rev>A</rev>
- </header>
- <module>orber_tc</module>
- <modulesummary>Help functions for IDL typecodes</modulesummary>
- <description>
- <p>This module contains some functions that gives support in creating
- IDL typecodes that can be used in for example the any types typecode field.
- For the simple types it is meaningless to use this API but the functions exist
- to get the interface complete.</p>
- <p>The type <c>TC</c> used below describes an IDL type and is a tuple according
- to the to the Erlang language mapping.</p>
- </description>
- <funcs>
- <func>
- <name>null() -> TC</name>
- <name>void() -> TC</name>
- <name>short() -> TC</name>
- <name>unsigned_short() -> TC</name>
- <name>long() -> TC</name>
- <name>unsigned_long() -> TC</name>
- <name>long_long() -> TC</name>
- <name>unsigned_long_long() -> TC</name>
- <name>wchar() -> TC</name>
- <name>float() -> TC</name>
- <name>double() -> TC</name>
- <name>boolean() -> TC</name>
- <name>char() -> TC</name>
- <name>octet() -> TC</name>
- <name>any() -> TC</name>
- <name>typecode() -> TC</name>
- <name>principal() -> TC</name>
- <fsummary>Return the IDL typecode</fsummary>
- <desc>
- <p>These functions return the IDL typecodes for simple types.</p>
- </desc>
- </func>
- <func>
- <name>object_reference(Id, Name) -> TC</name>
- <fsummary>Return the object_reference IDL typecode</fsummary>
- <type>
- <v>Id = string()</v>
- <d>the repository ID</d>
- <v>Name = string()</v>
- <d>the type name of the object</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for object_reference.</p>
- </desc>
- </func>
- <func>
- <name>struct(Id, Name, ElementList) -> TC</name>
- <fsummary>Return the struct IDL typecode</fsummary>
- <type>
- <v>Id = string()</v>
- <d>the repository ID</d>
- <v>Name = string()</v>
- <d>the type name of the struct</d>
- <v>ElementList = [{MemberName, TC}]</v>
- <d>a list of the struct elements</d>
- <v>MemberName = string()</v>
- <d>the element name</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for struct.</p>
- </desc>
- </func>
- <func>
- <name>union(Id, Name, DiscrTC, Default, ElementList) -> TC</name>
- <fsummary>Return the union IDL typecode</fsummary>
- <type>
- <v>Id = string()</v>
- <d>the repository ID</d>
- <v>Name = string()</v>
- <d>the type name of the union</d>
- <v>DiscrTC = TC</v>
- <d>the typecode for the unions discriminant</d>
- <v>Default = integer()</v>
- <d>a value that indicates which tuple in the element list that is default (value &lt; 0 means no default)</d>
- <v>ElementList = [{Label, MemberName, TC}]</v>
- <d>a list of the union elements</d>
- <v>Label = term()</v>
- <d>the label value should be of the <em>DiscrTC</em>type</d>
- <v>MemberName = string()</v>
- <d>the element name</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for union.</p>
- </desc>
- </func>
- <func>
- <name>enum(Id, Name, ElementList) -> TC</name>
- <fsummary>Return the enum IDL typecode</fsummary>
- <type>
- <v>Id = string()</v>
- <d>the repository ID</d>
- <v>Name = string()</v>
- <d>the type name of the enum</d>
- <v>ElementList = [MemberName]</v>
- <d>a list of the enums elements</d>
- <v>MemberName = string()</v>
- <d>the element name</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for enum.</p>
- </desc>
- </func>
- <func>
- <name>string(Length) -> TC</name>
- <fsummary>Return the string IDL typecode</fsummary>
- <type>
- <v>Length = integer()</v>
- <d>the length of the string (0 means unbounded)</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for string.</p>
- </desc>
- </func>
- <func>
- <name>wstring(Length) -> TC</name>
- <fsummary>Return the wstring IDL typecode</fsummary>
- <type>
- <v>Length = integer()</v>
- <d>the length of the wstring (0 means unbounded)</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for wstring.</p>
- </desc>
- </func>
- <func>
- <name>fixed(Digits, Scale) -> TC</name>
- <fsummary>Return the fixed IDL typecode</fsummary>
- <type>
- <v>Digits = Scale = integer()</v>
- <d>the digits and scale parameters of a Fixed type</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for fixed.</p>
- </desc>
- </func>
- <func>
- <name>sequence(ElemTC, Length) -> TC</name>
- <fsummary>Return the sequence IDL typecode</fsummary>
- <type>
- <v>ElemTC = TC</v>
- <d>the typecode for the sequence elements</d>
- <v>Length = integer()</v>
- <d>the length of the sequence (0 means unbounded)</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for sequence.</p>
- </desc>
- </func>
- <func>
- <name>array(ElemTC, Length) -> TC</name>
- <fsummary>Return the array IDL typecode</fsummary>
- <type>
- <v>ElemTC = TC</v>
- <d>the typecode for the array elements</d>
- <v>Length = integer()</v>
- <d>the length of the array</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for array.</p>
- </desc>
- </func>
- <func>
- <name>alias(Id, Name, AliasTC) -> TC</name>
- <fsummary>Return the alias IDL typecode</fsummary>
- <type>
- <v>Id = string()</v>
- <d>the repository ID</d>
- <v>Name = string()</v>
- <d>the type name of the alias</d>
- <v>AliasTC = TC</v>
- <d>the typecode for the type which the alias refer to</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for alias.</p>
- </desc>
- </func>
- <func>
- <name>exception(Id, Name, ElementList) -> TC</name>
- <fsummary>Return the exception IDL typecode</fsummary>
- <type>
- <v>Id = string()</v>
- <d>the repository ID</d>
- <v>Name = string()</v>
- <d>the type name of the exception</d>
- <v>ElementList = [{MemberName, TC}]</v>
- <d>a list of the exception elements</d>
- <v>MemberName = string()</v>
- <d>the element name</d>
- </type>
- <desc>
- <p>Function returns the IDL typecode for exception.</p>
- </desc>
- </func>
- <func>
- <name>get_tc(Object) -> TC</name>
- <name>get_tc(Id) -> TC</name>
- <fsummary>Fetch typecode</fsummary>
- <type>
- <v>Object = record()</v>
- <d>an IDL specified struct, union or exception</d>
- <v>Id = string()</v>
- <d>the repository ID</d>
- </type>
- <desc>
- <p>If the get_tc/1 gets a record that is and IDL specified
- struct, union or exception as a parameter it returns the
- typecode.</p>
- <p>If the parameter is a repository ID it uses the Interface Repository
- to get the typecode.</p>
- </desc>
- </func>
- <func>
- <name>check_tc(TC) -> boolean()</name>
- <fsummary>Check syntax of an IDL typecode</fsummary>
- <desc>
- <p>Function checks the syntax of an IDL typecode.</p>
- </desc>
- </func>
- </funcs>
-
-</erlref>
-
diff --git a/lib/orber/doc/src/orbs.gif b/lib/orber/doc/src/orbs.gif
deleted file mode 100644
index 47f2c85441..0000000000
--- a/lib/orber/doc/src/orbs.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/part.xml b/lib/orber/doc/src/part.xml
deleted file mode 100644
index ef84b8c05a..0000000000
--- a/lib/orber/doc/src/part.xml
+++ /dev/null
@@ -1,49 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE part SYSTEM "part.dtd">
-
-<part xmlns:xi="http://www.w3.org/2001/XInclude">
- <header>
- <copyright>
- <year>1997</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Orber User's Guide</title>
- <prepared></prepared>
- <docno></docno>
- <date>1998-04-26</date>
- <rev>2.2</rev>
- </header>
- <description>
- <p>The <em>Orber</em> application is an Erlang implementation of a
- CORBA Object Request Broker.</p>
- </description>
- <xi:include href="ch_contents.xml"/>
- <xi:include href="ch_introduction.xml"/>
- <xi:include href="ch_orber_kernel.xml"/>
- <xi:include href="ch_ifr.xml"/>
- <xi:include href="ch_install.xml"/>
- <xi:include href="ch_idl_to_erlang_mapping.xml"/>
- <xi:include href="ch_naming_service.xml"/>
- <xi:include href="ch_security.xml"/>
- <xi:include href="ch_stubs.xml"/>
- <xi:include href="ch_exceptions.xml"/>
- <xi:include href="ch_interceptors.xml"/>
- <xi:include href="ch_orberweb.xml"/>
- <xi:include href="ch_debugging.xml"/>
-</part>
-
diff --git a/lib/orber/doc/src/ref_man.xml b/lib/orber/doc/src/ref_man.xml
deleted file mode 100644
index 6fa409538d..0000000000
--- a/lib/orber/doc/src/ref_man.xml
+++ /dev/null
@@ -1,53 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE application SYSTEM "application.dtd">
-
-<application xmlns:xi="http://www.w3.org/2001/XInclude">
- <header>
- <copyright>
- <year>1997</year><year>2016</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>Orber Reference Manual</title>
- <prepared></prepared>
- <docno></docno>
- <date>1998-05-05</date>
- <rev>2.0</rev>
- </header>
- <description>
- <p>The <em>Orber</em> application is an Erlang implementation of a
- CORBA Object Request Broker.</p>
- </description>
- <xi:include href="any.xml"/>
- <xi:include href="fixed.xml"/>
- <xi:include href="corba.xml"/>
- <xi:include href="corba_object.xml"/>
- <xi:include href="orber.xml"/>
- <xi:include href="orber_ifr.xml"/>
- <xi:include href="orber_tc.xml"/>
- <xi:include href="orber_acl.xml"/>
- <xi:include href="CosNaming.xml"/>
- <xi:include href="CosNaming_NamingContext.xml"/>
- <xi:include href="CosNaming_NamingContextExt.xml"/>
- <xi:include href="CosNaming_BindingIterator.xml"/>
- <xi:include href="lname.xml"/>
- <xi:include href="lname_component.xml"/>
- <xi:include href="Module_Interface.xml"/>
- <xi:include href="interceptors.xml"/>
- <xi:include href="orber_diagnostics.xml"/>
-</application>
-
diff --git a/lib/orber/doc/src/theORB.gif b/lib/orber/doc/src/theORB.gif
deleted file mode 100644
index 976672b8df..0000000000
--- a/lib/orber/doc/src/theORB.gif
+++ /dev/null
Binary files differ
diff --git a/lib/orber/doc/src/tools_debugging_part.xml b/lib/orber/doc/src/tools_debugging_part.xml
deleted file mode 100644
index 94af44833c..0000000000
--- a/lib/orber/doc/src/tools_debugging_part.xml
+++ /dev/null
@@ -1,40 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE part SYSTEM "part.dtd">
-
-<part>
- <header>
- <copyright>
- <year>2002</year>
- <year>2016</year>
- <holder>Ericsson AB, All Rights Reserved</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- The Initial Developer of the Original Code is Ericsson AB.
- </legalnotice>
-
- <title>Tools, Debugging and FAQ</title>
- <prepared>Niclas Eklund</prepared>
- <docno></docno>
- <date>2002-06-25</date>
- <rev>A</rev>
- </header>
- <description>
- <p>This chapter describe the available tools and debugging facilities for Orber.
- Also contain a FAQ listing of the most common mistakes.</p>
- </description>
- <include file="ch_orberweb"></include>
- <include file="ch_debugging"></include>
-</part>
-