I'm trying to migrate an application from wildfly 9.0.1 to wildfly 10.1 and when I try to access the page I get this error.
The only component I could think of in my page related to it is a selectManyCheckbox maybe but I can't find anything that tries to render an "enable" string.
As it turns out it was a property set in my web.xml to blame:
<context-param>
<param-name>org.richfaces.enableControlSkinning</param-name>
<param-value>enable</param-value>
</context-param>
Related
I want to use springboot with security and primefaces.
I have followed this article but with one little change, I don't want to use JoinFaces. Everything works fine except the spring sec taglib.
xmlns:sec="http://www.springframework.org/security/tags
Now I'm not sure how to configure servletContext so that the sec tags would work.
Here is GitHub repo for now its really simple project just to test the combination SB + SS + PF.
I had the same scenario before and I ended up adding springsecurity.taglib.xml in my project. You can copy the file content from here and then register it in your web.xml file as follow:
<context-param>
<param-name>javax.faces.FACELETS_LIBRARIES</param-name>
<param-value>/WEB-INF/springsecurity.taglib.xml</param-value>
</context-param>
I am running an jsf2.2 application and using Primefaces with JAVA 1.6, i am trying to disable the client window feature which removes the jfwid.Please suggest me how i can handle this issue.
I believe the ClientWindow feature is disabled by default. The following JavaDoc details the behavior:
http://docs.oracle.com/javaee/7/api/javax/faces/lifecycle/ClientWindow.html#CLIENT_WINDOW_MODE_PARAM_NAME
Also I'm not sure why disableClientWindow would be expected on a p:commandButton(h:commandButton) as that is a POST request whereas the p:button(h:button) would be a GET request.
Looking at the vld docs for the h:commandButton you'll see there is not a disableClientWindow attribute but on the h:button there is.
I've tried disable it to all application on web.xml, but without any success. I tried the follow:
<context-param>
<param-name>javax.faces.lifecycle.ClientWindow.CLIENT_WINDOW_MODE_PARAM_NAME</param-name>
<param-value>none</param-value>
</context-param>
The only way that I got it to work was using it on code before a redirect, for example:
FacesContext.getCurrentInstance().getExternalContext().getClientWindow().disableClientWindowRenderMode(FacesContext.getCurrentInstance());
return "/home?faces-redirect=true";
Or using it on own button or link:
<a jsf:disableClientWindow="true" target="_blank" jsf:outcome="go_to_anywhere?faces-redirect=true">GoToAnywhere</a>
I have made a web application to be deployed in the Websphere server but i came up with a problem.
I have 20 servlets that use a common parameter so i have this declared on web.xml:
<context-param>
<param-name>filePath</param-name>
<param-value>C:\logs.txt</param-value>
</context-param>
I want this parameter to be easily edited in the Websphere console but doesn't work. I know this works on Tomcat but is there anything equivalent on websphere?
Thanks
You should edit web.xml only on the server, there is know interface for it in the Console, as I remember.
You can find this file here:{WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/enterpriseappname/deployments/deployedname/webmodulename
Link to the documentation:
http://www-01.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/tweb_jsfengine.html
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>
In the web.xml file, I'm trying to specify an error page as follows.
<error-page>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
I expect it to go without an error code according to Servlet 3.0 but it doesn't. I have to explicitly specify an appropriate error code for it to work something like the following.
<error-page>
<description>Missing page</description>
<error-code>404</error-code>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
Why doesn't the former approach work with Servlet 3.0?
I have upgraded NetBeans 7.2.1. It supports Apache Tomcat 7.0.27.0 which has Servlet 3.0 API.
By the way, I have disabled the HTTP Monitor as it raises the following warning.
MonitorFilter::WARNING: the monitor filter must be the first filter in
the chain.
It happened when I used Spring security in my application and it was reported as a jira issue.
Have a look at this post. I never personally made this
<error-page>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
working on Tomcat 7, as for the bug described in the link I gave you. I don't know if Apache solved it in later version of Tomcat, but I doubt.
My previous statement was probably wrong. Digging a bit, I found this: https://issues.apache.org/bugzilla/show_bug.cgi?id=52135 and the problem should have been solved in Tomcat 7.0.29, so your only solution is to update to post-29 version.
Here: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html, in the changelog for version 7.0.29 you can read why there was such an issue:
Add support for a default error page to be defined in web.xml by
defining an error page with just a nested location element. It appears
this feature was intended to be included in the Servlet 3.0
specification but was accidently left out. (markt)