carueda / tscfg Goto Github PK

This is a follow-up of #33

Upon an absent parameter corresponding to a required nested parameter in the config spec, e.g.:

obj {
  sub {
    req: int
  }
}

the corresponding exception message will only refer to the simple path req:

com.typesafe.config.ConfigException$Missing: No configuration setting found for key 'req'

Certainly not critical, but it would be convenient for such exception to instead refer to the full path (obj.sub.req), which would be especially handy in cases where the overall configuration is complex.

0 = {
  1 = bar
}
2 = foo

1 and 2 are properly handled, but not 0 -- corresponding class name is not adjusted to make it a valid identifier.

It would be cool to have an ability to set a field which might have only limited set of values for example, let's say fruitType can be only apple, banana or pineapple.
In the config it could look like this:

app.fruitType = "string E ["apple", "banana", "pineapple"]"

After it, sealed trait with three classes could be generated:

trait FruitType 
object FruitType {
   object Apple extends FruitType
   object Banana extends FruitType
   object Pineapple extends FruitType
}

I noticed some difficulties in traversing member structs when using the new inheritance feature (many thanks for that!). Think of my following example config:

#@define abstract
AbstractA {
  a: string
}

#@define extends AbstractA
ImplA {
  b: string
}

Parsing this config to Scala config class aborts with IllegalArgumentException thrown in ModelBuilder:210, as the parent of ImplA cannot be found.

Here is, what is happening: In ModelBuilder:85 it is ensured, that at first the shared objects are processed and added to the name space, without any further distinction among the shared objects. In my case by incident at first ImplA definition and then AbstractA definition should be traversed. Therefore AbstractA is not known to the name space on attempt to add ImplA leading to the described exception.

I would propose to extend the ordering logic in ModelBuilder:85 to utilize an inheritance tree of shared objects. This would also allow inheritance of abstract shared objects then, e.g.

AbstractA
-- AbstractAA
---- ImplAA
-- AbstractAB
---- ImplAB
...

and the logic wouldn't rely on the order in which the user provides the shared object definitions.

Additionally, this might come in handy for #66 of @johanneshiry as then case class members (leaf nodes) can easily be identified.

If I can provide you anything further for a better understanding of my issue, please just let me know. If you two wish for some support on this, please also just give me a little hint. 😉

Hello,
I am having some problem with regex inside string, so I would like to know if is there any way to exclude some keys from building?

My config file has this key:
regex = ">(RUS00),(\\d{12})(.\\d{7})(.\\d{8})(\\d{3})(\\d{3}),(\\d{1,10})((\\.)(\\d{3}))?"

It works fine in my project, but i got this error on tscfg:
String: 1: Expecting a value but got wrong token: 'd' (backslash followed by 'd', this is not a valid escape sequence (quoted strings use JSON escaping, so use double-backslash \ for literal backslash)) (if you intended 'd' (backslash followed by 'd', this is not a valid escape sequence (quoted strings use JSON escaping, so use double-backslash \ for literal backslash)) to be part of a key or string value, try enclosing the key or value in double quotes, or you may be able to rename the file .properties rather than .conf)

It works only if my regex is commented, so actually I am commenting my regex line every time I use tscfg.

It would be helpful to decouple typesafe config files from tscfg's type spec. This would help ensure that the original typesafe config is not modified in any way with special syntax that is not recognized by Typesafe Config or any of its other wrappers.

Example:

Before
application.conf:

endpoint {
  path: "string"
  url: "string | http://example.net"
  serial: "int?"
  interface {
    port: "int | 8080"
  }
}

Instead of specifying tscfg types in this typesafe config file itself, we can decouple the type spec by introducing an optional additional file.

After
application.conf:

endpoint {
  path: "string"
  url: "http://example.net"
  serial: ""
  interface {
    port: "8080"
  }
}

tscfg.conf:

endpoint {
  serial: "int?"
  interface {
    port: int
  }
}

