I want to keep my rails 3 app from saving all the development logs in the development.log because its making my file bigger.
You can either do this in your:
application.rb
Or if you only want to disable for specific environments do this in the specific env config, in your case:
config/environments/development.rb
You're probably looking for some or all of the following settings:
config.logger
config.active_record.logger
config.action_controller.logger
config.action_view.logger
config.action_mailer.logger
config.active_resource.logger
If you set any of them to nil e.g.:
config.active_record.logger = nil
It should disable logging for that specific component. You can experiment with these to disable logging for specific components or set all of them to nil to get no logging.
Switching it entirely off is a very bad idea. You can make it put less transactions in it by specifying a log level like:
config.log_level = :info
in the config/environments/development.rb file. For the various options look here:
http://guides.rubyonrails.org/configuring.html
Normally, in a rails-app, there is a configuration-file, where you can set development-, production-, staging - specific configuration-data for logging, database-binding, bootstraps,...
Maybe you check these file, if there are no attributes defined for logging, check out, if you´re logging-level is set to the appropriate value.
Link: Click
greets
Related
I have been working on a Windows Store app where I have to support multiple configuration parameters for my app. One of the parameters is the URL the app is talking to.
For example development environment, test, acceptance and finally production.
One of the things i'm currently thinking about is what is the most efficient way of supporting all these environments with the least effort. Because there isn't some kind of config file that we can change to update these parameters I came up with some ideas. I'm curious about other options that I might have not seen.
Here are the things I came up with:
1
Adding multiple configuration to the app and than using them in code to get the correct parameter like this:
private string webserviceUrl;
#if DEV
webserviceUrl = "devUrl";
#elif TEST
webserviceUrl = "testUrl";
#endif
2
With the approach in number 1 there are a few more options available like including a config xml file bases on the configuration, or fetching configuration settings from a webservice the first time the app is running.
3
Using a branch/merge strategy and update the config files in the branch. Advantage is that the code is clean and only contains the settings it needs for the build it's created for. And the package can be build by the build server. Disadvantage is that you need to branch/merge alot.
The last option feels like the most 'clean' solution to do this. Am I missing any options, or do you have experience with any of these methods? What would you prefer?
I think the assumption is that apps in the store will always point to production.
But, in saying that, I'm facing the same issue as we're side loading the application onto devices that we control, and not using the Windows Store at all.
To answer your question, I prefer option 1.
Option 2 and the xml/json config file seems like the best option though.
The webservice option probably won't work. What webservice URL do you use? And how will it work if you want some instances pointing to different environments as they will all be fetching the config from the same URL.
Another option you might want to consider would be options in the settings charm menu. For example, use radio buttons for the environments, and allow the user to configure which environment they want to target.
The issue would be locking it down in production for end users so that it isn't modifiable any more. Perhaps once "PROD" radio is selected, all the radio buttons are then hidden.
If you're deploying the application through side loading, then these settings could probably be configured during the install process.
I'd be interested to hear other opinions as well. This is also an old question, so I'd like to know what solution you decided on implementing.
I'm working on a multi-tenant application, so pretty much everything throughout (starting with routing) expects to have a "request.host" that looks like "tenant_id.myapp.com".
I'm trying to run a controller action from the Rails console, but I haven't been able to figure this one out.
The easiest thing to do seems to be "app.get", but I can't figure out how to set the host.
I also saw an answer that mentions using "ActionController::TestProcess", which as far as I understand has been removed from Rails (or if not, I haven't found how to include it)
Any other options?
Thanks!
Daniel
I just verified it in my console(Pry)
# Send request with fake HTTP_HOST
>>app.get(app.root_path, nil, {"HTTP_HOST" => "123.myapp.com"})
>>#=>200
# Then check if it works
>>app.request.env
>>#...
>># "HTTP_HOST" : "123.myapp.com"
Rails 3.0.10 and activemerchant gem 1.29.3
My app works fine in sandbox, but transactions in production mode are failing with "Security header is not valid", "ErrorCode"=>"10002"
We initiated a support request with paypal, after reviewing all the configuration parameters a million times and they feel we're hitting an incorrect endpoint. They've asked for a full trace for the transaction, including headers, etc, so I'm trying to figure out how to do that. I found this article
which suggested adding this to the config block
ActiveMerchant::Billing::PaypalGateway.wiredump_device = File.new(File.join([Rails.root, "log", "paypal.log"]), "a")
But that just results in an empty log; nothing gets dumped to it.
So, how can I obtain this info from the GATEWAY object, if possible? Here's the production config, the format of which is identical to what's used in staging env.
::GATEWAY = ActiveMerchant::Billing::PaypalGateway(
:login => 'me_api1.blah...',
:password => 'string...',
:signature => 'longer string...'
)
Thanks.
Needed to add the additional line as follows:
ActiveMerchant::Billing::PaypalGateway.wiredump_device.sync = true
Within the same config block in the environment
Somewhere in the class library you're using there should be a function to output this for you (if it's a well built library, that is.)
Even without that, though, you should be able to look in that PaypalGateway function to see where/how it's setting the endpoint. It's either hard-coding the value or it'll be setting different endpoints based on some sandbox option you have configured somewhere else in the class.
It's hard to tell you more than that without getting a look a the actual class library you're using, but I can concur that it must be either incorrect credentials or an incorrect endpoint. I've never once seen that security header error when it wasn't simply invalid credentials, which means either your values are incorrect or you're hitting the wrong endpoint.
If you want to post that whole function (or maybe even the whole library as the endpoint could be getting set from some other function) I can take a look and find the problem for you.
I've put the following code into my config/environments/test.rb file:
config.action_mailer.default_url_options = { :host => "localhost:3000" }
however when I run my tests, all routes use http://test.host. I'm trying to work with an API that won't accept http://test.host as a valid callback URI, so I need to change this to properly receive the API response. Any idea why this isn't working? (I'm using RSpec, Guard, and Spork in my testing suite).
EDIT: Possibly relevant - this is being done inside of a controller spec.
EDIT2: It seems that it changes after a request is made via get, post, etc. Running the following code within the test:
Rails.logger.debug users_url
get 'http://google.com'
Rails.logger.debug users_url
would produce the following output:
http://localhost:3000/users
...get request related response here
http://google.com/users
Nowadays you can just set them in your test.rb like so:
Rails.application.routes.default_url_options[:host]= 'localhost:3000'
Rails.application.routes.default_url_options[:host]= 'localhost:3000'
In the developemnt.rb / test.rb, can be more concise as following:
Rails.application.configure do
# ... other config ...
routes.default_url_options[:host] = 'localhost:3000'
end
From my experience, url_options will not be passed into tests without a bit of hacking.
See e.g.
How to set locale default_url_options for functional tests (Rails)
http://www.ruby-forum.com/topic/3448797
I've frequently encountered this problem when trying to set the locale in tests. I've never used action mailer, though, so there may be a simpler way to do it.
The solution I've found for setting the default locale in url_options is just to patch actiondispatch and force it to use whatever locale I want it to. You could adapt this to your case this way:
class ActionDispatch::Routing::RouteSet
def url_for_with_default_url_options(options)
url_for_without_default_url_options(options.merge(:host => "localhost:3000" ))
end
alias_method_chain :url_for, :default_url_options
end
I put that code in a file in spec/support so it is used in rspec tests and I also require it from my env.rb file so I can use it in cucumber tests as well.
Keep in mind that this will patch it everywhere, in both test code and in actual code running under tests, and it will override any other settings for the :host key that you try to pass in (since the patch merges the fix on top of the options passed into url_for). In your case I believe that shouldn't be a problem.
Monkey patching is not a very elegant solution, though, and I used this after everything else failed. You might find a simpler solution specific to action mailer.
How are you running your tests? Maybe appending RAILS_ENV=test might help.
There's a rails configuration option of config.colorize_logging that you can set to turn it on/off across the board. It's not clear to me where to configure (or write a logger subclass) that can keep colorized logging to my terminal without inserting all the goofy control characters into log files
Rails.logger is a ActiveSupport::BufferedLogger:
#<ActiveSupport::BufferedLogger:0x0000010524ae18 #level=0, #buffer={},
#auto_flushing=1, #guard=#<Mutex:0x0000010524ab70>,
#log=#<File:/Users/ian/coding/some_poject/log/development.log>>
Though it also seems to be splitting the output to $stdout at some point, and it's not clear to me where hooks are to configure the loggers.
You can add this to your configuration:
console do
config.colorize_logging = true
Rails.logger = Logger.new(STDOUT)
end
The console do should only execute if you're, well, using a console.
The Rails.logger = Logger.new(STDOUT) is something I add to make the logging use STDOUT automatically.
Hope this helps.