13 Replies Latest reply on Sep 10, 2008 11:06 AM by Alexey Loubyansky

    JBMICROCONT-336; empty string failure

    Ales Justin Master

      Shouldn't this
      - https://jira.jboss.org/jira/browse/JBMICROCONT-336
      be handled in JBossXB?

      Where in MC's case, PropertyMetaData would get
      StringValueMetaData with empty string set.

      Or what would be appropriate place/hack
      to set this in MC's xml metadata handling?

      I've added PropertyUsageTestCase
      which exposes the issue.

        • 1. Re: JBMICROCONT-336; empty string failure
          Alexey Loubyansky Master

          In XB empty string processing is different for simple and complex types. I.e. for the following element

          <e></e>

          the result will be an empty string if e is of a simple type and null if e is of a complex type. It's null for the complex types because otherwise elements of complex types would always get non-null text data which was undesirable.

          • 2. Re: JBMICROCONT-336; empty string failure
            Adrian Brock Master

             

            "alex.loubyansky@jboss.com" wrote:
            In XB empty string processing is different for simple and complex types. I.e. for the following element
            <e></e>

            the result will be an empty string if e is of a simple type and null if e is of a complex type. It's null for the complex types because otherwise elements of complex types would always get non-null text data which was undesirable.


            This is a complex type, but it is also "mixed", i.e. it can take a value.

            Maybe there should be some kind of @JBossXmlValue
            annotation where we can say we want the empty string even for complex types.

            I'd suggest an element on the annotation where you say you don't want
            the empty string data if there are child xml elements?

            That is the rule for the mc's property element, but there's no way to say
            that in an xml schema. ;-)

            A workaround would be to create a subclass of AbstractPropertyMetaData
            that initialises the value to an empty StringValueMetaData and then specify
            that class on @XmlElement of the setProperties()


            • 3. Re: JBMICROCONT-336; empty string failure
              Alexey Loubyansky Master

               

              adrian wrote:
              Maybe there should be some kind of @JBossXmlValue
              annotation where we can say we want the empty string even for complex types.


              This alone doesn't make sense to me. I.e. the property could always be initialized to an empty string and if there was actual data it would override it.

              adrian wrote:
              I'd suggest an element on the annotation where you say you don't want
              the empty string data if there are child xml elements?


              Yes, I was thinking you needed this one.

              An alternative could be a way to specify the default value (which in your case would be an empty string) in case there is no content.

              Do you always have only one child? Or there could be more?

              • 4. Re: JBMICROCONT-336; empty string failure
                Adrian Brock Master

                 

                "alex.loubyansky@jboss.com" wrote:
                adrian wrote:
                Maybe there should be some kind of @JBossXmlValue
                annotation where we can say we want the empty string even for complex types.


                This alone doesn't make sense to me. I.e. the property could always be initialized to an empty string and if there was actual data it would override it.


                You could have the case (not this one) where you have a mixed
                complex type and you want to know the value is ""


                adrian wrote:
                I'd suggest an element on the annotation where you say you don't want
                the empty string data if there are child xml elements?


                Yes, I was thinking you needed this one.

                An alternative could be a way to specify the default value (which in your case would be an empty string) in case there is no content.


                Except in this case, we don't to apply the default when there are other elements.

                Do you always have only one child? Or there could be more?

                It's a mixed type with one optional child that is a choice from a group
                (like I said before, the cdata and the valueGroup are really mutually
                exclusive in our case, but you can't say that in xsd :-).

                 <xsd:complexType name="valueType" mixed="true">
                
                 <xsd:complexContent>
                
                 <xsd:extension base="plainValueType">
                
                 <xsd:sequence>
                
                 <xsd:choice minOccurs="0">
                
                 <xsd:group ref="valueGroup"/>
                
                 </xsd:choice>
                
                 </xsd:sequence>
                
                 </xsd:extension>
                
                 </xsd:complexContent>
                
                 </xsd:complexType>
                


                • 5. Re: JBMICROCONT-336; empty string failure
                  Alexey Loubyansky Master

                   

                  "adrian@jboss.org" wrote:
                  "alex.loubyansky@jboss.com" wrote:
                  adrian wrote:
                  Maybe there should be some kind of @JBossXmlValue
                  annotation where we can say we want the empty string even for complex types.


                  This alone doesn't make sense to me. I.e. the property could always be initialized to an empty string and if there was actual data it would override it.


                  You could have the case (not this one) where you have a mixed
                  complex type and you want to know the value is ""


                  But with that annotation the value always will be "" (unless of course there is actual text data), won't it?

                  adrian wrote:

                  adrian wrote:
                  I'd suggest an element on the annotation where you say you don't want
                  the empty string data if there are child xml elements?


                  Yes, I was thinking you needed this one.

                  An alternative could be a way to specify the default value (which in your case would be an empty string) in case there is no content.


                  Except in this case, we don't to apply the default when there are other elements.


                  Yes, that's what I meant.

                  • 6. Re: JBMICROCONT-336; empty string failure
                    Adrian Brock Master

                     

                    "alex.loubyansky@jboss.com" wrote:
                    "adrian@jboss.org" wrote:
                    "alex.loubyansky@jboss.com" wrote:
                    adrian wrote:
                    Maybe there should be some kind of @JBossXmlValue
                    annotation where we can say we want the empty string even for complex types.


                    This alone doesn't make sense to me. I.e. the property could always be initialized to an empty string and if there was actual data it would override it.


                    You could have the case (not this one) where you have a mixed
                    complex type and you want to know the value is ""


                    But with that annotation the value always will be "" (unless of course there is actual text data), won't it?


                    The raw text data will be "", but the mixed complex type
                    (if it is interested in it) might want to
                    do some kind of value adapter processing on it?

                    All I'm saying is that for a mixed complex type
                    <blah/> is the same as <blah></blah>
                    

                    which should pass "" through the @XmlValue setter processing.

                    • 7. Re: JBMICROCONT-336; empty string failure
                      Alexey Loubyansky Master

                      I've added support for @JBossXmlValue(ignoreEmptyString=false) which can be applied to a type. https://jira.jboss.org/jira/browse/JBXB-151
                      I didn't add support for an annotation element to make it also dependent on child elements. I am still not sure about it.

                      • 8. Re: JBMICROCONT-336; empty string failure
                        Ales Justin Master

                         

                        "alex.loubyansky@jboss.com" wrote:
                        I've added support for @JBossXmlValue(ignoreEmptyString=false) which can be applied to a type. https://jira.jboss.org/jira/browse/JBXB-151
                        I didn't add support for an annotation element to make it also dependent on child elements. I am still not sure about it.

                        Where should I add this @JBossXmlValue?

                        If I put it like this
                        @JBossXmlValue(ignoreEmptyString = false)
                        public class AbstractPropertyMetaData extends AbstractFeatureMetaData
                         implements PropertyMetaData, ValueMetaDataAware, TypeProvider, Serializable
                        

                        it breaks a lot of MC. :-(

                        But the PropertyUsageTestCase passes. :-)

                        • 9. Re: JBMICROCONT-336; empty string failure
                          Adrian Brock Master

                          Can we just bump the issue to the next releas so we can get on with the CR1s?
                          This could be fixed in 2.0.1.GA if necessary.

                          • 10. Re: JBMICROCONT-336; empty string failure
                            Ales Justin Master

                             

                            "adrian@jboss.org" wrote:
                            Can we just bump the issue to the next releas so we can get on with the CR1s?
                            This could be fixed in 2.0.1.GA if necessary.

                            Fine by me.
                            Unless Alexey has some quick fix, before Kabir updates AOP. :-)

                            • 11. Re: JBMICROCONT-336; empty string failure
                              Alexey Loubyansky Master

                               

                              "alesj" wrote:
                              Where should I add this @JBossXmlValue?

                              If I put it like this
                              @JBossXmlValue(ignoreEmptyString = false)
                              public class AbstractPropertyMetaData extends AbstractFeatureMetaData
                               implements PropertyMetaData, ValueMetaDataAware, TypeProvider, Serializable
                              

                              it breaks a lot of MC. :-(


                              That's the right place to put it to. https://svn.jboss.org/repos/common/jbossxb/trunk/src/test/java/org/jboss/test/xb/builder/object/jbossxmlvalue/support/MixedTypeIgnoreEmptyStringFalse.java

                              • 12. Re: JBMICROCONT-336; empty string failure
                                Ales Justin Master

                                 

                                "alex.loubyansky@jboss.com" wrote:

                                That's the right place to put it to. https://svn.jboss.org/repos/common/jbossxb/trunk/src/test/java/org/jboss/test/xb/builder/object/jbossxmlvalue/support/MixedTypeIgnoreEmptyStringFalse.java

                                Yup, I checked your tests before putting it somewhere. :-)

                                Can you apply this yourself and see why the failures?
                                Once you have time, no rush ...

                                • 13. Re: JBMICROCONT-336; empty string failure
                                  Alexey Loubyansky Master

                                  You should know that with that annotation the simple content is always present and never null. So, I guess it may override some value somewhere or affect some if-condition since it's never null now.