github-repos/config
1
0
Fork 0
mirror of https://github.com/lightbend/config.git synced 2025-01-15 23:01:05 +08:00
Code Issues Packages Projects Releases Wiki Activity
388d85fb5d
config/NEWS.md
Havoc Pennington 388d85fb5d Serialization-pocalypse: change serialization format 
The previous use of Java's default serialization dumped
all implementation-detail class names and fields into the serialization,
making it basically impossible to improve the implementation.

Two strategies here:
 - prohibit serialization of unresolved configs, which are
   the location of a lot of implementation detail
 - delegate all serialization to an Externalizable
   SerializedConfigValue class, which serializes
   using fields that have lengths. Unknown fields
   can thus be skipped and we can write code to
   support obsolete fields, and so on.

As a side effect, this makes the serialization far more compact
because we don't need the Java per-class header noise, and we
jump through some hoops to avoid writing out duplicate ConfigOrigin
information. It still isn't super-compact compared to something
like protobuf but it's a lot less insane.
2012-04-12 13:04:14 -04:00

3.5 KiB
Raw Blame History

0.NEXT.0: Sometime

  • the serialization format has changed to one that's extensible and lets the library evolve without breaking serialization all the time. The new format is also much more compact. However, this change is incompatible with old serializations, if you rely on that. The hope is to avoid serialization breakage in the future now that the format is not the default Java one (which was a direct dump of all the implementation details).
  • serializing an unresolved Config (one that hasn't had resolve() called on it) is no longer supported, you will get NotSerializableException if you try.
  • supports self-referential substitutions, such as path=${path}":/bin", by "looking backward" to the previous value of path
  • supports concatenating arrays and merging objects within a single value. So you can do path=${path} [ "/bin" ] for example. See README and spec for more details.
  • supports += where path+="/bin" expands to path=${?path} [ "/bin" ]
  • supports include url("http://example.com/"), include file("/my/file.conf"), and include classpath("whatever"). This syntax forces treatment as URL, file, or classpath resource.
  • supports include "http://example.com/whatever.conf" (if an include is a valid URL, it's loaded as such). This is incompatible with prior versions, if you have a filename that is also a valid URL, it would have loaded previously but now it will not. Use the include file("") syntax to force treatment as a file.
  • class loaders are now recursively inherited through include statements; previously, even if you set a custom class loader when parsing a file, it would not be used for parsing a classpath resource included from the file.
  • parseString() and parseReader() now support include statements in the parsed string or reader
  • in -Dconfig.resource=name, name can start with a "/" or not, doesn't matter
  • if you implement ConfigIncluder, you should most likely also implement ConfigIncluderFile, ConfigIncluderURL, and ConfigIncluderClasspath. You should also use ConfigIncludeContext.parseOptions() if appropriate.
  • cycles in include statements (self-includes) are now detected and result in a nicer error instead of stack overflow
  • since 0.3.0, there is an obscure incompatible semantic change in that self-referential substitutions where the cycle could be broken by partially resolving the object now "look backward" and may fail to resolve. This is not incompatible with the version included in Play/Akka 2.0 because in that version this obscure case just threw an exception. But in 0.3.0 there were cases that worked that now work differently. You are very unlikely to be affected by this.

0.3.0: March 1, 2012

  • ConfigFactory methods now use the thread's context class loader by default, and have overloads so you can specify a class loader. Because jars may come with "reference.conf" in the jar, a config must always be loaded with the same class loader as the jar using the config.
  • ConfigValue instances are now serializable
  • new methods ConfigObject.withoutKey, ConfigObject.withOnlyKey, Config.withoutPath, Config.withOnlyPath allow subsetting configs more easily.
  • better handle complex interdependent substitutions (the ${foo} syntax) without getting confused; just about anything that makes conceptual sense should now work. Only inherently circular config files should fail.
  • some minor documentation fixes.