[JAVASERVERFACES-2529] Mojarra release notes says servlet 3.0 is a requirement where it is not Created: 04/Oct/12  Updated: 04/Oct/12  Resolved: 04/Oct/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12, 2.1.13
Fix Version/s: 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12, 2.1.13

Type: Bug Priority: Major
Reporter: rcoacci Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The release notes in http://javaserverfaces.java.net/nonav/rlnotes/2.1.13/releasenotes.html (and all versions up to 2.1.0) states that servlet 3.0 is a requirement. It's been said before in some forum that it's not (http://www.java.net/forum/topic/glassfish/glassfish-webtier/mojarra-jsf-21x-servlet-requirement-or-dependency-0) but the relase notes doesn't seem to be fixed yet.



 Comments   
Comment by Manfred Riem [ 04/Oct/12 ]

Applied to www,

svn commit -m "Make sure Servlet 2.5 is the listed requirement"
Sending rlnotes\2.1.0\releasenotes.html
Sending rlnotes\2.1.1\releasenotes.html
Sending rlnotes\2.1.10\releasenotes.html
Sending rlnotes\2.1.11\releasenotes.html
Sending rlnotes\2.1.2\releasenotes.html
Sending rlnotes\2.1.3\releasenotes.html
Sending rlnotes\2.1.4\releasenotes.html
Sending rlnotes\2.1.5\releasenotes.html
Sending rlnotes\2.1.6\releasenotes.html
Sending rlnotes\2.1.7\releasenotes.html
Sending rlnotes\2.1.8\releasenotes.html
Sending rlnotes\2.1.9\releasenotes.html
Transmitting file data ............
Committed revision 3301.





[JAVASERVERFACES-2145] A bug in the 2.1.2 source makes it ipossible to build the project. Created: 16/Jul/11  Updated: 20/Sep/14  Resolved: 01/Feb/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.2
Fix Version/s: 2.1.2, 2.2.0-m01

Type: Bug Priority: Trivial
Reporter: pablo53 Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any environment


Attachments: Text File changebundle-2145.txt    
Tags: build, building, compile, compiling, maven, mojarra, repo, repositories, repository, source, tlddoc

 Description   

A project file "mojarra-2.1.2-FCS-source\jsf-tools\pom.xml" declares version 2.1.1-SNAPSHOT of jsf-tools component, but the main project looks for 2.1.2-SNAPSHOT version. This makes ant to throw the following exception while building Mojarra 2.1.2:

BUILD FAILED
...\mojarra-2.1.2-FCS-source\build.xml:113: The following error occurred while executing this line:
...\mojarra-2.1.2-FCS-source\build.xml:81: The following error occurred while executing this line:
...\mojarra-2.1.2-FCS-source\jsf-api\build.xml:202: taskdef class com.sun.faces.ant.ComponentGenTask cannot be found

Changing the declaration to 2.1.2-SNAPSHOT allows to build the project successfully.

BTW: Another issue, constantly faced by everybody trying to build Mojarra, is broken maven repository. This time: tlddoc-1.3.jar cannot be found in $

{maven2.mirror}. This can be resolved by changing:

${maven2.mirror}

/taglibrarydoc/tlddoc/$

{taglibdoc.version}/tlddoc-${taglibdoc.version}

.jar

to:

$

{central.maven2}

/taglibrarydoc/tlddoc/$

{taglibdoc.version}/tlddoc-${taglibdoc.version}

.jar

in "mojarra-2.1.2-FCS-source/common/ant/dependencies.xml".



 Comments   
Comment by rogerk [ 16/Jul/11 ]

thanks for the heads up.

Comment by rogerk [ 16/Jul/11 ]

Committed to trunk:

Sending common/ant/dependencies.xml
Transmitting file data .
Committed revision 9202.

Committed to MOJARRA_2_1X_ROLLING:

Sending common/ant/dependencies.xml
Transmitting file data .
Committed revision 9203.

Comment by rogerk [ 08/Sep/11 ]

fix versions

Comment by rogerk [ 08/Sep/11 ]

fix versions

Comment by rogerk [ 08/Sep/11 ]

fix versions

Comment by Sreekanth [ 01/Feb/13 ]

Even Now I am facing the issue

When I run ant clean main, I get this error.

update:
[patch] patching file /space/Sreekanth/dev-workspace/JSF-Sources/trunk/dependencies/xs3p-1.1.5/xs3p.xsl
[patch] Reversed (or previously applied) patch detected! Assume -R? [n]
[patch] Apply anyway? [n]
[patch] Skipping patch.
[patch] 1 out of 1 hunk ignored – saving rejects to file /space/Sreekanth/dev-workspace/JSF-Sources/trunk/dependencies/xs3p-1.1.5/xs3p.xsl.rej
[patch] 'patch' failed with exit code 1

prepare:
[mkdir] Created dir: /space/Sreekanth/dev-workspace/JSF-Sources/trunk/jsf-api/build/generate

check.generation.necessity:

generate:
[delete] Deleting directory /space/Sreekanth/dev-workspace/JSF-Sources/trunk/jsf-api/build/generate

tools.javac:

BUILD FAILED
/space/Sreekanth/dev-workspace/JSF-Sources/trunk/build.xml:103: The following error occurred while executing this line:
/space/Sreekanth/dev-workspace/JSF-Sources/trunk/jsf-test/build.xml:105: The following error occurred while executing this line:
/space/Sreekanth/dev-workspace/JSF-Sources/trunk/jsf-api/build.xml:201: taskdef class com.sun.faces.ant.ComponentGenTask cannot be found
using the classloader AntClassLoader[/space/Sreekanth/MavenRepo/commons-collections/commons-collections/2.1.1/commons-collections-2.1.1.jar:/space/Sreekanth/MavenRepo/commons-digester/commons-digester/1.5/commons-digester-1.5.jar:/space/Sreekanth/MavenRepo/commons-beanutils/commons-beanutils/1.6.1/commons-beanutils-1.6.1.jar:/space/Sreekanth/MavenRepo/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar:/space/Sreekanth/MavenRepo/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar:/space/Sreekanth/dev-workspace/JSF-Sources/trunk/jsf-tools/build/classes]

Comment by Sreekanth [ 01/Feb/13 ]

One more issue is when we want to run the tests against glassfish, I copied build.properties.glassfish to build.properties, maven tries to look for dependencies in ~/.m2 home directory. The property "maven.repo.local" is missing in the <JSF-Sources>/trunk/build.properties.glassfish file.

Comment by Sreekanth [ 01/Feb/13 ]

Re-opening the issue. See my comments in the issue.

Thanks,
Sreekanth

Comment by Manfred Riem [ 01/Feb/13 ]

Please do ant main clean main the first time you run it.

Comment by sono99 [ 20/Sep/14 ]

On the installation instructions of how to build Mojarra, it should also be mentioned that each release my have a required dependency on the JDK used to build it.

E.g, 2.1.25 branch can only be branch with JDK 6 due tools.jar
https://wikis.oracle.com/display/GlassFish/JavaServerFacesRI#JavaServerFacesRI-Workingwiththesourcecode

<profiles>
<profile>
<id>default-tools.jar</id>
<activation>
<property>
<name>java.vendor</name>
<value>Sun Microsystems Inc.</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.6.0</version>
<scope>system</scope>
<systemPath>$

{java.home}

/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
</profile>
</profiles>

When I had java_home pointing to JDK7 i was unable to build jsf-tools due to compilation errors.

Thanks.





[JAVASERVERFACES-2104] Mojarra jobs that run GlassFish quicklook daily. Created: 10/Jun/11  Updated: 23/Mar/12  Resolved: 14/Jul/11

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.2

Type: Task Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

DP> Why can't you all have a hudson job that runs with the JSF latest
DP> bits with GlassFish trunk (in this case 3.1.1) atleast once a
DP> day. Ofcourse hudson wasn't up this week - but if it was we could
DP> have discovered this problem sooner

Yes, once hudson comes back we'll have a job that runs QL with the 3.1.1
branch on MOJARRA_2_1X_ROLLING and another job that does QL with the
trunk branch on MOJARRA_2_1X_ROLLING, yet another pair of jobs that runs
the QL on 3.1.1 and the GlassFish trunk with Mojarra trunk.



 Comments   
Comment by Ed Burns [ 14/Jul/11 ]

We finally have this!

http://ron-vm8.us.oracle.com:7070/hudson/view/GLASSFISH_QUICKLOOK/

Comment by Manfred Riem [ 23/Mar/12 ]

Closing resolved issue out





[JAVASERVERFACES-2092] f:convertDateTime validation error message FR Created: 01/Jun/11  Updated: 26/Jun/12  Resolved: 11/Jun/11

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: current, 2.0.4, 2.1.1
Fix Version/s: 2.1.2

Type: Bug Priority: Major
Reporter: mansour Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 30 minutes
Original Estimate: Not Specified
Environment:

Mojarra (tested with versions 2.0.4 and 2.1.1), tomcat 6.0, windows


Attachments: Text File 20110601-i_mojarra_2092.patch     File JSF2MessageBug.war    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2091 f:convertDateTime validation error me... Closed
Tags: api, i18n, jsf2, message

 Description   

Here is a simple example of date input text with <f:convertDateTime/> :

 
<h:inputText id="dateOfBirth" value="#{user.dateOfBirth}" 
    size="20" required="true" label="Date of Birth">
    <f:convertDateTime />
</h:inputText>
<h:message for="dateOfBirth" style="color:red" />

When we execute this with an error in date conversion (ex : xxxxx) in the inputText field, the error message displayed in <h:message> with locale FR contains the token '

{1}

' which means that a parameter is not interpreted :

Date of Birth : 'xxxxx' na pas pu être interprété en tant que date. Exemple : \{1\}

When we switch the locale in english, there is no problem the message is correctly displayed :

Date of Birth: 'xxxxx' could not be understood as a date. Example: Jun 1, 2011

Solution : in jsf-api.jar/javax.faces.Messages_fr.properties the character ' (quote) is not escaped in many messages, so try to put a double quote like this : ''

I've attached a sample web project that illustrates the problem



 Comments   
Comment by Ed Burns [ 01/Jun/11 ]

Please review this fix.

Comment by mansour [ 07/Jun/11 ]

Thank you for the patch, it works better now but it seems that you forgot some characters ''(quotes) that are not replaced by "\u00ab" and "\u00bb"in the file JsfToolsMessages_fr.properties. For the moment, we will include the file messages_fr.properties corrected in the web application and we wait for a new version that correct this 2.0.x or 2.1.x ?

Comment by Ed Burns [ 07/Jun/11 ]

Committed to trunk.

Sending jsf-api/src/main/java/javax/faces/LogStrings_fr.properties
Sending jsf-api/src/main/java/javax/faces/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Jalopy_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Luxury_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Resources_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/SUV_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/resources/Messages_fr.properties
Sending jsf-tools/src/main/resources/JsfToolsMessages_fr.properties
Transmitting file data ..........
Committed revision 9136.

Comment by Ed Burns [ 07/Jun/11 ]

Committed to 2.1 branch.

Sending jsf-api/src/main/java/javax/faces/LogStrings_fr.properties
Sending jsf-api/src/main/java/javax/faces/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Jalopy_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Luxury_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Resources_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/SUV_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/resources/Messages_fr.properties
Sending jsf-tools/src/main/resources/JsfToolsMessages_fr.properties
Transmitting file data ..........
Committed revision 9137.

Comment by Ed Burns [ 07/Jun/11 ]

Committed to 2.0.x branch, but we've already cut 2.0.6. Therefore, it will be in 2.0.7.

Thanks for reporting it.

Sending jsf-api/src/main/java/javax/faces/LogStrings_fr.properties
Sending jsf-api/src/main/java/javax/faces/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Jalopy_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Luxury_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Resources_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/SUV_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/resources/Messages_fr.properties
Sending jsf-tools/src/main/resources/JsfToolsMessages_fr.properties
Transmitting file data ..........
Committed revision 9138.

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version





[JAVASERVERFACES-2088] Mojarra 2.2.0 HEAD (rev. 9111) startup fails on tomcat 6 because of missing JSR 303 api classes Created: 30/May/11  Updated: 02/Nov/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: conversion
Affects Version/s: None
Fix Version/s: 2.0.6, 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: Hanspeter Duennenberger Assignee: ioss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

Tomcat 6, Windows XP


Attachments: Text File changebundle.txt    
Issue Links:
Dependency
blocks JAVASERVERFACES-2061 bv detection is incomplete Closed

 Description   

Hello,

Mojarra 2.2 HEAD fails on Tomcat 6 while initializing ConfigManager.

On a servlet container like Tomcat the JSR 303 API classes are not present (unless provided by app). But JAVASERVERFACES-2061 (change rev. 9043) added link/runtime dependency to the JSR 303 API classes. And because the location where this happens (line 164 in ConfigureListener) is not within a try/catch block, Mojarra deployment almost silently fails on the call to ConfigManager.getInstance().

My questions are:
1. will JSF 2.2 still run on Servlet containers like Tomcat?
2. If yes, will JSF 2.2 require JSR 303 API classes to be available always?

If JSF 2.2 should be able to run on Servlet container without the JSR 303 API classes being deployed, then that runtime dependency to the javax.validation classes must be removed.

If JSR 303 API classes will be required always, Mojarra should probably also write the ClassNotFoundException to System.out to inform developers immediately.

regards
Hanspeter



 Comments   
Comment by ioss [ 30/May/11 ]

Proposed fix.
Tested on Tomcat 6.0.32 by me and test confirmed by dueni (Hanspeter)

Comment by rogerk [ 31/May/11 ]

r=rogerk

Comment by ioss [ 31/May/11 ]

Revision: 9125
Author: ioss
Date: 2011-06-01 00:26
Message: Fix for http://java.net/jira/browse/JAVASERVERFACES-2088 - Mojarra 2.2.0 HEAD (rev. 9111) startup fails on tomcat 6 because of missing JSR 303 api classes
and fix of a small typo.

Comment by ioss [ 02/Jun/11 ]

Backport to 2.0.x- & 2.1.x- Rolling done

Comment by rogerk [ 04/Jun/11 ]

fix version

Comment by rogerk [ 04/Jun/11 ]

fix version

Comment by rogerk [ 04/Jun/11 ]

fix version





[JAVASERVERFACES-2079] impossible to change project stage away from development Created: 24/May/11  Updated: 15/Aug/13  Resolved: 11/Jun/11

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.1.2

Type: Bug Priority: Major
Reporter: jstrong Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

tomcat 7-10, JSF 2.1.1-b04, FCS


Attachments: File bugshow.war    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2082 please revisit JAVASERVERFACES-2079 Closed
Related
is related to JAVASERVERFACES-1922 Invalid missing form diagnostic messa... Closed
is related to JAVASERVERFACES-930 Add wrappers for FacesContext, Extern... Closed

 Description   

this exacerbates issue JAVASERVERFACES-1922, where others also point out they are unable to change PROJECT_STAGE in any way

using the context parameter:

<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>XXXX</param-value>
</context-param>

has no effect. development stage remains as development

even this PhaseListener, which casts to the mojarra impl and attempts to force change the field through reflection does nothing:

=========================================
@Override
public void beforePhase(PhaseEvent arg0) {

ApplicationImpl ai=(ApplicationImpl) FacesContext.getCurrentInstance().getApplication();

try {
if (ai.getProjectStage()==ProjectStage.Development )

{ Field f=ai.getClass().getDeclaredField("projectStage"); f.setAccessible(true); f.set(ai, ProjectStage.Production); }

} catch (Exception e)

{ e.printStackTrace(); }

}

