Issue 2153: CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier oper Jira Issue NOT13-1
Issue 2460: EventTypeRepository class issue Jira Issue NOT13-2
Issue 2501: Premature in eliminating Txn interfaces? Jira Issue NOT13-3
Issue 2512: suspend_connection/resume_connection messages - issue Jira Issue NOT13-4
Issue 3175: Notification service: admin MyChannel attribute Jira Issue NOT13-5
Issue 3517: Section 3.4.17. Page:136 Jira Issue NOT13-6
Issue 3518: Issue with pushing events Jira Issue NOT13-7
Issue 3519: The interface on EventChanel does not have the ability to get the ChannelId Jira Issue NOT13-8
Issue 3521: The Supplier Proxy & Consumer Proxy interfaces don't get ID's Jira Issue NOT13-9
Issue 6343: Notification Service IDL issues Jira Issue NOT13-10
Issue 9079: MaxEventsPerConsumer Jira Issue NOT11-1
Issue 2153: CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier oper (notif_service-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier operation, when asked for a proxy for a ClientType of ANY_EVENT, returns a proxy that is unuasable by event service clients. The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface returned inherits only from CosEventChannelAdmin::XSupplier, and then redefines the connect operation that was available in CosEventChannelAdmin:: ProxyXSupplier as connect_any_x_supplier. The interface can never be narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is unusable by the Event Service style client.
Resolution:
Revised Text:
Actions taken:
October 30, 1998: received issue
Discussion: :
Issue 2460: EventTypeRepository class issue (notif_service-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: In Appendix A it is stated that "the EventTypeRepository class only has one instance in any given implementation of the Repository". At the same time, there is a package interface and a package factory that implies that it"s possible to create multiple repositories (unless the NotificationTypesPackage interface is expected to always returns the same objects, no matter how many packages one have created).
Resolution:
Revised Text:
Actions taken:
February 19, 1999: received issue
Discussion:
Issue 2501: Premature in eliminating Txn interfaces? (notif_service-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: I feel there is a flaw in the model described in the current Notification Service spec for supporting Transactional Notification.
Resolution:
Revised Text:
Actions taken:
March 3, 1999: received issue
Discussion:
Issue 2512: suspend_connection/resume_connection messages - issue (notif_service-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The suspend_connection/resume_connection messages do not describe what should happen to messages that are queued up. Are new messages rejected for the duration between the disconect and resume? Are messages that were queued up flushed? How does the Persistent Event Reliablity QoS effect the way both are handled? size=2> Along the same lines, what happens to events when a consumer disconnects? I assume events in this case would be lost.
Resolution:
Revised Text:
Actions taken:
March 4, 1999: received issue
Discussion:
Issue 3175: Notification service: admin MyChannel attribute (notif_service-rtf)
Click here for this issue's archive.
Source: Micro Focus (Mr. Bjarne Rasmussen, nobodybrasmussen(at)silverstream.com)
Nature: Uncategorized Issue
Severity:
Summary:
The notification service administration objects support an attribute called MyChannel that returns the event channel that first created the administration object. The value type of this attribute is EventChannel. For typed administration objects, the typed channel can not be returned because a TypedEventChannel is not compatible with an EventChannel. One solution is to change the value type of this attribute to a generic Object, which can be narrowed to the correct type.
I see the following features lacking in CosNotification spec. What is the process on having this raised as an issue, and if all agree add it to the spec in the later revisions. Any info is appreciated. 1. Section 3.4.17. Page:136. The EventChannel interface in CosNotification, does not allow to retrieve its ChannelId. This is unlike the interface on the admins which allow to get the adminids? It would be very handy to retrieve the channel id given event channel. I also do not see a way to retrieve proxyId's given a consumer proxy or supplier proxy.
2. Publishers are allowed to push events for the types they have not offered using offer_change(). This can allow publishers to never advertise the event types they are offerring. For Example, as a consumer it can not tell what are the event types that will be offered on the channel. Can we require publishers to always call offer_change() on the new event types before pushing them to the event channel? If this behavior breaks existing functionality, then how about having push_xxx() check to see if the event type is offered, if not add it to the aggregate list?
1. The interface on EventChanel does not have the ability to get the ChannelId? This is quite contrary to the ability on the admin interfaces to retrieve the adminId's. Given a proxy to EventChannels's it will be very handy to retrieve the channelId's.
The interface on EventChanel does not have the ability to get the ChannelId? This is quite contrary to the ability on the admin interfaces to retrieve the adminId's. Given a proxy to EventChannels's it will be very handy to retrieve the channelId's. The Supplier Proxy & Consumer Proxy interfaces also do not have the ability to get the ID's.
just came across Notification Service IDL where you are mentioned as contact person: When I "grep" on all IDL files I notice that orb.idl is not included. I notice further that file CosNotifyFilter.idl in line 105 makes use of TypeCode: readonly attribute CORBA::TypeCode value_type; However section 3.19 "CORBA Module" of current CORBA standard 3.0.2 reads as: >> Names defined by the CORBA specification are in a module named CORBA. In an >> OMG IDL specification, however, OMG IDL keywords such as Object must not be >> preceded by a "CORBA::" prefix. Other interface names such as TypeCode are not >> OMG IDL keywords, so they must be referred to by their fully scoped names (e.g., >> CORBA::TypeCode) within an OMG IDL specification. >> For example in: >> #include <orb.idl> >> module M { >> typedef CORBA::Object myObjRef; // Error: keyword Object scoped >> typedef TypeCode myTypeCode; // Error: TypeCode undefined >> typedef CORBA::TypeCode TypeCode;// OK >> }; >> The file orb.idl contains the IDL definitions for the CORBA module. Except for >> CORBA::TypeCode, the file orb.idl must be included in IDL files that use names >> defined in the CORBA module. IDL files that use CORBA::TypeCode may obtain its >> definition by including either the file orb.idl or the file TypeCode.idl. In my humble opinion, "your" Notification IDL is not correct. Perhaps you have some time left to comment on this?
The type of MaxEventsPerConsumer should be an unsigned long, why should this be long, so far as I can't tell there is no need for a negative number