This sort of request might return a response code of 200 in a more typical web request with perhaps a relevant error message or similar. It felt that within a service – no human action, intervention or response – something a little more informative or appropriate was required such as 422 Unprocessable Entity.

To achieve this I defined an out fault interceptor as follows.

        <jaxws:outFaultInterceptors>
            <bean class="mypackage.MyServiceOutInterceptor"/>
        </jaxws:outFaultInterceptors>

The implementation was rather simple in the end:

public class MyServiceOutInterceptor extends AbstractSoapInterceptor {

    public MyServiceOutInterceptor() {
        super(Phase.SEND);
    }

    public void handleMessage(SoapMessage soapMessage) throws Fault {

        Set<Class<?>> formats = soapMessage.getContentFormats();
        for (Class<?> format : formats) {

            Object content = soapMessage.getContent(format);
            if (isServiceError(content)) {
                ServiceFaultException exception = asServiceError(content);
                soapMessage.put(org.apache.cxf.message.Message.RESPONSE_CODE, exception.getResponseCode());
                break;
            }

        }

    }

    private ServiceFaultException asServiceError(Object content) {
        return (ServiceFaultException) ((Fault) content).getCause();
    }

    private boolean isServiceError(Object content) {
        return (content.getClass().isAssignableFrom(SoapFault.class))
                && (((Fault) content).getCause() instanceof ServiceFaultException);
    }

}

We check that we have a valid error, and then deliberately set the response code for the SOAP message.

The ServiceFaultException class shown above is defined as a web fault using @WebFault and the relevant error message and code is set as required.

So, the merits of returning 422 for an entity that can not be found aside, the above demonstrates how to change the response code returned as a part of a SOAP fault to anything you like.

Admittedly when registering on a new site I almost always just cut and paste my password into the repeat password field. Indeed with various systems now insisting on specific character patterns, i would imagine the purpose-defeating practice of cut/paste into the repeat password field is only more prevalent. The Smashing piece includes a JQuery plugin that allows for a single password field that may be toggled to show the entered password – definitely worth a look.

The login user name suggestion is much simpler – allow users the ability to login with either a user name or email address – both should be unique in any case and your email address is certainly harder to forget.

Check the article out here — Innovative Techniques To Simplify Sign-Ups and Log-Ins.

Some other useful login/sign-up resources i’ve found useful in the past are listed below.

• http://www.smashingmagazine.com/2008/07/04/web-form-design-patterns-sign-up-forms/
• http://www.hongkiat.com/blog/login-registration-form/
• http://www.smashingmagazine.com/2009/06/23/10-ui-design-patterns-you-should-be-paying-attention-to/

In my subsequent travels i found Favicon Builder.  Simply upload a gif, jpg or png image and it generates a favicon that rendered perfectly. The generated download is a zip archive with a readme file, animated icon as a gif, favicon ico and a couple of scaled png files. Very nice

I modified one of them slightly and now use it as the new look for executequery.org.