XBean
  1. XBean
  2. XBEAN-151

Xbean-Spring is "incompatible" with Spring Framework 3.0.x

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: spring
    • Labels:
      None
    • Environment:

      Any

      Description

      A lot of people have complained about this but haven't opened an issue for it. I've investigate it a bit and really it's not that xbean-spring is truly incompatible, it's that everyone (including the spring-xbean unit tests) creates xbean-spring configurations that assume Spring validation is turned off. This means that an xbean-spring configuration will fail to load without the schemaLocation defined with all custom namespaces. This can get a little tricky with xbean-spring syntax since when you add the appropriate schemas for validation, the xbean-configuration will fail to validate even though the configuration loads and operates correctly at runtime. I've found a few constructs I've used to be tough to figure out how to get to validate in order to run with Spring 3.0.x. The easiest solution to deal with this is to something turn off the default validation in Spring 3.0.x (which wasn't turned on by default in versions of Spring previous to 3.0.x). To reproduce this, simply get the project's code from trunk, and change the spring dependency versions to, 3.0.3.RELEASE and build. xbean-spring will fail. I'm attaching the results of one of the failed tests and you'll see the xbean configuration for that test failed validation for the "beans" tag.

      Here is what the results of the build look like, in case it helps in anyway:

      Results :

      Tests in error:
      testPizza(org.apache.xbean.spring.context.RestaurantUsingXBeanTest)
      testPizza(org.apache.xbean.spring.context.RestaurantUsingXBeanAsRootTest)
      testBeer(org.apache.xbean.spring.context.BeerNullTest)
      testFavs(org.apache.xbean.spring.context.FavoriteUsingXBeanMixedTest)
      testBeer(org.apache.xbean.spring.context.KegXBeanTest)
      testBeer(org.apache.xbean.spring.context.KegXBeanAndPropertiesTest)
      testPizza(org.apache.xbean.spring.context.PizzaUsingXBeanWithJavaNamespaceTest)
      testConfigureJndiInsideSpringXml(org.apache.xbean.spring.jndi.JndiTest)
      testBeer(org.apache.xbean.spring.context.BeerUsingXBeanSystemPropTest)
      testPizza(org.apache.xbean.spring.context.PizzaUsingXBeanTest)
      testPizza(org.apache.xbean.spring.context.RestaurantUsingXBeanWithSimplerConfigTest)
      testRecipes(org.apache.xbean.spring.context.RecipeUsingXBeanMixedTest)
      testPizza(org.apache.xbean.spring.context.RestaurantUsingResourceXmlApplicationContextTest)
      test(org.apache.xbean.spring.context.SpringExtensionTest)
      testSocketService(org.apache.xbean.spring.context.SocketAddressXBeanTest)
      testSocketAddress(org.apache.xbean.spring.context.SocketAddressXBeanTest)
      testRecipes(org.apache.xbean.spring.context.RecipeUsingXBeanTest)
      testFavs(org.apache.xbean.spring.context.FavoriteUsingXBeanTest)
      testBeer(org.apache.xbean.spring.context.BeerUsingXBeanTest)
      testWine(org.apache.xbean.spring.context.WineUsingXBeanTest)
      testPizza(org.apache.xbean.spring.context.PizzaUsingXBeanWithPropertiesTextNodeTest)
      testSoup(org.apache.xbean.spring.context.SoupUsingXBeanTest)
      testFlatMap(org.apache.xbean.spring.context.FlatMapTest)
      test1(org.apache.xbean.spring.context.ComponentTest)
      test2(org.apache.xbean.spring.context.ComponentTest)
      testQName(org.apache.xbean.spring.context.QNameUsingXBeanTest)
      testWine(org.apache.xbean.spring.context.GinUsingSpringTest)
      testPizza(org.apache.xbean.spring.context.PizzaUsingXBeanWinBeanRefTest)
      testWine(org.apache.xbean.spring.context.VodkaUsingXBeanTest)
      testSalad(org.apache.xbean.spring.context.SaladUsingXBeanTest)
      testPizza(org.apache.xbean.spring.context.RestaurantUsingXBeanMixedTest)
      testPizza(org.apache.xbean.spring.context.RestaurantUsingSpringExtendedTest)

      Tests run: 58, Failures: 0, Errors: 32, Skipped: 0

        Activity

        Ryan Moquin created issue -
        Hide
        Ryan Moquin added a comment -

        Results from one of the tests, showing the validation error when upgrading to any of the spring 3.x releases.

        Show
        Ryan Moquin added a comment - Results from one of the tests, showing the validation error when upgrading to any of the spring 3.x releases.
        Ryan Moquin made changes -
        Field Original Value New Value
        Attachment org.apache.xbean.spring.context.RestaurantUsingXBeanTest.txt [ 12450417 ]
        Hide
        Ryan Moquin added a comment -

        Now that the issue is filed, I modified the ClassPathXmlApplicationContext and ResourceXmlApplicationContext extensions of xbean-spring which are used in the unit tests and explicitly disabled validation of the bean xml reader by adding this method to each class:

        protected void initBeanDefinitionReader(XmlBeanDefinitionReader reader)

        { reader.setValidating(false); }

        If you build after adding that method, then all the unit tests will pass. I'll attach the two classes I modified, though all I did was add the above method. I'm doubting you'd include that method as is, but it at least illustrates a very simple way to workaround the issue (retaining the configurability of the switch might be the desired fix for the issue).

        Show
        Ryan Moquin added a comment - Now that the issue is filed, I modified the ClassPathXmlApplicationContext and ResourceXmlApplicationContext extensions of xbean-spring which are used in the unit tests and explicitly disabled validation of the bean xml reader by adding this method to each class: protected void initBeanDefinitionReader(XmlBeanDefinitionReader reader) { reader.setValidating(false); } If you build after adding that method, then all the unit tests will pass. I'll attach the two classes I modified, though all I did was add the above method. I'm doubting you'd include that method as is, but it at least illustrates a very simple way to workaround the issue (retaining the configurability of the switch might be the desired fix for the issue).
        Hide
        Ryan Moquin added a comment -

        It's easy enough to just add the method to the two source files to see that it fixes the issue, but just for covenience, here are the two files I modified that include the method to turn of validation which makes the unit tests pass.

        Show
        Ryan Moquin added a comment - It's easy enough to just add the method to the two source files to see that it fixes the issue, but just for covenience, here are the two files I modified that include the method to turn of validation which makes the unit tests pass.
        Ryan Moquin made changes -
        Attachment ResourceXmlApplicationContext.java [ 12450418 ]
        Attachment ClassPathXmlApplicationContext.java [ 12450419 ]
        Hide
        David Jencks added a comment -

        Hi Ryan,

        thanks for looking into this. I'm wondering if you can clear up a couple points easily..

        1. is the spring validation just xml validation against the schema using e.g the sax parser validation, or is it something else?

        2. IIUC, assuming the answer to (1) is "spring validation is xml validation", even if you supply the schemas to the validator you get errors. Is this because the schema generated by xbean is wrong or is there some other problem? In other words, if we modified the "invalid" documents to match the schema would the errors go away and we could still get the same bean configuration out?

        Show
        David Jencks added a comment - Hi Ryan, thanks for looking into this. I'm wondering if you can clear up a couple points easily.. 1. is the spring validation just xml validation against the schema using e.g the sax parser validation, or is it something else? 2. IIUC, assuming the answer to (1) is "spring validation is xml validation", even if you supply the schemas to the validator you get errors. Is this because the schema generated by xbean is wrong or is there some other problem? In other words, if we modified the "invalid" documents to match the schema would the errors go away and we could still get the same bean configuration out?
        Hide
        Ryan Moquin added a comment -

        The issue will go away if you put the correct entries in the schemaLocation element. I some cases, I had some difficulties with getting some of my xbean configurations to validate against the generated XSD. I don't think the generated XSDs are wrong, though I'm not really sure what else I'm doing wrong. In previous versions of Spring, the method I override on those two classes were empty and therefore validation wasn't set on by default. I think it's definitely a choice for you guys on which way you'd rather resolve this issue. If you go the route of adding the correct schemaLocation attributes, then I guess we'll have to figure out why some of the configs don't validate. It is weird that the config won't validate, but the configuration still works as you would expect when using it at runtime.

        Show
        Ryan Moquin added a comment - The issue will go away if you put the correct entries in the schemaLocation element. I some cases, I had some difficulties with getting some of my xbean configurations to validate against the generated XSD. I don't think the generated XSDs are wrong, though I'm not really sure what else I'm doing wrong. In previous versions of Spring, the method I override on those two classes were empty and therefore validation wasn't set on by default. I think it's definitely a choice for you guys on which way you'd rather resolve this issue. If you go the route of adding the correct schemaLocation attributes, then I guess we'll have to figure out why some of the configs don't validate. It is weird that the config won't validate, but the configuration still works as you would expect when using it at runtime.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ryan Moquin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development