Another problem with Extension Points pertains to the problem of nondeterminism. This occurs when an XML processor (i.e., client, service, or validating XML parser) can’t figure out when a document or document fragment terminates. A complex type may, for example, define a sequence of elements that contains an optional telephone number element followed by an Extension Point. If the client sends the telephone number, the processor can’t know if that should be the last element or if the wildcard content in the extension might follow.
Another problem with Extension Points pertains to the problem of nondeterminism. This occurs when an XML processor (i.e., client, service, or validating XML parser) can’t figure out when a document or document fragment terminates. A complex type may, for example, define a sequence of elements that contains an optional telephone number element followed by an Extension Point. If the client sends the telephone number, the processor can’t know if that should be the last element or if the wildcard content in the extension might follow. One solution is to make everything that precedes the extension a required element, but this fundamentally alters the rules for how data is exchanged. The parties could instead identify the extension as being a required element and mark it off with Sentry Elements [Obasanjo] that surround the extension and act as delimiters.
This means that the sender must always provide an extension, but the contents of it may be left blank. While this solves the problem of nondeterminism, the party receiving this structure still has no way to predict what it might find
The only suggestion I can think of at the moment is to start from scratch and, step by step, work towards the current project (that you have problems with) to see where it goes wrong.
First of all, concerning the endpoint address in the WSDL: GlassFish will insert an appropriate endpoint address dynamically, so you need not concern yourself with this.
Second, is the Maven pom-file created entirely by NetBeans?