Recently, I was experimenting with Krazo 3.0.1 on Jakarta EE 10, using OpenLiberty 22.0.0.13-beta. I stumbled upon the same error message as reported in #282. I thought it had been resolved with #288, so I checked if the LibertyHttpCommunicationUnwrapper got invoked - it did.
So I dug a little further to find the ServletUtil#unwrapRequest method of OpenLiberty. As pointed out by @jesse-gallagher in #282, Liberty expects to be able to get an instance of their IExtendedRequest type from the passed-in request object. The passed-in request object (supplied by Krazo) is a HttpServletRequestWrapper instance backed by a Weld proxy for an SRTServletRequest60 instance. The unwrapRequest method doesn't handle this object properly, and hence throws the "SRV.8.2: RequestWrapper objects must extend ServletRequestWrapper or HttpServletRequestWrapper".
(Aside) the SRTServletRequest60 does in fact implement the IExtendedRequest interface. I think the isInstance() check in Liberty fails due to the Weld proxy around it. I've logged an issue for that: OpenLiberty/open-liberty#23774.
Anyway, when Krazo invokes RequestDispatcher#forward from ServletViewEngine#forwardRequest(), it passes a HttpServletRequestWrapper instance that wraps "the original request". That "original request" comes from the ViewEngineContext, which was constructed by the ViewableWriter. The ViewableWriter in turn gets it @Inject-ed, which explains the Weld proxy.
In my own experiment, I could work around this by implementing a WeldHttpCommunicationUnwrapper, which works pretty much the same as the existing LibertyHttpCommunicationUnwrapper. Using reflection, it checks if the request implements WeldClientProxy. If so, it invokes WeldClientProxy#getMetadata() and then WeldClientProxy.Metadata#getContextualInstance() to get the actual SRTServletRequest60 instance.
Would you be interested in having this in Krazo's code base?
Recently, I was experimenting with Krazo 3.0.1 on Jakarta EE 10, using OpenLiberty 22.0.0.13-beta. I stumbled upon the same error message as reported in #282. I thought it had been resolved with #288, so I checked if the
LibertyHttpCommunicationUnwrappergot invoked - it did.So I dug a little further to find the
ServletUtil#unwrapRequestmethod of OpenLiberty. As pointed out by @jesse-gallagher in #282, Liberty expects to be able to get an instance of theirIExtendedRequesttype from the passed-in request object. The passed-in request object (supplied by Krazo) is aHttpServletRequestWrapperinstance backed by a Weld proxy for anSRTServletRequest60instance. TheunwrapRequestmethod doesn't handle this object properly, and hence throws the "SRV.8.2: RequestWrapper objects must extend ServletRequestWrapper or HttpServletRequestWrapper".(Aside) the
SRTServletRequest60does in fact implement theIExtendedRequestinterface. I think theisInstance()check in Liberty fails due to the Weld proxy around it. I've logged an issue for that: OpenLiberty/open-liberty#23774.Anyway, when Krazo invokes
RequestDispatcher#forwardfromServletViewEngine#forwardRequest(), it passes aHttpServletRequestWrapperinstance that wraps "the original request". That "original request" comes from theViewEngineContext, which was constructed by theViewableWriter. TheViewableWriterin turn gets it@Inject-ed, which explains the Weld proxy.In my own experiment, I could work around this by implementing a
WeldHttpCommunicationUnwrapper, which works pretty much the same as the existingLibertyHttpCommunicationUnwrapper. Using reflection, it checks if the request implementsWeldClientProxy. If so, it invokesWeldClientProxy#getMetadata()and thenWeldClientProxy.Metadata#getContextualInstance()to get the actualSRTServletRequest60instance.Would you be interested in having this in Krazo's code base?