[
https://issues.apache.org/jira/browse/OLINGO-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743128#comment-16743128
]
Joel Aelwyn commented on OLINGO-1328:
-------------------------------------
After poking at the problem for a bit, I did come up with a fourth option,
although I'm not yet convinced that it really addresses the issue particularly
well: by narrowing the type of the OData instanced passed to ODataImpl and
narrowing the returned type of ODataImpl.createRawHandler to ODataHandlerImpl,
it becomes possible to use the OData instance to create the raw handler while
meeting the existing requirement in the code.
However, this feels like it is probably going the wrong direction, moving away
from using interfaces and making the binding even tighter. It is also really
just a variation of the "parameterize OData with the details of the types
returned" solution from the original description, in many ways.
> 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
>
> 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)