========================================



 Comments   
Comment by jstrong [ 24/May/11 ]

failing example

dump war into latest tomcat

i am using tomcat 710

note project stage stays as development even though its set to prod and i am trying to change it in the phaselistener

Comment by Ed Burns [ 26/May/11 ]

The value of the ProjectStage parameter is not intended to be mutable. Though this is not explicitly stated in the spec, this text in the spec for Application.getProjectStage() implicitly states it.

If the value has already been determined by a previous call to this method, simply return that value.

There is no provision for dynamically discovering the value each time Application.getProjectStage() is called.

I am hesitant to explicitly declare the value is not mutable at runtime, however, because a future version of the spec may want to allow runtime mutability. I, however, do not think allowing it is a good idea.

Ed, JSF spec lead.

Comment by Ed Burns [ 26/May/11 ]

To prove this works, I have created a regression test and am adding it to the 2.0, 2.1, and trunk lines.

Hudson gives us this agility.

Committed to trunk:

Adding jsf-test/JAVASERVERFACES-2079
Adding jsf-test/JAVASERVERFACES-2079/build.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079/Issue2079DevelopmentTestCase.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079/Issue2079ProductionTestCase.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression/i_jsf_2079/UserBean.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/main.xhtml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression/i_jsf_2079/UserBean.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/main.xhtml
Sending jsf-test/build.xml
Transmitting file data .............
Committed revision 9103.

Comment by Ed Burns [ 26/May/11 ]

Adding jsf-test/JAVASERVERFACES-2079
Adding jsf-test/JAVASERVERFACES-2079/build.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079/Issue2079DevelopmentTestCase.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079/Issue2079ProductionTestCase.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression/i_jsf_2079/UserBean.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/main.xhtml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression/i_jsf_2079/UserBean.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/main.xhtml
Sending jsf-test/build.xml
Transmitting file data .
Committed revision 9105.

Comment by Ed Burns [ 26/May/11 ]

Committing to 2.0 branch:

Adding jsf-test/JAVASERVERFACES-2079
Adding jsf-test/JAVASERVERFACES-2079/build.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079/Issue2079DevelopmentTestCase.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/java/com/sun/faces/systest/regression/i_jsf_2079/Issue2079ProductionTestCase.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/java/com/sun/faces/regression/i_jsf_2079/UserBean.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_0_ProjectStageDevelopment/src/main/webapp/main.xhtml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/pom.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression/i_jsf_2079
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/java/com/sun/faces/regression/i_jsf_2079/UserBean.java
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2079/i_jsf_2079_war_1_ProjectStageProduction/src/main/webapp/main.xhtml
Sending jsf-test/build.xml
Transmitting file data .
Committed revision 9106.

Comment by jstrong [ 26/May/11 ]

HANG ON!!!!!!

forget the phaselistener.

i put it in there to print out the developmentstage status.

i don't care about dynamically changing project stage. i only tried that since the web.xml setting to switch the stage does not work (as others have pointed out in JAVASERVERFACES-1922).

did you deploy the war into tomcat?

at least in tomcat 7010 the projectstage setting in web.xml does NOT change the projectstage in the app.

i have set it to Production in the war yet it remains at development.

Comment by ioss [ 26/May/11 ]

Moved comments by jstrong from JAVASERVERFACES-2082 here:

JS> you have miss
JS> i have provided a war. please deploy it into tomcat7011, there is a phaselistener printing out the
JS> phaselistener is printing out the projectstage.
JS> note that web.xml is setting the project stage to production
JS> note that he phaselistener is printing out the projectstage it devel;opment.
JS> it may wotk in glassfish but its not wqortking in tomcat.

JS> sorry accidentally submitted the comment.
JS> summary: in the war web.xml has
JS> <context-param>
JS> <param-name>javax.faces.PROJECT_STAGE</param-name>
JS> <param-value>Production</param-value>
JS> </context-param>
JS> deploy example war from JIRA 2079 to latest tomcat 7 (i am using 7010 or 11)
JS> go to http://localhost:8080/bugshow/mypage.htm
JS> a phaselistener is printing out the projectstage on each request.
JS> IT IS ALWAYS DEVELOPMENT REGARDLESS OF WHAT IS SET IN WEB.XML
JS> my dynamic change was just an attempt to force the change since the config setting was not working. it is not the issue i am trying to raise.
JS> again - others are having the same issue so there is definitely a problem

Comment by ioss [ 26/May/11 ]

Hi jstrong,

I deployed your war to Tomcat 7.0.14 and 7.0.10 with the following result:
1) I had to remove the el-*.jars (because of a conflict with the ones provided by Tomcat. I did not care to resolve it in another way.)
2) Created a org.jsf.robust.TestPhaseListener from the decompiled sources of your class (without the change "hack").
The important part:

public void beforePhase(PhaseEvent arg0) {
    ApplicationImpl ai = (ApplicationImpl)FacesContext.getCurrentInstance().getApplication();
    System.out.println((new StringBuilder())
            .append("------>>>  PROJECT STAGE IS ")
            .append(ai.getProjectStage()).toString());
}

3) Observed output:

------>>>  PROJECT STAGE IS Production
------>>>  PROJECT STAGE IS Production

So, as your war as it is in the attachment is not deployable to a pristine installation of Tomcat 7.0.10 or 7.0.14 and so /bugshow/mypage.htm can not be called and the phaselistener will not run, maybe you are not "looking" at what you expect to be deployed.
Also check, that you don't have the JNDI Property for PROJECT_STAGE set to Development, because this will have a higher priority then the context-parameter in web-inf.

If your issue still persists, please comment here and maybe you could try to deploy your war (without any libraries in WEB-INF/lib) to a glassfish instance.

Imre

Comment by jstrong [ 29/May/11 ]

thanks for looking at this so promptly.

the war actually does deploy for me with the included el libs which is strange.

i have tracked down the issue to the use of JRebel as a JVM agent during development.

i am generally careful to look at these things thoroughly before filing a bug report but have been using JRebel for quite some time without incident and forgot i was even using it.

i'll go though the other bugs i filed and see if JRebel was the cause of them as well.

it may useful to make a note JRebel has this strange behaviour.

mea culpa and apologies for wasting your time.

regards...

Comment by bitec [ 29/May/11 ]

jstrong

great notice about jRebel. I was the person, who experienced the same issue with "Production" stage and could not understand, why so few people experience the same issue... But I use Jrebel as though and this seems to be the reason. I have already met some unexpected behaviour (for virtual folders in GF for example) due to jrebel and it's great to understand, what is the main reason of this strange bug.

have you posted the issue to jrebel team? Could you paste the link about this here?

thanks.

Comment by jstrong [ 30/May/11 ]

RESPONSE FROM JREBEL SUPPORT:

Hello!

JRebel integration always enables the development mode for Mojarra. This is a feature, not a defect.


Anton Arhipov
support@zeroturnaround.com

Comment by bitec [ 30/May/11 ]

Nonsense. This cannot be a feature as some external application (jrebel) constraints the behaviour of my web application although it isn't expected this way at all. At least it should be tuned by jrebel configurations somehow, but this restriction prevents my application from being developed ok and makes me huck the jsf-weld code. I will create the issue in jrebel issue tracker and post the link here.

thanks, jstrong

Comment by jstrong [ 30/May/11 ]

haha

yeah, well i personally don't know why they have done this, but there you go.

