This is known issue.
Depends also on enhancement 105645. 

The issue is pretty serious and it's caused by incorrect implementation of ClassPathProvider in WEB / EJB project.
The build/generated/wsimport/service root is not involved to project's classpath.

Specifically, findClassPath method uses the generic - javaClassPathProvider object to compute classpath :
====
    public ClassPath findClassPath(FileObject file, String type) {
        ClassPath cp = javaClassPathProvider.findClassPath(file, type);
        if (cp != null) {
            return cp;
        }
        FileType fileType = getType(file);
        if (type.equals(ClassPath.COMPILE)) {
            cp = getCompileTimeClasspath(fileType);
        } else if (type.equals(ClassPath.EXECUTE)) {
            cp = getRunTimeClasspath(fileType);
        } else if (type.equals(ClassPath.SOURCE)) {
            cp = getSourcepath(fileType);
        } else if (type.equals("classpath/packaged")) { // NOI18N
            cp = getPackagedClasspath(fileType);
        }
        return cp;
    }
====
Unfortunately, that generic javaClassPathProvider object doesn't include build/generated/wsimport/service root. 

I fixed this temporarily in ClassPathSupportFactory class:
http://hg.netbeans.org/main?cmd=changeset;node=208f6a1698ee

In the feature, after issue 105645 is implemented (generic folder for all generated source root) all hard coded source
roots from SourcePathImplementation class should be removed.

Please revert 208f6a1698ee. It impacts all existing project types using it. I remember J2SE project having using test
which your hotfix broke. If you need to hotfix this then change Ejb and/or Web project. Btw. Web project already calls
createSourcePathImplementation with canHaveWebServices=true. And for Ejb you may need to extend ClassPathProviderImpl
constructor to take canHaveWebServices as well.

The hot fix was reverted: http://hg.netbeans.org/main?cmd=changeset;node=bc3c50146339

Now it's on web and ejb project to fix the issue:
build/generated/wsimport/service folder is not on project's source classpath

To test this issue: create WS from WSDL (Web Services wizard category) from attached wsdl file.
You'll see that 
org.example.duke.AddNumbersFault_Exception is badged with errors

Created attachment 74838 [details]
wsdl file for testing

According to the issue 105645 the required enhancement should be in NB 7.  So my question is why put temporary fix in until the new API is completed?

The answer:
I was trying to fix the regression caused by David Konecny with his refactoring (new implementation) of classpath
provider in Web and Ejb. The code completion for web services should work regardless issue 105645 is implemented or not.

The dependency on 105645 means that when this is implemented we can remove all hard coded source roots from
SourcePathImplementation.

Integrated into 'main-golden', will be available in build *200812111401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/208f6a1698ee
User: mkuchtiak@netbeans.org
Log: #154046: since Web/EJB project's classpath is derived from generic (J2SE) project classpath, canHeveWebServices param must be se to true

Fixed locally as 22947ec15993 by adding canHaveWebServices parameter to java.api.common.ClassPathProviderImpl.

Integrated into 'main-golden', will be available in build *200812121401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/bc3c50146339
User: mkuchtiak@netbeans.org
Log: #154046: reverting hot fix

The generated sources are now handled as normal sources.
See the issue 105645.