Whiteboard handler ordering is not honoured

[timothyjward]

Current Behavior

The specification states in 160.1.4 that Handler services are ordered according to the "natural order" of the services, i.e. that higher ranked services are run earlier, and services with equal ranking run in ascending order of service id.

This is not honoured in the specification. If two services have equal ranking then the order that they run in is undefined, also if they are ranked then they appear in the correct order in the DTO, but are run in the reverse order in the handler chain.

Expected Behavior

Handler services should use the natural order of services for ordering (e.g. by using compareTo on the service reference) so that they order correctly when they have the same rank. This order should then be honoured in the DTO and the handler chain.

Steps To Reproduce

No response

Version

latest snapshot

Are you interested in contributing a solution yourself?

None

Anything else?

No response

[laeubi]

The handlers are not sorted in the DTO and I'm not sure this is anything useful or mandated. So if you see any order here it is more a random side-effect.

Also notice that your handler will be called twice one for the inbound and one for the outbound message, as per specification:

For outbound messages handler processing starts with the first handler in the chain and proceeds in the same order as the handler chain. For inbound messages the order of processing is reversed: processing starts with the last handler in the chain and proceeds in the reverse order of the handler chain.

So in the case of server side call you will first see an inbound message (request) and lowest to highest handler is called and then for an outbound message (response) and highest to lowest is called!

Also note that according to the spec all logical handlers precede all protocol handlers.

Beside that, I can see that even if we give the handler in the desired order in the implementation I created a PR to print the infos here #20 )

This might be confusing at the first sight but the implementation behaves correctly here from my point of view.

From my PR you will see the following output:

Handler List is: 
 Rank 100 / Id 44 = org.eclipse.osgi.technology.webservices.integration.tests.handler.TestSoapHandler2@6917bb4
 Rank 0 / Id 42 = org.eclipse.osgi.technology.webservices.integration.tests.handler.TestLogicalHandler@6ed16657
 Rank 0 / Id 43 = org.eclipse.osgi.technology.webservices.integration.tests.handler.TestSoapHandler@1442f788

Set Handler Chain:
  0) org.eclipse.osgi.technology.webservices.integration.tests.handler.TestSoapHandler2@6917bb4
  1) org.eclipse.osgi.technology.webservices.integration.tests.handler.TestLogicalHandler@6ed16657
  2) org.eclipse.osgi.technology.webservices.integration.tests.handler.TestSoapHandler@1442f788

[inbound] TestSoapHandler.handleMessage no. 1
[inbound] TestSoapHandler2.handleMessage no. 1
[inbound] TestLogicalHandler.handleMessage no. 1 

Echo 'Hello World' to caller!

[outbound] TestLogicalHandler.handleMessage no. 2 
[outbound] TestSoapHandler2.handleMessage no. 2
[outbound] TestSoapHandler.handleMessage no. 2

TestLogicalHandler.close()
TestSoapHandler2.close()
TestSoapHandler.close()

[timothyjward]

The handlers are not sorted in the DTO and I'm not sure this is anything useful or mandated. So if you see any order here it is more a random side-effect.

We should discuss this on the next call. It seems odd that there is a specified order for handlers and the DTO may ignore it.

So in the case of server side call you will first see an inbound message (request) and lowest to highest handler is called and then for an outbound message (response) and highest to lowest is called!

This is what is expected by the TCK, and is the same in other similar specifications (e.g. Jakarta REST request/response handlers).

Also note that according to the spec all logical handlers precede all protocol handlers.

This is why the TCK test only uses logical handlers. See CaseChangingHandler and ReversingHandler in https://github.com/timothyjward/osgi/tree/tw/jakartaws-tck/org.osgi.test.cases.webservice/src/org/osgi/test/cases/webservice/webservices

The failing test is visible at https://github.com/timothyjward/osgi/blob/tw/jakartaws-tck/org.osgi.test.cases.webservice/src/org/osgi/test/cases/webservice/junit/HandlerRegistrationTests.java#L399-L442

This test registers handlers that should change case then reverse the string on the inbound, then change case on the outbound. The test fails as the string is reversed then changed on the inbound, then changed on the outbound. This indicates that the handlers are added out of order.

[laeubi]

We should discuss this on the next call. It seems odd that there is a specified order for handlers and the DTO may ignore it.

I must confess even though we use arrays this is more due to restriction of data types and one should see these as a collection of things. It would of course be possible to order the DTOs I just don't see much of a value / need for this.

This test registers handlers that should change case then reverse the string on the inbound, then change case on the outbound.

I must confess that the code is to complex for being understood what is really happening there, but as you register them in the order:

1. CaseChangingHandler
2. ReversingHandler

it will be executed:

1. on the message received (inbound == what the client sends) as ReversingHandler (2) then CaseChangingHandler (1)
2. on the message send (outbound == what the endpoint returns) as CaseChangingHandler (1) and ReversingHandler (2)

A much more simpler approach for testing ordering of handlers would be an AtomicInteger shared by two handlers and each increment and get the value on the handler call and store it in an inbound/outbound field. Then one can assert absolute order based on plain numbers stored in the handlers and you don't need to permutate the message at all.