As best as I can tell from reading this thread, there is no clear winner. I would recommend you guys hold a vote first before making any changes requested within here.
On Wed Dec 24 2014 at 10:30:36 AM Werner Keil <[email protected]> wrote: > 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 >
