Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 17 16:17
    havocp commented #663
  • Feb 17 16:16

    havocp on master

    added support for memory units … fixed code format added Javadocs and 6 more (compare)

  • Feb 17 16:16
    havocp closed #663
  • Feb 17 16:16
    havocp closed #172
  • Feb 17 15:18
    mpryahin commented #172
  • Feb 10 13:34
    archieby closed #668
  • Feb 10 13:34
    archieby commented #668
  • Feb 10 13:32
    raboof commented #668
  • Feb 10 13:30
    archieby commented #668
  • Feb 10 13:26
    havocp commented #668
  • Feb 10 13:21
    archieby opened #668
  • Feb 08 00:17
    kini opened #667
  • Feb 03 17:15
    dwijnand commented #514
  • Feb 03 17:14
    dwijnand commented #514
  • Feb 03 10:06
    roldevg synchronize #666
  • Feb 03 09:58
    lightbend-cla-validator commented #666
  • Feb 03 09:58
    roldevg synchronize #666
  • Feb 03 09:54
    lightbend-cla-validator commented #666
  • Feb 03 09:54
    roldevg synchronize #666
  • Feb 03 09:33
    roldevg edited #666
bbaldino
@bbaldino

@havocp yeah i figured things were kinda screwed there. do you know if it was considered to not introduce hierarchy to keys from property files? i.e. instead of org.acme.foo becoming:

org {
    acme {
        foo {
            ...
        }
    }
}

it was just a flag org.acme.foo... property? so you'd end up with flat props like:

some-outer-scope {
    org.acme.foo=true
    org.acme.foo.some_other_prop="some value"
}

though i guess this makes merging keys from prop files with other (overlapping or semi-overlapping) paths from other files awkward

it does make me wonder if, since it's knowingly lossy, there should be some special treatment for parsed keys from property files or something (one that would also require special calls from the user). maybe it could be an optional setting or something--though there'd certainly be added complexity here
bbaldino
@bbaldino

is there any way to get the full paths of all the 'leaf' keys? i.e. for this config:

a {
  b {
    b1="hello"
    b2="world"
  }
  c {
    foo="bar"
  }
}

get the list: ["a.b.b1", "a.b.b2", "a.c.foo"] ? i can build it, just wondered if anything that did it already existed...i couldn't find anything but seemed like something that may exist

