-
1. Re: Namespaces in SwitchYard
dward Jul 19, 2011 10:28 AM (in response to mageshbk)One point of clarrification: Not all the element names need to be namespace-qualified. They inherit the namespace of their parent element. Thus, the "xmlns" attribute is only added where it is needed.
You bring up a good point about the targetNamespace, and I like your idea about adding the namespace parameter to the @Service annotations. Sounds like a new Feature Request JIRA to me...
-
2. Re: Namespaces in SwitchYard
kcbabo Jul 19, 2011 10:33 AM (in response to mageshbk)My assumption so far has been that there is a single namespace for services and references defined in an application. Any @Service annotations should be part of the enclosing namespace definition for the application.
The merge thing does appear to be a bug. I also suspect that there are some gaps in the deployment/activator handling around namespaces. Just haven't had a chance to chase it up yet.
-
3. Re: Namespaces in SwitchYard
dward Jul 19, 2011 10:36 AM (in response to kcbabo)Loosing the targetNamespace looks like a bug. Stripping away unused xmlns attributes, and not having an xmlns on every element is not.
-
4. Re: Namespaces in SwitchYard
kcbabo Jul 19, 2011 10:41 AM (in response to dward)Loosing the targetNamespace looks like a bug.
Yep
Stripping away unused xmlns attributes, and not having an xmlns on every element is not.
I figured this went without saying. :-P
-
5. Re: Namespaces in SwitchYard
tfennelly Jul 19, 2011 10:46 AM (in response to mageshbk)This is probably relevant too: https://issues.jboss.org/browse/SWITCHYARD-350
-
6. Re: Namespaces in SwitchYard
dward Jul 19, 2011 11:14 AM (in response to tfennelly)I don't think they're related. I just commented on SWITCHYARD-350, "The error message in the attached screenshot seems strange. If implementation.camel extends the base implementation type from sca, then it should be fine..."
-
-
8. Re: Namespaces in SwitchYard
mageshbk Jul 19, 2011 11:21 AM (in response to dward)David Ward wrote:
One point of clarrification: Not all the element names need to be namespace-qualified. They inherit the namespace of their parent element. Thus, the "xmlns" attribute is only added where it is needed.
I meant not the attribute name, rather the values that are used in them.
-
9. Re: Namespaces in SwitchYard
mageshbk Jul 28, 2011 2:22 AM (in response to dward)Hi David,
Thanks for fixing this issue:
But what is the point of just preserving them when a runtime query on that configuration such as this returns blanks ("")?
CompositeServiceModel composite = (CompositeServiceModel) config; composite.getQName().getNamespaceURI(); composite.getComponentService().getQName().getNamespaceURI();
With the sample mentioned in the JIRA, one would expect those getNamespaceURI() methods to return this, right?
urn:switchyard-quickstart-demo:orders:0.1.0-SNAPSHOT
cheers,
Magesh
-
10. Re: Namespaces in SwitchYard
kcbabo Jul 28, 2011 10:01 AM (in response to mageshbk)I haven't actually tested this myself, so I can't say whether the implementation is behaving correctly. That said, I agree that the QNames returned for a composite name or service name should include the targetNamespace as the namespace URI.
-
11. Re: Namespaces in SwitchYard
dward Jul 28, 2011 11:49 AM (in response to mageshbk)Thanks for bringing this to my attention, Magesh. I've created this JIRA:
-
12. Re: Namespaces in SwitchYard
dward Jul 28, 2011 3:57 PM (in response to dward)Okay, I've completed https://issues.jboss.org/browse/SWITCHYARD-365 . Please be sure to read the comments. The change bubbled out, but I believe in a good way...