Namespaces in SwitchYard

[mageshbk]

Currently the merged configuration generator (ConfigMojo) does not seem to set the actual targetNamespace declared in the provided configuration. Say for e.g.,

<switchyard xmlns="urn:switchyard-config:switchyard:1.0"
            xmlns:swyd="urn:switchyard-config:switchyard:1.0"
            xmlns:trfm="urn:switchyard-config:transform:1.0"
            xmlns:bean="urn:switchyard-component-bean:config:1.0"
            xmlns:soap="urn:switchyard-component-soap:config:1.0"
            xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200912"
            targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0-SNAPSHOT"
            name="orders">

gets generated as

<switchyard xmlns="urn:switchyard-config:switchyard:1.0">
    <composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="orders">
...
        <component name="OrderService">
            <service name="OrderService">

Notice all the names are not type qualified ie., they are not generated with a namespace or the targetNamespace is not included in switchyard Element.

Thinking along these lines further, say if I do not have any configuration, just the @Service annotated beans,

1. Which namespace would these be generated? Java Package based?
2. If I want my OrderService in a different namespace, than my InventoryService, how would I achieve that?

Some more thoughts:

Say we provide an expansion in our annotation like this:

@Service(value=OrderService.class, namespace="urn:something")
public class OrderServiceBean implements OrderService

How will we get the namespace for @Reference, because that annotation will have an interface. Should we annotate the interface too?

@Service(namespace="urn:something")
public interface InventoryService

How will the other service implementations (like Camel for e.g.,) be confined to a namespace?

[dward]

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...

[kcbabo]

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.

[dward]

Loosing the targetNamespace looks like a bug. Stripping away unused xmlns attributes, and not having an xmlns on every element is not.

[kcbabo]

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

[tfennelly]

This is probably relevant too: https://issues.jboss.org/browse/SWITCHYARD-350

[dward]

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..."

[dward]

https://issues.jboss.org/browse/SWITCHYARD-351

[mageshbk]

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.

[mageshbk]

Hi David,

Thanks for fixing this issue:

https://issues.jboss.org/browse/SWITCHYARD-351

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

[kcbabo]

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.

[dward]

Thanks for bringing this to my attention, Magesh. I've created this JIRA:

https://issues.jboss.org/browse/SWITCHYARD-365

[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...