[
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/[email protected]/msg02186.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
