tag:blogger.com,1999:blog-741750605858169835.post659220810594417186..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Configuration in Java - It sure beats XML!Stephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-741750605858169835.post-62529393995030170872007-03-14T16:52:21.000+00:002007-03-14T16:52:21.000+00:00Once I worked on a 'configuration service'...Once I worked on a 'configuration service' for a Java distributed system. The system modules communicated with each other through a popular middleware (it wasn't SOA, the nature of those processes was different). Every module had several own config (xml) files (2 or 3, it depended on a module type). The system had to check its health at init stage before 'switching' into its production mode.<br /><br />XML config files in that case simply didn't work - ideally, I needed those files to be able to communicate to each other in order to check their corresponding values, exchange with their modules' test results, write the log, etc. Eventually I did it but with XML parsers/builders and XSD validation overhead. Those XML files had to be Java classes from the very beginning. And not just ordinary value holders but able to encapsulate a required behaviour.<br /><br />About IoC and text files: yeah, the note above makes sense. But why not to keep Java classes in files, let's say, with *.javat extension (java-text) as text files without compiling until they are requested by the runtime? A typical webapp does that for JSPs (off cause, unless they have not been compiled beforehand). If such an extension added to javac/jre, xml config files will have to go...<br /><br />About XML gurus: I've already seen a position of XML Architect advertised somewhere! XML does become more complicated. But will it ever have more power than OO language anyway?<br /><br />About non-programmers changing config XMLs: never seen it before. If it's the case, how many programmers would be on-call before, during and after the change made? :)Ivannoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-31792032573065710272007-03-13T12:43:18.000+00:002007-03-13T12:43:18.000+00:00"Petite already does this"
Dunno, what ..."Petite already does this"<br /><br />Dunno, what it seems to do is automatic registration of beans, but I couldn't find anything related to initialization and the automatic recompilation of source files as suggested by Stephen.quintessenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-14988859288533938932007-03-13T10:12:39.000+00:002007-03-13T10:12:39.000+00:00Petite already does this:
http://jodd.sourceforge....Petite already does this:<br />http://jodd.sourceforge.net/doc/petite.htmlAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42368718500706933772007-03-13T07:10:30.000+00:002007-03-13T07:10:30.000+00:00"Anyway, its good to know that I'm not al..."Anyway, its good to know that I'm not alone in finding XML frustrating"<br /><br />Well, personally I don't find XML frustrating at all because I still remember how (complex) configuration files were written before XML came along (see Apache). Basically eveybody made up his own format and wrote his own parsers, preferrably a different one for each project and I definitely don't want to go back to those times.<br /><br />But it doesn't mean I'm not open for better and more elegant solutions for specific problems if somebody can come up with them.quintessenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-12597827105299716842007-03-12T23:16:03.000+00:002007-03-12T23:16:03.000+00:00Thanks for all the great feedback! There's too...Thanks for all the great feedback! There's too much for individual replies, but I'd like to agree with the sentiment that "XML is code" and not very fun code to work with either.<br /><br />The point about needing to update the configuration using an online tool is well-made too, so anyone writing a configuration tool off the back of this blog would need to take this into account too.<br /><br />Finally, there were a couple of replies that missed the point of the blog. My argument is that a .java file *is* a text file capable of storing configuration. The only real differences are that you have to declare a class and method at the top/bottom (but you have headers and footers in XML too), and you have to compile the file before use. My point was that we need a configuration framework that can make the compilation and re-load part transparent. I want a tool where a .java file can be treated just like an xml file, such that it doesn't require a rebuild of the main jar/war/ear to pickup the changes.<br /><br />Anyway, its good to know that I'm not alone in finding XML frustrating.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-60374185718885703522007-03-12T21:16:36.000+00:002007-03-12T21:16:36.000+00:00"@Jordan: well, a possible (but undoubtedly s..."@Jordan: well, a possible (but undoubtedly silly) solution would be to use Spring to handle your configuration normally..."<br /><br />Spring's "dependency injection" seems heavy-handed and unnecessary to me. At the end of the day, it's just calling Class.forName and passing some parameters (sorry if this is a crude summary, I'm by no means a Spring expert).Jordan Zimmermanhttp://www.jordanzimmerman.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-6088015779682181602007-03-12T21:13:45.000+00:002007-03-12T21:13:45.000+00:00Blogreader asks: How do you do IoC? Or do you? How...Blogreader asks: How do you do IoC? Or do you? How do you unit test just the individual layers of MVC that you're working on? What alternative do you have?<br /><br />I believe it is a very bad idea to specify coupling in a configuration file. The Spring/IoC approach is a major mistake from what I know about it. The current trends in architecture are very disturbing to me. Architects today are going out of their way to hide logic and obfuscate relationships. I want to see the coupling directly in the debugger. I don't want to have to wade through config files to figure it out. The demos I've seen where someone very proudly makes one change in an XML file and the behavior of the app changes scares me instead of impressing me.Jordan Zimmermanhttp://www.jordanzimmerman.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-63338135636044055912007-03-12T20:01:48.000+00:002007-03-12T20:01:48.000+00:00I have a class called Context. It gets passed to ...I have a class called Context. It gets passed to every object during construction, if some of its members are needed by the object. It also gets passed to every static method as the first parameter if the static method needs some of its members.<br /><br />It's an emulation of Lisp special variables, though I started using it before I knew what those were.<br /><br />Only in two places do I construct a Context; a) in the 'main' for the application, and b) at the start of every automated test that needs a Context.<br /><br />I don't need to provide a way for non-programmers to reconfigure my application - and if I did, I'd do it by reading a property file, without really minding what format is used.<br /><br />I think Lisp as data looks better than XML, even for non-programmers.Ricky Clarksonhttp://cime.net/~ricky\noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42000213792499523272007-03-12T17:40:30.000+00:002007-03-12T17:40:30.000+00:00To elaborate a bit more on my last remark. Imagine...To elaborate a bit more on my last remark. Imagine you have:<br /><br />class ConnectionConfig {<br /> public String host;<br /> public int port;<br />}<br /><br />you could image that instead of having some kind of property or xml file you could have something like:<br /><br />class ConnectionConfigInitializer {<br /> public void configure(ConnectionConfig config) {<br /> config.host = "example.org";<br /> config.port = 1234;<br /> }<br />}<br /><br />(although a better way might need to be found for complex configuration with sub-objects and lists/arrays)<br /><br />The problem I see is that even with good use of annotations on the Config bean to add things like validation and maybe hints as to the precise domain of the needed values I think it would be very difficult to make configuration editors that could easily edit that kind of files (lots of apps have configuration interfaces, they should be able to write the values back to the file).<br /><br />And of course configuration files are often edited by people who don't use IDEs (users or administrators) or in situations where you have no access to those tools (on production servers) so that's another advantage of this format that you won't be able to use often in practice.<br /><br />Dunno, the longer I think about it the less convinced I am that this could actually work well. Somebody had better come up with some pretty convincing use-cases and examples :-)quintessenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-50319231698725300542007-03-12T17:24:29.000+00:002007-03-12T17:24:29.000+00:00i also believe it is easier for the programmer to ...i also believe it is easier for the programmer to configure with the help of the IDE, eg. in Java, i mean thats what i do. If a sysadmin might need to override defaults then one can use XMLEncoder to export as a file, and XMLEncoder to import the config object, or use JAXB, or inject resources from a properties file, possibly driven by annotations.evanxhttp://aptframework.dev.java.netnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-8654587442528105902007-03-12T17:07:10.000+00:002007-03-12T17:07:10.000+00:00@ejboy: mixing scripting and compiled languages? I...@ejboy: mixing scripting and compiled languages? I didn't know I was suggesting such a thing? Do you mean I was confusing them? Either way I don't agree, it was just an example of languages that use their existing syntax to do configuration. I'm aware that you can't just do the same in Java but it might be worth considering.<br /><br />@Jordan: well, a possible (but undoubtedly silly) solution would be to use Spring to handle your configuration normally, maybe by having it create the Config objects (beans) and passing (inserting) them (in)to the objects that need them. But instead of using the Spring xml configuration files to set the Config bean's values you could have it create special Config Initializer beans that can be edited at any moment and recompiled and reloaded by the framework.quintessenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-64247809970549224142007-03-12T16:33:53.000+00:002007-03-12T16:33:53.000+00:00Jordan: [ When moving to XML you are substituting ...Jordan: [ When moving to XML you are substituting a great language with great tools (Java) for an inferior language with inferior tools. ]<br /><br />I'm not sure what you mean by that. With how I use Spring and IoC is that I remove hard coding into my classes a way of connecting to a database, or putting into my classes some JNDI lookup with a magic value to get that back. This forces you to code to interfaces which is what you should be doing anyway.<br /><br />How do you do IoC? Or do you? How do you unit test just the individual layers of MVC that you're working on? What alternative do you have?BlogReadernoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-88826087381019682652007-03-12T15:03:24.000+00:002007-03-12T15:03:24.000+00:00To afsina,
Annotations perfectly solves the proble...To afsina,<br />Annotations perfectly solves the problem you desribe and they are supported by Spring, EJB3 and others quite a long time...<br />Typical example is transaction attributes.ejboyhttp://jroller.com/page/ejboynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-81350787876905288192007-03-12T14:36:10.000+00:002007-03-12T14:36:10.000+00:00well, i think author gave a bad example and the co...well, i think author gave a bad example and the commenters missed the point.<br />The example given is not suitable for having it in the java class, it is suitablefor for an external "property" file. the idea shoud be replacing application logic related configurations (like Spring bean configurations, struts configurations, hibernate configurations ) that non programmer people cannot touch anyway. not the simple property file type parameters...afsinanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-44836871125984466332007-03-12T14:32:12.000+00:002007-03-12T14:32:12.000+00:00It is not correct to say that XML does not provide...It is not correct to say that XML does not provide auto-completion. Any modern XML editor should be able to use a XSD to validate the XML on-the-fly and provide auto-completion. What is more, with XML and XSLT you can provide a nice, easy to read view of your configuration. <br /><br />Besides, anything can get unwieldy, Java interfaces uncluding. Configuration files are another kind of user interface that should be designed with care, for its use scenarios.Yuri M.noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-85395419309295852002007-03-12T13:38:37.000+00:002007-03-12T13:38:37.000+00:00To Rafael Chaves,
Great example!
To quintesse,
Pl...To Rafael Chaves,<br />Great example!<br /><br />To quintesse,<br />Please, don't mix scripting languages with static typed/compiled ones. I've seen configuration.php many times and this is OK because the content is intuitive and does not require recompilation. <br /><br />P.S. JSP also allows dynamic configuration from Java in a PHP way, i.e.:<br /><%<br /> Config.userNameMinLength = 6;<br /> Config.userNameMaxLength = 20<br />%>ejboyhttp://jroller.com/page/ejboynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-59069751814994605062007-03-12T12:12:06.000+00:002007-03-12T12:12:06.000+00:00For those who don't remember, EJB 1.0 did not ...For those who don't remember, EJB 1.0 did not have XML configuration files. Deployment descriptors were serializable Java classes.Rafael Chaveshttp://the.modelprogrammer.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-85716387126494446832007-03-12T10:39:15.000+00:002007-03-12T10:39:15.000+00:00I don't think there is anything wrong perse wi...I don't think there is anything wrong perse with using Java for configuration purposes, lots of languages, especially the more "script-like" ones do this all the time.<br /><br />You have to take care with deployment though. The configuration classes should not be part of the main body of code or otherwise an upgrade will wipe your settings. In fact I think they should be left out of the normal packages entirely.<br /><br />Maybe some structure where the default implementation (with the default values) is part of the normal source packages with some kind of generic mechanism to override that class with your own version.<br /><br />I do see a problem in situations where several modules might be using different versions of the same configuration class. With text/xml files it's easy to make them more robust so you can easily add and/or remove values from them without everything falling over. With classes that will not be possible I think.quintessenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-33631794678005980452007-03-12T09:58:47.000+00:002007-03-12T09:58:47.000+00:00I also think that the right solution is in the mid...I also think that the right solution is in the middle... :-)<br /><br />1) I think the constant values that must be easily modified by a Sysadmin or a final user (host, port, log level, etc.) should reside in a config file, be it XML or ".properties". IMHO, it doesn't make sense to force the sysadmin or user to recompile and app just to change the port number, for instance.<br /><br />2) On the other hand, I'm against having a config file for the application architecture: which implementations of classes to use, how to connect them with each other, whether a class should be a singleton or not, ... I think changing those things deserve a recompilation and further testing , they're not so frequent and they don't need to be modified by a Sysadmin or a final user.<br /><br />In big apps, it's useful and maintainable to centralize the dependencies code (which belong to the app architecture), but I prefer to do it with code itself, not with XML files. So I wholly embrace the Guice solution, which allows to centralize the dependencies easily, but with code and more type safety.<br /><br />Regards,<br /><br /> XaviXavi MirĂ³noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-2485401272472037702007-03-12T08:29:50.000+00:002007-03-12T08:29:50.000+00:00How about having .xml.java and/or .xml.class files...How about having .xml.java and/or .xml.class files next to the .xml files. They must be implementing an interface that outputs XML as text. Then:<br /><br />1) The framework can look for these files and generate the XML on the fly.<br />2) You can have an Ant task generate the XML for frameworks that doesn't know about this yet.<br />3) Have a running service that constantly reads the .xml.java/.xml.class files and generate the XML. This is for frameworks that both doesn't know about this new feature and needs for instance web.xml during the development (like Studio Creator).<br /><br />This mean that you can have type checked Java code that is your configuration, AND it would be child's play for all the frameworks to support it (which isn't even needed during a transition phase). Something like this for web.xml:<br /><br />in a file called "web.xml.java"<br />addServlet(MyServlet.NAME, MyServlet.class, true);<br />addServletMapping(MyServlet.NAME, "*.jsp");<br /><br />There can of course be a lot of nice feature included with this, like merging the new XML with what's in the original xml file and what not.<br /><br />How about it?<br /><br />Cheers,<br />Mikael GrevMikael Grevhttp://www.migcalendar.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-53888862332129592342007-03-12T07:34:21.000+00:002007-03-12T07:34:21.000+00:00Several years ago XML gurus told us that configura...Several years ago XML gurus told us that configuration/markup and business logic - everything should be in XML. Now we have an inverted situation. In my personal view both are wrong and the truth is in the middle (very close to Spring :)<br /><br />P.S. You can also use Java debugging hot-swap to change configuration parameters at runtime ;)ejboyhttp://jroller.com/page/ejboynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-43274392559034451412007-03-12T05:16:31.000+00:002007-03-12T05:16:31.000+00:00Totally with you on the configuration framework id...Totally with you on the configuration framework idea, I have wanted that since the bloody beginning of enterprise Java. Sun is so bizarre. They made one of the biggest config disasters in all of history (EJB), then they have spun out JSRs on all manner of trivial matters, and when we want to change a property, we have to explode an ear, change it, then jar the mess back up and redeploy. As for your 'maybe it already exists,' well, it kind of does: JMX can do all this and more. You don't even need a restart. The newest JMX in JDK 6 finally delivers on some of the congenital midgetry that was originally baked in. Furthermore, instrumentation can be done now in very compelling and flexible ways: some annotations, some aspects, etc.<br /><br />As for your example, I know you were saying ignore it, but in fact, ironically, the first thing that came to mind was constraints: another gaping hole in the Java landscape, but like the other one: a hole that can now be patched. Things like mins and maxes should be done w/annotations DbC style. Checkout Contract4J for that. You would still need to write some code to use them, but that's not a problem.Robhttp://jroller.com/page/robwilliamsnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-18907790154161666822007-03-12T03:40:25.000+00:002007-03-12T03:40:25.000+00:00If the idea is so that you do not recompile, then ...If the idea is so that you do not recompile, then I say simple text property files also meet that requirement.Bernard Choinoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-59537297132519378852007-03-12T03:27:38.000+00:002007-03-12T03:27:38.000+00:00XML is a disease. Today's hip young programmer...XML is a disease. Today's hip young programmers are falling over themselves to show how they can avoid compiling and writing code as if that were a good thing. Well, guess what - XML is code. It must be developed, maintained and deployed. When moving to XML you are substituting a great language with great tools (Java) for an inferior language with inferior tools. The quicker this illness passes, they better.Jordan Zimmermanhttp://www.jordanzimmerman.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-40371671632773563792007-03-12T02:06:19.000+00:002007-03-12T02:06:19.000+00:00The whole idea of having xml is not to recompile. ...The whole idea of having xml is not to recompile. we you have this inside of your ear file and want to change it then you need another build. This is not the case with xml since you just simple replace the xml file.<br />If you are insisting on your idea then your framework should take care of this as well.Rezahttp://www.rezaghp.comnoreply@blogger.com