I have headed into an issue with losing the grpc context while using the reactive rest-client for downstream calls. Im unsure if it is my implementation or a bug related to grpc context. It seems to be similar to: https://github.com/quarkusio/quarkus/issues/13959, but according to comment that should be fixed.
Anyway the grpc context seems to be lost when a call is made downstream with the rest-client. I have setup a reproducer repo: https://github.com/AnteLund/grpc-context-lost-reproducer which has some tests to show the issue.
Any ideas?
It was a bug. It got fixed in Quarkus 2.8 (maybe even 2.7). The context was lost during the REST client call. Now, the context is preserved between the two calls.
Related
I'am currently trying to understand the discovering of JAXRS-Endpoints in Quarkus. My assumption is that they are automatically discovered and there is no need to register them. In addition I tried to import Endpoints from an other module/jar File. It is working to out of the box.
But than I tried to understand the order of discovering endpoints.
I tried to overwrite a jar file provided endpoint in my application, but it is not working. Therfore in my opinion there is a potential security problem, if any third party module can overwrite my endpoints. Has anyone the same problems and can provide me informations how to think about this problem? (My only solution is to write an own extension which removes all endpoints an add only the ones I want to have, but I think this is against the idea)
Thanks in advance!
Duplicate endpoint detection was added to RESTEasy Reactive in https://github.com/quarkusio/quarkus/pull/15037.
This means that from version 2.7.0.CR1 and on, Quarkus will fail the build if duplicate JAX-RS endpoints are defined (assuming you are using quarkus-resteasy-reactive).
The (somewhat) new reactive API to Quarkus is awesome, but it introduces some complexity when writing code (much like in async code in JavaScript in my opinion).
How is it integrating with metrics/tracing/jwt APIs ? or anything that is passed by thread context?
Thnx
The integration is managed for you. Tracing and JWT are handle using context propagation. Metrics works flawlessly. Please report an issue if you see limitations or bugs.
I'm looking at Spring REST Docs and wondering if it has the ability to interrogate #RestController methods to produce basic documentation describing a Rest API (methods, http method, parameters, response type)? I believe Springfox Spring/Swagger does that, and would be easier than having to write a test to get that basic info/documentation.
Also, since I don't want to run integration tests in a Production environment, is the Spring RestDocs approach to run your integration tests in a Test environment and then copy the generated docs/snippets into the war so it can be viewed in a Prod environment?
I'm looking at Spring REST Docs and wondering if it has the ability to interrogate #RestController methods to produce basic documentation describing a Rest API
Spring REST Docs is test-driven and deliberately doesn't take the approach of introspecting #RestController methods. You REST API documentation is describing HTTP requests and responses. By being test-driven and working with real or mocked HTTP requests and responses, REST Docs ensures that what you're documenting is what users of your API will be dealing with.
The problem with introspecting #RestController methods is that it's only one small piece of the puzzle. When an HTTP request is received it passes through filters, interceptors, HTTP message conversion etc before it reaches your controller. The same is true in reverse when a response is being sent. Without a complete understanding of everything that happens before your controller's called and everything that happens after your controller returns, the documentation is at risk of being inaccurate.
is the Spring RestDocs approach to run your integration tests in a Test environment and then copy the generated docs/snippets into the war so it can be viewed in a Prod environment
Correct. The documentation is generated once at build time and then typically served as static files from your application. Details of how to do this with Spring Boot are included in the documentation.
This approach has the advantage that none of the code that's involved in creating the documentation is running in production. That reduces your application's footprint, and avoids the possibility of the code that's generating the documentation from causing a problem in production. I believe you can take a similar approach with code-first Swagger tools but, in my experience, it's unusual for people to do so.
Swagger is best choice for me. You cannot do make docs with Spring Rest Docs without integration tests. It's good article reviews rest tools
I'm trying to develop an application using JSF, primefaces, Tomcat7.
When I execute an ajax event, I get this warning:
17-ott-2012 9.26.04 org.apache.myfaces.trinidadinternal.context.PartialViewContextImpl getPartialResponseWriter
AVVERTENZA: getPartialResponseWriter() called during render_reponse. The returned writer is not integrated with PPRResponseWriter
What does it means? What do I have to do to integrate it?
In my server log, on startup, I find some messages about some web context parameters not found. May it be related to the previous warning?
Thanks for your help!!
This class is specific to MyFaces Trinidad. Apparently you're mixing Trinidad with PrimeFaces and it's not working very well. Since you didn't mention anything about Trinidad in your question, it's perhaps a leftover of previous experiments to play around with several component libraries. You might want to remove it before using PrimeFaces.
I've got a website build with Spring and jpa (by hibernate). I've got a bug and I don't know how to identify the line where the bug appears.
I can't debug it on my ide because it's a live version (all runs fine in local).
I've got log which says:
o
rg.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)#012#011
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)#012#011
at com.mycompany.server.rpc.UserService$$EnhancerByCGLIB$$64ed2d4f.createAccount(<generated>)#012#011
at com.mycompany.server.rpc.ServiceRPCImpl.createAccount(ServiceRPCImpl.java:309)
My problem is the third line. As the UserService object is handled by Spring, it becomes a proxy and I can't know the line of the bug.
Do you know how to solve the problem ?
Thanks
Is it possible for you to change from cglib to jdk proxy? (Spring AOP proxy reference)
Basically: if you access your beans as interfaces, you can use jdk proxies (spring default mechanism), thereby leaving the underlying object intact and gaining access to line numbers in stack traces.
I would say that not being able to reproduce this locally is a significant restraint. I would try to set up your local environment or a test server to reproduce the problem, using JMeter or other load test software to simulate load of concurrent user accesses. Once this is done, your tweak/compile/test cycle becomes a lot shorter, and you can make experimental changes without fear of disrupting service on your production server. It may seem like a lot of effort, but the work will pay dividends not just for this bug, but for bugs you may encounter in future.
It sounds like it could be a threading bug, especially since spring by default uses singleton scope. With that in mind, look into creating multithreaded integration tests for the service that is failing. Once you have reproduced the bug through load testing, you can verify that it's a threading bug by making your main service method synchronized, preventing concurrent use. If the bug disappears, it is most likely a concurrency bug.
As to finding the line of the bug - there is no line to look for since the code is generated. The best you can do is to add defensive checks in all beans that are being used in the advice around the UserService. (E.g. check for null values due to missing injections.) The init-method attribute on beans is useful for performing checks that the bean has been fully constructed and all required collaborators have been set.
If you cannot reproduce the issue in local environment, then may be it is environment / network related issue. I would first recreate the issue in test environment ( which is closer to production environment and not just own local machine ) to debug the bug.
You may also use Fiddler to debug network related issues for a live version.