i can personally live with this - as we obviously are not using jrebel in production and i know those anoying $%^&*( dev mode warning messages will disapear.

lost a lot of time chasing it up tho - and gave the mojarra devs a serve when they had nothing to do with it

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by Ed Burns [ 15/Jun/11 ]

Sending jsf-test/JAVASERVERFACES-2079/build.xml
Transmitting file data .
Committed revision 9169.

Comment by deepakpn [ 15/Aug/13 ]

Hi,

What is the expected behavior as of Glassfish 3.3.0.
It looks like setting the javax.faces.PROJECT_STAGE to Production in
web.xml has no effect and it still remains to be "Development" if done so.

Glassfish 3.3.0 release notes contains a note on working around a
bug in Mojarra JSF:


When running a JSF application in JSF2 PROJECT_STAGE="Development" mode, you may see the follow warning appear at the bottom of the page: "Form component needs to have a UIForm in its ancestry.".
This issue is caused by a bug in Mojarra JSF, a suggested work-around is to set the JSF2 PROJECT_STAGE="Production" in the web.xml file.

This wouldn't work for me since I'm not able to change the PROJECT_STAGE.
Is there a different work-around for the above Mojarra JSF issue?

Thanks.





[JAVASERVERFACES-2076] Remove dependency on legacy JBoss maven repository Created: 24/May/11  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: build
Affects Version/s: current
Fix Version/s: 2.0.6, 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: aschwart Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As of this morning, the repo at:

http://repository.jboss.org/maven2/

Seems to be down, possibly permanently.

Since Mojarra depends on this repository for javax.inject (and possibly other) artifacts, clean Mojarra builds are no longer succeeding.

Replacing the above repository with:

https://repository.jboss.org/nexus/content/repositories/thirdparty-releases

Fixes the Mojarra build.

See:

http://relation.to/Bloggers/JBossMavenRepositoryChanges

For more info on the repo changes.



 Comments   
Comment by rogerk [ 24/May/11 ]

for the record - here are the changes:

Index: dependencies.xml
===================================================================
— dependencies.xml (revision 9089)
+++ dependencies.xml (working copy)
@@ -83,7 +83,7 @@
<property name="yuicompressor.version" value="2.4.2"/>

<property name="central.maven2" value="http://repo1.maven.org/maven2" />

  • <property name="redhat.maven2" value="http://repository.jboss.org/maven2"/>
    + <property name="redhat.maven2" value="https://repository.jboss.org/nexus/content/repositories/thirdparty-releases"/>
    <!-<property name="maven2.mirror" value="http://mirrors.ibiblio.org/pub/mirrors/maven2"/>->
    <property name="maven2.mirror" value="http://repo.exist.com/maven2/"/>
    <property name="java.net.maven" value="http://download.java.net/maven/1"/>
Comment by rogerk [ 24/May/11 ]

Thanks. Checked into trunk.
Needs to be checked into other locations too.

Comment by rogerk [ 24/May/11 ]

checked into trunk:
Sending common/ant/dependencies.xml
Transmitting file data .
Committed revision 9091.

Checked into MOJARRA_2_1X_ROLLING
Sending common/ant/dependencies.xml
Transmitting file data .
Committed revision 9092.

Check into MOJARRA_2_0X_ROLLING
Sending common/ant/dependencies.xml
Transmitting file data .
Committed revision 9093.

Comment by rogerk [ 27/May/11 ]

Reopen to edit fix versions.

Comment by rogerk [ 27/May/11 ]

fix versions

Comment by rogerk [ 27/May/11 ]

re-closing

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version





[JAVASERVERFACES-2074] UIDebug doesn't check for existing url parameters Created: 21/May/11  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.0.6, 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: gerhard_petracek Assignee: ioss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Text File changebundle_with_test.txt    

 Description   

UIDebug#encodeBegin resolves the current action-url and just adds '?' for its own parameters.
-> if the url already contains parameters, the url contains two '?' in the end which breaks the javascript.



 Comments   
Comment by ioss [ 21/May/11 ]

One-line patch fixing the issue.
Testcase will follow.

Comment by rogerk [ 23/May/11 ]

This change looks good (r=rogerk).
Checkin and closing this issue is contingent on the creation of another change bundle
that includes a test (reattached to this issue).

Comment by ioss [ 23/May/11 ]

Changebundle including tests

Comment by ioss [ 23/May/11 ]

Commited to trunk
Committed revision 9077

Comment by ioss [ 24/May/11 ]

Commited to MOJARRA_2_1X_ROLLING and MOJARRA_2_0X_ROLLING

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version





[JAVASERVERFACES-2067] RI checks context parameters only with lower case "true" Created: 18/May/11  Updated: 11/Feb/14  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.0
Fix Version/s: 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: xj Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-2067-1.txt     Text File changebundle-2067-2.txt     Text File changebundle-2067.txt    
Issue Links:
Related
is related to JAVASERVERFACES-3177 Migrate test for issue 2067 to test/a... Closed

 Description   

This is reported against Mojarra-2.1.0.

In 11.1.3 Application Configuration Parameters of JSF 2.0 specification, it says that context parameters of boolean type should be evaluated with toLowerCase().equals("true"). RI only uses lower case "true" to check, is it correct?



 Comments   
Comment by rogerk [ 19/May/11 ]

Yes I think this ok. I don't think the spec is implying that an implementation has to "literally" use toLowerCase().equals("true"). The fact that Mojarra is set up so as to enforce that the boolean values match either true|false is fine.
The way Mojarra does it is better for performance.
Perhaps there could be a spec clarification on this?

Comment by xj [ 20/May/11 ]

Please let me clarify this issue more clearly. We think the implementation should check value regardless of upper case or lower case.

com.sun.faces.config.WebConfiguration#isValueValid:
----->
if (!ALLOWABLE_BOOLEANS.matcher(value).matches()) {
if (LOGGER.isLoggable(Level.WARNING)) {
LOGGER.log(Level.WARNING,
"jsf.config.webconfig.boolconfig.invalidvalue",
new Object[]

{ value, param.getQualifiedName(), "true|false" }

);
}
return false;
}

return true;
<-----

The above source code will return true if the "value" is "true".
However, ALLOWABLE_BOOLEANS.matcher("True").matches() will give a "false" result. This let the following code select default value.

WebConfiguration#processBooleanParameters
----->
if (alternate != null) {
if (isValueValid(param, strValue))

{ value = Boolean.valueOf(strValue); }

else

{ value = param.getDefaultValue(); }

<-----

Comment by rogerk [ 20/May/11 ]

So - if I am understanding you correctly - you are saying that in web.xml for example, valid values could be:

<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>true</param-value>
</context-param>

or

<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>=True</param-value>
</context-param>

same for "false" or "False",..

If so, what does that buy you? true|false are consistent with java boolean values...

Am I missing somehting here?

Comment by rogerk [ 20/May/11 ]

Never mind - I think I see your point w/r/t the specification.
I'll take a look..

Comment by rogerk [ 23/May/11 ]

Reopening.

Comment by rogerk [ 23/May/11 ]

changes.

Comment by ioss [ 23/May/11 ]

I suggest using:

Pattern.compile("true|false", Pattern.CASE_INSENSITIVE)

to also match for FAlse or truE (as required by the specification)
The testcase should better test for a stranger input like "FalSe" instead of "False".

Comment by rogerk [ 23/May/11 ]

Revised change bundle on the way..

Comment by rogerk [ 23/May/11 ]

Revised change bundle.

Comment by rogerk [ 23/May/11 ]

Revised change bundle (again)...

Comment by ioss [ 23/May/11 ]

r=ioss

Comment by rogerk [ 23/May/11 ]

Committed to trunk:
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Adding jsf-test/JAVASERVERFACES-2067
Adding jsf-test/JAVASERVERFACES-2067/build.xml
Adding jsf-test/JAVASERVERFACES-2067/htmlunit
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com/sun/faces/systest/Issue2067TestCase.java
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/pom.xml
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main/webapp/index.xhtml
Sending jsf-test/build.xml
Transmitting file data ........
Committed revision 9079.

Comment by rogerk [ 23/May/11 ]

Committed. Will commit to 2.1.X branch as well.

Comment by rogerk [ 23/May/11 ]

Committed to MOJARRA_2_1_X_ROLLING branch:
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Adding jsf-test/JAVASERVERFACES-2067
Adding jsf-test/JAVASERVERFACES-2067/build.xml
Adding jsf-test/JAVASERVERFACES-2067/htmlunit
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2067/htmlunit/src/main/java/com/sun/faces/systest/Issue2067TestCase.java
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/pom.xml
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2067/i_jsf_2067/src/main/webapp/index.xhtml
Sending jsf-test/build.xml
Transmitting file data ........
Committed revision 9080.

Change bundle is the same as trunk except for jsf-test/build.xml due to the fact that there were fewer tests.

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing





[JAVASERVERFACES-2066] The tag "th" never be rendered Created: 18/May/11  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.0
Fix Version/s: 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: xj Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-2066.txt     Text File changebundle-2066.txt    

 Description   

This is reported against Mojarra-2.1.0.

The tag "th" never be rendered when specifying true on the attribute "rowHeader" of h:column as the description in VDL. It seems that the TableRenderer implementation below returns false,

boolean isRowHeader = Boolean.TRUE.equals(column.getAttributes().get("rowHeader"));

and there is no chance to enter the following block.

if (isRowHeader) {
writer.startElement("th", column);
writer.writeAttribute("scope", "row", null);
}



 Comments   
Comment by rogerk [ 20/May/11 ]

Changes.

Comment by rogerk [ 20/May/11 ]

Revised change bundle per review from jdlee:
On 5/20/11 3:31 PM, Jason Lee wrote:
> On 5/20/11 2:19 PM, Roger Kitain wrote:
>> http://java.net/jira/browse/JAVASERVERFACES-2066
>>
>
> Looks mostly OK, though I think your assignment could simply be:
>
> isRowHeader = Boolean.valueOf(rowHeaderValue.toString());
>
>
> Also not a big fan of assignments inside conditionals like that, fwiw.
> Makes the code a bit harder to read. Other than that, it looks fine to me.
>

Comment by rogerk [ 20/May/11 ]

Committed to trunk:
Committed revision 9065.

Committed to branch MOJARRA_2_1_X_ROLLING:
Committed revision 9066.

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing





[JAVASERVERFACES-2065] javax.faces.render.RenderKit#getClientBehaviorRendererTypes() is not implemented Created: 18/May/11  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.0
Fix Version/s: 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: xj Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-2065.txt     Text File changebundle-2065.txt    
Tags: licbug

 Description   

This is reported against Mojarra-2.1.0.

Since current com.sun.faces.renderkit.RenderKitImpl does not implement the method getClientBehaviorRendererTypes(), "UnsupportedOperationException: The default implementation must override this method" will be thrown when calling this method.



 Comments   
Comment by rogerk [ 26/May/11 ]

Changes.

Comment by rogerk [ 27/May/11 ]


Revision 2 - take into account NPE.

Comment by rogerk [ 27/May/11 ]

Committed to trunk:
Sending jsf-ri/src/main/java/com/sun/faces/renderkit/RenderKitImpl.java
Adding jsf-test/JAVASERVERFACES-2065
Adding jsf-test/JAVASERVERFACES-2065/build.xml
Adding jsf-test/JAVASERVERFACES-2065/htmlunit
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com/sun/faces/systest/Issue2065TestCase.java
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/pom.xml
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/java
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/java/test
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/java/test/Bean.java
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/java/test/TestBehaviorRenderer.java
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/index.xhtml
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/resources
Sending jsf-test/build.xml
Transmitting file data ...........
Committed revision 9109.

Committed to MOJARRA_2_1X_ROLLING branch:

Sending jsf-ri/src/main/java/com/sun/faces/renderkit/RenderKitImpl.java
Adding jsf-test/JAVASERVERFACES-2065
Adding jsf-test/JAVASERVERFACES-2065/build.xml
Adding jsf-test/JAVASERVERFACES-2065/htmlunit
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/java/com/sun/faces/systest/Issue2065TestCase.java
Adding jsf-test/JAVASERVERFACES-2065/htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/pom.xml
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/java
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/java/test
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/java/test/Bean.java
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/java/test/TestBehaviorRenderer.java
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/index.xhtml
Adding jsf-test/JAVASERVERFACES-2065/i_jsf_2065/src/main/webapp/resources
Sending jsf-test/build.xml
Transmitting file data ...........
Committed revision 9110.

Comment by rogerk [ 27/May/11 ]

Need to edit in fixed versions

Comment by rogerk [ 27/May/11 ]

specify fix versions

Comment by rogerk [ 27/May/11 ]

re-closing.





[JAVASERVERFACES-2064] DemuxCompositeELResolver optimization not leveraged Created: 18/May/11  Updated: 20/Feb/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.0.next, 2.1.2, 2.2.0-m01

Type: Bug Priority: Minor
Reporter: aschwart Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-2064.txt     Text File ELUtils.java.patch    

 Description   

The DemuxCompositeELResolver optimization that was added in Mojarra 1.2.15
was not correctly ported forward to the 2.x releases. The
DemuxCompositeELResolver is present in 2.x. However, the corresponding
changes in ELUtils.java are missing.

As a result, all resolvers are added to both the root and property resolver
chains in DemuxCompositeELResolver, thus losing any optimization.



 Comments   
Comment by aschwart [ 18/May/11 ]

Attached ELUtils.java.patch calls addRootELResolver()/addPropertyELResolver() instead of add() as appropriate.

Comment by aschwart [ 18/May/11 ]

BTW, the attached patch is against 2_0X_ROLLING, since that happens to be the branch that I am on.

Comment by rogerk [ 18/May/11 ]

r=rogerk

Comment by rogerk [ 26/May/11 ]

Changes inline with provided patch.

Comment by rogerk [ 26/May/11 ]

Committed to trunk:

Sending jsf-ri/src/main/java/com/sun/faces/el/ELUtils.java
Transmitting file data .
Committed revision 9107.

Committed to MOJARRA_2_1X_ROLLING branch:

Sending jsf-ri/src/main/java/com/sun/faces/el/ELUtils.java
Transmitting file data .
Committed revision 9108.

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing





[JAVASERVERFACES-2061] bv detection is incomplete Created: 14/May/11  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.0.6, 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: gerhard_petracek Assignee: ioss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Attachments: Text File changebundle.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-2088 Mojarra 2.2.0 HEAD (rev. 9111) startu... Closed

 Description   

mojarra doesn't impl. 3.5.6.1 of the spec. correctly.

"... If Bean Validation is present in the runtime environment, the system must ensure that the standard validator with validator-id javax.faces.Bean is added ..."

mojarra just checks if the api is present. however, bv consists of api and impl. the bootstrapping will fail if the api is in the classpath and the impl is missing. mojarra doesn't check such a failed bootstrapping process (see Validation.buildDefaultValidatorFactory().getValidator()).



 Comments   
Comment by ioss [ 16/May/11 ]

Changebundle checking for the availability of a ValidatorFactory in ApplicationConfigProcessor.
(Smoketest passed)

Requesting Review

Comment by ioss [ 16/May/11 ]

This Issue came up, when using the archetypes at http://myfaces.apache.org.
For how to reproduce see: https://issues.apache.org/jira/browse/EXTCDI-178

As this is an Apache archetype repository and 2.1.x is not considered to be Tomcat ready, we should consider to also backport this into the 2.0.x.

Comment by rogerk [ 16/May/11 ]

r=rogerk

Comment by ioss [ 16/May/11 ]

Revision: 9043
Author: ioss
Date: 2011-05-16 21:16
Message: Fix that disables BeanValidation, if no implementation is available.
Issue #JAVASERVERFACES-2061 - bv detection is incomplete

Comment by ioss [ 16/May/11 ]

Backported to 2_0X_ROLLING and 2_1X_ROLLING

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing

Comment by ioss [ 30/May/11 ]

JAVASERVERFACES-2088 needs to be fixed first

Comment by ioss [ 02/Jun/11 ]

#2088 fixed

Comment by rogerk [ 03/Jun/11 ]

Fix version

Comment by rogerk [ 03/Jun/11 ]

Fix version

Comment by rogerk [ 03/Jun/11 ]

Fix version





[JAVASERVERFACES-2058] In partial state saving check that StateContext.startTrackViewModifications() is called from FaceletViewHandlingStrategy.restoreView if needed Created: 11/May/11  Updated: 20/Feb/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: gabfest Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-2058.txt     Text File Issue2058_for_2_1X_ROLLING_branch-v2.patch     Text File Issue2058_for_2_1X_ROLLING_branch-v3.patch     Text File Issue2058_for_2_1X_ROLLING_branch.patch     Text File mojarra-2058-2.1.x.patch    

 Description   

StateContext.startTrackViewModifications() is where the listener is added which state saves the structure of components that are added or removed. It is called from FaceletViewHandlingStrategy.buildView, here's the stack when you are running adf faces on top of the RI.

(StateContext.java:176) com.sun.faces.context.StateContext.startTrackViewModifications
(FaceletViewHandlingStrategy.java:1049) com.sun.faces.application.view.FaceletViewHandlingStrategy.doPostBuildActions
(FaceletViewHandlingStrategy.java:745) com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView
(StateManagementStrategyImpl.java:228) com.sun.faces.application.view.StateManagementStrategyImpl.restoreView
(StateManagerImpl.java:639) org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView
(ViewHandlingStrategy.java:123) com.sun.faces.application.view.ViewHandlingStrategy.restoreView
(FaceletViewHandlingStrategy.java:448) com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView
(MultiViewHandler.java:148) com.sun.faces.application.view.MultiViewHandler.restoreView
(ViewHandlerWrapper.java:288) javax.faces.application.ViewHandlerWrapper.restoreView
(ViewHandlerImpl.java:242) org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView
(LifecycleImpl.java:689) oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._restoreView
(LifecycleImpl.java:341) oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase
(LifecycleImpl.java:204) oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute

However in adf faces we have something called view root caching, when it's enabled we cache the component tree so that we don't have to call buildView. However this means startTrackViewModifications is also not called, and we lose any component adds/removes that happen before render response, when startTrackViewModifications will be called again.

Can you move calling startTrackViewModifications to FaceletViewHandlingStrategy.restoreView, or at least check that it's been called and if not call it?



 Comments   
Comment by aschwart [ 09/Jun/11 ]

The attached patch does the following:

1. Changes StateContext.startTrackViewModifications() to allow the FacesContext and UIViewRoot to be passed in.

Needed to pass the UIViewRoot in so that we can call this from restoreView(), before FacesContext.setViewRoot() has been called. Figured it wouldn't hurt to pass the FacesContext in while we are at it to avoid the call to getCurrentInstance().

2. Introduces a call to StateContext.startTrackViewModifications() from FacletViewHandlingStrategy.restoreView()

This addresses the Trinidad view root caching case where buildView() is not called.

3. Updated the two other calls to startTrackViewModifications() to pass in the new arguments.

These calls were in:

  • FaceletViewHandlingStrategy.doPostBuildActions().
  • TestStateContext.testAddComponent()

Note that I have not yet run the Mojarra tests against this. Having problems getting the tests to pass (even without this patch).

Comment by rogerk [ 09/Jun/11 ]

There is a problem with one of the dynamic component tests with this patch.

[junit] Running com.sun.faces.systest.dynamic1757.Issue1757TestCase
[junit] Testsuite: com.sun.faces.systest.dynamic1757.Issue1757TestCase
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 1.871 sec
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 1.871 sec
[junit]
[junit] Testcase: testDynamicComponents took 1.633 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at com.sun.faces.systest.dynamic1757.Issue1757TestCase.testDynamicComponents(Issue1757TestCase.java:104)
[junit] at com.sun.faces.htmlunit.HtmlUnitFacesTestCase.runTest(HtmlUnitFacesTestCase.java:616)

This test relates to http://java.net/jira/browse/JAVASERVERFACES-1757
(and also relates to the complex 1826 issue).

The failing test does the following:

<test:testcomponent>
<h:outputText value="Manually added child<br/>" escape="false"/>
</test:testcomponent>

The custom component (Java class) creates a new outputText component (with value "Dynamically added child") and adds it as a child. So when the page is rendered, it has two children in the following order:
Manually Added Child
Dynamically Added Child

On postback, the ordering is expected to be the same, however, on postback,
the ordering is switched:
Dynamically Added Child
Manually Added Child
so the test fails.

Comment by rogerk [ 09/Jun/11 ]

I should also add that the custom component adds the dynamic child during prerenderviewevent processing (it listens for prerenderviewevent and performs this processing)..

Comment by rogerk [ 09/Jun/11 ]

I've verified that the extra statecontext.startTrackViewModifications call in FaceletViewHandlingStrategy causes this. I don't know much more than that right now.

Comment by gabfest [ 14/Jul/11 ]

The problem with the patch was occurring when using facelets and full state saving.

It looks like in partial state saving build view is called before restore view, so starting to track the view modifications in restoreView is fine because the view has already been built.

In full state saving it looks like restoreView is called before buildView, so if you start tracking the view modifications in restoreView you treat the components in the base view as being view modifications.

Fix is to only start tracking the view modifications in restoreView if this is partial state saving. I'm not sure why you would want to track modifications in full state saving, possibly doPostBuildActions should also be checking if this is partial state saving?

Comment by gabfest [ 14/Jul/11 ]

new patch uploaded, can you try it?

Comment by rogerk [ 18/Jul/11 ]

With this patch, one of the cactus tests fails:

run.cactus.test:
[junit] Running com.sun.faces.context.TestStateContext
[junit] Testsuite: com.sun.faces.context.TestStateContext
[junit] Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 1.807 sec
[junit] Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 1.807 sec
[junit]
[junit] Testcase: testGetStateContext took 1.211 sec
[junit] Testcase: testPartialStateSaving took 0.287 sec
[junit] Testcase: testAddComponent took 0.229 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at com.sun.faces.context.TestStateContext.testAddComponent(TestStateContext.java:157)
[junit] at org.apache.cactus.internal.AbstractCactusTestCase.runBareServer(AbstractCactusTestCase.java:153)
[junit] at org.apache.cactus.internal.server.AbstractWebTestCaller.doTest(AbstractWebTestCaller.java:119)
[junit] at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest_aroundBody0(AbstractWebTestController.java:93)
[junit] at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest_aroundBody1$advice(AbstractWebTestController.java:224)
[junit] at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest(AbstractWebTestController.java)
[junit] at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2(ServletTestRedirector.java:101)
[junit] at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3$advice(ServletTestRedirector.java:224)
[junit] at org.apache.cactus.server.ServletTestRedirector.doPost(ServletTestRedirector.java)
[junit] at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0(ServletTestRedirector.java:72)
[junit] at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1$advice(ServletTestRedirector.java:224)
[junit] at org.apache.cactus.server.ServletTestRedirector.doGet(ServletTestRedirector.java)
[junit] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
[junit] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[junit] at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1562)
[junit] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:286)
[junit] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
[junit] at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
[junit] at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
[junit] at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
[junit] at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
[junit] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
[junit] at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:345)
[junit] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
[junit] at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
[junit] at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:162)
[junit] at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:160)
[junit] at org.glassfish.grizzly.filterchain.ExecutorResolver$3.execute(ExecutorResolver.java:95)
[junit] at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:444)
[junit] at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:364)
[junit] at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:290)
[junit] at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:133)
[junit] at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:76)
[junit] at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:63)
[junit] at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:823)
[junit] at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
[junit] at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:116)
[junit] at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$000(WorkerThreadIOStrategy.java:55)
[junit] at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$1.run(WorkerThreadIOStrategy.java:98)
[junit] at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508)
[junit] at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488)
[junit] at java.lang.Thread.run(Thread.java:680)

