This interface represents an entity that can be written to an OutputStream and has an identity that is represented by an integer.
Factory interface for creating Identifiables.
Interface used to manage a group of related IdentifiableFactory instances.
An IOR is represented as a list of profiles.
An IORFactory provides the capability of creating IORs.
An IORTemplate provides all of the data necessary to create an IOR except for the typeId and ObjectId.
An IORTemplateList is a list of IORTemplate instances.
This is the object adapter ID for an object adapter.
The full object key, which is contained in an IIOPProfile.
Construct ObjectKey and ObjectKeyTemplate instances from their CDR-marshalled representation.
An ObjectKeyTemplate represents the part of an Object Key that corresponds to the object adapter used to create an object reference.
Generic interface for all tagged components.
TaggedProfile represents a tagged profile in an IOR.
Base template for creating TaggedProfiles.
This interface represents an entity that can be written to an OutputStream.
Provide support for properly reading and writing Identifiable objects that are also encapsulations (tagged profiles and components).
Convenience class for defining objects that contain lists of Identifiables.
This class provides a number of factory methods for creating various IOR SPI classes which are not subclassed for specific protocols.
Base class to use for implementing TaggedComponents.
Provides access to the components and profiles in an IOR without the overhead of CDR encoding.
The abstract model of IORs works as follows:
In all cases, containment is represented by having the appropriate interface (IOR and IIOPProfileTemplate above) extend java.util.List. This makes it easy to use all of the facilities in the Java collections framework with IORs. However, note that all objects available through these APIs are immutable. Thus all list update operations through UnsupportedOperationException, and list iterators cannot modify the underlying list.
Templates are used because the basic object adapter model for object creation is to establish all properties of an IOR (except for type and object ID) when the object adapter is created. This has been present for the POA essentially from the beginning, since policies can only be passed to create_POA, and cannot be changed on an existing POA. The Portable Interceptors work has also made this clear, since the IOR interceptor runs only when an object adapter is created, which is the only time that user code can add tagged components to an IOR.
Copyright © 2019 JBoss by Red Hat. All rights reserved.