Hi,

Daniel was so nice to get me informed that you can disable jaxb-validation with 

"set-jaxb-validation-event-handler" -> "false"

Now i want to apply that for a client call. But i cant apply this to a 
<jaxws:endpoint> because i dont have that service under control (means, its not 
my service)

Here is my client code to call the service (service locator)

    public IAtlasExportTransactionBF getAtlasExportTxBF(String userName, String 
password)
            throws MalformedURLException {

        AtlasExportTransactionBF service = new AtlasExportTransactionBF(new 
URL(wsdlUrl));
        IAtlasExportTransactionBF iAtlasExportTxBFPort = 
service.getIAtlasExportTransactionBFPort();

                // Set request context property.
        java.util.Map<String, Object> requestContext =
                ((javax.xml.ws.BindingProvider) 
iAtlasExportTxBFPort).getRequestContext();
        requestContext.put(BindingProvider.USERNAME_PROPERTY, userName);
        requestContext.put(BindingProvider.PASSWORD_PROPERTY, password);

        return iAtlasExportTxBFPort;
}

Which object can i use to set the property outlined above? Or do i need to go a 
different route to set it? 


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 25.01.2010 um 18:41 schrieb Daniel Kulp:

> 
> With this error, it LOOKS like the incoming soap message does not match the 
> schema for the service.   Basically, an element named "targetAESSystem" came 
> in on the wire, but JAXB doesn't know what to do with it as when JAXB 
> generated the code from the schema, there wasn't an element for it in the 
> schema.
> 
> Basically, in 2.2.5, we turned on a JAXB ValidationEventHandler that reports 
> errors when unexpected elements are found.  Previously, JAXB would just 
> ignore 
> anything unexpected (unless full schema validation was turned on)  This is 
> mostly to reduce the number of "my objects are null"  questions on the 
> forums.   
> Now, if a namespace is wrong or similar, an exception is raised. 
> 
> There really are 3 "levels" of validation with JAXB:
> 
> 1) Completely none - this was the default in <=2.2.4.  JAXB tried to continue 
> processing whenever possible ignoring anything it thinks it can ignore.   The 
> major problem is that this is VERY hard to debug.
> 
> 2) Very basic "can JAXB map an element to the generated code".   This is now 
> the default in >=2.2.5.   It isn't any slower than (1) as the (1) still calls 
> a ValidationEventHandler in those cases, it's just the default handler 
> doesn't 
> do anything.   With this level, the handler now throws and exception.   
> 
> 3) Fulll schema validation.   This level does full schema validation which is 
> a bit slower, but does make sure the incoming message matches the schema. 
> 
> With 2.2.4, only 1 and 3 were available.   If you turn on schema validation 
> in 
> 2.2.4, you would most likely see a failure as well.   With 2.2.5, you can 
> revert it to (1) by adding a property of:
> "set-jaxb-validation-event-handler" set to "false".   
> 
> 
> In any case, it's not really a bug.   The incoming soap message does not 
> match 
> the schema.   Thus, it's a bug in the incoming soap message.   The "bug" 
> would 
> be in CXF 2.2.4 and earlier in that it allowed processing of invalid messages.
> 
> Dan
> 
> 
> 
> 
> On Fri January 22 2010 10:18:23 am Marc Logemann wrote:
>> Hmmmm. No comment from the group. Is this worth a JIRA ?
>> 
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> Am 21.01.2010 um 11:48 schrieb Marc Logemann:
>>> Hi,
>>> 
>>> i can CONFIRM that this bug was introduced after 2.1.4 because we rolled
>>> back to 2.1.4 and everything is fine. I am happy to help you with
>>> informations in case you need more than already provided.
>>> 
>>> ---
>>> regards
>>> Marc Logemann
>>> http://www.logemann.org
>>> http://www.logentis.de
>>> 
>>> Am 21.01.2010 um 10:58 schrieb Marc Logemann:
>>>> Hi,
>>>> 
>>>> dont know if it has to do with upgrading to 2.2.6 (from 2.1.4) but now
>>>> after i am calling a webservice of a 3rd party, i am getting this a
>>>> stack trace. Watch out for this weird "URIMappingInterceptor can only
>>>> handle HTTP GET, not HTTP null" line. Dont know if thats the problem. I
>>>> used log4j TRACE level so that CXF Pros can see the complete story ;-)
>>>> In the meantime i will go back to CXF 2.1.4 to see what happens with
>>>> that. Because its a production issue, i must do something ;-)
>>>> 
>>>> 
>>>> ----------------------------
>>>> ID: 4
>>>> Response-Code: 200
>>>> Encoding: UTF-8
>>>> Content-Type: text/xml;charset=utf-8
>>>> Headers: {content-type=[text/xml;charset=utf-8],
>>>> connection=[Keep-Alive], transfer-encoding=[chunked], Date=[Thu, 21 Jan
>>>> 2010 09:46:45 GMT], Keep-Alive=[timeout=15, max=100],
>>>> X-Powered-By=[ASP.NET], Server=[Microsoft-IIS/6.0]} Payload: <?xml
>>>> version="1.0" ?><S:Envelope
>>>> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/";><S:Body><ns2:createO
>>>> BTAtlasResponse
>>>> xmlns:ns2="urn:de.aeb.xnsg.atlas.expdecl.bf"><result><obtID>44022584</ob
>>>> tID><createdDeclarations><targetAESSystem>ATLAS</targetAESSystem><declara
>>>> tionId>44022588</declarationId><isDeleted>false</isDeleted><clientIdentCo
>>>> de>ASWO</clientIdentCode><transactionIdHost>6710921</transactionIdHost><t
>>>> ransactionLabelHost>ASWO International 
>>>> 6710921</transactionLabelHost><organisationUnitHost>LOGENTIS</organisati
>>>> onUnitHost><internalReference>ASWO International 
>>>> 6710921</internalReference><installationId>NETVERSYS</installationId><pe
>>>> rsonInCharge><name>It
>>>> Service</name><email>it.serv...@aswo.com</email></personInCharge><refere
>>>> nceNumberAES>0000134</referenceNumberAES><consignmentId>6710921</consignm
>>>> entId><declarant><customsNumber>2503514</customsNumber><name>ASWO
>>>> International Service GmbH</name><street>Riesweg
>>>> 1</street><city>Eime</city><postCode>31036</postCode><country><isoCode>D
>>>> E</isoCode></country></declarant><exporter><country/></exporter><consigne
>>>> e><name>ASWO RS D.O.O. </name><street>KRIZANICEVA 26 LOK 1
>>>> </street><city>BELGRADE</city><postCode>11050</postCode><country><isoCod
>>>> e>RS</isoCode></country></consignee><agent><country/></agent><termsOfDeli
>>>> very><incotermsCode>EXW</incotermsCode><place>Eime</place></termsOfDelive
>>>> ry><invoicePrice><value>1136.34</value><currency>EUR</currency></invoiceP
>>>> rice><countryOfDestination><isoCode>RS</isoCode></countryOfDestination><a
>>>> dditionalFields><id>1</id><name>natureOfTransCode</name><value>11</value>
>>>> <type>string</type></additionalFields><additionalFields><id>8</id><name>i
>>>> sStandByOperationActive</name><value>false</value><type>boolean</type></a
>>>> dditionalFields><additionalFields><id>9</id><name>isOnEnquiry</name><valu
>>>> e>false</value><type>boolean</type></additionalFields><additionalFields><
>>>> id>10</id><name>shortage</name><value>false</value><type>boolean</type></
>>>> additionalFields><additionalFields><id>11</id><name>isCancelled</name><va
>>>> lue>false</value><type>boolean</type></additionalFields><additionalFields
>>>>> <id>12</id><name>isInvalid</name><value>false</value><type>boolean</type
>>>>> </additionalFields><additionalFields><id>13</id><name>isNotAccepted</nam
>>>> e><value>false</value><type>boolean</type></additionalFields><additionalF
>>>> ields><id>14</id><name>isTransmitted</name><value>false</value><type>bool
>>>> ean</type></additionalFields><additionalFields><id>15</id><name>isManuall
>>>> yCompleted</name><value>false</value><type>boolean</type></additionalFiel
>>>> ds><additionalFields><id>16</id><name>alternativeAndIndicator</name><type
>>>>> string</type></additionalFields><additionalFields><id>21</id><name>isCop
>>>> iedForStandBy</name><value>false</value><type>boolean</type></additionalF
>>>> ields><additionalFields><id>22</id><name>typeOfDeclarationProcedure</name
>>>>> <value>e</value><type>string</type></additionalFields><numberOfItems>31<
>>>> /numberOfItems><processTrafficLight>YELLOW</processTrafficLight></created
>>>> Declarations><hasErrors>false</hasErrors></result></ns2:createOBTAtlasRes
>>>> ponse></S:Body></S:Envelope> --------------------------------------
>>>> [DEBUG http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.interceptor.attachmentinintercep...@f55767 [DEBUG
>>>> http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.interceptor.staxinintercep...@13d641a [DEBUG http-8080-1
>>>> 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.binding.soap.interceptor.readheadersintercep...@1e572bc
>>>> [DEBUG http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.binding.soap.interceptor.soapactioninintercep...@176fe2a
>>>> [DEBUG http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.binding.soap.interceptor.mustunderstandintercep...@1b8326
>>>> 9 [DEBUG http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.jaxws.handler.soap.soaphandlerintercep...@113af2a [DEBUG
>>>> http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.jaxws.handler.logical.logicalhandlerinintercep...@efe50b
>>>> [DEBUG http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.binding.soap.interceptor.checkfaultintercep...@cf9abe
>>>> [DEBUG http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.jaxb.attachment.jaxbattachmentschemavalidationh...@161d07
>>>> [DEBUG http-8080-1 10:46:51] | Invoking handleMessage on interceptor
>>>> org.apache.cxf.interceptor.urimappingintercep...@1f5b983 [DEBUG
>>>> http-8080-1 10:46:51] | Invoking HTTP method null
>>>> [DEBUG http-8080-1 10:46:51] | URIMappingInterceptor can only handle
>>>> HTTP GET, not HTTP null [DEBUG http-8080-1 10:46:51] | Invoking
>>>> handleMessage on interceptor
>>>> org.apache.cxf.interceptor.docliteralinintercep...@1288475 [WARN
>>>> http-8080-1 10:46:51] | Interceptor for
>>>> {urn:de.aeb.xnsg.atlas.expdecl.bf}AtlasExportTransactionBF#{urn:de.aeb.x
>>>> nsg.atlas.expdecl.bf}createOBTAtlas has thrown exception, unwinding now
>>>> org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected
>>>> element (uri:"", local:"targetAESSystem"). Expected elements are
>>>> <{}customsStatusCode>,<{}clientIdentCode>,<{}consignee>,<{}registrationN
>>>> umberAES>,<{}internalReference>,<{}organisationUnitHost>,<{}referenceNumb
>>>> erAES>,<{}messages>,<{}boStatusIdentCode>,<{}installationId>,<{}additiona
>>>> lFields>,<{}countryOfDestination>,<{}termsOfDelivery>,<{}numberOfItems>,<
>>>> {}documents>,<{}decisiveDate>,<{}personInCharge>,<{}isDeleted>,<{}declara
>>>> nt>,<{}agent>,<{}transactionIdHost>,<{}transactionLabelHost>,<{}invoicePr
>>>> ice>,<{}declarationId>,<{}exporter>,<{}processTrafficLight>,<{}boStatusEx
>>>> tName> at
>>>> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.jav
>>>> a:764) at
>>>> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.jav
>>>> a:623) at
>>>> org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:128)
>>>> 
>>>> ---
>>>> regards
>>>> Marc Logemann
>>>> http://www.logemann.org
>>>> http://www.logentis.de
>> 
> 
> -- 
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog

Reply via email to