It is a simple test that does the following:

public void testAddComponent()

{ StateContext stateContext = StateContext.getStateContext(getFacesContext()); FacesContext ctx = getFacesContext(); UIViewRoot viewRoot = Util.getViewHandler(ctx).createView(getFacesContext(), null); stateContext.startTrackViewModifications(ctx, viewRoot); UIOutput output = new UIOutput(); output.setId("foo"); viewRoot.getChildren().add(output); Map<String,ComponentStruct> added = stateContext.getDynamicAdds(); assertTrue(added.size() > 0); }
Comment by rogerk [ 18/Jul/11 ]

Upon first examination it appears that the StateContext addRemoveListener is never called...

Comment by gabfest [ 18/Jul/11 ]

I've attached a new patch, Issue2058_for_2_1X_ROLLING_branch-v2.patch

Previously, in StateContext.startTrackViewModifications() we were getting the view root by calling context.getViewRoot(). Now we are passing the view root into startTrackViewModifications().

Therefore testAddComponent has been changed, instead of creating the view root again with this code
Util.getViewHandler(getFacesContext()).createView(getFacesContext(), null);

We're now calling ctx.getViewRoot() (the view root has already been set in the setUp() method), and passing that into startTrackViewModifications.

Comment by gabfest [ 19/Jul/11 ]

I just realized I had System.out statements in StateContext in my previous patch, here's a new one with those removed

Comment by rogerk [ 25/Jul/11 ]

change bundle based on patch.

Comment by rogerk [ 25/Jul/11 ]

Committed to trunk:
Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Sending jsf-ri/src/main/java/com/sun/faces/context/StateContext.java
Sending jsf-ri/test/com/sun/faces/context/TestStateContext.java
Transmitting file data ...
Committed revision 9216.

Comment by rogerk [ 25/Jul/11 ]

Checked into MOJARRA_2_1X_ROLLING:
Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Sending jsf-ri/src/main/java/com/sun/faces/context/StateContext.java
Sending jsf-ri/test/com/sun/faces/context/TestStateContext.java
Transmitting file data ...
Committed revision 9217.

Comment by rogerk [ 08/Sep/11 ]

fix versions

Comment by rogerk [ 08/Sep/11 ]

fix versions

Comment by rogerk [ 08/Sep/11 ]

fix versions





[JAVASERVERFACES-2055] Ajax insert does not handle table markup Created: 06/May/11  Updated: 20/Feb/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: ajax
Affects Version/s: 2.1.1
Fix Version/s: 2.0.6, 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: tedgoddard Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ajaxInsertDelete.xhtml     Text File changebundle-2055.txt     Text File changebundle-2055.txt     Java Source File InsertDeleteBean.java     Text File insertfix.patch     Text File jsf.js.patch    
Status Whiteboard:

size_small importance_large includes_patch


 Description   

When an Ajax insert operation is generated via

partialWriter.startInsertAfter(id);

containing table-related markup, such as:

<insert><after id="j_idt6:dataTable:5"><![CDATA[<tr class="iceDatTblRow1" id="j_idt6:dataTable:6"><td class="iceDatTblCol1"><a class="iceCmdLnk" href="javascript:;" id="j_idt6:dataTable:6:j_idt8" onblur="setFocus('');" onclick="var form=formOf(this);form['j_idt6:j_idcl'].value='j_idt6:dataTable:6:j_idt8';iceSubmit(form,this,event);form['j_idt6:j_idcl'].value='';return false;" onfocus="setFocus(this.id);">+/-</a></td><td class="iceDatTblCol2"><span class="iceOutTxt" id="j_idt6:dataTable:6:j_idt12">v1.0</span></td></tr>]]></after></insert>

the doInsert() function is not able to process this due to the browser "fixing" the temporary markup by adding ancestor <table> tags.



 Comments   
Comment by tedgoddard [ 06/May/11 ]

The doInsert() function can be modified as follows to handle table markup.

var tablePattern = new RegExp("<
s*(td|th|tr|tbody|thead|tfoot)", "i");

/**

  • Insert a node specified by the element.
  • @param element
  • @ignore
    */
    var doInsert = function doInsert(element) {
    var scripts = [];
    var target = $(element.firstChild.getAttribute('id'));
    var parent = target.parentNode;
    var html = element.firstChild.firstChild.nodeValue;
    var isInTable = tablePattern.test(html);

if (!isAutoExec())

{ // Get the scripts from the text scripts = stripScripts(html); // Remove scripts from text html = html.replace(/<script[^>]*>([\S\s]*?)<\/script>/igm,""); }

var tempElement = document.createElement('div');
var newElement = null;
if (isInTable) {
tempElement.innerHTML = '<table>' + html + '</table>';
newElement = tempElement.firstChild;
//some browsers will also create intermediary elements such as table>tbody>tr>td
//test for presence of id on the new element since we do not have it directly
while ((null !== newElement) && ("" == newElement.id))

{ newElement = newElement.firstChild; }

} else

{ tempElement.innerHTML = html; newElement = tempElement.firstChild; }

if (element.firstChild.nodeName === 'after')

{ // Get the next in the list, to insert before target = target.nextSibling; }

// otherwise, this is a 'before' element
if (!!tempElement.innerHTML)

{ // check if only scripts were inserted - if so, do nothing here parent.insertBefore(newElement, target); }

runScripts(scripts);
deleteNode(tempElement);
};

Note the use of the previously declared regular expression which may be a useful optimization in other parts of jsf.js.

Comment by rogerk [ 16/May/11 ]

Hi Ted -

Can you attach a test case (webapp) to this issue?

Comment by tedgoddard [ 17/May/11 ]

Modified mojarra-2.1.1-FCS-source/jsf-ri/systest/src/com/sun/faces/systest/model/ajax files to exercise insert/delete on table markup as well as h2/hr.

Comment by rogerk [ 27/May/11 ]

Hello Ted -

Trying to get your patch to work. This is how I think the test app is supposed to work (correct me if I am wrong).. "Add Before" action adds an h2 BEFORE above the table. It also adds a new table row with contents "BEFORE" above TABLE CENTER.
Now the "Remove Before" action (I think) is supposed to delete both the h2 BEFORE and that new table row BEFORE. However, only h2 BEFORE is removed. The partial response for the "Remove Before" action is looking for an id of "trbefore" but it does not exist in the markup. Any chance you can actually make the changes in jsf.js and attach a patch file? Perhaps I applied your changes incorrectly.

Comment by tedgoddard [ 27/May/11 ]

Patch file tested against mojarra-2.1.1-FCS-source via patch jsf.js insertfix.patch.

Comment by rogerk [ 28/May/11 ]

Hey Ted -

Still no luck.. I could not apply your patch with the "patch" command so I did it manually. I still see the header elements removed, but the BEFORE and AFTER text is still in the table (because there is no "trbefore" and "trafter" element ids to satisfy the partial response:

<?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><delete id="h2after"></delete><delete id="trafter"></delete></changes></partial-response>

You should be able to create a patch file from doing svn diff:

svn diff jsf.js > jsf.js.patch

Comment by tedgoddard [ 30/May/11 ]

Should I generate the patch against the trunk or a specific branch?

Comment by rogerk [ 30/May/11 ]

trunk

Comment by tedgoddard [ 30/May/11 ]

The current trunk build does not run on Tomcat 7:

SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener
java.lang.NoClassDefFoundError: javax/validation/ValidationException
at com.sun.faces.config.ConfigManager.<clinit>(ConfigManager.java:262)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:164)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4723)
at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226)
at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassNotFoundException: javax.validation.ValidationException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)

(This should probably be a separate JIRA, but I'll just note it here.)

Comment by tedgoddard [ 30/May/11 ]

patch generated via svn

Comment by tedgoddard [ 30/May/11 ]

Hi Roger,

Latest patch file was generated with svn diff and is attached. Code change was verified using Google Chrome and Tomcat 7 (modified jsf-ri/src/main/java/com/sun/faces/config/processor/ApplicationConfigProcessor.java to comment out the code with the ValidationException dependency).

Comment by rogerk [ 31/May/11 ]

Changes from patch.

Comment by rogerk [ 31/May/11 ]

Revised for tablePattern var (lcoal for now).

Comment by rogerk [ 31/May/11 ]

Fix versions

Comment by rogerk [ 31/May/11 ]

Committed to trunk:
Sending jsf-api/src/main/resources/jsf.js
Sending jsf-ri/systest/src/com/sun/faces/ajax/AjaxInsertDeleteTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/systest/model/ajax/InsertDeleteBean.java
Sending jsf-ri/systest/web/ajax/ajaxInsertDelete.xhtml
Transmitting file data ....
Committed revision 9114.

Committed to MOJARRA_2_1X_ROLLING:
Sending jsf-api/src/main/resources/jsf.js
Sending jsf-ri/systest/src/com/sun/faces/ajax/AjaxInsertDeleteTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/systest/model/ajax/InsertDeleteBean.java
Sending jsf-ri/systest/web/ajax/ajaxInsertDelete.xhtml
Transmitting file data ....
Committed revision 9115.

Commited to MOJARRA_2_0X_ROLLING:
Sending jsf-api/src/main/resources/jsf.js
Sending jsf-ri/systest/src/com/sun/faces/ajax/AjaxInsertDeleteTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/systest/model/ajax/InsertDeleteBean.java
Sending jsf-ri/systest/web/ajax/ajaxInsertDelete.xhtml
Transmitting file data ....
Committed revision 9116.

Comment by rogerk [ 04/Jun/11 ]

fix version

Comment by rogerk [ 04/Jun/11 ]

fix version

Comment by rogerk [ 04/Jun/11 ]

fix version





[JAVASERVERFACES-2052] NPE in ZipDirectoryEntryScanner Created: 05/May/11  Updated: 26/Jun/12  Resolved: 11/Jun/11

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.6, 2.1.2

Type: Bug Priority: Trivial
Reporter: benoitf Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 10 minutes
Time Spent: Not Specified
Original Estimate: 10 minutes
Environment:

2.0.x and 2.1.x


Attachments: Text File changebundle-2052.txt    
Status Whiteboard:

size_small importance_medium jsf_2_1_2 jsf_2_0_x


 Description   

In the com.sun.faces.application.resource.ZipDirectoryEntryScanner constructor, there is the following code :

068. Set<String> webInfLibJars = extContext.getResourcePaths("/WEB-INF/lib");
[...]
073. for (String cur : webInfLibJars) {

It happens that /WEB-INF/lib folder is not mandatory and then the webInfLibJars may be null.
Thus, the for loop is throwing NPE (I've tested on JOnAS Application server)

A check should be added :
if (webInfLibJars != null) {
for (String cur : webInfLibJars) {

The problem is present in both 2.0.x and 2.1.x
http://java.net/projects/mojarra/sources/svn/content/branches/MOJARRA_2_0X_ROLLING/jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java?rev=9007
http://java.net/projects/mojarra/sources/svn/content/branches/MOJARRA_2_1X_ROLLING/jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java?rev=9007



 Comments   
Comment by rogerk [ 05/May/11 ]

NPE's are never good. Thanks for pointing this out.
Targeting this for trunk, but also 2.1.x and 2.0.x.

Comment by rogerk [ 05/May/11 ]

Although this is a simple NPE check, can you provide a simple test case that exercises the NPE?

Comment by rogerk [ 09/May/11 ]

Changes including test case.

Comment by rogerk [ 09/May/11 ]

Checked in:

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Adding jsf-test/JAVASERVERFACES-2052
Adding jsf-test/JAVASERVERFACES-2052/JAVASERVERFACES-2052.iml
Adding jsf-test/JAVASERVERFACES-2052/build.xml
Adding jsf-test/JAVASERVERFACES-2052/htmlunit
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src/main/java/com/sun/faces/systest/Issue2052TestCase.java
Adding jsf-test/JAVASERVERFACES-2052/htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/pom.xml
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/java
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/java/test
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/java/test/ResourceBean.java
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/webapp/index.xhtml
Adding jsf-test/JAVASERVERFACES-2052/i_jsf_2052/src/main/webapp/resources
Sending jsf-test/build.xml
Transmitting file data ...........
Committed revision 9017.

Comment by rogerk [ 09/May/11 ]

Checked into trunk.
Will also check into 2.0.x and 2.1.x

Comment by rogerk [ 09/May/11 ]

Backported to 2.0.X_ROLLING and 2.1.X_ROLLING branches which means this fix will be available in 2.0.5-b03 and 2.1.2 releases.

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing

Comment by rogerk [ 03/Jun/11 ]

reopen for fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version





[JAVASERVERFACES-2038] UIRepeat exposes wrong iteration status for broadcasted events when using begin attribute Created: 20/Apr/11  Updated: 20/Apr/11  Resolved: 20/Apr/11

Status: Closed
Project: javaserverfaces
Component/s: facelets
Affects Version/s: trunk
Fix Version/s: 2.1.2

Type: Bug Priority: Minor
Reporter: Mathias Werlitz Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

size_small importance_medium includes_patch


Attachments: Zip Archive repeatStatus.zip    
Status Whiteboard:

size_small importance_medium includes_patch


 Description   

When using the the begin attribute on UIRepeat the value of IterationStatus.begin exposed as the varStatus when a event is broadcasted by UIRepeat is wrong.

The problem is in the method UIRepeat.boadcast line 892 (Mojarra 2.1.1).
It reads:

int b = ((end != null) ? end : 0);

but should be

int b = ((begin != null) ? begin : 0);



 Comments   
Comment by Mathias Werlitz [ 20/Apr/11 ]

Attached an example that hows the wrong value when a event (ActionEvent) is triggered.

Comment by Ed Burns [ 20/Apr/11 ]

I have applied your fix, converted your excellent reproducer into a regression test, and am now running the automated tests.
If it passes, I'll commit. Thanks.

Comment by Ed Burns [ 20/Apr/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java
Sending jsf-test/JAVASERVERFACES-1655/build.xml
Adding jsf-test/JAVASERVERFACES-2038
Adding jsf-test/JAVASERVERFACES-2038/build.xml
Adding jsf-test/JAVASERVERFACES-2038/htmlunit
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src/main/java/com/sun/faces/systest/Issue2038TestCase.java
Adding jsf-test/JAVASERVERFACES-2038/htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/pom.xml
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/java
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/java/test
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/java/test/TestController.java
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/java/test/TestItem.java
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp/index.xhtml
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp/resources
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp/resources/myCC
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp/resources/myCC/layout.xhtml
Adding jsf-test/JAVASERVERFACES-2038/i_jsf_2038/src/main/webapp/resources/myCC/output.xhtml
Sending jsf-test/build.xml
Transmitting file data ..............
Committed revision 8996.

ONce hudson shows clear, I'll close it.

Comment by Ed Burns [ 20/Apr/11 ]

Thanks for submitting the patch.





[JAVASERVERFACES-2029] Annoying and incorrect complaints about multiple applications Created: 13/Apr/11  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.1.2, 2.2.0-m01

Type: Improvement Priority: Major
Reporter: ancoron Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File multiple-factory-manager.patch    

 Description   

Due to a patch introduced for fixing GLASSFISH-15809 we currently now face the issue that almost everything that calls something like 'FactoryFinder.getFactory(...)' results in the following warning in the logs:

Multiple JSF Applications found on same ClassLoader. Unable to safely determine which FactoryManager instance to use. Defaulting to first match.

This warning, however, is not correct as the warning also appears if only one instance has been found and the code does not consider the first as the warning says, but the very last it has found inside the factoryMap. This can be easily reproduced by creating a web application with the prettyfaces library, as they introduce a ServletRequestListener that always asks for the current JSF application, which triggers this warning at almost every request and therefore flooding the logs heavily.

Therefore I've made a simple patch (multiple-factory-manager.patch - against trunk) to fix this issue and to bring the code in sync with the message.



 Comments   
Comment by Ed Burns [ 14/Apr/11 ]

Thanks. This patch looks fine. I have applied it and am running the automated test suite. If all clears, I'll commit.

Comment by Ed Burns [ 14/Apr/11 ]

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Transmitting file data .
Committed revision 8988.

Committed on trunk

Comment by Ed Burns [ 14/Apr/11 ]

Committed on 2.1 branch

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Transmitting file data .
Committed revision 8989.





[JAVASERVERFACES-2021] ConfigManager swallows vital information from ConfigurationException Created: 05/Apr/11  Updated: 20/Feb/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: configuration
Affects Version/s: current
Fix Version/s: 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: Hanspeter Duennenberger Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ConfigManager.patch     Zip Archive myApp.zip    
Status Whiteboard:

size_small importance_small jsf_2_1_2


 Description   

In case e.g. a custom NavigationHandler gets the wrong type of delegate passed in, we get a ConfigurationException like this:

com.sun.faces.config.ConfigurationException:
Source Document: jndi:/localhost/csJsfSample/WEB-INF/faces-config.xml
Cause: Unable to create a new instance of 'com.csg.jsfcatalog.nav.GuidesNavigationHandler': java.lang.IllegalArgumentException: argument type mismatch

Of course now it's clear that this NavigationHandler must implement ConfigurableNavigationHandler in JSF 2.0.

The problem is, that in ConfigManager.initialize() line 378-379 the caught ConfigurationException is unwinded and repackaged into a new ConfigurationExcception but without the vital information from the original ConfigurationException:

378 Throwable t = unwind(e);
379 throw new ConfigurationException("CONFIGURATION FAILED! " + t.getMessage(), t);

Probably it would be better to only wrap non-ConfigurationException and rethrow the caught ConfigurationException or new created ConfigurationException wrapping the complete caught exception.
e.g. (see also attached patch file)

} catch (Exception e) {
// clear out any configured factories
releaseFactories();
Throwable t = e;
if (!(e instanceof ConfigurationException))

{ t = new ConfigurationException("CONFIGURATION FAILED! " + t.getMessage(), t); }

throw (ConfigurationException)t;
} finally {

There is a log statement to log the originial exception (line 373-377) - however, almost nobody ever activates INFO level for the JSF CONFIG logger ... and in case of an exception it's bad to not log the original exception. At least the log with level error should have a hint to activate INFO level on CONFIG logger to get the real cause ... or change this handling as hinted above.



 Comments   
Comment by rogerk [ 02/May/11 ]

triage.
Thanks for the patch. Will take a look.

Comment by rogerk [ 09/May/11 ]

Although this issue seems like it should be straightforward, I cannot seem to reproduce it.
Do you have a small test case that reproduces this issue?

Comment by Hanspeter Duennenberger [ 09/May/11 ]

Hi Roger,

in our case the problem happened having multiple NavigationHandler and one of them did not extend from ConfigurableNavigationHandler. Now in case the NavigationHandler not extending ConfigurableNavigationHandler gets a ConfigurableNavigationHandler injected, it will fail during JSF system startup (ConfigManager.initialize()).

regards
Hanspeter

Comment by rogerk [ 11/May/11 ]

Can you attach the code for your NavigationHandler(s) ?

Thanks.

Comment by Hanspeter Duennenberger [ 12/May/11 ]

Hi Roger.
I stole some time to do a reproducer - see the minimal setup in myApp.zip - it's a maven based modularized JSF webapp setup. It only has an index.xhtml and two impls of NavigationHandler - one extending ConfigurableNavigationHandler, one extending NavigationHandler.

As I wrote before, the original exception is logged with level INFO (ConfigManager line 373-377) - and if that is logged the developer gets the needed information.

Example:
INFO: Unsanitized stacktrace from failed start...
com.sun.faces.config.ConfigurationException:
Source Document: jndi:/localhost/myWeb/WEB-INF/faces-config.xml
Cause: Unable to create a new instance of 'my.pack.MyConfigurableNavigationHandler': java.lang.IllegalArgumentException: argument type mismatch
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:293) ....

However, if this INFO log-level is not activated, then the re-thrown exception as of Configmanager line 379 does not contain the vital information of the error cause, because the unwind (line 378) just takes the inner most cause. The result is the following stacktrace:

SCHWERWIEGEND: Critical error during deployment:
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! argument type mismatch
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:379)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:225)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:519)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:263)
at com.sun.faces.config.processor.ApplicationConfigProcessor.setNavigationHandler(ApplicationConfigProcessor.java:477)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:289)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:116)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:222)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:360)
... 16 more

