Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.0
    • Component/s: None
    • Labels:
      None
    1. xmlbeans.diff
      261 kB
      Piotr Zagorski
    2. jaxb-patch.diff
      189 kB
      Aaron Anderson
    3. HISE-68.patch
      333 kB
      Michał Więcław
    4. HISE-68.patch
      78 kB
      Pawel Byszewski

      Issue Links

        Activity

        Hide
        Piotr Zagorski added a comment - - edited

        Namespace context of expressions is available with xmlbeans.

        Show
        Piotr Zagorski added a comment - - edited Namespace context of expressions is available with xmlbeans.
        Hide
        Pawel Byszewski added a comment -

        tests fixed

        Show
        Pawel Byszewski added a comment - tests fixed
        Hide
        Rafal Rusin added a comment -

        Thanks!

        Show
        Rafal Rusin added a comment - Thanks!
        Hide
        Aaron Anderson added a comment -

        I am curious to know more about the issues with JAXB that caused the switch to XMLBeans. Can anyone explain the details around this issue?

        Show
        Aaron Anderson added a comment - I am curious to know more about the issues with JAXB that caused the switch to XMLBeans. Can anyone explain the details around this issue?
        Hide
        Rafal Rusin added a comment -

        The main problem is that JAXB doesn't hold namespace prefixes after parsing XML file into Java objects. So this issue blocks HISE-72, which is a great improvement in defining expressions inside HTD files. (No need to repeat 'declare namespace' for each expression).

        Regards

        Show
        Rafal Rusin added a comment - The main problem is that JAXB doesn't hold namespace prefixes after parsing XML file into Java objects. So this issue blocks HISE-72 , which is a great improvement in defining expressions inside HTD files. (No need to repeat 'declare namespace' for each expression). Regards
        Hide
        Aaron Anderson added a comment -

        While the default JAXB binding configuration does not retain namespace information for the HTD expression nodes I believe the JAXB binding configuration can be modified to do so. It seems that most of the HTD expressions are of types TExpression and TExtensibleMixedContentElements. Both of these types are XML mixed types and the preferred JAXB binding for mixed types is a w3c DOM. If the HTD expressions were represented as DOM objects then the namespaces could easily be retrieved by invoking the DOM lookupNamespaceURI method and then the prefix/namespaces could be programatically declared to Saxon. Having the expression nodes as DOM objects would probably be more efficient than the previous conversion of JAXB generated strings back to DOM nodes for XQuery evaluation. Another option would be to create a custom JAXB javaType binding in the JAXB custom binding file and specify a parse and print methods as well as setting the hasNsContext JAXB attribute to true so that the curent NameSpaceContext could be passed in and retained in the generated Java object.

        If desired I could demonstrate either of these approaches using a recent revision of the trunk prior to the conversion to XMLBeans.

        Show
        Aaron Anderson added a comment - While the default JAXB binding configuration does not retain namespace information for the HTD expression nodes I believe the JAXB binding configuration can be modified to do so. It seems that most of the HTD expressions are of types TExpression and TExtensibleMixedContentElements. Both of these types are XML mixed types and the preferred JAXB binding for mixed types is a w3c DOM. If the HTD expressions were represented as DOM objects then the namespaces could easily be retrieved by invoking the DOM lookupNamespaceURI method and then the prefix/namespaces could be programatically declared to Saxon. Having the expression nodes as DOM objects would probably be more efficient than the previous conversion of JAXB generated strings back to DOM nodes for XQuery evaluation. Another option would be to create a custom JAXB javaType binding in the JAXB custom binding file and specify a parse and print methods as well as setting the hasNsContext JAXB attribute to true so that the curent NameSpaceContext could be passed in and retained in the generated Java object. If desired I could demonstrate either of these approaches using a recent revision of the trunk prior to the conversion to XMLBeans.
        Hide
        Piotr Zagorski added a comment -

        Why do you think JAXB is better?

        At the beginning I did not want to remove JAXB but I encountered difficulties.
        1. JAXB object but also marshalled jaxb object does not retain all declared namespaces. I do not know how can I change this using the binding configuration.
        2. I think that by using <jaxb:dom/> I could get only fragment of the document tree. That fragment doesn't contain "unused" namespace declarations from parent nodes.
        3. hasNsContext is not supported by the JAXB RI. https://jaxb.dev.java.net/issues/show_bug.cgi?id=670

        Now, HISE reaches stability after the change. I do not know whether we want revert to JAXB. Rafał decides.
        I'm curious about a solution to this problem, so let me know if you have one.

        Show
        Piotr Zagorski added a comment - Why do you think JAXB is better? At the beginning I did not want to remove JAXB but I encountered difficulties. 1. JAXB object but also marshalled jaxb object does not retain all declared namespaces. I do not know how can I change this using the binding configuration. 2. I think that by using <jaxb:dom/> I could get only fragment of the document tree. That fragment doesn't contain "unused" namespace declarations from parent nodes. 3. hasNsContext is not supported by the JAXB RI. https://jaxb.dev.java.net/issues/show_bug.cgi?id=670 Now, HISE reaches stability after the change. I do not know whether we want revert to JAXB. Rafał decides. I'm curious about a solution to this problem, so let me know if you have one.
        Hide
        Aaron Anderson added a comment -

        The main reason I would like HISE to continue to use JAXB is that it is an official JCP standard and it is fully integrated into JAXWS. A couple months ago I made a contribution to remove the direct dependency on Spring so that HISE could be used in other frameworks such as JavaEE 6 and SCA. I am currently working on a JavaEE 6 deployment framework for HISE but unfortunately I have not been able to complete it due to recent increases in work and travel for my job. The switch to XMLBeans may halt my work since I am unfamiliar with XMLBeans and I don't believe their is native support for a XMLBeans binding for JAXWS outside of CFX. There was no discussion on the HISE development list on the challenges of using JAXB or the decision to switch to XMLBeans otherwise I would have offered to contribute to related issues earlier. It appears you have already looked into JAXB DOM bindings and didn't have any success and due to time constraints switching to XMLBeans was the only option. I will see if I can find an adequate JAXB solution and report back.

        Show
        Aaron Anderson added a comment - The main reason I would like HISE to continue to use JAXB is that it is an official JCP standard and it is fully integrated into JAXWS. A couple months ago I made a contribution to remove the direct dependency on Spring so that HISE could be used in other frameworks such as JavaEE 6 and SCA. I am currently working on a JavaEE 6 deployment framework for HISE but unfortunately I have not been able to complete it due to recent increases in work and travel for my job. The switch to XMLBeans may halt my work since I am unfamiliar with XMLBeans and I don't believe their is native support for a XMLBeans binding for JAXWS outside of CFX. There was no discussion on the HISE development list on the challenges of using JAXB or the decision to switch to XMLBeans otherwise I would have offered to contribute to related issues earlier. It appears you have already looked into JAXB DOM bindings and didn't have any success and due to time constraints switching to XMLBeans was the only option. I will see if I can find an adequate JAXB solution and report back.
        Hide
        Aaron Anderson added a comment -

        After reverting the trunk to use JAXB again on my local machine I was able to retrieve the full NamespaceContext for the tExpression elements. I had to attach the jaxb:dom binding to both the tExpression instances (priority, etc) and the TTask's any declaration. After unmarshalling the WS-HumanTask documentI am able to pull the DOM element from the any property and then I can use the apache commons XMLSchema's NodeNamespaceContext utility to rebuild the NamespaceContext just like how it is done currently.

        I used the following example:

        <htd:humanInteractions xmlns:htd="http://www.example.org/WS-HT"
        ...
        xmlns:cla="http://www.insurance.example.com/claims">

        <htd:tasks>

        <htd:task name="Task1" xmlns:cla2="http://www.insurance.example.com/claims2" >
        ...
        <htd:priority xmlns:cla3="http://www.insurance.example.com/claims3"> xs:integer(htd:getInput("ClaimApprovalRequest")/cla:prio*(cla2:t2+cla3:t3)) </htd:priority>

        and I was able to pull back the prefix mappings for the three cla declarations so I am fairly confident this solution is adequate. Because the DOM content is being attached to the any property instead of the corresponding named property I will need to further enhance the binding customization to compensate for this.

        Now that I have concluded that it is technically possible to revert back to JAXB I was wondering if there is any interest in doing so. The change would be quite extensive and due to the amount of work left I would like to get feedback from the project on whether it is worth pursuing before I commit to completing the task.

        Show
        Aaron Anderson added a comment - After reverting the trunk to use JAXB again on my local machine I was able to retrieve the full NamespaceContext for the tExpression elements. I had to attach the jaxb:dom binding to both the tExpression instances (priority, etc) and the TTask's any declaration. After unmarshalling the WS-HumanTask documentI am able to pull the DOM element from the any property and then I can use the apache commons XMLSchema's NodeNamespaceContext utility to rebuild the NamespaceContext just like how it is done currently. I used the following example: <htd:humanInteractions xmlns:htd="http://www.example.org/WS-HT" ... xmlns:cla="http://www.insurance.example.com/claims"> <htd:tasks> <htd:task name="Task1" xmlns:cla2="http://www.insurance.example.com/claims2" > ... <htd:priority xmlns:cla3="http://www.insurance.example.com/claims3"> xs:integer(htd:getInput("ClaimApprovalRequest")/cla:prio*(cla2:t2+cla3:t3)) </htd:priority> and I was able to pull back the prefix mappings for the three cla declarations so I am fairly confident this solution is adequate. Because the DOM content is being attached to the any property instead of the corresponding named property I will need to further enhance the binding customization to compensate for this. Now that I have concluded that it is technically possible to revert back to JAXB I was wondering if there is any interest in doing so. The change would be quite extensive and due to the amount of work left I would like to get feedback from the project on whether it is worth pursuing before I commit to completing the task.
        Hide
        Aaron Anderson added a comment -

        Here is a patch that re-introduces JAXB marshalling to the current trunk. It uses the JAXB Binder class to to map JAXB classes to DOM elements and vice versa.

        As a future enhancement a custom coded JAXB class for the tExpression type can be inserted into the JAXB code generation process and an unmarshaller listener can be created to populate the custom tExpression type with a NameSpace context value. This way after unmarshalling the Binder and DOM document can be discarded while the necessary expression objects would still have the namespacecontext property available for expression evaluation.

        Another enhancement would be to create custom coded JAXB classes for the lax types that contain content that needs to be unmarshalled properly. More specifically, the tFrom type. Without the JAXB binding customization generateMixedExtensions="true" the tFrom children remain as DOM objects and do not get unmarshalled. Even with generateMixedExtensions="true" the content does get marshalled but it gets placed in a protected field that can only be accessed via reflection. This is rather inelegant and should be remedied.

        Show
        Aaron Anderson added a comment - Here is a patch that re-introduces JAXB marshalling to the current trunk. It uses the JAXB Binder class to to map JAXB classes to DOM elements and vice versa. As a future enhancement a custom coded JAXB class for the tExpression type can be inserted into the JAXB code generation process and an unmarshaller listener can be created to populate the custom tExpression type with a NameSpace context value. This way after unmarshalling the Binder and DOM document can be discarded while the necessary expression objects would still have the namespacecontext property available for expression evaluation. Another enhancement would be to create custom coded JAXB classes for the lax types that contain content that needs to be unmarshalled properly. More specifically, the tFrom type. Without the JAXB binding customization generateMixedExtensions="true" the tFrom children remain as DOM objects and do not get unmarshalled. Even with generateMixedExtensions="true" the content does get marshalled but it gets placed in a protected field that can only be accessed via reflection. This is rather inelegant and should be remedied.

          People

          • Assignee:
            Unassigned
            Reporter:
            Michał Więcław
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development