Spring Security OAuth
  1. Spring Security OAuth
  2. SECOAUTH-199

The schema spring-security-oauth2-1.0.xsd cause validation error in Eclipse

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 1.0.0.M6
    • Fix Version/s: 1.0.0.M6
    • Component/s: OAuth 2
    • Labels:
      None
    • Environment:
      Mac OS X 10.7.3
      Eclipse Java EE IDE for Web Developers. Version: Indigo Service Release 1 Build id: 20110916-0149
      m2e version 1.0.100.20110804-1717

      Description

      If you import the spring-security-oauth2 project in Eclipse you get the following validation error:

      Description: src-resolve: Cannot resolve the name 'beans:identifiedType' to a 'type definition' component.
      On element: spring-security-oauth2-1.0.xsd
      In folder: spring-security-oauth2/src/main/resources/org/springframework/security/oauth
      Location: line 298

      Problem area code: <xs:extension base="beans:identifiedType">

      The problem seems to be that there is no, or incorrect, schema attached to the beans namespace.

      At line 6:
      <xs:import namespace="http://www.springframework.org/schema/beans"/>

      Proposed solution:

      Change line 6 to:
      <xs:import namespace="http://www.springframework.org/schema/beans" schemaLocation="http://www.springframework.org/schema/beans/spring-beans-3.1.xsd"/>

      or

      <xs:import namespace="http://www.springframework.org/schema/beans" schemaLocation="http://www.springframework.org/schema/beans/spring-beans.xsd"/>

        Activity

        Hide
        Christian Hilmersson added a comment -

        Ok, great.
        I got the idea from the Spring Context project where they did it that way (specifying the version).
        My reasoning for specifying the version is the same as why you don't use SNAPSHOT dependencies in Maven when building a release.
        Maybe not a hundred percent strict analogy but a bit similar.

        Show
        Christian Hilmersson added a comment - Ok, great. I got the idea from the Spring Context project where they did it that way (specifying the version). My reasoning for specifying the version is the same as why you don't use SNAPSHOT dependencies in Maven when building a release. Maybe not a hundred percent strict analogy but a bit similar.
        Hide
        Dave Syer added a comment -

        I think the namespaces in Spring Framework (e.g. the context one) can rely on the specific version of the beans namespace being available. Other projects with different release cycles prefer to leave the version unspecified so that it isn't tied to a particular release of Spring (the XSD files are very long lived typically). In our case it probably doesn't matter much as long as we don't get too adventurous and start depending on a version that isn't released yet. I'll merge your pull request and we can see if anyone complains.

        Show
        Dave Syer added a comment - I think the namespaces in Spring Framework (e.g. the context one) can rely on the specific version of the beans namespace being available. Other projects with different release cycles prefer to leave the version unspecified so that it isn't tied to a particular release of Spring (the XSD files are very long lived typically). In our case it probably doesn't matter much as long as we don't get too adventurous and start depending on a version that isn't released yet. I'll merge your pull request and we can see if anyone complains.
        Hide
        Christian Hilmersson added a comment -

        Ok, great!

        I can see what you mean with the "different lifecycle" issue but isn't it a good idea to decide which version of spring-beans that is used for each release of spring-security-oauth2 even though they are not released together?
        Since you have already stated a dependency to spring-beans 3.1.0 in the pom.xml I think it is alright to do that also in the xsd.
        As far as I understand, a certain version of the schema needs a certain version of the backing implementation to match parameters etc. Therefore, I guess the only thing that is possible to guarantee for the moment is that it works with spring-beans 3.1.0. What I mean is that we actually don't know right now if this code (spring-security-oauth2 1.0.0) is going to work with future versions of spring-beans even though it is most probable that it will.

        Show
        Christian Hilmersson added a comment - Ok, great! I can see what you mean with the "different lifecycle" issue but isn't it a good idea to decide which version of spring-beans that is used for each release of spring-security-oauth2 even though they are not released together? Since you have already stated a dependency to spring-beans 3.1.0 in the pom.xml I think it is alright to do that also in the xsd. As far as I understand, a certain version of the schema needs a certain version of the backing implementation to match parameters etc. Therefore, I guess the only thing that is possible to guarantee for the moment is that it works with spring-beans 3.1.0. What I mean is that we actually don't know right now if this code (spring-security-oauth2 1.0.0) is going to work with future versions of spring-beans even though it is most probable that it will.
        Hide
        Dave Syer added a comment -

        Well, in the short term I think this is a low risk change. Longer term it can get nasty if someone wants to use Spring 4.0 with SECOAUTH 1.0 - it might break for completely unnecessary reasons.

        Show
        Dave Syer added a comment - Well, in the short term I think this is a low risk change. Longer term it can get nasty if someone wants to use Spring 4.0 with SECOAUTH 1.0 - it might break for completely unnecessary reasons.
        Hide
        Dave Syer added a comment -

        I couldn't merge the pull request (my fault), but the change is applied.

        Show
        Dave Syer added a comment - I couldn't merge the pull request (my fault), but the change is applied.

          People

          • Assignee:
            Dave Syer
            Reporter:
            Christian Hilmersson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: