It seems that configuration option for (1: ClientId) is already in place. Client or service can register a feature containing properties to be overriding. This feature will retrieve Conduit or Destination from client or sever and replace configured properties in JMSConfiguration of Conduit or Destination correspondingly. It is possible to override any URL JMS property, if necessary.
Any thoughts regarding (2): unsubscribing from durable subscriptions? Regards, Andrei. > -----Original Message----- > From: Andrei Shakirin [mailto:[email protected]] > Sent: Donnerstag, 25. September 2014 16:03 > To: [email protected] > Cc: Christian Schneider > Subject: JMS: configuration of ClientId using JMS compliant style (CXF 3.x.x); > unsubscribe from durable subscriptions > > Hi, > > I am analysing possible extension of ClientId JMS configuration using JMS > compliant style (through URL). > > 1. ClientId. > Use case: the CXF client and service communicating using JMS Topic and > durable subscription. > Both client and service using ClientId and durable subscription name in order > to > identify state maintained on behalf of the client by a provider. > ClientId is specified through durableSubscriptionClientId parameter in > endpoint > URL. > URL is resolved globally for client and service through the WSDL stored into > ServiceRegistry / ServiceLocator. Therefore URL is shared between all client > and service instances of this service. > > Problem: as soon as some client instances are running on the same host (or > client and service are running on the same host), the JMS connection is > rejected because of using the same ClientId. > > Proposal: Would it makes sense to provide a way to override ClientId in the > URL: for example define ClientId as local jax-ws property on the client and on > the server sides. JMS transport will check for this property, if it isn't set > - use > value from URL. If it is set - use property value. > > 2. Durable subscription. > Currently CXF destination hasn't any mechanism to unsubscribe from durable > Topic subscription. Of course, we cannot simply unsubscribe by Destination > deactivation, because service can expect to receive the messages from the > Topic by next start. I see two options: > a) introduce kind of property to explicitly specify when destination should > be > unsubscribed from the durable Topic subscription > b) leave it completely out of scope of CXF and document that it is > administration activity to remove durable JMS subscriptions > > Any thoughts? > > Regards, > Andrei.
