On Friday, November 11, 2011 12:36:39 AM Alasdair Nottingham wrote: > Could we not just go back to the NamespaceHandlers in the service registry > for one that advertises the namespace in question?
Guillaume and I did talk about that option as well but quickly discarded it. Some XML "things" that appear in the blueprint may not need a NamespaceHandler for it for anything. Thus, you may end up having to create a class, register it with blueprint, etc... for really no purpose. For CXF, that would likely require creating and registering about 3 dozen namespace handlers. While doable, it's kind of sucky. :-) For example, CXF endpoints have the ability to register WS-Policy fragments on them. (and a WS-Policy fragment could use MANY different namespaces in it) >From a code standpoint, these are purely DOM elements and thus don't need a namespace handler per-se, they just need the schema to be able to validate the XML. THAT said, I was just chatting with a couple folks here at ApacheCon and I'm not sure this will work at all with Blueprint. Since blueprint looks through the DOM and aggregates all the namespaces and waits to startup when namespace handlers are available, it may mean the bundle won't even start. Just talking to Aki Yoshida (who's running into this issue) at ApacheCon, one possible solution is to extend the catalog option below that when the catalog is found, it will create the NamespaceHandler that does nothing but return the Schema for it. When that is done, THEN use your solution to go back to the registry. Still thinking........ Dan > > 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 -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
