aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: ARIES-626....
Date Fri, 11 Nov 2011 00:36:39 GMT
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 <> 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
> Talend -

Alasdair Nottingham

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message