Policy error check should produce line number and system ID

Copied over from [https://metro.dev.java.net/issues/show_bug.cgi?id=9](https://metro.dev.java.net/issues/show_bug.cgi?id=9)

Sometimes policy code succeeds in reporting an error (the following is a result
of intentionally putting a bogus element in the policy), but for this to be
useful, it also needs to report a line number and system ID, so that the
developer can see where the mistake is made.

That's an error handling 101.

------
Oct 28, 2008 11:54:55 AM [com.sun.xml.ws.policy.EffectiveAlternativeSelector]
selectBestAlternative
WARNING: WSP0075: Policy assertion
"

{http://schemas.sun.com/2006/03/wss/client}

NoSuchThing" was evaluated as
"UNKNOWN".

------- Additional comments from kohsuke Tue Oct 28 19:57:00 +0000 2008 -------
Assigning it to Fabian. I understand that he is the maintainer of the policy
code.

------- Additional comments from ritzmann Tue Oct 28 20:50:18 +0000 2008 -------
Please submit these bugs under wsit.dev.java.net in the future.

A policy on the client side typically is a merge of multiple policies. When you
have a policy like this on the server:

and a policy like this on the client:

The client will see:

We would have to maintain a reference to the source location for every single
assertion. It is also possible to merge policies with the same assertions in
them. The resulting policy will only contain one instance of that assertion. In
that case we would have to maintain a list of references to the source
locations for the assertion. In most cases, when the policy parsing code is
invoked through the JAX-WS WSDL parser, we do not have access to the location
of the WSDL document that contains the policies at all.

------- Additional comments from kohsuke Tue Oct 28 23:41:58 +0000 2008 -------
Yes, the policy code needs to remember where every single assertions came from,
and yes, that's what we do elsewhere — javac remembers line and column number
for every AST node, XJC and wsimport remembers where every binding came from,
JAXP schema validator remembers where each declaration came from, and so is the
rest of the WSDL model in the JAX-WS runtime.

And I could be wrong, but WSDLParserExtension gives you XMLStreamReader, which
has the location information via XMLStreamReader.getLocation(). So you do have
the location information, don't you.
#### Environment
Operating System: All
Platform: All
URL: [https://metro.dev.java.net/issues/show_bug.cgi?id=9](https://metro.dev.java.net/issues/show_bug.cgi?id=9)
#### Affected Versions
[current]

Source: [https://github.com/javaee/metro-wsit/issues/1049](https://github.com/javaee/metro-wsit/issues/1049)
Author: glassfishrobot

Start with the policy code entry point named in the report, EffectiveAlternativeSelector, and inspect how WSDLParserExtension and XMLStreamReader.getLocation() are involved. Review the discussion about merged policies and missing document locations before defining the scope. Done means policy errors can identify the relevant line number and system ID, with tests demonstrating that information.

Written by the indexing model from the issue text.