Home

News: XML in IoC containers: A Hell or A Realm?

  1. XML in IoC containers: A Hell or A Realm? (20 messages)

    While the essence of Inversion-of-Control (IoC) container appears to be easily comprehensible and well understood, it is subtly confusable and badly misread. One of the biggest confusing is about the use of XML. Namely, application composite wiring/configurations are programmed as XML documents (or textual strings). This practice in IoC containers, notoriously known as the "XML Hell", draws various FUD criticisms, such as: * These XML codes are merely lousy and verbose procedural scripts. * These XML codes are poorly debuggable. * These XML codes lack static type safety. * These XML codes are refactoring-adverse. In the article IoC containers other than the DI pattern, these seemingly evident FUD criticisms are questioned: Are these XML codes verbose and lousy procedural scripts? First of all, these XML codes are not scripts that verbalize the procedures to produce the required configurations. Instead, they are models that visualize the required composite laytout themselves (or requirements and constraints). This is just like the distinction between the assembly instruction book of a vehicle and its design blueprint. Hence, these XML codes are meant to be schematically intuitive and self-documenting rather than linguistically fluent and concise. Secondly, these XML codes are intended to serve as mediating data worksheets as well. These data worksheets are going to be exchanged between IoC containers and independent applications/plugins that provide value-added features, such as model generation, editing, displaying, transformation, verification, storing, and querying. Therefore, these XML codes are preferred to be programmatically manipulable as first class objects to heterogeneous programs rather than grammatically readable as natural language texts to English programmers. It is widely thought that such a data modeling issue was no more than another nail for the universally effective golden hammer - procedural languages (such as Java). A chief scientist of a Java consulting firm once even made an assertion: "Everything that can be done with xml should be doable from a java program". Consequently, various kludges have been invented and enthusiastically practiced to eliminate XML for data modeling, for instance, by expressing data composite model layouts in procedural method chaining layouts (i.e. the so-called fluent API coding style) or Java annotated data type layouts (i.e. metadata). Although claimed as substitutes or killers of their XML counterpart, it is not hard to see that these clever kludges are merely poorman's mimics of declarative data description languages. Not only they lack language level support of formal and intuitive schema definitions and structure/content integrity constraints, but also their codes are hard to be manipulated as first class objects. These "using procedural language for data modeling" kludges appear to have certain claimed advantages (such as debuggable, static type safety, refactoring-friendly) over XML, they missed the fundamental points of both the procedural programming and the data modeling paradigms in general. Are these XML codes poorly debuggable? Here, the "debug" specifically means stepping and tracing through the runtime executions of procedure codes at source level. When comparing to IoC containers, XML-eliminated DI frameworks frequently emphasize their advantage (as a killer feature) of being able to debug user authored application assembling/configuring codes written in procedural languages. Nevertheless, relying on such stepping/tracing debug simply indicates the following two facts of these DI wiring programs and their languages: * these programs consist user designed procedural code and user defined mutable states/variables. * these programs are written in languages that lack of data schema support (i.e. neither allowing users to define problem/domain specific schemata nor being able to impose such statically verifiable schema constraints). On the contrary, user authored XML codes in IoC containers are not procedural scripts but data descriptions that model the required composite arrangements with well defined schemata and statically verifiable integrity constraints. In general, code orders in these XML programs do not imply the actual step-by-step imperative execution orders of the underlying plumbing operations performed transparently by IoC containers. Hence, just like freeing from runtime debugging syntax errors, static type errors, and memory pointer arithmetic faults is an advantage of the Java environment, relieving the burden of runtime debugging structure/content constraint violations and IoC plumbing procedures is the very point and the strength of IoC containers and the data description language like XML! Are these XML codes unable to feature static type safety? This FUD critism is specific to the static type safety. This is because that the dynamic type safety is already supported in IoC containers through comparing reflection retrieved metadata informations against operation signatures referred in these XML codes. For static type safety, component type informations are supposed to be retrieved from POJO (and/or POCO) component source code. Apparently, this was considered by this FUD to be not possible or significantly difficult. However, firstly, it is obvious that what should be blamed here is not these XML codes but those POJO/POCO source codes written in classic procedural languages. Namely, the difficulty (if any) is not on inspecting operation signatures referred in these XML code but on retrieving type informations from those POJO/POCO source code. In another word, this issue actually reveals an advantage of these XML codes over classic procedural language code on being explicitly manipulable as first class objects. Secondly, various "static reflection" engines for these procedural languages, such as Eclipse CDT C++ DOM/AST, JDT Java DOM/AST (since June 2004, Eclipse 3.0), GCC-XML (since 2002), Eclipse JDT JDOM (as early as 2002, for Eclipse 1.x/2.x) have long and widely been available. With these engines, type information "static reflection" from POCO/POJO component source code is as simple as dynamic reflection from compiled metadata. Therefore, static type safety check for these XML codes is as easy as the widely supported dynamic type safety for IoC containers. Thirdly, this FUD criticism itself is merely a red herring to mislead readers to believe that, without static type safety, these XML codes would imply significant overhead (claimed to be 10 times slower) and be error prone at runtime. Nevertheless, in IoC containers, dynamic type check on each signature in these XML codes needs only be performed once (or very few times). Hence, the real performance overhead from dynamic type check is negligible for almost all real world applications that use decent IoC containers. More importantly, in IoC/DI scenario, operation signatures referred in these XML codes are resolved (and checked) by IoC container at applications (especially test applications) initialization or reinitialization phase. Hence, these XML codes are no longer involved in the executions of the applications once they passed this initialization/reinitialization phase, let along to cause runtime type errors in production applications. Certainly, a start-up time type check that requiring a start-up test is still different from source code editing or compiling time check. However, arguing such a start-up type check was practically unacceptable would be self-contradictory to the previous argument that emphasized the advantage of runtime debuggability which implies more than starting the applications. Fourthly, with regarding to static code check, this FUD criticism inadvertently brought up a fundamental weakness of procedural languages and a significant strength of the XML paradigm. Namely, grammar (or syntax structure) and static type safety check of procedural languages tend to be too primitive and too generic to ensure user authored procedures are free from runtime errors or wrong runtime results without errors. This is why procedural languages and their XML-eliminated DI frameworks emphasize runtime debug and sufficient runtime test coverage. On the contrary, in IoC containers, these XML codes do not specify the runtime procedures but explicitly describe the required results and, therefore, are not only inherently free from runtime errors caused by procedural bugs in user codes but also enable much sophisticated and problem/domain specific schema verifications to statically diagnose errors in user described requirements or even results themselves. Are these XML codes refactoring-adverse? This FUD claim can be put as: POCO/POJO function signatures are expressed as literal strings in these XML codes. Because literal string in C++/Java code do not participate in code refactoring, hence, these XML code are not able to participate in component interface refactorings either. The erroneousness of this FUD claim is fail to understand that having a pair of quote characters surround a string text is merely an appearance rather than the cause of "refactoring-adverseness". In fact, the quote character pairs surrounding string texts are removed at lexical analysis stage even before these strings being added to the abstract syntax trees (AST) internally used by compilers or refactoring engines. The "refactoring-adverseness" of these strings is not due to the quote character pairs surrounding them but simply because the literals strings themselves in C++ or Java languages have no language level connections to names/signatures of variables, interfaces/classes, and/or functions/methods known by refactoring engines. On the contrary, the mapping from the attribute values in form of quoted strings in these XML codes to POCO/POJO interface/class type names and function/method signatures are well defined. Otherwise, the underlying IoC engines would not even be able to resolve invocation methods through reflection in the first place. Hence, having refactoring on these XML codes is straightforward, and having them participate in POCO/POJO component code refactoring is not more difficult than (if not significantly easier than) the original work of supporting refactoring on C++/Java code themselves (would C++/Java be criticized as being refactoring-adverse as well?), not to mention this integration approach has largely been simplified by the open architectures of existing refactoring IDEs (such as the Eclipse Language Toolkit (LTK) refactoring architecture) and the Eclipse CDT C++ DOM/AST and JDT Java DOM/AST "static reflection" engines. Furthermore, the "refactoring" in this FUD criticism obviously meant the interactive refactorings supported by integrated development environments (IDEs) of procedural languages, such as Eclipse. Having these XML code participate in such an interactive refactoring of POCO/POJO, as pointed out above, can be supported in Eclipse. However, it would only make sense if the XML code and the POCO/POJO component/service implementation codes were developed together within the same IDE project. Unlike programmatic API frameworks (as well as those XML-eliminated DI frameworks) which consider wiring configurations an statically built-in integral part developed together with and spread throughout their applications, IoC containers have assembly/deployment arrangement code completely separated from POCO/POJO component/service implementations. Namely, these arrangement code tend to be authored independently outside of (or decoupled from) the development phase(s)/cycle(s), IDE project(s), and/or brain(s)/team(s)/vendor(s) of those components/services. Hence, having these XML code participate in an interactive refactoring of those POCO/POJO code is largely a phantom requirement from misreading or misusing of IoC containers.

    Threaded Messages (20)

  2. I switched long ago to @Autowired and @Resource and virtually stopped using XML in my large Spring config. IMO, Annotations are far superior to XML and less prone to error. I write all of my DI config in annotations and haven't looked back. The only XML config I have is initialization parameters for external classes and the declaration of my packages for the tag.
  3. Annotation nor XML is a golden hammer. Mind to share why you use XML originally? Likely, it was a wrong choice in the first place. Even if without annotation, you didn't have to wiring your application using XML. There were non-XML DI frameworks before annotation. XML vs annotation is just like apple vs orange, or embedded data vs command-line arguments, external data files, or relation databases. Hope this answered your question.
  4. Annotation nor XML is a golden hammer. Mind to share why you use XML originally?
    Conceptually...separation of concerns?....Linking my persistence layer, a very stable, unlikely to be modified module, to less stable configuration dependent on outsiders, like our IT department. Specifically...injecting Strings and datasources from JNDI into my code. My persistence layer was finalized, but the configuration, settings were much more fluid. Also, I presently use XML based configuration to inject resources I have no control over, such as Spring MVC and JPA initialization code into my application. Philosophically, I see it as glue...easy to understand configuration...enabling 2 stable entities to work well together without prior knowledge of the context in which they're being executed. My persistence layer doesn't really know if it's running HSQL in a TestNG test or Oracle on a massive cluster in production. Spring MVC doesn't know if they're running my application or another. The "glue code," in this case XML + annotations allows me to easily link the 2 and reuse them in different contexts.
    Likely, it was a wrong choice in the first place.
    That's certainly possible. Please define "wrong." I am sincerely trying to follow understand your argument, but not having much success. In what sense is that choice for configuration wrong? In the papers, are you advocating a specific design pattern/technique/methodology? I noticed a lot of criticism, but haven't been able to figure out what you're advocating.
  5. Annotation nor XML is a golden hammer. Mind to share why you use XML originally?

    Conceptually...separation of concerns?....Linking my persistence layer, a very stable, unlikely to be modified module, to less stable configuration dependent on outsiders, like our IT department.

    Specifically...injecting Strings and datasources from JNDI into my code. My persistence layer was finalized, but the configuration, settings were much more fluid.

    Also, I presently use XML based configuration to inject resources I have no control over, such as Spring MVC and JPA initialization code into my application.

    Philosophically, I see it as glue...easy to understand configuration...enabling 2 stable entities to work well together without prior knowledge of the context in which they're being executed.

    My persistence layer doesn't really know if it's running HSQL in a TestNG test or Oracle on a massive cluster in production. Spring MVC doesn't know if they're running my application or another. The "glue code," in this case XML + annotations allows me to easily link the 2 and reuse them in different contexts.

    Thanks! This is exactly what I said, neither one is golden hammer.
    Likely, it was a wrong choice in the first place.

    That's certainly possible. Please define "wrong." I am sincerely trying to follow understand your argument, but not having much success. In what sense is that choice for configuration wrong?


    In the papers, are you advocating a specific design pattern/technique/methodology? I noticed a lot of criticism, but haven't been able to figure out what you're advocating.
    This article is to clarify a few key facts that have been widely mis-told before. If you find specific false arguments in the article, please feel free to point them out. Thanks!
  6. Excellent argument[ Go to top ]

    I totally agree with the author. This is a new perspective of looking at DI and IOC. With respect to Spring IOC, every application development needs a framework to reduce development time. Teams select framework which have established themselves in the industry to reduce risk. So is the case with Spring. Spring chose XML as configuration tool cause at that time XML was the right way to go with. As technology advances we will see changes in Spring framework too to support XMLless or true DI or IOC.
  7. Bravo! Really good article. Note 1: Seems like annotations with string parameters aren't much more verifiable then attribute values in XML. Note 2: SpringIDE do static check of Spring IoC configurations.
  8. Bravo! Really good article.

    Note 1: Seems like annotations with string parameters aren't much more verifiable then attribute values in XML.

    Note 2: SpringIDE do static check of Spring IoC configurations.
    Thanks! 1. agree! 2. good to know that. I played SpringIDE shortly few years ago. Do remember its static check was truely static (using AST based "static reflection" from source code) or dynamic in disguise (using reflection from compiled code)?

  9. 2. good to know that. I played SpringIDE shortly few years ago. Do remember its static check was truely static (using AST based "static reflection" from source code) or dynamic in disguise (using reflection from compiled code)?
    I'm not sure if they use AST but it's quite enough for developer to check code/configuration as it's written. The inspired discussion is really interesting too. I'm not really an everyday IoC developer. But underlying layers generated from UML. The modeled dependencies then expressed in IoC configuration files. Having such configurations in XML seems really natural. They express just specific layer without overloading it with implementation code. When I need implementation I see to actual code. I really agree with Steven Boscarine about approach when to use what.

  10. 2. good to know that. I played SpringIDE shortly few years ago. Do remember its static check was truely static (using AST based "static reflection" from source code) or dynamic in disguise (using reflection from compiled code)?


    I'm not sure if they use AST but it's quite enough for developer to check code/configuration as it's written.
    Cool! this indicates it is real static.

    The inspired discussion is really interesting too. I'm not really an everyday IoC developer. But underlying layers generated from UML. The modeled dependencies then expressed in IoC configuration files. Having such configurations in XML seems really natural. They express just specific layer without overloading it with implementation code. When I need implementation I see to actual code.
    I really agree with Steven Boscarine about approach when to use what.
  11. Good point[ Go to top ]

    I like this article as it puts the finger on an issue that IMHO is worthy talking about. I looked some time ago at Google Guice and really liked it, because it does its IoC job in a type safe and efficient way (through generics) without any extensive byte code manipulation and without any lengthy XML files. Solution through design instead throug byte code manipulation! If I debug code that uses Spring I get sick of every time jumping over all the Spring injected methods in the stack. Alas, when you don't have years of experience with using Spring you are simply out of business, so you have no choice whether XML or not ... Cheers, Oliver
  12. FUD?[ Go to top ]

    I thought this article was a major exercise in FUD itself. An argument like "my old washing machine is broken, but it sure makes a nice vase stand so new washing machines suck!" is not really an argument, is it? Refactoring-adverseness of XML config. code is wholly dependent on not having a tool/Eclipse plug-in there. Of course, for Spring there are tools, but in general, there aren't. So, without mentioning specific IoC/DI frameworks in combination with supported IDE's, XML.equals(Maintenance Hell) every time.
  13. Re: FUD?[ Go to top ]

    I thought this article was a major exercise in FUD itself. An argument like "my old washing machine is broken, but it sure makes a nice vase stand so new washing machines suck!" is not really an argument, is it?

    Refactoring-adverseness of XML config. code is wholly dependent on not having a tool/Eclipse plug-in there. Of course, for Spring there are tools, but in general, there aren't. So, without mentioning specific IoC/DI frameworks in combination with supported IDE's, XML.equals(Maintenance Hell) every time.
    This article is neither about "say no to annotation" nor about "XML vs annotation". This has been repeated many times and very clearly stated in the referred article IoC vs DI. This kind of comparision, which I have seen many times, is apple vs orange, and sometime even become comparing assembly instruction book of a vehicle to its (digitialized) design blueprint. As pointed out in the article IoC vs DI, although widely misread and consistantly misused, IoC containers are actually not to facilitate the DI (or IoC) pattern. This is just like old-EJB containers were not to facilitate service-lookup pattern. Therefore, for users, it makes perfect sense to use a purely-programmatic DI frameworks rather than a (XML based) IoC container if their purpose is merely to facilitate the DI design pattern in their programs. When doing this DI programming, it also make sperfect sense that the availability of refactoring tools to be a important concern. What I clarified in this article, when questioning the "refactoring-adverse", is not about the availability of such tools, but about its "feasibility" and "necessarity" (when IoC containers are not misused).
  14. complexity is bad[ Go to top ]

    Basically software maintenance is proportional to the complexity and size of your software artifacts. There have been plenty of studies on this over the past few decades, so lets take that as a fact: more LOC = higher maintenance cost, more complexity = higher maintenance cost. Domain specific languages (DSL) reduce the number of LOC, which is good. If you are looking for an excuse to create a DSL, there you have it. And XML is of course a popular dialect for expressing DSLs. However, using multiple languages or DSLs in one project of course results in complexity because you need to be up to speed with all of them to be able to maintain the project. A typical IOC container that heavily depends on XML for configuration easily uses dozens of different schemas that all go into different files based on file name conventions, or worse, file location conventions. That's complexity. Anything that requires a two day course to actually understand how your hello world app actually works (as opposed "copy paste this shit you are not worthy of understanding, click that button there and hope for the best") is probably overly complicated. Spring definitely suffers from this problem. Calling it configuration doesn't change the fact that you end up having to maintain hundreds or thousands of lines of code in essentially dozens of different languages spread over a shit load of files that all need to be just right for things to work properly. That's inherently brittle design. And as pointed out, complexity increases maintenance cost. With some Spring XML stuff, I'd be in the camp that suggests it is still worth the trouble although I am definitely against using XML when annotations can do the job for the simple reason I end up with less artifacts and LOC to maintain. In a way, having to use XML is sort of a failure of the Java language. Ruby/python/groovy proponents pride themselves of being able to express all sorts of DSLs in Ruby itself. Java just isn't that well suited for this kind of thing. You won't find a lot of xml in Groovy on Rails, Python Django, Ruby on Rails, etc. They don't need to switch language to express configuration. Java does. Annotations help but they are not a 100% solution.
  15. re: complexity is bad[ Go to top ]

    Basically software maintenance is proportional to the complexity and size of your software artifacts. There have been plenty of studies on this over the past few decades, so lets take that as a fact: more LOC = higher maintenance cost, more complexity = higher maintenance cost.
    LOC make sense when comparing between programs that express same logic. It does make sense if you compare LOC of a program that express logic of how to do a thing and another program that specifies what is the thing. This is just like you try to compare between a vehicle's assembly procedural program (or instruction manual) and its digitalized blueprint and concluded that the assembly procedural is superior by being more readable and concise than the blueprint.


    Domain specific languages (DSL) reduce the number of LOC, which is good. If you are looking for an excuse to create a DSL, there you have it. And XML is of course a popular dialect for expressing DSLs.

    However, using multiple languages or DSLs in one project of course results in complexity because you need to be up to speed with all of them to be able to maintain the project. A typical IOC container that heavily depends on XML for configuration easily uses dozens of different schemas that all go into different files based on file name conventions, or worse, file location conventions. That's complexity. Anything that requires a two day course to actually understand how your hello world app actually works (as opposed "copy paste this shit you are not worthy of understanding, click that button there and hope for the best") is probably overly complicated. Spring definitely suffers from this problem.

    Calling it configuration doesn't change the fact that you end up having to maintain hundreds or thousands of lines of code in essentially dozens of different languages spread over a shit load of files that all need to be just right for things to work properly. That's inherently brittle design.

    And as pointed out, complexity increases maintenance cost. With some Spring XML stuff, I'd be in the camp that suggests it is still worth the trouble although I am definitely against using XML when annotations can do the job for the simple reason I end up with less artifacts and LOC to maintain.

    In a way, having to use XML is sort of a failure of the Java language. Ruby/python/groovy proponents pride themselves of being able to express all sorts of DSLs in Ruby itself. Java just isn't that well suited for this kind of thing. You won't find a lot of xml in Groovy on Rails, Python Django, Ruby on Rails, etc. They don't need to switch language to express configuration. Java does. Annotations help but they are not a 100% solution.
    Different from DSL, XML code here serve for two purposes: 1. visualize what user want (rather than verbalize how to do them) and statically verifiable. 2. as intermediate data worksheets (or, working documents) that can be easily exchanged and manipulated by heterogeneous user programs. Yes, those languages and their DSLs you mentioned many be much fluent, concise, readable (as natural language for English programmers). However, these characters are orthogonal to intuitive, self-documenting, statically verifiable, and safely manipulable. Thanks!
  16. Re: re: complexity is bad[ Go to top ]


    LOC make sense when comparing between programs that express same logic. It does make sense if you compare LOC of a program that express logic of how to do a thing and another program that specifies what is the thing. This is just like you try to compare between a vehicle's assembly procedural program (or instruction manual) and its digitalized blueprint and concluded that the assembly procedural is superior by being more readable and concise than the blueprint.
    Typo. I meant "It does not make sense if you compare LOC of a ...."
  17. tiffany jewelry[ Go to top ]

    tiffany jewelry replica jewelry tiffany silver jewelrymart jewelry earring jewelry watches Bluetooth Baby Monitor Computer Accessories rolex watches replica watches Breitling Watches
  18. Bravo[ Go to top ]

    Great article and great points. FYI, you don't need a DSL or an XML-based IoC container to do IoC. Pure Java will do just fine with setter methods and constructor injection. What I'd really like to see is some declarative initialization be brought to the Java language, some like: mybean = new Foo() { propertyA = 5; propertyB = "hello world"; propertyC = otherBean; @start { do some init; } @end { do some cleanup; } } I started prototyping something like this, but didn't really have the time to finish it.
  19. Re: Bravo[ Go to top ]

    Great article and great points. FYI, you don't need a DSL or an XML-based IoC container to do IoC. Pure Java will do just fine with setter methods and constructor injection.

    What I'd really like to see is some declarative initialization be brought to the Java language, some like:

    mybean = new Foo() {

    propertyA = 5;
    propertyB = "hello world";
    propertyC = otherBean;

    @start {
    do some init;
    }

    @end {
    do some cleanup;
    }
    }

    I started prototyping something like this, but didn't really have the time to finish it.
    Yes, this is similar to Spring JavaConfig I think. However, the purpose of using XML by old-EJB (and even before that) and inherited by IoC containers is to have application wiring/configuration codes as an intermediate data worksheets (or working documents) that can be exchanged between applications (including the IoC containers) and manipulated (such as verification, transformation, visual display/design, modification, etc.) by them at various abstraction level. You certainly can use java code for this purpose, but it sucks (even if with DOM/AST mapping).
  20. FUD is a very strong word[ Go to top ]

    It implies that your opponents are knowingly making false statements, blatantly exploiting weakness in human nature, with an evil agenda of destroying intelligent understanding. While I believe they are just airing their honest opinions, right or wrong, smart of dumb. It is bad sportsmanship if you question your opponents' integrity and intention in a debate. Maybe you are just not very familiar with the word 'FUD' and misused it.
  21. Re: FUD is a very strong word[ Go to top ]

    Yes, it was misused. Thanks for pointing out.