[cddlm] Problems in the tests

[Steve Loughran]

Guilherme Mauro Germoglio Barbosa / Projeto Ourgrid - Projeto 
Ourgrid/LSD wrote:
> Hello,
> 
> While implementing some of CDDLM tests (CDL/Deployment API), I've found 
> the following problems:
> 
> 1. The implementation of the CDLTestUtils.java has the method:
> 
> /   /**
>     * Get a required attribute of an element. We search first for the 
> namespace qualified attribute,
>     * then the non-namespaced version.
>     *
>     * @param element   element to search
>     * @param attribute attr
>     * @param docinfo   document data
>     * @return the attribute value
>     * @throws CDLException if the attribute is not there
>     */
>    public static String getAttribute(Element element, String namespace, 
> String attribute, String docinfo) {
>              String attr = element.getAttributeNS(namespace, attribute);
>       if (attr == null)) {
> //     if ("".equals(attr)) {
>            attr = element.getAttribute(attribute);
>        }
>        if (attr == null)) {
> //      if ("".equals(attr)) {
>            //raise an error on an empty attribute
>            throw new CDLException("No " + attribute + " for " + 
> element.getTagName() + docinfo);
>        }
>        return attr;
>    }
> 
> /The commented part (/if.../)  is how I think it is the correct, as the 
> documentation of  /org.w3c.dom.Element/ says:
> 
> */String org.w3c.dom.Element.getAttributeNS(String namespaceURI, String 
> localName)/*
> /(...)
> Returns:
>    The Attr value as a string, or the empty string if that attribute 
> does not have a specified or
>     default value./
> /(...)
> 
> /Is anyone against I commit these changes?

I'd fail on the attr being null, or if not null, equalling "". iei

if(attr==null || attr.length()==0) {
  ...
}

because if the code is in there, its probably because one XML parser is 
returning null.

I've just patched the code so either condition is caught. Thanks for the 
suggestion.




> 
> 2. The deployment API has the test:
> 
> /*api-18: Create a System while subscribed with an invalid endpoint*/
> 
> Subscribe to a portal for creation events with a notification EPR that 
> is invalid. There are the following types of invalid portal
> 
>    *
> 
>      Nonexistent URL (e.g. "http://notifications.example.org/epr1").
> 
>    *
> 
>      endpoint with no open connection (e.g.
>      "http://localhost:8081/epr1"), assuming port 8081 is closed
> 
>    *
> 
>      404 URL (e.g. "http://deployment.sourceforge.net/example/epr1").
> 
> Assertions:
> 
>    *
> 
>      In all cases, the notification delivery failure is noted, the
>      endpoint is no longer subscribed
> 
> 
> Don't you think this behavior of simply unsubscribing the consumer in 
> its first failure can result in bad unsubscriptions? I mean, the failure 
> can be transient and only by a few seconds can make the consumer 
> unreachable/invalid.
> The other problem is that I didn't find in the WSN specification what 
> must be done when a notification fails. Does it mean that it is free to 
> the implementation have its own policy when notification fails? The 
> Pubscribe implementation tries to notify a certain number of times when 
> an EndPoint Reference is invalid and then quits, but does not 
> unsubscribe the EPR - which means that, when in the future an event that 
> must be notified occurs, the implementation will try to notify the 
> invalid EPR again.
> 
> Guilherme

Clearly WS-N hasnt thought through/tested all the failure modes. But it 
aint our job to do it for them. So lets downgrade this to an 
optional/informative test, because that is all it can be.

-steve