Maybe the simplest fix would be to just remove the "Throwable t = unwind(e);"
I mean, in the end still a ConfigurationException is thrown - whythe hassle to unwind and swallow vital information? Just remove ConfigManager line 373-378 and throw the caught Exception as the new ConfigurationException in line 379.

regards
Hanspeter

Comment by rogerk [ 13/May/11 ]

Target

Comment by rogerk [ 13/May/11 ]

Committed to trunk
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigManager.java
Transmitting file data .
Committed revision 9037.

Need to commit to MOJARRA_2_1X_ROLLING branch for 2.1.2 release.

Comment by rogerk [ 16/May/11 ]

Committed to 2_1_X branch:

Sending ConfigManager.java
Transmitting file data .
Committed revision 9038.

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing





[JAVASERVERFACES-1988] CompositeComponentTagHandler.createComponent is not thread safe Created: 14/Mar/11  Updated: 26/Jun/12  Resolved: 24/Oct/11

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.4
Fix Version/s: 2.0.6, 2.0.7, 2.1.2, 2.1.4, 2.1.5, 2.2.0-m01

Type: Bug Priority: Major
Reporter: alexschmidt Assignee: rogerk
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 1988.patch     Zip Archive 20111021-i_mojarra_1988-patches.zip     Text File changebundle-1988-2.0.X.branch.txt     Text File changebundle-1988.txt     Text File changebundle.txt    
Status Whiteboard:

size_medium importance_medium


 Description   

Using jmeter to simulate many client request I got the following exception:

Caused by: java.lang.ArrayIndexOutOfBoundsException: 7
at java.util.ArrayList.add(ArrayList.java:352)
at javax.faces.component.ComponentStateHelper.add(ComponentStateHelper.java:220)
at javax.faces.component.UIComponentBase$AttributesMap.put(UIComponentBase.java:2290)
at javax.faces.component.UIComponentBase$AttributesMap.put(UIComponentBase.java:2151)
at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler$CompositeComponentRule$LiteralAttributeMetadata.applyMetadata(CompositeComponentTagHandler.java:564)
at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.setAttributes(CompositeComponentTagHandler.java:228)
at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.applyNextHandler(CompositeComponentTagHandler.java:181)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
... 15 more

First I verified that all client threads use distinct values/instances
of FacesContext, HTTPSession, ViewRoot.
But there was a single UIComponent concurrently used in multiple ViewRoots.

Debugging of all threads gave me the following hint:
CompositeComponentTagHandler.createComponent is not thread safe and returned the same object instance for different ViewRoots (member variable cc is accessed without synchronized block)



 Comments   
Comment by rogerk [ 14/Mar/11 ]

triage

Comment by Mathias Werlitz [ 29/Apr/11 ]

I can reproduce the same error. It also applies to versions 2.1.0 and 2.1.1.

This is an absolute critical BLOCKER issue. It makes composite components completly unusable when concurrent request are processed by the server.

The point is TagHandler instances must be implemented in a thread safe manner because only one instance exists for a tag in a Facelets view.
Instead the member variable "cc" of CompositeComponentTagHandler holds the instance of the composite component (UINamingContainer) for a concrete view that participates in the full request lifecycle. The state of this component changes during the request. Concurrent threads (requests) will either overwrite the component instance or mess up the attributes/state within the component.

From my point of view synchronizing will not help in this case, because lifecycle is controlled outside of the tag handler and the component instance is not private as it will be used/accessed outside of the tag handler. It is simply forbidden to store the component reference as a tag handler member variable. The tag handler may only store fixed data within itself that does not change at all.

Comment by Mathias Werlitz [ 02/May/11 ]

We use the following options, but this is not really important:

javax.faces.PROJECT_STAGE = Production
javax.faces.FACELETS_REFRESH_PERIOD = -1

Comment by Mathias Werlitz [ 02/May/11 ]

I attached a possible patch for this serious issue. It removes the member variable "cc" and will undo the bugfix (commit 8596) for JAVASERVERFACES-1696. The mentioned issue of JAVASERVERFACES-1696 does seem to be fixed with my patch as well.

Comment by rogerk [ 02/May/11 ]

Thanks for the patch. I'll take a look as soon as I get some cycles.
We'll have to run your patch through our extensive automated test suite
for any regressions/problems..

Comment by Mathias Werlitz [ 25/May/11 ]

Any news on this one?
This is an highly critical issue as it prevents to use Mojarra in production.

Comment by rogerk [ 25/May/11 ]

Changes corresponding to provided patch.

Comment by rogerk [ 25/May/11 ]

All tests pass, and I've verified that the test for http://java.net/jira/browse/JAVASERVERFACES-1696 still passes as well.

Comment by rogerk [ 25/May/11 ]

Checked into trunk:
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Transmitting file data ..
Committed revision 9098.

Will check into MOJARRA_2_1X_ROLLING branch as well.

Comment by rogerk [ 25/May/11 ]

Checked into MOJARRA_2_1X_ROLLING branch. Will be available in 2.1.2.

Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Transmitting file data ..
Committed revision 9099.

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing

Comment by Rinner23 [ 31/May/11 ]

Is this problem still existing on the current 2.0.4 release? If so, this is a major issue as we cannot move on to later versions due to no official compatibility with Tomcat 6.x...

If so, we need to address this immediately or consider alternatives. Do you think the patch can be tested on 2.0.4 also?

Best Regards,

Matt Sweeney

Comment by rogerk [ 31/May/11 ]

I will test this on our MOJARRA_2_)X_ROLLING branch (which will be the next 2.0.x release).

Comment by Mathias Werlitz [ 31/May/11 ]

Yes, the problem exists for the current 2.0.4 release. From my point of view the fix can be applied to the 2.0.x branch as well.
If you use composite components you should also be aware of JAVASERVERFACES-2040, which might cause serious memory issues in production.

Comment by rogerk [ 01/Jun/11 ]

reopening to include 2.0.x

Comment by rogerk [ 01/Jun/11 ]

Changes for 2.0.X branch.

Comment by rogerk [ 01/Jun/11 ]

fix versions

Comment by rogerk [ 01/Jun/11 ]

changes for 2.0.X branch

Comment by rogerk [ 01/Jun/11 ]

Committed to MOJARRA_2_0X_ROLLING branch:
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Sending jsf-ri/systest/src/com/sun/faces/composite/CompositeComponentsTestCase.java
Adding jsf-ri/systest/src/com/sun/faces/systest/HelloBean.java
Adding jsf-ri/systest/web/composite/simpleCompositeComponentUsingPage.xhtml
Adding jsf-ri/systest/web/composite/submit.xhtml
Adding jsf-ri/systest/web/resources/composite/simpleCompositeComponent.xhtml
Transmitting file data ......
Committed revision 9126.

Comment by Rinner23 [ 01/Jun/11 ]

Thank you, really appreciate the quick response time =)

Comment by rogerk [ 04/Jun/11 ]

fix version

Comment by rogerk [ 04/Jun/11 ]

fix version

Comment by rogerk [ 04/Jun/11 ]

fix version

Comment by Ed Burns [ 21/Oct/11 ]

Turns out this patch has caused a regression, see JAVASERVERFACES-2232.

However, the JAVASERVERFACES-1988 is a real problem. I just need to find another solution for it.

Investigating now.

Comment by Ed Burns [ 21/Oct/11 ]

This zip contains two patches, both for the MOJARRA_2_1X_ROLLING branch. One that rolls back the fix for 1988. The other applies a new fix to the rolled back workarea.

Comment by Ed Burns [ 22/Oct/11 ]

Rework the fix to not cause JAVASERVERFACES-2232.

Comment by Ed Burns [ 24/Oct/11 ]

Committed fix to 2.1 branch in r 9412.

Committed small revision of fix to 2.1 branch in r 9414.

Comment by Ed Burns [ 24/Oct/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Adding jsf-test/JAVASERVERFACES-2232
Adding jsf-test/JAVASERVERFACES-2232/build.xml
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/pom.xml
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun/faces/regression/i_mojarra_2232_war
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun/faces/regression/i_mojarra_2232_war/JavaTopLevelComponent.java
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/resources
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/i_mojarra_2232.xhtml
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/resources
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/resources/ezcomp
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/resources/ezcomp/i_mojarra_2232_cc.xhtml
Sending jsf-test/build.xml
Transmitting file data ....
Committed revision 9418.

Committed to trunk.

Comment by Ed Burns [ 24/Oct/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Adding jsf-test/JAVASERVERFACES-2232
Adding jsf-test/JAVASERVERFACES-2232/build.xml
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/pom.xml
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun/faces/regression/i_mojarra_2232_war
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/java/com/sun/faces/regression/i_mojarra_2232_war/JavaTopLevelComponent.java
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/resources
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/i_mojarra_2232.xhtml
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/resources
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/resources/ezcomp
Adding jsf-test/JAVASERVERFACES-2232/i_mojarra_2232_war/src/main/webapp/resources/ezcomp/i_mojarra_2232_cc.xhtml
Sending jsf-test/build.xml
Transmitting file data .........
Committed revision 9421.

Now committed to 2.0 branch.

This means the regression has been fixed on all the JSF2 lines.





[JAVASERVERFACES-1943] java.io.NotSerializableException: javax.faces.component.UINamingContainer caused by using valueChangeListener attribute in a composite component Created: 10/Feb/11  Updated: 20/Feb/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: state saving
Affects Version/s: 2.1
Fix Version/s: 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: nzinoviev Assignee: rogerk
Resolution: Fixed Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-1943.txt     Zip Archive jsf-vcl-a-test.zip     File jsf-vcl-test-1.0.war     Zip Archive jsf-vcl-test.zip    
Status Whiteboard:

size_medium importance_large jsf_2_1_2


 Description   

Recently I switched from Mojarra 2.0.2 (SNAPSHOT 20100105) to Mojarra 2.1.0-b11
And started to get the following exceptions:

java.io.NotSerializableException: javax.faces.component.UINamingContainer
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at java.util.HashMap.writeObject(HashMap.java:1001)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at com.sun.faces.renderkit.ClientSideStateHelper.doWriteState(ClientSideStateHelper.java:325)
at com.sun.faces.renderkit.ClientSideStateHelper.writeState(ClientSideStateHelper.java:173)
at com.sun.faces.renderkit.ResponseStateManagerImpl.writeState(ResponseStateManagerImpl.java:122)
at com.sun.faces.application.StateManagerImpl.writeState(StateManagerImpl.java:166)
at com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:225)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:418)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)

After some debugging I found that serialization brokes on ContextualCompositeMethodExpression
which has 'cc' field which is not serializable. Probably this thing shouldn't get into state saving...

I found that the issue is caused by using valueChangeListener (attribute) in a composite component:

I have a page calling a component:

<ui:composition template="/template.xhtml">
<ui:define name="body">
<gc:groupsTable belongsToManager="#

