Allow retrieving ocpp handler

[andig]

Proposed changes

Refs #294. This PR allows developing custom handlers without having to reimplement the entire default handler.

Types of changes

What types of changes does your code introduce?

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

[lorenzodonini]

I'm fine with merging this, but I'm not entirely convinced of the purpose of this feature. Retrieving a request handler at runtime allows to then invoke it arbitrarily:

handler(someWebsocket, requestObj, "dummyID", "BootNotification")

But this would break the library's flow, as you would be invoking your own application's callback without a message actually coming in. This may be harmless for the request handler but can lead to unexpected behavior for the response handler (there's state involved).

If this is only for testing purposes I would rather work on providing a cleaner methodology/API for this purpose.

Or am I misunderstanding this?

[andig]

But this would break the library's flow, as you would be invoking your own application's callback without a message actually coming in.

Agreed. Our purpose is really specific: we're using this solely for testing a CP not responding to a particular kind of message (which we're observing in reality):

func (suite *ocppTestSuite) TestTimeout() {
	// 1st charge point- remote
	cp1, ocppjClient := suite.startChargePoint("test-4", 1)
	suite.Require().NoError(cp1.Start(ocppTestUrl))
	suite.Require().True(cp1.IsConnected())

	handler := ocppjClient.GetRequestHandler()
	ocppjClient.SetRequestHandler(func(request ocppapi.Request, requestId string, action string) {
		if action != core.ChangeAvailabilityFeatureName {
			handler(request, requestId, action)
		}
	})

	// 1st charge point- local
	_, err := NewOCPP("test-4", 1, "", "", 0, false, false, ocppTestConnectTimeout)

	suite.Require().NoError(err)
}

In that case our implementation must not go into error state. If there is another way of testing this we could switch.

[andig]

@lorenzodonini do you have any other idea how we could test this case without adding more api?

[lorenzodonini]

@andig Not a quick one. I merged this for the time being, but I might be changing it in the future to provide a cleaner way to achieving what you want. Will give you the heads up when that happens

[andig]

Much appreciated, thank you 🙏