Giter VIP home page Giter VIP logo

mojarra's Introduction

Mojarra 5.0

Eclipse's implementation of the Jakarta Faces 5.0 specification

For support on Mojarra 2.3 and earlier please contact your vendor for support (RedHat, IBM, Oracle, Omnifish, Payara, etceteras)

Minimum Requirements

  • Java 17
  • Jakarta Servlet 6.1
  • Jakarta Expression Language 6.0
  • Jakarta CDI 4.1
  • Jakarta Web Socket 2.2 (optional, only when <f:websocket> is used)
  • Jakarta JSON Processing 2.1 (optional, only when <f:websocket> is used)
  • Jakarta Validation 3.1 (optional, only when <f:validateBean> or <f:validateWholeBean> is used)

Installation

Depending on the server used, Jakarta Faces may already be built-in (full fledged Jakarta EE containers such as WildFly, JBoss EAP, TomEE, Payara, GlassFish, Liberty, etc.), or not (barebones Jakarta Server Pages/Jakarta Servlet containers such as Tomcat, Jetty, etc.). If the server doesn't ship with Jakarta Faces built-in, then you need to manually install Jakarta Faces 4.0 along with CDI 4.0+, Jakarta JSON Processing 2.0+ and Jakarta Standard Tag Library 2.0+ as those Jakarta Servlet containers usually also don't even ship with those Jakarta Faces dependencies.

Non-Maven

In case you're manually carrying around JARs:

Maven

In case you're using Maven, you can find below the necessary coordinates:

  • Java EE containers (WildFly, JBoss EAP, TomEE, Payara, GlassFish, Liberty, etc)

    <dependency>
       <groupId>jakarta.platform</groupId>
       <artifactId>jakarta.jakartaee-api</artifactId>
       <version>11.0.0</version>
       <scope>provided</scope>
    </dependency>

In case of WildFly/JBoss EAP, you need to manually package jsf-api.jar and jsf-impl.jar based on jakarta.faces.jar first. In case of TomEE, just swap the myfaces*.jar files with jakarta.faces.jar in the server's /lib folder. In case of Payara/GlassFish, just swap the jakarta.faces.jar file in the server's /glassfish/modules folder.

  • Servletcontainers (Tomcat, Jetty, etc)

    <dependency>
        <groupId>org.glassfish</groupId>
        <artifactId>jakarta.faces</artifactId>
        <version><!-- Use latest 4.0.x version. --></version>
    </dependency>
    <dependency>
        <groupId>org.jboss.weld.servlet</groupId>
        <artifactId>weld-servlet-shaded</artifactId>
        <version>4.1.0.Final</version>
    </dependency>
    <dependency> <!-- Optional, only when <f:websocket> is used. -->
        <groupId>org.glassfish</groupId>
        <artifactId>jakarta.json</artifactId>
        <version>2.1.0</version>
    </dependency>
    <dependency> <!-- Optional, only when <f:validateBean> or <f:validateWholeBean> is used. -->
        <groupId>org.hibernate.validator</groupId>
        <artifactId>hibernate-validator</artifactId>
        <version><!-- Use latest 8.0.x version. --></version>
    </dependency>

    You can check org.glassfish:jakarta.faces repository to find the latest Mojarra 4.0.x version.

Testing

Since Mojarra 4, tests have been moved to the Faces project.

Hello World Example

We assume that you already know how to create an empty Maven WAR Project or Dynamic Web Project in your favourite IDE with a CDI 4.0+ compatible /WEB-INF/beans.xml deployment descriptor file (which can be kept fully empty). Don't forget to add JARs or configure pom.xml if necessary, as instructed in previous chapter.

Controller

Optionally, register the FacesServlet in a Servlet 6.0+ compatible deployment descriptor file /WEB-INF/web.xml as below:

<?xml version="1.0" encoding="UTF-8"?>
<web-app
    xmlns="https://jakarta.ee/xml/ns/jakartaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd"
    version="6.0"
>
    <servlet>
        <servlet-name>facesServlet</servlet-name>
        <servlet-class>jakarta.faces.webapp.FacesServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>facesServlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>
</web-app>

