I have a workflow.xml with several subworkflows that I am generating via
jaxb.
Since the xml is generated using jaxb, I end up with some fun xml
namespaces such as:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<coordinator-app name="DCSqoop-DC1" frequency="${coord:days(1)}"
start="${startPeriod}" end="${endPeriod}" timezone="UTC"
xmlns:ns2="uri:oozie:sla:0.1" xmlns="uri:oozie:coordinator:0.4"
xmlns:ns4="uri:oozie:bundle:0.2" xmlns:ns3="uri:oozie:workflow:0.4"
xmlns:ns5="uri:oozie:sqoop-action:0.3">
....
<ns3:action name="sqoop_table">
<ns3:sub-workflow>
<ns3:app-path>/tmp/sqoop_tab.xml</ns3:app-path>
<ns3:propagate-configuration/>
<ns3:configuration>
<ns3:property>
<ns3:name>incrementalFrom</ns3:name>
<ns3:value>2005-01-01T00:00Z</ns3:value>
</ns3:property>
<ns3:property>
<ns3:name>incrementalTo</ns3:name>
<ns3:value>2014-05-01T00:00Z</ns3:value>
</ns3:property>
</ns3:configuration>
</ns3:sub-workflow>
<ns3:ok to="JOIN_SMALL_TABLE"/>
<ns3:error to="FAIL"/>
</ns3:action>
....
The workflow passes validation, and indeed it will run - as long as I don't
attempt to pass a configuration to the subworkflow. If I do, I get:
IOException: bad conf file: top-level element not <configuration>
at
org.apache.oozie.action.ActionExecutor.convertException(ActionExecutor.java:401)
at
org.apache.oozie.action.oozie.SubWorkflowActionExecutor.start(SubWorkflowActionExecutor.java:183)
at
org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:211)
at
org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:59)
at org.apache.oozie.command.XCommand.call(XCommand.java:277)
at
org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:326)
at
org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:255)
at
org.apache.oozie.service.CallableQueueService$CallableWrapper.run(CallableQueueService.java:175)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.io.IOException: bad conf file: top-level element not
<configuration>
at
org.apache.oozie.util.XConfiguration.parseDocument(XConfiguration.java:283)
at org.apache.oozie.util.XConfiguration.parse(XConfiguration.java:269)
at org.apache.oozie.util.XConfiguration.<init>(XConfiguration.java:74)
at
org.apache.oozie.action.oozie.SubWorkflowActionExecutor.injectInline(SubWorkflowActionExecutor.java:94)
at
org.apache.oozie.action.oozie.SubWorkflowActionExecutor.start(SubWorkflowActionExecutor.java:161)
... 9 more
After much effort at reproducing, and stepping through source, it appears
the problem is in
org.apache.oozie.util.XConfiguration.parseDocument(Document doc) :
// Canibalized from Hadoop <code>Configuration.loadResource()</code>.
private void parseDocument(Document doc) throws IOException {
Element root = doc.getDocumentElement();
if (!"configuration".equals(root.getTagName())) {
throw new IOException("bad conf file: top-level element not
<configuration>");
}
processNodes(root);
}
Specifically the condition requiring the root element to be
"configuration". Using a xml namespace of ns3, the root element of my
action's configuration is "ns3:configuration". So it throws an IOException.
FYI, the action configuration that fails ends up being:
<ns3:sub-workflow xmlns:ns3="uri:oozie:workflow:0.4">
<ns3:app-path>/tmp/sqoop_tab.xml</ns3:app-path>
<ns3:propagate-configuration/>
<ns3:configuration>
<ns3:property>
<ns3:name>incrementalFrom</ns3:name>
<ns3:value>2005-01-01T00:00Z</ns3:value>
</ns3:property>
<ns3:property>
<ns3:name>incrementalTo</ns3:name>
<ns3:value>2014-05-01T00:00Z</ns3:value>
</ns3:property>
</ns3:configuration>
</ns3:sub-workflow>
If I manually modify the generated workflow to make workflow 0.4 the
default namespace and remove the ns3: prefixes from the subworkflow
definition, it works fine.
I am wrangling with jaxb now to see if I can get it to use workflow as the
default namespace to work around this, but this looks like a defect to me.
Thanks,
Gary S
