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.