JAX-WS spec language about setting an Executor on a Service instance needs to be clarified (see spec sub-section 4.1.4 Executor)

[glassfishrobot]

"4.1.4 Executor

• Conformance (Use of Executor): If an executor object is successfully configured for use by a Service via
  the setExecutor method, then subsequent asynchronous callbacks MUST be delivered using the specified
  executor. Calls that were outstanding at the time the setExecutor method was called MAY use the
  previously set executor, if any. "

Above section implies that a second setExecutor on a Service will be used for all new requests (and allows outstanding requests to be handled by either the new or old Executors). But with RI 2.1.5 client we found that once the port instance is instantiated, any subsequent setExecutor calls on the Service do not take effect on existing port instances.

It's probably the case that if another port instance were created, after a second setExecutor, then requests from that second port instance would use the second Executor, while requests from the first port instance would continue to use the first Executor. The rule seems to be that an Executor set on a Service is bound to the port instance when it is instantiated. Once an Executor is bound to a port instance, it cannot be changed for a different Executor. We think that some additional text should be added to this conformance statement, indicating this behavior. Note that there is already analogous language in the conformance statement for Handler Resolver in section 4.1.3.

We discussed this with Jitendra Kotamraju and I quote him below:

"I would go with the current RI behaviour. Service is like a factory for creating proxy objects, so the executor that is set after proxy creation shouldn't affect already created proxy objects. If you can file a bug, we can add the clarification in the next spec revision."

Environment

It is about adding the clarification in the next spec revision.

Affected Versions

[2.1.5]

[glassfishrobot]

Reported by umjoshi

[glassfishrobot]

Was assigned to jitu

[glassfishrobot]

This issue was imported from java.net JIRA JAX_WS-939