Havoc Pennington
@havocp
the entrySet method returns all the paths with values as a flat list
Edmondo Porcu
@edmondo1984
Hello, does anyone knows how to have keys that contain spaces?
if I place it surrounded by ' ' or by " " when I do config.entrySet().asScala in Scala, I get strings with ""quote"" like so
Havoc Pennington
@havocp
entrySet returns path expressions rather than keys. ConfigObject has keys
bbaldino
@bbaldino
thanks @havocp !
Anubhav Jain
@anubhav.jain1_gitlab
Hi, I am new to typesafe config, but I am really struggling with the substitution in .properties file
The substitution works with .conf but not with .properties.
Havoc Pennington
@havocp
substitutions are a feature of the .conf format not something done for other formats
Anubhav Jain
@anubhav.jain1_gitlab
Thanks @havocp , since the three formats are supported .conf, .properties and .json, is it possible to have the substitution enabled for the .properties and .json formats also. May be as a feature request.
Konstantin Bespalov
@k-bespalov
Hello! I have a problem and don't know how to solve. I have scala application which runs on oracle jdk 8 and now i'm trying run application on openjdk 11. and after switching jdk to openjdk 11 I faced to a problem with running unit-tests. I have module which has reference.conf and uses ConfigFactory.load(). And in tests this ConfigFactory.load() returns almost empty config without properties from reference.conf. Do you know what is happening or how I can debug it? Thanks in advance
bbaldino
@bbaldino
i ran into this as well, i think the reference.conf from main isn't on the classpath for test. in my tests i either write a test config file for that test and load it directly or, for simpler tests, parse a string in place
Konstantin Bespalov
@k-bespalov
but it used to work on jdk 8. now I have to copy kafka reference.conf to reference.conf of tests. it is not so nice :(
Havoc Pennington
@havocp
you could see whether -Dconfig.trace=loads gives any helpful information about where the files are being found. I'm aware that newer JDKs change class loading in various ways but I don't know much about how specifically to fix it or debug it for this problem.
generally if you can get ClassLoader.getResources to return the reference.conf you need then the config library should work.
Konstantin Bespalov
@k-bespalov
thank you. will try to look with this option
Michael Silbermann
@msilb
hi all, I am building a library that includes a reference.conf file with the property secret-key = ${SECRET_KEY}. In my test package I've included another reference.conf file overriding the property with some dummy value like this secret-key = dummy. Is this the recommended approach for library design or are there better alternatives?
bbaldino
@bbaldino
this is the test package in the same project? i've done this by including test files in src/test/resources, but, since multiple configs are often necessary for tests, i scope them in different files (one per test file) and scopes within that file (for each test scenario) then load that file explicitly as a resource using ConfigFactory.parseResources instead of just ConfigFactory.load
Russell Bie
@bxacsq
Hi, is there any way to convert the substitution to lowercase? something like this:
a.b = "UPPER"

a.c = ${a.b.LOWER_CASE}  // "upper"
Havoc Pennington
@havocp
no, that would have to be done in code
Russell Bie
@bxacsq
Can we create a custom ConfigResolver to do that?
Havoc Pennington
@havocp
could work!
bbaldino
@bbaldino
When you've got an application with a library inside, both using the config library...is it common/idiomatic to "load" the config in both places (the library and the application)? As in call ConfigFactory.load()?
Havoc Pennington
@havocp
yes but the library should also allow passing in a Config as a parameter, using load() only as a default
see examples app and library in the git repo
bbaldino
@bbaldino
ok, and for a lib that didn't have a central initialization point, say, we'd be left with calling load() on its own or some other technique to make the already-created config object available i assume
just wondering if there's something commonly done there
Havoc Pennington
@havocp
the ideal is that any object or function that uses config settings has an overload or variation that lets you pass a Config in, because that enables the application using the library to use something other than ConfigFactory.load(); but default to load() so if they stick to the defaults, they don't have to pass a Config around. The reasonConfigFactory.load() has no parameters (and returns a singleton) is so that it can be called many times from many places and always return the same result, so it's a safe default.
that's what the examples suggest. I'm not sure how many libraries "in the wild" actually do this.
there's deliberately not an init call like ConfigFactory.setDefault(something) because the problem is that you'd have to be sure it was called before anyone tried to use any config, which is sort of a nightmare.
bbaldino
@bbaldino
thanks...yeah i'm sort of running into that myself at the next layer up: trying to figure out how to instantiate config and then make it available to our libraries used as part of the application (which have no central entry point). we used to use osgi to provide config, but it's a pain having to retrieve that service everywhere so i went with a central class which can be accessed statically to get config, but that has the annoyance you mentioned: making sure it gets initialized in time. i currently do that statically as well, but that has its own issues.
bbaldino
@bbaldino
is there a way to parse only the system properties? (i.e. not any config files on the classpath)
bbaldino
@bbaldino
i hacked something to filter based on origin description, but wondering if maybe there's a cleaner way
Eric K Richardson
@ekrich
Looks like ConfigFactory.defaultOverrides() will give you system properties as a Config.
bbaldino
@bbaldino
ah, great!
Eric K Richardson
@ekrich
or ConfigFactory.systemProperties() is more direct. Hope this helps.
bbaldino
@bbaldino
ugh, how did i miss that. thanks @ekrich
Eric K Richardson
@ekrich
No worries, I just have the code open for the cross platform version and just took a peek knowing that it could be done - but not how :smile:
bbaldino
@bbaldino
For ease-of-use during development we've been deploying bundled jars so we only have to copy one file to a dev server instead of all of them. We've run into an issue with conflicting reference.conf files, as both a library we use has one and the application, but they're both in resources/reference.conf so only the last one ends up in the final fat jar. Is there a strategy we could use here to load both correctly? I tried nesting the lib's reference.conf but found that the class loader only looks for the file at one exact path when using ConfigFactory.load()
bbaldino
@bbaldino
Ah, I've just found that perhaps this is problem on the bundling side (just found https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#AppendingTransformer), so I'll look into that.
Edgar Orendain
@orendain
I remember reading a while back that optional environment variable defintions can not belong in reference.conf. Was there any validity to this? Will environment variables at runtime be picked up by configs that use them in reference.conf?
nafg
@nafg
@orendain where does it say that? I do it
Gerry Fletcher
@gerryfletch
I'm dealing with a pretty weird issue. I am using ConfigFactory.load() in a couple of places, and it works when running the application. but during a Scalatest run, it will work for usage within the context of a test (i.e a compiled test-class), but not for application code. The error is that com.typesafe.config.ConfigException$Missing: merge of system properties,reference.conf @ jar:file:ssl-config-core!/reference.conf doesn't hold the configuration setting I'm looking for. I'm not entirely sure why it is looking inside ssl-config-core...
Even weirder, it works fine running on JDK8, but has this issue on JDK11...
Havoc Pennington
@havocp
it loads all reference.conf and application.conf on the classpath, and for the two jdks and your test/prod setups the classpath contents must differ. Exactly why they differ I don’t know. Using the -Dconfig.trace option (described in readme) may help debug.
Gerry Fletcher
@gerryfletch
@havocp Thanks, I used the -Dconfig.trace=loads option last night and found that when the test-class loads the config, it uses an sbt.internal.LayeredClassLoader, and when the class under test loads the config, it uses java.net.URLClassLoader
That appears to be the only differences. I logged the classpath URLs in both instances and they are identical. It is impossible for them to be referencing a separate resource. There are some recent issues pointing to something similar, however: sbt/sbt#5410
So perhaps I have stumbled upon the same issue :/