Community
Participate
Working Groups
The OSGi XML Parser Service specification requires parser factory service registrations (SAXParserFactory and DocumentBuilderFactory) to include the following two service properties: parser.validating and parser.namespaceAware. This allows service filters to be used in order to obtain only those factories capable of creating parsers with the required functionality. Equinox registers a service for each of the two parser factories with default values as part of starting the framework. I realize the parser service specification is part of the compendium but wonder why the same rule wouldn't apply here?
Created attachment 199303 [details] proposed patch This patch modifies the EclipseAdaptorHook to register the two xml parser factories with the required properties and default values.
Seems like a good idea.
Also see bug 88483. I think most VMs actually do have validating and namespace aware parsers built in, but we don't do the steps at startup to detect if this is true.
(In reply to comment #0) > The OSGi XML Parser Service specification requires parser factory service > registrations (SAXParserFactory and DocumentBuilderFactory) to include the > following two service properties: parser.validating and parser.namespaceAware. Note that the specification only requires a value of TRUE if validating or namespaceAware is supported. All other values or absence indicates FALSE. Section 702.4 from the compendium spec: <spec> • PARSER_NAMESPACEAWARE – The registered parser is aware of name- spaces. Name-spaces allow an XML document to consist of indepen- dently developed DTDs. In an XML document, they are recognized by the xmlns attribute and names prefixed with an abbreviated name-space identifier, like: <xsl:if ...>. The type is a Boolean object that must be true when the parser supports name-spaces. All other values, or the absence of the property, indicate that the parser does not implement name- spaces. • PARSER_VALIDATING – The registered parser can read the DTD and can validate the XML accordingly. The type is a Boolean object that must Getting a Parser Factory XML Parser Service Specification Version 1.0 true when the parser is validating. All other values, or the absence of the property, indicate that the parser does not validate. </spec>
(In reply to comment #3) > Also see bug 88483. I think most VMs actually do have validating and namespace > aware parsers built in, but we don't do the steps at startup to detect if this > is true. I knew there had to be a similar bug opened somewhere at some point. I just couldn't find it. (In reply to comment #4) > Note that the specification only requires a value of TRUE if validating or > namespaceAware is supported. All other values or absence indicates FALSE. > Section 702.4 from the compendium spec: Okay, fine. I missed that. So if someone wanted to ensure they got a non-validating parser, they could do something like (|!((parser.validating=*))(parser.validating=false)). Se also bug 351502. We should consider registering a namespace aware parser in addition to or in lieu of the non-namespace aware one if the environment supports it. I don't think bundles should customize factories retrieved from the registry to their own liking since that would affect all other using bundles.
(In reply to comment #5) > (In reply to comment #3) > > Also see bug 88483. I think most VMs actually do have validating and namespace > > aware parsers built in, but we don't do the steps at startup to detect if this > > is true. > I knew there had to be a similar bug opened somewhere at some point. I just > couldn't find it. > (In reply to comment #4) > > Note that the specification only requires a value of TRUE if validating or > > namespaceAware is supported. All other values or absence indicates FALSE. > > Section 702.4 from the compendium spec: > Okay, fine. I missed that. So if someone wanted to ensure they got a > non-validating parser, they could do something like > (|!((parser.validating=*))(parser.validating=false)). > Se also bug 351502. We should consider registering a namespace aware parser in > addition to or in lieu of the non-namespace aware one if the environment > supports it. I don't think bundles should customize factories retrieved from > the registry to their own liking since that would affect all other using > bundles. I meant to add that I think most would want a namespace aware one, no? Making one available would prevent folks from having to register their own or misuse the existing one.
Closing as invalid. First, the properties for xml parser factories do not need to be included if the value is false. Services requiring a value of false can use filters such as the following: (|(!(parser.validating=*))(parser.validating=false)). Second, the framework, as does the XML Parser Service specification, uses a ServiceFactory to deliver xml parser factories to requesting bundles. This means a bundle is free to modify the factory settings (e.g., setNamespaceAware and setValidating) as it pleases without affecting other bundles. If a bundle registers a parser factory without using a service factory, it's not following the spec and all bets are off.
