aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject ARIES-626....
Date Thu, 10 Nov 2011 21:52:09 GMT

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-

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
Talend -

View raw message