RESTEasy 2.0.1GA
Java 1.6
Spring 3.0.3
I have tried everything I can, and cannot make head or tail of what's going on. I have a Spring MVC application, however I'd like to have some RESTEasy endpoints available outside the Spring MVC app, but in the same container, ultimately being able to wire in the same beans.
As a first step, I'm simply trying to stand-up RESTEasy inside the container, serving requests from a Spring-configured bean. I have tried the boilerplate from the instructions and have also tried manual setup, to no avail.
Bean
#Resource
#Path("/")
public class NeighborComparison {
private String foo;
#GET #Path(value="customer") #Produces("text/plain")
public String getNeighborComparison() {
return "foo";
}
}
web.xml
<context-param>
<param-name>resteasy.servlet.mapping.prefix</param-name>
<param-value>/api</param-value>
</context-param>
<listener>
<listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>
</listener>
<!-- NOT configuring SpringContextLoaderListener because I declare my own, so if I do, everything
blows up, plus all it actually does is sanity check configuration -->
<listener>
<listener-class>com.example.MyCustomContextLoaderListener</listener-class>
</listener>
<servlet>
<servlet-name>Resteasy</servlet-name>
<servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Resteasy</servlet-name>
<url-pattern>/api/*</url-pattern>
</servlet-mapping>
applicationContext.xml
<bean id="resteasy.providerFactory" class="org.jboss.resteasy.spi.ResteasyProviderFactory"
factory-method="getInstance">
</bean>
<bean id="resteasy.dispatcher" class="org.jboss.resteasy.core.SynchronousDispatcher">
<constructor-arg ref="resteasy.providerFactory"/>
</bean>
<bean id="resteasy.spring.bean.processor" class="org.jboss.resteasy.plugins.spring.SpringBeanProcessor">
<description>
Add Resources and #Providers to the appropriate places
in Resteasy's infrastructure
</description>
<constructor-arg ref="resteasy.dispatcher"/>
</bean>
<bean id="neighborComparison" class="opower.api.customer.neighbor_comparison.NeighborComparison">
</bean>
According to the documentation, all I have to do is “manually register the RESTeasy BeanFactoryPostProcessor by allocating an instance of org.jboss.resteasy.plugins.spring.SpringBeanProcessor”. I believe this spring configuration does that.
Jetty starts and the app context spins up with no issues. Application works normally, however when I
> curl -H"Accept: text/plain" localhost:8080/ei/api/customer
("ei" is the application context). The log shows (this and only this):
2011-03-29 16:44:24,153 DEBUG [qtp-575315405-0] [EI] [] [asy.core.SynchronousDispatcher] PathInfo: /customer
2011-03-29 16:44:24,156 DEBUG [qtp-575315405-0] [EI] [] [asy.core.SynchronousDispatcher] Failed executing GET /customer
org.jboss.resteasy.spi.NotFoundException: Could not find resource for relative : /customer of full path: http://localhost:8080/ei/api/customer
Even if I could convince RESTEasy to show me the mappings, it seems that it's just not discovering my bean.
If I map it explicitly via the resteasy.resources context param, it works, though obviously doesn't have access to auto-wired Spring beans.
Anything else I can try? I have debug log on the entire RESTEasy codebase and I don't get any messages. I've also confirmed that Spring is, in fact, creating my bean, so it's just that RESTEasy isn't finding it.
Your resource class needs to be annotated with #Path annotation for RESTeasy to pick up on it during bootstrap:
#Path("/customer")
#Resource
public class NeighborComparison {
#GET #Path("/{customerId}") #Produces("text/plain")
public String getNeighborComparison(#PathParam("customerId") long customerId) {
return "foo";
}
}
Note the #Path("/{customerId}} annotation without which your #PathParam parameter would not have been mapped correctly, resulting in a pretty detailed exception (and an accompanying 500 response on the client side). Assuming the service is picked up by RESTeasy of course.
In addition if you don't use RESTeasy's SpringContextLoader, you have to make sure your SpringBeanProcessor instance is registered with the ApplicationContext. RESTeasy delegates to it by registering an ApplicationListener in SpringContextLoader:
ApplicationListener listener = new ApplicationListener() {
public void onApplicationEvent(ApplicationEvent event) {
if (event instanceof ContextRefreshedEvent) {
ContextRefreshedEvent cre = (ContextRefreshedEvent) event;
ConfigurableListableBeanFactory autowireCapableBeanFactory = (ConfigurableListableBeanFactory) cre
.getApplicationContext().getAutowireCapableBeanFactory();
new SpringBeanProcessor(dispatcher, registry, providerFactory)
.postProcessBeanFactory(autowireCapableBeanFactory);
}
}
};
configurableWebApplicationContext.addApplicationListener(listener);
If using a custom context loader and not the RESTEasy-provided one, this code has to appear somewhere in your context loader so that everything gets wired up. A bit convoluted, yeah. It is SpringBeanProcessor that goes through all Spring beans and registers with RESTeasy those that have a #Path annotation somewhere in their hierarchy (type and their corresponding interfaces).
Related
Consider a web based application with spring 4. The spring bean profiles is defined in web.xml like:
<context-param>
<param-name>spring.profiles.active</param-name>
<param-value>prod,edb,cas</param-value>
</context-param>
Now consider a bean is defined in spring-applicaiton-context.xml as
<util:properties id="myPolicy"
location=
"classpath:/configs/${ACCESS-ACTIVE-PROFILE-SECOND-ITEM}/my-policy.properties" />
Is it possible that I can access the list of active profiles and select the second one (in my example edb). In this way I can make my resource load dynamically when active profile changes.
This may help! I could get the active profile when web application starts with below code:
public void contextInitialized(ServletContextEvent event){
ApplicationContext applicationContext = WebApplicationContextUtils
.getWebApplicationContext(event.getServletContext());
String activeProfiles[] = applicationContext.getEnvironment().getActiveProfiles();
system.out.print(activeProfiles[1])
}
The syntax would be "#{environment.activeProfiles[1]}" - however, it's too early in the context life cycle; the activeProfiles is not set up before the SpEL is evaluated in this case.
What's wrong with
<beans profile="foo">
<util:properties id="myPolicy"
location="classpath:/configs/foo/my-policy.properties" />
</beans>
<beans profile="bar">
<util:properties id="myPolicy"
location="classpath:/configs/bar/my-policy.properties" />
</beans>
?
Actually, I just found that
"#{environment.getActiveProfiles()[1]}"
works - explicitly calling the getter causes the property to be loaded.
I'm new in Spring and want to connect spring ioc into my small(test) web-app.
I have such Servlet ProductServlet:
public class ProductServlet extends HttpServlet{
private static final long serialVersionUID = 1L;
private RequestHelper requestHelper;
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
processRequest(request);
}
private void processRequest(HttpServletRequest request){
requestHelper.process(request);
}
public RequestHelper getRequestHelper() {
return requestHelper;
}
public void setRequestHelper(RequestHelper requestHelper) {
this.requestHelper = requestHelper;
}
}
and my web.xml:
<servlet>
<servlet-name>ProductServlet</servlet-name>
<servlet-class>com.epam.productshop.controller.ProductShop</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ProductServlet</servlet-name>
<url-pattern>/ProductServlet</url-pattern>
</servlet-mapping>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/spring-config.xml
</param-value>
</context-param>
and also I have such spring configuration xml:
<bean id="factory" class="com.epam.productshop.readerfactory.ReaderFactory">
<property name="file" value="/xml/products.xml" />
</bean>
<bean id="requestHelper" class="com.epam.productshop.requesthelper.RequestHelper" scope="singleton">
<property name="factory" ref="factory" />
</bean>
<bean name="ProductServlet" class="com.epam.productshop.controller.ProductServlet" scope="singleton">
<property name="requestHelper" ref="requestHelper"/>
</bean>
and I have such problem:
I want spring set requestHelper object into my servlet during servlet init(). but instead of this it's gives me nullpointer.
I'm trying to implement my servlet from HttpRequestHandler, writing SpringBeanAutowiringSupport.processInjectionBasedOnServletContext(this, getServletContext()); into init() method and other things that i see in the internet but all this things doesn't solve my problem.
Please help me
In your question you have
<bean name="ProductServlet" class="com.epam.productshop.controller.ProductServlet" scope="singleton">
<property name="requestHelper" ref="requestHelper"/>
</bean>
You cannot instantiate servlets with Spring container, they are instantiated by servlet container. You're merely declaring another instance of ProductServlet.
So, when the Servlet init() method is called you should call
SpringBeanAutowiringSupport.processInjectionBasedOnServletContext(this, getServletContext());`
To inject the requestHelper declare an #Autowired annotated field or property in your servlet:
private RequestHelper requestHelper;
#Autowired
public void setRequestHelper(RequestHelper requestHelper){
this.requestHelper = requestHelper;
}
from processInjectionBasedOnServletContext javadoc:
Process #Autowired injection for the given target object, based on the
current root web application context as stored in the ServletContext.
Here is a solution, which might help you:
public class ProductServlet extends HttpServlet
{
private static final long serialVersionUID = 1L;
private RequestHelper requestHelper = null;
private requestHelperInit(HttpServletRequest request)
{
if(requestHelper == null)
{
ApplicationContext ap = WebApplicationContextUtils.getWebApplicationContext(request.getSession().getServletContext());
requestHelper = ap.getBean(RequestHelper.class);
}
}
}
Then call requestHelperInit(request) method in either your doGet() or doPost() method as the first statement.
If you are still looking for a solution, then I hope this will help you out.
You have a couple of choices. If you really want to inject a servlet, the problem is that the servlet container is already in charge of creating the servlet. Since injections are a creation time occurence, and it's a bit hard to get at this servlet creation, you have to use less elegant solutions. However, this question explains how to inject servlets.
On the other hand, you might consider aborting this approach. If you are really creating a web application, it's fairly uncommon to code directly to the servlet api. Why not choose one of the many web application frameworks that sit on top of the servlet api and provide higher level functionality, aka bells and whistles. One of the bells and whistles is that these frameworks provide convenient integration with Spring so you can easily inject your code. For instance, Struts 2 has a spring plugin that allows you to use spring to inject all of the objects created by the framework, including framework infrastructural components.
My existing Spring Web MVC application has the following handler mapping in the Controller.
#RequestMapping(method = RequestMethod.GET, value = "/welcome")
I trigger the following requesthttp://www.example.com/welcomeand this works fine.
The problem is
http://www.example.com/welcome.check.blah
also works!!!
Also, a HTTP GET request URL to the application with script tag is getting redisplayed though it fails the authorization.
Example http://www.example.com/welcome<script>alert("hi")</script> gets redisplayed as such in the browser window and as a result of my authorization logic "Not authorized" message is displayed.
I wonder if this is a security issue and should I need do any encoding/filtering in the code?
This behavior is due to the option useSuffixPatternMatch which is true by default inside the RequestMappingHandlerMapping (I assume you use Spring MVC 3.1).
useSuffixPatternMatch :
Whether to use suffix pattern match (".*") when matching patterns to requests. If enabled a method mapped to "/users" also matches to "/users.*". The default value is "true".
To set useSuffixPatternMatch to false, the easiest way is to use #Configuration :
#Configuration
#EnableWebMvc
public class Api extends WebMvcConfigurationSupport {
#Override
public RequestMappingHandlerMapping requestMappingHandlerMapping() {
RequestMappingHandlerMapping mapping = super.requestMappingHandlerMapping();
mapping.setUseSuffixPatternMatch(false);
return mapping;
}
}
In current Spring Java config, there is a slightly easier way to configure the same thing:
#Configuration
public class DispatcherConfig extends WebMvcConfigurationSupport {
#Override
protected void configurePathMatch(PathMatchConfigurer configurer) {
configurer.setUseSuffixPatternMatch(false);
}
}
When you use Spring to request a mapping of that type (i.e. "/anything") Spring actually maps your controller to several URLs:
/welcome
/welcome.*
/welcome/
To prevent this - either be more specific when you RequestMapping (i.e. /welcome.htm ), or manually map the URL to controller in your Xml config:
<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/welcome">YourControllerBean</prop>
</props>
</property>
</bean>
Cheers, Pete
You can also restrict this in the web.xml by mentioning the url pattern. Instead of giving "/", you can mention "/.htm" in your web.xml.
Something like
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/application/*.htm</url-pattern>
</servlet-mapping>
You can use the useDefaultSuffixPattern property.
<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
<property name="useDefaultSuffixPattern" value="false" />
</bean>
Also refer URL Pattern Restricting in SPRING MVC
Starting from Spring framework 5.3 useDefaultSuffixPattern is deprecated and turned off by default. Spring upgrade notes, section "Use of Path Extensions Deprecated in Spring MVC"
I would like to use Spring as a JNDI provider. This means that I would like to configure a bean in my Spring context, which can be accessed via JNDI. This would look something like this:
<bean class="org.some.thing.here">
<property name="beans">
<map>
<entry key="w/t/f">
<bean class="some.thing.Else">
// rest ommitted
</bean>
</entry>
</map>
</property>
</bean>
Then, in my application (lets say a Controller), I want to be able to grab this bean via:
Context ctx = new InitialContext();
some.thing.Else bar = (some.thing.Else) ctx.lookup("w/t/f");
How could I go about doing this? I've looked at XBean, however the project looks out of date (doesn't work with Spring 3.0.X I don't think), and there is very little documentation.
Any other options? I would also considering rolling my own jndi provider class if it isn't too hard to do.
EDIT: I should add that I don't have an option using JNDI, I have a library we have to use which requires certain components to be loaded via JNDI. I would like to use Spring as the provider.
Why use JNDI at all? Just get the Spring ApplicationContext and get the bean from that.
Assuming you initialized Spring using ContextLoaderListener in your webapp, you should be able to retrieve the application context from the ServletContext. From there you can get any bean you declared in Spring.
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
Object bean = context.getBean(some.thing.Else.class);
If you have to use JDNI, then you can create a ServletContextListener that does something like the following in contextInitialized():
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
Object bean = context.getBean(some.thing.Else.class);
Context initCtx = new InitialContext();
Context springCtx = initCtx.createSubcontext("spring");
springCtx.bind("bean", bean);
Then, you should be able to lookup the Spring bean at "spring/bean" from the InitialContext.
Two things to note:
The context listener should probably also call initCtx.destroySubcontext("spring") in contextDestroy too.
The java:comp/env namespace is read-only (in Tomcat at least), so you can't put anything there.
Asker edit: Just a couple more points of clarity...
If you plan on referencing Spring beans via ApplicationContext, then you need a ContextLoaderListener defined in your web.xml. This must be defined before your custom listener class... like so:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<listener>
<listener-class>
org.example.sandbox.MyCustomServletContextListener
</listener-class>
</listener>
Also, you can get the ServletContext that getWebApplicationContext uses from the ServletContextEvent, like so:
#Override
public void contextInitialized(ServletContextEvent contextEvent) {
try {
ApplicationContext appContext = WebApplicationContextUtils.getWebApplicationContext(contextEvent.getServletContext());
// get a bean named "myCalendar" from the application context
Calendar cal = (Calendar)appContext.getBean("myCalendar");
// bind via JNDI
Context initialContext = new InitialContext();
Context subCtx = initialContext.createSubcontext("sample");
subCtx.bind("calendar", cal);
} catch (NamingException e) { // ommitted }
}
AngerClown is right, don't bother with JNDI unless you need to provide references to other modules that insist on it. If you are in a webapp container like Tomcat, it will have a JNDI registry. Use that. If not inside a webapp container, it doesn't make sense to have JNDI anyway, since it's for J2EE environments.
Assuming you are inside a webapp, a better way to launch your app is to have the main class be a Spring bean that implements lifecycle interfaces (like InitializingBean) to get a call when it's time to start your app. By that point, your main application class will have been injected with all it's dependencies. This avoids the need to call methods on the ApplicationContext directly.
Even so, if you must call methods on the ApplicationContext and you are launched by Spring, you can implement BeanContextAware and get injected with the context.
Yet another way to write your own JndiExporter
https://blog.konstantinpavlov.net/2008/12/31/how-to-export-spring-bean-to-jndi/
I want to write a simple servlet in JBoss which will call a method on a Spring bean. The purpose is to allow a user to kick off an internal job by hitting a URL.
What is the easiest way to get hold of a reference to my Spring bean in the servlet?
JBoss web services allow you to inject a WebServiceContext into your service class using an #Resource annotation. Is there anything comparable that works in plain servlets? A web service to solve this particular problem would be using a sledgehammer to crush a nut.
There is a much more sophisticated way to do that. There is SpringBeanAutowiringSupportinside org.springframework.web.context.support that allows you building something like this:
public class MyServlet extends HttpServlet {
#Autowired
private MyService myService;
public void init(ServletConfig config) {
super.init(config);
SpringBeanAutowiringSupport.processInjectionBasedOnServletContext(this,
config.getServletContext());
}
}
This will cause Spring to lookup the ApplicationContext tied to that ServletContext (e.g. created via ContextLoaderListener) and inject the Spring beans available in that ApplicationContext.
Your servlet can use WebApplicationContextUtils to get the application context, but then your servlet code will have a direct dependency on the Spring Framework.
Another solution is configure the application context to export the Spring bean to the servlet context as an attribute:
<bean class="org.springframework.web.context.support.ServletContextAttributeExporter">
<property name="attributes">
<map>
<entry key="jobbie" value-ref="springifiedJobbie"/>
</map>
</property>
</bean>
Your servlet can retrieve the bean from the servlet context using
SpringifiedJobbie jobbie = (SpringifiedJobbie) getServletContext().getAttribute("jobbie");
I've found one way to do it:
WebApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(getServletContext());
SpringifiedJobbie jobbie = (SpringifiedJobbie)context.getBean("springifiedJobbie");