How do I enable soap tracing on Liberty(19.0.0.1) that is running on IBMi (v7r2)?
I've tried adding
*=info: com.ibm.ws.websvcs.trace.*=all via HTTP admin, but no trace of any SOAP messages is found.
EDIT:
HTTP Admin (IBM Web Administrator for i) > Server Properties > Server Tracing
Yes, I've added the asterisks but I'm new here and formatting kinda crooked it :)
So there a few different ways to configure trace on Liberty, but I find adding the element to the server.xml is easiest (like one of the comments suggested). This element with the JAX-WS trace enabled on Liberty is:
<logging traceSpecification="com.ibm.ws.jaxws.*=all:org.apache.cxf.*=all"/>
This will print out lots of trace, but you can search for the SOAP Messages in the log files by searching for either/both:
Inbound Message (The Request)
Outbound Message (The Response)
The logged request/response contents will include the SOAP Message.
For more info on configuring trace on Liberty check out:
https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_logging.html
Ok, thank you very much for help.
I used Merged Trace with org.apache.cxf.*=all:com.ibm.ws.jaxws.*=all
and that worked just fine.
Related
I have a web application running on Wildfly 26 that uses SSE broadcasting and works correctly with http. However, when I switch to using an https endpoint, I get Wildfly log entries of:
WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1)
RESTEASY002186: Failed to set servlet request into asynchronous mode,
server sent events may not work
This happens with each registration attempt of the https endpoint but I never see this when registering with the http endpoint.
Testing with curl against the http endpoint results in curl waiting for events to show up (and keeps printing them out as it receives them) until I quit. Using curl to test the https endpoint, I will see the same headers I got from the http endpoint, namely:
HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: text/event-stream
But after printing out my registration successful event, curl seems to believe the stream is closed and exits -- giving me my command prompt back.
My #GET MediaType.SERVER_SENT_EVENTS registration endpoint will create an OutboundSseEvent and send it to the SseEventSink to acknowledge successful registration to my SseBroadcaster instance (this is the event curl sees and prints before exiting). I then log a registration successful message before exiting the method. All of this appears to work correctly for both http and https but the stream doesn't stay open once the request endpoint completes because of the failure to run asynchronously as outlined above.
I have not found information on the causes and/or workaround solutions for my RESTEASY002186 problem. I posted a question on this issue last week using the Wildfly Google Group (https://groups.google.com/g/wildfly/c/SO2eHdvMEko) but thought I would try a wider audience since this doesn't seem to be a commonly experienced condition. I don't see any indications during initialization that WildFly will be unable to use asynchronous mode, it just complains when it tries and fails... Any help would be greatly appreciated!
Edit 6/6/2022
The code is running on an isolated network so I can't just cut/paste the code here, but I gutted the resources file to a bare minimum -- just leaving enough for the client to be able to register. The problem remains unchanged. The code is now essentially:
#Path("sse")
public class SseResources {
#GET
#Produces(MediaType.SERVER_SENT_EVENTS)
public void listen(#Context Sse sse, #Context SseEventSink sseEventSink) {
SseRegComplete regComplete = new SseRegComplete("sse-server");
OutboundSseEvent event = sse.newEventBuilder().
name(regComplete.getType().toString()).
id(regComplete.getEventId()).
mediaType(MediaType.APPLICATION_JSON_TYPE).
data(SseRegComplete.class, regComplete).
comment("Event Stream Registration Completed Successfully").
build();
sseEventSink.send(event);
}
}
Before the above simplified code, I had declared the resource as #ApplicationScoped, had Sse injected into it, and kept a reference to the SseBroadcaster so I could use it whenever an event would come in. I was catching the events to broadcast by using an #Observes method (which I also got rid of). I was calling register(sseEventSink) on the SseBroadcaster in the listen method so I could later call broadcast(outboundEvent) whenever I had updates to publish. I got rid of all that just to see if I could get the stream to stay open but to no avail. I still get the RESTEASY002186 message and curl still exits after printing out the regComplete event sent to it in the code above.
Edit 6/7/2022
Yesterday I was able to get my code working in a new vanilla Wildfly 26 install using an https endpoint URL by following these configuration instructions. Something I hadn't mentioned in the original post is that I am trying to add SSE functionality to an already existing app. It is several years old and we actually moved to Wildfly 26 about 6 months ago because of the log4j vulnerability in the earlier version of Wildfly we were using. I suspect that the problem is related to either our Wildfly configuration (perhaps because old settings were brought over that shouldn't have been) or some 3rd party dependency that is preventing Wildfly from using asynchronous mode.
We are using Shiro for authentication and authorization against an LDAP server -- perhaps Shiro has some hooks into the Wildfly runtime that are causing issues? After initial login, we use a session cookie in all subsequent calls. That is a difference from my test server but I don't think it is relevant because the call definitely passed authentication before executing the registration code. The only other thing that comes to mind right now is our web app ships with LogBack and tells Wildfly not to use the default logging framework.
I plan to start today by comparing the two standalone.xml files to see if anything jumps out at me as being fundamentally different. Is there anything else I should be checking for differences (I think there is a domain.xml file somewhere...)?
Edit 6/14/2022
This definitely has something to do with Shiro being in the loop. When I edit the web.xml file to have Shiro's filter-mapping url-pattern to not include the SSE endpoint, everything works as expected.
We have an api deployed on Azure that uses Google authentication. Over the weekend, the API started to throw 500 errors that were resolved after restarting the API. Is there a way to identify what the underlying cause for these errors might be?
Check if you have custom error mode in web.config file to “on” or “Remoteonly”. If
yes then turn it off. Add the following line to System.web element in web.config
Enable custom logging/instrumentation in the code which can help you in more
information.
ASP.NET applications can use the System.Diagnostics.Trace class to log information to
the application diagnostics log. For example
System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");
Enable Detailed Error Messages - Detailed version of the html files produced when
your website responds with an error message. This is good to enable for debugging
some error responses in your website. It is stored in the website's file system.
Web Server Logging - Also known as HTTP logs or IIS logs, this will log all requests
to your website in W3C Extended Log File Format.
Failed Request Tracing - Also known as FREB, here you can get lots of information
from IIS through its different stacks for each failing request.
We are using WSO2 Carbon 4.2.0 through the WSO2 Application Server (AS) package. In replacing an older, highly customized Carbon installation (provided by a company that no longer supports the product, has abandoned it and refuses to work on it, and left us no details on how/what they modified in Carbon), we have deployed a couple web applications in the webapps container as they were deployed before in the older instance. We have changed our WebContextRoot in the carbon.xml from the default "/" to a sub-URL of ex: "/stuff", as is also detailed in the self-answered SO question here. However the answer given there is not detailed in what the OP actually encountered when he modified his WSO2 instance.
In testing the above configuration we noticed that if a user were to go to a non-existent web address on the server, depending on the format of the URL they are either:
redirected to a blank page;
receive a "500 Internal server error" (I suspect this is the embedded Tomcat?);
get sent to the Carbon login page (which we definitely do not want to happen for security reasons); or
get an XML document stating:
<faultString> The service cannot be found for the endpoint reference (EPR) /stuff/services/nonexistantservicename </faultString>
At least in the case of missing content we wish the user to be sent to a standardized 404 error page, or at the least be sent an HTTP 404 error by the server. For services the XML error is palatable, we can deal with that.
The only option for us right now to circumvent this issue is to place a proxy in front of the WSO2 instance, which would be another layer to manage and tune, and possibly degrade performance. Please know that I am not a programmer but just an admin with DevOps experience. I would not know how to handle this with e.g. a Java solution or re-coding parts of WSO2. Customizing the core product would also hamper future upgrades of WSO2, a scenario we are trying to dig ourselves out of now as detailed above. Is there no internal WSO2 mechanism to handle non-existent content? Can we not redirect any errors to a standard canned response page?
I have an EAR deployed on WAS 7.0.0.3 server and the web service also deployed.
MQ listener is up and running in my WAS server and corresponding MQ host, channel name and MQ queue name are configured correctly. It is the response queue.
Whenever I'm getting data from MQ, I'm getting the below error in SystemOut.log
error
"MQJCA4004: Message delivery to an MDB 'null' failed with exception:
'deactivate of endpoint is in progress.' "
Please help me on this.
I've managed to further analyze similar MQJCA4004 error using this, kinda hackish, technique.
You need a Java decompiler that preserves line numbers.
JadClipse plugin for Eclipse can do that. Just make sure you have enabled:
Debug Settings
[x] Align code for debugging
in Window > Preferences > Java > Decompiler.
The standard Intellij Idea Community decompiler has that feature already enabled.
The IBM class responsible for producing the MQJCA4004 error is
com.ibm.mq.connector.inbound.AbstractWorkImpl
When you open it (with decompilation enabled) you'll be able to find the string MQJCA4004. Place a breakpoint there and start remote debugging your application server. When you hit that breakpoint, you'll gain access to all the context information including the exception (with call stack) that's causing this error.
I'm using Websphere 7. Using existing WSDL, I've created WS client using wsimport ant task (com.sun.tools.ws.ant.WsImport).
Is there a way I can log SOAP xml requests/responses sent/received by this client?
Trace for SOAP WS messages can be enabled by following these steps on Websphere 7 administration console:
Go to administration console
Go to: Servers -> WebSphere application servers -> server > Change Log Detail Levels
In the package tree find the package com.ibm.ws.websvcs.trace, click on package name and choose 'All Mesasges and Traces', as result you should have log details set as below:
*=info: com.ibm.ws.websvcs.trace.*=all
Click on 'OK' and then Save the changes.
SOAP request/responses can now be found in trace.log on your appl. server.
For WebSphere Liberty Profile, logging of JAX-WS SOAP request and response messages can be enabled by adding the following trace configuration to the server.xml:
<logging traceFormat="BASIC" consoleLogLevel="INFO" traceSpecification="com.ibm.ws.jaxws.wsat.*=debug" traceFileName="stdout" />
Adding the traceFileName="stdout" attribute redirects the trace output to the console. Without this attribute it will write to the trace log file instead.