XWiki never really fully worked in a portlet. We have a xwiki-platform-container-portlet module, and we worked a very long time ago with @mflorea on a special branch of XWiki with a lot of hacks to make it more or less work in a portlet, but it never really became standard.
I don’t see any point keeping xwiki-platform-container-portlet (based on the 20 years old Portlet 1.0 specification) so I would like to propose to move it to the attic starting with 17.0.0, to not have this very misleading module in the standard source tree anymore.
For the history part, this was because in the early days of XWiki, there was a working integration of XWiki to make it work when embedded inside Exo Platform (which was running as a Portlet). So when we introduced the container module we took into account the Portlet container. Actually this Portlet use case was one of the main motivator to introduce a container abstraction level, so that XWiki could run inside various containers.
The next question is whether we continue to see the need to abstract the Servlet container or not. We have lots of places where this abstraction is not working and we use code like if (request instanceof ServletRequest) ... ((ServletRequest) request).....
Note that one other pro of having a Portlet container module was to verify that we couldn’t add a new Container API that wouldn’t be implementable in the Portlet container. We’ll loose it if we move to the attic.
So my question are:
Is there any need to keep a container abstraction?
How do we ensure that the container abstraction can work for various containers and which container do we want to support?
I doubt it worked for long, and probably with some customization on Exo Platform side. XWiki is not working in a portlet since at least 12 years.
I’m in charge of moving things to jakarta. The last Portlet specification was released in 2017, so there is no jakarta portlet and I don’t think there will ever be any.
We are not verifying this. Verifying this would mean checking if XWiki works in a portlet, and the answer is easy: it’s not.
I was referring to API verification. I know it’s not as best as a functional tests but at least you cannot compile if you add a new API and you don’t implement it in the portlet module. Ofc you can simply have some empty method or throw an exception but at least that will make you think about how it could be implemented…
Anyway the big questions for me are:
If the answer to 1 is yes (I’d like to understand the reasoning) then dropping portlet is fine with me. And for 1 to be yes, I think we need 2 to list more than 1 container (note that the “standalone” container is not a real container, it’s for tests).
If the answer to 1 is no, then we should drop not just the portlet container but the whole container concept.
