[ http://jira.jboss.com/jira/browse/JBCOMMON-43?page=comments#action_12403126 ] Alexey Loubyansky commented on JBCOMMON-43: ------------------------------------------- The fix has been committed with a testcase. I want to bring to attention that there is a possible backwards incompatibility in behavior (which affects any case when resolveEntity is called) in that if the schema location registered in the resolver is different from the one in the XML's schemaLocation attribute with the purpose of override. In this case, the schemaLocation from the XML file will be used. And at the moment w/o falling back to the registered one if the one in the XML occured to be invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBCOMMON-43?page=comments#action_12405316 ] Alexey Loubyansky commented on JBCOMMON-43: ------------------------------------------- The test itself is not a problem. The question is whether it's going to affect existing users or cause us problems in the future. That's why I brought it up on the forums. There is a workaround though... It is still possible to take that schemaLocation from the XML and map it to another schemaLocation (some local one perhaps) that we would like to use internally to resolve the schema. So the picture might look like: - there is publicId (namespace) in the XML - this publicId is mapped (in the JBossEntityResolver) to a systemId (schemaLocation) - schemaLocation1 - the XML comes with its own systemId (schemaLocation) for the publicId (namespace) - schemaLocation2, which is different from schemaLocation1 Since, the schemaLocation's are different, further schemaLocation1 is ignored! This is the difference from the previous version. The resolution is now based on schemaLocation2. But... In JBossEntityResolver we may also map schemaLocation2 (as publicId) to another schemaLocation, e.g. schemaLocation1! Assuming schemaLocation1 can be resolved using classpath resource loading (it won't be tried as URL). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira