Fallback is a cool feature in Feignclient, however I would like to know what happens during fallback event. Is there anyway to output the root cause to log file?
Related
[Quarkus] How can we toggle the file log handlers
I am trying to use file handlers and want to configure if that file handler should be enabled or disabled
I am using this property
quarkus.log.handler.file."myHandler".enable=${myHandlerShouldBeEnabled}
quarkus.log.handler.file."myHandler".format=${someFormat}
quarkus.log.category."com.mypackage".handlers"=myHandler
But even on setting myHandlerShouldBeEnabled=false, logs are getting written to file.
Any suggestion will be helpful
This is indeed a bug that I reported here based on this question.
It should be fixed by this Pull Request.
I was unable to run typesafe activator in cloud9 :
The activator page loads OK but then I get the following error messages :
in the browser :
"Connection lost; you will need to reload the page or restart
Activator. It's also possible that Activator is open in another tab,
which causes this error."
in the cloud9 terminal :
"! #6j9pn9913 - Internal server error, for (GET)
[/home/stream?token=cba94...64394] -> play.api.Application$$anon$1:
Execution exception[[RuntimeException: Bad CSRF token for websocket]]"
Any help on how to solve this ?
Activator listens on 127.0.0.1 and is not even supposed to be listening on an external interface; it isn't completely clear to me why you can connect to it at all.
But however that connection works, it looks like the result is that the CSRF check fails. The CSRF check is checking that the query parameter there (?token=cba94...) matches a cookie that should have been set by the Activator page load. This demonstrates that the /home/stream request (to open the websocket) is coming from a page that has the cookie, i.e. from the same domain. Perhaps Activator doesn't know the domain you are loading the page from and therefore the cookie gets lost? Just a guess.
When the CSRF check fails that would then fail the websocket and cause the "Connection lost" error, though that error can also be caused by other things (such as proxies and antivirus software) that interfere with websockets.
You could possibly fix this, or take a step towards fixing this, by configuring the http.address system property to be picked up here: https://github.com/typesafehub/activator/blob/52012321b3a5a9f9dcf53582664e385d92763718/ui/app/activator/UIMain.scala#L130
You could also try setting application.defaultCookieDomain to the domain you are using (this is a Play config option and Activator's UI is a play app).
However:
you may well find other bugs in this scenario - it is not tested or supported
it is not at all secure unless you have some kind of authenticated proxy in front of it (there's no auth on the activator UI, and the UI has buttons to view and delete files, etc).
The activator shell command line is maybe a better option when you have your project build on a headless server, though I won't say running the UI is 100% impossible - you might be able to get it to work.
I'm writing a web service in Sinatra. I use middleware to add simple, dumb CORS support (by simply spamming Access-Control-Allow-Origin=* on all requests). I know there's a gem with more robust support, but this does what I want with 3 lines of code. Except...
Except that if #app.call env raises an exception, I never get a chance to modify the headers. The exception bubbles all the way up to Rack::ShowExceptions, and I can't find a way to inject my extra header into its response.
Do I have to stop using Rack::ShowExceptions? Do I have to mokeypatch it? Should I put more middleware further down the stack that catches non-CORS-aware error messages and adds them? I'm not sure I know how to do any of those.
Turns out I guessed right: I simply had to make sure that use DumbCorsSupport was before use Rack::ShowExceptions. It's worth noting, though, that at least in the browsers I'm using, if your 500 page doesn't offer the same CORS headers as the rest of your service, your client-side error callbacks won't get triggered!
I am supporting an application that has some DWR components. Whenever there is a server error i get a javascript alert that simply says 'error'.
Does anyone know where this might be configured and if there is a way to disable this. Id rather it silently fail at whatever then do this very distracting message.
Use DWR exception handlers in the positions wherever there is a chance for run time errors.
Use try catch mechanism and printstacktrace() in catch block. It works for me!
I want to disable logging for struts2 validation,whenever a struts action called containing validation I get 'junk' in my log, smth like this :
"[Apr 15 14:42:41] ERROR (CommonsLogger.java:24) - Validation error for domain:blahblah.".
I'm already using log4j and it's logging just fine but I don't want to this 'junk' filling my log.
If some code is nedded I will get it but at this moment I don't know what to present.
To be precise this 'junk' logs are logging the validation messages in struts2 (e.g 'Please enter your name'),maybe this will help someone help me. :)
In log4j you can modify the logging level per-class, and typically every class has its own logger. But they're hierarchical, so you can typically set the logging level for a package and affect all its members. So add the following to your log4j.properties file:
log4j.logger.com.opensymphony.xwork2.validator = FATAL
This is a pretty broad brush though -- with this you won't get visibility into potentially serious problems with validation. You may want to pinpoint which class is emitting the logging message and only modify its logging.
#milostrivun
log4j.logger.com.opensymphony.xwork2.validator = FATAL
This would set the logger level to FATAL which is equivalent to instructing log4j to log message which are of priority FATAL or more(Though there is no higher level than FATAL).
So, the TRACE, DEBUG, INFO, WARN, ERROR level messages coming from any class within the com.opensymphony.xwork2.validator packagae would not get printed.
Makes sense?