Issues - robey/configgy

robey / configgy

Description:

simple config and logging setup for scala

Sort by: Priority | Votes | Last Updated

Loading…

8.

0 votes

inherit replace or merge keys?
2 comments Created 2 months ago by mighdoll

Title

Body
Inherit blocks and structured keys don't work well together right now. Sibling keys from parent blocks are wiped out when children override any sibling key. Here's an example: <parent> a.a = "parentA" a.b = "parentB" </parent> <child inherit="parent"> a.b = "childB" </child> scala> Configgy.config.getString("child.a.a") scala> config.getString("child.a.a") res8: Option[String] = None I can see an argument for the current behavior, though I'd prefer to have the tree of parent keys merge with the child keys by default. Perhaps there ought be an choice. e.g.: <a inherit="parent merge"> <a inherit="parent replace">
or cancel
Inherit blocks and structured keys don't work well together right now. Sibling keys
from parent blocks are wiped out when children override any sibling key.

Here's an example:
```
a.a = "parentA" 
a.b = "parentB"
```
```
a.b = "childB"
```
scala> Configgy.config.getString("child.a.a") scala> config.getString("child.a.a") res8: Option[String] = None

I can see an argument for the current behavior, though I'd prefer to have the tree of
parent keys merge with the child keys by default. Perhaps there ought be an choice. e.g.:
Comments

robey Mon Sep 21 12:49:51 -0700 2009 | link

i think i see what you mean. another way of thinking of it is that the "inherit" bit should be sticky across children, so that if A inherits from B, then A.y should inherit from B.y.

Comment
i think i see what you mean. another way of thinking of it is that the "inherit" bit should be sticky across children, so that if A inherits from B, then A.y should inherit from B.y.
or cancel

mighdoll Mon Sep 21 13:27:09 -0700 2009 | link

yep, that sounds like it would do it.

(There are conceptually two trees here: the inherit tree, and the '.' heirarchy. I think we used 'child' referring to different trees in our respective comments)

I see the bottom of my earlier comment didn't post... I can imagine an inheritor might want the current behavior in some cases. If that's worthwhile, perhaps inheritors could mark some of their blocks as no-inherit.

Comment
yep, that sounds like it would do it. (There are conceptually two trees here: the inherit tree, and the '.' heirarchy. I think we used 'child' referring to different trees in our respective comments) I see the bottom of my earlier comment didn't post... I can imagine an inheritor might want the current behavior in some cases. If that's worthwhile, perhaps inheritors could mark some of their blocks as no-inherit.
or cancel

Parsed with GitHub Flavored Markdown
9.

0 votes

case sensitve access to keys would be handy
0 comments Created 2 months ago by mighdoll

Title

Body
I wrote a simple log4j adapter, and ended up with a similar problem. I ended up with: logOverride-log4j-logger-org-bla-Foo = "org.bla.Foo=warn" I had to put the org.hibernate in quotes to capture the capitilization. With case sensitive keys, rather than the current node+level syntax for configgy logging, this would be nicer: log.MyBuggyModule="trace"
or cancel

I wrote a simple log4j adapter, and ended up with a similar problem. I ended up with:
logOverride-log4j-logger-org-bla-Foo = "org.bla.Foo=warn"
I had to put the org.hibernate in quotes to capture the capitilization.

With case sensitive keys, rather than the current node+level syntax for configgy logging, this would be nicer:
log.MyBuggyModule="trace"

Comments

Parsed with GitHub Flavored Markdown
10.

0 votes

allow periods in configgy block names
0 comments Created 2 months ago by mighdoll

Title

Body
Here's a fun idea to make nested configgy blocks more concise. Rather than this (brackets elided): Module SubModule SettingType key1 key2 /SettingType /Submodule /Module How 'bout this: Module.SubModule.SettingType key1 key2 /Module.SubModule.SettingType
or cancel
Here's a fun idea to make nested configgy blocks more concise.

Rather than this (brackets elided):

Module
SubModule
```
SettingType
  key1
  key2
/SettingType
```
/Submodule /Module

How 'bout this:

Module.SubModule.SettingType
key1 key2 /Module.SubModule.SettingType
Comments

Parsed with GitHub Flavored Markdown
12.

0 votes

Log rotation on "sunday" uses wrong date in file name
1 comment Created 2 months ago by ijuma

Title

