How to configure WebSphere Liberty v17.x logging feature in order to see in the traces or logs the payload sent and received from a JAX-RS v2.0 call from WebSphere Liberty?
We tried many things including configuring the logging feature like this:
<logging traceSpecification="*=info
:com.ibm.websphere.jaxrs20.=all \
:com.ibm.ws.jaxrs20.=all \
:org.apache.cxf.*=all "/>
but we are still not able to see the payload send and received from JAX-RS calls.
We see lots of internal traces from WAS but no payload/body is visible
The payload/body is usually in JSon marshalled from CXF and jackson, the JAX_RS implementation bundled with liberty.
The Java mapping is done via JAXB annotations in java
Related
My ActiveMQ messaging instance (ActiveMQ 5.16.2 on Amazon MQ) uses STOMP. I cannot use the JMS QueueBrowser, and there is no way to "unack" a message. As soon as there is a consumer that pulled that message from the queue i.e. marked as "unconsumed" as stated in the docs here.
Assuming the broker cannot be changed, I was looking at the REST API mapping of JMS here, but I do not see any endpoint that mimic the ActiveMQ admin pages (JSP), that is capable to browse the queue, consumers and message content without actively "pulling" those messages from the queue.
So, how to implement that JMS logic we can see in the ActiveMQ admin pages programmatically (e.g. via REST apis)?
Looking at the docs of REST API, assumed having the logon, this approach works
curl -XGET https://user:pass#server:8162/admin/browse.jsp?JMSDestination=ActiveMQ.DLQ
and it grab the JSP page output as on the web console, so I assume that it could be done via some "official" rest API.
NOTE. The ActiveMQ JSP page is not using any AJAX call, so I assume it is using the JMS Java API directly.
The REST/JMS mapping doesn't offer any message browsing functionality.
However, it's worth noting that the REST/JMS mapping is independent of the management functionality exposed by Jolokia. Jolokia is an HTTP-JMX bridge so anything exposed via JMX can be accessed via HTTP (e.g. using curl). The DestinationViewMBean has various "browse" methods you can use, e.g.:
$ curl -XGET -u admin:admin -H "Origin: http://localhost" http://localhost:8161/api/jolokia/exec/org.apache.activemq:type=Broker,brokerName=localhost,destinationType=Queue,destinationName=TEST/browse\(\)
Where TEST is the name of your queue.
You can get a list of JMX objects using the search command, e.g.:
$ curl -XGET -u admin:admin -H "Origin: http://localhost" http://localhost:8161/api/jolokia/search/org.apache.activemq:*
You can read more about the Jolokia Protocol on their website.
When should we use API Proxy against API AutoDiscovery. After implementing both, I found AutoDiscovery can also apply policies, analytics which API Gateway does, only thing is I cannot use a different url if using AutoDiscovery. Main advantage of API Proxy would be if my Gateway application and Mule Implementation Project is in different subnet, so if we are my Gateway server is compromised, no one can get to my implementation network.
But if both interface and implementation is in the same network, and purpose is just to call a REST Endpoint, should we not go with API AutoDiscovery.
Problems with Mule API Gateway Proxy
No defined way of Exception Handling, if we are not able to reach the Implementation Server.
No defined way of moving the Proxy Application across environments (CI/CD)
Extra HTTP Hops, can be acceptable if the above 2 issues have a defined way
Mule API AutoDiscovery
Since this is in the Mule Application, standard Exception Handling.
CI/CD is defined as it is the Mule Implementation Project.
No Extra HTTP Hop.
Only thing here is, we cannot change the implementation URL, that is only tightly coupled thing.
Can someone provide insight on when should we go for API Gateway vs AutoDiscovery. Also currently is there a way of doing Exception Handling in API Gateway Project and also CI / CD ?
API Autodiscovery is required if you plan to apply/unapply a policy to a particular endpoint, and/or take advantage of usage statistics in the context of API Platform. Api Autodiscovery is kind of metadata that links a HTTP(s) listener to its counterpart API version on API Manager.
For example:
<api-platform-gw:api id="api.basic.path" apiName="My API" version="1.0.0" flowRef="basic.path">
</api-platform-gw:api>
<flow name="basic.path">
<http:listener config-ref="a.http.config" />
<set-payload value="Endpoint successfully called." />
</flow>
Autogenerated Mule Proxies do have autodiscovery defined. You can also develop your own project and define the corresponding autodiscovery either by using the Studio UI, or handling the XML config directly.
The proxies are mean to be used in the case that your implementation backend is not a Mule application (for example, an existing REST based API hosted in a Tomcat server). You can enrich the logic with custom exception handling among other things on the Mule side. If you'd like better exception handling on the implementation backend, you will have to implement it there.
If your implementation backend is a Mule based application, using a proxy is not required. For most use cases, adding the corresponding autodiscovery element in the configuration file will do the trick.
I am using IBM JAX-RS implementation to develop my REST APIs. I am looking to include validation of resource method parameters using Bean Validation (annotations) support provided in JAX-RS 2.0. I know that Jersey implementation supports this feature (https://jersey.java.net/documentation/latest/bean-validation.html). Is there a similar support available with IBM JAX-RS implementation on WAS 8.5.5? If so could you please direct me to some tutorial on how to accomplish this?
I am specifically looking into enabling and configuring Bean Validation support along with its integration with IBM JAX-RS.
Yes, WebSphere (both traditional and Liberty) will support bean validation with JAX-RS. But I am not aware of any tutorials. The code in the Jersey document that you referenced will work with WebSphere's JAX-RS/BV implementation.
To enable JAX-RS and Bean Validation in Liberty, your server.xml must contain the following features:
<featureManager>
<feature>jaxrs-2.0</feature>
<feature>beanValidation-1.1</feature>
</featureManager>
As an alternative, you could include some feature that includes those features (like webProfile-7.0 or javaee-7.0, but that may get you more function than you want).
Then, if you have your application packaged as an EAR or WAR file, you can copy it into your server's dropins directory, start the server and you should be able to run the example (the default HTTP port is 9080).
This link provides additional information about developing and deploying JAX-RS applications in WebSphere Liberty:
http://www.ibm.com/support/knowledgecenter/was_beta_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_dep_jaxrs.html
Hope this helps,
Andy
I want to use swagger for documenting our RESTful APIs. Our Jersey classes will be consumed from the mule flow. To use swagger for documenting my API I need to use the servlet configuration as mentioned in here - https://github.com/wordnik/swagger-core/wiki/Java-JAXRS-Quickstart
As the Jersey classes are deployed in mule, there is no web.XML.
If you know how to configure swagger with Mule please let me know how to do that. I truly appreciate your feedback and suggestions.
I see two possible options, the latter being the one with the highest chance of success:
Run a Servlet container inside Mule, as demonstrated by the bookstore example provided with the standalone distribution, configuring web.xml as indicated and making sure you're using servlet not http inbound endpoints in your Mule configuration.
Generate at build time a static Swagger configuration using https://github.com/ryankennedy/swagger-jaxrs-doclet and serve it using the static resource message processor from the HTTP transport.
I'm using WCF services in the client application for transfering data from client to server and vice-versa. I'm looking for a mechanism to log the data sent to server into the log file on client machine. I looked into the WCF library but could not find any code which serializes the WCF requests. Logging no issues, I use N-Log for that but I don't find any built in function which gives the webrequest data.
My question is, is there any built in support for getting the webrequest details?
The built in option is called Message logging but this option uses its own way to log messages using standard .NET trace listeners.
If you want custom message logger you have to implement your own logging endpoint behavior with IClientMessageInspector.