Couple options:
1) I think just doing
requestContext.put("set-jaxb-validation-event-handler", "false")
would work.
2) You could do something like:
BusFactory.getDefaultBus().setProperty(.....)
which would make it apply to EVERYTHING.
3)
Client c = ClientProxy.getClient(iAtlasExportTxBFPort);
c.getEndpoint().setProperty(...)
Dan
On Thu January 28 2010 5:18:08 am Marc Logemann wrote:
> 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.
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
