Closed mkolas closed 10 years ago
So first, a little heads up on how schemas are supposed to work:
When we describe a schema by URL, Spring has some hooks to point it to a local schema file if possible: http://docs.spring.io/spring/docs/3.0.5.RELEASE/spring-framework-reference/html/extensible-xml.html#extensible-xml-registration
However- Spring can only point to a local file if that file exists. Otherwise, it sends out a request for the schema by its URL.
This is a problem when we're asking for versions of schemas that our Alfresco instance doesn't natively have. For example, in propertyfile-location-bean-config.xml, we have calls for version 3.1 of spring-beans and spring-aop. Unfortunately Alfresco (as of version 4.2.1) only has version 3.0.5 of Spring- so without access to the internet, it fails to find version 3.1 of those schemas.
For a client-specific fix, I can make sure that the versions match the Spring version they have access to. For OpenContent trunk, this might require using older schemas or overwriting core files if we're on Alfresco.
For reference, the files that request 3.1 schema files:
1.core/core-bean-config.xml 1.core/propertyfile-location-bean-config.xml 2.activiti/activiti-bean-config.xml 2.jdbc/jdbc-bean-config.xml 2.solr/solr-bean-config.xml
I changed all of these for good measure locally and Alfresco started up without issue.
This has been tested with a Wizard Alfresco instance and no problems detected.
Fixed OC rev 9388.
A client noticed that once they had disconnected their Alfresco instance from the public internet, OC would fail to start. This is because our Spring context files reference schemas remotely instead of reading them from the classpath. We should be able to resolve this by having local copies of the schema.