Could we not just go back to the NamespaceHandlers in the service registry for one that advertises the namespace in question?
On 10 November 2011 21:52, Daniel Kulp <[email protected]> wrote: > > I had a discussion with Guillaume this morning about some possible > solutions > to ARIES-626 and there a couple options. I'd like peoples thoughts on > them. > > First off, there are two parts to the issue: > > 1) Relative imports (like schemaLocation="foo.xsd") - this is a simple fix > as > the StreamSource we create we were not creating with a systemId so > relatives > could not be resolved. Just committed a fix for that. (although I need > to > create a testcase for it) > > 2) External imports - these are a lot more complex. They actually > currently > work, but the problem is that it requires an internet connection which is > obviously not something we want to require. Thus, we need a way to map > the > locations to something resolvable internally. Guillaume and I talked > about > a couple options: > > a) When something needs to be resolved like this, call into the > NamespaceHandlers again with the new namespace until something is returned. > Unfortunately, half the namespacehandlers I looked at don't even look at > the > incoming param and always return "their" schema. Thus, this would likely > not > work well with existing code. > > b) Create an extended interface that NamespaceHandlers could optionally > implement to map locations. (or provide a catalog) > > c) Look for a catalog in someplace "standard". Maybe /OSGI- > INF/blueprint/blueprint.schemas. > > Spring does this by looking for META-INF/spring.schemas files and using > them > to map URL's to new URL's in the bundle. Thus, they more or less have > gone > with (c). I'm definitely OK with that as well, but would like people's > thoughts. Also, what would peoples suggestions be for the file location? > > Anyway, I'll likely try working on this a bit next week, but would > definitely > appreciate any ideas and thoughts. > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com > -- Alasdair Nottingham [email protected]
