[
https://issues.apache.org/jira/browse/OLINGO-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750625#comment-16750625
]
Joel Aelwyn commented on OLINGO-1328:
-------------------------------------
The attached patch takes a different path to achieving the same basic goal, by
adding a constructor to ODataHttpHandlerImpl that allows descendants to pass an
already-created instance of ODataHandlerImpl, meaning that they can provide an
alternative implementation as long as it extends ODataHandlerImpl. It also
modifies the protection level of the OData instance stored by ODataHandlerImpl
so that it is visible to descendants, rather than forcing them to store their
own copy.
It adds no new unit tests, although the modified code should be covered by
existing tests due to the fact that the "primary" constructor now passes
through to the newly created one.
> ODataHttpHandlerImpl should not be tightly coupled to ODataHandlerImpl
> ----------------------------------------------------------------------
>
> Key: OLINGO-1328
> URL: https://issues.apache.org/jira/browse/OLINGO-1328
> Project: Olingo
> Issue Type: Improvement
> Components: odata4-server
> Affects Versions: (Java) V4 4.6.0
> Reporter: Joel Aelwyn
> Priority: Minor
> Attachments:
> 0001-OLINGO-1328-Make-OData-instance-visible-to-descendan.patch
>
>
> The constructor of ODataHttpHandlerImpl creates an instance of
> ODataHandlerImpl directly, which forces a tight coupling and requires that
> anything which wishes to provide an alternative implementation of
> ODataHandler must also provide an alternative implementation of
> ODataHttpHandler, even if the custom implementation extends the existing
> ODataHandlerImpl class and no changes to ODataHttpHandlerImpl are otherwise
> required.
> There are multiple ways in which this could be resolved:
> * Use the OData instance passed to the constructor to obtain the handler
> instance, which would require addressing the visibility of the
> getLastThrownException, handleException, and getUriInfo methods on the
> handler by either:
> ** Parameterizing the OData class with the type of the handler implementation
> and requiring that the instance passed be parameterized appropriately
> (probably not a great answer).
> ** Exposing the methods as part of the ODataHandler interface.
> * Providing a protected, non-final method to obtain the handler instance, so
> that extenders of ODataHttpHandlerImpl can control what implementation of
> ODataHandlerImpl is generated and used.
> There might also be other alternatives I'm missing that would be preferable,
> but the only example of this that I could find in the current project is the
> Netty approach, which results in large amounts of duplicate code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
