Is there anywhere a working (runnable) example of implementation of Camel servlet endpoint with "no-xml" approach? Working unit test with http-client wold also be great. To me, the set up seems too "complicated" being not familiar with servlet configurations. Examples I can find use mostly XML-only approach.
I'm using Camel on top of Spring Boot.
Its covered in the Camel in Action 2nd edition book, where there is a camel-servlet example in the microservices chapter 7.
https://www.manning.com/books/camel-in-action-second-edition
The example comes as part of a bigger use-case but its the rating service: https://github.com/camelinaction/camelinaction2/tree/master/chapter7/prototype/rating
Related
Is there over there a lot of examples about how to create "reactive" services using spring, or whichever microprofile implementation (quarkus, kuuluzee).
According to Servlet 3.1, whichever servlet can be handled as "non-blocking".
I figure out that is mandatory to perform this servlet into a non-blocking servlet container like netty...
First question:
Is it really as I writing? Do I need a non-blocking servlet container implementation in order to make really "reactive" services?
Second question:
It's not clear to me about how to create a basic raw "non-blocking" servlet. I mean, which would be the difference between a "normal" extending servlet from HttpServlet? How would this implementation look like?
Any references?
I'm including Spring Cloud Sleuth + Zipkin 2.2.7 in my Spring Boot application, and am using injected RestTemplates so that calls to them are instrumented and sent to zipkin.
My zipkin spans arising from RestTemplate calls contain tags for http.method and http.path, but no other HTTP info.
Is there any way to surface query parameters in tags? Sometimes there is interesting information in them that would be really useful to surface in a tag (e.g. GET /foo?includeSuperSensitiveData=true).
Let me try to explain what is going on under the hood:
TraceRestTemplateBeanPostProcessor modifies all the RestTemplate beans. As you can see there, it injects a LazyTracingClientHttpRequestInterceptor that is using a brave.spring.web.TracingClientHttpRequestInterceptor to instrument the http calls. So this is done by Brave, not Sleuth.
You might be able to extend TracingClientHttpRequestInterceptor, add the details you need to your implementation and create a bean (you might need to disable the config class that creates it if there is no #ConditionalOnMissingBean).
I am trying to adopt Pact. I understand the consumer side of the equation and it looks very nice. But I am confused about the producer side.
It seems the documentation advocate running the provider app, and verifying the contracts against a running server.
I prefer not to do it. First, I need to curate a database with proper information for each pact, which is painful to say the least. Second, starting up the application is going to be a hassle - did I mention it is a monolith? -, finally, there are POSTS which are going to mutate the state of the database, and make test running brittle.
What I want to do is to do a mockMvc style testing with the pacts. I would like to mock my services, and just test the endpoint, which I think what should be tested in this case.
How can I achieve this with Pact?
Well if you don't test your contracts against your Provider that loses the whole point of Contract testing, since your contracts aren't tested against both sides. Because the main point is that Consumers dictate how the Provider should behave and in your case you would like to bypass the provider with a mockMvc and there is no point for doing contract testing only against your Consumer not the Provider. Even though your Provider is a monolith it's still better to run it and test with a contract, then to run all the microservices for end-to-end testing.
Yes you can achieve it with PACT, however I have the same opinion with Cotnic that it beats the purpose of having PACT on provider side. The main purpose of PACT is to verify that your server as the provider is working as according to the agreement (PACT). Therefore in my opinion the proper way to use PACT as a CONTRACT is by running it against a fully deployed server, and using #State to "Prepare" the Server (db, startup applications, etc)
Anyway, if you are using Spring, you probably can have a look at this sample for using Pact with MockMvc
https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-provider-spring
Pact-JVM now supports Spring mockmvc tests to verify a Spring or Springboot provider. See https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-provider-spring
I want to start using the framework Pact for JVM for contract testing. But does Pact JVM support REST and JMS?
I haven't found any information about this.
Yes, Pact JVM supports REST[1], its primary use case, and also supports JMS testing in the form of Messages [2].
Note that as of this moment, the other language implementations don't support this Message style test, but the work is in progress to make it happen.
[1] Assuming REST = JSON/HTTP
[2] https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-consumer-junit#consumer-test-for-a-message-consumer
Pact is a restful consumer/provider testing tool only; It has to communicate over HTTP and the data contract can only be in JSON at the moment (this could change in the future). We have talked about supporting other protocols like messaging (websockets), but there isn't much need for it as of yet and we have other priorities to work on currently.
I understand that a servlet is an actual class in Java that basically extends and provides useful characteristics of a web server, but are there any alternative equivalents where the same similar key characteristics of a servlet are accomplished in a different language?
Particularly something that has:
the servlet life cycle of init(), service() and remove()
limitations on disk access (persistence)
performing page layout function
can be dynamically reloaded
can call other servlets
can operate like a URL
similar security
I have found servlets in AJAX, Spring and the like, but I mean something that is not in the java family at all. To specify further, I found the following but they don't seem to be used very much, both run over Java, and Armed Bear C-Lisp seems still employs a java virtual machine.
node-servlet
armed bear common lisp
There are quite a number of servlet alternative since servlet is just an implementation of HTTP request and response mechanism based on Java.
Almost all languages has a mechanism to deal with HTTP methods. They just not called 'servlet'. For example node.js has great tools for this. Have a look at express.js which is arguable most used node.js framework.
Make a google search like this: "x rest server" and use whatever language you want instead of 'x', you will most likely get what you asked for. Let's try it for a couple of languages:
ruby rest server : sinatra, grape
swift rest server : kitura, perfect, vapor
c# rest server : web api, servicestack
javascript rest server : node.js, express.js, hapi.js
phyton rest server : django, flash