{reportsEditBean.groupSetManager}

"
caption="Template Belongs To Groups"
readOnly="#

{reportsEditBean.readOnly}

"/>

</ui:define>
</ui:composition>

The offending part of the component is:

<composite:interface name="groupsTable">
<composite:attribute name="belongsToManager" required="true" shortDescription="a controller"
type="com.sun.aurora.web.AbstractBelongsToManager"/>
<composite:attribute name="caption" required="false"/>
<composite:attribute name="readOnly" default="false" required="false" type="Boolean"/>
</composite:interface>
<composite:implementation>
<h:selectOneListbox value="#

{cc.attrs.belongsToManager.groupToAdd}

"
valueChangeListener="#

{cc.attrs.belongsToManager.groupToAddChangeListener}

"
immediate="true"
hideNoSelectionOption="false"
/>
</composite:implementation>

relevant part of the bean is:
(I wanted to show the signatures)

public abstract class AbstractBelongsToManager implements Serializable {

private static final long serialVersionUID = 1L;

private String groupToAdd = GROUP_TO_ADD_LABEL;

private static final String GROUP_TO_ADD_LABEL = "- select -";
public String getGroupToAdd()

{ return groupToAdd; }

public void groupToAddChangeListener(ValueChangeEvent valueChangeEvent)

{ ... }

public void setGroupToAdd(String groupToAdd) {
}
}

Actually, I looked at jsf-demo samples and haven't found any usages of valueChangeListener attribute.



 Comments   
Comment by nzinoviev [ 10/Feb/11 ]

I tried to do things similiar to
~/work/mojarra/trunk/jsf-ri/systest/web/resources/composite/customValueChangeListener.xhtml

but it doesn't work.

It seems that one needs to add valueChangeListener attribute to reproduce this:
<h:inputText id="input" valueChangeListener="#

{cc.attrs.valueChangeListener}

"/>

Comment by nzinoviev [ 10/Feb/11 ]

My last resort was to change component to expose

<composite:editableValueHolder name="selectListInput" />

then call it via

<gc:expand-collapse title="Groups" open="false">
<gc:groupsTable belongsToManager="#

{reportsEditBean.groupSetManager}

"
caption="Template Belongs To Groups"
readOnly="#

{reportsEditBean.readOnly}

">
<f:valueChangeListener for="selectListInput"
binding="#

{reportsEditBean.groupSetManager.groupToAddChangeListener}

" />
</gc:groupsTable>
</gc:expand-collapse>

but it doesn't help either.

Comment by rogerk [ 10/Feb/11 ]

Can you please provide a war with source?
That would expedite our debugging process.

Comment by rogerk [ 10/Feb/11 ]

target

Comment by Ed Burns [ 10/Feb/11 ]

Target for 2.1.1

Comment by nzinoviev [ 10/Feb/11 ]

This is a war which reproduces the problem for me.
When I go to http://localhost:13000/jsf-vcl-test-1.0/
I get the java.io.NotSerializableException: javax.faces.component.UINamingContainer

I'm going to attach maven project for this war next.

Comment by nzinoviev [ 10/Feb/11 ]

Maven project for the war. WARNING: it contains directly pom.xml and src dir, so please unpack to some new directory

Comment by nzinoviev [ 10/Feb/11 ]

So I attached a simple project which hopefully reproduces the issue. I'm using GF v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) by the way. Please let me know if you can reproduce this. While I was trying all the workarounds I could imagine, it really puzzled me why existing tests do not catch it. The exact case used here seems not to be covered but the others seem to be...

Comment by nzinoviev [ 10/Feb/11 ]

I found another case which leads to similar exception involving just commandButton action expression. This was hard to corner because it needs an outer composite component:

Suppose Bean above has also a simple action method:

public String removeGroup()

{ return null; }

Calling (form) code is

<gc:component1 bean="#

{bean}

"/>
<h:commandButton value="Refresh"/>

component1 is

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:composite="http://java.sun.com/jsf/composite"
xmlns:gc="http://java.sun.com/jsf/composite/components">

<body>
<composite:interface name="groupsTable">
<composite:attribute name="bean" required="true" shortDescription="a controller"/>
</composite:interface>
<composite:implementation>
<gc:outer>
<h:commandButton action="#

{cc.attrs.bean.removeGroup}

" value="Remove"/>
</gc:outer>
</composite:implementation>
</body>
</html>

and outer is just

<composite:interface name="outer"/>
<composite:implementation>
(<composite:insertChildren/>)
</composite:implementation>

pressing either of the buttons leads to the exception.
Removing outer component solves the problem.

This appears to be a very major issue, looks like client state saving has been ruined for a while. I'm going to attach a new war and maven project.

Comment by nzinoviev [ 10/Feb/11 ]

Just go to equivalent of

http://localhost:13000/jsf-vcl-test-1.0/faces/Index_action.xhtml

and press one of the buttons.

Comment by nzinoviev [ 08/Apr/11 ]

Any ideas on when this would be addressed? It really makes JSF 2.1 unusable for applications using client view state saving. We need it fixed to move to jsf 2.1 a huge project of Java SQE org.

Comment by Ed Burns [ 11/Apr/11 ]

Target 2.1.2

Comment by adriaaaaan [ 19/Apr/11 ]

This issue is a major blocker for me, it completely breaks my application when enabling high availability in gf 3.1.

Comment by adriaaaaan [ 19/Apr/11 ]

I've managed to hack a workaround by making cc transient on a modified ContextualCompositeMethodExpression.java (thats not a real solution though obviously). Doing that leaves me with just one exception (which was there before, though less frequent) which i believe is all the same fault. My application is like above, it has a composite component that uses a el resolved valueChangeListener. This happens when HA is enabled in gf 3.1 using mojarra 2.1.1.

[#|2011-04-19T17:17:34.557+0100|SEVERE|glassfish3.1|org.apache.catalina.connector.CoyoteAdapter|_ThreadID=23;_ThreadName=Thread-1;|PWC3989: An exception or error occurred in the container during the request processing
java.lang.ClassCastException: cannot assign instance of java.lang.String to field com.sun.faces.facelets.el.ContextualCompositeMethodExpression.cc of type javax.faces.component.UIComponent in instance of com.sun.faces.facelets.el.ContextualCompositeMethodExpression
at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2039)
at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1952)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1666)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1322)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1666)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1322)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1666)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1322)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1666)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1322)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1666)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1322)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at java.util.HashMap.readObject(HashMap.java:1030)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1666)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1322)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at java.util.HashMap.readObject(HashMap.java:1030)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at java.util.HashMap.readObject(HashMap.java:1030)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at org.apache.catalina.session.StandardSession.readRemainingObject(StandardSession.java:1951)
at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1859)
at sun.reflect.GeneratedMethodAccessor173.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at org.apache.catalina.session.StandardSession.deserialize(StandardSession.java:1144)
at org.apache.catalina.session.StoreBase.readSession(StoreBase.java:288)
at org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:542)
at org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:494)
at org.glassfish.web.ha.session.management.ReplicationStore.loadFromBackingStore(ReplicationStore.java:413)
at org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:396)
at org.apache.catalina.session.PersistentManagerBase.doSwapIn(PersistentManagerBase.java:1053)
at org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:1011)
at org.glassfish.web.ha.session.management.ReplicationManagerBase.findSession(ReplicationManagerBase.java:150)
at org.apache.catalina.connector.Request.isRequestedSessionIdValid(Request.java:2664)
at org.apache.catalina.connector.Request.parseSessionCookiesId(Request.java:3690)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:621)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]
Comment by adriaaaaan [ 05/May/11 ]

Glassfish's preserve session on redeploy also throws this exception

INFO: PWC2785: Cannot serialize session attribute com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap for session 0c4ef7d68aab6a263a737ec67cfb
java.io.NotSerializableException: javax.faces.component.UINamingContainer

Comment by rogerk [ 11/May/11 ]

Can you please send me sources for this war?
I think all I need now is the Bean.java source.

Comment by rogerk [ 11/May/11 ]

Ok. I was able to reconstruct a bean and duplicate the issue.
And thanks for your detailed analysis.
I believe this issue (problem) was introduced as a result of a patch for this issue:

http://java.net/jira/browse/JAVASERVERFACES-1462

The patch for that issue added UIComponent cc to ContextualCompositeMethodExpression.java

Just to verify I re-tested by making that UIComponent cc ivar transient
and your app appeared to work.I'm not saying that is the fix.

Comment by rogerk [ 13/May/11 ]

Changes based on reporters test app.

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/facelets/el/ContextualCompositeMethodExpression.java
— Make UIComponent "cc" ivar transient
M jsf-test/build.xml
— Include JAVASERVERFACES-1943 in test harness.

A jsf-test/JAVASERVERFACES-1943
A jsf-test/JAVASERVERFACES-1943/htmlunit
A jsf-test/JAVASERVERFACES-1943/htmlunit/src
A jsf-test/JAVASERVERFACES-1943/htmlunit/src/main
A jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java
A jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com
A jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun
A jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces
A jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces/systest
A jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces/systest/Issue1943TestCase.java
— HtmlUnit test
A jsf-test/JAVASERVERFACES-1943/htmlunit/pom.xml
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java/vc
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java/vc/Bean.java
— Test Bean
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/Index_action.xhtml
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/Index.xhtml
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/template.xhtml
— Test pages
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/faces-config.xml
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/web.xml
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/classes
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/classes/test
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/vccomponent.xhtml
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/outer.xhtml
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/component1.xhtml
— Test composite component pages
A jsf-test/JAVASERVERFACES-1943/i_jsf_1943/pom.xml
A jsf-test/JAVASERVERFACES-1943/build.xml

Comment by Ed Burns [ 16/May/11 ]

Looks good. r=edburns.

Comment by rogerk [ 16/May/11 ]

Committed to trunk:

Sending jsf-ri/src/main/java/com/sun/faces/facelets/el/ContextualCompositeMethodExpression.java
Adding jsf-test/JAVASERVERFACES-1943
Adding jsf-test/JAVASERVERFACES-1943/build.xml
Adding jsf-test/JAVASERVERFACES-1943/htmlunit
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces/systest/Issue1943TestCase.java
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/pom.xml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java/vc
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java/vc/Bean.java
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/Index.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/Index_action.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/classes
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/classes/test
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/component1.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/outer.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/vccomponent.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/template.xhtml
Transmitting file data ..............
Committed revision 9039.

Comment by rogerk [ 16/May/11 ]

Sending jsf-test/build.xml
Transmitting file data .
Committed revision 9040.

Comment by rogerk [ 16/May/11 ]

Checked into 2_1_X branch:

Sending jsf-ri/src/main/java/com/sun/faces/facelets/el/ContextualCompositeMethodExpression.java
Adding jsf-test/JAVASERVERFACES-1943
Adding jsf-test/JAVASERVERFACES-1943/build.xml
Adding jsf-test/JAVASERVERFACES-1943/htmlunit
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-1943/htmlunit/src/main/java/com/sun/faces/systest/Issue1943TestCase.java
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/pom.xml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java/vc
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/java/vc/Bean.java
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/Index.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/Index_action.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/classes
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/classes/test
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/component1.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/outer.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/resources/components/vccomponent.xhtml
Adding jsf-test/JAVASERVERFACES-1943/i_jsf_1943/src/main/webapp/template.xhtml
Transmitting file data ..............
Committed revision 9042

Comment by adriaaaaan [ 18/May/11 ]

Thanks for quick turnaround on this one but I'm not convinced this is fixed. As stated in my previous post, just making cc transient throws another exception in its place. (easiest way to reproduce is to restart gf3.1 with persistent sessions on restart enabled)

SEVERE: PWC2773: Exception loading sessions from persistent storage
java.lang.ClassCastException: cannot assign instance of java.lang.String to field com.sun.faces.facelets.el.ContextualCompositeMethodExpression.cc of type javax.faces.component.UIComponent in instance of com.sun.faces.facelets.el.ContextualCompositeMethodExpression.

This occurs with the above changes for me.

Comment by adriaaaaan [ 18/May/11 ]

Replacing the mojarra implementation with the trunk one (as opposed to patching) doesn't seem to throw the above issue so i guess its fine

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing





[JAVASERVERFACES-1919] provide ant target that produces source bundle including TLDA text Created: 20/Jan/11  Updated: 11/Jun/11  Resolved: 11/Jun/11

Status: Closed
Project: javaserverfaces
Component/s: build
Affects Version/s: None
Fix Version/s: 2.0.6, 2.1.2

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_large

Tags: 3_1-exclude

 Description   

Every time we do a release, we have to include the README_TLDA.txt file. This file may not be checked into the external source tree, nor may it be included in the default binary build. We need to make a separate target that does an ant http get on the file inside of OWAN and includes it in the right place in the binary zip.

Please see <https://stbeehive.oracle.com/content/dav/st/Mojarra/Public%20Documents/Mojarra%202.0.4/mojarra-2.0.4-FCS-source-tlda.zip> for an example zip that contains the file in the right place. This URL is safe to publish externally because only Oracle Employees may access it.



 Comments   
Comment by Ed Burns [ 08/Apr/11 ]

http://java.net/jira/browse/JAVASERVERFACES-1919

Add a target for generating the source zip that includes the TLDA file,
while not commiting the TLDA file to version control. Rather, the file
is obtained from the OWAN at URL
http://anybodys.us.oracle.com/java/javaee/Specs/JSF/README_TLDA.txt.

M build.xml

Committed to trunk, 2.1, 2.0, and 1.2 branches.

Comment by rogerk [ 03/Jun/11 ]

reopen for fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version





[JAVASERVERFACES-1869] Deployment fails if project contains a RAR with a JAR Created: 12/Nov/10  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: 2.0.6, 2.1.2, 2.2.0-m01

Type: Bug Priority: Critical
Reporter: felipeal Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive i_mojarra_1869.zip    
Issuezilla Id: 1,869
Status Whiteboard:

size_medium importance_large

Tags: 3_1-exclude

 Description   

We have an EAR application that bundles a bunch of SAR files with JARs inside.
When we deploy it to a WebLogic 10.3 server that provides JSF 2.0.1, the
deployment fails due to the following exception:

com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! error in
opening zip file
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:354)
at
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java
:219)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsMana
ger.java:481)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.ja
va:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
Truncated. see log file for complete stacktrace
Caused By: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:114)
at java.util.jar.JarFile.<init>(JarFile.java:135)
at java.util.jar.JarFile.<init>(JarFile.java:72)
at
com.sun.faces.facelets.util.Classpath.getAlternativeJarFile(Classpath.java:252)
Truncated. see log file for complete stacktrace
>

Although the stack trace does not make it clear why the zip file could not be
opened, the URL it tries to open is:

/scratch/fleme/fmwhome/AS11gR1SOA/soa/connectors/FileAdapter.rar!fileAdapter.jar

(and the full URL passed to getAlternativeJarFile was
rar:/scratch/fleme/fmwhome/AS11gR1SOA/soa/connectors/FileAdapter.rar!fileAdapter
.jar!/META-INF/).

In fact, here's a more detailed stack trace:

Thread [pool-4-thread-2] (Suspended (breakpoint at line 252 in Classpath))
Classpath.getAlternativeJarFile(URL) line: 252
Classpath.search(ClassLoader, String, String) line: 109
Classpath.search(String, String) line: 86
MetaInfFacesConfigResourceProvider.loadURLs(ServletContext) line: 159
MetaInfFacesConfigResourceProvider.getResources(ServletContext) line:
107
ConfigManager$URLTask.call() line: 1053
ConfigManager$URLTask.call() line: 1022
FutureTask$Sync.innerRun() line: 303
FutureTask<V>.run() line: 138
ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
ThreadPoolExecutor$Worker.run() line: 908
Thread.run() line: 619



 Comments   
