Simon Kitching wrote:
On Tue, 2003-10-07 at 03:09, Jean-Francois Arcand wrote:
Simon Kitching wrote:
On Sun, 2003-10-05 at 07:26, Jean-Francois Arcand wrote:I'm not absolutely sure (althrouth the solution I've implemented in Tomcat was with the help of the Xerces team). The current implementation will works fine with Xerces 2.1 and lower when you wan to validation both DTD and schema with the same digester instance. The curent implementation contains the "portable way" described in jaxp 1.2 spec. For a reason I can't explain (I'm not following the Xerces dev list), they have changed the way they supports schema & DTD in version 2.3 to 2.5. I think the jaxp spec was unclear about validating both DTD and scheam with the same parser, and that's why we need to set those "unportable" property for now.
Doesn't it really suck that there is no parser-independent way of enabling w3c-standard xml schema support? Is everybody absolutely sure there is no portable way to do this? [NB: I've had a look myself, and this does indeed appear to be the case, though I'm not a JAXP guru].
Can you describe what "the solution I've implemented in Tomcat" means?
Here is the CVS log of what I did in Tomcat to make it work with Xerces 2.3/2,5 (was working fine with 2.3)
if (validation) {
- webDigester.setSchema(url.toString());
+ if (webDigester.getFactory().getClass()
+ .getName().indexOf("xerces")!=-1) {
+ try{
+ webDigester.setFeature(
+ "http://apache.org/xml/features/validation/dynamic";,
+ true);
+ webDigester.setFeature(
+ "http://apache.org/xml/features/validation/schema";,
+ true);
+ } catch(ParserConfigurationException e){
+ // log("contextConfig.registerLocalSchema", e);
+ } catch(SAXNotRecognizedException e){
+ // log("contextConfig.registerLocalSchema", e);
+ } catch(SAXNotSupportedException e){
+ // log("contextConfig.registerLocalSchema", e);
+ }
+
+ }
}Remember that the same instance (or parser) is used for validating both DTD and schema.
See my patch above. The first schema implemenation I've submitted to the digester team was parser-independent, except it only works with Xerces 2.0.1, 2.0.2 and 2.1 (2.2 was completely broken...truss me I spend a fair amount of time finding it was broken :-( ). Xerces 2.3- Xerces 2.5 still suppors schema in a parser-independent way, except validating schema & DTD with the same parser is broken (and the jaxp spec is unclear about that part). If the majority of digester uses 2.1, the we are safe and we should not apply my patch. IMBW, but I think people use at least 2.3....
The original "solution" you proposed for Digester was simply to rip out all support for parser-independent setting of this feature, and force the user to use parser-specific code. No criticism intended: if JAXP doesn't provide a parser-independent way of enabling schema validation, then it doesn't. However I wouldn't call this a "solution". Has something different been implemented for Tomcat?
Well, we can kept the actual feature, but as Robert has suggested, inside some kind of factory ( the current implementation may/would be the default ).
You also say "we need to set those unportable property for now". Does this mean that the existing code might be restored in the near future?
Or something like:
You can do it actually by calling digester.setFeature or digester.setProperty. Is that what you means?maybe one solution might be to refactor the setting algorithm into a separate class and then have factory methods for each parse type which create instances that know how to execute the required configuration.+1
Sounds good to me provided everyone is sure there isn't a parser-independent way to do this.
Can this solution be generalised to handle setting of parser-dependent features other than just schema language?
No. Robert is proposing some kind of encapsulation. I'm not entirely
sure what he is implying, but I think it is something like this:
public interface ParserFeatureSetter { public void enableSchemaValidation();
}
with concrete classes for each different parser implementation, and some kind of factory to create the correct concrete class.
I'm just thinking what other methods could exist on this interface, ie
what other facilities parsers provide that
If setFeature has a JAXP-defined url for a feature, I consider this "parser-independent". However in many cases behaviour X is available in many/all parsers but requires a different feature "uri", requiring the calling code to be parser-dependent. Adding these common features as methods on the above interface would allow the calling code to be parser-independent again.
public interface ParserFeatureSetter{
public void enableSchemaValiation(Parser parser);
}
and we may have a default one that encapsulate the current schema implementation (that works with Xerces 2.1). So we are not using any functionality.
Thanks,
-- Jeanfrancois
Robert, if I've misunderstood your suggestion, please let me know.
Regards,
Simon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
