Thomas Watson created ARIES-1227:
------------------------------------

             Summary: Allow PerserService to parse successfully when namespace 
handlers are missing
                 Key: ARIES-1227
                 URL: https://issues.apache.org/jira/browse/ARIES-1227
             Project: Aries
          Issue Type: Improvement
          Components: Blueprint
            Reporter: Thomas Watson
            Assignee: Thomas Watson


The blueprint ParserService exposes the blueprint parser to other bundles.  
This is great because it allows other bundles to model and reason about 
blueprint dependencies.  But the ParserService currently fails with a 
ComponentDefinitionException if a custom NamespaceHandler is used within the 
component XML file being parsed and that custom NamespaceHandler service is not 
currently registered.

This becomes painful in scenarios where we are trying to reason about the 
dependencies of a group of bundles and one of these bundles provides a 
NamespaceHandler service which will be used at runtime by other bundles in the 
group.  For example, an OSGi Subsystem may be installed with such a group of 
bundles as its content.  The subsystems implementation in Aries attempts to 
model the blueprint dependencies of the bundle resources before actually 
installing and starting the bundles.  This is done by using the blueprint 
ParserService.  But it always fails to do so because any blueprint XML that 
uses the custom namespace will fail to model correctly which ultimately results 
in a subsystem installation failure.

It would be nice if the ParserService could be configured to ignore the missing 
NamespaceHandlers and continue with modelling the basic blueprint XML.  One way 
to accomplish this would be to have a framework property that can be configured 
to ignore when a namespace is missing while using the ParserService.  This will 
only change the behavior of the ParserService and not the internal usage of the 
Parser implementation by blueprint-core.  It should also not change the current 
behavior of the ParserService unless the option to ignore is enabled explicitly.

Another option is to change the ParserService API somehow to pass in an option 
to ignore unknown NamespaceHandlers.  This has an unfortunate side-effect of 
exploding the API of the ParserService and the many other layers built on top 
of it (e.g. ParserProxy and ModelledResourceManager which get used by Aries 
subsystesms).  Perhaps that is the correct thing to do, but I am not 
comfortable changing that much API for this usecase.  A global switch that 
simply enables the option to ignore missing NamespaceHandlers is good enough 
for my usage.  If others want to add API to allow clients of the API to make 
that choice that is fine with me, but I would prefer that to be done by someone 
more familiar with the overall API here.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to