HTTP 403 on Schemas?

[mkuredjian]

Is there a reason why the http://www.springframework.org/schema/beans, for example is returning a 403? Is something down for maintenance?

[Curacao]

I am having the same issue. The site seems to be down.

[a4techjames]

I am having the same issue. The site seems to be down.

Curacao, We have same problem.. Is is already fixed? Can someone fix it so we can access. Please. Thanks

[a4techjames]

What happen to this?

Forbidden

You don't have permission to access /schema/beans on this server.
Apache/2.2.3 (CentOS) Server at www.springframework.org Port 80

[mkuredjian]

I guess to get around this problem in the future, one should retain a mirror of the schemas?

[a4techjames]

Yes that is what I guess. It also need maintenance.

[cheetah100]

We didn't realise there was a runtime dependency on these schemas. It is obvious now, but looking at the number of examples which use the http location of the schemas we might just see a stack of production systems hit if they are restarted. In hindsight the schemas should be distributed with core Spring, or at least made available as part of the application rather than depending on Internet access.

[mkuredjian]

We didn't realise there was a runtime dependency on these schemas. It is obvious now, but looking at the number of examples which use the http location of the schemas we might just see a stack of production systems hit if they are restarted. In hindsight the schemas should be distributed with core Spring, or at least made available as part of the application rather than depending on Internet access.

I only saw it this afternoon while trying to launch an application which uses OXM. If anyone cares:

http://stackoverflow.com/questions/1...net-connection

e: 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. It seems like the way schemaLocation works is by checking first whether specified location is valid, and if not, then checking the spring.schemas file to see if the XSD can be resolved from the classpath. In the event that the schema can be resolved from the classpath, you don't have failure to launch; however, if the version is missing from spring.schemas AND the URL is inaccessible, then you will see failure on startup.

The reason I was having problems with my application is because I was referencing an ancient v1.5 of the OXM schema, which was no longer contained in spring.schemas; hence failure. To fix this, I either left the version unspecified as part of the URI, or specified a version that was listed in the metadata and bundled with the JAR.

Still, why is this service unavailable?

[Pavo]

We didn't realise there was a runtime dependency on these schemas. It is obvious now, but looking at the number of examples which use the http location of the schemas we might just see a stack of production systems hit if they are restarted. In hindsight the schemas should be distributed with core Spring, or at least made available as part of the application rather than depending on Internet access.

Hi,

We have encountered this exact scenario in Production. Two of our WebSphere nodes have been restarted, however Spring MVC fails to launch our application.

Will whatever change was made, be undone?

Thanks,
Pete

[twentyseven]

Hello,

Will the different schemas be available soon on the site or should we find another solution ?