PAYARA-3729 EJB HTTP Endpoint improvments #3926
Conversation
|
jenkins test please |
|
jenkins test please |
| .getMethod(requestPayload.getString("method"), argTypes) | ||
| .invoke(bean, argValues); | ||
|
|
||
| Object result = invokeBeanMethod(beanName, methodName, argTypes, argValues, principal, credentials); | ||
| response.setContentType(APPLICATION_JSON); | ||
| response.getWriter().print(result instanceof String? result : JsonbBuilder.create().toJson(result)); |
There was a problem hiding this comment.
Well if the protocol is like that, and Strings works in current client, then we should use text/plain in this case. Because as application/json the String needs to be quoted
There was a problem hiding this comment.
I does work indeed but you are correct. I wonder why it was done this way originally. Maybe we can just use JSON in any case.
There was a problem hiding this comment.
I changed this so it always sends JSON which also works.
| logger.log(Level.WARNING, "EJB bean method invocation failed.", ex); | ||
| response.sendError(SC_INTERNAL_SERVER_ERROR, | ||
| "Error while invoking invoking method " + methodName + " on EJB with name " + beanName + ": " | ||
| + ex.getMessage()); |
There was a problem hiding this comment.
And error handling in client is likely next topic to look at.
There was a problem hiding this comment.
Yes, one I know and find irritating is that the client does not detect that the endpoint isn't enabled. That said @arjantijms reminded me that for security reasons we have to be careful how much information we do expose to the user.
| boolean success = excuteInAppContext(() -> { | ||
| } else { | ||
| String methodName = requestPayload.getString("method"); | ||
| Class<?>[] argTypes = toClasses(requestPayload.getJsonArray("argTypes")); |
There was a problem hiding this comment.
I believe you need to use app classloader for that (but I can take care of it as part of "Full JSON-B support" issue)
There was a problem hiding this comment.
Good catch. As this could break something I think this PR should not introduce a new problem.
There was a problem hiding this comment.
Since it used plain Class.forName before, it will not be a new problem :)
There was a problem hiding this comment.
It did but it did so within excuteInAppContext I think which does set the app classloader as context classloader which should address this if I am not mistaken. Therefore I moved that into the lambda and thereby into the right context again.
There was a problem hiding this comment.
No, you I think you need to use Class.forName(className, true, contextClassLoader)
There was a problem hiding this comment.
Somehow I was thinking the context classloader would be involved in Class.forName(String). Changed it to use the context classloader. It should be more correct this way. Tested it as well and used the change to test redeploying the invoker app using the admin console which also works (as long as one sets the correct name/context root).
| protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { | ||
| JsonObject requestPayload = readJsonObject(request.getReader()); |
There was a problem hiding this comment.
Another error case would be malformed Json
There was a problem hiding this comment.
I did not address this since the caller usually is our client which we should make sure does not use malformed JSON. While being a possible problem it does not seemed so important to handle to me.
…ssloader to create classes and objects
|
jenkins test please |
While testing #3925 I looked into several kinds of errors. Some where user errors due to limitations I wasn't aware of. This PR contains the improvements I made to understand the errors I dealt with.
getClass().getInterfaces()but make use of the EJB bean name in case it does contain the interface nameIgnore the changes to the pom as those are part of #3925. This PR just branched from that branch as I did both at the same time.
Test app can be found here https://github.com/payara/payara-samples/pull/8