Bug 1043425 - switchyard-plugin adds xmlns:xmlns namespace, which is not valid
Summary: switchyard-plugin adds xmlns:xmlns namespace, which is not valid
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: SwitchYard
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: DR1
: 6.1.0
Assignee: David Ward
QA Contact: Matej Melko
URL:
Whiteboard:
: 1047938 (view as bug list)
Depends On: 1085860
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-16 09:55 UTC by Jiri Sedlacek
Modified: 2025-02-10 03:34 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-02-10 03:34:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
reproducer (3.43 KB, application/x-compressed-tar)
2013-12-16 09:55 UTC, Jiri Sedlacek
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SWITCHYARD-1908 0 Major Resolved switchyard-plugin adds xmlns:xmlns namespace, which is not valid 2016-03-14 15:43:42 UTC

Description Jiri Sedlacek 2013-12-16 09:55:35 UTC
Created attachment 837178 [details]
reproducer

After processing switchyard.xml by switchyard-plugin (version 1.1.1-p2-redhat-1) it adds xmlns:xmlns="..." namespace definition, which is not valid according to specification and processing fails.

Project for reproducing the issue is attached, there are two switchyard.xml file:

switchyard.xml - problem can be reproduced with this one
switchyard2.xml - equivalent file, root element defined in default namespace - this one can be processed.

Comment 1 Jiri Sedlacek 2013-12-16 11:30:02 UTC
it sometimes happens also if root tag is in default namespace and someother tag is in default namespace too - then xmlns:xmlns is attached to this tag (I saw this on validates or transforms tags)

Comment 2 Len DiMaggio 2013-12-16 14:52:36 UTC
Just to confirm - adding the default namespace - as you show in the switchyard2.xml file you attached - does this avoid the issue in 100% of the cases?

Comment 3 Jiri Sedlacek 2013-12-16 14:54:53 UTC
no, it can happen on other element with default namespace inside of document, I haven't found a cause yet.

Comment 4 Keith Babo 2013-12-16 15:16:41 UTC
It's due to the bpel-component dragging in saxonhe and xalan into build classpath.  I will reply with more detail and another workaround in a sec.

Comment 5 Keith Babo 2013-12-16 16:38:05 UTC
Before I get into details, I want to reiterate that this only occurs with projects which include a dependency on switchyard-component-bpel (i.e. they use a BPEL service).

I can eliminate this error with the following exclusions:

<dependency>
  <groupId>org.switchyard.components</groupId>
  <artifactId>switchyard-component-bpel</artifactId>
  <exclusions>
    <exclusion>
      <groupId>xalan</groupId>
      <artifactId>xalan</artifactId>
    </exclusion>
    <exclusion>
      <groupId>net.sourceforge.saxon</groupId>
      <artifactId>saxonhe</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Unfortunately, this only works because the reproducer project doesn't actually use the BPEL implementation.  Using the above exclusions on a project which dose use BPEL results in an error.  Interestingly enough, the bpel-service quickstarts do not exhibit this issue an they do not use the default (xmlns="...") namespace.  There must be a combination or ordering of dependencies for BPEL projects which makes this possible, but I haven't been able to isolate it yet.  For the time being, I would recommend the workaround of assigning the default namespace explicitly in projects which use BPEL.

Comment 6 Keith Babo 2014-01-02 16:12:32 UTC
*** Bug 1047938 has been marked as a duplicate of this bug. ***

Comment 14 Red Hat Bugzilla 2025-02-10 03:34:39 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.


Note You need to log in before you can comment on or make changes to this bug.