Bug 780623 (SOA-3061)

Attachment: Added: quickstart_freemarker_namespace_failure.zip

Workaround Description: Added: Until there is a way to strip the namespace from the DOM fragment that has been created by the DomModelCreator, a workaround would be to remove the namespace from the incoming document *before* the SmooksAction, using XSLT:

jboss-esb.xml:
-------------
    <!-- Remove namespace from input document before the SmooksAction -->
    <action name="remove-namespace-using-xslt" class="org.jboss.soa.esb.actions.transformation.xslt.XsltAction">
        <property name="templateFile" value="/smooks.xsl"/>
    </action>     
    <action name="simple-transform" class="org.jboss.soa.esb.smooks.SmooksAction">
        <property name="smooksConfig" value="/smooks-res.xml" />
    </action>

smooks.xsl:
-------------
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes"/>

<xsl:template match="/|comment()|processing-instruction()">
    <xsl:copy>
      <xsl:apply-templates/>
    </xsl:copy>
</xsl:template>

<xsl:template match="*">
    <xsl:element name="{local-name()}">
      <xsl:apply-templates select="@*|node()"/>
    </xsl:element>
</xsl:template>

<xsl:template match="@*">
    <xsl:attribute name="{local-name()}">
      <xsl:value-of select="."/>
    </xsl:attribute>
</xsl:template>
</xsl:stylesheet>
Workaround: Added: [Workaround Exists]

As the outlined workaround of using an XSLT action comes with a performance impact, here's an approach that should work better (by courtesy of TomF):

Override the DomModelCreator to not produce namespaced DOM fragments, which has an inner class called DOMCreator. In there is where you'd make your changes

Element domElement = element.toDOMElement(document); 

I think it would be a case of replacing that line of code with something that constructs the Element without namespace info attached - and that would be it I think.

Candidate, not commited. Can we deal with it in Smooks? Or if it requires an update to freemarker, then we need to punt. Tom C to investigate.

From Tom F via email : "3061 already has my feedback on it i.e. there should be a fix if we want, but it would require writing of a new class in the ESB, or fixing the relevant class in Smooks." 

Given that, I think we can take it in 5.2.

Link: Added: This issue relates to JBESB-3680

I'm trying to get more information on this from the FreeMarker community.  I wrote a test and sent it to them.  Hopefully there's a code solution I can put into Smooks, or instructions on how to write the FreeMarker template work with the namespaces.

OK... there's actually a solution to this issue, without any changes to JBossESB/Smooks.

When using FreeMarker's nodemodel stuff on namespaced XML, you must define the namespaces in the FreeMarker template ala http://freemarker.org/docs/xgui_imperative_learn.html#autoid_73

So, taking the example attached to this JIRA.  The freemarker template must change from...

{code}
${item.nachname}|${item.eintrittsdatum}|Erstellungszeit hhmmss|U|PersNr|${item.anrede}|Name|${item.vorname}|Geb.Datum|Funktion||Verteilstelle|Eintritt|Austritt|
{code}

To...

{code}
<#ftl ns_prefixes={"acme":"http://acme.com/ns"}>
${item["acme:nachname"]}|${item["acme:eintrittsdatum"]}|Erstellungszeit hhmmss|U|PersNr|${item["acme:anrede"]}|Name|${item["acme:vorname"]}|Geb.Datum|Funktion||Verteilstelle|Eintritt|Austritt|{code}

Then it works.

This isn't actually a bug but the correct syntax needs documenting.

Release Notes Text: Added: Not yet documented

Release Notes Docs Status: Added: Documented as Resolved Issue
Writer: Added: dlesage
Release Notes Text: Removed: Not yet documented Added: https://issues.jboss.org/browse/SOA-3061

If the input file for a Freemarker transformation contained a name-space declaration, users would encounter an freemarker.core.NonStringException.  A fix has been applied so that these name-spaces are now stripped out, meaning users will no longer see the error.

Verified in ER6.

Reopening this bug because the suggested syntax from comment #8 does not work. In addition, the Release Notes text is incorrect, as no fix has been applied.

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.