Closed mixellent closed 12 years ago
Sorry about the limiting version restriction - an oversight on my part. I will update the dependency to ~> 1.6
instead of the >=
you have proposed. I am planning a logging v. 2 in the near future, and so I do not want to inadvertently break the rails plugin here.
Thanks for the patch, though! Any other feedback you might have on this plugin would be greatly appreciated.
No worries, thanks for the heads up Tim. When are you looking to perform the version update containing the dependency fix?
Also, some feedback with regards to your gem (all in all quite easy to use once setup is completed using the logging.rb settings file):
I am still struggling with specifying a logger object for each of my models, in order for those loggers to also be accessible in the related controllers.
Right now, I am performing the following in each of my models (for which I want logging):
logger = Logging.logger[self] ... logger.debug "Logging info here"
Now, of course I am unable to access this logger object from the controller this way. What do you suggest as a better way to have access to a single logger object from both the controller and model? (for example when you have a TripController and Trip model)
Can I specify a logger object in one of the initializers/configuration files (will I then have access to it from controllers and models?), or should I create a get_logger method in each of my models making my logger object accessible to the controller through that method (i.e.: logger = @trip.get_logger)?
A new release of logging-rails has been issued - version 0.4.0 should be available on rubygems right now.
There is a line in the railtie that adds a logger
method to Object. Since every class inherits from Object, this logger
method is available everywhere. You can use this method to access the appropriate logger for your model or controller.
What you are asking for is the "same" logger instance for both. In your controller you would define a logger
method that returns the appropriate model logger:
def logger
Logging.logger['YourModelClass']
end
However, I would not recommend doing this. One benefit of the Logging framework is the ability to specify the logging level for a single class. This allows very targeted debugging and avoids "scroll blindness" resulting from thousands of log messages scrolling quickly by.
I would recommend your controllers and models keep their own individual loggers. However, and I should have asked this first, what is your desired goal for having the same logger instance shared between a controller and a model?
My initial goal was to basically keep logging for a specific user flow from controller to model (and maybe related background worker) into the same logging file (so we don't have to switch between log files for a user flow). But maybe you are right and it could be a better practice to keep each class logic into a separate log file for easier debugging later.
Hi Tim,
Please merge these changes into the main branch. (This is actually my first pull request, so I'm sorry if for previous e-mails you may have received with other requests, I am only starting to get used to it :)
Thanks,
Michael