ARIES-626....

[Daniel Kulp <dk...@apache.org>]

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

Re: ARIES-626....

[Daniel Kulp <dk...@apache.org>]

I think I'm pretty much "all set" with this issue now.   I need to test a bit 
more with CXF/Camel to make sure nothing else is broken, but I'm fairly happy 
with it.

Basically, there are two options now:

1) Bundles that provide namespace handlers should definitely register handlers 
for all the namespaces they may use.   If a schema imports another, it's best 
that they add an handler for that import as well.   A resolver was added to go 
back to the handler registry to get the schemas for those cases.

2) If a blueprint.xml uses elements/attributes in namespaces where a namespace 
handler DOESN'T exist, but also is not needed, there is a new schema.map file 
that the developer can add that will map that namespace to a schema for the 
purpose of validating the XML.   It also removes that namespace from the "wait 
queue" so the bundle can start.

That should solve most of the issues people are having.   CXF can provide NS 
handlers for pretty much everything it knows about (most will likely never 
have to parse anything, but at least the schemas can be found).   In the cases 
where the users may be adding their own policies or something in their own 
namespaces, they can use the schema.map to provide the schema.

Is everyone OK with all of that?

Dan



On Friday, November 11, 2011 11:53:59 AM Daniel Kulp wrote:
> 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 <dk...@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 Community Coder - http://coders.talend.com

Re: ARIES-626....

[Daniel Kulp <dk...@apache.org>]

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 <dk...@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

Re: ARIES-626....

[Alasdair Nottingham <no...@apache.org>]

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 <dk...@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
>



-- 
Alasdair Nottingham
not@apache.org