Body
Let's assume that the file name is foo. This is what I'm seeing: -rw-r--r-- 1 root root 10702915 Aug 22 23:53 foo-20090819.log -rw-r--r-- 1 root root 20293696 Aug 29 19:58 foo-20090823.log -rw-r--r-- 1 root root 20795664 Sep 5 19:58 foo-20090830.log -rw-r--r-- 1 root root 21192915 Sep 12 23:44 foo-20090910.log -rw-r--r-- 1 root root 20373508 Sep 19 19:49 foo-20090913.log -rw-r--r-- 1 root root 20301093 Sep 26 23:21 foo-20090923.log The actual rotation seems to take place at the right time, but the date in the file name is clearly wrong (and the pattern isn't clear to me).
or cancel

Let's assume that the file name is foo. This is what I'm seeing:

-rw-r--r-- 1 root root 10702915 Aug 22 23:53 foo-20090819.log -rw-r--r-- 1 root root 20293696 Aug 29 19:58 foo-20090823.log -rw-r--r-- 1 root root 20795664 Sep 5 19:58 foo-20090830.log -rw-r--r-- 1 root root 21192915 Sep 12 23:44 foo-20090910.log -rw-r--r-- 1 root root 20373508 Sep 19 19:49 foo-20090913.log -rw-r--r-- 1 root root 20301093 Sep 26 23:21 foo-20090923.log

The actual rotation seems to take place at the right time, but the date in the file name is clearly wrong (and the pattern isn't clear to me).

Comments

ijuma Sun Sep 27 22:44:29 -0700 2009 | link

The formatting got all messed up, sorry. Here is another attempt:

-rw-r--r-- 1 root root 10702915 Aug 22 23:53 foo-20090819.log
-rw-r--r-- 1 root root 20293696 Aug 29 19:58foo-20090823.log
-rw-r--r-- 1 root root 20795664 Sep 5 19:58 foo-20090830.log
-rw-r--r-- 1 root root 21192915 Sep 12 23:44 foo-20090910.log
-rw-r--r-- 1 root root 20373508 Sep 19 19:49 foo-20090913.log
-rw-r--r-- 1 root root 20301093 Sep 26 23:21 foo-20090923.log

Comment
The formatting got all messed up, sorry. Here is another attempt: -rw-r--r-- 1 root root 10702915 Aug 22 23:53 foo-20090819.log -rw-r--r-- 1 root root 20293696 Aug 29 19:58foo-20090823.log -rw-r--r-- 1 root root 20795664 Sep 5 19:58 foo-20090830.log -rw-r--r-- 1 root root 21192915 Sep 12 23:44 foo-20090910.log -rw-r--r-- 1 root root 20373508 Sep 19 19:49 foo-20090913.log -rw-r--r-- 1 root root 20301093 Sep 26 23:21 foo-20090923.log
or cancel

Parsed with GitHub Flavored Markdown
13.

0 votes

Include sources in maven repo
0 comments Created about 1 month ago by memelet

Title

Body
Also, when I went to build my own *-sources.jar I found that there is no tag for 1.4... thanks!
or cancel

Also, when I went to build my own *-sources.jar I found that there is no tag for 1.4...

thanks!

Comments

Parsed with GitHub Flavored Markdown
14.

0 votes

Support Scala 2.8
0 comments Created about 1 month ago by ijuma

Title

Body
This issue is to track support for Scala 2.8. I've started a branch for that as described here: http://blog.juma.me.uk/2009/10/25/configgy-for-scala-2-8/ I intend to keep it current as time permits until it's merged upstream. In any case, take a look if you have the time as you may find that some of the required changes are not to your liking and feedback to EPFL should be given before the final release.
or cancel

This issue is to track support for Scala 2.8. I've started a branch for that as described here:

http://blog.juma.me.uk/2009/10/25/configgy-for-scala-2-8/

I intend to keep it current as time permits until it's merged upstream. In any case, take a look if you have the time as you may find that some of the required changes are not to your liking and feedback to EPFL should be given before the final release.

Comments

Parsed with GitHub Flavored Markdown
15.

0 votes

NPE in Logger.elements
1 comment Created 20 days ago by ijuma

Title

Body
I get the following NPE when using Configgy with JDK6u18 (early access): Caused by: java.lang.NullPointerException at net.lag.logging.Logger$.elements(Logger.scala:318) at net.lag.logging.Logger$.clearHandlers(Logger.scala:252) at net.lag.logging.Logger$.reset(Logger.scala:243) at net.lag.logging.Logger$.<init>(Logger.scala:224) at net.lag.logging.Logger$.<clinit>(Logger.scala) ... 59 more Seems like the logger is being released between the getLoggerNames call and the getLogger call.
or cancel
I get the following NPE when using Configgy with JDK6u18 (early access):

Caused by: java.lang.NullPointerException
```
at net.lag.logging.Logger$.elements(Logger.scala:318)
at net.lag.logging.Logger$.clearHandlers(Logger.scala:252)
at net.lag.logging.Logger$.reset(Logger.scala:243)
at net.lag.logging.Logger$.<init>(Logger.scala:224)
at net.lag.logging.Logger$.<clinit>(Logger.scala)
... 59 more
```
Seems like the logger is being released between the getLoggerNames call and the getLogger call.
Comments

ijuma Mon Nov 16 03:41:46 -0800 2009 | link

Fix here:

http://github.com/ijuma/configgy/commit/f6e757745ac18edc1a5c53619687a9f44d6c422f

Comment
Fix here: http://github.com/ijuma/configgy/commit/f6e757745ac18edc1a5c53619687a9f44d6c422f
or cancel

Parsed with GitHub Flavored Markdown