OpenDaylight JIRA

OpenDaylight JIRA https://jira.opendaylight.org This file is an XML representation of an issue en-us

8.20.10

820010

22-06-2022

[CONTROLLER-280] JAX-RS applications should use whiteboard pattern instead of WAB https://jira.opendaylight.org/browse/CONTROLLER-280 controller Operating System: All Platform: All CONTROLLER-280

JAX-RS applications should use whiteboard pattern instead of WAB

Improvement Resolved Won't Do Tomas Olvecky Tomas Olvecky Mon, 7 Apr 2014 12:21:34 +0000 Tue, 25 Jul 2023 08:23:24 +0000 Tue, 22 Apr 2014 12:03:20 +0000 config 0 2 Tomas, The WAB specification uses the whiteboard pattern internally. In fact all the WAB modules register a service of type javax.servlet. So what is exactly this enhancement for? Thanks, Giovanni WAB imposes additional requirements on underlying infrastructure, namely a fully compliant servlet container. For things like restconf we want to experiment with switching to netty for performance reasons. This should be significantly easier if we don't implement whole servlet specification. WAB also exposes too much information that should be configurable, e.g. CORS filter settings that might be dependent on distribution. Third reason is that WAB does not work well with dynamic nature of services: programmer of each WAB needs to: 1.specify context under which web app will be available (and we have a use case with multiple md-sals in system) 2.provide a custom error handling if request comes before dependent services are initialized (might not be an issue, but with 'SR whiteboard' pattern this can be avoided by registering only after dependencies are resolved.) Of course I am open to discussion and I am not about to switch all JAX-RS apps now, just restconf. Tomas I failed to explain that I want to register javax.ws.rs.core.Application service in restconf's Activator (In reply to Tomas Olvecky from comment #3) > I failed to explain that I want to register javax.ws.rs.core.Application > service in restconf's Activator Thanks, i was commenting exactly asking this one. That sounds reasonable, but be aware that if you do this way and define JAXB annotation on inherited classes the JAXB context calculated by JAXRS may not consider all the subclasses, for that one we made a specific enhancement in the controller implemented by the bundlescanner and bundlescanner.implementation. Just FYI. Not sure what is your use case but be aware of it. (In reply to Tomas Olvecky from comment #2) > WAB imposes additional requirements on underlying infrastructure, namely a > fully compliant servlet container. For things like restconf we want to > experiment with switching to netty for performance reasons. This should be > significantly easier if we don't implement whole servlet specification. > WAB also exposes too much information that should be configurable, e.g. CORS > filter settings that might be dependent on distribution. > Third reason is that WAB does not work well with dynamic nature of services: > programmer of each WAB needs to: This is not true, you can register and unregister WAB dynamically you can try it with existing northbounds modules. > 1.specify context under which web app will be available (and we have a use > case with multiple md-sals in system) This can be relocated depending on the servlet container used. > 2.provide a custom error handling if request comes before dependent services > are initialized (might not be an issue, but with 'SR whiteboard' pattern > this can be avoided by registering only after dependencies are resolved.) > Of course I am open to discussion and I am not about to switch all JAX-RS > apps now, just restconf. As long as it's restconf i'm fine. Thanks, Giovanni > Tomas Thanks for response, (In reply to Giovanni Meo from comment #4) > (In reply to Tomas Olvecky from comment #3) > > I failed to explain that I want to register javax.ws.rs.core.Application > > service in restconf's Activator > > Thanks, i was commenting exactly asking this one. That sounds reasonable, > but be aware that if you do this way and define JAXB annotation on inherited > classes the JAXB context calculated by JAXRS may not consider all the > subclasses, for that one we made a specific enhancement in the controller > implemented by the bundlescanner and bundlescanner.implementation. Just FYI. > Not sure what is your use case but be aware of it. > > (In reply to Tomas Olvecky from comment #2) > > WAB imposes additional requirements on underlying infrastructure, namely a > > fully compliant servlet container. For things like restconf we want to > > experiment with switching to netty for performance reasons. This should be > > significantly easier if we don't implement whole servlet specification. > > WAB also exposes too much information that should be configurable, e.g. CORS > > filter settings that might be dependent on distribution. > > Third reason is that WAB does not work well with dynamic nature of services: > > programmer of each WAB needs to: > > This is not true, you can register and unregister WAB dynamically you can > try it with existing northbounds modules. Not really, it is bound with bundle lifecycle, which services are not. > > > 1.specify context under which web app will be available (and we have a use > > case with multiple md-sals in system) > > This can be relocated depending on the servlet container used. > > > 2.provide a custom error handling if request comes before dependent services > > are initialized (might not be an issue, but with 'SR whiteboard' pattern > > this can be avoided by registering only after dependencies are resolved.) > > Of course I am open to discussion and I am not about to switch all JAX-RS > > apps now, just restconf. > > As long as it's restconf i'm fine. > > Thanks, > Giovanni > > > Tomas I have decided to wontwix it now, it is mainly a research that would allow optimizing away servlet container and using netty for JAX-RS directly. This turns out to be more complicated as I imagined and is not a priority for now. Blocks CONTROLLER-289 Development External issue ID 674 External issue URL Priority Rank 0|i02jfb: