SimpleDateFormat variable expansion, is it possible?

[drapostolos]

I would like to define a Config interface like this:

public interface Configuration extends Config {
    @DefaultValue("${user.home}${file.separator}${date:yyyyMMdd-HHmmssSSS}")
    String logDirPath();
}

where

    public static void main(String[] args) throws Throwable {

        Configuration cfg = ConfigFactory.create(
                Configuration.class,
                System.getProperties());
        System.out.println(cfg.logDirPath());
        System.out.println(cfg.logDirPath());
    }

prints the expected output:

C:\Users\alex\20141018-163934471
C:\Users\alex\20141018-163934471

Where theX in "${date:X}" represent any pattern as used by java.text.SimpleDateFormat.

More generally, it would be nice to be able to register custom substitutors. Something like this

public interface Configuration extends Config {
    @SubstitutorClasses(names = {"date", "xyz"}, classes = {DateSubstitutor.class, XyzSubstitutor.class})
    @DefaultValue("${user.home}${file.separator}${date:yyyyMMdd-HHmmssSSS}")
    String logDirPath();
}

Could this be a possible feature for OWNER in the future?

[lviggiano]

This looks as an interesting add.

[drapostolos]

I'll submit a pull request as soon as I get the time.

[lviggiano]

Define some junit tests first to show how this shall be used. I'd like to
see some preview on how you would design such feature, abd how that should
work.
Il 22/ott/2014 23:32 "Alexander Poulikakos" [email protected] ha
scritto:

I'll submit a pull request as soon as I get the time.

—
Reply to this email directly or view it on GitHub
#104 (comment).

[lviggiano]

I mean, from your example:

public interface Configuration extends Config {
    @DefaultValue("${user.home}${file.separator}${date:yyyyMMdd-HHmmssSSS}")
    String logDirPath();
}

${date:...} comes from a property file, so it's already a string, why would you format that differently if you can specify that properly on the first place?

Registering a custom substitutor may be interesting, though I'd like to see a test case to figure out how the feature would work.

Try to design a simple API for that: adding complexity adds overhead on other important features that are still missing. But also, once we introduce something in the API, I'd like to have some clean+simple+powerful api, so we don't need to change the feature later (breaking backward compatibility).

[drapostolos]

Just added a pull request for this, containing only the unit tests. See #108

[drapostolos]

Updated the pull request #108 with the actual implementation.

[lviggiano]

I'll look into it asap

[drapostolos]

FYI This feature is inspired by a similar feature in apache commons configuration (which I have found useful).
See this chapter in their User Guide.

[drapostolos]

Any comments on this?

/Alex

[lviggiano]

I didn't had time to study this in deep, yet. I think I got a general understanding, but not a complete idea on this.

Unfortunately I am working on this project on my spare time.
There is no schedule that I am following, so I can't give an estimation on when this task will be accomplished.

[drapostolos]

Fair enough. Just wanted to be sure you haven't forgotten about it. Will remind you again in a month or two.

/Alex

[drapostolos]

just a friendly reminder about this.