axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] [Resolved] (AXIS2-5295) BadgerFish JSON Reader throws invalid exception
Date Wed, 02 May 2012 19:38:50 GMT


Andreas Veithen resolved AXIS2-5295.

       Resolution: Fixed
    Fix Version/s: 1.7.0

Badgerfish is now fully supported with data bindings. The implementation uses the feature
introduced by AXIOM-399.
> BadgerFish JSON Reader throws invalid exception
> -----------------------------------------------
>                 Key: AXIS2-5295
>                 URL:
>             Project: Axis2
>          Issue Type: Bug
>          Components: json
>    Affects Versions: 1.6.1, 1.6.2
>            Reporter: Jeremy Nix
>            Assignee: Andreas Veithen
>             Fix For: 1.7.0
>         Attachments: axiom_patch.txt, badgerfish_request.json, soap_request.xml
> I was unable to use the Badgerfish JSON implementation out of the box.  It kept throwing
an exception ["Element namespace from data source is ""
not the expected].  I tried various configuration modifications before I dove into the code
to see what was happening.  I tracked it down to an exception thrown in the Axiom-Impl OMSOurcedElementImpl#forceExpand
method.  It is checking that its namespace matches whatever the datasource reader's namespace
is.  The problem is that the OMSourcedElementImpl is created in AbstractJSONOMBuilder with
no namespaces parsed out.  Parsing out of the namespaces occurs later once the BadgerFishXMLStreamReader
is instantiated.
> To get around this issue, I saw a few possible options.  1) Update the AbstractJSONOMBuilder
(or JSONBadgerfishOMBuilder) and change the processDocument method to dig further into the
stream and parse out the namespace(s).  The problem with this solution is that I was worried
about what ramifications would result now that we have read past the first element/object
in the JSON input stream.  2) Update OMSourcedElementImpl and disable this validation check.
> I opted to go with the second solution.  I'm sure that it was put there for a reason,
so a more elegant hack may involve looking at the content type and only avoiding this check
if the content type is application/badgerfish/json (or similar).
> I'm going to attach my hack along with an example SOAP request and its badgerfish json

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message