Spring Framework
  1. Spring Framework
  2. SPR-8470

CastorMarshaller - marshaller and unmarshaller properties.

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 3.1 M2
    • Fix Version/s: 3.2.2
    • Component/s: OXM
    • Last commented by a User:
      true

      Description

      I had been working with Werner Guttman lead of the Castor XML project on ideas for extending the Spring OXM for current Castor version.
      I've prepared a patch with additional "complex" properties that we would like to exposed by CastorMarshaller.

      I've attchet three patches one with changes made in CastorMarshaller, second with tests for those additional properties.
      The last patch is required to build this version.

        Issue Links

          Activity

          Hide
          Chris Beams added a comment -

          Thanks for the patches Jacob. Could you describe one or two use cases here? i.e., how this set of changes might benefit Spring users?

          Slating this for 3.1 Backlog for now, which is a strong reminder to us to get this into 3.1 if possible. The more compelling you make the use cases, the more likely that becomes, of course!

          Chris

          Show
          Chris Beams added a comment - Thanks for the patches Jacob. Could you describe one or two use cases here? i.e., how this set of changes might benefit Spring users? Slating this for 3.1 Backlog for now, which is a strong reminder to us to get this into 3.1 if possible. The more compelling you make the use cases, the more likely that becomes, of course! Chris
          Hide
          Jakub Narloch added a comment -

          Hi Chris,

          The provided patch mainly exposes the internal properties allowing the user to have greater influence on the marshaller used internally.

          Maybe I should have divide this into two separate patches, the first group of properties allows to somehow affect the marshlaller settings for example the properties could be used to modify the 'org.exolab.castor.xml.naming' property and for example switch from default mixed mode to camelCase like.

          private EntityResolver entityResolver;
          
          private XMLClassDescriptorResolver resolver;
          
          private Map<String, String> doctypes;
          
          private Map<String, String> properties;
          

          The rest of the properties like:

          private CastorObjectFactory objectFactory;
          
          private CastorIdResolver idResolver;
          
          private CastorMarshalListener[] marshalListeners;
          
          private CastorUnmarshalListener[] unmarshalListeners;
          

          Can be used to control the marshalling process, for example the IDResolver allows to inject arbitrary objects into the unmarshalled result. The listeners adds the observavable pattern to the CastorMarshaller.

          All of this above is provide the developers with functionality similar as the backing marshaller framework has.

          Show
          Jakub Narloch added a comment - Hi Chris, The provided patch mainly exposes the internal properties allowing the user to have greater influence on the marshaller used internally. Maybe I should have divide this into two separate patches, the first group of properties allows to somehow affect the marshlaller settings for example the properties could be used to modify the 'org.exolab.castor.xml.naming' property and for example switch from default mixed mode to camelCase like. private EntityResolver entityResolver; private XMLClassDescriptorResolver resolver; private Map< String , String > doctypes; private Map< String , String > properties; The rest of the properties like: private CastorObjectFactory objectFactory; private CastorIdResolver idResolver; private CastorMarshalListener[] marshalListeners; private CastorUnmarshalListener[] unmarshalListeners; Can be used to control the marshalling process, for example the IDResolver allows to inject arbitrary objects into the unmarshalled result. The listeners adds the observavable pattern to the CastorMarshaller. All of this above is provide the developers with functionality similar as the backing marshaller framework has.
          Hide
          Chris Beams added a comment -

          Reassigning to Juergen, who's already been in communication with Werner on this topic.

          Show
          Chris Beams added a comment - Reassigning to Juergen, who's already been in communication with Werner on this topic.
          Hide
          Serkan Arıkuşu added a comment -

          These patches are not on the 3.1.2 release after a year.
          How can we push this?

          Show
          Serkan Arıkuşu added a comment - These patches are not on the 3.1.2 release after a year. How can we push this?
          Hide
          Juergen Hoeller added a comment -

          I've added "entityResolver", "classDescriptorResolver", "idResolver", "objectFactory", "doctypes", "properties" to CastorMarshaller now. Note that I opted for accepting the original Castor IDResolver and ObjectFactory for the "idResolver" and "objectFactory" property, respectively, since we're generally not introducing our own strategy interfaces for such specific purposes.

          I did not include any listener support at this point. This looks very specific and quite fragile to me, i.e. closely depending on Castor listener signatures - and well, the UnmarshalListener interface seems to have been deprecated and replaced between Castor 1.2 and 1.3 there, strengthening my point. I'd rather suggest sticking with your own CastorMarshaller subclass for such purposes.

          Juergen

          Show
          Juergen Hoeller added a comment - I've added "entityResolver", "classDescriptorResolver", "idResolver", "objectFactory", "doctypes", "properties" to CastorMarshaller now. Note that I opted for accepting the original Castor IDResolver and ObjectFactory for the "idResolver" and "objectFactory" property, respectively, since we're generally not introducing our own strategy interfaces for such specific purposes. I did not include any listener support at this point. This looks very specific and quite fragile to me, i.e. closely depending on Castor listener signatures - and well, the UnmarshalListener interface seems to have been deprecated and replaced between Castor 1.2 and 1.3 there, strengthening my point. I'd rather suggest sticking with your own CastorMarshaller subclass for such purposes. Juergen
          Hide
          Juergen Hoeller added a comment -

          FYI, in the same pass, I've deprecated "setObject" in favor of "setRootObject", since a general property name "object" looks quite odd on a Spring bean. That aside, that property seems to be just meant for programmatic use anyway since it's inherently not thread-safe to specify the target object to unmarshal into there?

          Juergen

          Show
          Juergen Hoeller added a comment - FYI, in the same pass, I've deprecated "setObject" in favor of "setRootObject", since a general property name "object" looks quite odd on a Spring bean. That aside, that property seems to be just meant for programmatic use anyway since it's inherently not thread-safe to specify the target object to unmarshal into there? Juergen
          Hide
          Jakub Narloch added a comment -

          Cool.
          Thanks very much. I will try to update the last patch regarding the Spring Reference and afterward push it through PR on github.

          > That aside, that property seems to be just meant for programmatic use anyway since it's inherently not thread-safe to specify the target object to unmarshal into there?
          It's quite likely that's there is very limited use of setting the root object and I agree that it's not thread safe at all.

          Show
          Jakub Narloch added a comment - Cool. Thanks very much. I will try to update the last patch regarding the Spring Reference and afterward push it through PR on github. > That aside, that property seems to be just meant for programmatic use anyway since it's inherently not thread-safe to specify the target object to unmarshal into there? It's quite likely that's there is very limited use of setting the root object and I agree that it's not thread safe at all.

            People

            • Assignee:
              Juergen Hoeller
              Reporter:
              Jakub Narloch
              Last updater:
              Jakub Narloch
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 9 weeks, 4 days ago