Re: c/68415 add new API for programmatic registration of web Servlet, Filter, etc.


Michael Vorburger <vorburger@...>
 

+aaa-dev FYI:

Robert, and other interested parties in this matter:

On Mon, Feb 26, 2018 at 2:51 PM, Michael Vorburger <vorburger@...> wrote:
On Mon, Feb 26, 2018 at 5:24 AM, Robert Varga <nite@...> wrote:
On 26/02/18 11:18, Michael Vorburger wrote:
> Hello Robert,

Hello Michael,

> thank you for your interest
> on https://git.opendaylight.org/gerrit/#/c/68415/
> <https://git.opendaylight.org/gerrit/#/c/68415/>, the proposed new API
> for programmatic registration of web Servlet, Filter, etc. in infrautils
> to be initially used in neutron
> https://lists.opendaylight.org/pipermail/neutron-dev/2018-February/001587.html
> <https://lists.opendaylight.org/pipermail/neutron-dev/2018-February/001587.html>
> and later in aaa and restconf.
>
> I thought it may be easiest to have a quick discussion on an email
> thread than on Gerrit, so in reply to your -1 review:
>
>> What is the added value when compared to servlet-api?
>> I feel this adds an unnecessary layer of indirection.
>
> So I had actually looked into this whole area quite a bit, and tried a
> bunch of things, but basically I was not able to figure out how to use
> the Servlet 3.0 API to dynamically register Servlet, Filter, etc. at
> run-time in an environment such as OSGi... :-( From what I gathered,
> there are (at least) the following couple of problems:
>
> A. that new dynamic registration stuff in the Servlet 3.x API is very
> much geared towards "on WAR start up" scenerios, but NOT intended for
> "add web components to a running web server". See also
> e.g. https://github.com/eclipse/jetty.project/issues/1395
> <https://github.com/eclipse/jetty.project/issues/1395> where Jetty threw
> me an IllegalStateException when I played with this. And even if one
> were to try to "fix" Jetty, wait for a release, and upgrade (which is
> WAAAY beyond the timeline I wanted to get this done in!), AFAIK we would
> be working around the Servlet Spec, and could hit similar problems again
> if ever someone wanted to run this on something else than Jetty.
>
> B. even if - that ServletContainerInitializer stuff still needs
> something to "bootstrap", to "hook into", from some sort of start-up
> code in OSGi - whether an arbitrary ODL bundle's Activator (bad) or BP
> Bean @PostConstruct (nice) or DS. NB the this JD quote: "Implementations
> of this interface must be declared by a JAR file resource located inside
> the META-INF/services directory and named for the fully qualified class
> name of this interface, and will be discovered using the runtime's
> service provider lookup mechanism or a container specific mechanism that
> is semantically equivalent to it." is... urgh! No. Not in OSGi. Just a
> simple explicit web component registration service API with a very
> narrow surface is really all this needs.
>
> C. the full Servlet API offers a whole lot of other methods which I do
> not see how we would implement in a "bridge" to Karaf's Jetty Web
> server. (Whereas, full disclosure from my side, I actually already have
> the implementation of the API proposed in c/68415; I just want to
> introduce things step by step for easier reviews.)
>
> Long story short.. next step? Perhaps if you have a concrete proposal
> how we can use the servlet-api instead of what I'm proposing on c/68415,
> then please provide more details / show us how to use the Servlet API to
> register a servlet and filter from an OSGi bundle in Karaf ?

It boils down to what ws.rs implementation

I'm assuming you mean JAX-RS here, not https://ws-rs.org ? :-)
 
we choose and how we
integrate with it. There are at least three choices:
- jersey
- CFX
- resteasy

sure - but I'm confused now; jersey/CFX/resteasy has nothing directly to do with the goal of c/68415, which is to replace the web.xml with programmatic registration of web components (incl. e.g. AAA or Cross Origin Filters, apart from JAX-RS) in order to have number of advantages, some of which are documented in the JavaDoc of the new WebServer interface in c/68415: 1. code instead XML, 2. instances instead of classes, 3. possibly standalone instead of OSGi, for testing.

BTW: https://git.opendaylight.org/gerrit/#/c/68767/ is an illustration of how c/68415 can be used. Very nice, no?

When we are talking about OSGi/BP integration, CXF allows for webservice
applications to be declared in BP and it comes pre-packaged with
Karaf... So it's not like we only have jersey as the only choice.

again, interesting; but that's not what I'm after primarily; I'm proposing a simple explicit web component registration service API to replace web.xml for any web components - not just JAX RS webservice applications (Jersey or not).
 
There literally are 11 instances of web.xml within OpenDaylight
codebase, some extremely simple, others involving filters. I do not
believe we rolling our own should be the first choice, but we should
carefully and fully explore the space and find a solution which requires
us to maintain minimum amount of ODL-specific code...

I hereby confirm that I have, to the best of my abilities, explored this space, and concluded that a simple API to register web components as proposed in c/68415 is the suitable solution. The amount of ODL-specific code is relatively small. To avoid any possible misinterpretation of what follow-up change I'll raise after the propose API: The OSGi implementation would be an adapter to PAX Web, in the order of magnitude of likely tens not even hundreds of lines. I'm hoping that this suitably addressed your concern re. maintain minimum amount of ODL-specific code.

What do you propose as next step? Do you have a counter proposal illustrating how to forget about c/68415 and use the Servlet API in c/68767 instead? Or should we chat by voice in tomorrow's Kernel meeting to wrap this up?

as discussed in last week's Kernel meeting, see minutes on https://meetings.opendaylight.org/opendaylight-meeting/2018/kernel_projects/opendaylight-meeting-kernel_projects.2018-02-27-17.01.html, I've now initially proposed this into AAA instead of infrautils, see https://git.opendaylight.org/gerrit/#/q/topic:simple-dist_web, and look forward to agree next steps on this front in today's Kernel call together with everyone interested.

Tx,
M.
--
Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch

Join z.archive.aaa-dev@lists.opendaylight.org to automatically receive all group messages.