aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: ARIES-626....
Date Fri, 11 Nov 2011 16:53:59 GMT
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 <dkulp@apache.org> 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
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Mime
View raw message