How to add CoAP resources to CoapServer now that CoapAPI is gone

[niklas-sparfeld-gcx]

Question

Hi! 👋

In our Leshan server implementations we added some custom pure CoAP resources to Leshan's underlying CoapServer, by calling into the CoapAPI:

server.coap().server.add(CustomCoapResource())

Our most important use-case is a simple file server. Of course, we could (and maybe should) serve files via a separate CoAP server, but our current approach is light-weight and works well for us.

With 2.0.0-M11 you removed the CoapAPI and I cannot find out how to add custom resources now.

Of course, there's reflection, but...

data class CoapAPI(val server: CoapServer)

fun LeshanServer.coap(): CoapAPI {
    val endpointsProviderField = LeshanServer::class.java.getDeclaredField("endpointsProvider")
    endpointsProviderField.isAccessible = true
    val endpointsProvider = endpointsProviderField.get(this) as CaliforniumServerEndpointsProvider

    val coapServerField = CaliforniumServerEndpointsProvider::class.java.getDeclaredField("coapServer")
    coapServerField.isAccessible = true
    return CoapAPI(coapServerField.get(endpointsProvider) as CoapServer)
}

Is there a better approach that I'm missing?

Thanks 👍

[sbernard31]

Hi,
Yep unfortunately with addition of new Transport Layer Abstraction, we removed the CoAP API.
(See : #1318)

The CoapServer is now encapsulated in CaliforniumServerEndpointsProvider.
I looked at the code and currently the coapServer attribute is private with no getter to access to it... 😞

Is there a better approach that I'm missing?

So for now ... the is no best approach, OR maybe implementing your own LwM2mServerEndpointsProvider inspired by CaliforniumServerEndpointsProvider ?

But I agree that this should be improved. (Transport Layer Abstraction is still an in development feature ...)
So maybe we can try to find together a good way to solve this issue (and so adapt the code)

Is getting access to the CoapServer the only feature you need from old CoapAPI ?

[niklas-sparfeld-gcx]

Is getting access to the CoapServer the only feature you need from old CoapAPI ?

Actually we only need add(Resource... resources) of CoapServer, but I believe that access to CoapServer would be most logical.

We also use the CoAP-level sendRequest(Request), but that's already available on the endpoints, so there's no need for a CoapAPI for that.

In my opinion, simply adding a public getter for CoapServer on the endpoints provider would work. Probably also adding a getter for the endpoints provider on LeshanServer would be convenient 🤔

Alternatively making it protected, but that's more hassle 🤷

[jvermillard]

In my opinion, simply adding a public getter for CoapServer on the endpoints provider would work.

+1
in the meantime, you can try use reflection to access the private field and add your resources

[sbernard31]

Actually we only need add(Resource... resources) of CoapServer, but I believe that access to CoapServer would be most logical.

Agree

We also use the CoAP-level sendRequest(Request), but that's already available on the endpoints, so there's no need for a CoapAPI for that.

The send CoAP API from CoapAPI was a bit more LWM2M oriented than the "pure" Californium endpoint.sendRequest(Request) API.
It was :

• Registration oriented,
• Supporting the Queue Mode, (taking account presence state and update it)
• Automatically configure security information on coap request.
• advanced support of timeout.

(So maybe at some time I should reintroduce it)

In my opinion, simply adding a public getter for CoapServer on the endpoints provider would work. Probably also adding a getter for the endpoints provider on LeshanServer would be convenient 🤔

Yep, I also think something like this could be useful. I need to think about how it could looks like.
Because this is not about just adding a getter on LwM2mServerEndpointsProvider because at short/midterm Transport Layer Abstraction must support several LwM2mServerEndpointsProvider by Server.
So should we access to it ?

• by class ? but we can have several provider with same type.
• by name/id ? so we need to add name/id to providers. (at first thought, this seems to be the more convenient way ?)
• or just a list ? but not so convenient.

[niklas-sparfeld-gcx]

I'd go with a list for now.

• you don't yet know of any use cases beyond "I want to get the single endpoints provider, so that I can manipulate the underlying CoapServer". Without knowing more use cases, I would personally refrain from introducing more complexity than strictly required just by guessing more potential use cases.
• you're on milestone releases anyway, so you are allowed to break the API
• only few people will use this API, so you won't anger many people ;)
• Whoever wants to access by class, can easily do so (e.g. kotlin: filterIsInstance<CaliforniumEndpointsProvider>())

That's just my 2 cents, you might very well know better.

[sbernard31]

I'd go with a list for now

I will probably follow your advice in a first time.

I'm on something else for now, but I will let you know as soon as I move forward on this.
If you want to contribute it providing a PR by yourself, just let me know 🙂

[sbernard31]

I created a small PR about that : #1516

[sbernard31]

@niklas-sparfeld-gcx, let me know if this fits your needs ?

[niklas-sparfeld-gcx]

It does 👍

[sbernard31]

OK 🙂, I integrated OR #1516 in master, so I think we can close this issue.

For "LWM2M oriented send CoAP Request" feature, we will see later, if needed we will create a dedicated issue.