ws-woden-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kaputin <>
Subject Re: Defining constants on the API vs. feature/property-specific methods
Date Thu, 20 Oct 2005 11:23:01 GMT
The verbose tracing feature is based on WSDL4J in which is is usage is:

        reader.setFeature("javax.wsdl.verbose", true);

and conditional statements in key methods check the feature and if true,
print to Sysout.

In Woden, I have defined the constant as

When the feature is implemented it could be used via the setFeature method
or we could define specific methods - t.b.d. But there isn't any tracing or
loggin code in Woden yet. The constant defined in Woden is there as a
placeholder for the feature, to be added some time soon - assuming that we
do want tracing and we want to be able to enable/disable it - using
whatever tracing mechanism we decide on (maybe something customizable like
ErrorHandler, maybe log4j?).

Here's the definition of what I referred to as continue-parsing-on-error:

     * Set to <code>true</code> if parsing should continue after
     * encountering a non-fatal error in the WSDL which might result
     * in incomplete WSDL model being returned by the reader,
     * <code>false</code> otherwise.
    public static String FEATURE_CONTINUE_ON_ERROR =

This is not the same as continue-on-fatal-error in Xerces. As discussed
previously, I will leave this out unless we can come up with a use case
scenario that requires it. The behaviour in Woden is to terminate on a
fatal error.

Here's my rationale for continue_on_error:

I think we need some way of deciding, when validation is turned off,
whether to continue parsing a WSDL document after a parsing error has been
encountered. In the WSDL editor scenario where a user is working on an
incomplete WSDL, they might want automatic, parse-time validation turned
off and just request validation explicitly when they're ready.  In this
case, we do want to continue parsing on error and present the partially
complete WSDL model to the user. In a runtime scenario, where validation
(i.e. schema validation and the Woden validator component) has been turned
off for performance reasons, we probably want to terminate on a parsing
error, rather than return an incomplete WSDL model. The intention of this
continue_on_error feature was to capture this decision.  But I'm open to

John Kaputin

             Lawrence Mandel                                               
             om>                                                        To 
             20/10/2005 00:59                                           cc 
             Please respond to         Re: Defining constants on the API   
                 woden-dev             vs. feature/property-specific       


Can you describe how the following features will be used?

verbose tracing

Unless we have a use case for continue-on-fatal-error I'd like to suggest
we do not include this in the Woden parser. The lack of understanding of
the ramifications of using this feature in Xerces has caused confusion in
Eclipse land.

Lawrence Mandel

As per the recent discussion thread, I have added some constants to the
WSDLReader interface representing identifiers for reader configuration
features (verbose tracing, validation, continue-parsing-on-error) and
properties (xml parser api, type system api).  Generic set/getFeature and
set/getProperty methods exist on WSDLReader for making use of these.

Another approach to consider is having feature or property-specific methods
for the small set of Woden-defined features and properties and of course,
keeping the generic methods for user-defined features and properties.

So on WSDLReader we'd create methods something like:

boolean isVerboseFeatureOn()
setVerboseFeatureOn() & setVerboseFeatureOff()
or just

We do this already for some potential config properties with
set/getErrorHandler(), set/getLocale() and set/getFactoryImplName() defined
on the WSDLReader interface. Again, whichever approach we take, we should
be consistent. Just a thought for now - can decide later, when we have a
better idea exactly what the Woden-defined features and properties will be.

John Kaputin

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message