In the ZIOP 1.0 specification, the IDL in Annex A has:

typedef unsigned short CompressorId { };

The braces are invalid and should be removed.

In the ZIOP 1.0 specification, Annex A has:

Compressor get_compressor(
in CompressorId compressor_id,
in CompressorLevel compression_level)
raises (UnknownCompressorId);

CompressorLevel should be CompressionLevel.

Section 17.3.1 of CORBA 3.1 / 3.2 says:

17.3.1 Structures

PolicyValue

This structure contains the value corresponding to a Policy of the
PolicyType indicated by its ptype. This representation allows the
compact transmission of QoS policies within IORs and Service
Contexts. **The format of pvalue for each type is given in the
specification of that Policy.**

When the ZIOP 1.0 specification describes the ZIOP policies, it does not
give the format for pvalue.

The ZIOP body format contains the original length of the compressed
data, which is important because it allows the compressor to efficiently
allocate a buffer to uncompress it. Unfortunately, the
Compressor::decompress() operation is not given that size, meaning that
it has to guess how big the uncompressed data will be.

The original data size should be given to the decompress() operation.
One way to do that without changing the operation signature would be to
specify that the inout Buffer target sequence should have its length
pre-populated to the expected size.

Summary:

Summary: Change the layout of both bounded and unbounded sequences to be the same

Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
This tool mangles the following identifier (not necessarily a complete list) by
prepending them with "_":

"BSTR", "CALLCONV", "coclass", "CY",
"CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
"dual", "EXCEPINFO", "guid", "GUID",
"HRESULT", "importlib", "IDispatch",
"INTERFACEDATA", "IUnknown", "LCID",
"METHODDATA", "odl", "oleautomation",
"PARAMDATA", "properties", "propget", "propput", "retval",
"SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
"VARIANT", "VARIANTARG", "VARIANT_BOOL",
"VARTYPE", "VARENUM"

As far as I can tell, the output of the "mktyplib" tool makes use
(directly or indirectly) of the regular C++ bindings, whose identifiers
are not mangled the same way. This makes it impossible to emit COM bindings
for IDL files that contain the above keywords.

The problem that I"m running into is in CosTrading IDL, where the identifier
"properties" is used.

>You write on page 18-51:
>In COM V2.0, interfaces can have single inheritance. However, as opposed to
>CORBA,
>there is a standard mechanism by which an object can have multiple interfaces
>(without
>an inheritance relationship between those interfaces) and by which clients can
>query
>for these at run-time. (It defines no common way to determine if two interface
>references refer to the same object, or to enumerate all the interfaces
>supported by an
>entity.)
>
>It's not right, that there's no common way to determine if two interface
>references refer to the same object. The IUnknown-Pointer of two different
>interfaces of the same object must be the same (object identity in COM).

Summary: (D)IForeignComplexType,(D)ICORBAStruct,(D)ICORBAUnion,(D)IForeignException,(D)ICORBAUserException should have standard UUIDs and UUID identifiers

Summary: The COM/CORBA Part A spec states that user exceptions go after return values in one place, and before return values in another. (3.2.10.3 and 4.1.3.1)

There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??

IDL4 extends the IDL type system with int8/uint8/map/bitset/bitfield/bitmask, these all could be useful at the CORBA layer so to have guaranteed interoperability CORBA should define the CDR marshaling support for these new types

CORBA 3.4 should have support for int8/uint8/map/bitset/bitfield/bitmask/bitvalue for DynamicAny, DynamicSkeleton, Interface Repo, Any/TypeCode and other CORBA APIs related to types

RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
The document citation indicates that the integrity of the valuetype –
that is, the received marshalled state – is to be preserved in an
ORB-mediated operation, even if that valuetype cannot be unmarshalled,
either partially (truncated) or at all. If this value is then passed to
another operation, the original marshalled state is to be transmitted.
This preserves the transmitted object in its entirety, regardless of
local implementation concerns. This is obviously necessary for bridges
or event processing, such as through the notification service.

