Doorgaan naar hoofdcontent

xml modification

So I wanted to modify some xml.
And yes, that might mean xslt.

However, the modification wasn't nice... in Java, it was fine, but to do that in xslt... rather not.

So, I ventured into the world of 'how do you call java from xslt'.
Of course, you can.
Of course, you need to use Saxon.
Of course, then you need a PAYED version of Saxon
... Sigh. I guess I'll stick to flat xslt and a lot of work then.
Just to remember how it *can* be done:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:imro="http://www.geonovum.nl/imro/2012/1.1"
xmlns:gml="http://www.opengis.net/gml/3.2"

 xmlns:java="http://xml.apache.org/xalan/java" exclude-result-prefixes="java"
>


    <xsl:output method="xml" encoding="utf-8" indent="yes"/>

    <!-- Identity template : copy all text nodes, elements and attributes -->  
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()" />
        </xsl:copy>
    </xsl:template>

    <xsl:template match="SomeXmlElement">
      <xsl:copy>
        <xsl:element name="newElement" >
          <xsl:value-of select="java:nl.demo.MyClass.staticfunction(string(//xpathnodeselectors))"/>
        </xsl:element>
      </xsl:copy>
    </xsl:template>

</xsl:stylesheet>

Of course. there is a hackier way.
What you can do, is parse the xml using JSoup.
JSoup is a html parsing library... but it supports xml.
Then you can use css selectors to walk through the DOM, and modify easily.
And writing out is pretty simple...

Document document = Jsoup.parse(stream, "UTF-8", "", Parser.xmlParser());
    document.outputSettings().prettyPrint(false).syntax(Document.OutputSettings.Syntax.xml);

document.selectFirst("SomeXmlElement").text(staticFunction(...);
document.toString(); // we have now modified the xml...
The sad state of java and xml, where a HTML parser makes an easier interface...

Reacties

Populaire posts van deze blog

Spring's conditional annotation with properties

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...

OSGI insights without sonar

So I was on a project without sonar. Oh my. Well, it was an OSGI project, so the problems couldn't be that bad, right? But how good were they (and what things were bad?) I found Stan4j , a code analysis tool for eclipse, which draws nice graphs and can handle osgi pretty well it seems. Now I can see that dependencies/bundle names aren't properly aligned (even though OSGI doesn't complain), etc.

JPA and transactions

So I was working with JPA and transactions. Consider the following: In bean 1, with implicit TX 1, managed entities are loaded/created,and returned in bean 2, with implicit TX 2, entities are modified in bean 3, with NO TX, bean 1 is called, and the results are passed to bean 2. and bean 4 is similar to bean 3, but with it's own transaction, TX3 What happens when bean 3 finishes: are the entities updated? What happens when bean 4 finishes, are the entities updated? The answer to this is simple; entities are managed through a persistance context. That context is tied to the transaction. So in bean 2, there is a difference. When called from bean 3, it runs in a different transaction then bean 1, and thus a different persistance context, and thus the entities are not managed 'by this transaction'.When called from bean 4, it all runs in the same transaction, TX3, and the results are persisted.