This question already has answers here:
How to install and use CDI on Tomcat?
(2 answers)
Closed 7 years ago.
good afternoon every body, I'm stucked on the following problem...
I have to use jsf and cdi on a project, I've seen that when i use cdi i should be usign the #named instead of #ManagedBean, but when i change it the message is no longer shown on the browser.
it is just a test for now, so it has no complex code and stuff.
here is my index:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:head>
<title>Hello JSF!</title>
</h:head>
<h:body>
<h:outputText value="#{teste.message}" />
</h:body>
</html>
here is my bean:
package jsfConnection;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
#Named("teste")
#RequestScoped
public class Teste {
public String getMessage() {
return "ola";
}
}
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
<description>Patrimônio web.xml</description>
<!-- Nome da sua aplicação -->
<display-name>Patrimônio</display-name>
<!-- Faces Servlet -->
<!-- Configuração do arquivo inicial quando a aplicação for inicializada -->
<welcome-file-list>
<welcome-file>index.xhtml</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsf</welcome-file>
</welcome-file-list>
<!-- Configuração do Controlador Faces Servlet -->
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
when i use #ManagedBean it shows normally but when i switch to #Named it simply does not print anything...
This is a duplicate of "How to install and use CDI on Tomcat?". Please note that I attempted to make some detailed instructions on my Blog: "Enabling JSF 2.2 and CDI 1.2 on Tomcat 8". These instructions should work for Tomcat 7 too, although I did not test. I might also be good to note that you might be better off using a version of TomEE, which already comes packaged with an implementation of CDI and JSF.
See the Blog for more detailed information, but setting it all up on Tomcat requires 2 main steps:
Defining the right provided and runtime libraries as your maven dependencies
Configure and Bootstrap the CDI Implementation (Weld).
Setting up bootstrapping happens using the following 3 files:
WEB-INF/web.xml
WEB-INF/beans.xml
META-INF/context.xml - This META-INF directory can be found at the webapp root, or the same location where WEB-INF can be found.
Note also that as part of the web.xml file, you define how requests (URL's) are mapped to a physical location (path). The <servlet-mapping> for your Faces Servlet, which can be either as a path prefix, or as an extension: <url-pattern>/faces/*</url-pattern> vs <url-pattern>*.xhtml</url-pattern>.
Tomcat is not a Java EE server, so CDI doesn't work out of the box. To use CDI in it, you need to 1) include a CDI implementation and 2) configure it in web.xml.
See the documentation of your CDI implementation (Weld or OpenWebBeans) for details.
Related
File uploads are working for small files (under the default 2MB limit), but will not work for larger files. I'm using JSF on Tomcat 8.0 and have modified my web.xml appropriately to increase the limit. I've put breakpoints in the constructor of javax.servlet.MultipartConfig so I can see it reads the web.xml configuration. When the action is called though, it defaults back to the default of 2MB (specifically in Request.parseParts(...) the wrapper's config is null, so uses the connector's default).
WEB.xml:
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
<multipart-config>
<max-file-size>-1</max-file-size>
<max-request-size>-1</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>
</servlet>
home.xhtml
<h:form id="contentFormId" enctype="multipart/form-data">
...
<h:inputFile style="display:none;" id="fileUpload" value="#{bean.uploadItem}">
</h:inputFile>
<h:commandButton id="browse" action="#{bean.fileUploadListener}" value="Add Files" onclick="$('#contentFormId-fileUpload').click()">
</h:commandButton>
...
</h:form>
context.xml
<?xml version="1.0" encoding="utf-8"?>
<Context allowCasualMultipartParsing="true"
...
</Context>
Updated
After creating a simplified application, it appears that the Rewrite library is causing a different container wrapper to be used in the request.
Without Rewrite:
Request.getWrapper() returns StandardEngine[Catalina].StandardHost[localhost].StandardContext[/TestWeb].StandardWrapper[Faces Servlet]
With Rewrite #URLMapping annotation:
Request.getWrapper() returns StandardEngine[Catalina].StandardHost[localhost].StandardContext[/TestWeb].StandardWrapper[default]
So it seems that I need to configure this application's default container similar to how Faces is configured, or find a way to get Rewrite to delegate to the Faces Servlet container. Editing the maxPostSize in Tomcat is an option (change the default), but not one I want to take if I can avoid it.
I don't like this solution, but it serves my purposes for now. It seems like it should default to the FacesServlet's settings because that's the final destination after rewrite.
My solution was to move (or copy) the multipart-config setting to the default servlet in web.xml:
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet>
<servlet-name>default</servlet-name>
<multipart-config>
<max-file-size>-1</max-file-size>
<max-request-size>-1</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>
</servlet>
I created an Enterprise application, with an EJB and a war module. I added some XHTML files in the Web Pages folders organized like this:
Web Pages
WEB-INF
web.xml
protected
testNavigation2.xhtml
testNavigation.xhtml
I also configured the Faces Servlet with the url-pattern *.xhtml.
Having deployed my application I can access without problems the URL: host/projectname/testNavigation.xhtml. The testNavigation.xhtml file is shown.
But I can't access: host/projectname/protected/testNavigation2.xhtml. Using that URL results in:
HTTP Status 404 - /protected/testNavigation2.xhtml Not Found in
ExternalContext as a Resource
The server console (I'm using Glassfish 4.1) reports:
Warning: Context path from ServletContext: /meteocal-project-war
differs from path from bundle: meteocal-project-war Warning:
JSF1064: unable to find or serve resource,
/protected/testNavigation2.xhtml.
How can I make xhtml files accessible from subfolders? I did actually a lot of research on this and judging from what I've read the behaviour I'm experimenting seems weird.
I don't think this is needed, but I'll post the content of web.xml in case I'm wrong:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>protected/testNavigation2.xhtml</welcome-file>
</welcome-file-list>
</web-app>
Thanks for your attention,
I'll greatly appreciate any help you can give
This answer has been posted by Tiny in a comment. I report that here to mark it as an answer.
You might have forgotten to deploy the application after you created the folder named protected having that XHTML file - testNavigation2.xhtml under the application root. Redeploy the application all over again from scratch.
NetBeans basically requires a hard deploy whenever you create folders in your application. If it were to happen even after you made a hard deploy, scan the file system on your operating system to see, if there is a folder named protected having the said XHTML file in the deployed WAR file. The symptom basically is only that the newly created folder protected itself along with the mentioned XHTML file is unavailable in the deployed WAR file.
by Tiny
I am trying to enable compression and packaging of my css and js files in Richfaces 4.3.3 using the inbuilt optimisation features, but nothing I try seems to have any effect and all script and CSS files are still being loaded as separate entities - I've enabled the optimisation feature in my web.xml as follows
<context-param>
<param-name>org.richfaces.resourceOptimization.enabled</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.resourceMapping.packedStages</param-name>
<param-value>Production</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.resourceOptimization.compressionStages</param-name>
<param-value>Production</param-value>
</context-param>
<servlet>
<servlet-name>Resource Servlet</servlet-name>
<servlet-class>org.richfaces.webapp.ResourceServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Resource Servlet</servlet-name>
<url-pattern>/org.richfaces.resources/*</url-pattern>
</servlet-mapping>
the links on my pages are being included like so
<h:outputStylesheet name="bootstrap.css" library="css" />
or
<h:outputScript library="js" name="bootstrap-dropdown.js" />
and these files are in the WEB-INF/resources folder. I may be mistaken, but I would then expect that richfaces would detect these files and add them into the packed.css and packed.js files, but these files are still being loaded separately. One final thing to note is that I have my PROJECT_STAGE set as follows in my faces-config.xml file
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Production</param-value>
</context-param>
Any pointers or tips anyone could give me would be greatly appreciated!
You misunderstand how it works.
org.richfaces.resourceOptimization.enabled=true
means "when you're looking for resources, load the optimized ones." It doesn't create the packed.js/packed.css, those were created when the richfaces*.jar was built.
If you want your own resources being processed take a look at the richfaces maven plugin.
I've written a quick GWT app with the following code:
MyTaskService
package com.google.gwt.mytasks.client;
import com.google.gwt.core.client.GWT;
import com.google.gwt.user.client.rpc.RemoteService;
import com.google.gwt.user.client.rpc.RemoteServiceRelativePath;
#RemoteServiceRelativePath("taskAction")
public interface MyTasksService extends RemoteService {
public void addTask(String title, String description);
}
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- Default page to serve -->
<welcome-file-list>
<welcome-file>MyTasks.html</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>MyTasksService</servlet-name>
<servlet-class>com.google.gwt.mytasks.server.MyTasksServiceImpl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyTasksService</servlet-name>
<url-pattern>/mytasks/taskAction</url-pattern>
</servlet-mapping>
</web-app>
Module.gwt.xml
<module rename-to='mytasks'>
<inherits name="com.google.gwt.user.User"/>
<inherits name="com.google.gwt.user.theme.standard.Standard"/>
<entry-point class="com.google.gwt.mytasks.client.MyTasks"/>
<!-- Specify the paths for translatable code -->
<source path='client'/>
<source path='shared'/>
</module>
Every time I click on the submit button I get the following error:
com.google.gwt.user.client.rpc.StatusCodeException: 404
Error 404 NOT_FOUND
HTTP ERROR: 404NOT_FOUND
RequestURI=/com.google.gwt.mytasks.MyTasks/taskActionPowered by
Jetty://
The problem seems to be that GWT isn't renaming the module before publishing, i you have a look at RemoteServiceRelativePath annotation documentation it defines the servlet path as GWT.getModuleBaseURL() + value(), being value() the value given to the annotation. One easy solution that might work would be to define the servlet mapping at the path the module is looking at.
Instead of:
<servlet-mapping>
<servlet-name>MyTasksService</servlet-name>
<url-pattern>/mytasks/taskAction</url-pattern>
</servlet-mapping>
Use:
<servlet-mapping>
<servlet-name>MyTasksService</servlet-name>
<url-pattern>/com.google.gwt.mytasks.MyTasks/taskAction</url-pattern>
</servlet-mapping>
I'm having trouble using RichFaces 3.3.2 and Facelets 1.1.14 under Weblogic 10.3.4 and 10.3.5 (aka 11g). I have an xhtml file with the expression #{empty messages}, and on the console I get the following exception:
SEVERE: Error Rendering View[/index.xhtml]
javax.el.ELException: //media/DADOS/data/java/wl1034/user_projects/domains/wlrep1034/autodeploy/SimpleJSFa/index.xhtml:
ELResolver cannot handle a null base Object with identifier 'messages'
at com.sun.facelets.compiler.TextInstruction.write(TextInstruction.java:48)
at com.sun.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:39)
at com.sun.facelets.compiler.UILeaf.encodeAll(UILeaf.java:149)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:889)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:108)
The messages variable really does not exist at this point, but that's why I used an empty statement. It works fine on Tomcat 5.5 and Websphere 6.1.
The complete xhtml file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:rich="http://richfaces.org/rich">
<body>
<h1>Bean Message: #{TestBean.greeting}</h1>
Are there messages pending? #{messages == null || empty messages} .
</body>
</html>
TestBean.java:
package eg.bean;
import java.util.ArrayList;
import java.util.List;
import javax.faces.context.FacesContext;
import javax.servlet.http.HttpServletRequest;
public class TestBean {
private String greeting = "Hello, World!";
public TestBean() {
// Uncommenting the following line puts an object in the session, under the
// key "messages", and then the page displays properly.
// addSomeMessages();
}
public String getGreeting() {
return greeting;
}
public void setGreeting( String message ) {
this.greeting = message;
}
public void addSomeMessages() {
// This method is not being called for this example, but this is where
// I would add a list of messages to be displayed to the user, and place it
// on session scope (not advisable, I know, but bear with me)
HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
List<String> messages = new ArrayList<String>();
messages.add( "A message.");
request.getSession().setAttribute( "messages", messages );
}
}
I can only guess that somehow a different implementation of ELResolver is being used by Weblogic, which could be caused by classloader conflicts, but I've been fiddling with it for a while and am getting nowhere.
I have the following jars in WEB-INF/lib:
commons-beanutils-1.7.0.jar
commons-digester-1.8.jar
commons-logging-1.1.1.jar
jsf-api.jar
jsf-facelets.jar
jsf-impl.jar
richfaces-api-3.3.2.SR1.jar
richfaces-impl-3.3.2.SR1.jar
richfaces-ui-3.3.2.SR1.jar
SimpleJSF.jar
My faces-config.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
<managed-bean>
<managed-bean-name>TestBean</managed-bean-name>
<managed-bean-class>eg.bean.TestBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
<application>
<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>
<resource-bundle>
<base-name>RepositoryBundle</base-name>
<var>bundle</var>
</resource-bundle>
</application>
</faces-config>
web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">
<!-- Use Documents Saved as *.xhtml -->
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.xhtml</param-value>
</context-param>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.disableVersionTracking</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>facelets.LIBRARIES</param-name>
<param-value>/WEB-INF/sense.taglib.xml</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
<param-value>com.sensedia.repository.web.startup.SensediaFaceletViewHandler</param-value>
</context-param>
<context-param>
<param-name>com.prime.facestrace.DISABLE_TRACE</param-name>
<param-value>false</param-value>
</context-param>
<!-- ********************** SERVLETS ********************** -->
<!-- Faces Servlet -->
<servlet>
<servlet-name>FacesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- ********************** FILTERS ********************** -->
<filter>
<filter-name>richfaces</filter-name>
<filter-class>org.ajax4jsf.Filter</filter-class>
</filter>
<filter-mapping>
<filter-name>richfaces</filter-name>
<servlet-name>FacesServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>
<!-- Faces Servlet Mapping -->
<servlet-mapping>
<servlet-name>FacesServlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
<welcome-file-list>
<welcome-file>index.jsf</welcome-file>
</welcome-file-list>
</web-app>
EDIT: I was deploying as a standalone war file, but I also tried packaging as an EAR module. Problem persists. When deploying as an EAR file I added a weblogic.xml jar besides my own web.xml with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
</weblogic-web-app>
I also added an application.xml to the ear's META-INF directory, simply referencing the war module. I also added a weblogic-application.xml file besides that one, to further specify classloader isolation:
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>org.mozilla.*</package-name>
<package-name>javax.jws.*</package-name>
<package-name>com.sun.*</package-name>
<package-name>javax.xml.rpc.*</package-name>
<package-name>javax.xml.soap.*</package-name>
</prefer-application-packages>
</weblogic-application>
Actually, the EL implementation is supposed to be provided by the container itself. A classpath conflict would only lead to class/method definition errors like LinkageError, NoClassDefFoundError, AbstractMethodError, etc. This is not the case here, but this indeed look much like a bug in Weblogic's EL implementation. Since I don't use WebLogic, I can't test/confirm this.
You could try to use the following expression instead
#{messages == null || empty messages}
Or you could try to totally replace the EL implementation, for example the JBoss one (which allows passing method arguments). Just drop jboss-el.jar in /WEB-INF/lib and add the following to the web.xml
<context-param>
<param-name>com.sun.faces.expressionFactory</param-name>
<param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
</context-param>
It turns out to be a classloader issue after all. I had packaged the JSF 1.2 jars into my application's WEB-INF/lib folder:
jsf-api.jar
jsf-impl.jar
Weblogic 10.3.x has its own implementation, located in MW_HOME/wlserver/common/deployable-libraries/jsf-1.2.war (and the 2.0 version in jsf-2.0.war). I replaced the above jars in my own webapp with the following jars from jsf-1.2.war!/WEB-INF/lib:
glassfish.jsf_1.0.0.0_1-2-15.jar
glassfish.jstl_1.2.0.1.jar
javax.jsf_1.1.0.0_1-2.jar
wls.jsf.di.jar
I also had to remove all the packages in the prefer-application-packages element in weblogic.xml:
<!--
<prefer-application-packages>
<package-name>org.mozilla.*</package-name>
<package-name>javax.jws.*</package-name>
<package-name>com.sun.*</package-name>
<package-name>javax.xml.rpc.*</package-name>
<package-name>javax.xml.soap.*</package-name>
</prefer-application-packages>
-->
After this, the page displayed correctly. (It did cause other problems, such as a ViewExpiredException on every page, but that's another problem, I think...)