[jira] [Comment Edited] (OLINGO-193) Olingo on Spring implementation scenarion

["Lior Okman (JIRA)" <ji...@apache.org>]

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

Lior Okman edited comment on OLINGO-193 at 12/22/14 6:01 PM:
-------------------------------------------------------------

Hi,

I've examined the ODataServlet code (to be used without CXF), and in my opinion it is not usable in any intermediate to advanced scenario with the Spring framework (note that the Spring framework is not the same thing as Spring Boot).

The problem with ODataServlet is that it uses reflection to create the factory instance, and there is no way to inject a pre-instantiated service factory to it, because of this code (line 70 in the ODataServlet file):
{code}
   serviceFactory = (ODataServiceFactory) Class.forName(factoryClassName).newInstance();
{code}

This sort of code is anathema to the way that the Spring framework works. There is a way to workaround this bad behaviour (by using AOP with the Spring @Configurable functionality and dynamic weaving) but it is hacky in this context, and not code I would want to be forced to use.

While your simple project does use Spring, it is impossible to have the service factory be a Spring managed bean, so there is actually no advantage to using Spring in combination with Olingo the way that your simple project does this - and it is not what is required in order to say that Olingo supports Spring.

Regards,
Lior


was (Author: lior.okman):
Hi,

I've examined the ODataServlet code (to be used without CXF), and in my opinion it is not usable in any intermediate to advanced scenario with the Spring framework (note that the Spring framework is not the same thing as Spring Boot).

The problem with ODataServlet is that it uses reflection to create the factory instance, and there is no way to inject a pre-instantiated service factory to it, because of this code (line 70 in the ODataServlet file):
{code}
   serviceFactory = (ODataServiceFactory) Class.forName(factoryClassName).newInstance();
{code}

This sort of code is anathema to the way that the Spring framework works. There is a way to workaround this bad behaviour (by using AOP with the Spring @Configurable functionality and dynamic weaving) but it is hacky in this context, and not code I would want to be forced to use.

While your simple project does use Spring, it is impossible to have the service factory be a Spring managed bean, so there is actually no advantage to using Spring in combination with Olingo - and it is not what is required in order to say that Olingo supports Spring.

Regards,
Lior

> Olingo on Spring implementation scenarion
> -----------------------------------------
>
>                 Key: OLINGO-193
>                 URL: https://issues.apache.org/jira/browse/OLINGO-193
>             Project: Olingo
>          Issue Type: New Feature
>          Components: odata2-core
>         Environment: Spring
>            Reporter: Jan Penninkhof
>            Assignee: Michael Bolz
>            Priority: Minor
>              Labels: spring
>         Attachments: move-up.diff, root-locator-reuse.diff, spring-core-olingo.diff, spring.diff, unittests.diff
>
>
> Currently only a imlementation scenario using CXFNonSpringJaxrsServlet is provided. However, to implement OLingo while bootstrapping Spring at the same time, this scenario won't work. Instead probably CXFServlet should be used instead.
> However, CXFServlet has quite a different API and Olingo currently doesn't have wiring to that API.
> It would be excellent if there would be a version of Olingo that could work in a Spring environment as well, e.g. to allow for reuse of existing Spring components.
> Please also refer to a discussion on this topic in the mail-archive:
> https://www.mail-archive.com/dev@olingo.incubator.apache.org/msg02186.html



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