[
https://issues.apache.org/jira/browse/WODEN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523573
]
John Kaputin commented on WODEN-177:
------------------------------------
Prior to the last change (r570770) the scope of the WSDLContext was the
WSDLFactory. All objects created by the WSDLFactory would share the same
context object, and hence have access to the same ErrorReporter and
ExtensionRegistry.
However, the API permits the user to set a custom extension registry on the
WSDLReader via the setExtensionRegistry method. The use case is where the
standard factory is OK for creating the reader, but a user-provided extension
registry is needed for parsing the WSDL via the reader. In this use case, the
context or scope of this user-provided registry is the WSDLReader object and
any WSDL element objects that it uses during parsing - this context does not
extend to the WSDLFactory and other objects that the factory creates.
So with r570770, WSDLContext will initially be provided by the WSDLFactory and
passed to a new WSDLReader, but if reader.setExtensionRegistry is called the
reader will store a new WSDLContext object that refers to the original factory
and error reporter, but to the new registry object. This new context object is
'reader-scoped' and will be passed downstream to any WSDL element objects
created by this reader.
Other objects created by the WSDLFactory will continue to refer to the original
factory-scoped WSDLContext (unless those reader or writer objects set a
different extension registry). Note, the ErrorReporter is always scoped to the
WSDLFactory - there are no setErrorReporter methods, only an
errorReporter.setErrorHandler() method. Similar 'writer-scoped' behaviour
still needs to be implemented for the WSDLWriter implementations.
> Share client-configurable objects across the Woden implementation
> -----------------------------------------------------------------
>
> Key: WODEN-177
> URL: https://issues.apache.org/jira/browse/WODEN-177
> Project: Woden
> Issue Type: Improvement
> Reporter: John Kaputin
> Assignee: John Kaputin
> Fix For: M8
>
> Attachments: wsdl_context_src.patch, wsdl_context_test.patch
>
>
> Some objects such as ErrorReporter and ExtensionRegistry can be configured by
> the client, so these objects should be shared across the Woden
> implementation to ensure consistent behaviour. Currently in some places
> references to configured objects are not propagated across the
> implementation, so new objects are instantiated, but these will not contain
> any prior client config, so inconsistent results may occur.
> A WSDLContext object will be introduced to the implementation, which acts as
> a container for shared objects - currently ErrorReporter and
> ExtensionRegistry, but others may be added later. This WSDLContext object
> will be created by the WSDLFactory and a reference to it will be passed to
> objects created by the factory and then on to some objects further
> 'downstream'. The places in the implementation that require a reporter or
> registry will have access to the WSDLContext containing them.
> The 'scope' of the WSDLContext is the WSDLFactory that created it. So any
> objects created by that WSDLFactory instance (WSDLReaders, Descriptons, etc)
> will share the same WSDLContext and hence the same ErrorReporter and
> ExtensionRegistry. Any changes made to these shared objects will be
> reflected across the scope.
> This design can be revisited if a use case is identified that requires a
> finer-grained scope (e.g. scoped to the WSDLReader).
> Initially, the WSDLContext class will be internal-only, not part of the API.
> If a suitable use case is identified, it could be added to the API.
> With this solution, we can reduce the number of setters and getters for
> ErrorReporter and ExtensionRegistry across the API and impl classes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