Moreover, since all values will now be strings by default unless explicitly converted (#42), the string type specification becomes redundant and unnecessary. The result is a much simpler typespec.

The user can then supply this optional typespec file like so:
java -jar tscfg-x.y.z.jar --spec example.spec.conf --typespec example.typespec.conf

If the user does not specify the --typespec parameter, tscfg can look for a default tscfg.conf file in the same directory. If one does not exist, tscfg can proceed with default type conversions (i.e., all String).

Let me know what you think!

for example,

// auto-generated by tscfg x.y.z on ...
// source: example/def.example.conf

package tscfg.example;

import com.typesafe.config.Config;

public class Cfg {
  ...

Support a size type corresponding to the size-in-bytes formats supported by Typesafe-Config as specified in https://github.com/typesafehub/config/blob/master/HOCON.md#size-in-bytes-format

Example config spec for tscfg to process:

# required size
sizeReq: "size"

# optional size, no default
sizeOpt: "size?"

# optional size with default value 1024 bytes
sizeOptDef: "size | 1K"

# list of sizes
sizes: [ size ]

# list of lists of sizes
sizes2: [ [ size ] ]

Input config example:

sizeReq = "2048K"
sizeOpt = "1024000"
sizes = [ 1000, "64G", "16kB" ]
sizes2  = [[ 1000, "64G" ], [ "16kB" ] ]

(thanks P. Ambrose for reporting)

if one of the properties is named foo.config.bar, a Config class is created by tscfg. The problem is
all references to com.typesafe.config.Config are incorrectly referencing the
generated class. I think the problem will be easily fixed by fully qualified references
to com.typesafe.config.Config in the method args.

Currently (0.8.4):

From:

foo-object {
  bar-baz: string
}
other-stuff: int

the generated Scala is:

case class ScalaIssue30Cfg(
  foo_object  : ScalaIssue30Cfg.FooObject,
  other_stuff : scala.Int
)
object ScalaIssue30Cfg {
  case class FooObject(
    bar_baz : java.lang.String
  )
  ...

That is, regarding the characters that would make the identifiers invalid in Scala, tscfg either removes them (foo-object becomes FooObject) or replace them with underscores (other-stuff -> other_stuff; bar-baz -> bar_baz).

So, the suggested idea here is to add an option to instead use back ticks for such translations (which should probably have been the default behavior since this was implemented):

case class ScalaIssue30Cfg(
  `foo-object`  : ScalaIssue30Cfg.`Foo-Object`,
  `other-stuff` : scala.Int
)
object ScalaIssue30Cfg {
  case class `Foo-Object`(
    `bar-baz` : java.lang.String
  )
...

Note that back sticks have already been used but only for Scala reserved words.

With

idleTimeout = 75 seconds

idleTimeout gets typed as STRING. The ObjectType is

ObjectType(Map(idleTimeout -> AnnType(STRING,true,Some(75 seconds),None)))

(captured as optional and with default value "75 seconds" is ok.)

But idleTimeout should get the type DURATION(ms) instead of STRING.

Related with #64, the base class shouldn't necessarily be abstract, but this is currently required per the issue 64b test, which refers to this spec:

    #@define
    BaseModelConfig {
      uuids: [string]
      scaling: double
    }
    
    #@define extends BaseModelConfig
    LoadModelConfig {
      modelBehaviour: string
      reference: string
    }
    
    test.loadModelConfig = LoadModelConfig

Is there any way to use an object multiple times in a spec and have it generate a shared config type?

E.g.

example {
  a: ${shared}
  b: [${shared}]
}

Where shared could be something like:

shared {
  c: string
  d: {
    e: int
    f: double
  }
}

I often run into this use case, where different parts of the config share a common object.
The above generates two differently named types for shared, forcing you to implement whatever logic consumes the shared object twice.

Is there a way around this, or do you have a recommended approach for such scenarios?

The use of the Lightbend/Typesafe Config library itself for purposes of parsing the input used to generate the wrapper has a number of limitations and counter-intuitive effects, in concrete when doing the automatic type detection from given values (NOTE: explicit types are not an issue). See for example #41, #50, #46.

This is not a fault of that library but rather a consequence of using it to infer the types. In particular, note that Lightbend/Typesafe Config:

• i) deals with concrete config input (as opposed to a schema as used in tscfg)
• ii) it complementarily offers multiple ways to get the value of the particular parameter, including getInt, getDouble, etc., so, in other words, it defers to the user to decide how to access the value.

The proposal here is to define a proper syntax/language more appropriate for schema definition purposes and, along with that, implement/use a corresponding parsing mechanism. Although tscfg is not yet v1, perhaps consider forcing the new proper syntax as the default in some stable version, while also adding an option to indicate the particular input language.

Reactions/comments welcome.

I am trying to declare and use two different shared objects.

sample conf

#@define
Shared {
  c: string
  d: {
    e: int
  }
}

#@define
Shared2 {
  dd: string
  dddd: {
    eeee: int
  }
}

example {
  a: Shared
  b: [ Shared ]
  c: [ Shared2 ]
}

command used

java -jar tscfg-0.9.981.jar --dd . --spec sample.conf

Generated file

public class ExampleCfg {
  public final ExampleCfg.Example example;

  public static class Example {
    public final java.lang.String a;
    public final java.util.List<java.lang.String> b;
    public final java.util.List<java.lang.String> c;

    public Example(
        com.typesafe.config.Config c,
        java.lang.String parentPath,
        $TsCfgValidator $tsCfgValidator) {
      this.a = c.hasPathOrNull("a") ? c.getString("a") : "Shared";
      this.b = $_L$_str(c.getList("b"), parentPath, $tsCfgValidator);
      this.c = $_L$_str(c.getList("c"), parentPath, $tsCfgValidator);
    }
  }

  public ExampleCfg(com.typesafe.config.Config c) {
    final $TsCfgValidator $tsCfgValidator = new $TsCfgValidator();
    final java.lang.String parentPath = "";
    this.example =
        c.hasPathOrNull("example")
            ? new ExampleCfg.Example(
                c.getConfig("example"), parentPath + "example.", $tsCfgValidator)
            : new ExampleCfg.Example(
                com.typesafe.config.ConfigFactory.parseString("example{}"),
                parentPath + "example.",
                $tsCfgValidator);
    $tsCfgValidator.validate();
  }

  private static java.util.List<java.lang.String> $_L$_str(
      com.typesafe.config.ConfigList cl,
      java.lang.String parentPath,
      $TsCfgValidator $tsCfgValidator) {
    java.util.ArrayList<java.lang.String> al = new java.util.ArrayList<>();
    for (com.typesafe.config.ConfigValue cv : cl) {
      al.add($_str(cv));
    }
    return java.util.Collections.unmodifiableList(al);
  }

  private static java.lang.RuntimeException $_expE(
      com.typesafe.config.ConfigValue cv, java.lang.String exp) {
    java.lang.Object u = cv.unwrapped();
    return new java.lang.RuntimeException(
        cv.origin().lineNumber()
            + ": expecting: "
            + exp
            + " got: "
            + (u instanceof java.lang.String ? "\"" + u + "\"" : u));
  }

  private static java.lang.String $_str(com.typesafe.config.ConfigValue cv) {
    return java.lang.String.valueOf(cv.unwrapped());
  }

  private static final class $TsCfgValidator {
    private final java.util.List<java.lang.String> badPaths = new java.util.ArrayList<>();

    void addBadPath(java.lang.String path, com.typesafe.config.ConfigException e) {
      badPaths.add("'" + path + "': " + e.getClass().getName() + "(" + e.getMessage() + ")");
    }

    void validate() {
      if (!badPaths.isEmpty()) {
        java.lang.StringBuilder sb = new java.lang.StringBuilder("Invalid configuration:");
        for (java.lang.String path : badPaths) {
          sb.append("\n    ").append(path);
        }
        throw new com.typesafe.config.ConfigException(sb.toString()) {};
      }
    }
  }
}

Ideally, a, b type should be Shared and c should be Shared2. But generated code contains all three variables as strings.

Size-in-bytes conversion should be explicitly (not optionally) specified by user using size | <size>. Unless this is explicitly specified, tscfg should assume it is a string by default; no implicit conversion should be done. (This is also the default behaviour of Typesafe Config.)

Example:

In each of the following cases, tscfg currently generates a variable memory of type Long, with value 53687091200.

memory: 50G
memory: "50G"

To be consistent with the default behavior of Typesafe Config, which doesn't make assumptions about types unless explicitly requested (e.g., using methods such as getBytes, getInt, etc), tscfg should instead generate a variable memory of type String, with value "50G". This should be the default behavior, unless the user explicitly requests a size-in-bytes comparison as follows:

memory: "size | 50G"

(This has been discussed at length in #41).

When no explicit type is given in the input config spec, infer the type according to the given value. This is mainly intended to facilitate generation solely based on existing configuration files.

When generating a java class from the following input:

my.parameter = 1.1
I get:

public static class my {
public final double parameter;
}

All is well, but:
my.parameter = 1.0
I get:

public static class my {
public final int parameter;
}

Which i think should be a double. The test in https://github.com/carueda/tscfg/blob/master/src/test/scala/tscfg/generators/java/JavaMainSpec.scala :

"example 1" in {
  val c = new JavaIssue15bCfg(ConfigFactory.parseString(
    """
      |strings:  [hello, world, true]
      |integers: [[1, 2, 3], [4, 5]]
      |doubles:  [3.14, 2.7182, 1.618]
      |longs:    [1, 9999999999]
      |booleans: [true, false]
      |""".stripMargin
  ))

is missing e.g. 4.0 in doubles to test this case.

There's a couple different patterns here I'd like to discuss; we've been switching between them at work in our handwritten boilerplate for Config and I was hoping this code generator could be extended to add one or the other or both.

Our apps just load their config once on startup, so it made sense to have the code executed in a static so it can be available everywhere; this does cause quite a bit of coupling which we will have to deal with later but it's great for rapid prototyping, especially if you don't expect the config to change.

Singleton Pattern

Our first attempt just used a singleton pattern, so with the codegen example from README it just looks like this:

public class Cfg {
  public final Service service;
  public static class Service {
    public final boolean debug;
    public final double factor;
    public final int poolSize;
    public final String url;
  }

  private static Cfg INSTANCE;
  public static final getInstance() {
    if (INSTANCE == null) INSTANCE = new Cfg(ConfigFactory.load());
    return INSTANCE;  
  }
}

Since we can't modify generated code because it can be overwritten at any point, it would be nice if the generator added something like this for us so we don't have to stick it in another class.

Statics Pattern

An alternative pattern we came up with that I've personally become more attached to is to just have a hierarchy of classes with static final fields, e.g. with the same example:

public class Cfg {
  private Cfg() {}

  private static final Config config = ConfigFactory.load();

  public static class Service {
    private Service() {}

    public static final boolean debug = config.getBoolean("service.debug");
    public static final double factor = config.getDouble("service.factor");
    public static final int poolSize = config.getInt("service.poolSize");
    public static final String url = Config.getString("service.url");
  }
}

It's kind of bad style but it looks really nice in usage:

Service.bind(Cfg.Service.url);

This avoids calling getInstance() everywhere which is really just line noise.

Hello again :-)

it has been a while but we still make extensive use of this library.
Today we discovered some flaws that relate to the implementation of shared objects / inheritance in the config generation.
The main issue is, that defined parent classes using #@define abstract do not implement java.io.Serializable and hence their serialization is prevented which might be required in some situations (which we are currently facing when we want to setup an akka cluster and send the configuration around).

So when we discussed this in our team we came up with three different approaches that would solve our issue, but we would love to hear your @carueda opinion on this and which one you would prefer to have handed in as a PR.

1. Always extend abstract class with java.io.Serializable
   The most easiest approach is to just add java.io.Serializable to all classes marked as #@define abstract. AFAIK this wouldn't break anything but just adds serialization capabilities to all abstract superclasses.

2. Extend the check to allow java.io.Serializable as parent in ModelBuilder:168
   This would be another way to allow java.io.Serializable by exclude it from the superclass check. With this adaption, we would allow something like

#@define extends java.io.Serializable
ChildStruct {
  c: string
  d: string
}

if a struct needs to be serializable.

3. Fully remove the check on existing parent classes in ModelBuilder:168
   This would be the biggest possible change that would not only solve our problem but somehow introduce a new feature. Without this check it would be possible to mix in any trait that is available in the existing codebase because we do not check anymore if the superclass is also defined within the config definition template. This would leverage the capabilities of superclasses to a new level and would allow for a huge flexibility. However, this would also introduce the possibility of non-compiling code as we lose control over the resulting code and cannot guarantee anymore that the resulting config class compiles as it may depend on third-party code at the specific project.

That said I'm open to provide a PR for one these solutions if you would like to.

Looking forward on your feedback and further discussions.

Best,

Johannes

We are using tscfg with scala 2.13.x and we get lot's of deprecation warnings:

object JavaConverters in package collection is deprecated (since 2.13.0): Use `scala.jdk.CollectionConverters` instead

I prepared a small adaptions to use the (in 2.13 newly introduced) scala.jdk.CollectionConverters to get rid of this warnings. But this would be a breaking change as it would require 2.13. Is there any interest in updating to 2.13 or is the intended way to stay with 2.12 and ignore the warnings for now?

I know this is just a small benefit that comes with a breaking change, but I thought I would ask it anyway as it has become a little bit annoying in our projects to have these deprecation messages everywhere.

This will allow the tool implementation to evolve in a more flexible manner while avoiding/minimizing unneeded formatting changes in generated code.

Basically these benefits:

• development can focus more on the correctness of the semantics and much less on dealing with the resulting formatting. Of course, changes in the output are to be expected when actually dealing with intended additions or changes.
• users can upgrade to new versions of the library with less concern about impact in terms of changes in the generated code. Some users also commit the generated code to version control, so, in general, better to avoid unnecessary formatting changes.

An initial approach is to just incorporate (as libraries) scalafmt for Scala, and probably google-java-format for Java; in general with whatever defaults they have. (Note: initially at least, the goal is just some consistent/automated formatting, not necessarily trying to follow any formatting rules that users may have for their own projects -- but this could be reviewed later if needed.)

Longer term, for Scala, we could also consider incorporating https://scalameta.org/ in the pipeline.

Suppose I have the following property in my typesafe-config file:

memory: "string | 50G"

the generated code using tscfg is:

memory = if(c.hasPathOrNull("memory")) c.getString("memory") else "50G"

However, if I load the config first using Typesafe's ConfigFactory.load() method, and if I then initialize the generated class using this Config object, I see this in the initialized object:

memory = "string | 50G"

Instead, I expect:

memory = "50G"

So it looks like despite generating the code correctly, initializing the generated class using a Typesafe Config object does not seem to parse the string correctly.

I highly recommend that if a key has a quoted string value in the Typesafe config file, the code generator should not implicitly convert it to bytes. Of course, if it is an unquoted string, it should convert it to bytes as is done currently.

Hey,

Would it be possible to have the releases available in maven central?

Best,
Niklas

It's not available to create spec contains List type with default value.
For example, spec intParams = [int] generate list of integers.
But default value for list will be ignored intParams = [int] | [1,2,3]. As workaround optional annotation can be used with default value in the code.

Definite syntax still TBD but the idea for the spec would be something like:

durations {
  # optional duration; reported Long (Option[Long] in scala) is null (None) if value is missing
  # or whatever is provided converted to days
  days = "duration:day?"

  # required duration; reported long (Long) is whatever is provided 
  # converted to hours
  hours = "duration:hour"

  # optional duration with default value;
  # reported long (Long) is in milliseconds, either 550,000 if value is missing
  # or whatever is provided converted to millis
  millis = "duration:ms | 550s"
}

Right now you can enter a default config such as this:

endpoint {
  url: "String | http://example.net"
}

However, if endpoint is not entered into the final config then you end up with a missing config exception. And optional does not work because it results in a None, which cannot reference the url property.

So, my proposed solution is to add a top level annotation to denote that objects themselves should use defaults if they exist.

Instead of config.endpoint.url throwing an exception because endpoint doesn't exist it will instead create the endpoint object and let the final property referenced determine if an exception or default should be used.

capture other types as supported by Config, perhaps even add some like "regex", etc.

Looking through the codegen it appears that it just calls Config.get*() for each of the config object's fields, so if any keys are missing or mistyped it will error out on the first one.

However, you can call Config.checkValid() with a prototype config and it will report errors for all missing or mistyped keys in the config with a runtime exception; we've been specifying a schema manually in our config static class (which kind of invalidates my point in #47 about not having two different sources of truth for the config schema but this way we would still only have a single spec, our default config) but it would be nice when using this library to automatically generate the prototype config and validate the config being passed to the constructor, e.g. for the example in README:

public class Cfg {
  public final Service service;
  public static class Service {
    public final boolean debug;
    public final double factor;
    public final int poolSize;
    public final String url;
  }
  
  public Cfg(Config config) {
    config.checkValid(Config.parseMap(
      Map.of(
        "service", Map.of(
          "debug", false, // the value doesn't matter, only the type
          factor, 0.0,
          poolSize, (int) 0,
          url, "",
        )
    ));

    // initialize `Cfg` if an exception was not thrown
  }
}

Broadly speaking, besides specific types for the fields, a variety of other attributes could be associated to the elements in a configuration spec:

• mark a section as optional
• indicate that the value for a field is a password or similar sensitive piece of information such that it's omitted (or shown in some special fashion) by the generated toString method
• have the generated toString method to skip a field or section
• indicate restrictions (like valid ranges for numeric values)
• etc.

Although some of this could be addressed via some extended syntax to the type (in the case of fields at least), a typical "annotation" approach would be more flexible.

The annotation syntax would be special comment lines, for example:

main {
  # Mail server properties if you want to enable notifications to users
  #@optional
  email {
    server: string

    #@password
    password
  }
  ...
}

For example I use non ascii

// 测试 is test in Chinese.
test = "测试" 

The generator complains:

Exception in thread "main" java.nio.charset.MalformedInputException: Input length = 1
	at java.nio.charset.CoderResult.throwException(CoderResult.java:281)
	at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:339)
	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
	at java.io.InputStreamReader.read(InputStreamReader.java:184)
	at java.io.BufferedReader.read1(BufferedReader.java:210)
	at java.io.BufferedReader.read(BufferedReader.java:286)
	at java.io.Reader.read(Reader.java:140)
	at scala.io.BufferedSource.mkString(BufferedSource.scala:96)
	at tscfg.Main$.generate(Main.scala:133)
	at tscfg.Main$.main(Main.scala:54)
	at tscfg.Main.main(Main.scala)

Maybe something wrong with the default charset tscfg uses?
My file is in UTF-8.

Example:

lists {
  names: [ string ]
  positions: [
    {
      lat: "double"
      lon: "double"
    }
  ]
}

denotes that:

• names is a list of strings
• positions is a list of objects {lat, lon}.

Since this is for purposes of the spec itself, the given list should have only one element. A warning can be generated in case additional elements (which will be ignored) are included.

After their introduction, we found shared objects very useful in our configuration setup. Based on our experience working with shared objects, we would highly appreciate the availability of some kind of basic inheritance for shared object definition. Especially from the scala config perspective, this would reduce code duplicates when working with several shared object definitions that have one or more fields in common because one could pattern match against them.

I have not thought about all details yet, because I'm unsure if this a feature that could be of interested to be included, but my first idea was something like:

#@define_pa
BaseModelConfig {
  uuids: [string]         
  scaling: double  
}

#@define
LoadModelConfig ex BaseModelConfig{
  modelBehaviour: string  
  reference: string       
}

#@define
FixedFeedInModelConfig ex BaseModelConfig

This would end up in either a sealed trait or an abstract class (whatever is easier) in the generated code (only thought about scala for now, maybe slightly different concept needs to be developed for java code):

  sealed trait BaseModelConfig {
    val scaling: scala.Double
    val uuids: scala.List[java.lang.String]
  }

  final case class LoadModelConfig(
                              scaling: Double,
                              uuids: List[String],
                              modelBehaviour: java.lang.String,
                              reference: java.lang.String
                            ) extends BaseModelConfig

  object LoadModelConfig {
    def apply(
               c: com.typesafe.config.Config,
               parentPath: java.lang.String,
               $tsCfgValidator: $TsCfgValidator
             ): SimonaConfig.LoadModelConfig = {
      SimonaConfig.LoadModelConfig(
        scaling = $_reqDbl(parentPath, c, "scaling", $tsCfgValidator),
        uuids = $_L$_str(c.getList("uuids"), parentPath, $tsCfgValidator),
        modelBehaviour =
          $_reqStr(parentPath, c, "modelBehaviour", $tsCfgValidator),
        reference = $_reqStr(parentPath, c, "reference", $tsCfgValidator)
      )
    }

    private def $_reqStr(
                          parentPath: java.lang.String,
                          c: com.typesafe.config.Config,
                          path: java.lang.String,
                          $tsCfgValidator: $TsCfgValidator
                        ): java.lang.String = {
      if (c == null) null
      else
        try c.getString(path)
        catch {
          case e: com.typesafe.config.ConfigException =>
            $tsCfgValidator.addBadPath(parentPath + path, e)
            null
        }
    }

    private def $_reqDbl(
                          parentPath: java.lang.String,
                          c: com.typesafe.config.Config,
                          path: java.lang.String,
                          $tsCfgValidator: $TsCfgValidator
                        ): scala.Double = {
      if (c == null) 0
      else
        try c.getDouble(path)
        catch {
          case e: com.typesafe.config.ConfigException =>
            $tsCfgValidator.addBadPath(parentPath + path, e)
            0
        }
    }
  }

final case class FixedFeedInModelConfig(scaling: Double, uuids: List[String]) extends BaseModelConfig

  object FixedFeedInModelConfig {
    def apply(
               c: com.typesafe.config.Config,
               parentPath: java.lang.String,
               $tsCfgValidator: $TsCfgValidator
             ): SimonaConfig.FixedFeedInModelConfig = {
      SimonaConfig.FixedFeedInModelConfig(
        scaling = $_reqDbl(parentPath, c, "scaling", $tsCfgValidator),
        uuids = $_L$_str(c.getList("uuids"), parentPath, $tsCfgValidator),
      )
    }

    private def $_reqDbl(
                          parentPath: java.lang.String,
                          c: com.typesafe.config.Config,
                          path: java.lang.String,
                          $tsCfgValidator: $TsCfgValidator
                        ): scala.Double = {
      if (c == null) 0
      else
        try c.getDouble(path)
        catch {
          case e: com.typesafe.config.ConfigException =>
            $tsCfgValidator.addBadPath(parentPath + path, e)
            0
        }
    }
  }

This is a first draft of the concept for now but I hope the general idea becomes clear. Looking forward to read what you think about it.

Cheers,

Johannes

tl;dr

• inheritance for shared objects
• added final modifier to scala case classes for scala best practices 🤓

We've been using Typesafe-Config at work in a few projects now and we really like it; we've actually written very similar boilerplate code to what this library generates, and now having stumbled across it I'd like to use it instead.

However, because we've been using Config directly, all we have are actual config files that act as both reference/template and default; I am aware they can be used directly as specs for codegen with this tool but it generates code that assumes any given values in the config files are the defaults when I would like to just have them all be required values (so if they're modified later but a key is omitted or mistyped it throws an error instead of falling back to default).

I see this has already been sort-of discussed in #43 but I would say this is the "application" workflow that was mentioned; I would like to just use the default config as the spec, otherwise it's two separate files to keep in sync with each other with duplicated structure but one contains types while the other contains values.

I think this could be implemented as a flag like --assume-all-required or something which doesn't pull default values from the spec; it just uses them to infer the types of the fields.

with API documentation, etc. So far, that "API" is the tscfg.Main.main method with documentation being the usage message printed out by that method.

Related: #24

When trying to use v0.9.95, I am getting a no main manifest attribute error.

I am invoking it the same way as v0.9.94, which works fine:
java -jar /tscfg-0.9.95.jar

Make it more modularized, readable, easily expandable.

With

issue {
  optionalFoo = "string?"
}

the generated scala code:

// generated by tscfg 0.3.3 on Tue Aug 30 16:10:01 PDT 2016
// source: example/issue13.conf

package tscfg.example

object ScalaIssue13Cfg {
  object Issue {
    def apply(c: scala.Option[com.typesafe.config.Config]): Issue = {
      Issue(
        c.map(c => if(c.hasPathOrNull("optionalFoo")) Some(c.getString("optionalFoo")) else None).get
      )
    }
  }
  case class Issue(
    optionalFoo : scala.Option[java.lang.String]
  ) {
    override def toString: java.lang.String = toString("")
    def toString(i:java.lang.String): java.lang.String = {
      i+ "optionalFoo = " + this.optionalFoo + "\n"
    }
  }
...

does not compile:

[error] ...src/main/scala/tscfg/example/ScalaIssue13Cfg.scala:14: double definition:
[error] def apply(c: Option[com.typesafe.config.Config]): tscfg.example.ScalaIssue13Cfg.Issue at line 8 and
[error] case def apply(optionalFoo: Option[String]): tscfg.example.ScalaIssue13Cfg.Issue at line 14
[error] have same type after erasure: (c: Option)tscfg.example.ScalaIssue13Cfg.Issue
[error]   case class Issue(
[error]              ^
[error] one error found

When I define the following in my config spec:

userIds: [string] // ok
userIds: "[string]" // quotes -> result in regular String type instread of List<String>

I wonder if this is expected behaviour?

With a configuration "spec" input like this

foo {
  clone     = ".."
  finalize  = ".."
  getClass  = ".."
  notify    = ".."
  notifyAll = ".."
  toString  = ".."
  wait      = ".."
}

The Scala output would be:

...
case class Foo(
    clone     : String,
    finalize  : String,
    getClass  : String,
    notify    : String,
    notifyAll : String,
    toString  : String,
    wait      : String
  ) { ...

This does not compile:

• these names collide with corresponding no-args methods in Object class
• actually for toString this is a method already being overridden in the body of the case class

I ran across this issue when running the tool on a real application having notify in its configuration. So, in general, these "special" names should be transformed in some way in the generated code to avoid the collision (e.g., with a trailing underscore).

(Note that this is not an issue in the Java output case.)

Quoted keys are not properly handled, eg:

"do log" : boolean
"$_foo"  : baz

Configuration templates are often a means to provide end users with a description of the properties that should be set for the proper operation of an application or library. Based on the template, end users will then enter the concrete settings that are appropriate.

On the other hand, configuration "specs," as used for tscfg generation, are mainly intended to be used by the developer of such application or library.

The proposal here is about adding an option to also generate a template configuration file from the given spec so the developer does not have to manually create/edit such templates.

For example, from the spec

# Some description of the endpoint section 
endpoint {
  # The path associated with the endpoint
  path = "string"

  # Port where the endpoint service is running
  port = "int | 8080"

  # Email to send notifications to. If missing, no emails are sent.
  email = "string?"
}

the generated template could look something like

# Some description of the endpoint section 
endpoint {
  # 'path': Required string.
  # The path associated with the endpoint
  path =   

  # 'port': Optional integer. Default value: 8080
  # Port where the endpoint service is running
  #port =

  # 'email': Optional string.
  # Email to send notifications to. If missing, no emails are sent.
  #email = 
}

Mit config.getDuration("path") bekommt man eine java.time.Duration.
Es wäre schön, wenn tscfg darauf erweitert werden könnte und anstatt eines Longs eben die Duration (java8 oder neuer) zurückliefert.

First of all, I'd like to thank you for this library. This makes mapping Typesafe config files to objects a breeze!

I'm noticing an issue with the string-to-bytes conversion. If I specify a large number, such as:

memory: 50G

The resulting code is generated as:

memory = if(c.hasPathOrNull("memory")) c.getBytes("memory") else 53687091200

The compiler then throws an error saying 53687091200 is outside the range of Int. If I convert this to a long (53687091200L), it works. But this adds a manual element to the code generation; I must now manually fix this every time I use tscfg regenerate the code.

A ref: https://github.com/lihaoyi/mill/tree/master/contrib/scalapblib

Similar to #5 but with standard types:

String.bar  = "baz"
Option.bar  = "baz"
Boolean.bar = "foo"
int.bar     = 1

will generate incorrect code due to conflicts with standard types: java.lang.String, scala.Option, etc.

I am unable to mock generated Conf class for testing with Mockito even after enabling mocking final classes/methods in Mockito.

This is failing with Mockito.when(...).thenReturn(...);
I am guessing this is because Mockito can mock only method calls.