Allow alternate path in Dancer::Logger::File?
Currently the logdir() method in Dancer::Logger::File looks like: sub logdir { my $appdir = setting('appdir'); my $logroot = $appdir || File::Spec->tmpdir(); return path($logroot, 'logs'); } However, our production environments all mount off read-only filesystems, so having logging dependant on appdir won't work. I can write a new logger module that does something like: sub logdir { my $appdir = setting('appdir'); my $altpath = setting('log_path'); my $logroot = $appdir || File::Spec->tmpdir(); return ( $altpath ? $altpath : path($logroot, 'logs') ); } Is that something that is worth going into the core? I'm fine either way, but I thought this might be useful to others in the future. Thanks. Mike.
As a quick workaround, if your read-only filesystem (and your OS too!) supports linking you could make 'logs' point to the directory you really want to use for logs. 99% of chances that you had a good reason not to do that, but sometimes it's difficult to see the wood if one is concentrating on the trees. Personally, I would rewrite your sub as follows: sub logdir { my $altpath = setting('log_path'); return $altpath if $altpath; my $appdir = setting('appdir'); my $logroot = $appdir || File::Spec->tmpdir(); return path($logroot, 'logs'); } I see no reason to possibly create a temporary directory if you don't really need to. Cheers, Flavio. On Wed, Oct 27, 2010 at 8:11 PM, Mike Schroeder <mike@donor.com> wrote:
Currently the logdir() method in Dancer::Logger::File looks like:
sub logdir { my $appdir = setting('appdir'); my $logroot = $appdir || File::Spec->tmpdir(); return path($logroot, 'logs'); }
However, our production environments all mount off read-only filesystems, so having logging dependant on appdir won't work. I can write a new logger module that does something like:
sub logdir { my $appdir = setting('appdir'); my $altpath = setting('log_path'); my $logroot = $appdir || File::Spec->tmpdir(); return ( $altpath ? $altpath : path($logroot, 'logs') ); }
Is that something that is worth going into the core? I'm fine either way, but I thought this might be useful to others in the future.
Thanks.
Mike.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Thanks Flavio - good rewrite. Regarding the symlinks, the issue is that we are deploying Dancer on our grid, so we try to minimize the amount of customization required to add a node to a cluster. Much easier to update one shared config file than to have each node need to add a symlink on bootup. Since Dancer is so flexible to allow us to easily override the Logger, and since it sounds like we are an edge case, you can forget about my idea to add this to the core. Thanks for listening. Mike. On Thu, Oct 28, 2010 at 3:42 AM, Flavio Poletti <polettix@gmail.com> wrote:
As a quick workaround, if your read-only filesystem (and your OS too!) supports linking you could make 'logs' point to the directory you really want to use for logs. 99% of chances that you had a good reason not to do that, but sometimes it's difficult to see the wood if one is concentrating on the trees.
Personally, I would rewrite your sub as follows:
sub logdir { my $altpath = setting('log_path'); return $altpath if $altpath;
my $appdir = setting('appdir'); my $logroot = $appdir || File::Spec->tmpdir(); return path($logroot, 'logs'); }
I see no reason to possibly create a temporary directory if you don't really need to.
Cheers,
Flavio.
On Wed, Oct 27, 2010 at 8:11 PM, Mike Schroeder <mike@donor.com> wrote:
Currently the logdir() method in Dancer::Logger::File looks like:
sub logdir { my $appdir = setting('appdir'); my $logroot = $appdir || File::Spec->tmpdir(); return path($logroot, 'logs'); }
However, our production environments all mount off read-only filesystems, so having logging dependant on appdir won't work. I can write a new logger module that does something like:
sub logdir { my $appdir = setting('appdir'); my $altpath = setting('log_path'); my $logroot = $appdir || File::Spec->tmpdir(); return ( $altpath ? $altpath : path($logroot, 'logs') ); }
Is that something that is worth going into the core? I'm fine either way, but I thought this might be useful to others in the future.
Thanks.
Mike.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
I have no idea of how stuff is deployed upon a grid, so I will surely say laughable things but: if you have to deploy anything that resembles a directory tree, why not including a symlink in the tree as well? In general, the idea of setting the log path via a configuration seems valid in my opinion, so if I had any power of voting I would say "yes". I have no power, anyway :-) Cheers, Flavio. On Thu, Oct 28, 2010 at 5:45 PM, Mike Schroeder <mike@donor.com> wrote:
Thanks Flavio - good rewrite.
Regarding the symlinks, the issue is that we are deploying Dancer on our grid, so we try to minimize the amount of customization required to add a node to a cluster. Much easier to update one shared config file than to have each node need to add a symlink on bootup.
Since Dancer is so flexible to allow us to easily override the Logger, and since it sounds like we are an edge case, you can forget about my idea to add this to the core.
Thanks for listening.
Mike.
On Thu, Oct 28, 2010 at 3:42 AM, Flavio Poletti <polettix@gmail.com>wrote:
As a quick workaround, if your read-only filesystem (and your OS too!) supports linking you could make 'logs' point to the directory you really want to use for logs. 99% of chances that you had a good reason not to do that, but sometimes it's difficult to see the wood if one is concentrating on the trees.
Personally, I would rewrite your sub as follows:
sub logdir { my $altpath = setting('log_path'); return $altpath if $altpath;
my $appdir = setting('appdir'); my $logroot = $appdir || File::Spec->tmpdir(); return path($logroot, 'logs'); }
I see no reason to possibly create a temporary directory if you don't really need to.
Cheers,
Flavio.
On Wed, Oct 27, 2010 at 8:11 PM, Mike Schroeder <mike@donor.com> wrote:
Currently the logdir() method in Dancer::Logger::File looks like:
sub logdir { my $appdir = setting('appdir'); my $logroot = $appdir || File::Spec->tmpdir(); return path($logroot, 'logs'); }
However, our production environments all mount off read-only filesystems, so having logging dependant on appdir won't work. I can write a new logger module that does something like:
sub logdir { my $appdir = setting('appdir'); my $altpath = setting('log_path'); my $logroot = $appdir || File::Spec->tmpdir(); return ( $altpath ? $altpath : path($logroot, 'logs') ); }
Is that something that is worth going into the core? I'm fine either way, but I thought this might be useful to others in the future.
Thanks.
Mike.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On 2010-10-28, at 1:13 PM, Flavio Poletti wrote:
In general, the idea of setting the log path via a configuration seems valid in my opinion, so if I had any power of voting I would say "yes". I have no power, anyway :-)
+1 Making this configurable seems like a very reasonable way of handling it. I also have no power. :) -- Olaf Alders olaf@wundersolutions.com http://www.wundersolutions.com http://twitter.com/wundercounter 866 503 2204 (Toll free - North America) 416 944 8306 (direct)
On Thursday 28 October 2010 18:26:56 Olaf Alders wrote:
On 2010-10-28, at 1:13 PM, Flavio Poletti wrote:
In general, the idea of setting the log path via a configuration seems valid in my opinion, so if I had any power of voting I would say "yes". I have no power, anyway :-)
+1 Making this configurable seems like a very reasonable way of handling it. I also have no power. :)
As Dancer users, you certainly have the power to suggest improvements - we tend to try to listen to our users :) I also agree that a configurable logging path makes perfect sense. I've raised it as a wishlist item on the issue list on Github: http://github.com/sukria/Dancer/issues/#issue/170 -- David Precious <davidp@preshweb.co.uk> http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On Thu, Oct 28, 2010 at 3:12 PM, David Precious <davidp@preshweb.co.uk>wrote:
On Thursday 28 October 2010 18:26:56 Olaf Alders wrote:
On 2010-10-28, at 1:13 PM, Flavio Poletti wrote:As Dancer users, you certainly have the power to suggest improvements - we tend to try to listen to our users :)
Thanks David - and I have to say Dancer is one of the most responsive projects out there!
I've raised it as a wishlist item on the issue list on Github:
What is the best practice for this project? Raise an issue for discussion on this list first? or post an idea/issue directly on github? I'm happy to comply with whatever the project wants...
participants (4)
-
David Precious -
Flavio Poletti -
Mike Schroeder -
Olaf Alders