Policy error check should produce line number and system ID

[glassfishrobot]

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".

Environment

Operating System: All Platform: All

Affected Versions

[current]

[glassfishrobot]

Reported by kohsuke@java.net

[glassfishrobot]

kohsuke@java.net said: Assigning it to Fabian. I understand that he is the maintainer of the policy code.

[glassfishrobot]

ritzmann@java.net said: 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.

[glassfishrobot]

kohsuke@java.net said: 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.

[glassfishrobot]

ritzmann@java.net said: Copied to WSIT issue tracker: https://wsit.dev.java.net/issues/show_bug.cgi?id=1049

[glassfishrobot]

Was assigned to metro-issues

[glassfishrobot]

This issue was imported from java.net JIRA METRO-9

[glassfishrobot]

Marked as won't fix on Tuesday, October 28th 2008, 7:06:32 pm