Joel Aelwyn created OLINGO-1328:
-----------------------------------
Summary: 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
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)
