[jira] [Commented] (OLINGO-856) ODataHandler like interface in core API

[Michael Bolz (JIRA)]

    [ 
https://issues.apache.org/jira/browse/OLINGO-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146392#comment-15146392
 ] 

Michael Bolz commented on OLINGO-856:
-------------------------------------

Hi [~rareddy],

Thanks for feedback.

I agree with your idea of less "register" methods in the interface.
However I would suggest to have separate register methods for _necessary_ parts 
and one for the _extensions_.
So that the {{ODataHander}} looks like (1):
{code}
public interface ODataHandler {
  ODataResponse process(final ODataRequest request);
  void register(Processor processor);
  <T extends OlingoExtension> void register(T extension);
}
{code}

Of my favorite (2):
{code}
public interface ODataHandler {
  ODataResponse process(final ODataRequest request);
  void register(Processor processor);
  <T extends OlingoExtension> void registerExtension(T extension);
}
{code}
This way it is for the (service) developer clear that he register an extension 
(in addition the {{CustomContentTypeSupport}} and {{CustomETagSupport}} then 
have to extend the {{OlingoExtension}} (marker) interface).


However for backward compatibility I think we have the option to do (3):
{code}
public interface ODataHandler {
  ODataResponse process(final ODataRequest request);
  void register(Processor processor);
  <T extends OlingoExtension> void register(T extension);
}
{code}
and let the {{CustomContentTypeSupport}} and {{CustomETagSupport}} extend the 
{{OlingoExtension}} (marker) interface.

or (4):
{code}
public interface ODataHandler {
  ODataResponse process(final ODataRequest request);

  void register(Processor processor);
  <T extends OlingoExtension> void register(T extension);

  void register(CustomContentTypeSupport customContentTypeSupport);
  void register(CustomETagSupport customETagSupport);
}
{code}

So my favorite is (3) (because (2) could cause compile errors on existing code),
however (4) is the option which provides full backward compatibility and 
introduce the new method and marker interface.

Best Regards, 
Michael

> ODataHandler like interface in core API
> ---------------------------------------
>
>                 Key: OLINGO-856
>                 URL: https://issues.apache.org/jira/browse/OLINGO-856
>             Project: Olingo
>          Issue Type: New Feature
>          Components: odata4-server
>    Affects Versions: (Java) V4 4.1.0
>            Reporter: Michael Bolz
>            Assignee: Michael Bolz
>            Priority: Minor
>
> If Olingo will be used in a none Java Servlet environment it is complicated 
> to do this because of the {{void process(HttpServletRequest request, 
> HttpServletResponse response);}} entry point which is dependent on the 
> servlet request/response objects.
> To avoid this a interface with a {{process}} method like in the 
> {{org.apache.olingo.server.core.ODataHandler}} with the {{ODataRequest}} and 
> {{ODataResponse}} objects would be better.
> This interface also should be the result of the 
> {{OData.createHandler(ServiceMetadata serviceMetadata):ODataHttpHandler}} 
> method.
> This would help a lot to use Olingo in other web frameworks (beside of the 
> Java Servlet).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)