[jira] [Updated] (AXIS2-5295) BadgerFish JSON Reader throws invalid exception

["Andreas Veithen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AXIS2-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Veithen updated AXIS2-5295:
-----------------------------------

    Fix Version/s: 1.6.3
    
> BadgerFish JSON Reader throws invalid exception
> -----------------------------------------------
>
>                 Key: AXIS2-5295
>                 URL: https://issues.apache.org/jira/browse/AXIS2-5295
>             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, 1.6.3
>
>         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 "http://www.i2b2.org/xsd/hive/msg/1.1/" 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 equivalent.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org