Comment by felipeal [ 12/Nov/10 ]

I'm assigning it to Ed Burns, as we already chatted about it and he is aware of
the problem.

Comment by Ed Burns [ 20/Jan/11 ]

See JAVASERVERFACES-1918

Comment by bo_stern [ 10/May/11 ]

This will become a major problem (show stopper) when SOA Suite (Fusion Middleware) PCBPEL_MAIN uptakes WLS 12g.

Comment by bo_stern [ 13/May/11 ]

Oracle sev2 bug (Severe Loss of Service) 12553287 has been opened and assigned to 9281 (JavaServer Faces) / RI.

Comment by Ed Burns [ 16/May/11 ]

First, I simply deployed your rar to GlassFish 3.1.1 and it did not show
the problem. I thought perhaps the reason might be that the problem
only shows up when you have a rar (with a jar inside) in an ear. I have
taken your rar and built a maven-rar-packaging project around that, and
then made a maven-ear-packaging project that uses the rar. The source
for this arrangement is at [1].

Unfortunately, I cannot still reproduce the problem in GlassFish 3.1.1.
Here are two explanations for this.

1. My ear is not correctly constructed.

2. The problem does not reproduce in GlassFish.

To rule out 1.), Can you please take the zip, do mvn install in the rar,
and then the ear directories, and deploy the resultant ear to a server
and see if it shows the problem? If it does not show the problem, then
can you give me a full ear file that does show the problem, instead of
just a rar?

Once you get back to me, I'll try out the arrangement with on WLS
10.3.4.

Thanks,

Ed

[1] http://javaweb.us.oracle.com/~edburns/i_jsf_1869.zip

Comment by Ed Burns [ 17/May/11 ]

Since Felipe's original post was based on WLS 10.3.4, and I already have WLS 10.3.4 support in Mojarra, I'm going to try to reproduce in that first, before trying anything more recent and specific to 12g.

Comment by Ed Burns [ 17/May/11 ]

Committed to trunk.

Sending jsf-ri/build-tests.xml
Sending jsf-ri/src/main/java/com/sun/faces/facelets/util/Classpath.java
Adding jsf-ri/test/com/sun/faces/facelets
Adding jsf-ri/test/com/sun/faces/facelets/util
Adding jsf-ri/test/com/sun/faces/facelets/util/ClasspathTestCase.java
Transmitting file data ...
Committed revision 9053.

Comment by Ed Burns [ 23/May/11 ]

Committed to 2.0 branch.

Sending jsf-ri/src/main/java/com/sun/faces/facelets/util/Classpath.java
Sending jsf-ri/test/com/sun/faces/facelets/util/ClasspathTestCase.java
Transmitting file data ..
Committed revision 9081.

Comment by Ed Burns [ 24/May/11 ]

Committed to 2.1 branch.

Sending jsf-ri/build-tests.xml
Sending jsf-ri/src/main/java/com/sun/faces/facelets/util/Classpath.java
Adding jsf-ri/test/com/sun/faces/facelets
Adding jsf-ri/test/com/sun/faces/facelets/util
Adding jsf-ri/test/com/sun/faces/facelets/util/ClasspathTestCase.java
Transmitting file data ...
Committed revision 9087.

Comment by Ed Burns [ 24/May/11 ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/facelets/util/Classpath.java
Sending jsf-ri/test/com/sun/faces/facelets/util/ClasspathTestCase.java
Transmitting file data ..
Committed revision 9089.

Comment by Ed Burns [ 24/May/11 ]

I was unable to get this to reproduce on GlassFish, and have been unable to get it to reproduce in an automated fashion with WLS. Therefore, I'm archiving the work for the automated test for this here.

The functionality of the fix is tested, however in white-box fashion, in the junit test ClasspathTestCase.

Comment by Ed Burns [ 24/May/11 ]

The fix has been committed to trunk, jsf 2.0 and jsf 2.1 lines. Marking fixed.

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version





[JAVASERVERFACES-1856] Jar-packaged composite components fail on WLS Created: 01/Nov/10  Updated: 17/Dec/13  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: resources
Affects Version/s: 2.0.1
Fix Version/s: 2.0.next, 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: aschwart Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 20110317-1537-i_jsf_1856.patch     Text File 20110325-1725-i_jsf_1856.patch     Java Source File ClasspathResourceHelper.java     Text File i_jsf_1856.patch    
Issue Links:
Related
is related to JAVASERVERFACES-3113 Migrate test for issue 1856 to test/a... Closed
Issuezilla Id: 1,856
Status Whiteboard:

size_medium importance_large jsf_2_1_1

Tags: adf

 Description   

Composite components that are packaged in jar files fail when deploying to WLS. The problem: when
testing for the existence of a composite component library, Mojarra calls ClassLoader.getResource() on the
path to the directory containing the composite component library. While GF's class loader honors calls to
getResource() for directory paths, WLS's class loader does not. As a result, the composite component
library is not found, and composite component references fail to resolve.

The failing code path starts around
com.sun.faces.facelets.tag.jsf.CompositeComponentTagLibrary.tagLibraryForNSExists(), which delegates to
the ResourceHandler/ResourceManager to check for the existence of the composite component resource
library.



 Comments   
Comment by Ed Burns [ 02/Nov/10 ]

Target 2.2

Comment by rogerk [ 10/Feb/11 ]

Set target version 2.1.1

Comment by Ed Burns [ 16/Feb/11 ]

I am unable to reproduce this issue on WLS10.3.4 with the latest Mojarra trunk.

Comment by aschwart [ 16/Feb/11 ]

Max is taking a look to see whether he can find a difference between the test cases that we have been using in ADF and the one that Ed has created for Mojarra.

Comment by Ed Burns [ 16/Feb/11 ]

Testcase that shows this is not a bug.

Comment by Ed Burns [ 16/Feb/11 ]

Sending common/ant/wls-10.3.4_no_cluster/container.xml
Sending common/ant/wls-10.3.4_no_cluster/wls-jsf
Sending jsf-ri/systest/build.xml
Adding jsf-ri/systest/src/com/sun/faces/systest/composite/JarPackagedCompositeComponentTestCase.java
Adding (bin) jsf-ri/systest/web/WEB-INF/lib/i_jsf_1856.jar
Adding jsf-ri/systest/web/composite/i_jsf_1856-using.xhtml
Transmitting file data .....
Committed revision 8853.

Comment by Ed Burns [ 17/Feb/11 ]

Feedback from Max Starets let me know that I can close this because the thinking of the moment is that the problem is in the way that JDev creates jars.

Comment by Ed Burns [ 17/Mar/11 ]

Ok. It turns out the implementation of ResourceHandler.libraryExists() relies on an implementation detail of the jar tool that is not in the zip file specification on which the jar is based. Basically, you can't count on directory entries being there.

I'm going to have to revise the implementation to fall back on another detection mechanism if the directory is not there.

I'll note that http://java.net/jira/browse/GLASSFISH-16058 fixes this problem, though looking at the bug I can't really say why.

In any case, Fusion Middleware relies on WLS 10.3.4 anyway so we have to affect the fix in Mojarra.

Comment by Ed Burns [ 18/Mar/11 ]

I was hoping I could leverage the code that already traverses the jars in order to discover the entries, but I found a problem in the spec.

The code that traverses the jars currently does so just so it can discover annotated classes. section 11.5.1 of the spec says that such jars must contain a faces-config.xml file, even if it is zero length, to cause the jar to even be seen by the annotation scanning system.

The resource library specification section 2.6.1.2 does not require the faces-config.xml file. Therefore, we can't rely on the jar traversing code without either broadening it to also include, say META-INF/resources.

This is what I will investigate next.

Comment by Ed Burns [ 18/Mar/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/JavaClassScanningAnnotationScanner.java
Deleting jsf-ri/systest/src/com/sun/faces/systest/composite/JarPackagedCompositeComponentTestCase.java
Deleting jsf-ri/systest/web/WEB-INF/lib/i_jsf_1856.jar
Deleting jsf-ri/systest/web/composite/i_jsf_1856-using.xhtml
Adding jsf-test/JAVASERVERFACES-1856
Adding jsf-test/JAVASERVERFACES-1856/build.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/pom.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib
Adding (bin) jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib/i_jsf_1856.jar
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/i_jsf_1856-using.xhtml
Sending jsf-test/build.xml
Transmitting file data ........
Committed revision 8933.

committed to trunk.

Comment by Ed Burns [ 19/Mar/11 ]

Committed to 2.1 branch

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/JavaClassScanningAnnotationScanner.java
Deleting jsf-ri/systest/src/com/sun/faces/systest/composite/JarPackagedCompositeComponentTestCase.java
Deleting jsf-ri/systest/web/WEB-INF/lib/i_jsf_1856.jar
Deleting jsf-ri/systest/web/composite/i_jsf_1856-using.xhtml
Adding jsf-test/JAVASERVERFACES-1856
Adding jsf-test/JAVASERVERFACES-1856/build.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/pom.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib
Adding (bin) jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib/i_jsf_1856.jar
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/i_jsf_1856-using.xhtml
Sending jsf-test/build.xml
Transmitting file data ...
Committed revision 8934.

Comment by Ed Burns [ 21/Mar/11 ]

Another iteration to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/web.xml
Transmitting file data ....
Committed revision 8939.

Comment by Ed Burns [ 21/Mar/11 ]

Another iteration to 2.1 branch

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/web.xml
Transmitting file data ...
Committed revision 8940.

Comment by Ed Burns [ 22/Mar/11 ]

Sending build.xml
Sending common/ant/common.xml
Sending common/ant/glassfishV3/container.xml
Adding common/ant/test-app.xml
Sending jsf-ri/build-tests.xml
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Sending jsf-ri/systest/build-tests.xml
Adding jsf-ri/systest/web/regexp
Adding jsf-ri/systest/web/regexp/converter02.txt
Adding jsf-ri/systest/web/regexp/converter06.txt
Adding jsf-ri/systest/web/regexp/escape_test.txt
Adding jsf-ri/systest/web/regexp/regression
Adding jsf-ri/systest/web/regexp/regression/AreaTextRowsAttrTest.txt
Adding jsf-ri/systest/web/regexp/regression/SelectOneManySizeAttrTest.txt
Adding jsf-ri/systest/web/regexp/standard
Adding jsf-ri/systest/web/regexp/standard/autocomplete.txt
Adding jsf-ri/systest/web/regexp/standard/component01.txt
Adding jsf-ri/systest/web/regexp/standard/dtablecolumnclasses.txt
Adding jsf-ri/systest/web/regexp/standard/messages01.txt
Adding jsf-ri/systest/web/regexp/standard/messages02.txt
Adding jsf-ri/systest/web/regexp/standard/pgridcolumnclasses.txt
Adding jsf-ri/systest/web/regexp/standard/selectmany02.txt
Adding jsf-ri/systest/web/regexp/verbatim_test.txt
Sending jsf-ri/systest-per-webapp/build-tests.xml
Adding jsf-test
Adding jsf-test/JAVASERVERFACES-1856
Adding jsf-test/JAVASERVERFACES-1856/build.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/pom.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib
Adding (bin) jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib/i_jsf_1856.jar
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/i_jsf_1856-using.xhtml
Adding jsf-test/build.xml
Sending lib/jsf-extensions-test-time.jar
Transmitting file data ...............................
Committed revision 8945.

Comment by Ed Burns [ 23/Mar/11 ]

Customer not yet satisfied with fix.

Comment by Ed Burns [ 23/Mar/11 ]

Another iteration, this on the trunk.

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagLibrary.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceHandlerImpl.java
Transmitting file data ...
Committed revision 8947.

Comment by Ed Burns [ 23/Mar/11 ]

Committed to 2.0 branch

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagLibrary.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceHandlerImpl.java
Transmitting file data ...
Committed revision 8949.

Comment by Ed Burns [ 24/Mar/11 ]

Committed to 2.1 branch.

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagLibrary.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceHandlerImpl.java
Transmitting file data ...
Committed revision 8950.

Comment by Ed Burns [ 25/Mar/11 ]

Still doing directory scan.

Comment by Ed Burns [ 25/Mar/11 ]

Reviewed with Sheetal.

Comment by rogerk [ 27/May/11 ]

fix versions

Comment by rogerk [ 27/May/11 ]

re-closing





[JAVASERVERFACES-1542] Bug in FactoryFinder.FactoryManagerCache.getApplicationFactoryManager() Created: 09/Feb/10  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 1.2_09 BETA1
Fix Version/s: 2.0.6, 2.1.2, 2.2.0-m01

Type: Bug Priority: Critical
Reporter: wanghongbing Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Text File changebundle.txt    
Issuezilla Id: 1,542
Status Whiteboard:

size_medium importance_large


 Description   

The same bug exists in latest 2.0 codeline too.
If getApplicationFactoryManager(ClassLoader cl) fails when doing
try

{ return factories.get(); }
it will clean up current cached FactoryManager, when next request comes in, a
new FactoryManager will be created filled with 4 factory/factory impl map with
empty factory impl value for following factories
javax.faces.application.ApplicationFactory
javax.faces.context.FacesContextFactory
javax.faces.lifecycle.LifecycleFactory
javax.faces.render.RenderKitFactory
The factory impl values were filled up during deploying time by going through
web applicaiton's config files, but this will not get re-executed so the map
will not be restored correctly, which will cause all subsequent request to have
problem for those 4 factory impl.
One of the case that factories.get() can go wrong is when current thread is
interrupted, it throws InterruptedException. The solution is when recreating
FacotyManager, it restores all factory impls correctly.

Here is part of related code in FactoryFinder.java:
private FactoryManager getApplicationFactoryManager(ClassLoader cl) {

while (true) {
Future<FactoryManager> factories = applicationMap.get(cl);
if (factories == null) {
Callable<FactoryManager> callable =
new Callable<FactoryManager>() {
public FactoryManager call()
throws Exception { return new FactoryManager(); }
};

FutureTask<FactoryManager> ft =
new FutureTask<FactoryManager>(callable);
factories = applicationMap.putIfAbsent(cl, ft);
if (factories == null) { factories = ft; ft.run(); }
}

try { return factories.get(); }

catch (CancellationException ce) {
if (LOGGER.isLoggable(Level.FINEST))

{ LOGGER.log(Level.FINEST, ce.toString(), ce); }

applicationMap.remove(cl);
} catch (InterruptedException ie) {
if (LOGGER.isLoggable(Level.FINEST))

{ LOGGER.log(Level.FINEST, ie.toString(), ie); }

applicationMap.remove(cl);
} catch (ExecutionException ee)

{ throw new FacesException(ee); }

}

}



 Comments   
Comment by Ryan Lubke [ 10/Feb/10 ]

Update target milestone.

Comment by Ed Burns [ 22/Jun/10 ]

Reassign to edburns

Comment by rogerk [ 25/Jun/10 ]

triage

Comment by Ed Burns [ 03/Nov/10 ]

2.2

Comment by rdelaplante [ 02/May/11 ]

I think I am experiencing this bug in production with GlassFish 3.1-b43. See the details in the GlassFish forum:
http://www.java.net/forum/topic/glassfish/glassfish/v31-jsf-20-app-runs-two-days-then-dies-could-not-find-factory-javaxfacesrenderrenderkitfactory

Comment by Michael Willis [ 06/May/11 ]

We are getting this issue on our servers, the problem occurs about 3 times a week and the server has to be restarted.

Stack Trace:

Caused by: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.render.RenderKitFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:725)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:239)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:159)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:532)
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:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
...

