On Sep 20, 2012, at 12:04 PM, "Voß, Marko" <[email protected]> wrote:
> I'll talk to the team tomorrow. Maybe the new behavior is acceptable but I > doubt that. CXF just keeps a javax.xml.validation.Schema object around that represents the schema for the entire service. We pass that into JAXB. We don't have the ability to have a separate Schema object per operation at this time. I'd be open for a patch for this, but quite honestly, I'm not sure how the configuration for that would look. You would need a way to configure a unique schema for each operation/type which would result in a bunch of .xsd files, etc… Dan > > > Best, > > -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Thursday, September 20, 2012 5:26 PM > To: Voß, Marko > Cc: [email protected] > Subject: Re: UnmarshalException instead of SchemaValidationException > > One more thing, after seeing a response from Dan in the other thread, > > Unmarshaller.Listener can also be registered with the provider, not sure it > can help in your case, but mentioning it just in case > > Sergey > On 20/09/12 16:06, Sergey Beryozkin wrote: >> On 20/09/12 15:48, Sergey Beryozkin wrote: >>> On 20/09/12 15:39, Voß, Marko wrote: >>>>> I guess I'm not understanding the problem well. You said earlier: >>>> >>>>>>> In a negative test, I send some XML to this service, which is >>>>>>> wrong XML for type A. Let's say the XML is of type B. The XML >>>>>>> passes the schema validation, because of it is valid for type B". >>>> >>>>> AFAIK, at the schema validation level, all JAXB does is ensures the >>>>> incoming XML is valid according to the schema, which it is >>>>> according to what you said earlier on. >>>> >>>> In the old code of this service, the service validated the incoming >>>> XML against the schema of the expected type. >>>> In the example, the XML got validated against the schema of type A, >>>> no matter what XML was incoming. I expected the same behavior with >>>> CXF, since I define the expected type in the signature. >>>> >>>>> Unmarshalling is at the next stage, so if the previous stage let 'B' >>>>> to come in then obviously the unmarshaller expecting it to be 'A' >>>>> throws UnmarshallException. I do not see how to make >>>>> SchemaValidationException thrown if the schema validation phase >>>>> passes... >>>> >>>> I meant, that the schema validation phase should not pass, because >>>> the wrong schema is being used right now. >>> >>> Well, you have a schema document which is registered with the JAXB >>> provider so this is what is used to validate the incoming XML. >>> >>> >>>> It should use the schema of the type defined in the signature and >>>> not the schema, which fits to the incoming XML. >>> >>> Is it possible in JAXB to configure Unmrashaller such that it >>> validates the incoming XML based on the information it obtains while >>> populating A, some kind of Java-based in validation ? >>> >>> If yes we can do that >> >> In fact this can probably be enforced at the custom XMLStreamReader level. >> What about this: >> - register custom RequestHandler filter >> - at that level we know the matching Method >> - know, register the basic XMLStreamReader on the current message >> (extending the CXF helper reader), initialized with the info obtained >> from the Method or say from XmlType annotation on the relevant class). >> If the root XML name is not matching the expectations - throw the >> schema validation exception... >> >> Not sure if it is something that will do in your case, but technically >> it can be easily done, can provide more info if needed... >> >> Cheers, Sergey >> >> >> >>> >>> Cheers, Sergey >>> >>> >>>> >>>> -----Original Message----- >>>> From: Sergey Beryozkin [mailto:[email protected]] >>>> Sent: Thursday, September 20, 2012 4:21 PM >>>> To: Voß, Marko >>>> Cc: [email protected] >>>> Subject: Re: UnmarshalException instead of SchemaValidationException >>>> >>>> On 20/09/12 14:08, Voß, Marko wrote: >>>>> Hello, >>>>> >>>>>> I guess if a schema is open enough to accept either A or B >>>>>> representations, then there's no bug. >>>>> >>>>> That is not the case here. >>>>> >>>> >>>> I guess I'm not understanding the problem well. You said earlier: >>>> >>>>>> In a negative test, I send some XML to this service, which is >>>>>> wrong >>>> XML for type A. Let's say the XML is of type B. The XML passes the >>>> schema validation, because of it is valid for type B". >>>> >>>> AFAIK, at the schema validation level, all JAXB does is ensures the >>>> incoming XML is valid according to the schema, which it is according >>>> to what you said earlier on. >>>> >>>> Unmarshalling is at the next stage, so if the previous stage let 'B' >>>> to come in then obviously the unmarshaller expecting it to be 'A' >>>> throws UnmarshallException. I do not see how to make >>>> SchemaValidationException thrown if the schema validation phase >>>> passes... >>>> >>>>>> I can see that Unmarshaller can also accept ValidationEventHandler >>>>>> ("validationHandler" provider property). Not sure if it can help - >>>>>> may be you can restrict it there somehow. >>>>> >>>>> Well, we are using the schema validation setup this way already: >>>>> >>>>> <bean name"myJaxbProvider" class="..."> <property >>>>> name="catalogLocation" value="..."/> <property >>>>> name="schemaLocations" value="..."> <list> >>>>> <value>classpath:/xsd/foo.xsd</value> >>>>> ... >>>>> </list> >>>>> </property> >>>>> </bean> >>>>> >>>>> So we have to setup the validation twice or remove this kind of >>>>> validation, we have been talking about lately, and use the >>>>> validationHandler instead? >>>>> >>>> I think ValidationEventHandler is there to complement the validation >>>> set up, for the handler to get more info about the validation >>>> process >>>> >>>>>> May my using JAXBElement<A> instead of A is more restrictive, can >>>>>> you try it ? >>>>> >>>>> Tested this with no difference in the result. >>>>> >>>> OK... >>>> >>>> Cheers, Sergey >>>>> >>>>> Best, >>>>> >>>>> -----Original Message----- >>>>> From: Sergey Beryozkin [mailto:[email protected]] >>>>> Sent: Thursday, September 20, 2012 2:27 PM >>>>> To: [email protected] >>>>> Cc: Voß, Marko >>>>> Subject: Re: UnmarshalException instead of >>>>> SchemaValidationException >>>>> >>>>> Hi >>>>> On 20/09/12 13:02, Voß, Marko wrote: >>>>>> Hello, >>>>>> >>>>>> Say, we have a JAX-RS method like this: >>>>>> >>>>>> @PUT >>>>>> @Path("/foo") >>>>>> @Produces(MediaType.TEXT_XML) >>>>>> @Consumes(MediaType.TEXT_XML) >>>>>> public static A create(A a); >>>>>> >>>>>> In a negative test, I send some XML to this service, which is >>>>>> wrong XML for type A. Let's say the XML is of type B. The XML >>>>>> passes the schema validation, because of it is valid for type B >>>>>> but this method expects type A and so we get a UnmarshalException >>>>>> instead of the SchemaValidationException complaining about the wrong >>>>>> element found. >>>>>> >>>>>> Is it a bug, that the schema validation is not using the schema >>>>>> for type A? It looks like it is using the schema, which is >>>>>> responsible for the root element of the passed XML if found. >>>>>> >>>>> >>>>> I guess if a schema is open enough to accept either A or B >>>>> representations, then there's no bug. >>>>> >>>>> I can see that Unmarshaller can also accept ValidationEventHandler >>>>> ("validationHandler" provider property). Not sure if it can help - >>>>> may be you can restrict it there somehow. >>>>> >>>>> May my using JAXBElement<A> instead of A is more restrictive, can >>>>> you try it ? >>>>> >>>>> Cheers, Sergey >>>>> >>>>>> best, >>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> >>>>>> Fachinformationszentrum Karlsruhe, Gesellschaft für >>>>>> wissenschaftlich-technische Information mbH. >>>>>> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht >>>>>> Mannheim HRB 101892. >>>>>> Geschäftsführerin: Sabine Brünger-Weilandt. >>>>>> Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner. >>>>>> >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> >>>>> Fachinformationszentrum Karlsruhe, Gesellschaft für >>>>> wissenschaftlich-technische Information mbH. >>>>> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht >>>>> Mannheim HRB 101892. >>>>> Geschäftsführerin: Sabine Brünger-Weilandt. >>>>> Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner. >>>>> >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> >>>> Fachinformationszentrum Karlsruhe, Gesellschaft für >>>> wissenschaftlich-technische Information mbH. >>>> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht >>>> Mannheim HRB 101892. >>>> Geschäftsführerin: Sabine Brünger-Weilandt. >>>> Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner. >>>> >>>> >> >> > > > > > ------------------------------------------------------- > > Fachinformationszentrum Karlsruhe, Gesellschaft für > wissenschaftlich-technische Information mbH. > Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB > 101892. > Geschäftsführerin: Sabine Brünger-Weilandt. > Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner. > > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
