Huge thread, so I'll stick to the format question for now, see inline. On Wed, Dec 24, 2014 at 9:56 AM, Oliver B. Fischer <[email protected] > wrote:
> See inline... > Am 24.12.14 um 02:07 schrieb Anatole Tresch: > >> 3.) Should we define any configuration formats, and if so which one? >> *-> I would like to see a minimal set of formats in core, so we can >> provide a minimal dependency version that fits most needs. >> .properties, >> .xml(properties) and .ini I think is a good set, but definitively not >> more.* >> *-> We can then leverage apache commons config with bridges in the >> extension modules for suporting additional formats ;). * >> > > At my company we use mostly https://github.com/typesafehub/config/blob/ > master/HOCON.md and YAML. For me only property files and the other > mentioned formats feel a little bit outdated. Not only because they exist > already for a long time but for their usability. > > Writing large configurations is mostly about structuring the information > you provide. In this area are property files weak and no one wants XML > again. If I would tell this someone around me the answer would be: "Come > back if you have something more usefull." > > In one of the largest clouds outside the infrastructure of the likes of Google, Amazon, Microsoft, etc. (on top of Kokki/Multiconf) we used JSON and some components also used YAML. However, these are just the DevOps duties like build management and processing with some management, provisioning and monitoring of the actual servers, too. When it comes to configuration of various Enterprise Containers and Java EE applications to be deployed there in all the various stages, XML rules. And those who really think for the actual Java part everything can be done purely with annotations probably also insist, Santa is coming through their chimney tonight ;-D Purely annotation based solutions are nice to do quick demos, but if you need true staging all the way from your local development box to a giant cluster in production, at least the server and containers requires loads of XML to provision it correctly for each container, and without touching and changing the code for every step, there is practically no production ready app servers today supporting that, even if the app may truly be written just with annotations supporting everything from local dev boxes to production, then the slightest change in each of these phases would still break everything. And those large cloud solutions by big vendors normally get deployed by others that are not supposed to build and compile your app again;-) OSGi sounded promising also for EE containers, but Glassfish (which had some good support for it) is merely the Java EE RI now and JBoss WildFly also removed it. So dynamic loading and injection of components at runtime becomes harder. I also looked into HOCON which is a nice approach, though a bit limited. Fortunately, what it admits to be missing, Java is getting as a standard these days, a unit subsystem (JSR 363). On the monitoring front, Parfait https://code.google.com/p/parfait/ shows how the earlier JSR (275) is used for support of MB, GB, etc. but also other vital signs of the system if needed like temperature (seamless and typesafe whether it's °C or F;-) US Smart Grid vendor Opower wrote a JSON binding solution around Unit-API (0.6, the "missing link" betweeen 275 and 363) so supporting formats like JSON for data exchange also works. There's an upcoming JSR for JSON-B, so maybe under Java EE 8 or with this on its own, you may use Java EE standards there, too, until then alternatives like Jackson or GSON, do, too. Merry Christmas, Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory Board Member, DWX '15 Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap | #EclipseUOMo | #DevOps Skype werner.keil | Google+ gplus.to/wernerkeil
