cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Whitmore (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CXF-6118) Schema Validation refinements
Date Sat, 13 Dec 2014 02:11:13 GMT

    [ 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:10 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 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


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)

Mime
View raw message