I have to use OpenSessionInViewInterceptor in a non-web application. I have configured OSV Interceptor as follows,
<bean id="openSessionInViewInterceptor" class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
<property name="sessionFactory"><ref bean="sessionFactory"/></property>
</bean>
I'm getting a Lazy load exception. Any pointers to where I'm going wrong? Is the configuration correct?
Or does a non-web app require OpenSessionInViewFilter instead of interceptor?
Thanks!
From the first line Java Doc of OpenSessionInViewInterceptor
Spring web request interceptor that binds a Hibernate Session to the thread for the entire processing of the request.
So if you do not have a Web Request because you do not have a web application, then this Interceptor does not helps you.
The OpenSessionInViewFilter is for only Web Applications too.
So you will need to start your Session/Transaction "By Hand", for example with #Transactional.
Related
We have an existing Spring MVC application (non Spring-boot application) with all (or most) of the beans configured in the XML. We wanted to use this as a Spring Cloud Config Client (we have a Spring Boot application acting as config server).
In this regard, what is the XML equivalent of configuring the beans in XML with refresh scope (same as #RefreshScope annotation). Tried configuring the RefreshScope as bean and using scope="refresh" but could see that the beans are not reflected with new values after peforming /refresh endpoint (from actuator)
Any help on this is highly appreciated
As pointed out in other answers 'refresh' scope is just another scope. However there's an issue where the bean properties are not updated with new values after /refresh call - if you define and inject properties in XML. More on the issue here. However the bean (i.e. actually the proxy) is instantiated after each /refresh call - but you need "aop:scoped-proxy" config since bean to which you inject the 'refresh' scoped bean, could be on a different scope. i.e.
<bean name="xmlValueBean" class="me.fahimfarook.xml.XMLValueBean" scope="refresh">
<aop:scoped-proxy proxy-target-class="true" />
</bean>
Well if you want to use #RefreshScope in core Spring(also Spring MVC) as people already pointed out, you have to implement the scope yourself also.
I also had the same dilemma and I did, I also wrote a blog about it, you can find there all the implementation details.
You can also use Spring Boot Configuration Server with your Spring MVC application, if you like to.
#RefreshScope for Spring MVC
#RefreshScope is just another scope. Look at how the RefreshScope class is implemented. It is creating a new scope named "refresh".
That means you should be able to use the new scope in your XML configuration, like this.
<bean id = "..." class = "..." scope = "refresh">
</bean>
I have a fully functional Restlet app that I am trying to add Spring Data Jpa + Hibernate.
Firstly I need to get Spring and Restlet playing together.
The example below is from the Restlet docs, it is trying to set a root property on the Application Class, I can not find this root property, it must be from and old version of the API.
Can someone please post an example of Spring and Restlet 2.2 config, this is very frustrating.
<bean id="basecampAppliction" class="classpath to Application class">
<property name="root" ref="router" />
</bean>
Also, all the examples I have found rely on Spring doing the routing, I would like to keep the routing in the Application code if that is possible.
The docs on the Restlet web site are out of date, please see fix above.
How can i set proxy for all my controllers in spring framework?
I wanna change the return expresion of my controllers.
I'm going to assume you're using Spring MVC 3.* and an XML configuration. If this is not the case, please let me know and I will update my answer accordingly.
Spring MVC provides the HandlerInterceptor interface which can be used to both pre and post process requests handled by all Controllers. I would suggest that you create and implementation of this interface and use the postHandle() method to change the output of your Controllers accordingly.
Once you have your HandlerInterceptor implementation complete, you will need to instruct Spring MVC to use it. The namespace configuration for Spring MVC makes this very easy. As an example:
<mvc:interceptors>
<mvc:interceptor>
<mvc:mapping path="/**"/>
<bean class="com.example.MyInterceptor" />
</mvc:interceptor>
</mvc:interceptors>
In this example I am registering a single HandlerInterceptor implemented by the class com.example.MyInterceptor. I am also configuring Spring MVC to have the HandlerInterceptor implementation work on all requests. You can of course change the mapping to suit your application needs.
Simply marking a field as #Autowired in a GWT servlet does not work as intended. The code will compile and the web application will start up - which means Spring was successfully able to autowire the field, but when the servlet is actually hit by client-side code, it will yield a NullPointerException - like there's a different, uninitialized copy of the servlet being hit.
I've found several ways on the web to get this working, one is by using a base servlet class that does some Spring logic but doing this means every GWT servlet must extend this base class. The other way was by using AspectJ and the #Configurable Spring annotation. There was very little configuration involved here and it just magically worked.
My question is why doesn't just autowiring the field just work as intended? What is GWT doing that causes this to break.
The code will compile and the web application will start up - which
means Spring was successfully able to autowire the field
Not necessarily. The web container can instantiate a servlet without any help from Spring. Which you could be experiencing:
but when the servlet is actually hit by client-side code, it will
yield a NullPointerException - like there's a different, uninitialized
copy of the servlet being hit.
try overriding Servlet's init():
#Override
public void init(ServletConfig config) throws ServletException {
super.init(config);
WebApplicationContextUtils.getWebApplicationContext(config.getServletContext())
.getAutowireCapableBeanFactory().autowireBean(this);
}
When the RPC service is called from the client, the "server-side" looking at the called URL and the servlets mapping will find the class, will make the instance and it will serve the request. Meaning if you have #Autowired annotation, or you already have an instance of the RPC class in the spring context, it does not matter. The new instance will be created and it won't "know" about Spring.
I resolve this by implementing a class which extends RemoteServiceServlet and implements Controller (from Spring MVC) and ServletContextAware.
This way you can map every RPC service by URL using the Spring MVC approach, for ex:
<bean id="publicUrlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/myFirstRpc">firstRpcServiceBeanRef</prop>
<prop key="/mySecondRpc">secondRpcServiceRef</prop>
</props>
</property>
</bean>
You also avoid the declarations for every single RPC servlet in web.xml, the mappings are clean and you have the Spring injection.
You declare only a single mapping in web.xml for org.springframework.web.servlet.DispatcherServlet which will serve all RPC calls.
There are couple of examples on the web with explanation about GWT RPC and Spring MVC controller integration.
Hope this will help.
It turns out that when using Spring at least, there's a MUCH simpler way to do this such that you can use #Autowired and it doesn't involve massive configuration or base classes. The caveat is that you must also use AspectJ. Here's what you need for your GWT servlet:
#Configurable
public class MyGwtServiceImpl extends RemoteServiceServlet implements MyGwtService
{
#Autowired
private MyService service;
// ...
}
And in your Spring config make sure you also have:
<!-- enable autowiring and configuration of non-spring managed classes, requires AspectJ -->
<context:spring-configured/>
One final note. If you are also using Spring security with your GWT application (and in your GWT servlets), you will need to make sure you define the correct mode to ensure the AspectJ weaving is done correctly (i.e., you get both #Secured annotation processing AND the #Autowired processing) you will need:
<!-- turn on spring security for method annotations with #Secured(...) -->
<!-- the aspectj mode is required because we autowire spring services into GWT servlets and this
is also done via aspectj. a server 500 error will occur if this is changed or removed. -->
<security:global-method-security secured-annotations="enabled" mode="aspectj"/>
I use web profile and it does not allow to use Java EE #Schedule functionality. So, I have several ways to solve the problem:
reinstall the server to use full profile. Problems: it's risky (functionality/performance) for my production and burdensome
Use other scheduling functionality like Spring. Problems: I don't know how to link Spring with JavaEE as I want to use CDI beans in my scheduler. Seam-spring module could help me (http://sfwk.org/Seam3/SpringModule) but its documentation is not available at the moment and I don't really know the status of it.
So, which is the best way to enable scheduling inside my glassfish app?
Thanks
We've had a lot of luck using the Quartz open source job scheduler within Spring on other projects so I can highly recommend it for scheduling. You can configure the scheduler to be started from a Servlet (into which CDI beans can be injected) and the scheduled job can call an EJB Stateless Session bean (into which you can also inject CDI beans).
Here are some links - hope this helps!
Initialze a Scheduler in a servlet container
Here's a great article on calling an EJB from Quartz
Ok, I managed to do this using spring module. Would be better to use embedded Scheduler J2EE functionality, but this is not included into Glassfish web profile, only to full (WTF??). As my project is in prod, I don't want to upgrade to full one, especially as there is no flexible way to do this upgrade. Only full server substitute. Very poor JavaEE....
So, first, we need to define some functionality, which will be run at schedule:
#Scope(value="application")
public class ClosePolisesTimer {
BusinessAttirbuteDAO attributeDAO;
#Scheduled(cron="0 0 0 * * *")
public void doCloseObsolete() {
// ...
}
}
Second, we should create the spring configuration file with the following configuration:
<bean id="businessAttributeDAOBean" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:global/KaskoCalculator/BusinessAttirbuteDAO" />
</bean>
<bean id="ClosePolisesTimer" class="com.rstk.kasko.bean.service.ClosePolisesTimer">
<aop:scoped-proxy />
<property name="polisDAO" ref="polisDAOBean" />
<property name="attributeDAO" ref="businessAttributeDAOBean" />
</bean>
<task:annotation-driven scheduler="closePolisExecutor"/>
<task:scheduler id="closePolisExecutor" pool-size="1"/>
That's all. I define EJB beans and use "aop:scoped-proxy" to initialize my scheduler by them. Spring schedule is included into core spring module, so only core spring dependency is necessary