I want to connect servlet using urlconnection in wicket-spring integration, but when i try to hit the url its redirecting to webapplication page, So can anyone tell me how to connect servlet methods by using filters or any other way, so that i can directly hit dopost or doget methods.
The question is not very clear, so I'll try to guess. I suppose that you have a Wicket filter that intercepts and handles all the requests. Also you have some servlet, and you want requests to that servlet to not be intercepted by Wicket filter.
If this is what you want, here is what you can do to achieve this.
Let's say you have Wicket filter mapped to / and the servlet mapped to /my-service. Then you could tell Wicket filter to ignore requests to /my-service url:
<filter>
<filter-name>wicket.filter</filter-name>
<filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
<init-param>
<param-name>applicationClassName</param-name>
<param-value>... some application class name ...</param-value>
</init-param>
<init-param>
<param-name>ignorePaths</param-name>
<param-value>/my-service</param-value>
</init-param>
</filter>
If you want several paths to be ignored, you can separate them with commas like this:
<init-param>
<param-name>ignorePaths</param-name>
<param-value>/my-service,/my-other-service</param-value>
</init-param>
With this configuration, Wicket will ignore any requests under /my-service (that is, /my-service, /my-service/blabla and so on) and any request under /my-other-service.
Related
I'm investigating using Jetty 9 as a proxy, using standalone Jetty, not embedded Jetty. I've looked for help in many places:
Most of these are related to embedded Jetty:
How to create Proxy Server using jetty8?
Jetty ProxyServlet with SSL support
This question is along the same lines:
Can stand-alone Jetty be used as a reverse proxy (without Apache mod-proxy)
...but the only answer is a link to a page that covers some parameters for the proxy, but no examples or other helpful hints.
On to the question...
I've created an extension to Jetty's ProxyServlet, which overrides the rewriteURI() method to actually change the request to a different URL. This custom proxy works when running Jetty embedded, but when I use a web.xml file and the jetty-maven-plugin to create a war to deploy, it no longer works.
When I make a request, I can debug the application and see that it gets into the rewriteURI() method, it then calls Jetty's ProxyServlet's service() method, which runs to completion, but then nothing happens. The page remains blank, and eventually ProxyServlet's onResponseFailure() is called with a TimeoutException, "Total timeout elapsed". Dev tools shows the request receiving a 504 Gateway Timeout.
It seems as though something is missing in how things are connected, but I can't tell what it might be. Any help would be greatly appreciated. I've included web.xml and the custom proxy (ProxyServletExtension) below.
web.xml
<servlet>
<servlet-name>proxy</servlet-name>
<servlet-class>org.example.ProxyServletExtension</servlet-class>
<init-param>
<param-name>maxThreads</param-name>
<param-value>1</param-value>
</init-param>
<async-supported>true</async-supported>
</servlet>
<servlet-mapping>
<servlet-name>proxy</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
ProxyServletExtension.java
...
import org.eclipse.jetty.proxy.ProxyServlet;
...
public class ProxyServletExtension extends ProxyServlet {
#Override
protected URI rewriteURI(HttpServletRequest request) {
// Forward all requests to another port on this machine
String uri = "http://localhost:8060";
// Take the current path and append it to the new url
String path = request.getRequestURI();
uri += path;
// Add query params
String query = request.getQueryString();
if (query != null && query.length() > 0) {
uri += "?" + query;
}
return URI.create(uri).normalize();
}
}
I found the hints I needed to solve this with jetty transparent proxy always returns 403 forbidden. The question didn't exactly pertain to my question, but the code snippet provided showed me what I needed in the <servlet> in web.xml.
Updated web.xml
<servlet>
<servlet-name>proxy</servlet-name>
<servlet-class>org.example.ProxyServletExtension$Transparent</servlet-class>
<init-param>
<param-name>maxThreads</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>proxyTo</param-name>
<param-value>http://localhost:8060</param-value>
</init-param>
<async-supported>true</async-supported>
</servlet>
<servlet-mapping>
<servlet-name>proxy</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
Required changes
Set the <servlet-class> to ProxyServletExtension$Transparent, previously I wasn't using a trasparent proxy.
Use an <init-param> of proxyTo using the address you would like to proxy the requests to. This also means that the ProxyServletExtension.java class above (in the question) is completely unnecessary.
Also, it is worth mentioning that there is a prefix <init-param> as well, which can be used to remove part of the incoming request before proxying to the proxied request.
<servlet>
<servlet-name>springmvcdemo</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>springmvcdemo</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
vs
<servlet>
<servlet-name>springmvcdemo</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>springmvcdemo</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
I know there are duplicated questions but i'm still confused. My understanding is that when using /* , every request will go through this servlet (It means all .jsp, .html,etc will end up in this ). / will make this servlet the default servlet ( if there are exact URL installed..., return ) But it seem to me that when using / every request all still go through The DispatcherServlet no matter what. I can't open any .jsp file directly. Can someone explain to me more about this?
As per the Servlet specification, mapping for "/" means default servlet meaning if there is no explicit servlet matching the request, then this default servlet would be serving the request. For e.g., there is a servlet named "default" defined in Tomcat server common configuration web.xml which is inherited by all applications. This servlet serves the static contents like css,images etc which are typically not mapped in applications web.xml. Similarly there is a special Servlet which handles requests for jsp files ( all request ending with *.jsp as naturally these will be needed to be compiled to Servlets which would then process the request). So if you override the default servlet to be any other servlet in the application web.xml, then all requests not handled by any other servlet goes to this servlet and if this Servlet is not capable to serving request, it will not work.
If you declare Spring dispatcher servlet as the default Servlet, then you will not be able to serve static contents from container provided Servlet. Instead there is a special handler provided which can load static resources from configurable path pattern from directory / classpath. You need to use <mvc:resources/> tag for this feature. However if you still want to use container provided Servlet for serving resource you would need to use
<mvc:default-servlet-handler/> in the spring configuration. You can read more about this approach and its prons/cons here - section 15.12.4
I am learning Spring MVC .
To configure servlet mapping in web.xml.
Who can tell what's difference between them
<servlet-name>login</servlet-name>
<url-pattern>/login/</url-pattern>
<servlet-name>login</servlet-name>
<url-pattern>/login</url-pattern>
<servlet-name>login</servlet-name>
<url-pattern>/</url-pattern>
<servlet-name>login</servlet-name>
<url-pattern>/*</url-pattern>
<servlet-name>login</servlet-name>
<url-pattern>/*.do</url-pattern>
Maybe more...
It is really necessary for me to know ,so that a new servlet will not be Intercept by other ones.
<servlet-name>login</servlet-name>
<url-pattern>/login</url-pattern>
This is exact url pattern, this servlet will be invoked only if the url is like someThing.com/login
<servlet-name>login</servlet-name>
<url-pattern>/*</url-pattern>
This is directory url pattern. So /someString or /someOtherString or /some/someOther will invoke the same login servlet.
<servlet-name>login</servlet-name>
<url-pattern>/*.do</url-pattern>
This is extension url pattern. Anything that is suffixed as .do will map to this. e.g. /someUrl.do or /some/someOther.do will invoke the login servlet.
this looks rather strange,you have this
<servlet-name>login</servlet-name>
<url-pattern>/*</url-pattern>
and thats all you need, the rest of the mapping are supercilious. But calling your spring servlet login is a bit weird. Normally you would call it spring-servlet or similar, everything is then mapped to that servlet, and specific request mappings are handled by different controllers - you can use RequestMappign annoation on controller methods.
I need to log in with j_spring_security_check using special characters in the username and/or in the password via url
http://localhost:8080/appname/j_spring_security_check?j_username=username&j_password=üüü
isn't working and
http://localhost:8080/appname/j_spring_security_check?j_username=username&j_password=%c3%bc%c3%bc%c3%bc
(with "üüü" urlencoded)
isn't working either
Any suggestion? Let me know if you need to see any other configuration.
Thanks
The Java Servlet standard is lamentably poor at supporting Unicode. The default of ISO-8859-1 is useless and there is still no cross-container-compatible means of configuring it to something else.
The filter method in matteosilv's answer works for request bodies. For parameters in the URL, you have to use container-specific options. For example in Tomcat, set URIEncoding on the <Connector> in server.xml; in Glassfish it's <parameter-encoding> in glassfish-web.xml.
(If you have to work in a fully cross-container-compatible manner you end up having to write your own implementation of getParameter(), which is sad indeed. Bad Servlet.)
However in any case it is a bad idea to pass login form fields in GET URL parameters.
This is firstly because a login causes a state-change to occur, so it is not "idempotent". This makes GET an unsuitable method and causes a load of practical problems like potentially logging you in when you navigate a page, or failing to log you in due to caching, and so on.
Secondly there are a range of ways URLs can 'leak', including referrer tracking, logging, proxies and browser history retention. Consequently you should never put any sensitive data such as a password in a URL, including in GET form submissions.
I'd suggest using a POST form submission instead, together with the CharacterEncodingFilter.
Maybe an encodingFilter in the web.xml file could be helpful:
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>
org.springframework.web.filter.CharacterEncodingFilter
</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
source: Spring security: Form login special characters
The issue was actually solved for me by moving the CharacterEncodingFilter ABOVE the SpringSecurityFilterChain in web.xml.
I'm new to Java Enterprise and to Spring but I have a strong grasp of standard Java. I am looking through an existing web application project. The project uses Tomcat/Spring/Hibernate which I understand is fairly common. It also uses DWR for remote method invocations. I'm finding it somewhat difficult to separate responsibilities: what Tomcat is responsible for, what Spring is responsible for, how a request gets from one to the other, and how the major pieces of Spring fit together. I've read a great deal of documentation on Spring, particularly about beans and bean factory and am still in process of reading more. Any advice you guys have would be welcome, but I'll provide some specific questions.
Question 1: Where does the web.xml fit into things (when is it used/called, and where is it called from)?
Code sample 1:
<servlet>
<servlet-name>qrst</servlet-name>
<display-name>qrst Servlet</display-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
What does the above snippet do (or, what does it cause to happen)? At some point in my web app qrst.jsp gets used; is it the DispatcherServlet that calls qrst.jsp using the servlet name? Else what is the significance of the servlet name? What is load on startup?
Code sample 2:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/someLocation/some-servlet.xml
</param-value>
</context-param>
Links or explanation of what the above does? I can see from looking at the XML file that it contains bean definitions and I do understand what beans are and how they are used, but I don't know any other details about this and would like to.
Code sample 3:
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<display-name>DWR</display-name>
<servlet-class>
org.directwebremoting.servlet.DwrServlet
</servlet-class>
<init-param>
<param-name>classes</param-name>
<param-value>
somepackage.someclass
</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
From what I read about beans, I believe those init-param elements are just parameters that get set in the servlet's java class. What's the significance of the servlet name, and what about the load on startup? The web app somehow "knows" when an AJAX (dwr) call is happening versus when the web app is being loaded for the first time (when its loading for the first time it should use qrst.jsp). How does it know this? How does it decide to route the request to DWR instead of to qrst.jsp? Where does it do this?
Thanks.
Servlets are JavaEE's idiom for answering HTTP requests. You program the behavior of your application in a Servlet which will respond to a request.
Tomcat is a Servlet container, which means you deploy your application in Tomcat and it will manage all the communication infrastructure for you: it accepts connections, manages database connections(*) and will call upon your servlets to handle incoming requests.
web.xml is part of any JavaEE application, not Spring. Your code sample 1 declares that your app will use an instance of class org.springframework.web.servlet.DispatcherServlet to handle incoming requests.
Although servlets are the basic foundations for JavaEE development, it is not advised to create your own; instead, with Spring, you create MVC controllers. Then the DispatcherServlet will call upon these controllers to handle the requests. It's just another indirection (but a very powerful one!)
is it the DispatcherServlet that calls qrst.jsp using the servlet name?
Not directly. It's just a coincidence that your servlet and the JSP file have the same name.
What is loaded on startup?
Your code sample 2 instructs the DispatcherServlet to load the beans from file /someLocation/some-servlet.xml. If there are controller beans in this file and according to how you configured the url mapping, beans from this file will answer the incoming requests. See the reference.
I believe those init-param elements are just parameters that get set in the servlet's java class
The init-param elements in web.xml are for the servlet class.
The web app somehow "knows" when an AJAX (dwr) call is happening versus when the web app is being loaded for the first time (when its loading for the first time it should use qrst.jsp). How does it know this?
Missing from the question are either the <servlet-mapping> element (found in web.xml), or the url mappings (found in the spring files). These are responsible for deciding whether an URL should be handled by the dispatcher servlet or the dwr servlet.
For instance, with an servlet mapping like below:
<servlet-mapping>
<servlet-name>qsrt</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>dwr</servlet-name>
<url-pattern>*.dwr</url-pattern>
</servlet-mapping>
Then all URLs ending in .do will be answered by the dispatcher servlet, and those ending with .dwr will be handled by the dwr servlet. Here's where the names of the servlets are important.
JSP files are a different story. The container will simply use them to handle a URL ending in *.jsp. Do not create your onw servlet mapping for URLs ending in *.jsp. This will only cause headaches. This is probably unspecified behavior.
Edit:
However, the URL in the browser's address bar always looks the same: it would always invoke the qrst servlet
Then it is possible that your servlet-mapping is so broad (something like: <url-pattern>/*</url-pattern>) that it will handle anything you throw at the server and never give a chance for the other servlets to handle it.
Last but not least, when working with DWR or any Ajax technology, install the HttpFox extension for Firefox so you can monitor the Ajax calls of your application.