I am learning about filters. So I have the following code in my web.xml:
<filter>
<filter-name>asyncFilter</filter-name>
<filter-class>el.test.AnyRequestFilter</filter-class>
<async-supported>true</async-supported>
</filter>
<filter-mapping>
<filter-name>asyncFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>ASYNC</dispatcher>
</filter-mapping>
When I write is is autocompletes me ASYNC, but after that it becomes in red colour and IntelliJ show me that the error is that is is unknown enum.
Why is that?
Thanks for your attention.
P.S. I have problems with following code too:
<error-page>
<location>/WEB-INF/jsp/view/badRequest.jsp</location>
<error-code>404</error-code>
</error-page>
on <error-code> it is written no child element expected at this point, but the code is working(I can run it).
from https://docs.oracle.com/cd/E19879-01/819-3669/bnagf/index.html
4.In the Add Filter Mapping dialog, select one of the following dispatcher types:
REQUEST: Only when the request comes directly from the client
FORWARD: Only when the request has been forwarded to a component (see Transferring Control to Another Web Component)
INCLUDE: Only when the request is being processed by a component that has been included (see Including Other Resources in the Response)
ERROR: Only when the request is being processed with the error page mechanism (see Handling Servlet Errors)
So ASYNC is not a valid value.
Edit : it seems it was added in javaee 6 : http://docs.oracle.com/javaee/6/tutorial/doc/bnagb.html
So maybe you have some configuration problem of JRE/JDK version with your project and IDE.
Related
I have Login.xhtml and Home.xhtml. I configured the url pattern in web.xml as follows
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>Login.xhtml</welcome-file>
</welcome-file-list>
When I run the whole project, the login page URL is like this http://localhost:8080/fran/Login.xhtml , here fran is my project name..
However, I would like it to be http://localhost:8080/fran/Login/ instead of http://localhost:8080/fran/Login.xhtml.
How can I achieve this? Is it possible to customize the <url-pattern> for every page to get rid of the .xhtml extension?
If your sole reason is to get rid of the .xhtml extension, then there are various ways depending on the JSF version you're using.
JSF 2.3+
JSF 2.3 offers a new API to collect all views: the ViewHandler#getViews(). Combine this with ServletRegistration#addMapping() in a ServletContextListener as below.
#FacesConfig
#WebListener
public class ApplicationConfig implements ServletContextListener {
#Override
public void contextInitialized(ServletContextEvent event) {
addExtensionLessMappings(event.getServletContext(), FacesContext.getCurrentInstance());
}
private void addExtensionLessMappings(ServletContext servletContext, FacesContext facesContext) {
servletContext
.getServletRegistrations().values().stream()
.filter(servlet -> servlet.getClassName().equals(FacesServlet.class.getName()))
.findAny()
.ifPresent(facesServlet -> facesContext
.getApplication()
.getViewHandler()
.getViews(facesContext, "/", ViewVisitOption.RETURN_AS_MINIMAL_IMPLICIT_OUTCOME)
.forEach(view -> facesServlet.addMapping(view))
);
}
}
Effectively, this is an oneliner. Source: Arjan Tijms' Blog and The Definitive Guide to JSF.
If you're using MyFaces as JSF 2.3 implementation, then this can be transparently activated by solely the following web.xml context parameter:
<context-param>
<param-name>org.apache.myfaces.AUTOMATIC_EXTENSIONLESS_MAPPING</param-name>
<param-value>true</param-value>
</context-param>
Mojarra does not have an equivalent yet.
JSF 2.2-
Use OmniFaces FacesViews. It offers a zero-configuration way to achieve that by placing the view files in /WEB-INF/faces-views/ folder. Otherwise, if you intend to not modify your project structure and want to keep your view files at the usual place and still benefit of extensionless URLs, then it's a matter of adding the following context parameter:
<context-param>
<param-name>org.omnifaces.FACES_VIEWS_SCAN_PATHS</param-name>
<param-value>/*.xhtml</param-value>
</context-param>
In case you don't want to use OmniFaces, but rather want to homegrow your own, just look at source code of OmniFaces. It's open source under Apache 2.0 License. It's only not an oneliner.
Take a look at prettyfaces: Pretty URLs for JavaServer Faces ,
Look at the 2. Create pretty-config.xml example in the main page
And take a look at the Chapter 2. Get Started
Just a little complement to mr. #balusc excelent answer about MyFaces on JSF 2.3... (Edit: not really a complement as one can not complement what's complete, but just a workaround for tomcat/tomee users to deal with this tomcat bug).
Using MyFaces 2.3.6, I received a Exception talking about servlet specification and ServletContextListener:
java.lang.UnsupportedOperationException: Section 4.4 of the Servlet 3.0 specification does not permit this method to be called from a ServletContextListener that was not defined in web.xml, a web-fragment.xml file nor annotated with #WebListener
Following the stack i saw this line:
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:103)
And after adding that listener to web.xml all worked fine:
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
I'm working with ZK and spring.
I downloaded 2 different project that now I try to merge. My problem is in this part of code:
<html:form action="j_spring_security_check" method="POST" xmlns:html="native">
that is in the file login.zul. I found these lines in web.xml:
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
I saw that if I change /* with /login.zul it happened that in my url becomes: localhost:8080/myProject/j_spring_security_check and I saw error 404.
If I didn't change my url is localhost:8080/myProject/ and the page index.zul works correctely.
But index.zul is in the same folder as login.zul.
I saw the same error also if I set /index.zul in state of "/*".
How can I decide another url in stead of /*?
Thanks!
The above URL pattern /* declares that you want to protect all your pages. It has nothing to with the fact, which page do you want to load after the successfull login.
The title is also missleading, j_spring_security_check is just the default URL for Spring Security login form submission: SpringSec will start his authentication module (that is username/password checking) when a request to this URL comes. You do not want to change it. You may change it if you for example do not want to tell the world that you uses Spring Security, or you do not want to change your existing login form that uses an other action attribute.
You may have a configuration XML for Spring Security like spring-security.xml or an equivalent Java based configuration) - with a tag in it. You need to set the default-target-url attribute of that tag as
<form-login login-page="/some_dir/login.zul" default-target-url="/some_other_dir/panel.zul"
You should use relative URLs inside your webapp.
You may have an authentication-success-handler-ref instead of default-target-urlin a more complicated situation, but you should not mix them .
I have a WAR file that defines a filter to run on all URLs:
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
...
<filter>
<filter-name>OurRedirectServletFilter</filter-name>
<filter-class>com.mycompany.RedirectServletFilter</filter-class>
</filter>
...
<filter-mapping>
<filter-name>OurRedirectServletFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
The filter is designed to perform some redirects from 'convenience' URLs to a corresponding 'actual' URL, but I don't think that's really relevant to the problem.
On WebSphere 7.0, this filter doesn't run for requests to the root URL, e.g. /ctxroot or /ctxroot/; instead I just get a 404 response. It does run for /ctxroot/blah, whether blah is a valid or invalid path.
I've tried adding additional filter mappings for URL patterns <url-pattern>/</url-pattern> and <url-pattern></url-pattern>, but I get the same behavior.
I've tested on base WAS 7.0.0.0, and with the latest fix pack applied, i.e. WAS 7.0.0.27.
The filter works as expected on WAS 8.5 and I'm pretty sure on WAS 8.0, as well as on every version of WebLogic, JBoss, and Tomcat that I've tried. This then seems to be a bug with WAS 7.0, but I'd still like to find a workaround. Anybody know of one?
I eventually looked at the body of the 404 error response and saw error code SRVE0190E, which led me to this helpful page. The issue is that filters aren't called by default for URLs that correspond to resources that don't exist (though I swear I tested that for a URL other than the context root, and my filter was called).
It's possible to configure WebSphere to call filters in this situation by setting a custom property as further described in the linked page:
com.ibm.ws.webcontainer.invokefilterscompatibility=true
I also found that for the case of the context root URL, setting a welcome-file entry in web.xml that maps to an existing resource causes the filter to be called:
<welcome-file-list>
<welcome-file>fakehome.html</welcome-file>
</welcome-file-list>
As described here: http://wikis.sun.com/display/Jersey/WADL
I'm using Jersey 1.4 in Tomcat 6.
I have tried every possible URI with a "/application.wadl" and all I get is a 404 (not available). I'm obviously not understanding something, but every blog I read makes it sound like this is "out of the box" functionality. I'm using Tomcat 6..should this matter?
I was able to use Pavel's example on using the WadlResource object here, but it seems I shouldn't need to do this: http://markmail.org/message/lbeaw5vyr4qergdd#query:+page:1+mid:fo4dt7tbd6rb3gvi+state:results
thanks.
I think that ChrisO most likely has the answer in that your wadl would be available at http://localhost:{port}/{warname}/application.wadl
I had the same problem, and found out that default application.wadl was only working when configured at the root of the app
My conf included several url patterns like the following
<filter-mapping>
<filter-name>jersey-spring</filter-name>
<url-pattern>/admin/rest/*</url-pattern>
</filter-mapping>
And I had to add this to make it work :
<filter-mapping>
<filter-name>jersey-spring</filter-name>
<url-pattern>/application.wadl</url-pattern>
</filter-mapping>
Hope it helps
If you are using Jersey, the WADL will be given automatically when you suffix the application.wadl to your url.
Here all the /rest/ is the <url-pattern> for the <servlet-mapping>
http: // yourmacine:8080 / RESTfulExample/rest/application.wadl
You need to specify the display-name and url-pattern of the sevlet mapping(if any) before application.wadl
I'm trying to setup Jetty to serve compressed html content. In web.xml I setup GzipFilter and mapped it to /* but this doesn't seem to work. Here's the filter configuration:
<filter>
<filter-name>GZipFilter</filter-name>
<display-name>Jetty's GZip Filter</display-name>
<description>Filter that zips all the content on-the-fly</description>
<filter-class>org.mortbay.servlet.GzipFilter</filter-class>
<init-param>
<param-name>mimeTypes</param-name>
<param-value>text/html</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>GZipFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
I'm just starting to use Jetty, so the solution might be ridiculously simple. If you can link me to documentation that might help me, that would be great too.
GZIP Compression
GZIP Compression can be used to reduce the amount of data being sent "over the wire". Compression is applied as a transport encoding. This can greatly improve webapplication performance, however it can also consume more CPU and some content (eg images) cannot be well compressed.
Static Content
The Jetty Default Servlet can serve precompressed static content as a transport encoding and avoid the expense of on-the-fly compression. If the "gzip" init parameter is set to true, then Jetty will look for compressed static resources. So if a request for "foo.txt" is received and the file "foo.txt.gz" exists, then it will be served as "foo.txt" with a gzip transport encoding.
GzipFilter
The Jetty Gzip Filter is a compression filter that can be applied to almost any dynamic resource (servlet). It fixes many of the bugs in commonly available compression filters (eg handles all ways that content length may be set) and has been testing with Jetty continuations and suspending requests.
Some user-agents may be excluded from compression, so as to avoid some common browser bugs (yes this means IE!).
refer from jetty doc:
http://docs.codehaus.org/display/JETTY/GZIP+Compression
you can look Gzipfilter source code,here is a lot of useful comments :
http://download.eclipse.org/jetty/stable-7/xref/org/eclipse/jetty/servlets/GzipFilter.html
I'm gonna answer this too, since I've had a huge headake trying to make this work, and I finally did it. Also, I'm not a major expert in the fine details of HTTP so I'll give a non-professional answer.
First, here's how I checked if my GZipFilter was working or not. Started Firefox, made sure I had the Firebug addon, started the Firebug addon, went to the "Net" tab. Then I accessed the URL which should return a GZipped response. Here's what Firebug shows:
The "Size" column shows the size of the response. If you hover over the "Size" column label with your mouse, it will tell you that if the response is compressed, then it will display the compressed size of the response.
This all was done with the GZip filter enabled in Jetty. I then removed the GZip filter declaration from my web.xml, restarted Jetty and repeated the test. This time around the response had the exact same size as before, which clearly indicated that the GZip compression was not working.
After multiple trial and errors, what I did is look in Firebug at the "Request Headers" section to see the value for the "Accept" header. I've noticed that here this had values such as "application/xml" and "text/xml", but the way I had configured my GZIp filter's init param "mimeTypes" only contained "text/xml" (and was missing "application/xml"). It was configured like so:
<filter>
<filter-name>GzipFilter</filter-name>
<filter-class>org.eclipse.jetty.servlets.GzipFilter</filter-class>
<init-param>
<param-name>mimeTypes</param-name>
<param-value>text/html,text/plain,text/xml,application/xhtml+xml,text/css,application/javascript,image/svg+xml,application/json,application/xml; charset=UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
After adding the "application/xml" value to the list like so:
<filter>
<filter-name>GzipFilter</filter-name>
<filter-class>org.eclipse.jetty.servlets.GzipFilter</filter-class>
<init-param>
<param-name>mimeTypes</param-name>
<param-value>text/html,text/plain,text/xml,application/xhtml+xml,application/xml,text/css,application/javascript,image/svg+xml,application/json,application/xml; charset=UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
I redid my previous test, and sure enough now the reported size of the response was much smaller:
Also notice that now, the reported Response Headers contain an extra field called "Content-Encoding" with a value of "gzip".
So basically the idea is to check what kind of values you send in your Request "Accept" header and make sure that all those values are configured in the GZip filter's "mimeTypes" init param.
Sometimes using Gzipfilter has some problems, depending on how you are handling buffers and flushing. As such, using org.eclipse.jetty.servlets.IncludableGzipFilter (which actually an extends GzipFilter) may solve your problems.
On jetty 9.3:
edit jetty.conf and include the xml file "jetty-gzip.xml"
edit start.ini and add "--module=servlets"
edit jetty-gzip.xml and configure the mime-types you want.
Restart jetty and test again.
What was the error? Are you getting classpath problems or something else? If classpath, you need to make sure the gzipfilter class is available to the jetty runtime or it will die.
Are you sending the request with the "Content-Encoding: gzip" request header?