[
https://issues.apache.org/jira/browse/OLINGO-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Aelwyn updated OLINGO-1328:
--------------------------------
Attachment: 0001-OLINGO-1328-Make-OData-instance-visible-to-descendan.patch
> 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)
