Return-Path: X-Original-To: apmail-cxf-users-archive@www.apache.org Delivered-To: apmail-cxf-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 386EDD53F for ; Thu, 20 Sep 2012 16:29:03 +0000 (UTC) Received: (qmail 75400 invoked by uid 500); 20 Sep 2012 16:29:02 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 75353 invoked by uid 500); 20 Sep 2012 16:29:02 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 75344 invoked by uid 99); 20 Sep 2012 16:29:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Sep 2012 16:29:02 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sberyozkin@gmail.com designates 74.125.83.41 as permitted sender) Received: from [74.125.83.41] (HELO mail-ee0-f41.google.com) (74.125.83.41) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Sep 2012 16:28:56 +0000 Received: by eeil10 with SMTP id l10so576302eei.0 for ; Thu, 20 Sep 2012 09:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GG1rE5y1QktMVr3SWyjDz9UFfNrIJYmADot0T8tPqRo=; b=n348pzxyHWPndUYhOT3aHC3U9uxXdcN/0EKCxJnqHMj/O/7r2F+bzpAaz7lg6AtoVj 2h2VkRpk5FH2mIZPyHAQc7PZ9mSMStoGIpZAks6aFDEryiqviA/tRf+FyTS3PEnnpOzj NeltzQt/7At2libzo86/LANIBe+lK5K8uM/ZvO7ehhrEoZSEYGmNwH5mr7gb4kY5pQ2X vg0HGTZjFrHBs2QLJLLwbz/rvVs68N7rC+4K+IJbv7JyL0tpzFiGvqDIrizrCWmODyKM scga/txoSJMSmoaM1/KQgEgnj1wJnQVy+Pmp6dsBzt2T1dQl/KYDtgnP6HQ99j7wfeQk FDJA== Received: by 10.14.182.134 with SMTP id o6mr2909848eem.26.1348158514775; Thu, 20 Sep 2012 09:28:34 -0700 (PDT) Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id e7sm16936904eep.2.2012.09.20.09.28.33 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 09:28:34 -0700 (PDT) Message-ID: <505B4431.4040904@gmail.com> Date: Thu, 20 Sep 2012 17:28:33 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "users@cxf.apache.org" Subject: Re: UnmarshalException instead of SchemaValidationException References: <771817DCAFFE28449279ED8AAFECEDFC011CAF8D29@kaex04.fiz-karlsruhe.de> <505B0B7D.7060409@gmail.com> <771817DCAFFE28449279ED8AAFECEDFC011CAF8D6A@kaex04.fiz-karlsruhe.de> <505B265D.9010302@gmail.com> <771817DCAFFE28449279ED8AAFECEDFC011CAF8DC5@kaex04.fiz-karlsruhe.de> <505B2CC3.5090204@gmail.com> <505B30E1.7060405@gmail.com> <505B3585.4090208@gmail.com> <771817DCAFFE28449279ED8AAFECEDFC011CAF8E14@kaex04.fiz-karlsruhe.de> <9DAFA6D0-C90D-4344-ACB4-85F7E70D77E0@apache.org> <505B43BD.20606@gmail.com> In-Reply-To: <505B43BD.20606@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org a would be ServiceB was wrongly typed, should be @Path("/root/b") public void ServiceB { @POST public B postB(B) {} } Sergey On 20/09/12 17:26, Sergey Beryozkin wrote: > On 20/09/12 17:11, Daniel Kulp wrote: >> >> On Sep 20, 2012, at 12:04 PM, "Vo�, >> Marko" 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� >> > Indeed. May be one more option, if that is possible, to split the > original endpoint into two ones, say if we have > > @Path("/root") > public void Service { > @Path("/a") > @POST > public A postA(A) {} > > @Path("/b") > @POST > public B postA(B) {} > } > > then it can be split into two endpoints. with each of them - having > unique schemas: > > > @Path("/root/a") > public void ServiceA { > @POST > public A postA(A) {} > } > > > @Path("/root/b") > public void ServiceB { > @Path("/b") > @POST > public B postA(B) {} > } > > Cheers, Sergey > > >> >> Dan >> >> >>> >>> >>> Best, >>> >>> -----Original Message----- >>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com] >>> Sent: Thursday, September 20, 2012 5:26 PM >>> To: Vo�, Marko >>> Cc: users@cxf.apache.org >>> 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:sberyozkin@gmail.com] >>>>>> Sent: Thursday, September 20, 2012 4:21 PM >>>>>> To: Vo�, Marko >>>>>> Cc: users@cxf.apache.org >>>>>> 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: >>>>>>> >>>>>>> >>>>>> name="catalogLocation" value="..."/> >>>>>> name="schemaLocations" value="..."> >>>>>>> classpath:/xsd/foo.xsd >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 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:sberyozkin@gmail.com] >>>>>>> Sent: Thursday, September 20, 2012 2:27 PM >>>>>>> To: users@cxf.apache.org >>>>>>> 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 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. >>> >>> >> >