Noted should be that Jakarta Faces is already "implicitly" registered and mapped on *.xhtml, *.jsf, *.faces and /faces/* when running on a Jakarta Servlet container. This will be overridden altogether when explicitly registering as above. The *.xhtml URL pattern is preferred over above for security and clarity reasons. When you don't explicitly map it on *.xhtml, then people can still access Faces pages using *.jsf, *.faces or /faces/* URL patterns. This is not nice for SEO as Faces by design doesn't 301-redirect them to a single mapping.

The Faces deployment descriptor file /WEB-INF/faces-config.xml is fully optional.

<?xml version="1.0" encoding="UTF-8"?>
<faces-config
    xmlns="https://jakarta.ee/xml/ns/jakartaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-facesconfig_4_0.xsd"
    version="4.0"
>
    <!-- Put any faces config here. -->
</faces-config>

Model

Then create a backing bean class as below:

package com.example;

import jakarta.enterprise.context.RequestScoped;
import jakarta.inject.Named;

@Named
@RequestScoped
public class Hello {

    private String name;
    private String message;

    public void createMessage() {
        message = "Hello, " + name + "!";
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getMessage() {
        return message;
    }

}

Noted should be that in reality in the average Jakarta EE application the above "model" is further breakdown into a Jakarta Persistence entity, a Jakarta Enterprise Beans service and a smaller backing bean. The Jakarta Persistence entity and Jakarta Enterprise Beans service then basically act as a true "model" and the backing bean becomes a "controller" for that model. This may in first place be confusing to starters, but it all depends on the point of view. See also What components are MVC in Faces MVC framework? and Faces Controller, Service and DAO.

View

Finally create a Facelets file /hello.xhtml as below:

<!DOCTYPE html>
<html lang="en"
    xmlns:f="jakarta.faces.core"
    xmlns:h="jakarta.faces.html">
    <h:head>
        <title>Hello, World!</title>
    </h:head>
    <h:body>
        <h:form>
            <h:outputLabel for="name" value="Enter your name" required="true" />
            <h:inputText id="name" value="#{hello.name}" />
            <h:message for="name" />
            <br />
            <h:commandButton value="Say hello" action="#{hello.createMessage}">
                <f:ajax execute="@form" render="@form" />
            </h:commandButton>
            <br />
            #{hello.message}
        </h:form>
    </h:body>
</html>

Start the server and open it by http://localhost:8080/contextname/hello.xhtml.

Activating CDI in Jakarta Faces 4.1

CDI is activated by default in Jakarta Faces 4.1 and can´t be deactivated.
It´s not required anymore to add @FacesConfig to a CDI managed bean to accomplish this. As of Jakarta Faces 4.0 @FacesConfig still removes the need to explicitly add a FacesServlet entry to web.xml.

Building

In case you want to checkout this repository and manually build from source yourself (if necessary after editing source code), here are the instructions:

Jakarta Faces.Next

  1. Make sure that you have JDK 17, Ant and Maven installed.

  2. Checkout branch master.

  3. Run the following commands from the root directory of the project:

    # under the root dir of project
    mvn clean install
  4. The binary is now available as impl/target/jakarta.faces-4.x.x-SNAPSHOT.jar.

Jakarta Faces 4.0

  1. Make sure that you have JDK 11, Ant and Maven installed.

  2. Checkout branch 4.0.

  3. Run the following commands from the root directory of the project:

    # under the root dir of project
    mvn clean install
  4. The binary is now available as impl/target/jakarta.faces-4.0.x-SNAPSHOT.jar.

Jakarta Faces 3.0

  1. Make sure that you have JDK 1.8, Ant and Maven installed.

  2. Checkout branch 3.0.

  3. Run the following commands from the root directory of the project:

    # under the root dir of project
    mvn clean install
  4. The binary is now available as impl/target/jakarta.faces-3.0.x-SNAPSHOT.jar.

Jakarta Faces 2.3

  1. Make sure that you have JDK 1.8, Ant and Maven installed.

  2. Checkout branch 2.3.

  3. Run the following commands from the root directory of the project:

    # under the root dir of project
    mvn clean install
  4. The binary is now available as impl/target/jakarta.faces-2.3.x-SNAPSHOT.jar.

Jakarta Faces 2.2

Jakarta Faces 2.2 and lower are not supported by Eclipse. If such support is needed, consult your Jakara EE vendor of choice.

Editing source code with IDE

In case you want to checkout to edit the source code of Mojarra with full IDE support, here are the instructions. Note that this only allows you to edit the code. Actually building the Mojarra artefacts still has to be done using the instructions provided above.

Eclipse

Jakarta Faces 4.0

  1. Checkout branch 4.0 using File -> import -> Git
  2. Right click the Mojarra project after checkout, choose Configure -> Convert to Maven Project

Jakarta Faces 3.0

  1. Checkout branch 3.0 using File -> import -> Git
  2. Right click the Mojarra project after checkout, choose Configure -> Convert to Maven Project

Jakarta Faces 2.3

  1. Checkout branch 2.3 using File -> import -> Git
  2. Right click the Mojarra project after checkout, choose Configure -> Convert to Maven Project

Pull Requests

Pull requests are accepted on following branches:

Note that it's okay to send a PR to the master branch, but this one is for Faces.next and not the current 2.3.x or 3.0.x version.

Releasing

pom.xml versions can be adjusted as follows

mvn versions:set -DgroupId=* -DartifactId=* -DoldVersion=* -DgenerateBackupPoms=false -DnewVersion=4.0.1-SNAPSHOT

Resources

mojarra's People

Contributors

arjantijms avatar balusc avatar christophs78 avatar codylerum avatar cristof avatar dependabot[bot] avatar emkas avatar gerdogdu avatar ggam avatar gndrm avatar hussainnm avatar jgauravgupta avatar kmix avatar larsgrefer avatar manfredriem avatar melloware avatar mnriem avatar mojarra-bot avatar nicolaisotta avatar pferraro avatar pizzi80 avatar pzygielo avatar ren-zhijun-oracle avatar rmartinc avatar ruolli avatar schulzp avatar soul2zimate avatar spyrkob avatar tmiyargi avatar tomashofman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mojarra's Issues

image attribute on the comandButton should be treated like graphicImage

image attribute of commandButton has to either take and absolute or relative
path to the image and not a context-relative path like graphicImage's url
attribute does?

Its not a big deal because you can get the same behavior by nesting a
graphicImage inside a commandLink, but it would be nice if the attributes were
consistent, preferably using either a relative link or if a "/" is the first
character, it leads with the context-root, not the absolute root.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

iframe

I have some problem when I use JSF with iframe. My code is as the following.

iframeFirst.jsp

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

<f:view>

<title>A Simple JavaServer Faces Application</title>

<f:verbatim>

<IFRAME SRC="welcome.faces" TITLE="menu" WIDTH=500 HEIGHT=500> </IFRAME>

Please enter your name and password.

Name:

</h:form>

welcome.faces

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

<f:view>

<title>A Simple JavaServer Faces Application</title>

Welcome to JavaServer Faces, user com.corejsf.UserBean session

web.xml

javax.faces.STATE_SAVING_METHOD client Faces Servlet javax.faces.webapp.FacesServlet 1 Faces Servlet *.faces index.html

The error is:
java.lang.ClassCastException
javax.faces.component.html.HtmlInputSecret.restoreState
(HtmlInputSecret.java:902)
javax.faces.component.UIComponentBase.processRestoreState
(UIComponentBase.java:999)
javax.faces.component.UIComponentBase.processRestoreState
(UIComponentBase.java:1011)
javax.faces.component.UIComponentBase.processRestoreState
(UIComponentBase.java:1011)
com.sun.faces.application.StateManagerImpl.restoreComponentState
(StateManagerImpl.java:273)
com.sun.faces.application.StateManagerImpl.restoreView
(StateManagerImpl.java:184)
com.sun.faces.application.ViewHandlerImpl.restoreView
(ViewHandlerImpl.java:246)
com.sun.faces.lifecycle.RestoreViewPhase.execute
(RestoreViewPhase.java:157)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)

If the iframe shows after the other content of the page, it works. But in my
case, I have to show the iframe first. And if I change the STATE_SAVING_METHOD
to server, the submit button does not work well. I have to click the button
several times before it works, sometimes up to 9.
Is there any way I could get around this? The dead line of my project is next
Wednesday. If I could not find a solution in JSF, I have to rewrite some of my
code in jsp.
I appreciate any respond so that I could make a final decision.

Have a nice weekend.

Environment

Operating System: All
Platform: All

Affected Versions

[1.0]

Taglib generator enhancements

Make the Taglib generator generic so that it can accept an XML file containing
metadata about the component and generate the tag handler for it. Currently, the
tag handler needs some more information than just the metadata which is
hardcoded in the generator itself. Ultimately, it would be nice to make it
standalone application with its own installer.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

OC4J tag reuse conflict with UIComponentTag

From another developer on the 'net:

http://forum.java.sun.com/thread.jsp?forum=427&thread=546174&tstart=0&trange=15

Based on the stack trace, I think I know what's going on. (No testcase, but I'm fairly confident of this
analysis.) This looks like another conflict between tag reuse code in the OC4J container and the JSF
tags.

Here's how it happens:
1. User runs a page.
2. ViewTag.doStartTag() executes, as do a few children of the view tag. UIComponentTag's
createComponents instance variable is therefore non-empty.
3. An exception kills off execution of that page.
4. ViewTag.doEndTag() never gets called (nor should it), but OC4J caches the ViewTag instance!
5. Same user - or another user - brings up a JSF page.
6. OC4J reuses that ViewTag instance, and calls doStartTag(). createComponents is still non-empty
(because doEndTag() was never called).
7. When the first tag inside ViewTag runs, UIComponentTag.createChild() is called, and executes:
parent.getChildren().add(parentTag.getIndex(), component);
... where "parent" is the UIViewRoot. getIndex() returns a non-zero number, but ViewTag doesn't
actually have any children. Boom!

My understanding is that the OC4J behavior is legit under the Servlet 2.3 spec (which is what's
implemented in the version of OC4J this user is using), but not legit under the Servlet 2.4 spec. But this
could relatively easily be fixed in JSF by explicitly setting createdComponents and createdFacets to null
in UIComponentTag.doStartTag().

Environment

Operating System: All
Platform: All
URL: http://forum.java.sun.com/thread.jsp?forum=427&thread=546174&tstart=0&trange=15

Affected Versions

[1.1]

taglib generator doesn't correctly cause certain tags to extend properly

The taglib generator doesn't do the right thing with respect to making those
tags which map to components who say rendersChildren == true extend
UIComponentBodyTag. For example, PanelGridTag should extend UIComponentBodyTag,
but it currently does not do so.

Environment

Operating System: All
Platform: All

Affected Versions

[1.0]

ye-olde content interweaving issue

The age-old content interweaving problem. Consider this JSP fragment:

<h:panelGrid columns="1">
first text
<h:outputText value="second text"/>
third text
<h:outputText value="fourth text"/>
fifth text
</h:panelGrid>

You'd expect

first text
second text
third text
fourth text
fifth text

What you get instead is

second text
fourth text
first text
third text
fifth text

This is well documented in Hans's article at
<http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html>.

Environment

Operating System: All
Platform: All

Affected Versions

[1.0]

Merge RI configuration files into one and remove tool metadata

The JSF RI current parses two configuration files (among the others mandated by
the specification): jsf-ri-config.xml and standard-html-renderkit.xml (makes
heavy use of entity references).

Propose that the two config files are merged into one file used by the RI at
runtime that doesn't contain all of the tool metadata.

Environment

Operating System: All
Platform: All

Affected Versions

[current]

EL Parser Enhancement

Open ticket for EL Parser Enhancement.

Enhancements will include a new PropertyResolver, VariableResolver and a
complete refactoring of com.sun.faces.el.* and com.sun.faces.el.impl.*

These changes will also affect com.sun.faces.application.ApplicationImpl and
com.sun.faces.util.Util.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

OutputFormat/Message Tag Lib Issues

From a feedback message:

Hi, I have found following issues for h:outputFormat and h:message,
h:messages.

  1. id is not output in HTML SPAN tag.
    h:outputFormat outputs HTML SPAN tag. But it does not output id
    attribute in SPAN tag at all. (OutputMessageRenderer.java)

  2. h:outputFormat tag accepts converter attribute. But it seems not
    be used. I suggest to drop it.

  3. h:message and h:messages tag take title attribute. But it seems
    not be used. I suggest to drop it.

Thanks,

– HANAI Shisei [email protected]

=====================================================================
Did some initial research on this one...
Can't think of a reason why you would need a converter property
on OutputFormat.... In any case, standard-html-renderit.xml
includes valueholder-props in uioutput-props (because UIOutput is
a ValueHolder)... hence the "converter" tag attr is generated...
However, OutputMessageRenderer may not deal with converters....

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Message list (HtmlMessages) does not correctly handle style attribute

Let's say I have a HtmlMessages component on my page, and it's absolutely
positioned via css:

<h:messages binding="#

{Page1.messageList1}

" errorClass="errorMessage"
fatalClass="fatalMessage" id="messageList1" infoClass="infoMessage"
style="left: 48px; top: 432px; position: absolute"
warnClass="warnMessage"/>

Let's say my page generates MULTIPLE FacesMessages, for example if I have
multiple text fields each marked "required", and I enter no input and submit the
form.

In that case, the MessageList component writes out a separate for each
faces message, replicating the style on each such . This means that the
position CSS property gets set on all the spans, and they end up clobbering each
other!!

Validation Error: "nameField": Value is required.

Validation Error: "phoneField": Value is required.

The browser will gladly paint these two messages right on top of each other.

I think it would be more correct for the inline error message to actually put
each error message on a separate line - e.g. generate a single

, and spit
out a for each sub message if you want with a
in between each.

Or, if you're committed to the current flow operation, fix this bug by emitting
a single with the HtmlMessages' style tag replicated on it, and then emit
a nested span tag for each FacesMessage - but WITHOUT the HtmlMessages styles on
them.

Environment

Operating System: All
Platform:

Affected Versions

[1.1]

portlet-guessNumber fails to display in portal

I tried the latest sources from following source bundle
javaserverfaces_source_20040715.class

built everything including portlet-lib and portlet-guessNumber.
When I go to view the portlet it fails with ClassCastException here is the stack
trace below. I am using Sun One Portal server 6.2

2004/07/23 10:13:31.677 EDT | JavaServer Faces | SEVERE | service-j2ee |
PortletAppEngineServlet.HandleError()() - Error: null | null
x -----------------------------------------------------------------------------
X java.lang.ClassCastException
X at
com.sun.faces.application.ApplicationAssociate.getInstance(ApplicationAssociate.java:118)
X at
com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:104)
X at com.sun.faces.portlet.ViewHandlerImpl.renderView(ViewHandlerImpl.java:122)
X at
com.sun.faces.portlet.LifecycleImpl$RenderResponsePhase.execute(LifecycleImpl.java:543)
X at com.sun.faces.portlet.LifecycleImpl.phase(LifecycleImpl.java:249)
X at com.sun.faces.portlet.LifecycleImpl.render(LifecycleImpl.java:191)
X at com.sun.faces.portlet.FacesPortlet.render(FacesPortlet.java:270)
X at
com.sun.portal.portletappengine.PortletAppEngineServlet.service(PortletAppEngineServlet.java:261)
X at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)
X at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:770)
X at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:626)
X at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:537)
X at
com.sun.portal.container.portlet.impl.PortletContainer.invokePAE(PortletContainer.java:348)
X at
com.sun.portal.container.portlet.impl.PortletContainer.getMarkup(PortletContainer.java:171)
X at
com.sun.portal.providers.portletwindow.PortletWindowProvider.getContent(PortletWindowProvider.java:282)
X at
com.sun.portal.desktop.context.PSContainerProviderContext.getContent(PSContainerProviderContext.java:430)
X at
com.sun.portal.desktop.taglib.containerProviderContext.GetContentTag.doStartTag(GetContentTag.java:33)
X at
_jsps._etc._opt._SUNWps._desktop._sampleportal_en_US._JSPTabContainer._html._tab_jsp._jspService(_tab_jsp.java:1024)
X at
com.sun.portal.providers.jsp.jasper3.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
X at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)
X at
com.sun.portal.providers.jsp.JspServletWrapper.service(JspServletWrapper.java:182)
X at com.sun.portal.providers.jsp.JSPProvider.processJspFile(JSPProvider.java:863)
X at com.sun.portal.providers.jsp.JSPProvider.processJspFile(JSPProvider.java:777)
X at com.sun.portal.providers.jsp.JSPProvider.getContent(JSPProvider.java:546)
X at
com.sun.portal.providers.containers.jsp.tab.JSPTabContainerProvider.getContent(JSPTabContainerProvider.java:539)
X at
com.sun.portal.desktop.context.PSContainerProviderContext.getContent(PSContainerProviderContext.java:430)
X at
com.sun.portal.desktop.context.PSDesktopContext.getContent(PSDesktopContext.java:1132)
X at com.sun.portal.desktop.DesktopServlet.doGetPost(DesktopServlet.java:603)
X at com.sun.portal.desktop.DesktopServlet.service(DesktopServlet.java:320)
X at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)
X at
org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:771)
X at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:322)
X at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
X at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
X at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
X at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:209)
X at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
X at
com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:161)
X at com.iplanet.ias.web.WebContainer.service(WebContainer.java:586)
X -----------------------------------------------------------------------------

Environment

Operating System: All
Platform:

Affected Versions

[1.1]

[PORTLET] initial view definition on portlet level

Now, the initial view is set only by com.sun.faces.portlet.INIT_VIEW web-app
context param. It's inconvenient, because in web-app there are always many
portlets, each one having it's own initial view.
I thing that initial view should be specified in portlet descriptor, eg. as
portlet initial parameter.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

h:dataTable headerClass --> headerClasses

Could you change the JSF specification so that h:dataTable header attribute
would be changed to headerClasses. In other words it would be possible to
assign different Classes to header columns. Basically it should work as
columnClasses attribute.

For more details... see the thread:
http://forum.java.sun.com/thread.jsp?forum=427&thread=514955

Environment

Operating System: All
Platform: All
URL: http://forum.java.sun.com/thread.jsp?forum=427&thread=514955

Affected Versions

[1.1]

graphicImage tag broken when using jdk 5.0

If you try to use the graphicImage tag while running jdk 5.0, you receive a
java.lang.UnsupportedOperationException when something in the implementation
attempts to insert null as a key in a Map. Stack trace included below.

java.util.AbstractMap.put(AbstractMap.java:227)
com.sun.faces.el.PropertyResolverImpl.setValue(PropertyResolverImpl.java:158)
com.sun.jsfcl.data.ResultSetPropertyResolver.setValue(Unknown Source)
com.sun.faces.el.impl.ArraySuffix.setValue(ArraySuffix.java:192)
com.sun.faces.el.impl.ComplexValue.setValue(ComplexValue.java:171)
com.sun.faces.el.ValueBindingImpl.setValue(ValueBindingImpl.java:234)
com.sun.faces.application.ApplicationImpl.createComponent
(ApplicationImpl.java:396)
javax.faces.webapp.UIComponentTag.createComponent(UIComponentTag.java:1018)
javax.faces.webapp.UIComponentTag.createChild(UIComponentTag.java:1045)
javax.faces.webapp.UIComponentTag.findComponent(UIComponentTag.java:742)
javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:423)
com.sun.faces.taglib.html_basic.GraphicImageTag.doStartTag
(GraphicImageTag.java:372)
org.apache.jsp.welcome_jsp._jspx_meth_h_graphicImage_0(welcome_jsp.java:185)
org.apache.jsp.welcome_jsp._jspx_meth_h_form_0(welcome_jsp.java:146)
org.apache.jsp.welcome_jsp._jspx_meth_f_view_0(welcome_jsp.java:113)
org.apache.jsp.welcome_jsp._jspService(welcome_jsp.java:74)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:102)
javax.servlet.http.HttpServlet.service(HttpServlet.java:861)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:282)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:263)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:210)
javax.servlet.http.HttpServlet.service(HttpServlet.java:861)
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:324)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:246)
java.security.AccessController.doPrivileged(AccessController.java:-2)
javax.security.auth.Subject.doAsPrivileged(Subject.java:500)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:268)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:236)
org.apache.catalina.core.ApplicationFilterChain.access$000
(ApplicationFilterChain.java:55)
org.apache.catalina.core.ApplicationFilterChain$1.run
(ApplicationFilterChain.java:145)
java.security.AccessController.doPrivileged(AccessController.java:-2)
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:141)
org.apache.catalina.core.ApplicationDispatcher.invoke
(ApplicationDispatcher.java:718)
org.apache.catalina.core.ApplicationDispatcher.processRequest
(ApplicationDispatcher.java:478)
org.apache.catalina.core.ApplicationDispatcher.doForward
(ApplicationDispatcher.java:413)
org.apache.catalina.core.ApplicationDispatcher.access$000
(ApplicationDispatcher.java:77)
org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run
(ApplicationDispatcher.java:92)
java.security.AccessController.doPrivileged(AccessController.java:-2)
org.apache.catalina.core.ApplicationDispatcher.forward
(ApplicationDispatcher.java:319)
com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322)
com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:147)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:324)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:246)
java.security.AccessController.doPrivileged(AccessController.java:-2)
javax.security.auth.Subject.doAsPrivileged(Subject.java:500)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:268)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:236)
org.apache.catalina.core.ApplicationFilterChain.access$000
(ApplicationFilterChain.java:55)
org.apache.catalina.core.ApplicationFilterChain$1.run
(ApplicationFilterChain.java:145)
java.security.AccessController.doPrivileged(AccessController.java:-2)
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:141)
org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:220)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:109)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
org.apache.catalina.core.StandardContextValve.invokeInternal
(StandardContextValve.java:214)
org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:168)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:109)
org.apache.catalina.authenticator.AuthenticatorBase.invoke
(AuthenticatorBase.java:472)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:107)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:144)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:109)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:133)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:107)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:539)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:107)
com.sun.enterprise.webservice.EjbWebServiceValve.invoke
(EjbWebServiceValve.java:134)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:107)
com.sun.enterprise.security.web.SingleSignOn.invoke(SingleSignOn.java:254)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:107)
com.sun.enterprise.web.VirtualServerValve.invoke(VirtualServerValve.java:209)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:107)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:114)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:109)
com.sun.enterprise.web.VirtualServerMappingValve.invoke
(VirtualServerMappingValve.java:166)
org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:107)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:936)
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:165)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:683)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:604)
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:542)
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:647)
java.lang.Thread.run(Thread.java:534)

Environment

Operating System: All
Platform: All

Affected Versions

[current]

[PORTLET] initial view definition on portlet level

Now, the initial view is set only by com.sun.faces.portlet.INIT_VIEW web-app
context param. It's inconvenient, because in web-app there are always many
portlets, each one having it's own initial view.
I thing that initial view should be specified in portlet descriptor, eg. as
portlet initial parameter.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

UIData and large data. Change int to long

UIData use int data type. There is very long lists of items. F.g. very big
database table with billions or records. Of course, for such kind of data I
should use special datamodel which can get just shown items from DB. But all
methods of UIData return int values. Even getRowCount() can't return value
larger than int.

Environment

Operating System: All
Platform: All

Affected Versions

[current]

taglib generator doesn't correctly cause certain tags to extend properly

The taglib generator doesn't do the right thing with respect to making those
tags which map to components who say rendersChildren == true extend
UIComponentBodyTag. For example, PanelGridTag should extend UIComponentBodyTag,
but it currently does not do so.

Environment

Operating System: All
Platform: All

Affected Versions

[1.0]

href="javascript:" is better then onclick in commandLink renderer

I think using href="javascript:document.forms......." is better solution then
using onclick DHTML event in rendered HTML code for commandLink component?

This is because:
1. browser do not handle unnecessary href="#" (which sometimes is very
unnecessary because scrolls page to the top of page before sending the request
to server)
2. in forum (f.g. http://forum.java.sun.com/thread.jsp?forum=427&thread=506830)
I read then onclick event for commandLink doesn't work because in html onclick
already used.

<h:commandLink id="link" action="goto">
<h:outputText value="#

{msg.linkName}

"/>
</h:commandLink>

Rendered as:

Next Page

My suggestion:

Next Page

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

"border" attribute - SelectOneRadio

From a customer:

Hi,

h:selectOneRadio renders HTML

and tag. This tag has
border attribute and it renders in both of
and tag.
But tag can't have border tag. It seems a bug.

– HANAI Shisei [email protected]

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Hidden Field - FormRenderer - Renderer Dependencies

Our implementation to set up hidden fields in the form introduces
tightly coupled renderer dependencies. For the original cause of
this implementation see bugster report 5055795.

For example.. We expose public static methods on FormRenderer that
are used in CommandLinkRenderer as well as HiddenFieldRenderer.
(ex: FormRenderer.addNeededHiddenField....)
Anyone now using our CommandLinkRenderer must also use our FormRenderer..

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

[PORTLET] portlet title is not set

FacesPortlet should set portlet title during render. Check
javax.portlet.GenericPortlet.render() implementation.

The code could look something like:

response.setTitle(
portletConfig.getResourceBundle(request.getLocale()).getString(
"javax.portlet.title"));

On Novell Extend portlet container, not setting the title results in displaying
portlet definition name in place of title.

Environment

Operating System: All
Platform: All

Affected Versions

[current]

Passing backing beans as parameter

I think it's nice to add support to EL of passing to the action methods, to the
subview etc the backing beans as parameters.

There are param tag but it pass just string as parameter.

Sometime there is very useful to pass some object (particulary backing bean) to
the action method or to the included subview.

F.g. there can be some subview with menubar. List with current menubar stored in
the current backing bean. For all our pages with its own backing bean (and menu)
we will have common subview.

I'm understen this can be achieved by other ways but IMHO this technique can be
very power and useful.

Environment

Operating System: All
Platform: All

Affected Versions

[current]

Application default locale ignored by configuration system

From the forums:
http://forum.java.sun.com/thread.jsp?forum=427&thread=538043&tstart=0&trange=15

Hi, following is bug, I believe.

com/sun/faces/config/ConfigureListener.java
Method: configure()

value = config.getDefaultLocale();
if (value != null) {
if (log.isTraceEnabled()) { // <--- !!!!
if (log.isTraceEnabled())

{ log.trace("setDefaultLocale(" + value + ")"); }

application.setDefaultLocale
(Util.getLocaleFromString(value));
}
}

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

ServletContext/PortletContext incompatibility

In com.sun.faces.application.ApplicationAssociate there are assumptions on
context object being ServletContext. in case of FacesPortlet use,
PortletContext object is passed here. Not sure what's the solution:

1. return ServletContext instead of PortletContext in
com.sun.faces.portlet.ExternalContextImpl.getContext
2. remove ServletContext assumption in ApplicationAssociate

now the result is ClassCastException in ApplicationAssociate.getInstance. i've
made temporary patch as in p.1 and it seems to work...

i'm using Novell Extend Director as portlet container. maybe in other
containers PortletContext implementation class implements ServletContext as
well and this might work. however, afaik it's not required in Portlet API
specification.

Environment

Operating System: All
Platform: All

Affected Versions

[current]

state saving in server bug

There is a long standing state saving in server bug that causes the most
recent view to be restored instead of the one that caused the
postback when there are multiple views of the same viewId in session.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Application default locale ignored by configuration system

From the forums:
http://forum.java.sun.com/thread.jsp?forum=427&thread=538043&tstart=0&trange=15

Hi, following is bug, I believe.

com/sun/faces/config/ConfigureListener.java
Method: configure()

value = config.getDefaultLocale();
if (value != null) {
if (log.isTraceEnabled()) { // <--- !!!!
if (log.isTraceEnabled())

{ log.trace("setDefaultLocale(" + value + ")"); }

application.setDefaultLocale
(Util.getLocaleFromString(value));
}
}

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

managed-bean properties pointing at non-managed beans fail

I'm trying to set up a managed bean that points at non-managed bean:

foo my.Foo request object #

{myObject}

I've used a plugin VariableResolver that guarantees that "myObject" is
available. But
com.sun.faces.config.ManagedBeanFactory.getScopeForSingleExpression()
throws an exception, because it doesn't know what scope "myObject" is in.
When confronted with an object it doesn't know, ManagedBeanFactory must
assume (or hope) for the best, not throw an exception. This code must only
detect provable errors, not potential errors.

The simple fix is to replace:
// we are referring to a bean that doesn't exist in the
// configuration file.
Object[] obj = new Object[1];
obj[0] = (null != firstSegment[0]) ? firstSegment[0] : value;
throw new EvaluationException(
Util.getExceptionMessageString(
Util.NAMED_OBJECT_NOT_FOUND_ERROR_MESSAGE_ID, obj));

with just "return RIConstants.APPLICATION;"

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

ye-olde content interweaving issue

The age-old content interweaving problem. Consider this JSP fragment:

<h:panelGrid columns="1">
first text
<h:outputText value="second text"/>
third text
<h:outputText value="fourth text"/>
fifth text
</h:panelGrid>

You'd expect

first text
second text
third text
fourth text
fifth text

What you get instead is

second text
fourth text
first text
third text
fifth text

This is well documented in Hans's article at
<http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html>.

Environment

Operating System: All
Platform: All

Affected Versions

[1.0]

Problems with subviews, verbatim, form, and client state management

I originally posted this in the forum:

http://forum.java.sun.com/thread.jsp?forum=427&thread=541780

I have 2 pages main.jsp and menu.jsp. main.jsp includes menu.jsp. menu.jsp has a
form with a commandlink. The commandlink submits an action that then navigates
to some third page. When I click on the command link instead of navigating to
the third page main.jsp is reloaded and the command link has dissappeared.

If I try the exact same example using Server side state management everything
works fine.
If I remove the verbatim tags everything works fine.
If I move the verbatim tags below the command link everything works fine.

Anyone have any ideas?

main.jsp

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:view>
See if this works.
<jsp:include page="menu.jsp" flush="false"/>
</f:view>

menu.jsp

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:subview id="menu">
<f:verbatim>Test Text</f:verbatim>
<h:form>
<h:commandLink action="error"><h:outputText value="test"/></h:commandLink>
</h:form>
</f:subview>

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

href="javascript:" is better then onclick in commandLink renderer

I think using href="javascript:document.forms......." is better solution then
using onclick DHTML event in rendered HTML code for commandLink component?

This is because:
1. browser do not handle unnecessary href="#" (which sometimes is very
unnecessary because scrolls page to the top of page before sending the request
to server)
2. in forum (f.g. http://forum.java.sun.com/thread.jsp?forum=427&thread=506830)
I read then onclick event for commandLink doesn't work because in html onclick
already used.

<h:commandLink id="link" action="goto">
<h:outputText value="#

{msg.linkName}

"/>
</h:commandLink>

Rendered as:

Next Page

My suggestion:

Next Page

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Frame support

JSF has never done very well in applications with FRAMESETS.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

ServletContext/PortletContext incompatibility

In com.sun.faces.application.ApplicationAssociate there are assumptions on
context object being ServletContext. in case of FacesPortlet use,
PortletContext object is passed here. Not sure what's the solution:

1. return ServletContext instead of PortletContext in
com.sun.faces.portlet.ExternalContextImpl.getContext
2. remove ServletContext assumption in ApplicationAssociate

now the result is ClassCastException in ApplicationAssociate.getInstance. i've
made temporary patch as in p.1 and it seems to work...

i'm using Novell Extend Director as portlet container. maybe in other
containers PortletContext implementation class implements ServletContext as
well and this might work. however, afaik it's not required in Portlet API
specification.

Environment

Operating System: All
Platform: All

Affected Versions

[current]

"border" Attribute - SelectManyCheckboxListRenderer

From a customer:

Hi, Following seems a bug.

SelectManyCheckboxListRenderer renders "border" attribute in "input"
tag. Accrding to HTML spec, "input" tag can not have "border"
attribute.

Line 229(Original)
Util.renderPassThruAttributes(writer, component,
new String[]

{"style"}

);

(Suggested fix)
Util.renderPassThruAttributes(writer, component,
new String[]

{"style", "border"}

);

– HANAI Shisei [email protected]

===========================================================================
Verified against HTML 4.0.1 spec that "border" is not valid for
"input" elements. This should be excluded as a pass through attribute.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

LifecycleImpl

For phase listeners, possibly modify the phase processing to allow the
afterPhase method to be called in a finally block. If an error occurs in one of
the Phases, the afterPhase would never be called. This may prevent resource
cleanup and cause memory leaks in developer implementations.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Incorrect locale after session expires

From the forum.

I have the following lines in the faces-config file:

fr es

Note that my app gets its locale from the session. When the session expires my
jsf app tries to switch to the browser's locale which is US. How can I prevent
this and have it switch to the fr locale instead? Do I have to have a
HttpSessionListener listen to the session destruction and reset it to fr or is
there a cleaner way to do it?

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Possible missed opportunity for more helpful error message

Re: Conversion Error Occurred
Author: Valerie_Lipman Aug 2, 2004 11:30 AM (reply 19 of 19)
Hi all!

Ok - I worked w/Haroon this morning andI think I understand what's going on
here! Let me try to explain.... first I'll summarize the scenario at hand:

Start w/page with 3 components:

  • textfield
  • button
  • message list

Add a rowset to the page, and bind the textfield to one of the columns in that
rowset

Now run. The data shows in the textfield, but when I type something else into
the textfield and click the button, a conversion error is shown in the message list.

I haven't added a converter or anything - what's going on? Shouldn't this work?

Answer : No, but it would be nice if you got a better error message. Now I'll
try to explain why!

Textfield is a JSF input component (as is a dropdown, etc). By default, when a
page is "submitted" (via button click), in the JSF lifecycle they will
inherently go through validation and conversion.

In this case, the textfield is bound to a rowset which by default is set to
CONCUR_READ_ONLY (the default concurrency property). So it cannot accept changes
(because the rowset won't allow it), and hence an error was thrown durring the
conversion stage. Granted, If it had given you an error stack that included
something like "rowset does not allow current operation" that would have been
helpful I'll see if we can do something there (might be deep inside JSF, not
sure yet).

So, what do you need to do to get it to work? You have 2 choices:

  1. Change the concurrency property to CONCUR_UPDATABLE and then all will be fine

  2. Set the immediate property on the button so that it will bypass the
    conversion/validation phases. For example, you will see that in the AppModel
    sample, we set the immediate property on the cancel buttons because really, who
    cares if the stuff isn't valid etc - we're just gonna throw it away anyway. But
    you should do this only when you are sure you don't want ANY of the
    validation/conversion to occur for the page. In this scenario, I think it was
    correctly refusing to update the values in the rowset (although it didn't give a
    clear enough error message) - so that's a feature

Let me know if you have more q's!
Val

Environment

Operating System: All
Platform:
URL: http://swforum.sun.com/jive/thread.jspa?threadID=47015&start=15&tstart=0

Affected Versions

[1.1]

very poor performance of datatables

There are serious performance problems with large datatables. I've made
serveral simple test comparing JSF versus plain JSP implementation. In case of
table (<h:dataTable>) 10 columns wide, 50 rows (each cell about 10 chars) there
was serious non-linear performance degradation, comparing to smaller table (8
colums, 20 rows).
Larger table case was about 100 times slower (request processing time) under
medium-to-heavy load. The average time was very unstable, with very high
deviation. It seems that garbage collector cycles might be the reason.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

form parameter not processed.

I am trying to generate the folowing page :

record id - record description - link to delete current record
record id - record description - link to delete current record
...

I have the folowing code in my jsf page:
<h:dataTable value="#

{PostBackingBean.posts}

" var="post" >
<h:column>
<h:outputText value="#

{post.id}"/>
</h:column>
<h:column>
<h:outputText value="#{post.description}"/>
</h:column>
<h:column>
<h:outputText value="#{post.debet_credit}"/>
</h:column>
<h:column>
<h:form>
<h:inputHidden id="id" value="#{post.id}

">
</h:inputHidden>
<h:commandLink id="delete" value="#

{msgs.PromptDelete}

" action="#

{PostBackingBean.deleteAction}

"/>
</h:form>
</h:column>
</h:dataTable>

I am using the weekly build (multiple forms in one page is not the problem).
The page looks nice.
However, when executing the delete action the hidden value is not being passed
into the PostBackingBean.
This is very strange to me. When I print the request parameters of the
resultpage I get the following output:

[exec] 04/07/05 20:10:28 name=_id0:0:_id8,value=_id0:0:_id8
[exec] 04/07/05 20:10:28 name=_id0:0:_id8:_idcl,value=_id0:0:_id8:delete
[exec] 04/07/05 20:10:28 name=_id0:0:_id8:id,value=183

I know that the SetId method of the backingbean is executed however, the value
that is set is null.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

"target" property on commandLink does not work.

"target" property on commandLink does not work. commandLink currently acts like
a button, so target property probably needs to be disabled.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

commandLink tag does not work with frames

i copied the issue description on Sun's java faces forum to describe the issue:

Hi all:
i used a main page devided into 3 frames: top, left(navigation) and right
(contents). in top frame, there is a
<h:commandLink>, such as below:
<h:commandLink action="#

{userBean.logout}

">
<h:outputText value="Logout" />
</h:commandLink>

i want that when logout link cliked, the web application navigates to
login.jsp. but the login.jsp appears in the top frame instead of the whole
browser window.

does anybody know how to display the login.jsp in the whole browser window?

regards.

yes, target attribute does not work with commandLink tag because of the encode
behavior of commandLink, when encoding, the href attribute of the tag set
to "#".
i used outputLink instead here because i don't need to fire an ActionEvent.

Environment

Operating System: All
Platform: All
URL: http://forum.java.sun.com/thread.jsp?forum=427&thread=536481&tstart=30&trange=15

Affected Versions

[1.1]

UIComponentTag.isSuppressed() performance

The isSuppressed() method is unnecessarily slow for two reasons:

1. It's called twice per tag (doStartTag() and doEndTag()) and does the same
work both times, even though its result must be the same in each case.

2. The logic of this method calls isRendered() unnecessarily. Specifically,
a tag should be suppressed if:
"parent-is-suppressed" || is-a-facet || !isRendered() ||
parent.isRendersChildren()

However, the logic is actually ordered to check "is-a-facet" and isRendered()
first. Generally, this is not a problem; however, if "rendered" is attached
to a ValueBinding that points at a managed bean that then must be created and
initialized only because of this isRendered() call, and the component is
already inside of a "rendered=='false'" and "rendersChildren=='true'"
component, then that's a problem. (A client is running into this problem.)

Code recommendations (sorry, no patch...)
(1) Move "isSuppressed()" logic into private isSuppressedImpl() method. Use
that method to initialize a "suppressed" private boolean instance variable at
the top of doStartTag(). Change protected isSuppressed() method to simply
return that instance variable.

(2) Change the isSuppressedImpl() method logic to more-or-less:
UIComponentTag parentTag;

if (getFacetName() != null)

{ return (true); }
// Note that isSuppressed() is a cached value by (1), so this is
// a very fast call
if (parentTag.isSuppressed()) { return (true); }

if (!component.isRendered())

{ return (true); }
UIComponent parent = this.component.getParent();
if (parent != null) && parent.getRendersChildren()) { return (true); }

return false;

I'm fairly certain this doesn't change the semantics in any way, and it's
considerably faster, especially when isRendered() is expensive.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

OutputMessageRenderer "id" Attr Not Rendered

Found by Customer:

id is not output in HTML SPAN tag.
h:outputFormat outputs HTML SPAN tag. But it does not output id attribute in
SPAN tag at all. (OutputMessageRenderer.java)

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

form parameter not processed.

I am trying to generate the folowing page :

record id - record description - link to delete current record
record id - record description - link to delete current record
...

I have the folowing code in my jsf page:
<h:dataTable value="#

{PostBackingBean.posts}

" var="post" >
<h:column>
<h:outputText value="#

{post.id}"/>
</h:column>
<h:column>
<h:outputText value="#{post.description}"/>
</h:column>
<h:column>
<h:outputText value="#{post.debet_credit}"/>
</h:column>
<h:column>
<h:form>
<h:inputHidden id="id" value="#{post.id}

">
</h:inputHidden>
<h:commandLink id="delete" value="#

{msgs.PromptDelete}

" action="#

{PostBackingBean.deleteAction}

"/>
</h:form>
</h:column>
</h:dataTable>

I am using the weekly build (multiple forms in one page is not the problem).
The page looks nice.
However, when executing the delete action the hidden value is not being passed
into the PostBackingBean.
This is very strange to me. When I print the request parameters of the
resultpage I get the following output:

[exec] 04/07/05 20:10:28 name=_id0:0:_id8,value=_id0:0:_id8
[exec] 04/07/05 20:10:28 name=_id0:0:_id8:_idcl,value=_id0:0:_id8:delete
[exec] 04/07/05 20:10:28 name=_id0:0:_id8:id,value=183

I know that the SetId method of the backingbean is executed however, the value
that is set is null.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

OutputText Not Rendering w/ Verbatim Tag (Client Mode)

From the forum:

the following is a sample jsp code that shows the verbatim tag (in the 2nd
column of the panelGrid) somehow causes the outputText in the facet of the
panelGrid not render the text anymore. the first time you load the jsp page, you
can see the outputText being rendered as the header for the table. but if you
click on the redisplay button, the outputText is not rendered anymore in the header.

if you replace the verbatim tag with another tag, say outputText, in the 2nd
column, then the problem goes away.

any help is appreicated. (i am using sun's ri.)

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

<f:view>

<title></title>

<%-- the first column --%>
<h:commandLink>
<h:outputText value="redisplay"/>
</h:commandLink>

<%-- the second column --%>

<%-- this works
<h:outputText value="output text"/>
--%>

<%-- this doesn't work on redisplay: the outputText in the facet is not rendered.
--%>
<f:verbatim >
verbatim text here
</f:verbatim>

</h:panelGrid>
</h:form>

============================================
This works fine "server" state saving mode.
"client" state saving mode produces the problem
described above.

-roger

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

very poor performance of datatables

There are serious performance problems with large datatables. I've made
serveral simple test comparing JSF versus plain JSP implementation. In case of
table (<h:dataTable>) 10 columns wide, 50 rows (each cell about 10 chars) there
was serious non-linear performance degradation, comparing to smaller table (8
colums, 20 rows).
Larger table case was about 100 times slower (request processing time) under
medium-to-heavy load. The average time was very unstable, with very high
deviation. It seems that garbage collector cycles might be the reason.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Constructor Injection vs. ApplicationAssociate

For providing the vendor implementation logic through the core JSF-RI configs,
instead of being dependent on a scoped ApplicationAssociate, provide all
configuration information through *Impl objects and allow the client developer
to write objects that accomodate constructor injection.

Basically, I would like to have the RI get away from a strong dependency on
scoped variables to be in place, the most major being the ApplicationAssociate.
Also, the ApplicationAssociate contains too much behavior/state. Instead, we
have our core package of implementations (with each behavior seperated ala JSF
API) that are provided via JAXB and overridable via constructor injections. I
would almost go as far as to have a config loader for each Factory to seperate
dependencies even more.

By allowing the FactoryFinder to maintain application/factory state, we aren't
dependent on the existence of crutial, scoped variables that are under the
ownership of the running application, not of the vendor implementation.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.