Dynamic java-xml binding - is it possible?


EJB design: Dynamic java-xml binding - is it possible?

  1. Dynamic java-xml binding - is it possible? (7 messages)

    XML to Java binding is interesting and I have been using it a lot. But such binding frameworks work on the generated code. Also if I am not wrong, such framework load the entire XML document in the memory. If the XML, I am working on is huge, this could be a memory hog, especially if I am interested in only a subset of the XML document. I was wondering, if anybody has any suggestions to avoid these problems:
    1. Having to generate java classes
    2. Loading subset of XML (in to a JavaBean) without loading huge XML document.

    I know XMLBeans has a neat concept of XML Cursors, but there I have to operate on elements instead of java objects. Having to deal with java objects gives me strong type casting that I like.

    I am thinking about using Apache digester with Apache Dynabeans as my first pass at it.
    Any suggestions? If you have done something like this or ifI am missing something here, please let me know. I would appretiate all your comments/suggestions.

    Thanks and regards,
  2. Can I ask what's the requirement that gave birth to this necessity?

  3. Can I ask what's the requirement that gave birth to this necessity?Cheers,Martin
    While integrating with our data providers, we get complete data back from them. But it is possible that we may need only a subset of that data for a perticular operation.
    Further more, we are trying to access this subset at runtime, depending on some metadata provided to us. So it is difficult to have java binding classes generated and distributed everytime. Also these binding frameworks load all the XML in the memory, which I would like to avoid, if possible.
    Does that make any sense? Or I am missin out something here?
  4. If I may ask, how will you know which subset of the XML document you will work on? Even if you know the tags, you still need to run through the document until you get to the specific part that you want to handle.

    If you know beforehand what part you would like to process, I would recomment pre-processing the XML document and cut out the relevant parts, and then use a binding tool. Does that make sense? Or why would you need a dynamic generation for this - maybe I'm missing the point?
  5. What would the API of your solution be? If the structure of the underlying XML changes at runtime, you need dynamic access to it. Two approaches:
    1) generate the Java classes with a tool, compile and load them at runtime), and use reflection to access the properties
    2) use a SAX based API in order to "search" the XML, perhaps using XPATH to find the elements you need. I don't know if such a product exists, but it could be interesting. DOM parsers let you query with XPATH but, as you well said, they load the whole XML in memory.
    I guess such a parser/query engine would need a very cute caching mechanism in order to avoid traversing the hole XML for each query.... ;)

    Ah! Something else. Would it be possible to use XSLT to transform the monster XML into the subset you need, and THEN use a DOM parser? You do have metadata to generate the XSLT at runtime...

  6. Martin,

    Thanks for your input.

    SAX is definately a possibility, but I fear I will loose strong type casting provided by javabeans, especially, if I need to use retrived data in calculations.

    I thought about using apache jakarta digester and BeanUtils to somehow achieve the result. If I can represent my XML to JAVA binding in terms of Digester mapping rules, I would be in a position to read part of the XML data (at least that is what my understanding of Digester is).

    I can write an implementation of org.apache.commons.digester.Rule to create a LazyDynaBean using Apache Jakarta BeanUtils.

    Makes any sense? Let's see if I can come up with a prototype to do this.

  7. Sorry, man, I'm not familiar with that product... Still, I don't know why do you think you will lose strong typing. You can use the SAX parser to build the object you need and preserve strong-typing.

  8. Thanks for your input Martin.
    I shall give it a thought and try.
    Let's see how it goes.