We are running Glassfish 3.1 and JSF 1.2

Has anyone worked on a patch for this?

Comment by rdelaplante [ 06/May/11 ]

@mickwillis: I don't have an answer for you, but am wondering if this problem started when you migrated to GlassFish 3.1? Did you have this problem on 3.0? 2.1? We went from 2.1.1 to 3.1.0. I didn't encounter this problem until our app went into production. We've been in production with GlassFish 3.1 for one week now and have encountered this issue only once so far. I'm not sure if this is related, but I set the number of Grizzly threads in the web container to 100 (I think the default was 5). That might explain why we're not experiencing it as often as you.

Comment by Ed Burns [ 06/May/11 ]

I discovered a long latent problem in FactoryFinder late in the development cycle for GlassFish 3.1. I have fixed it and the fix is present in the Mojarra releases for 2.1.1 and 2.0.5. I also have a fix committed in the 1.2 line, but that has not yet been released. I am happy to provide access to the 1.2 line build if someone agrees to try it as a development build.

Also, 2.0.5 has not yet been released but it is done. If you get 2.0.5-b02 from <http://download.java.net/maven/2/com/sun/faces/>, those are the same bits as I'll be publishing soon as 2.0.5 final.

I suspect this issue can be closed but I'd really love to see a reproducible testcase.

Comment by rdelaplante [ 06/May/11 ]

That's great news! Do you think this bug is the cause of what I described in the GlassFish forum post linked to above? Will the fix be included in GlassFish 3.1.1 which is scheduled for release May 31 2011?

Comment by Michael Willis [ 06/May/11 ]

@rdelaplante, my apologies, we are using Glassfish 3.0 not 3.1 and yes the issue started once we moved from Glassfish 2.1 to 3.0. We are performing some further investigations and then will consider whether to apply the fix.

Comment by Michael Willis [ 06/May/11 ]

@Ed Burns, Thanks for the update. We would like to try the 1.2 line build of this fix. Our intention would be to trial it in our QA environment for a short period before releasing it on to one of our live servers. Can you provide the source code jars? Thanks.

Comment by Ed Burns [ 06/May/11 ]

http://java.net/projects/javaserverfaces/downloads/download/scratch/mojarra-1.2_16-20110421-SNAPSHOT-binary.zip

http://java.net/projects/javaserverfaces/downloads/download/scratch/mojarra-1.2_16-20110421-SNAPSHOT-source.zip

Comment by Ed Burns [ 06/May/11 ]

It turns out there is indeed a problem where the FactoryFinder does not recover gracefully from an InterruptedException that is thrown during a call to factories.get(). The attached patch and testcase addresses this problem.

Comment by Ed Burns [ 09/May/11 ]

Seems to work on trunk with GlassFish 3.1.1 snapshot

Comment by rdelaplante [ 09/May/11 ]

Does that mean none of the patches associated with this ticket will be included in JSF RI or GlassFish 3.1 because it was a bug in GlassFish 3.1.0 and older?

Comment by Ed Burns [ 09/May/11 ]

No, on the contrary. It's in 2.1.1, 2.0.5 (for which only the b02 build is available, but that will be the final build of 2.0.5) and also it's in 1.2_16, which is not yet released, but which I have pointed to earlier in the issues.

Now, the next official release of GlassFish, whenever that comes, will have the fix.

Comment by Ed Burns [ 09/May/11 ]

Here is the commit log for the patch I mentioned on 06/May/11 02:27 PM

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Adding jsf-test/JAVASERVERFACES-1542
Adding jsf-test/JAVASERVERFACES-1542/build.xml
Adding jsf-test/JAVASERVERFACES-1542/htmlunit
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src/main/java/com/sun/faces/systest/OneShotDisableFactoryFinder.java
Adding jsf-test/JAVASERVERFACES-1542/htmlunit/src/main/java/com/sun/faces/systest/ShowTheAppIsWorking.java
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/pom.xml
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/java
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/java/com
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/java/com/sun/faces/regression/FactoryFinderTestCaseBean.java
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/webapp/WEB-INF/beans.xml
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/webapp/disableFactoryFinder.xhtml
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/webapp/main.xhtml
Adding jsf-test/JAVASERVERFACES-1542/i_jsf_1542/src/main/webapp/showTheAppIsWorking.xhtml
Sending jsf-test/build.xml
Transmitting file data .............
Committed revision 9016.

I put this patch into the trunk.

Comment by aschwart [ 09/May/11 ]

I have reviewed the change bundle, but unfortunately I am confused about how this addresses the problem. Think I may be missing something.

If I understand the problem correctly, it seems that at some point after startup (ie. after the server has been up for some time), we hit the following sequence:

1. The get() call on the "factories" FutureTask throws an interrupted exception
2. This causes the FactoryManager to be released.
3. On a subsequent request, the FactoryManager is re-created.
4. However, the FactoryManager is left in its uninitialized state - ie. no factories are registered.
5. As a result, the next attempt to get a factory blows up.

We need to address #4 - ie. when the FactoryManager is re-created, we need to ensure that any factories specified in faces-config.xml are re-registered. I don't see how this change bundle addresses this.

A more fundamental question that might be worth exploring is why we are seeing InterruptedExceptions during the FutureTask.get() call. If the server has been up for some time, it is unlikely that there is any waiting/blocking happening during the FutureTask.get() call - ie. the FutureTask's value would have been initialized and the get() call should return immediately. My guess is that the threads are already in an interrupted state when we arrive at the FutureTask.get() call and that this causes the InterruptedException to be thrown. If this is the case, we could detect this and clear the interrupted state before calling FutureTask.get(). (Though it would probably make sense to track down why these threads are left in the interrupted state - seems like this should have been cleaned up before it arrives at the FactoryFinder code.)

A related question is whether FactoryFinder should be releasing the FactoryManager when the InterruptedException occurs. Seems like we only need to be worried about InterruptedExceptions that occur during the first call to FutureTask.get() (ie. the one that creates the FactoryManager). InterruptedExceptions during subsequent calls to FutureTask.get() shouldn't necessarily force the FactoryManager to be re-initialized. Instead, we should just re-try the FutureTask.get() call.

Comment by aschwart [ 09/May/11 ]

Alternatively, perhaps we should revisit whether we can use a simpler mechanism (ie. one that does not require the use of Futures) to ensure that a single FactoryManager instance is created per application.

Comment by rdelaplante [ 09/May/11 ]

FYI in my case, I think this was triggered by Grizzly interrupting a thread. The first time it showed up in my log looks like this:

[#|2011-04-30T09:02:21.788-0500|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-1;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-81(1).|#]

[#|2011-04-30T09:02:21.788-0500|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=45;_ThreadName=Thread-1;|StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.render.RenderKitFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:815)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:317)
at com.sun.faces.context.FacesContextImpl.<init>(FacesContextImpl.java:128)
at com.sun.faces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:93)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:399)
...

We've been running stable for a little over a week now. It happened only once since we upgraded from GlassFish 2.1.1 to 3.1-b43.

Comment by aschwart [ 09/May/11 ]

Thinking about this a bit more, I think that the right solution is to not bother using the FutureTask to create the FactoryManager. Creating the FactoryManager instance is cheap - no need to protect against multiple creations. ConcurrentHashMap.putIfAbsent() is sufficient to ensure that only a single instance is used.

The fact that FactoryFinder is seeing threads in an interrupted state seems to indicate that some code (container code perhaps?) is not cleaning up threads before handing them off to JSF. This seems like something important to track down and fix.

Also, Mojarra is using FutureTask in other places (for similar reasons). Removing the FutureTask dependency from FactoryFinder will avoid the immediate problem of the FactoryManager getting hosed, though it is important to also take a look at other FutureTask usages to make sure that there aren't other problems lurking.

Comment by aschwart [ 09/May/11 ]

Oh, I missed Ryan's comment before posting my last comment:

> FYI in my case, I think this was triggered by Grizzly interrupting a thread. The first time it showed up in my log looks like this:
>
> [#|2011-04-30T09:02:21.788-0500|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-1;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-81(1).|#]

Interesting. The message indicates that the thread is idle when it is interrupted. Seems like the interrupted flag should be cleared before it is used to process a new request.

Comment by rdelaplante [ 09/May/11 ]

Will you let the Grizzly team know about that? GlassFish 3.1.1 is scheduled for May 31st and it would be nice to get this problem solved for the release.

Comment by aschwart [ 09/May/11 ]

Sent mail to Justin and Ryan.

Comment by rdelaplante [ 09/May/11 ]

Notice in my log the Grizzly thread interruption happens the same millisecond as a user trying to load a JSF 2.0/facelet page. Also they both have different ThreadIDs, so I'm not sure if the problem is related?

Comment by aschwart [ 09/May/11 ]

> Also they both have different ThreadIDs, so I'm not sure if the problem is related?

Interesting. Yeah, quite possible that this is not related. Let's see if Grizzly guys have any more insight on this.

BTW, I have an idea for a workaround, though it is too gross to document in a public issue tracker.

Comment by Justin Lee [ 09/May/11 ]

This is likely more an initialization problem in JSF than a grizzly bug. We interrupt threads all the time with no apparent ill affects. That said, if you have a test case you can provide, I can step through the idle thread kill and just double check. That message in the log is the standard message when an idle connection is detected so it doesn't cause me any particular concern. I'd be happy to double check, though.

Comment by aschwart [ 09/May/11 ]

Thanks for reviewing this Justin.

Although the IllegalStateException error message does seem to indicate a JSF initialization problem ("Application was not properly initialized at startup"), this is misleading. In Ryan and Michael's cases, the application/JSF is properly initialized and operational - it is only after an interrupted thread is encountered that things go wrong. Unfortunately since the problem only reproduces after days of use, it doesn't seem like a test case is going to be forthcoming.

How to move forward?

The easiest fix/workaround at the Mojarra layer would be to avoid using a FutureTask for initializing/retrieving the FactoryManager. This does have the drawback that other FutureTask usages in the Mojarra code base might suffer from similar problems, so these would need to be examined.

Since the problem may be more widespread than the FactoryFinder/FactoryManager case, it would be worthwhile to track down why Mojarra is seeing threads in an interrupted state. One test that might be interesting would be to check the Thread.isInterrupted() state when FacesServlet.service() is called. If isInterrupted() returns true, this would indicate that the container is not resetting the thread interrupted state before handing off to the servlet. (Or, alternatively, the same test could be performed in an application-specified servlet filter.)

Comment by kwelker [ 13/May/11 ]

Just saw this as well and had to restart the server to resolve like others. Running Glassfish 3.1 release (b43) and the default JSF which is 2.1.0-11. Has anyone tried upgrading to 2.1.1 (04/04/2011) and seen it or not seen it with that version of JSF?

I see the bug is resolved as not reproduceable. What information is needed to help reproduce it?

[#|2011-05-13T12:28:33.212-0500|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=12;_ThreadName=Thread-1;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-8181(10).|#]

[#|2011-05-13T12:28:33.217-0500|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=289;_ThreadName=Thread-1;|StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.render.RenderKitFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:815)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:317)
at com.sun.faces.context.FacesContextImpl.<init>(FacesContextImpl.java:128)
at com.sun.faces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:93)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:399)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.medallion.web.tags.UploadFilter.doFilter(UploadFilter.java:100)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:323)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]
Comment by aschwart [ 16/May/11 ]

I took a quick look at the FactoryFinder diffs in the new changebundle. Two comments:

1. The following code is no longer used and should be removed:

Callable<FactoryManager> callable =
new Callable<FactoryManager>() {
public FactoryManager call()
throws Exception

{ return new FactoryManager(); }

};

2. The return value of ConcurrentMap.putIfAbsent() needs to be honored.

Currently, the code does this:

...
result = new FactoryManager();
applicationMap.putIfAbsent(key, result);
}
return result;

However, if a FactoryManager is already present in the applicationMap, we'll want to use/return that instead of the newly created FactoryManager.

Other than that, looks good.

Comment by Ed Burns [ 16/May/11 ]

Thanks. I'll fix that and commit to all the source lines.

Comment by aschwart [ 16/May/11 ]

One other suggestion: it might be helpful add a check for Thread.isInterrupted() in FacesServlet (and either log a message or throw an exception) for diagnostic purposes - ie. would be interesting to know whether Mojarra is seeing interrupted threads when entering the Faces lifecycle, as this could indicate a container bug.

Comment by Ed Burns [ 16/May/11 ]

Committed to trunk.

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Sending jsf-api/src/main/java/javax/faces/webapp/FacesServlet.java
Deleting jsf-test/JAVASERVERFACES-1542
Sending jsf-test/build.xml
Transmitting file data ...
Committed revision 9046.

Comment by Ed Burns [ 17/May/11 ]

Committed to MOJARRA_2_1X_ROLLING branch.

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Sending jsf-api/src/main/java/javax/faces/webapp/FacesServlet.java
Transmitting file data ..
Committed revision 9050.

Comment by Ed Burns [ 18/May/11 ]

Committed to MOJARRA_2_0X_ROLLING branch.

Sending build.xml
Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Sending jsf-api/src/main/java/javax/faces/webapp/FacesServlet.java
Sending jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java
Sending jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
Sending jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
Sending jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
Sending jsf-ri/build.xml
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Sending jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
Sending lib/jsf-extensions-test-time.jar
Transmitting file data ...........
Committed revision 9055.

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by rogerk [ 03/Jun/11 ]

fix version

Comment by Manfred Riem [ 20/Feb/12 ]

Reopening to set correct fix version





[GLASSFISH-16573] message logged as INFO should be logged as FINE Created: 06/May/11  Updated: 06/Jun/11  Resolved: 06/Jun/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1.1_b04
Fix Version/s: 3.1.1_b07

Type: Bug Priority: Critical
Reporter: Anissa Lam Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-GF-16573.txt    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16577 "No execute and render identifiers sp... Resolved
Tags: 3_1-next

 Description   

I am seeing the following message in server.log when running Admin Console.

[#|2011-05-06T09:23:48.508-0700|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=26;_ThreadName=admin-thread-pool-4848(5);|No execute and render identifiers specified. Skipping component processing.|#]

[#|2011-05-06T09:23:48.509-0700|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=26;_ThreadName=admin-thread-pool-4848(5);|No execute and render identifiers specified. Skipping component processing.|#]

[#|2011-05-06T09:23:48.509-0700|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=26;_ThreadName=admin-thread-pool-4848(5);|No execute and render identifiers specified. Skipping component processing.|#]

user will see this log every few clicks in GUI. and everytime it shows up, it shows up as a group of 3.

GUI has a header page, and we just want to do a "ping" ajax request. It will not execute or render anything. This is probably causing this message.
The msg suggests that it is skipping "component processing" because the Ajax request did not ask for any components to be executed or rendered. I don't know if this log is really needed. At most, it should be logged at FINE level.

This logging at INFO happens recently. It did NOT show up in 3.1 final release. But i am seeing that when running the trunk AND also on 3.1.1. This needs to be fixed.



 Comments   
Comment by rogerk [ 20/May/11 ]

Changes.

Comment by rogerk [ 20/May/11 ]

Committed to Mojarra trunk:
Committed revision 9063.

Committed to Mojarra branch MOJARRA_2_1_ROLLING:
Committed revision 9064.

This should be available in the Mojarra 2.1.2 release for GlassFish 3.1.1

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





Generated at Sat Mar 28 14:36:40 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.