Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Krazo does not work with OpenLiberty 22.* beta (Jakarta EE 10) #364

Open
mthmulders opened this issue Dec 29, 2022 · 2 comments
Open

Krazo does not work with OpenLiberty 22.* beta (Jakarta EE 10) #364

mthmulders opened this issue Dec 29, 2022 · 2 comments
Labels
help wanted Extra attention is needed server:liberty Targets OpenLiberty server
Milestone

Comments

@mthmulders
Copy link
Contributor

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?

@erdlet
Copy link
Member

erdlet commented Dec 29, 2022

Hi @mthmulders,

thanks a lot for testing and providing this detailed analysis. It'd be great when you vould provide your solution to Krazo, since we're a little bit short of time at the moment and Liberty makes the most ptoblems

@jesse-gallagher
Copy link
Contributor

I don't have much to add other than: thanks for adding this! I hadn't yet had an occasion to move to JEE 10, but I did today, hit this problem again, built a snapshot build, and it works great once more.

@erdlet erdlet modified the milestones: 3.1.0, 4.0.0 Apr 30, 2023
@ivargrimstad ivargrimstad added the help wanted Extra attention is needed label Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed server:liberty Targets OpenLiberty server
Projects
None yet
Development

No branches or pull requests

4 participants