So the question arises, what happens if you have a partial (truncated)
unmarshall and the recipient application changes the local state of the
valuetype through its attributes or local operations? How can/will you
even know the state was changed? Do you ignore the changes and send the
originally received marshalled stream, send only the new valuetype even
though it is a truncation of the original, or "merge" the new values for
the unmarshalled part followed by the original appended data for the
truncated part? Should this third option be possible through an
explicit ORB call – that is, the application is responsible to identify
the change in state to the ORB? I assume that the semantics of
"truncatable" must come to include the understanding that data in the
truncatable portions may not be contextually dependent on the inherited
parent of the valuetype.

As a further question, is there a reason why this semantic
interpretation should not be extended to be a general requirement rather
than only with respect to transmission of anys? My experience has found
that passing anys tends to be expensive and is avoided where it can be.
A more general interpretation permits transmission of a comprehensive
data structure among intermediate agents that only use (unmarshall) the
information they need.

Suggested changes to the AssemblyFactory interface.

AssemblyFactory Issues.

1. Ease of use Issue. After the create operation is performed, one is
force to call lookup to get the Assembly that just got just created. Why is
a cookie returned by the create operation instead of an Assembly? Is the
reason because of security? If the interface were more open this would
still allow a secure implementation to be implemented.
Suggested change is to return an Assembly instead of a Cookie. Change
destroy operation to take in an Assembly parameter instead of Cookie.
Change lookup operation to take in a name parameter. These changes
make it consistent with the other CCM interfaces, such as Container,
KeyLessCCMHome, ComponentServer, and ServerActivator.
2. Multiple users Issue. For multiple users, how does a client know what
assemblies are created. Add a get_assemblies operation that returns a list
of assemblies. These changes make it consistent with other CCM interfaces,
such as Container, ComponentServer, and ServerActivator.
3. User-friendly identifier for Assembly Instance issue. Add an input
name parameter that can be assigned to the Assembly instance that gets
created. Add a read only name or label attribute to the Assembly interface.

in the BaseIDL there is a class StructDef which has the Attribute members of
Type Field. How can I model a IDL struct with more than one entry?
I think there should be a aggregation from StructDef (1<>----->*) to the Field
class (Page 8-10 of the CCM Spec).

*) With EnumDef there is the same problem, I guess a assotiation from EnumDef to
string (1<>----->*) would solve it (Page 8-10 of the CCM Spec).

*) Also with ExceptionDif and its attribute members (Page 8-11 of the CCM Spec).

• document : formal/02-06-65
• chapter : 1.5.2.4

• text in question :

module Components
{
valuetype Cookie

;
};

• Issues :

1. Naming style used in this definition violates rules defined in
"OMG IDL Style Guide" (ab/98-06-03).

2. Naming style used in this definition is inconsistent with other parts
of the CCM IDL, for example:

module Components
{
valuetype PortDescription

;

valuetype FacetDescription : PortDescription

;
}

• suggested resolution : replace `cookieValue' with `cookie_value'

Using the static invocation interfaces, it is possible to receive a
valuetype that derives from the one declared in an operation, as long
as a valuetype factory is known in the receiver (truncation is not the
issue here).

The same is not possible at the DII: When creating the request, the
caller must indicate what type it expects, by forming a named value.
Conceptually, the typecode in the named value should be the typecode
of the base of all acceptable value types. However, if the ORB
receives a derived type, it has no means of unmarshalling it - even if
the application has knowledge about the derived type.

What is missing is an interface to make typecodes of value types known
to the ORB; with those, the ORB could then understand the CDR of the
valuetype, and create a DynAny when asked to.

Due to the way that custom values are marshaled it is
nearly impossible for a bridge (or other process) to
process/forward GIOP messages which contain custom
marshaled values (which the bridge has no compile/run-time
knowledge of).

The main issue is that the "alignment" of the
custom marshaled data is unknown, other than the
data will always start on a four byte boundry due
to the presence of chunking.

Should/could the value encoding format be changed to
enforce eight byte alignment for all custom marshaled
data (chunks)? This would allow bridges and other
tools to process->[store]->forward messages containing
custom values.

Summary: How does this operation work?

Summary: Several of the bullets in section 11.1.5 are unclear.

Summary: Is it correct to offer the vanilla collection methods and add a new set for keyed access?

Summary: When reading a stream, there is no way of telling where context (limited to calls to begin_context and end_context) end and a new one starts.. Resolved problem with new "tag-byte" 0xFF.

