[
https://issues.apache.org/jira/browse/CXF-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245111#comment-14245111
]
Thomas Whitmore edited comment on CXF-6118 at 12/13/14 2:15 AM:
----------------------------------------------------------------
Sorry for the delayed response -- just moved to a new job, so limited time to
wrap up before I left. We did verify your workaround (moving service
annotations to the implementation, not the interface) and were able to get a
good solution with this.
Reading your comment & the Nabble thread quickly: "An IN for service is the
OUT for client." This is fundamental & I think the touchstone.
- I think I read that you've fixed the code that forcibly override Client
settings from the Service model/ or whatever. That's much better.
re: Daniel Kulp: "I’m -1 on the part of this that changes the IN to an OUT on
the client side".
- IN and OUT direction specifiers are, fundamentally, relative to the endpoint.
- they are not objective, since they have no external frame of reference.
(REQUEST and RESPONSE are framed objectively with regard to the interaction.)
- any Model that assumes IN direction can be applied to either endpoint
equally, is insufficient.
We should not need to "change IN to OUT" for Client side in a static way; a
specifier on Client.IN should still refer to the response.
Instead, the correct understanding should be dynamic -- that we _apply Service
specifications to the Client_ with direction reversed. This does not affect
correct specification at either end, it only corrects the _defaulting or
application between ends_.
---
REQUEST and RESPONSE are Ok as a concept -- using an external frame of
reference for direction, rather than being endpoint-relative, is potentially a
good idea. However, I would be lukewarm about adding more API surface, as IN &
OUT were not well known yet -- most examples focused on "true" or "false".
Achieving a solid conceptual footing is, however, definitely useful.
Re: Daniel Kulp's comments about weakening the schema, this was essentially
about "optionality" of content rather than blatantly invalid data. Service used
an existing schema (specified to submit only complete & correct applications),
but extended the scope to retrieve "draft" status application -- which may have
only partial data.
Business decision was to develop initially using the already-published schema.
This avoided cost of versioning & publishing a new separate schema, which would
be equivalent value-wise but merely looser as to optionality.
Anyway, thanks for your amazingly rapid assistance & updates.
Best regards,
Thomas
was (Author: thomasw_nz):
Sorry for the delayed response -- just moved to a new job, so limited time to
wrap up before I left. We did verify your workaround (moving service
annotations to the implementation, not the interface) and were able to get a
good solution with this.
Reading your comment & the Nabble thread quickly: "An IN for service is the
OUT for client." This is fundamental & I think the touchstone.
- I think I read that you've fixed the code that forcibly override Client
settings from the Service model/ or whatever. That's much better.
re: Daniel Kulp: "I’m -1 on the part of this that changes the IN to an OUT on
the client side".
- IN and OUT direction specifiers are, fundamentally, relative to the endpoint.
- they are not objective, since they have no external frame of reference.
(REQUEST and RESPONSE are framed objectively with regard to the interaction.)
- any Model that assumes IN direction can be applied to either endpoint
equally, is incorrect & insufficient. (This last point is a design cornerstone.)
I'm not sure what exactly's missing, there are a couple of possibilities; but
either the Model has to understand directionality as "swapped" between ends, or
it has to distinguish Service and Client ends. Either/or.
So I thought what I read of Jason's change seemed reasonable & provably sound.
Recasting the model on objective terms is an alternative, but more complex.
---
REQUEST and RESPONSE are Ok as a concept -- using an external frame of
reference for direction, rather than being endpoint-relative, is potentially a
good idea. However, I would be lukewarm about adding more API surface, as IN &
OUT were not well known yet -- most examples focused on "true" or "false".
Achieving a solid conceptual footing is, however, definitely useful.
Re: Daniel Kulp's comments about weakening the schema, this was essentially
about "optionality" of content rather than blatantly invalid data. Service used
an existing schema (specified to submit only complete & correct applications),
but extended the scope to retrieve "draft" status application -- which may have
only partial data.
Business decision was to develop initially using the already-published schema.
This avoided cost of versioning & publishing a new separate schema, which would
be equivalent value-wise but merely looser as to optionality.
Anyway, thanks for your amazingly rapid assistance & updates.
Best regards,
Thomas
> Schema Validation refinements
> -----------------------------
>
> Key: CXF-6118
> URL: https://issues.apache.org/jira/browse/CXF-6118
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 2.7.8, 2.7.13, 3.0.2
> Environment: Java 1.7.0_51,
> Spring Framework 3.2.0,
> Windows 7
> Reporter: Thomas Whitmore
> Assignee: Jason Pell
> Priority: Minor
> Labels: client, operation, schema, validation
> Fix For: 3.1.0, 3.0.3, 2.7.14
>
> Attachments: problem example.zip
>
>
> Disabling input schema-validation for my <jaxws:client> was unsuccessful
> following the docs. Neither 'false' nor 'NONE' were effective and the client
> (an integration test) was still validating & throwing exceptions.
> Debugging the CXF code, I found Message.SCHEMA_VALIDATION_ENABLED being set
> to 'IN' by code in
> AbstractInDatabindingInterceptor.setOperationSchemaValidation(). This setting
> of 'IN' appears to be coming from the Service/ Endpoint definitions!
> I had defined the service (LoanApplicationWS) as validating IN (by means of
> annotations). When I changed the service validation to NONE, client was no
> longer forced to validate.
> There are two issues here:
> 1) Service/Endpoint validation settings, should not automatically be
> overriding Client settings
> 2) Service OUT validation corresponds to Client IN validation; the
> directions are inverted.
> The background here, is to extend a service & schema designed for "complete"
> Loan Applications to be able to retrieve "draft" applications -- which are
> only partly-formed, and thus do not include some elements required in the
> schema.
> For this reason, I intend to disable output validation of the Service; and
> correspondingly disable input validation at the Client.
> However, CXF is somehow finding validation settings Service/Endpoint and
> applying them (in an incorrect directional sense) to the Client.
> I've included screenshots of the Client 1) broken and 2) working, according
> to changes to the Service validation setting.
> Please find a partial project attached containing a few relevant files & the
> screenshots.
> Thanks,
> Regards
> Thomas
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
