in fact you probably don't even need to do that if you use GlassFish v3 which removes the need for registering and mapping the Faces servlet in web.xml (which itself remains optional).
So your Facelet page with a .xhtml extension invoked via a /faces/* request and a @javax.faces.bean.ManagedBean -annotated POJO should be all you need.
-Alexis
On 6 févr. 2010, at 16:53, Dominik Dorn wrote:
> You accessed it through
>
> /contextPath/faces/test.xhtml
>
> not just
> /contextPath/test.xhtml
>
> right?
>
>
> On Sat, Feb 6, 2010 at 12:48 AM, Mark Space <markspace_at_sbcglobal.net> wrote:
>>>> Here's my JSF page. There's a lot less config than previous versions of
>>>> JSF/JSP, but I thought that was the point with 2.0.
>>>
>>> and this file has an .xhtml extension?
>>> Ludo
>>
>>
>> Yes. It's automatically generated by NetBeans, so no worries there. The
>> full name is "test.xhtml"
>>
>> Just for more information, here's the config files. There is no
>> faces-config.xml, which has me a bit concerned. I have a web.xml and
>> sun-web.xml. They're both pretty short:
>>
>> web.xml:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
>> 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-app_3_0.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>/faces/*</url-pattern>
>> </servlet-mapping>
>> <welcome-file-list>
>> <welcome-file>index.xhtml</welcome-file>
>> </welcome-file-list>
>> </web-app>
>>
>> sun-web.xml:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application
>> Server 9.0 Servlet 2.5//EN"
>> "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
>> <sun-web-app error-url="">
>> <context-root>/jsfDemo</context-root>
>> <class-loader delegate="true"/>
>> <jsp-config>
>> <property name="keepgenerated" value="true">
>> <description>Keep a copy of the generated servlet class' java
>> code.</description>
>> </property>
>> </jsp-config>
>> </sun-web-app>
>>
>>
>> It's got me stumped.
>>
>>
>>
>>
>> Mark Space wrote:
>>>
>>> Hi all,
>>>
>>> I have what is likely a configuration issue but I can't work out where the
>>> problem is. I made a simple JSF 2 page to test out my Glassfish
>>> installation.
>>>
>>> What I'm seeing is is that custom actions don't seem to be interpreted at
>>> all. They just end up in the output on the client (browser) unchanged. In
>>> addition, EL expressions that reference managed beans end up the same way:
>>> #{bean.property} just gets passed straight through to the client un-altered.
>>>
>>> Here's my JSF page. There's a lot less config than previous versions of
>>> JSF/JSP, but I thought that was the point with 2.0.
>>>
>>> <?xml version='1.0' encoding='UTF-8' ?>
>>> <!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:h="http://java.sun.com/jsf/html">
>>> <h:head>
>>> <title>Facelet Title</title>
>>> </h:head>
>>> <h:body>
>>> Hello from Facelets
>>> <br /><br />
>>> #{TestBean.hashCode}
>>> <br /><br />
>>> <h:form>
>>> <h:inputText size="2" maxlength="2"/>
>>> <h:commandButton id="submit" value="submit" action="response" />
>>> </h:form>
>>> </h:body>
>>> </html>
>>>
>>> Both the #{TestBean.hashCode} and the entire <h:form> element get passed
>>> to the browser unchanged. I assume there's some obvious configuration
>>> missing but I can't guess what. Most of this project is auto-generated in
>>> NetBeans and I assume correct. It looks right when I browse through the
>>> files in the War file. But obviously something is amiss.
>>>
>>> Any ideas? Help is much appreciated.
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>