Announcement Announcement Module
Collapse
No announcement yet.
HTTP 403 on Schemas? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    The only fix (just tried it and works) I can recommend is to place all the needed spring schemas in the same folder as your applicationContext and in your applicationContext.xml specify the location of the XSDs using the classpath protocol:

    <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://www.springframework.org/schema/p"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns="http://www.springframework.org/schema/beans"
    xsi:schemaLocation="
    http://www.springframework.org/schema/context
    classpath:spring-context-3.0.xsd
    http://www.springframework.org/schema/beans
    classpath:spring-beans-3.0.xsd">

    Comment


    • #17
      Originally posted by georgea View Post
      The only fix (just tried it and works) I can recommend is to place all the needed spring schemas in the same folder as your applicationContext and in your applicationContext.xml specify the location of the XSDs using the classpath protocol:
      I did the same fix this morning on all our production webservers, as it's easiest to make.

      Comment


      • #18
        Finally a solution for HTTP 403 error

        Hi all,
        This is the solution we've found so far.
        What we did was to add a file in "WebContent/META-INF/spring.schemas" with the content :
        Code:
        http\://www.springframework.org/schema/beans/spring-beans-3.0.xsd=org/springframework/beans/factory/xml/spring-beans-3.0.xsd
        http\://www.springframework.org/schema/tool/spring-tool-3.0.xsd=org/springframework/beans/factory/xml/spring-tool-3.0.xsd
        http\://www.springframework.org/schema/util/spring-util-3.0.xsd=org/springframework/beans/factory/xml/spring-util-3.0.xsd
        http\://www.springframework.org/schema/aop/spring-aop-3.0.xsd=org/springframework/aop/config/spring-aop-3.0.xsd
        http\://www.springframework.org/schema/jdbc/spring-jdbc-3.0.xsd=org/springframework/jdbc/config/spring-jdbc-3.0.xsd
        http\://www.springframework.org/schema/context/spring-context-3.0.xsd=org/springframework/context/config/spring-context-3.0.xsd
        http\://www.springframework.org/schema/jee/spring-jee-3.0.xsd=org/springframework/ejb/config/spring-jee-3.0.xsd
        http\://www.springframework.org/schema/lang/spring-lang-3.0.xsd=org/springframework/scripting/config/spring-lang-3.0.xsd
        http\://www.springframework.org/schema/task/spring-task-3.0.xsd=org/springframework/scheduling/config/spring-task-3.0.xsd
        http\://www.springframework.org/schema/tx/spring-tx-3.0.xsd=org/springframework/transaction/config/spring-tx-3.0.xsd
        What we basically did was to tell Spring to look for the required files in the project's libraries itself. For example, for the beans entry which all of us were having errors :
        "http\://www.springframework.org/schema/beans/spring-beans-3.0.xsd",
        We found the particular in the Project's libraries folder with this location "org/springframework/beans/factory/xml/spring-tool-3.0.xsd".

        For your project, the address might be different, you can find the particular xsd file in Maven dependencies section. Also, you might not need all the mappings that I've put above. You can map whatever you want in the schemas file.

        Hope this helps!

        Comment


        • #19
          Fix

          Originally posted by trulija View Post
          I did the same fix this morning on all our production webservers, as it's easiest to make.
          I have fixed our production servers now, I believe in the correct way, which is to place a spring.schemas in META-INF to map the URLs to the classpath files manually.

          https://gist.github.com/2761901

          Comment


          • #20
            Great minds think alike

            Comment


            • #21
              It's good that there is a workaround, but not all can go and change production code just like that.
              Is the removal of the schemas permanent? If not, does anyone know when they will be accessable again?

              Comment


              • #22
                Hi

                Is the workaround to just create that file in META-INF of your project, or is there something else to do - have tried this but will getting the errors. All the XSDs are in the jar files, I even tried extracting them and placing the classpath but that didnt help either.

                Any help appreciated, got to get a build out soon...:-(

                Comment


                • #23
                  What is really weird is that only one of our spring-based applications (non-web) was affected - any reason for that;

                  Comment


                  • #24
                    Originally posted by mkuredjian View Post
                    I managed to get around this by ensuring I had updated all the schemaLocation versions to ones which had entries contained within the various META-INF/spring.schemas files that come with the spring JARs.
                    mkuredjian's solution was the right solution for me. It is the right way to have your schema versions defined in your xml files.

                    Comment


                    • #25
                      The schema URLs seem to be back up now.

                      Comment


                      • #26
                        I finally managed to get META-INF/spring.schemas files to work.
                        This solution is much more cleaner than classpath hack in applicationContext.xml.

                        Initially I had some problems on my development machine with Eclipse. When I stared Tomcat within Eclipse, META-INF/spring.schemas was not parsed.

                        It seems that clean & rebuild of project forced Eclipse/Tomcat to parse META-INF/spring.schemas file.

                        Comment


                        • #27
                          Wow, a whole lot of spring apps won't take off today because of the dependency on spring online schema availability. This is just epic. @Spring guys, would it be difficult to provide correctly packaged 'spring.schemas' files?

                          Just in case the problem comes up again: the issue can be solved by packaging updated `spring.schemas` and placing it into META-INF/ inside classpath.

                          Comment


                          • #28
                            Originally posted by vanyatka View Post
                            Wow, a whole lot of spring apps won't take off today because of the dependency on spring online schema availability. This is just epic. @Spring guys, would it be difficult to provide correctly packaged 'spring.schemas' files?

                            Just in case the problem comes up again: the issue can be solved by packaging updated `spring.schemas` and placing it into META-INF/ inside classpath.
                            It appeared to be contained to the 3.0 line. We have a couple 2.5 apps still running that restarted fine this morning, same with our newer 3.1 applications that were restarted. Only our 3.0 applications had this problem. We're deploying changes to our 3.0 apps to include the spring.schemas files to prevent this from occurring in the future, but it appears 2.5 and 3.1 resolve locally as one would expect them to.

                            Comment


                            • #29
                              Originally posted by georgea View Post
                              What is really weird is that only one of our spring-based applications (non-web) was affected - any reason for that;
                              It's very likely that the affected application points to one of the 403'd schema URIs AND the version specified for that component isn't packaged as part of the JAR.

                              Comment


                              • #30
                                The problem has been fixed.

                                Still, I want to point out that this issues shouldn't have disturbed a properly built application. This kind of issue should raise some eyebrows when it happens in a Spring powered application and that application should be checked for Spring jars inconsistencies and xml files schema definition accuracy. See more on this subject in Chris' reply to this JIRA issue.

                                Comment

                                Working...
                                X