I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In
section 15.8 paragraph 5 on page 15-55, the specification states:

"If the client ORB policy permits bi-directional use
of a connection, a Request message should contain an IOP::ServiceContext
structure in its Request header, which indicates that this GIOP connection
is bi-directional."

but then in section 15.9 paragraph 4 on page 15-59, the specification
states:

"In the absence of a BidirectionalPolicy being passed in the
PortableServer::POA::create_POA operation, a POA will assume a policy value
of
NORMAL."

but then again in the next sentence the specification states:

"A client and a server ORB must each have a BidirectionalPolicy with a value
of
BOTH for bi-directional communication to take place."

Could someone clarify for me what the intent for the scope of the policy was
here, and what the rationale behind that decision was? We are currently
reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
and I would like to understand the issues regarding the scope of the BiDir
policy.

The creation of a TcUser interface with multiple associations does not have
a standardised way for destruction.

Proposed solutions

1. Add a destroy() method to TcUser
2. Explicitly state in the RFP that the CosLifeCycle::destroy() method should
be called once the object is no longer required.

Summary: Problem: It is not necessary to have uniqueness of Invoke Ids within a dialog.
The invoke id can be reused as soon as it is no longer active.

Proposed solution: Put in text following the discussion of management of invoke
ids in the TC spec.

In section 4.2.5 of the CCM spec formal/02-06-65, it is said that "Servant lifetime policies may be defined for each segment within a component", but there is no way to do it. Lifetime policy is declared in the CCD descriptor of the component, as an attribute of the "servant" XML element, and is implicitly applied on all the segments of the component(when it is segmented) !

Suggested resolution: to leave the servant element as it is, expressing a DEFAULT lifetime policy, and to add the same servant element as an optional child of the segment element. This will specify the lifetime policy of the segment and override the defautl one. DTD has to be changed as follows :

<!ELEMENT segment
( segmentmember+
, containermanagedpersistence?
, extension*
>
<!ATTLIST segment
name CDATA #REQUIRED
segmenttag CDATA #REQUIRED >

becomes:

<!ELEMENT segment
( segmentmember+
, servant?
, containermanagedpersistence?
, extension*
>
<!ATTLIST segment
name CDATA #REQUIRED
segmenttag CDATA #REQUIRED >

In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
is this text:

"Declarations for facets, receptacles, event sources, event sinks,
and attributes all map onto operations on the component's equivalent
interface. These declarations and their meanings are described in
detail below."

In the following sections, I see facets, receptacles, event sources,
and event sinks described, but I see no mention of attributes.
It would be usefult to have an example of attributes in an appropriate
place, as outlined by section 1.3.3.

In section "1.10 Configuration with Attributes", I see that configurators
are described, but I see no example of using attributes directly
to configure a component.

It would be very useful to include a small example to illustrate
how to configure a component directly by using attributes.

Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

======================================================

component Whatever

;

home WhateverHome manages Whatever
{
};

// C++
WhateverHome_var weh = // obtain ref
Whatever_var we = weh->create();

we->cacheMaxKb(200);

we->configuration_complete();

======================================================

I don't suggest that this example be used verbatim,
but a similar example would be useful to have in the
CCM spec.

Summary: Description:
Clarification is needed on the passing of credentials.
Section 4.7.3 states that "Since all proxies will have access to the IOR of
the target object, and the certificate of the client, they can judge whether
this client may use a pass-through connection or not." Section 4.12 states
that "When a client establishes a normal connection to a target via a
trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to
achieve end-to-end authentication, the proxy will have to forward the
client"s certificate/identity to the server." Section 4.12 implies that the
ForwardedIdentity service context will only be used when using a secure
transport, but section 4.7.3 implies that the client certificate will always
be available. In fact, the ForwardedIdentity service context should only be
used in the case of a NORMAL connection using a secure transport because
those are the only conditions under which there is a notion of trust between
a requestor and the recipient of that request. This means that the only
mechanism upon which to base a decision of whether or not to allow a
PASSTHRU connection is the source host address/port.

In section 1.1.2 of the CCM specification:

1.1.2 Ports
===========
..... The component model supports four basic kinds of ports:

• Facets
• Receptacles
• Event sources
• Event sinks
• Attributes

Well, that list includes five things, not four.

So, is an attribute considered a port or not?

The wording in this section needs to be clarified in the CCM
specification, because it is not clear if an attribute
is a port or not.

Summary: On page 9, paragraph beginning with "Within an interface...." should read "..attributes should appear after operations..."

The following information is sent in order for the specification to
clearly state if components and local interfaces can support abstract
interfaces (the specification is confusing on this point).

CORBA 3.0.1 does not explicitely states if a component can support an
abstract interface, thus it can be considered that it is possible. If so
a big problem arises as local interfaces inheriting abstract ones is
confusing in the specification.

In addition, it is neither explicitely stated that provides and uses
declarations can or cannot be of types defined through abstract
interfaces. It does not seem to make sense for a port to be an abstract
type. Facets will never be used by value, and an operation cannot
(should not) return the reference of a facet or a valuetype (which would
be in favor of provides to be defined using abstract interfaces).

• • Problem

Consider the following definitions which are correct regarding
formal/02-12-06:

/* omg idl3 */

abstract interface I

;

interface C : Components::CCMObject, I { } ;

local interface CCM_C : I { } ;

According to formal/02-12-06, the last line may not be correct. Local
interfaces may not inherit abstract interfaces (section 10.5.28). (I use
may as it is confusing and can lead to various understanding of the
spec.)

• • Potential solutions:

1. State in the CORBA 3.0.1 that components cannot support abstract
interfaces. In favor: Could ne considered as a minor change. Against: a
component reference cannot be returned by an operation that can return
an object by value or by reference. This solution looks cleaner that the
second one from a software engineering point of view.

2. Clearly state that components and local interfaces can support
abstract interfaces. This use may be surprising from a software
engineering point of view, but may be important for some users. This
bring back the debate "quality vs powerfulness".

In any case, I think it should be clearly stated if local interfaces may
or may not inherit abstract ones.

Summary: When multiple union labels resolve to the same union member, the property accessor for that union member has an additional (optional) argument

Summary: The following methods should be added to DIForeignComplexType, IID should be changed: string type_name(); string scoped_name(); string_repository_id(); more details in corresponding archive file

Summary: Third bullet should read:"...are sorted based upon interface name.." Last bullet should read "..the operations introduced in the current interface are mapped last and ordered.."

Summary: Example of "on both machines" does nor correspond to the diagrams. Add "on an intermediate machine" to sentence

Identifier (FPI).

These FPIs are required for the CAD, CSD, CCD and CPF DTDs.

Proposed resolution:

Adds the CCM DTDs on the OMG web site and adds the following text in the specification:

• section 6.3, before subsection 6.3.1 :

The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "http://www.omg.org/dtd/softpkg_3_0.dtd" />

• section 6.4, before subsection 6.4.1 :

The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

• section 6.4.4:

replace

<!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd">

with

<!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

• section 6.7, before subsection 6.7.1 :

The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

• section 6.7.1:

replace

<!DOCTYPE componentassembly SYSTEM "componentassembly.dtd">

with

<!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

• section 6.8, before subsection 6.8.1 :

The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "http://www.omg.org/dtd/properties_3_0.dtd" />

Summary: There are a bunch of code samples that use a different font than the rest of the document

Summary: Section 4.1.18.6 Table 4-14: A few of these mappings don"t seem to make sense (i.e. the meaning of the different exceptions in each object system is much different

The description for Object::get_policy (in the Core, section 4.3.7.1)
states:

"The get_policy operation returns the policy object of the specified
type (see Policy Object on page 4-32), which applies to this object. It
returns the effective Policy for the object reference. The effective
Policy is the one that would be used if a request were made."

For a policy defined by PI, I don't see anyway for the ORB to implement
this operation correctly, since there isn't any way for it to know how
to properly resolve any client override policies with the policy
information stored in the IOR.

When a invocation is actually in process, the ClientRequestInterceptor
can use the information available in the ClientRequestInfo interface to
get the client override and the IOR policy data and do the correct
resolution before continuing with the request. However,
Object::get_policy() needs to do the same type of thing, but it has no
invocation context to do it in.

I think the same problem also applies to the implementation of
ClientRequestInfo::get_request_policy().

I think we need a new interception point to do this work. Something
like:

local interface PolicyInterceptor

;

local interface PolicyInfo

;

If this turns out to be an acceptable solution, then we should also
change ClientRequestInfo to:

local interface ClientRequestInfo : RequestInfo, PolicyInfo

;

and remove the redundant operations.

Issue on Document orbos/2000-08-04, CSIv2 Joint Submission

Document: orbos/2000-08-04, CSIv2 Joint Submission
Subject: Identity Assertion of X.501 Distinguished Name is not good enough
Severity: Critical

Summary:

The Identity Token union contains a branch that is labled
X501DistinguishedName. A single DN is insufficient to identify an entity.
A path of X501Distinguished Names is needed instead. Also, other concerns
about naming types are raised.

Discussion:

An X.501 Distinguished Name is insufficient to identify a single entity.
The name must be accompanied by the name of its defining authority. In the
case of public key certificates, the names certificate authority must be
included.

The chain of DNs in this manner must be included up to a root authority
to have any definitive meaning.

This approach will be consistent with the client sending a X.509
Certificate Chain. A DN path is actually defined by the certificate chain.

Furthermore, the DN path should only come from an authority that is
acceptable to the server, whether it be a DN path, or an X.509
Certificate Chain.

The IOR should list the acceptable authorities and their name types.

It is becoming more an more evident that we must invent GSS_NT_Export_Name
types for X.509 Certificate Chain and X.501 DN path.

The SAS_ContextSec structure should list, instead of the naming types,
the naming authorities!

We shall assume that the name types of the asserted identities shall be
the same as the name types of listed naming authorities in the IOR.

This is the only way this procedure can work Interoperable and without
the client Guessing what it should do.

Suggestions:

An OID for an X.509 Public Key Certificate Chain shall be defined for a
GSS Export Name, and its encoding will be a ASN1 sequence of and X.509
certificate with the least significant certificate first.

An OID for an X.501 Distinguished Name Path shall be defined for a GSS
Exported Name, and its encoding shall be an ASN1 sequence of an X.501
Distinguished Name with the least significant name first.

To avoid having the target put a whole certificate chain in its IOR,
a new OID shall be allocated in which its GSS Exported Name encoding is a
X.501 DN path, but stipulates that the client should send a certificate
chain from that named authority. This GSS Exported Name shall only be
used in IORs and not for transmission in the Identity Token.

typedef Security::GSS_NT_ExportedName NamingAuthority;

struct CompoundSecMech

;

The CORBA 2.3.1 specification does not cover the interaction between the
DynValue interface and custom valuetypes.

I frankly don't see any way that the DynValue interface can possibly
correctly handle a custom valuetype when the ORB does not have a factory
for the type. It is theoretically possible for DynValue to properly
work with a known custom type, but the implementation strategy could not
be based on parsing the marshalled form of the valuetype.

So, there are two issues that need to be addressed:

1. Should DynValue handle custom valuetypes at all?

2. For the set of custom valuetypes that it cannot handle, what
exceptions should be raised by each operations?

Issue: The association of entity component primary key and PSS key is unclear. There is only one attribute as the primary key in the CCM entity component, PSS has no primary key. An entity can be identified uniquely by the PSS key, but currently PSS permits several keys, and each PSS key can be composed of several attributes. Consequently, it is difficult to establish association between entity component primary key and PSS key, and the create and find methods can not to be mapped to the corresponding methods of PSS.

The draft CORBA 2.3 spec (ptc/99-03-07) does not deal with a potential deadlock situation. If an object is explicitly deactivated with POA::deactivate_object(), the object remains in the active object map until all operations pending on the object have completed. Any attempts to reactivate the object (implicitly via a ServantActivator, or explicitly via activate_object_with_id()) must block until the pending invocations have completed. However, if a servant's implementation of an object deactivates the object and then (directly or indirectly through a call to another collocated object) reactivates the object, the invocation will deadlock.

Summary: Existing software based on messages with ASNI format description and a future version based on IDL. Does anybody know something about such a compiler?

Summary: There is a bit of confusion in the specification concerning the
exceptions that are possible during the internalization process.

The internalize operation can raise CosLifeCycle::NoFactory and
StreamDataFormatError exceptions. This operation calls the
internalize_from_stream operation of the Streamable interface that can
raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
ObjectCreationError exceptions.The last paragraph on page 8-20 (August
1997 release) states that the ObjectCreationError and
StreamDataFormatError exceptions of the internalize_from_stream
operation originate from the read_object amd read_<type> operations on
the StreamIO interface. However, the ObjectCreationError is not raised
by any of these, according to the IDL in figure 8-6.

The CCMObject interface contains numerous operations for generic
connection management (in addition to the type-specific operations
defined by equivalent IDL for a component).

However, there's a separate set of "connect" and "disconnect"
operations for each kind of port, i.e., receptacles, emitters and
publishers. This is inconvenient for generic software that treats
ports generically, such as the deployment infrastructure in an
implementation of the Deployment and Configuration specification.

The set of operations might even get larger in the future, when
Streams for CCM becomes available.

I thus propose to add generic "connect_feature" and "disconnect_
feature" operations that is able to interconnect compatible ports
regardless of the type of port.

Proposed resolution:

In section 1.11.1, "CCMObject Interface," add the following two
operations to the CCMObject interface:

module Components {
interface CCMObject : Navigation, Receptacles, Events

;
};

Add the following explanation to the same section:

connect_feature

The connect_feature operation connects the object reference
specified by the connection parameter to the component feature
specified by the name parameter. The feature must be either a
receptacle, emitter or publisher port.

If the feature identified by the name parameter is a receptacle
port, the connect_feature operation acts equivalent to calling
the connect operation on the Receptacles interface.

If the feature identified by the name parameter is an emitter
port, the connect_feature operation acts equivalent to calling
the connect_consumer operation on the Events interface. A nil
"cookie" value is returned.

If the feature identified by the name parameter is a publisher
port, the connect_feature operation acts equivalent to calling
the subscribe operation on the Events interface.

If the feature identified by the name parameter is neither
receptacle, emitter or publisher port, or if the component does
not have any feature by that name, the InvalidName exception is
raised.

disconnect_feature

The disconnect_feature operation dissolves the connection
identified by the ck cookie to the component feature specified
by the name parameter.

If the feature identified by the name parameter is a receptacle
port, the disconnect_feature operation acts equivalent to calling
the disconnect operation on the Receptacles interface.

If the feature identified by the name parameter is an emitter
port, the disconnect_feature operation raises the InvalidConnection
exception if a non-nil cookie is passed as the ck parameter;
otherwise, it acts equivalent to calling the disconnect_consumer
operation on the Events interface.

If the feature identified by the name parameter is a publisher
port, the disconnect_feature operation acts equivalent to calling
the unsubscribe operation on the Events interface.

If the feature identified by the name parameter is neither
receptacle, emitter or publisher port, or if the component does
not have any feature by that name, the InvalidName exception is
raised.

I develop CosConcurrencyControl service for JacORB, but I don't
understud from specification how client can destroy LockSet.
When I create Object which allow concurrency access, I create LockSet.
When I destroy this Object I must destroy LockSet, because it's garbage,
bu no way for this does not exists.

As solution of this problem, I add in CosConcurrencyControl.idl next
changes:
exception LockExists{};

and method
void destroy raises (LockExists);

in interface LockSet.

As I undestand this changes is wrong, but have you idea about desigion
this problem.

Summary: in section 4.9.2 last paragraph:

"Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
interface I. Any event on the channel that does not correspond to an
operation defined in interface I is NOT passed on to the consumer. Such a
ProxyPushSupplier is therefore an event filter based on type".

My question is: if we have this proxy to block generic calls (push() in this
case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
support push() ? Why should the generic calls like push() be blocked anyway
if (according to 4.7.1) TypedPushConsumer should support both typed and generic
models ?

Is there something I am misunderstanding ?

Summary: Issue regarding implementation of the Query IDL specifications on a Java ORB. Issue involves implementing following idl definition from the CosQueryCollection module

Summary: It is not believed that the spec ever defines what a "malformed" PropertyName is. The closest definition is in para on page 26, section 5.1.1.2 and is not much help