Yes, if oozie:workflow:0.4 is the default namespace and none of the workflow elements are prefixed with a namespace, it works.
The same thing happens for the coordinator configuration elements if the coordinator is not the default namespace also. I have had to juggle the jaxbcontext to work around this problem, but it is solved for me for the moment. Still, this should be fixed as a namespace-prefixed configuration element is perfectly valid xml. E.g. this should not throw any error about not being a configuration element: <ns3:configuration xmlns:ns3="uri:oozie:workflow:0.4"> A more robust check of the element w/resp to namespace is in order. Thx Gary S On Thu, Jun 5, 2014 at 1:27 PM, Mona Chitnis <[email protected]> wrote: > Can you try by replacing all occurrences of Œns3:¹ with empty string? > > On 6/5/14, 12:58 AM, "Gary Schulte" <[email protected]> wrote: > > >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.jav > >a:401) > >at > >org.apache.oozie.action.oozie.SubWorkflowActionExecutor.start(SubWorkflowA > >ctionExecutor.java:183) > >at > >org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXComman > >d.java:211) > >at > >org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXComman > >d.java:59) > >at org.apache.oozie.command.XCommand.call(XCommand.java:277) > >at > >org.apache.oozie.service.CallableQueueService$CompositeCallable.call(Calla > >bleQueueService.java:326) > >at > >org.apache.oozie.service.CallableQueueService$CompositeCallable.call(Calla > >bleQueueService.java:255) > >at > >org.apache.oozie.service.CallableQueueService$CallableWrapper.run(Callable > >QueueService.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(SubWo > >rkflowActionExecutor.java:94) > >at > >org.apache.oozie.action.oozie.SubWorkflowActionExecutor.start(SubWorkflowA > >ctionExecutor.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 > >
