I'd like to know what is the most efficient way of handling properties in Scala. I'm tired of having gazillion property files, xml files and other type of configuration files in Java and wonder if there's "best practice" to handle those someway more efficient in Scala?
+3
A:
Why would you have a gazillion property files?
I'm still using the Apache commons Digester, which works perfectly well in Scala. It's basically a very easy way of making a user-defined XML document map to method calls on a user-defined configurator class. I find it extremely useful when I want to parse some configuration data (as opposed to application properties).
For application properties, you might either use a dependency injection framework (like Spring) or just plain old property files. I'd also be interested to see if Scala offers anything on top of this, though.
oxbow_lakes
2009-06-08 08:12:56
+1
A:
Check out Configgy which looks like a neat little library. It includes nesting and change-notification. It also include a logging library.
Unfortunately, it didn't compile for me on the Mac instances I tried. Let us know if you have better luck and what you think...
Update: solved Mac compilation problems. See this post.
DrGary
2009-06-08 17:42:49
+3
A:
Quoting from "Programming in Scala":
"In Scala, you can configure via Scala code itself."
Scala's runtime linking allows for classes to be swapped at runtime and the general philosophy of these languages tends to favour convention over configuration. If you don't want to deal with gazillion property files, just don't have them.
George
2009-06-09 12:17:31
I'm not seeing how that answers the question. Could you expand?"Swapping at runtime" seems to imply configuration by dynamically responding to the runtime environment. But many configuration parameters are unknown to the runtime, such as DB passwords or which admin gets error emails. We could talk about service-discovery mechanisms, but that's overkill for small projects and they'll have their own configuration parameters, kicking the question downhill.At some point, you need to provide input to your program. If you organize it into key/value pairs, you have property files...
DrGary
2009-06-09 16:26:17
For environment-specific settings (which really should be the only ones that are externalised) you can get system properties like in Java, like this:val databaseName = System.getProperty("myapp.db.name").You then configure these in your startup script and give them to the runtime like so:java -Dmyapp.db.name=DeeBee MainClass. As for passwords, you probably shouldn't have those in files, though, may be you can have your app prompt you when it starts up.
George
2009-06-11 11:49:42