<< Back to previous view

[JAVASERVERFACES-3246] default-locale is not used for resolving texts of resource bundles Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: javaserverfaces
Component/s: configuration
Affects Version/s: 2.1.26, 2.1.28
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lutzulrich Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File mojarra-default-locale.war    
Tags:
Participants: Ed Burns, lutzulrich and Manfred Riem

 Description   

Excerpt from faces-config.xml:

<locale-config>
<default-locale>en</default-locale>
<supported-locale>de</supported-locale>
</locale-config>

But the Default locale 'en' seems to be ignored.
If there is some resource bundle with an English and German variant, the resolved texts are always German, no matter what the preferred locale of the HTTP request is.

The Problem can be resolved by adding a <supported-locale> element for the default locale.

There seems to be no such bug in 2.2.6.



 Comments   
Comment by Manfred Riem [ 17/Apr/14 02:39 PM ]

Please send a reproducer to issues@javaserverfaces.java.net. Thanks!





[JAVASERVERFACES-3240] FlowDefinition not a CDI scope Created: 10/Apr/14  Updated: 17/Apr/14

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jozef Hartinger Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns, Jozef Hartinger and Manfred Riem

 Description   

FlowDefinition is not a CDI scope. Yet it is returned from the FlowDiscoveryCDIContext.getScope() method. The method contract says clearly that this method should return a scope annotation.

CDI implementations do not validate this yet but should any one start with that, it is going to make Mojarra unusable with CDI.

TBH the entire FlowDiscoveryCDIContext does not look like a proper Context implementation at all but a rather a hack to propagate state. There are better ways to achieve this.



 Comments   
Comment by Manfred Riem [ 11/Apr/14 01:16 PM ]

Jozef, please tell us the better ways. Thanks!

Comment by Jozef Hartinger [ 11/Apr/14 03:44 PM ]

Ideally remove the redundant context altogether.

Comment by Jozef Hartinger [ 11/Apr/14 03:47 PM ]

https://github.com/jharting/mojarra/commit/e72f6f1ae3fef1f4c0b2c9872d110a2e6d022ccc





[JAVASERVERFACES-3236] ByteConverter Created: 08/Apr/14  Updated: 11/Apr/14

Status: Open
Project: javaserverfaces
Component/s: conversion
Affects Version/s: 2.2.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: e_norman Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: e_norman and Ed Burns

 Description   

The error message from the ByteConverter#getAsObject call indicates that it is expecting a number between 0 and 255 from the browser. However, the implementation of ByteConverter is using the Byte.valueOf(value) API to parse the string which expects the java representation of a byte which is a number between -128 and 127.

I would expect the ByteConverter#getAsObject to subtract 128 from the number and ByteConverter#getAsString to add 128 to the number to match what the error message says.






[JAVASERVERFACES-3198] EL Expressions containing '#{cc.whatever}' used in actionListener or validator attributes inside composite components expose whole UIComponent tree to HttpSession Created: 06/Mar/14  Updated: 25/Mar/14

Status: Open
Project: javaserverfaces
Component/s: composite components
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: alex.bel Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mojarra 2.2.5
Apache Tomcat 7.0.52


Tags:
Participants: alex.bel and Ed Burns

 Description   

composite.xhtml:

<h:body>

    <composite:interface componentType="ExampleComposite">
    </composite:interface>

    <composite:implementation>
        <h:panelGrid columns="1">
            <h:inputText id="ec_in" validator="#{cc.someValidator}"/>
            <h:commandButton id="ec_button" value="some button" actionListener="#{cc.someListener}" />
        </h:panelGrid>
    </composite:implementation>
</h:body>
</html>

composite.java:

@FacesComponent("ExampleComposite")
public class ExampleComposite extends UINamingContainer {
    public void someValidator(FacesContext context, UIComponent component, Object value) {

    }

    public void someListener() {

    }
}

Here we have validator and actionListener bound to methods inside ExampleComposite composite class.
Under the hood these EL Expressions are represented by the ContextualCompositeMethodExpression class which has 'cc' field which points to the composite component (ExampleComposite instance)
Now what happens when Mojarra saves view state:
1) Those ContextualCompositeMethodExpression instances are written to the view state
2) The view state are put in the HttpSession
3) HttpSession now have hard reference to ContextualCompositeMethodExpression instances
4) ContextualCompositeMethodExpression has hard references to ExampleComposite instances
5) ExampleComposite is instance of UIComponent which has hard references to parent, children, and facets
6) Garbage collector is not able to collect the UIComponent tree because it is hard referenced from the HttpSession. That's the problem, especially on large pages when UIComponent tree becomes huge.
This image describes what I'm talking about: http://s8.postimg.org/hwq8h1web/ccmp_leak.png

How to reproduce:
1) Download the sample application: http://www.sendspace.com/file/ub5bp6
2) Build WAR with maven or IDE
3) Deploy WAR on Tomcat 7
4) Open <address of tomcat>/bug.xhtml in a browser
5) Check tomcat's stdout. You should see following lines (formatted a little bit):

Bad session attributes:[
/[SessionAttr: com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap]/[Map.Entry: '367679118722284412'] (Map)
/[Map.Entry: '-8757272016074238217'] (Array)/[ArrayIndex: 1] (Map)/[Map.Entry: 'form:j_idt3:ec_button'] (Array)/[ArrayIndex: 0] (Array)
/[ArrayIndex: 0] (Array)/[ArrayIndex: 0] [com.sun.faces.facelets.el.ContextualCompositeMethodExpression] #{cc.someListener}/[Field: cc] example.ExampleComposite@47415dbf

 /[SessionAttr: com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap]/[Map.Entry: '367679118722284412'] (Map)
/[Map.Entry: '-8757272016074238217'] (Array)/[ArrayIndex: 1] (Map)/[Map.Entry: 'form:j_idt3:ec_in'] (Array)/[ArrayIndex: 1] (Array)
/[ArrayIndex: 0] (Array)/[ArrayIndex: 0] [com.sun.faces.facelets.el.ContextualCompositeMethodExpression] #{cc.someValidator}/[Field: cc] example.ExampleComposite@47415dbf]

6) These lines are produced by SessionCheckFilter. It examines HttpSession and tries to find UIComponent instances inside it.

My thoughts:
1) Why does the ContextualCompositeMethodExpression class have the 'cc' attribute? The ContextualCompositeValueExpression class (which does the similar work for ValueExpressions) doesn't have one. Also this 'cc' attribute is transient and there is no code that restores the value after deserialization. So, cc will be null after serialization-deserialization cycle. Is it OK?
2) Why are actionListeners and validators (MethodExpressionActionListener and MethodExpressionValidator) not affected by partial state saving?



 Comments   
Comment by Ed Burns [ 21/Mar/14 04:56 PM ]

1) Why does the ContextualCompositeMethodExpression class have the 'cc' attribute? The ContextualCompositeValueExpression class (which does the similar work for ValueExpressions) doesn't have one. Also this 'cc' attribute is transient and there is no code that restores the value after deserialization. So, cc will be null after serialization-deserialization cycle. Is it OK?

Regarding "why does it have the cc ivar"? The answer is that we need to save it so we can correctly establish the context of the cc regardless of the level of nesting of the composite component.

When you say serialization-deserialization, do you mean regarding session replication? If that's the case, you are correct, the cc ivar will be null on the other side of a session replication deserialization.

2) Why are actionListeners and validators (MethodExpressionActionListener and MethodExpressionValidator) not affected by partial state saving?

Do you observe that MethodExpressionActionListener.saveState() and restoreState() are not being called in any case?

Comment by Ed Burns [ 21/Mar/14 05:16 PM ]

I'm wondering if there is a little optimization we can do here. I appreciate you have taken the time to file this very detailed bug. It would help us a lot if you could answer this question about the state of the code in your example.

Look at the pushCompositeComponent() method in ContextualCompositeMethodExpression. Can you set a breakpoint on line 300 of that class, in the foundCc = this.cc line in the following statement?

if (null == foundCc) {
            foundCc = this.cc;
        }

If that line is never hit in your case, I wonder if we could add an else {} clause that clears the this.cc ivar. This would cause it to not be pulled into the state.

Comment by Ed Burns [ 21/Mar/14 05:16 PM ]

This appears to be related to JAVASERVERFACES-1462 and JAVASERVERFACES-1943.





[JAVASERVERFACES-3193] Regression -JSF page performance degrades significantly as page size increases. Resurfaces in 2.2.5 release. Created: 24/Feb/14  Updated: 26/Feb/14

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rkite Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

« Hide

Tomcat with Mojarra 2.1.11, JBoss 7.2 (Mojarra 2.1.11) running on Windows 7 64bit Sun/Oracle 1.6.0_32 java 32bit


File Attachments: File AjaxTest.xhtml     Java Source File PageAjaxTest.java    
Issue Links:
Dependency
depends on JAVASERVERFACES-2847 Remove addRemove listener just before... Closed
depends on JAVASERVERFACES-2848 Make sure f:phaseListener gets regist... Closed
Related
is related to JAVASERVERFACES-2498 Performance problems with dynamically... Closed
is related to JAVASERVERFACES-2563 Performance degradation in Render Res... Closed
is related to JAVASERVERFACES-2885 Move FaceletComponentMap from FacesCo... Closed
Tags: performance
Participants: Ed Burns, Manfred Riem and rkite

 Description   

I cloned this from closed issue JAVASERVERFACES-2334 since the issue is getting worse with subsequent releases of Mojarra.

This is from original post
<--
<f:ajax> tag degrades to performance of regular JSF 2 post as the xhtml page size increases. Attached is a sample xhtml page and backing bean that exhibits the problem. The page has 2 <f:form> tags the first one is very small and has the <f:agax> tag. The second <h:form> is large and contains a lot of html. Problem happens in GlassFish 3.1.1, JBoss 7.1 and Tomcat 7.0

Using javax.faces.FULL_STATE_SAVING_VIEW_IDS makes no difference in performance. -->

We have gone from 1.7 seconds for the attached example to 3.5 seconds by upgrading from Mojarra 2.1.5 to Mojarra 2.1.11. This is more than just an AJAX issue. Rendering of pages is slow and gets slower as the page size increases. By debugging Mojarra code I have found that for every "entry" in a page processed the tree is walked from the top node down. It finds the correct positions of the nodes to be modified by walking the tree 100s of times per page load. Is there a way Hash maps or other data structures could be used to avoid walking the full tree so many times per page load?

We have many pages where just the rendering, Post or AJAX request takes several seconds even if there is no database access. There is no way to support multiple users when a page load takes 2 or more seconds at 100% CPU utilization. Rendering of the page should be in fractions of a second and not take longer than database access.



 Comments   
Comment by rkite [ 24/Feb/14 07:20 PM ]

Please see original issue --> https://java.net/jira/browse/JAVASERVERFACES-2494

This problem has surfaced again in release 2.2.5 I re-tested 2.2.1 - 2.2.4 and they perform well. The test page renders around 1/10th of a second with these releases.

Release 2.2.5 is back to performing slow similar to before the fix with around 3 seconds to render the attached test page through Ajax or a post.

Comment by Manfred Riem [ 26/Feb/14 02:18 PM ]

Can you please try that page in full state saving and see if that makes a difference?

Comment by rkite [ 26/Feb/14 05:20 PM ]

I added the following entry to web.xml.

<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>

It does not make a noticable difference. Around 3 seconds with 2.2.5 and about 1/10th of a second with 2.2.4.

Comment by Manfred Riem [ 26/Feb/14 07:21 PM ]

That is not the one I meant. Can you try the following?

<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>

Or if you want to turn it on for a specific page(s)

<context-param>
<param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
<param-value>/faces/mypage.xhtml,/faces/myotherpage.xhtml</param-value>
</context-param>

Comment by rkite [ 26/Feb/14 08:05 PM ]

That worked and the performance is back on the test page. Other pages still render slow.

That would make one large web.xml if I had to do that for 150+ large pages in our system. 2.2.4 does not require that to be fast.





[JAVASERVERFACES-3191] Serialization and CDI Viewscope Created: 24/Feb/14  Updated: 17/Apr/14

Status: Open
Project: javaserverfaces
Component/s: integration
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dev42 Assignee: Ed Burns
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apache Tomcat 7.0.50 (64bit), Jboss Weld 2.1.2.Final or Apache OpenWebBeans 1.2.1


File Attachments: Zip Archive JAVASERVERFACES-3191-example.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1268 javax.faces.view.ViewScoped should be... Open
is related to JAVASERVERFACES-3199 Make sure the view map is also synchr... Resolved
Tags:
Participants: codylerum, dev42, Ed Burns, Jozef Hartinger, Manfred Riem and rhusar

 Description   

Currently, when beans with the CDI viewscope annotation are used, these are stored in the session variable 'com.sun.faces.application.view.activeViewContexts'.
When a bean is created, JSF puts it into that map and uses a non-serializable object as key (instances of org.apache.webbeans.component.ManagedBean for Apache OpenWebBeans and org.jboss.weld.bean.ManagedBean for Jboss Weld):

com.sun.faces.application.view.ViewScopeContextManager:

public <T> T createBean(FacesContext facesContext, Contextual<T> contextual, CreationalContext<T> creational) {
	if (LOGGER.isLoggable(Level.FINEST)) {
		LOGGER.log(Level.FINEST, "Creating @ViewScoped CDI bean using contextual: {0}", contextual);
	}

	T result = contextual.create(creational);

	if (result != null) {
		String name = getName(result);
		facesContext.getViewRoot().getViewMap(true).put(name, result);
		getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
	}

	return result;
}

When the session state is serialized, for example during session replication or webserver reboot, serialization exceptions occur and the serialization fails:

Cannot serialize session attribute com.sun.faces.application.view.activeViewContexts for session 8FE5F6468D0F58D64A4D7B13B9E65A12
java.io.NotSerializableException: org.apache.webbeans.component.ManagedBean
	- custom writeObject data (class "java.util.concurrent.ConcurrentHashMap")
...

The same error happens with org.jboss.weld.bean.ManagedBean under Weld.

Occurs with both the newest Weld and OpenWebBeans implementations:
Apache OpenWebBeans 1.2.1
Jboss Weld 2.1.2.Final



 Comments   
Comment by Manfred Riem [ 24/Feb/14 02:18 PM ]

Can you please provide reproducer without any 3rd party libraries? Thanks!

Comment by dev42 [ 25/Feb/14 02:46 PM ]

I can put together a reproduction example, but somehow i am not allowed to attach any files to this issue. Does that action require special privileges in jira?

Comment by Manfred Riem [ 25/Feb/14 05:47 PM ]

Please send the zip file to issues@javaserverfaces.java.net. Thanks!

Comment by codylerum [ 05/Mar/14 03:16 PM ]

Shouldn't @ViewScoped be @NormalScope(passivating = true)

http://docs.oracle.com/javaee/7/api/javax/faces/view/ViewScoped.html

Comment by rhusar [ 05/Mar/14 05:43 PM ]

I would think so. Use of @ViewScoped annotation requires that the beans stored in this scope be serializable, thus should set passivating = true.

This change along with making ViewScopeContextObject serializable, passes the test. Here is a patch:

diff --git a/jsf-api/src/main/java/javax/faces/view/ViewScoped.java b/jsf-api/src/main/java/javax/faces/view/ViewScoped.java
index a0fea3b..777712d 100644
--- a/jsf-api/src/main/java/javax/faces/view/ViewScoped.java
+++ b/jsf-api/src/main/java/javax/faces/view/ViewScoped.java
@@ -115,7 +115,7 @@ import javax.enterprise.context.NormalScope;
 
  * @since 2.2
  */
-@NormalScope
+@NormalScope(passivating = true)
 @Inherited
 @Documented
 @Target({ElementType.TYPE, ElementType.FIELD, ElementType.METHOD})
diff --git a/jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeContextObject.java b/jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeContextObject.java
index 632dc83..6634713 100644
--- a/jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeContextObject.java
+++ b/jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeContextObject.java
@@ -39,6 +39,7 @@
  */
 package com.sun.faces.application.view;
 
+import java.io.Serializable;
 import javax.enterprise.context.spi.Contextual;
 import javax.enterprise.context.spi.CreationalContext;
 
@@ -46,7 +47,7 @@ import javax.enterprise.context.spi.CreationalContext;
  * An object used by ViewScopeContext to keep track of contextual and creational
  * context.
  */
-class ViewScopeContextObject {
+class ViewScopeContextObject implements Serializable {
 
     /**
      * Stores the contextual.
Comment by Ed Burns [ 06/Mar/14 07:26 PM ]

I have filed JAVASERVERFACES_SPEC_PUBLIC-1268 to cover the spec side of this. We're going to try and put it in right away, but if this causes the TCK signature tests to fail, then we'll only be able to put in the jsf-ri side of it.

Thanks for the post.

Ed

Comment by dev42 [ 10/Mar/14 06:41 AM ]

Thank you all for the quick replies and patch suggestions, looking forward to version 2.2.6!

Best regards,

Bernhard

Comment by Manfred Riem [ 19/Mar/14 02:47 PM ]

After applying the fix and seeing what it would do I am going to push back. We have conflicting requirements here. A @ViewScoped bean requires @PostConstruct and @PreDestroy to be called on it, but it does not define how to deal with passivation, at least not from the specification perspective.

So I propose I make a ViewScopeContextMap which itself is serializable, but its contents (ViewScopeContextObject instances) will be transient. This way it will be a proper bean with respect to the session, but also keep the contract of @ViewScoped. Note I do think that the specification issue can stay as we need to at minimum clarify in the spec whether or not @ViewScoped does participate in passivation and if they do how!

Comment by Jozef Hartinger [ 10/Apr/14 08:47 PM ]

I cannot see a problem with that. There are other passivating CDI scopes (e.g. @SessionScoped, @ConversationScoped or @TransactionScoped). None of the scopes/specs introduces any special passivation/activation callbacks. I find the java.io.Serializable/Externalizable contract sufficient for this purpose.

Comment by codylerum [ 10/Apr/14 10:42 PM ]

Manfred wouldn't the @ViewScoped beans then be lost during clustering?

Comment by Ed Burns [ 16/Apr/14 09:00 PM ]

In the absence of a proper fix for JAVASERVERFACES_SPEC_PUBLIC-1268, we can avoid the problem is to avoid the exception by excluding the @ViewScoped beans from participating in the session replication. One approach for doing that is to use something like Trinidad's TransientHolder. http://grepcode.com/file/repo1.maven.org/maven2/org.apache.myfaces.trinidad/trinidad-api/2.1.0/org/apache/myfaces/trinidad/util/TransientHolder.java

Comment by Ed Burns [ 17/Apr/14 02:44 PM ]

The workaround for this in WildFly is <https://github.com/wildfly/wildfly/pull/6153/files>.





[JAVASERVERFACES-3184] Support namespacing of parameters according to NamingContainer rules (JSF 2.2 forward port) Created: 19/Feb/14  Updated: 25/Mar/14

Status: Open
Project: javaserverfaces
Component/s: configuration, portlet
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Neil Griffin Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File 20140220-liferay-3184.patch    
Tags:
Participants: Ed Burns and Neil Griffin

 Description   

Similar to JAVASERVERFACES-3031 (which was applied to the (MOJARRA_2_1X_ROLLING) branch, the patch for supporting namespacing of parameters needs to be applied to the MOJARRA_2_2X_ROLLING branch as well.



 Comments   
Comment by Neil Griffin [ 20/Feb/14 10:22 PM ]

I just attached a patch to an email sent to issues@javaserverfaces.java.net





[JAVASERVERFACES-3172] Make it so system error messages only end up in the page when ProjectStage is Development Created: 07/Feb/14  Updated: 07/Feb/14

Status: Open
Project: javaserverfaces
Component/s: lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 days, 23 hours, 50 minutes
Time Spent: 10 minutes
Original Estimate: 3 days

Tags:
Participants: Ed Burns

 Description   

See Bug17006700 if available. Otherwise, here's the idea. Giving a stack trace away is a free tip to a malicious user. It's better to not give that sort of thing away. I propose we make it so unless ProjectStage is Development, we don't send error information to the client. This includes for Ajax.

I propose a short-circuit <context-param> for testing that disables this suppression. We would have to modify the web.xml files for all the tests to have this context param, because I know some of the tests assert for this error information.






[JAVASERVERFACES_SPEC_PUBLIC-1262] web_partialresponse_2_2.xsd uses incorrect cardinality on partial-response element. Created: 03/Feb/14  Updated: 07/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES-3171 Exception during render on Ajax reque... Closed
Tags:
Participants: Ed Burns

 Description   

The XSD file for the partial-response element states that a <partial-response> may have exactly one of <changes>, <redirect>, or <error> as a child element. This is incorrect. We should allow any number and combination of those child elements for maximum flexibility.

This problem manifests itself when the server needs to send an <error> response when some <changes> response data has already been written to the response. This can happen if there is an error during rendering.






[JAVASERVERFACES-3142] Expose more powerful injection SPI Created: 13/Jan/14  Updated: 11/Apr/14

Status: Open
Project: javaserverfaces
Component/s: integration
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Jozef Hartinger Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns, Jozef Hartinger and Manfred Riem

 Description   

The current injection SPI (InjectionProvider.java) is limited and does not allow for certain CDI features to be enabled on JSF-managed instances, such as constructor injection and interception.



 Comments   
Comment by Manfred Riem [ 13/Jan/14 06:26 PM ]

Jozef, can you please discuss with us what you think would be needed here? Thanks!

Comment by Ed Burns [ 20/Feb/14 02:31 PM ]

De-prioritize due to no response.

Comment by Manfred Riem [ 25/Mar/14 06:06 PM ]

Lowering priority because of no response

Comment by Jozef Hartinger [ 11/Apr/14 02:58 PM ]

Sorry for the delay. Initially I thought that the current injection SPI (InjectionProvider.java) should be replaced with something more powerful, that allows an integrator to provide a class instance. However, now I came to a conclusion that it would be better for Mojarra to just use the CDI SPI to obtain InjectionTarget<T> instance for each component and use those to create component instances. Not sure if that happens currently.

Comment by Manfred Riem [ 11/Apr/14 03:19 PM ]

Jozef, thanks for responding. Could you include a minor example of how it needs to work?





[JAVASERVERFACES_SPEC_PUBLIC-1256] FacesContextWrapper should call FacesContext.setCurrentinstance(this) in its default constructor Created: 10/Jan/14  Updated: 23/Jan/14

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle.txt    
Tags:
Participants: Ed Burns, Hanspeter Duennenberger and Manfred Riem

 Description   

A common mistake when wrapping FacesContext is to forget to call FacesContext.setCurrentInstance(this) from within the constructor of the new CustomFacesContext extending FacesContextWrapper. Without that call, FacesServlet will use the wrapped FacesContext, but FacesContext.getCurrentInstance() would only return the wrapped RI's FacesContextImpl, but not the wrapper chain.

The call of FacesContext.setCurrentInstace(this) in the default constructor of FacesContextWrapper would prevent this mistake easily.



 Comments   
Comment by Ed Burns [ 22/Jan/14 08:26 PM ]

r=edburns.

Comment by Manfred Riem [ 22/Jan/14 09:28 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3141, r=edburns, make sure the correct FacesContext is set by a wrapped FacesContext."
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Transmitting file data .
Committed revision 12783.

Comment by Manfred Riem [ 23/Jan/14 04:49 PM ]

Applied to 2.2 branch,

svn commit -m "Reverting as this violates the current TCK"
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Transmitting file data .
Committed revision 12786.

Comment by Manfred Riem [ 23/Jan/14 04:50 PM ]

Issue moved to the SPEC tracker as affecting the current fix violates tests in the TCK. Hence this has to wait for the next SPEC cycle.





[JAVASERVERFACES_SPEC_PUBLIC-1264] allow use of Servlet init parameter Created: 10/Jan/14  Updated: 06/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns, Hanspeter Duennenberger and Manfred Riem

 Description   

Sometimes it is useful to configure multiple FacesServlet instances with some common and some distinct configuration.
Currently this is not possible - ExternalContext.getInitParameter(name) only provides access to ServletContext init parameters, but not to ServletConfig init parameters.

web.xml allows <context-param>s within <web-app> but also also <init-param>s within <servlet>.
The current ExternalContext interface provides no access to Servlet init-params. It would also be problematic to expose Servlet-init-param explicitly since Portlet API would not match.

A simple solution though would be that ExternalContext.getInitParameter(name) would first consult the Servlet <init-param> and second the web-app <context-param>s.
It would then also make sense to cache the so resolved parameters on FacesContext to optimize multiple access to the same init-parameter.

This proposal most likely affects the SPEC - if accepted create a SPEC issue as well.

regards
Hanspeter



 Comments   
Comment by Manfred Riem [ 06/Feb/14 04:40 PM ]

As this indeed has a major specification impact it has been moved to the spec issue tracker





[JAVASERVERFACES_SPEC_PUBLIC-1255] f:view contracts="#{bean.contracts}" should allow to return null from the bean to let contracts be calculated from configurarion Created: 10/Jan/14  Updated: 22/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and Hanspeter Duennenberger

 Description   

com/sun/faces/facelets/tag/jsf/core/ViewHandler uses TagAttribute.getValue() to retrieve the contracts EL expression value - EL (before 3.0) will coerce null from the bean.contracts to "" and make no contract active.

If ViewHandler would use TagAttribute.getObject() null would be evaluated to null and the contracts calculation from the configuration would be used.

This might as well affect the spec - if this is accepted, a SPEC issue has to be created as well.






[JAVASERVERFACES-3130] NavigationHandlerImpl differs from specification if a matching navigation-case element was located Created: 03/Jan/14  Updated: 27/Feb/14

Status: In Progress
Project: javaserverfaces
Component/s: navigation
Affects Version/s: 2.2.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: TobiasTRD Assignee: Ed Burns
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RI 2.2.4 with Tomcat 7


File Attachments: Zip Archive navigation-3130.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1265 Clarify that a piece of text in the n... Open
Tags:
Participants: Ed Burns and TobiasTRD

 Description   

The spec for navigation says in chapter 7.4.2

If a matching <navigation-case> element was located, proceed as follows.
If the <to-view-id> element is the id of a flow, discover that flow's start node and resolve it to a vdl view
identifier by following the algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call
Nodes other than ViewNodes"
If the <to-view-id> element is a non-view flow node, resolve it to a vdl view identifier by following the
algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call Nodes other than
ViewNodes".

Now we have the following button
<h:commandButton value="submit" action="enterFlow" />

So with the following navigation rule in faces-config.xml I would expect to open 'myFlow' because the navigation case matches to the outcome 'enterFlow' and the spec says we use the to-view-id to get the flow-id.
<navigation-rule>
<from-view-id>/index.xhtml</from-view-id>
<navigation-case>
<from-outcome>enterFlow</from-outcome>
<to-view-id>myFlow</to-view-id>
<to-flow-document-id />
<redirect />
</navigation-case>
</navigation-rule>

But the NavigationHandlerImpl uses the from-outcome and navigates to a flow called enterFlow that I don't have.
This is because of two implementation details in NavigationHandlerImpl.

1. private CaseStruct determineViewFromActionOutcome(FacesContext ctx, Set<NavigationCase> caseSet, String fromAction, String outcome, String toFlowDocumentId)
...
result.isFlowEntryFromExplicitRule = null != fh.getFlow(ctx, toFlowDocumentId, outcome);

Line 1271 uses the outcome to get the flow and not result.viewId

2. private CaseStruct getViewId(FacesContext ctx, String fromAction, String outcome, String toFlowDocumentId)
...
// and try to call into the flow
caseStruct = findFacesFlowCallMatch(ctx, fromAction, outcome, toFlowDocumentId);

Line 495 also uses the outcome to overwrite the CaseStruct. So again we search for the flow 'enterFlow' and not 'myFlow'.

The second part of the spec 'if the <to-view-id> element is a non-view flow node' is also not working.

If we have the following flow definition:
<flow-definition id="myFlow">
<switch id="switch">
<case>
<if>#{myBean.check}</if>
<from-outcome>doSomething</from-outcome>
</case>
<default-outcome>gotoEnd</default-outcome>
</switch>
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>testcase</from-outcome>
<to-view-id>switch</to-view-id>
<redirect />
</navigation-case>
</navigation-rule>
</flow-definition>

<h:commandButton value="submit" action="testcase" />

If I click the submit button we get the navigation-case with outcome 'testcase' and to-view-id 'switch'. So the to-view-id is a non view node and spec would have us to resolve the node and handle the response with the switch element and finally go to 'doSomething' if #{myBean.check} is true. But we are redirected to the switch.xhtml that doesn't exist.
Since I didn't use <to-flow-document-id /> in the definition the CaseStruct is not touched after the first match. If I use to-flow-document-id we would use the outcome and not the to-view-id for the new navigation. This is because of the bug mentioned above. But at some point I read that using to-flow-document-id inside a flow should not work (don't remember where). Because we call other flows only with flow-call.



 Comments   
Comment by TobiasTRD [ 03/Jan/14 05:41 PM ]

My problem with https://java.net/jira/browse/JAVASERVERFACES-3050 was misunderstood.

The important part of the spec is "If a matching <navigation-case> element was located, proceed as follows. ...". So in both cases we are talking from a <navigation-case> and not the direct use of the flow-id or node-id.
I could work without <navigation-case> and use the ids directly as mentioned in 3050. But the spec allows the detour over the <navigation-case>. So in my opinion either the spec or the implementation is wrong or at least misleading.

On issue #1

As chapter 7.4.2 of the spec says (page 7-11) for a matching <navigation-case> the <to-view-id> is resolved to a flow-id. But the current implementation uses the <from-outcome> as the flow-id. So in the given example I would expect to enter 'myFlow' and not 'enterFlow'.

On issue #2

Refers to the same part of the spec (next sentence). If the <to-view-id> is a non-view flow node we need to resolve it first. In my example the action 'testcase' resolves to a matching <navigation-case> with valid <to-view-id> 'switch' that is a non-view flow node. So the id must be resolved as described in chapter 7.4.2.1. The result of the navigation should be either 'doSomething' or 'gotoEnd'. The same problem occurs with the outcome 'testreturn' in my example. It should resolve to the flow-return node and not to returnFromFlow.xhtml.

Comment by TobiasTRD [ 03/Jan/14 05:46 PM ]

I have created an example project with navigation rules. How can I add an attachment?

Comment by Ed Burns [ 03/Jan/14 05:48 PM ]

Please send an email with the example as an attachment to issues@javaserverfaces.java.net . I really appreciate you taking the time to make an example.

Comment by TobiasTRD [ 10/Jan/14 01:28 PM ]

Did you get the example? I mailed it to the mailinglist but I can't see it there.

Comment by Ed Burns [ 24/Jan/14 11:07 PM ]

Thank you for the reproducer. I'm delighted to see you used the test archetype. I hope that made it faster to create. It certainly makes it easier to see the problem. I'm working on a fix now.

Comment by Ed Burns [ 24/Jan/14 11:16 PM ]

I found what looks like a typo in the example.

The index.xhtml page has

<h:commandButton value="enter wrong flow" action="enterFlow" />

and the faces-config.xml has

<navigation-rule>
		<from-view-id>/index.xhtml</from-view-id>
		<navigation-case>
			<from-outcome>entryFlow</from-outcome>
			<to-view-id>myFlow</to-view-id>
			<redirect />
			<to-flow-document-id />
		</navigation-case>
	</navigation-rule>

Note, there is a mismatch between the <from-outcome> and the "action" attribute.

When I correct the "action" attribute to be "entryFlow" instead of "enterFlow" I now get a 404 on the redirect. I'm still debugging this, but I did want to report this apparent problem with the reproducer. Please confirm it is ok to make that change.

Comment by Ed Burns [ 24/Jan/14 11:18 PM ]

Corrected apparent typo.

Comment by TobiasTRD [ 25/Jan/14 04:18 PM ]

O sorry. This bug came in when I had to transfer my application to the reproducer.

To reproduce the bug it doesn't matter if you change the action to entryFlow or the navigation case to enterFlow. In both cases the action should match the navigation case. In this case a navigation to the flow myFlow is expected.
I intended to write enterFlow in the navigation because I do have an enterFlow in the example.

The second issue comes when you click on action="testcase" or action="testreturn" in myFlow.

Comment by Ed Burns [ 07/Feb/14 10:23 PM ]

Concerning the second part of the bug:

The second part of the spec 'if the <to-view-id> element is a non-view flow node' is also not working.

If we have the following flow definition:

<flow-definition id="myFlow">
<switch id="switch">
<case>
<if>#{myBean.check}</if>
<from-outcome>doSomething</from-outcome>
</case>
<default-outcome>gotoEnd</default-outcome>
</switch>
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>testcase</from-outcome>
<to-view-id>switch</to-view-id>
<redirect />
</navigation-case>
</navigation-rule>
</flow-definition>

<h:commandButton value="submit" action="testcase" />

Can you please confirm that this second part only deals with navigation once you are inside a flow? If not, I assert the second part is not a valid bug because the <navigation-case> inside of a flow only takes effect when you are already in the flow.

Granted, that's not clear from this text

If the <to-view-id> element is a non-view flow node, resolve it to a vdl view identifier by following the
algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call Nodes other than
ViewNodes".

I'll file a spec issue to clarify that.

In any case, can you please confirm that your part to is not talking about entering a flow, but rather is talking about navigation within a flow?

Comment by TobiasTRD [ 27/Feb/14 05:44 PM ]

Yes the second part comes only if you are navigating inside a flow.
So this works only (or not with the bug) if you are on the example page of myFlow.





[JAVASERVERFACES-3129] The combination of enctype="multipart/form-data" and ajax stops navigation in some scenarios Created: 03/Jan/14  Updated: 11/Mar/14

Status: Reopened
Project: javaserverfaces
Component/s: ajax, view handling
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Fuhrmann Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, glassfish 4.0, Mojarra JSF Implementation 2.2.5 (20131231-1412-SNAPSHOT)


File Attachments: PDF File 20140107-i_moj_3129-bugreport.pdf     Zip Archive 20140107-i_moj_3129-bugreport.zip     Zip Archive 20140306-i_moj_3129-reproducer.zip    
Tags:
Participants: Ed Burns, Manfred Riem and Thomas Fuhrmann

 Description   

When I use ajax functionality to manipulate data of a view scoped bean the navigation does not work anymore if a form of type enctype="multipart/form-data" gets submitted. The expected action method is called and even the preRenderView event of the next page is called. But the next page gets not presented in the browser (ie and ff). I use two forms inside the xhtml page to manipulate the data. When I remove the enctype="multipart/form-data" everything works as expected.

I will send an example application to reproduce the problem. It is a little application used to administrate materials. I have created a static material repository where one material with the title "First Material" is predefined. Every material has a title (must be unique) and a list of authorizations for teachers. Only two teachers are available (static data too). When accessing the application you get presented a list view showing all materials (only one for now). When you click on the edit symbol behind the material you will be forwarded to a material edit page. Please click on the edit symbol of the predefined authorization for the teacher "Peter Test". This will trigger an ajax action which loads the stored authorization inside the form on top of the page. Now it is possible to edit this authorization. But there is no need for other actions. Just hit the save button at the buttom of the page. This should delegate you back to the list view (after saving the material data set). The Action gets called, but the list page gets not presented.



 Comments   
Comment by Thomas Fuhrmann [ 03/Jan/14 03:43 PM ]

I forgot to change the predefined priority, sorry. This one should be minor. To which email address should I send the example app?

Comment by Manfred Riem [ 03/Jan/14 03:47 PM ]

Please send it to issues@javaserverfaces.java.net

Comment by Manfred Riem [ 06/Jan/14 02:27 PM ]

Using your example I am unable to reproduce this on GF 4.0 + the latest 2.2.5 SNAPSHOT.

Can you please try with the latest SNAPSHOT and also add the following snippet to your pages so you can verify you are running the latest 2.2.5-SNAPSHOT?

<h:outputText value="#{FacesContext.getCurrentInstance().getClass().getPackage().getImplementationVersion()}"/>

Thanks!

Comment by Thomas Fuhrmann [ 06/Jan/14 03:17 PM ]

I just retested it with this snapshot: javax.faces-2.2.5-20140103.164528-43 - same behaviour

The <h:outputText value="#{FacesContext.getCurrentInstance().getClass().getPackage().getImplementationVersion()}"/> did not work so I chamged it to the following:

<h:outputText value="#{material.version}" /> in the layout.xhtml

and this method in the material bean:

public String getVersion() { return FacesContext.getCurrentInstance().getClass().getPackage().getImplementationVersion(); }

The output is 2.2.5-SNAPSHOT

Here the steps I did:

1. Access the aplication using http://localhost:8080/Bugreport/
2. Click on the edit symbol behind "First Material" (alt text "editMaterial")
3. Click on the edit symbol behind "Peter Test: read" (alt text "edit Authorization")
4. Press the blue save button -> the list page should be shown once again (the one which is available under http://localhost:8080/Bugreport/) but the browser still Shows the edit page

Comment by Thomas Fuhrmann [ 06/Jan/14 04:11 PM ]

The used Java Version: jdk1.7.0_05

I could send you the whole Glassfish installation dir with the deployed app if you can't reproduce the bug. Is there some sort of drop box available?

If you change the cancle button from <h:button value="cancel" outcome="/facelets/material/showMaterial" styleClass="cancelButton" /> to (the old fashioned way) <h:commandButton value="cancel" immediate="true" action="/facelets/material/showMaterial" styleClass="cancelButton" /> it does not work either. Than you can user the save or the cancle button. Both do not return to the list page. Maybe this is helpful ...

Comment by Manfred Riem [ 06/Jan/14 07:21 PM ]

Unfortunately when you are specifying your render targets you cause the f:metadata section not be executed. Change your render target to @all and you will see it works. Note if you change it to do a render="@form" and it will still not work. You might want to consider to rework this not to use f:metadata.

Comment by Thomas Fuhrmann [ 07/Jan/14 09:58 AM ]

Sorry, but I do not understand your comment. There is no issue with the f:metadata section. I have an issue with the enctype="multipart/form-data" in combination with Ajax calls. Maybe I was not able to describe it properly; maybe my english is too bad. When I leave the enctype definition of the html form everything works as expected. I eased up the example application and I will send you the application once again together with a little pdf document describing the issue step by step.

Thanks for your investigations!

Comment by Ed Burns [ 08/Jan/14 06:34 PM ]

Sent via email on 2014-01-07.

Comment by Ed Burns [ 08/Jan/14 06:42 PM ]

I'm taking another look at this now. Thank you for your excellent documentation. I hope the reproducer works as well as the PDF looks.

Comment by Ed Burns [ 08/Jan/14 07:35 PM ]

When you say

the presented page will still be the material edit view instead of the material list view.

you mean when this method gets executed

MaterialBean.java
public String update() {
		removeTempAuthorizationIds();
		MaterialRepository.updateMaterial(TransferObjectFactory.createMaterialTransferObject(this));
		return "/facelets/material/showMaterial";
	}

we get a redisplay of the editMaterial.xhtml page instead of a navigation to the showMaterial page.

Am I understanding you correctly?

Comment by Thomas Fuhrmann [ 09/Jan/14 08:51 AM ]

Yes, that is correct.

It seems that the navigation is not completely broken because even though the showMaterial.xhtml page is not displayed, its preRenderView event gets executed and this is only defined in the xhtml page itself (you can recognize the execution when debugging the method).

I simplified the Bugreport-Application again. Maybe the preRenderView stuff and the TeacherBean and AuthorizationBean classes are too confusing. There is only a partial ajax rendering and a form of enctype="multipart/form-data" needed to determine the issue.

I will send you the changed application during the next hours.

After the ajax call neither the save nor the cancel button works. If you remove the enctype="multipart/form-data" both work correctly.

Greetings and thanks,
Thomas





[JAVASERVERFACES_SPEC_PUBLIC-1250] Some not existing classes in chapter 5.4.1 Created: 03/Jan/14  Updated: 03/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: tremes Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and tremes

 Description   

In specified chapter in TABLE 5-3 there are mentioned following artifacts (among others):

javax.faces.view.ViewDeclarationFactory
javax.faces.view.facelets.FaceletFactory

I can't see these in 2.2.4 api. There's only javax.faces.view.ViewDeclarationLanguageFactory.



 Comments   
Comment by tremes [ 03/Jan/14 07:54 AM ]

And javax.faces.context.FlashFactory is likely missing.





[JAVASERVERFACES_SPEC_PUBLIC-1239] HTML_BASIC components converter attribute supports converterId, as well as the already stated ValueExpression that points to a Converter Created: 27/Nov/13  Updated: 27/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags:
Participants: Ed Burns

 Description   

The tags for all of the HTML_BASIC components in Facelets have a "converter" attribute that is specified to do the following.

Type:

javax.el.ValueExpression
(must evaluate to javax.faces.convert.Converter)

Description:

Converter instance registered with this component.

In practice, looking at com.sun.faces.facelets.tag.jsf.ValueHolderRule, this also supports a value that is a converter id.

The spec should be updated to reflect this reality.






[JAVASERVERFACES_SPEC_PUBLIC-1238] Enhance component referencing / findComponent Created: 15/Nov/13  Updated: 15/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript, Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: tandraschko Assignee: Ed Burns
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and tandraschko

 Description   

Currently component referencing with the JSF API is very limited.
Keywords can currently only be used with f:ajax and not for e.g. outputLabel "for" attribute.
Also keywords cant be combined and we dont even have many keywords.

For PrimeFaces, i created a small modular API to enhance the search alogorithm as you can read here:
http://blog.primefaces.org/?p=2740

Noteable features are:

  • keywords can be used for all components
  • combinable keywords like @composite:@parent or @form:myId
  • currently a (limited) pluggable framework to allow new keywords for endusers

For the JSF API, a new artifact for resolving expression for findComponent (like ViewHandler etc.) would be great and can easily be enhanced by component libraries.
Maybe something like "ComponentExpressionResolver".

If its somehow possible, i would like to help to create and finalyze the API.

Sorry for Issue 1237 - please close it.






[JAVASERVERFACES_SPEC_PUBLIC-1237] Enhance component referencing / Created: 15/Nov/13  Updated: 15/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: tandraschko Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and tandraschko




[JAVASERVERFACES-3010] Make it so Groovy beans can be full fledged CDI beans. Created: 27/Aug/13  Updated: 27/Mar/14

Status: Open
Project: javaserverfaces
Component/s: managed bean
Affects Version/s: 2.1.18, 2.1.19, 2.1.20, 2.1.21, 2.1.22, 2.1.23, 2.1.24, 2.1.25, 2.2.0, 2.2.1, 2.2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours

Issue Links:
Dependency
depends on JAVASERVERFACES-3005 Re-enable Groovy test from JAVASERVER... Closed
Tags:
Participants: Ed Burns

 Description   

Make it so Groovy beans can be full fledged CDI beans.






[JAVASERVERFACES-2798] ClientWindow: deal gracefully with multiple client windows having the same id Created: 14/Mar/13  Updated: 26/Mar/14

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES_SPEC_PUBLIC-1172



 Comments   
Comment by Ed Burns [ 14/Mar/13 03:03 AM ]

This issue can be fixed independent of JAVASERVERFACES_SPEC_PUBLIC-1172.





[JAVASERVERFACES-3244] jsf:action on html buttons (still) changes the rendered markup Created: 16/Apr/14  Updated: 16/Apr/14

Status: Open
Project: javaserverfaces
Component/s: renderkit
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: squikly Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows7, Apache Tomcat 7.0.22


Tags:
Participants: Manfred Riem and squikly

 Description   

Bug JAVASERVERFACES-3169 (https://java.net/jira/browse/JAVASERVERFACES-3169) is not fixed: jsf:action on html buttons still changes the rendered markup.

This markup:

<button jsf:action="#{bean.action}">
myButton
</button>
<div class="panel-body">
<div class="row">
<div class="col-1"> 1 </div>
<div class="col-2">
<select class="form-control">
<option>opt1</option>
<option>opt2</option>
</select>
</div>
<div class="col-3"> 3 </div>
<div class="col-4"> 4 </div>
</div>
</div>

is rendered like this:

<button value="" name="j_idt41" type="submit">
myButton
</button>
<div class="panel-body">
<div class="row">
<div class="col-1"> 1 </div>
<div class="col-2">
<select id="criteria-verb" class="form-control">
<option>opt1</option>
</select>
<option>opt2</option>
</div>
</div>
</div>
<div class="col-3"> 3 </div>
<div class="col-4"> 4 </div>

Removing jsf:action parameter, markup is properly rendered.



 Comments   
Comment by Manfred Riem [ 16/Apr/14 01:34 PM ]

Please send a reproducer to issues@javaserverfaces.java.net. Thanks!





[JAVASERVERFACES-3241] java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 Created: 11/Apr/14  Updated: 16/Apr/14

Status: Open
Project: javaserverfaces
Component/s: ajax, composite components, state saving
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: thomas.meister Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File JAVASERVERFACES-3241.patch    
Tags:
Participants: Manfred Riem and thomas.meister

 Description   

IndexOutOfBoundsException caused by javax.faces.component.AttachedObjectListHolder::restoreState(FacesContext context, Object state)



 Comments   
Comment by thomas.meister [ 11/Apr/14 10:58 AM ]

} else {
// assume 1:1 relation between existing attachedObjects and state
for (int i = 0, len = attachedObjects.length; i < len; i++) {
T l = this.attachedObjects.get;
if (l instanceof StateHolder) { ((StateHolder) l).restoreState(context, attachedObjects[i]); }
}
}

// this.attachedObjects seems to be empty whereas state contains some objects in my case....

Comment by thomas.meister [ 11/Apr/14 10:59 AM ]

my error stacktrace:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at javax.faces.component.AttachedObjectListHolder.restoreState(AttachedObjectListHolder.java:165)
at javax.faces.component.UIInput.restoreState(UIInput.java:1423)
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy$2.visit(FaceletPartialStateManagementStrategy.java:380)
at com.sun.faces.component.visit.FullVisitContext.invokeVisitCallback(FullVisitContext.java:151)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1689)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UINamingContainer.visitTree(UINamingContainer.java:163)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UINamingContainer.visitTree(UINamingContainer.java:163)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIForm.visitTree(UIForm.java:371)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1700)
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:367)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138)
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:572)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:148)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353)
at org.omnifaces.viewhandler.RestorableViewHandler.restoreView(RestorableViewHandler.java:66)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
:
:

Comment by Manfred Riem [ 11/Apr/14 01:12 PM ]

Please send a reproducer in a zip file to issues@javaserverfaces.java.net. Thanks!

Comment by thomas.meister [ 16/Apr/14 01:36 PM ]

I tried to create a reproducer within a zip, but our project env is too complex. But I can reproduce it consequently. In case of IndexOutOfBoundsException my state param contains an object array containing a beanvalidation (JSF303) group instance (?!?), while this.attachedObjects is empty.

An additional size-check of this.attachedObjects solves my problem (see attached patch file).

Comment by thomas.meister [ 16/Apr/14 01:37 PM ]

Index: src/main/java/javax/faces/component/AttachedObjectListHolder.java
<+>UTF-8
===================================================================
— src/main/java/javax/faces/component/AttachedObjectListHolder.java (revision )
+++ src/main/java/javax/faces/component/AttachedObjectListHolder.java (revision )
@@ -40,12 +40,13 @@

package javax.faces.component;

-import javax.faces.context.FacesContext;
-import java.util.List;
-import java.util.ArrayList;
import java.lang.reflect.Array;
+import java.util.ArrayList;
import java.util.Iterator;
+import java.util.List;

+import javax.faces.context.FacesContext;
+
/**

  • <p>
  • Utility class to enable partial state saving of Lists of attached objects
    @@ -163,10 +164,12 @@
    } else {
    // assume 1:1 relation between existing attachedObjects and state
    for (int i = 0, len = attachedObjects.length; i < len; i++) {
    + if (this.attachedObjects.size() > i) {
  • T l = this.attachedObjects.get;
  • if (l instanceof StateHolder) {
  • ((StateHolder) l).restoreState(context, attachedObjects[i]);
    + T l = this.attachedObjects.get;
    + if (l instanceof StateHolder) { + ((StateHolder) l).restoreState(context, attachedObjects[i]); + }
  • }
    + }
    }
    }
Comment by Manfred Riem [ 16/Apr/14 01:40 PM ]

I am sorry but unless I have a reproducer that does not include any external dependencies I cannot just apply this patch. Unfortunately sometimes a 3rd party library does things that are not entirely correct. I need to make sure this is not the case.

Comment by thomas.meister [ 16/Apr/14 02:19 PM ]

Perhaps a 3rd party library is not entirely correct, but an IndexOutOfBoundsException is really waste.

A check of the boundaries of this.attachedObjects would really help in this situation.





[JAVASERVERFACES-3229] Ajax: page content is lost (jsf.js) Created: 05/Apr/14  Updated: 11/Apr/14

Status: Open
Project: javaserverfaces
Component/s: ajax
Affects Version/s: 2.1, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6, 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: k.ksenofontov Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: k.ksenofontov and Manfred Riem

 Description   

Hello,

Steps:
1) the page has any ajax request;
2) ajax response has javascript elements.

Actual result:
1) Some of the page content lost after ajax update;

Expected:
Ajax update correct.

The issue occurs due to wrong regexp in jsf-uncompressed.js:

function elementReplaceStr(element, tempTagName, src) has code:
src = src.replace(/<script[^>]type="text\/javascript">([\S\s]*?)<\/script>/igm,"");
which can cut content other than javascript.

The proper regexp should be:
src = src.replace(/<script[^>].?type="text\/javascript".?>([\S\s]*?)<\/script>/igm,"");

function doUpdate(element, context, partialResponseId):
the same after lines "//Remove scripts from text":
newsrc = src.replace(/<script[^>].?type="text\/javascript".?>([\S\s]*?)<\/script>/igm, "");

html = html.replace(/<script[^>].?type="text\/javascript".?>([\S\s]*?)<\/script>/igm,"");

function doInsert(element) has the same regexp also.



 Comments   
Comment by Manfred Riem [ 11/Apr/14 01:17 PM ]

Please send a reproducer in a zip file to issues@javaserverfaces.java.net. Thanks!





[JAVASERVERFACES-3228] ajax do not update viewstate when one render id not form but including form Created: 05/Apr/14  Updated: 11/Apr/14

Status: Open
Project: javaserverfaces
Component/s: ajax
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aruanruan Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: aruanruan and Manfred Riem

 Description   

1. i have two form, one has button ', another surround by a pannel, my button click event should udpate first form and second with render id using the pannel, the doUpdate function check the viewstate id, then update rende id which mean form , so the second id is one pannle, not form, so the viewstate not add into second form,

i think the code should be follows(check the children forms):

if (typeof f !== 'undefined' && f !== null && f.id !== context.formid) {
field = f.elements["javax.faces.ClientWindow"];
if (typeof field === 'undefined') { field = document.createElement("input"); field.type = "hidden"; field.name = "javax.faces.ClientWindow"; field.id = id; f.appendChild(field); }
field.value = windowId.nodeValue;
}else {
//aruan 2014.04.04 add add children form
// get container
var container = document.getElementById(temp[i]);
var forms = container.getElementsByTagName("form");
for(var j = 0;j<forms.length;j++){
f = forms[j];
if (typeof f !== 'undefined' && f !== null && f.id !== context.formid) {
field = getViewStateElement(f);
if (typeof field === 'undefined') { field = document.createElement("input"); field.type = "hidden"; field.name = "javax.faces.ViewState"; field.id = id; f.appendChild(field); }
field.value = state.nodeValue;
}
}
}



 Comments   
Comment by Manfred Riem [ 11/Apr/14 01:18 PM ]

Please send a reproducer in a zip file to issues@javaserverfaces.java.net. Thanks!





[JAVASERVERFACES-3227] when el expression has quoted string which including '{' and '}' cause ELException EL Expression Unbalanced Created: 05/Apr/14  Updated: 11/Apr/14

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aruanruan Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: aruanruan and Manfred Riem

 Description   

when i develop a dynmamic json bean use el expression like this '#{jsonBean["com.miraclet.evaluation.db.dict.AnonymousType/{name:"chinese\"}"]}
com.sun.faces.facelets.el.ELText.java throws the exception ELException("EL Expression Unbalanced: ... "

so i read the source code, the function findVarLength check char '{' into next nested level and '}' out of nested
level. when checking '}', use str == 0 mean not in string, but '{' not checking the condition,

my suggestion is the code else if ('{' == c ) {nested++;} into ' else if ('{" == c and str == 0){ nested++;}



 Comments   
Comment by Manfred Riem [ 11/Apr/14 01:20 PM ]

Please send a reproducer in a zip file to issues@javaserverfaces.java.net. Thanks!





[JAVASERVERFACES-3224] Plain HTML is lost when a composite component is added dynamically and is re-rendered Created: 04/Apr/14  Updated: 11/Apr/14

Status: Open
Project: javaserverfaces
Component/s: dynamic components
Affects Version/s: 2.1.28, 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lutzulrich Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7.0.47


File Attachments: File i_moj_3224-reproducer-dynamic-composite.rar    
Tags:
Participants: lutzulrich and Manfred Riem

 Description   

A problem similar to the one described in issue 3158.

A composite component which contains a mixture of plain HTML and JSF tags is added dynamically with FaceletContext.
If the partial response is rendered first, everything is fine.
But if another AJAX request is submitted and the part of the HTML document which contains the composite is updated,
the plain HTML is missing.

I will provide an example where the initial view already contains an instance of the Composite (dcc:foo).
There is a button for adding another instance of the foo component.
Afterwards, if one Triggers the other button 'Partial update', the updated page obviously does not look alright.

I am well aware that issue 3158 has been closed 'working as designed' and that you couldn't reproduce that error.

Note that I am using Tomcat (instead of Glassfish), as well, just as the reporter of 3158.
But I guess, there shoudn't be any difference just because of different Container implementations.






[JAVASERVERFACES-3211] f:verbatim destroy content of html page Created: 22/Mar/14  Updated: 26/Mar/14

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: krokodylowy3 Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

apache-tomcat-7.0.52,jdk1.6.0_39,winxp


Tags:
Participants: krokodylowy3 and Manfred Riem

 Description   

For backward compability users may wan't sometimes use f:verbatim tag.
Unfortunately sometetimes usege of f:verbatim destroys content of page.

Example 1 - in this example content after and in body tag is destructed

<!DOCTYPE html  [<!ENTITY nbsp "&#160;">]>
<html dir="ltr" class="client-js ve-not-available" lang="en"
	 xmlns="http://www.w3.org/1999/xhtml"
     xmlns:f="http://xmlns.jcp.org/jsf/core"
	 xmlns:jsf="http://xmlns.jcp.org/jsf"
	 xmlns:pt="http://xmlns.jcp.org/jsf/passthrough">
<head jsf:id="head">
<script src="JavaServer%20Faces.js" async=""></script>
</head>
<body jsf:id="body" class="mediawiki ltr sitedir-ltr ns-0 ns-subject page-JavaServer_Faces skin-vector action-view vector-animateLayout">
<div id="mw-page-base" class="noprint"></div>
<div id="mw-head-base" class="noprint"></div>
</body>
</html>

Example 2 - in this example first div is not enclosed and second div appeears in first div so content of page is unexpected

<!DOCTYPE html  [<!ENTITY nbsp "&#160;">]>
<html dir="ltr" class="client-js ve-not-available" lang="en"
	 xmlns="http://www.w3.org/1999/xhtml"
     xmlns:f="http://xmlns.jcp.org/jsf/core"
	 xmlns:jsf="http://xmlns.jcp.org/jsf"
	 xmlns:pt="http://xmlns.jcp.org/jsf/passthrough">
<head jsf:id="head">
<script src="JavaServer%20Faces%20-%20Wikipedia,%20the" async=""></script>
</head>
<body jsf:id="body" class="mediawiki ltr sitedir-ltr ns-0 ns-subject page-JavaServer_Faces skin-vector action-view vector-animateLayout">
<f:verbatim>
<div id="mw-page-base" class="noprint"></div>
</f:verbatim>
<div id="mw-head-base" class="noprint"></div>
</body>
</html>


 Comments   
Comment by krokodylowy3 [ 22/Mar/14 02:28 PM ]

web.xml for above example

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
        version="3.0">

	<description>JSFlive - JSF 2.2 HTML5 support</description>

	<!-- Faces Servlet -->
	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<!-- Faces Servlet Mapping -->
	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.jsf</url-pattern>
		<url-pattern>*.jspx</url-pattern>
	</servlet-mapping>

	<!-- Welcome files -->
	<welcome-file-list>
		<welcome-file>index.html</welcome-file>
	</welcome-file-list>

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

	<context-param>
		<param-name>facelets.DEVELOPMENT</param-name>
		<param-value>true</param-value>
	</context-param>
	
	<context-param> 
	  <param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
	  <param-value>2</param-value> 
	</context-param>
		
    <context-param>
        <param-name>javax.faces.SERIALIZE_SERVER_STATE</param-name>
        <param-value>false</param-value>
    </context-param>

    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>server</param-value>
    </context-param>
	
	<context-param>
		<param-name>com.sun.faces.validateXml</param-name>
		<param-value>false</param-value>
	</context-param>


</web-app>

Comment by Manfred Riem [ 26/Mar/14 02:54 PM ]

Can you please send the reproducer in a zip file to issues@javaserverfaces.java.net? That would help tremendously. Thanks!





[JAVASERVERFACES-3208] NPE when trying to evaluate a passthrough attribute in h:datatable if header facet declared Created: 20/Mar/14  Updated: 17/Apr/14

Status: Open
Project: javaserverfaces
Component/s: expression language
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: napartar Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bit + Tomcat 7


File Attachments: Zip Archive i_moj_3208-test-case.zip     Zip Archive test-case.zip    
Tags:
Participants: Manfred Riem and napartar

 Description   

Mojarra throws a Null Pointer Exception when trying to set a f:passThroughAttribute in an h:column of a h:dataTable.

The requirements are:

-Value for the passthrough attribute is an EL expression with the datatable iteration variable involved.

-The datatable has got an f:facet (header or footer) declared.

Test case:

<html xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns: p="http://xmlns.jcp.org/jsf/passthrough">
<h:head />
<h:body>
<h:dataTable value="#{bean.entities}" var="entity">
<h:column>
<f:facet name="footer">
Name
</f:facet>
<f:passThroughAttribute name="data-order"
value="#{entity.modifiedOn}" />
<h:outputText value="#{entity.name}" />
</h:column>
</h:dataTable>
<h:messages />
</h:body>
</html>

@ManagedBean
@ViewScoped
public class Bean {

public class Entity {
private String name;

private Date modifiedOn;

public Entity(String name, Date modifiedOn) { this.name = name; this.modifiedOn = modifiedOn; }

public Date getModifiedOn() { return modifiedOn; }

public String getName() { return name; }

}

/**

  • Create a List of entities with dates differing from now to now + 2 days
    */
    public List<Entity> entities = Arrays.asList(
    new Entity("name1", new Date()), new Entity("name2", new Date(
    new Date().getTime() + (1000 * 60 * 60 * 24))), new Entity(
    "name0", new Date(new Date().getTime()
    + (1000 * 60 * 60 * 48))));

public List<Entity> getEntities() { return entities; }

}

The Exception thrown is:

java.lang.NullPointerException com.sun.faces.renderkit.html_basic.HtmlResponseWriter.getAttributeValue(HtmlResponseWriter.java:1215) com.sun.faces.renderkit.html_basic.HtmlResponseWriter.flushAttributes(HtmlResponseWriter.java:1175) com.sun.faces.renderkit.html_basic.HtmlResponseWriter.closeStartIfNecessary(HtmlResponseWriter.java:1117) com.sun.faces.renderkit.html_basic.HtmlResponseWriter.writeText(HtmlResponseWriter.java:940) com.sun.faces.facelets.compiler.LiteralTextInstruction.write(LiteralTextInstruction.java:76) com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82) com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:302) com.sun.faces.renderkit.html_basic.TableRenderer.renderFooter(TableRenderer.java:270) com.sun.faces.renderkit.html_basic.TableRenderer.encodeBegin(TableRenderer.java:100) javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:864) javax.faces.component.UIData.encodeBegin(UIData.java:1133) javax.faces.component.UIComponent.encodeAll(UIComponent.java:1855) javax.faces.component.UIComponent.encodeAll(UIComponent.java:1860) javax.faces.component.UIComponent.encodeAll(UIComponent.java:1860) com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) org.apache.tomcat.websocket.server.WsFilter.do

Stackoverflow related post:

http://stackoverflow.com/questions/22510052/access-iteration-variable-in-passthrough-attribute/22516192



 Comments   
Comment by Manfred Riem [ 03/Apr/14 02:04 PM ]

Can you send a reproducer zip to issues@javaserverfaces.java.net? Thanks!





[JAVASERVERFACES-3206] FacesServlet URL-pattern mapping neglects web.xml security configuration Created: 18/Mar/14  Updated: 11/Apr/14

Status: Open
Project: javaserverfaces
Component/s: configuration
Affects Version/s: 2.2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: k0l0ssus Assignee: Manfred Riem
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish V4


Tags: security facesservlet url-pattern
Participants: DrankUpon, k0l0ssus and Manfred Riem

 Description   

Ref: http://stackoverflow.com/questions/22434622/facesservlet-url-patterns/22441493

OP noticed that using the URL mapping configuration for FacesServlet (in combination with a web.xml <security-constraint> configuration that also contained the "/faces/") allows a user to access restricted resources by adding an extra "/faces/" to page URL in the browser address bar. While OP hasn't stated his exact environment, I can confirm this is the case on my Glassfish v4, Mojarra 2.2, servlet v3.1

To reproduce:

1. In a basic JSF webapp, define FacesServlet mapping with /faces/*
2. Define a restricted web resource collection per standard JEE security configuration. This web resource should contain the "/faces/" string in the URL. For example

<security-constraint>
<display-name>TEST_SECURITY</display-name>
<web-resource-collection>
<web-resource-name>All_of_it</web-resource-name>
<description/>
<url-pattern>/faces/index.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint>
<description>roles</description>
<role-name>CLUBBER_LANG</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description/>
<role-name>CLUBBER_LANG</role-name>
</security-role>

3. Attempt to access the restricted resource with an extra "/faces/" (or any number of extra "/faces/, it doesn't make a difference) in the address bar, i.e. http://localhost/testapp/faces/faces/index.html. The restricted resource is accessible without any login prompting.



 Comments   
Comment by Manfred Riem [ 18/Mar/14 01:53 PM ]

Please verify if this is still the case in 2.2.6. Thanks!

Comment by DrankUpon [ 18/Mar/14 02:45 PM ]

Hello,

I am the OP of the issue that k0l0ssus was referring to. I have since downloladed the latest javax.faces-2.2.6.jar and added the dependency.

I can verify this issue still does exist.

Here is my current web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>faces/index.xhtml</welcome-file>
</welcome-file-list>
<security-constraint>
<display-name>ADMIN</display-name>
<web-resource-collection>
<web-resource-name>Admin Section</web-resource-name>
<description/>
<url-pattern>/faces/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<description/>
<role-name>ADMIN</role-name>
</auth-constraint>
<user-data-constraint>
<description/>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>jsfTest</realm-name>
</login-config>
<security-role>
<description/>
<role-name>ADMIN</role-name>
</security-role>
</web-app>

going to: http://localhost:8080/JSFtest/faces/admin/index.xhtml
result: Prompted for login and cannot access without validation

going to: http://localhost:8080/JSFtest/faces/faces/admin/index.xhtml
result: No login prompt and I am able to view the page.

Environment:

Javax-Faces: 2.2.6
JSF API: 2.2.0
Server: GlassFish Server Open Source Edition 4.0 (build 89)

Thank you
Vincent

Comment by Manfred Riem [ 26/Mar/14 01:58 PM ]

I am not sure by reading so I just want to make sure. Did you replace the javax.faces.jar in the GF 4 modules directory? If not can you please verify it that way? Thanks!

Comment by Manfred Riem [ 11/Apr/14 04:02 PM ]

Can you please send a reproducer in a zip file. Thanks!





[JAVASERVERFACES-3194] JSF 2.2 ViewScope context not destroyed when View Map is destroyed Created: 27/Feb/14  Updated: 03/Apr/14

Status: Reopened
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: codylerum Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mojarra 2.2.5-jbossorg-3
Wildfly 8.0.0.Final


File Attachments: Text File changebundle.txt     Text File changebundle.txt     Zip Archive eebox-example_for_mojarra.zip     Zip Archive newfiles.zip     Zip Archive newfiles.zip    
Tags:
Participants: codylerum and Manfred Riem

 Description   

Example App sent to issues@javaserverfaces.java.net

Start localhost:8080/eebox/vs.xhtml

Click on the "View Scoped" link repeatedly to see new beans created in the console. Logged inside @PostConstruct

See that no matter how many you create the @PreDestroy is never called until the HTTP session times out (2 minutes) and even then only the last 25 have @PreDestroy called.



 Comments   
Comment by Manfred Riem [ 25/Mar/14 02:16 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3194, make sure expired @ViewScoped get cleaned up properly."
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeContextManager.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeManager.java
Adding test/agnostic/el/src/main/java/com/sun/faces/test/agnostic/el/ViewExpiredBean.java
Adding test/agnostic/el/src/main/webapp/viewExpired.xhtml
Adding test/agnostic/el/src/test/java/com/sun/faces/test/agnostic/el/Issue3194IT.java
Transmitting file data .....
Committed revision 13058.

Comment by Manfred Riem [ 25/Mar/14 03:48 PM ]

Applied to 2.2 branch,

svn commit -m "Fix test bean"
Sending test/agnostic/el/src/main/java/com/sun/faces/test/agnostic/el/ViewExpiredBean.java
Transmitting file data .
Committed revision 13060.

Comment by Manfred Riem [ 25/Mar/14 05:24 PM ]

Applied to 2.2 branch,

svn commit -m "Reverting as it fails a couple of tests"
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeContextManager.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeManager.java
Deleting test/agnostic/el/src/main/java/com/sun/faces/test/agnostic/el/ViewExpiredBean.java
Deleting test/agnostic/el/src/main/webapp/viewExpired.xhtml
Deleting test/agnostic/el/src/test/java/com/sun/faces/test/agnostic/el/Issue3194IT.java
Transmitting file data ..
Committed revision 13061.

Comment by Manfred Riem [ 03/Apr/14 03:31 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3194, make sure the @ViewScoped get cleaned up properly when map overflows"
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeContextManager.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeManager.java
Sending jsf-ri/systest/src/com/sun/faces/event/DynamicAddTestCase.java
Adding test/agnostic/el/src/main/java/com/sun/faces/test/agnostic/el/ViewExpiredBean.java
Adding test/agnostic/el/src/main/webapp/viewExpired.xhtml
Adding test/agnostic/el/src/test/java/com/sun/faces/test/agnostic/el/Issue3194IT.java
Transmitting file data ......
Committed revision 13082.

Comment by Manfred Riem [ 03/Apr/14 04:24 PM ]

Applied to 2.2 branch,

svn commit -m "Revert as multiple tests are failing"
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeContextManager.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewScopeManager.java
Sending jsf-ri/systest/src/com/sun/faces/event/DynamicAddTestCase.java
Deleting test/agnostic/el/src/main/java/com/sun/faces/test/agnostic/el/ViewExpiredBean.java
Deleting test/agnostic/el/src/main/webapp/viewExpired.xhtml
Deleting test/agnostic/el/src/test/java/com/sun/faces/test/agnostic/el/Issue3194IT.java
Transmitting file data ...
Committed revision 13083.





[JAVASERVERFACES-3144] Duplicate client IDs for ViewState inputs Created: 13/Jan/14  Updated: 03/Mar/14

Status: Reopened
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Spomf Assignee: Manfred Riem
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 4 on Ubunutu 13.10


File Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Related
is related to JAVASERVERFACES-3166 ViewExpiredException after Ajax call ... Closed
Tags: viewstate clientid duplicate
Participants: Ed Burns, Manfred Riem and Spomf

 Description   

All ViewState input elements get the client ID "j_id1:javax.faces.ViewState:0". It does not matter if the ID of the form is set or auto-generated.



 Comments   
Comment by Spomf [ 13/Jan/14 03:05 PM ]

Since I cannot edit the description, I want to clearify here that the issue will lead to invalid HTML when there are multiple forms and their respective viewstate inputs have the same ID.

Additionally in the responseXML from the jsf.ajax.onEvent, the id of the update node for the view state element is "javax.faces.ViewState" and not the actual client ID which I get on other components. This will cause the status "malformedXML" in the event object and the description "During update: javax.faces.ViewState not found".

Comment by Manfred Riem [ 13/Jan/14 06:23 PM ]

Can you supply us with an example application that demonstrate the problem? Thanks!

Comment by Spomf [ 14/Jan/14 09:29 AM ]

The error in the responseXML seems to be RichFaces fault, so you can probably ignore that. Anyway, I do not see a way to upload the code so I pasted it below. I used a new, empty Maven web project in NetBeans 7.4 and added these files:

---- test.xhtml ----

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:f="http://xmlns.jcp.org/jsf/core">
<h:head>
<title>Facelet Title</title>
</h:head>
<h:body>
<h:form>
</h:form>
<h:form>
</h:form>
<h:form id="form3">
<h:inputText value="#{testBean.input}" id="input" />
<h:outputText value="#{testBean.input}" id="output" />
<h:commandButton value="Submit">
<f:ajax execute="input" render="output" />
</h:commandButton>
</h:form>
</h:body>
</html>

---- TestBean.java ----

import javax.faces.view.ViewScoped;
import javax.inject.Named;

@Named
@ViewScoped
public class TestBean {
private String input;

public String getInput() { return input; }

public void setInput(String input) { this.input = input; }
}

---- web.xml ----

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>faces/test.xhtml</welcome-file>
</welcome-file-list>
</web-app>

Comment by Ed Burns [ 17/Jan/14 05:39 PM ]

r=edburns

Comment by Manfred Riem [ 17/Jan/14 05:43 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3144, r=edburns, make sure we ask for the view state string for each h:form"
Sending jsf-ri/src/main/java/com/sun/faces/application/view/WriteBehindStateWriter.java
Adding test/agnostic/facelets/html/src/main/java/com/sun/faces/test/agnostic/facelets/html/FormDuplicateIdBean.java
Adding test/agnostic/facelets/html/src/main/webapp/formDuplicateId.xhtml
Adding test/agnostic/facelets/html/src/test/java/com/sun/faces/test/agnostic/facelets/html/Issue3144IT.java
Transmitting file data ....
Committed revision 12779.

Comment by Manfred Riem [ 21/Jan/14 03:22 PM ]

Failing TCK, reopening to address this

Comment by Manfred Riem [ 21/Jan/14 03:39 PM ]

Applied to 2.2 branch,

svn commit -m "Reverting commit"
Sending jsf-ri/src/main/java/com/sun/faces/application/view/WriteBehindStateWriter.java
Deleting test/agnostic/facelets/html/src/main/java/com/sun/faces/test/agnostic/facelets/html/FormDuplicateIdBean.java
Deleting test/agnostic/facelets/html/src/main/webapp/formDuplicateId.xhtml
Deleting test/agnostic/facelets/html/src/test/java/com/sun/faces/test/agnostic/facelets/html/Issue3144IT.java
Transmitting file data .
Committed revision 12780.

Comment by Manfred Riem [ 22/Jan/14 09:37 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3144, r=edburns, make sure we ask for the view state string for each h:form"
Sending jsf-ri/src/main/java/com/sun/faces/application/view
Sending jsf-ri/src/main/java/com/sun/faces/application/view/WriteBehindStateWriter.java
Adding test/agnostic/facelets/html/src/main/java/com/sun/faces/test/agnostic/facelets/html/FormDuplicateIdBean.java
Sending test/agnostic/facelets/html/src/main/webapp/WEB-INF
Adding test/agnostic/facelets/html/src/main/webapp/formDuplicateId.xhtml
Adding test/agnostic/facelets/html/src/test/java/com/sun/faces/test/agnostic/facelets/html/Issue3144IT.java
Transmitting file data ....
Committed revision 12785.

Comment by Manfred Riem [ 03/Mar/14 04:08 PM ]

Applied to 2.2 branch,

svn commit -m "Reverting fix for issue 3144 as it introduces issue 3166"
Sending jsf-ri/src/main/java/com/sun/faces/application/view/WriteBehindStateWriter.java
Deleting test/agnostic/facelets/html/src/main/java/com/sun/faces/test/agnostic/facelets/html/FormDuplicateIdBean.java
Deleting test/agnostic/facelets/html/src/main/webapp/formDuplicateId.xhtml
Deleting test/agnostic/facelets/html/src/test/java/com/sun/faces/test/agnostic/facelets/html/Issue3144IT.java
Transmitting file data .
Committed revision 12943.

Comment by Manfred Riem [ 03/Mar/14 04:09 PM ]

Reopening as it is now not fixed





[JAVASERVERFACES_SPEC_PUBLIC-1274] In ViewMetadata.createMetadataView() clarify state for temporary UIViewRoot Created: 10/Apr/14  Updated: 10/Apr/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Resolved
Tags:
Participants: Ed Burns

 Description   

In ViewMetadata.createMetadataView(), specify

  • the new UIViewRoot must be set as the FacesContext's viewRoot before applying the tag handlers, restoring
    the old FacesContext in a finally block.
  • The content's of the current UIViewRoot's ViewMap must be copied to the ViewMap of the new UIViewRoot
    before applying the tag handlers.





[JAVASERVERFACES_SPEC_PUBLIC-1273] Clarify what happens to the current FacesContext during the execution of ViewMetadata.createMetadataView() Created: 03/Apr/14  Updated: 03/Apr/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Resolved
Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES-3205.

first.xhtml
<f:view>
  <f:metadata>
    <f:viewParam name="id" value="#{outcomeTestFirstBean.firstId}"></f:viewParam>
  </f:metadata>

	<h:head>
	</h:head>
	<h:form>
		
		<h2>Problem description:</h2>
		When visiting this page using the following link: <a href="?id=11111">/first.jsf?id=11111</a> we can show that include-view-params causes a problem.<br/>
		Clicking the TestOutcomeLink poses no problem and will load the second page normally.<br/>
		Any postback will however try to execute the preRenderView event of the OutcomeTestSecondBean (because the metaData is parsed at ViewMetadataImpl.createMetadataView(FacesContext) line: 115)
		<br/><br/><br/>
		<h:link outcome="second" value="TestOutcomeLink" includeViewParams="true">
			<f:param name="extraParam" value="99999" />
		</h:link>
		<br/><br/><br/>
		<h:commandLink value="Postback goes BOOM" action="#{outcomeTestFirstBean.justAnAction}" />&nbsp;
		<h:commandButton value="Postback goes BOOM" action="#{outcomeTestFirstBean.justAnAction}" />
	</h:form>
</f:view>

and

second.xhtml
<f:view>
  <f:metadata>
    <f:viewParam name="id" value="#{outcomeTestSecondBean.secondId}"></f:viewParam>
    <f:event listener="#{outcomeTestSecondBean.load}" type="preRenderView" />
  </f:metadata>
	<h:head>
	</h:head>
	<h:form>
		<h:outputLabel value="#{outcomeTestSecondBean.secondId}" />
	</h:form>
</f:view>

When first.xhtml renders, the <h:link> will cause the <f:metadata>
section of second.xhtml to be executed. This will cause a dummy
UIViewRoot to be created and thrown away, per the spec. Unfortunately,
the <f:listener> in second.xhtml's <f:metadata> section ends up on
first.xhtml's UIViewRoot. The spec for
ViewMetadata.createMetadataView() must require the existing UIViewRoot,
if any, to be restored before returning from the method.






[JAVASERVERFACES_SPEC_PUBLIC-1272] Take advantage of Java SE 8 JSR-310 Time API in the javax.faces.convert package Created: 31/Mar/14  Updated: 31/Mar/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

JSF has had javax.faces.convert.DateTimeConverter since 1.0. Now that Java SE 8 has a new time API, we need to have another converter that supports this API.






[JAVASERVERFACES_SPEC_PUBLIC-1271] Simplify overriding a component's renderer Created: 27/Mar/14  Updated: 27/Mar/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms

 Description   

A component in JSF can be customized by overriding its renderer and creating a new tag for it, e.g as demonstrated here: https://weblogs.java.net/blog/mriem/archive/2013/11/07/jsf-tip-34-override-jsf-renderer-and-create-new-tag-it

This however requires a small but tedious amount of XML. As an analogy to the createTag attribute of FacesComponent a similar attribute on @FacesRenderer could simplify this task and provide a greater ease of use. E.g. the XML in the above referenced example could be replaced by the following:

@FacesRenderer(forComponentType="javax.faces.HtmlOutputText" tagName="myOutputText")
public class MyTextRenderer extends Renderer {
    // ...
}

Overriding the render of a component and keeping its existing tag requires roughly the same amount of XML, but less straightforward. It requires the user to find out what the render-kit-id, component-family and renderer-type is of the component for which they want to override. This is demonstrated e.g. here: https://weblogs.java.net/blog/mriem/archive/2013/11/05/jsf-tip-32-override-jsf-renderer

It would be great if this could be simplified to just this:

@FacesRenderer(forComponentType="javax.faces.HtmlOutputText")
public class MyTextRenderer extends Renderer {
    // ...
}

As a user often primarily knows a component by its namespace and tag name, it might be worthwhile to let the user alternatively reference the component via this kind of naming. E.g.

@FacesRenderer(forComponentTag="http://java.sun.com/jsf/html:outputText")
public class MyTextRenderer extends Renderer {
    // ...
}





[JAVASERVERFACES_SPEC_PUBLIC-1270] JavaDoc for TagDecorator regarding pass-through attributes not in line with implementation Created: 19/Mar/14  Updated: 19/Mar/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: michael_kurz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: michael_kurz

 Description   

The documentation for class TagDecorator states the following for processing attributes:

For each of argument tag's attributes obtain a reference to a TagAttribute with the following characteristics. For discussion let such an attribute be convertedTagAttribute.

  • convertedTagAttribute's location: from the argument tag's location.
  • If the current attribute's namespace is http://xmlns.jcp.org/jsf, convertedTagAttribute's qualified name must be the current attribute's local name and convertedTagAttribute's namespace must be the empty string. This will have the effect of setting the current attribute as a proper property on the UIComponent instance represented by this markup.
  • If the current attribute's namespace is empty or different from the argument tag's namespace, let the current attribute be convertedTagAttribute. This will have the effect of setting the current attribute as an attribute on the attributes map of the UIComponent instance represented by this markup.

The third item states, that attributes without a namespace or with a namespace different from the tag's namespace should be attributes of the component (and NOT pass-through attributes).

This is not in line with the implementation in Mojarra (which is correct in my opinion!). Mojarra treats all attributes of a pass-through element without a namespace as pass-through attributes. This perfectly makes sense as I would consider attributes without a prefix in a pass-through element as something belonging to the HTML tag.

With the behavior defined in the spec, this would not work:

<input type="text" jsf:id="name" jsf:value="#{bean.name}"
    placeholder="Enter name"/>

But this feels natural to me! The behavior implemented in Mojarra seems to be consistent too: pass-through attributes must be prefixed on jsf tags and jsf attributes must be prefixed on pass-through elements.

This issue popped up in MyFaces recently as MYFACES-3868 (see [1]).

[1]: https://issues.apache.org/jira/browse/MYFACES-3868






[JAVASERVERFACES_SPEC_PUBLIC-1269] Incorrect literal string value for javax.faces.application.ViewHandler.DISABLE_FACELET_JSF_VIEWHANDLER_PARAM_NAME Created: 11/Mar/14  Updated: 11/Mar/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Tags:
Participants: Ed Burns

 Description   

Spec says the value of this field should be javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER, but the code has DISABLE_FACELET_JSF_VIEWHANDLER.






[JAVASERVERFACES_SPEC_PUBLIC-1268] javax.faces.view.ViewScoped should be @NormalScoped(passivating=true) Created: 06/Mar/14  Updated: 16/Apr/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Managed Beans
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Issue Links:
Related
is related to JAVASERVERFACES-3191 Serialization and CDI Viewscope Open
Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES-3191.



 Comments   
Comment by Ed Burns [ 16/Apr/14 08:32 PM ]

I was discussing this on IM with someone from ADF and they made a good point.

if you are managing data structures hanging off of the session on the application's behalf, you are responsible for providing a mechanism for the application to mark the sub pieces as dirty

This is a core requirement for solving this issue.

Comment by Ed Burns [ 16/Apr/14 09:12 PM ]

Another important point about this issue pertains to failover and view state. If you make it so @ViewScoped beans can be failed over, then you will also have to make it so view state can be failed over.

Blake Sullivan from ADF suggests using something like <https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/util/SubKeyMap.java> to store each view state as a separate session attribute.

SubKeyMap is a convenience for flattening out the individual view state entries into separate session attributes so that they can be individually dirtied, and thus are less prone to re-replication. You still have to replicate all the view state entries, but with this solution there is less of an update burden.





[JAVASERVERFACES_SPEC_PUBLIC-1267] Clarify meaning of null return from UIComponent.getFamily() Created: 13/Feb/14  Updated: 13/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Issue Links:
Dependency
blocks JAVASERVERFACES-3180 Possible NPE in FormOmittedChecker Closed
Tags:
Participants: Ed Burns

 Description   

Clarify meaning of null return from UIComponent.getFamily().

See JAVASERVERFACES-3180.






[JAVASERVERFACES_SPEC_PUBLIC-1266] Extract Facelets as Templating for Java EE Created: 11/Feb/14  Updated: 11/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns




[JAVASERVERFACES_SPEC_PUBLIC-1265] Clarify that a piece of text in the navigation handler section of the spec only pertains when inside of a flow. Created: 07/Feb/14  Updated: 07/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3130 NavigationHandlerImpl differs from sp... In Progress
Tags:
Participants: Ed Burns

 Description   

Consider this spec text, from section 7.4.2:

If the <to-view-id> element is a non-view flow node, resolve it to a vdl view identifier by following the algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call Nodes other than ViewNodes".

That text only pertains to navigation within a flow. This restriction must be explicitly called out.






[JAVASERVERFACES_SPEC_PUBLIC-1261] inconsistent behavior with absolute contracts references like /contracts_dir/contract_name/resource.xhtml Created: 03/Feb/14  Updated: 03/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3146 absolute contract reference (e.g. tem... Closed
Tags:
Participants: Hanspeter Duennenberger

 Description   

See also https://java.net/jira/browse/JAVASERVERFACES-3146.

Absolute references to resources in contracts is not supported by design. However, with contracts deployed in /webapp_root/contracts_dir/contract_name it is possible to reference such resources using the absolute reference /contracts_dir/contract_name/resource.xhtml. Moving the same contract out to a separate jar this reference cannot be resolved anymore.

Since such absolute references are not supported by design such absolute contracts references must be prevented no mather if the contract is deployed into /webapp_root/contracts_dir or in META-INF/contracts within a jar.






[JAVASERVERFACES_SPEC_PUBLIC-1260] Allow for extensionless mapping of views Created: 31/Jan/14  Updated: 31/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3131 More flexible view mapping Closed
Tags:
Participants: Manfred Riem




[JAVASERVERFACES_SPEC_PUBLIC-1259] Allow mapping on /* Created: 31/Jan/14  Updated: 31/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3131 More flexible view mapping Closed
Tags:
Participants: Manfred Riem




[JAVASERVERFACES_SPEC_PUBLIC-1258] Declare that text output by <h:outputText> (or equivalent inline EL expressions) within script or style blocks is not escaped by default. Created: 30/Jan/14  Updated: 30/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES-3150.






[JAVASERVERFACES_SPEC_PUBLIC-1257] Prevent FaceletContext.FACELET_CONTEXT_KEY constant to be inlined by compiler Created: 27/Jan/14  Updated: 29/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: lfryc Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle.txt    
Tags:
Participants: lfryc and Manfred Riem

 Comments   
Comment by lfryc [ 27/Jan/14 12:52 PM ]

I can't see the description of the issue even though I added it.


Re-posting:

In RichFaces 5 when we compile ActionListenerHandler against Mojarra 2.2.5 and then run the code against older 2.1 release (2.1.7), we get NullPointerException.

The issue is well described in RF-13472.

The problem here is that a value of FACELET_CONTEXT_KEY contstant is inlined by compiler, but the value has changed between Mojarra 2.1 ("com.sun.faces.facelets.FACELET_CONTEXT") and 2.2 ("javax.faces.FACELET_CONTEXT"). This means the code compiled against one 2.2 won't work on 2.1 and vice versa.


What we can do is prevent compiler from inlining the FACELET_CONTEXT_KEY constant.

As suggested on stackoverflow, it is possible to use String#intern() or String#toString():

public static final String FACELET_CONTEXT_KEY = 
            "javax.faces.FACELET_CONTEXT".intern();

http://stackoverflow.com/questions/377819/are-all-compile-time-constants-inlined
http://stackoverflow.com/questions/1833581/when-to-use-intern-on-string-literals


I believe the fix should go to 2.1.x branch as well.

Comment by Manfred Riem [ 27/Jan/14 05:17 PM ]

Lukas, I have attached the change bundle and once review has done I will commit it, then when it passes the 2.2 TCK I'll will close this issue. For the 2.1 work please file a back port task pointing back to this issue. Thanks!

Comment by Manfred Riem [ 28/Jan/14 03:36 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3155, r=edburns, intern the FACELET_CONTEXT_KEY so it does not get inlined."
Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletContext.java
Transmitting file data .
Committed revision 12799.

Once the 2.2 TCK passes I will go ahead and close the issue. Thanks!

Comment by Manfred Riem [ 29/Jan/14 01:53 PM ]

Applied to 2.2 branch,

svn commit -m "Reverting change as it breaks the TCK"
Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletContext.java
Transmitting file data .
Committed revision 12804.

Comment by Manfred Riem [ 29/Jan/14 01:54 PM ]

Unfortunately as the proposed change breaks the TCK I have moved it to the spec issue tracker to put it on the table for 2.3.





[JAVASERVERFACES_SPEC_PUBLIC-1254] contracts attribute too restrictive. Created: 22/Jan/14  Updated: 22/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Dependency
blocks JAVASERVERFACES-3139 relax restriction of where to place <... Closed
Tags:
Participants: Ed Burns

 Description   

The javadoc for the contracts attribute on <f:view> includes this text.

Any use of this attribute on a non-outer-most file must be silently ignored.

A customer stated this is overly restrictive. There are cases when it would be useful to allow a "last one wins" approach. This issue suggests changing the text to read:

Any use of this attribute on a non-outer-most file is undefined.






[JAVASERVERFACES_SPEC_PUBLIC-1253] Consider enabling abandoning a flow directly for another flow Created: 17/Jan/14  Updated: 17/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive i_spec_1253-reproducer.zip     Text File i_spec_1253.patch    
Tags:
Participants: Ed Burns

 Description   

Consider an app with this arrangement.

src/main/webapp/WEB-INF/faces-config.xml
src/main/webapp/flowA/flowA-flow.xml
src/main/webapp/flowA/flowA.xhtml
src/main/webapp/flowB/flowB-flow.xml
src/main/webapp/flowB/flowB.xhtml
src/main/webapp/flowC/flowC-flow.xml
src/main/webapp/flowC/flowC.xhtml
src/main/webapp/index.xhtml
src/main/webapp/site-template.xhtml

All .xhtml pages in this app are template clients of
site-template.xhtml. The site-template.xhtml has a row of buttons along
the top that allow immediate navigation to all of the flows. The intent
is that whatever flow you're in, you want to abandon it and enter the
new flow when the corresponding button is clicked. This is not a flow
call, but rather should be treated as an atomic "abandon/enter".

The current specification does not support this cleanly.



 Comments   
Comment by Ed Burns [ 17/Jan/14 08:16 PM ]

Diff of reproducer.

Comment by Ed Burns [ 17/Jan/14 08:18 PM ]

zip of reproducer.





[JAVASERVERFACES_SPEC_PUBLIC-1252] It should be possible to specify Resource Dependencies via XML Created: 14/Jan/14  Updated: 16/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75

 Description   

From the portlet EG mailing list (Neil Griffin and Ed Burns)

NG> @Ed Burns: When you get a chance, could you please shed some light
NG> on why resource dependencies can only be done via JSF annotations,
NG> and not by faces-config.xml? Thx.

EB> I suppose it could be. It turned out to be easier to implement with
EB> annotations. I think you have discovered a wrinkle where our stated
EB> goal of having complete parity of functionality between annotations and
EB> XML is not met.






[JAVASERVERFACES_SPEC_PUBLIC-1249] add "maxRepeats" attribute to ui:repeat. Created: 27/Dec/13  Updated: 27/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

It would be very handy if there were a "maxRepeats" attribute on ui:repeat such that the repetition would terminate when either of the following two conditions was true.

1. the collection is empty

2. the maxRepeats value has been reached in terms of number of iterations.






[JAVASERVERFACES_SPEC_PUBLIC-1248] Allow EL in ResourceBundles used by JSF. Created: 27/Dec/13  Updated: 27/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator)
Affects Version/s: None
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

It would be nice if we could allow the use of EL expressions in ResourceBundles used by JSF.






[JAVASERVERFACES_SPEC_PUBLIC-1247] Disable implicit navigation within flows on a per-flow basis. Created: 27/Dec/13  Updated: 27/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

The ease of use of implicit navigation can be a boon for quick development, but it can also make it difficult to reason about flows when they get more complex. Consider adding a configuration element that disables implicit navigation in a flow.






[JAVASERVERFACES_SPEC_PUBLIC-1246] Prevent jumping into a flow without going through the front door. Created: 27/Dec/13  Updated: 27/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

RS> One observation is with regards to access to flow scoped data. When
RS> using the provided buttons, everything works as it should, i.e. flow
RS> scoped data is created at the point of entering the flow and
RS> destroyed when the flow is exited. However, it is easy to bypass the
RS> entry and exit points. For example I can go directly to a page
RS> associated with a flow without entering the flow, and if the page
RS> tries to access flow data, the result would be
RS> ContextNotActiveException.

One could argue that such an exception is the right response. The
context is indeed not active. However, if you are not using any flow
scoped data, such an exception would not be thrown, and it would give
the impression that the navigation is supported.

I think we can add some language to the spec to detect these "jump in"
cases.



 Comments   
Comment by Ed Burns [ 27/Dec/13 05:59 PM ]

Rossen wrote:

When flows are defined under the web application's root, I can easily access
their source from a browser which is a security concern. I can see there is
an example that puts the flow definition under WEB-INF but the pages are
still under the web application root and hence the flow is in two different
places. It would be useful to be able to keep a flow with all its files in a
folder under WEB-INF.





[JAVASERVERFACES_SPEC_PUBLIC-1245] Section "Determining the active Locale" includes too narrow language Created: 26/Dec/13  Updated: 26/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: 2.3

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

There is text in section "Determining the active Locale" (section number 2.5.2.1 as of version 2.2 of the JSF spec) that speaks too narrowly of how the system must process the <supported-locale> entries in the <locale-config> of the faces-config.xml file. In particular, this text runs afoul of the changes for script tags specified in IETF BCP47.

This text must be generalized so that existing behavior continues to be spec compliant, while BCP47 style entries can also be supported.

The spec for the <f:view locale> attribute must also be inspected so that it is compatible with BCP47.






[JAVASERVERFACES_SPEC_PUBLIC-1244] Reword requirements for EL expressions inlined in Facelets pages, but outside of components. Created: 19/Dec/13  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: 2.3

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Tags:
Participants: Ed Burns

 Description   

Text copied from JAVASERVERFACES-3094

The JSF spec (2.1) requires in section 10.3.1 that "The runtime must ensure that EL expressions that appear in the page without being the right-hand-side of a tag attribute
are treated as if they appeared on the right-hand-side of the value attribute of an <h:outputText /> element in the http://java.sun.com/jsf/html namespace." This should also work in this case.

This text is problematic with respect to c:set and friends.

I suggest we soften the above language to make it clear that we don't need to have UIOutput instances in the tree. Rather, we just need it to render as if we did.






[JAVASERVERFACES_SPEC_PUBLIC-1243] Use bean-like name as converter-id when @FacesConverter "value" attribute is omitted Created: 19/Dec/13  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: kithouna Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: facesvalidator validator validator-id value annotation
Participants: kithouna

 Description   

The JavaDoc of @FacesValidator's "value" attribute states:

If no value is specified, or the value is null, the value is taken to be the return of calling getSimpleName on the class to which this annotation is attached and lowercasing the first character.

It would be nice to have this feature for @FacesConverter as well.

See also JAVASERVERFACES_SPEC_PUBLIC-703






[JAVASERVERFACES_SPEC_PUBLIC-1241] web-facesconfig_2_2.xsd is missing definition for client-window-factory element Created: 09/Dec/13  Updated: 09/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tremes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Manfred Riem and tremes

 Comments   
Comment by Manfred Riem [ 09/Dec/13 04:15 PM ]

As this requires a change to the released schema this would require a spec change. Moved to the spec issue tracker.





[JAVASERVERFACES_SPEC_PUBLIC-1240] Ajax behavior renderer automatically/incorrectly quotes client behavior context parameters when building script. Created: 10/Nov/13  Updated: 06/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: cduncan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: cduncan, Ed Burns and Manfred Riem

 Description   

In the AjaxBehaviorRenderer.buildAjaxCommand() method, all ClientBehaviorContext.Parameter parameters are automatically quoted using RenderKitUtils.appendProperty(). This makes dynamicly calculated JavaScript values useless. All other calls to RenderKitUtils.appendProperty specify whether to quote parameters or not. Please do the same for ClientBehaviorContext.Parameter parameters.

The following call in AjaxBehaviorRenderer.java around line 250 should pass false.

for (ClientBehaviorContext.Parameter param : params) { RenderKitUtils.appendProperty(ajaxCommand, param.getName(), param.getValue()); }

I cannot use this very nice way of generating scripts in my custom components until this is fixed. I am currently using jsf.ajax.request, which works fine, but, I would rather use the implementation apis since it is much cleaner.



 Comments   
Comment by cduncan [ 10/Nov/13 02:20 PM ]

The most versatile and unobtrusive solution would be to add a "quoted" member variable to the ClientBehaviorContext.Parameter class. The value could be defaulted to true and referenced in the for loop mentioned above. This would not break existing usage since the for loop defaults to quoted currently. This would allow the developer to choose whether they wanted the quotes or not.

Comment by Manfred Riem [ 11/Nov/13 04:41 PM ]

Can you please tell us which version is affected, what application server you are running? And can you send a reproducing example to issues@javaserverfaces.java.net? That will help us tremendously! Thanks!

Comment by cduncan [ 12/Nov/13 02:33 PM ]

Manfred, I am using the Glassfish 4.0 zip version, which looks to be 2.2.0 according to manifest.mf. My proposed solution in the above comment was looking at the 2.2.4 source.

Thanks!
Chris

Comment by Ed Burns [ 13/Nov/13 08:57 PM ]

Thanks for your response about your version stack. It would help a lot if you could send a reproducer to the list, as suggested by Manfred. Whenever an issue comes in that requests a change in behavior, it is very important that we have the ability to verify that this change does not introduce problems.

Comment by Manfred Riem [ 19/Nov/13 02:16 PM ]

As the code currently in place is working correctly and you are asking for an improvement (by passing it the additional boolean) I am going to re-qualify this as an improvement.

Comment by cduncan [ 24/Nov/13 02:26 AM ]

Manfred, this issue is a show stopper bug for me and not an improvement. I cannot use the client behavior mechanism since it quotes the JavaScript parameters. I will attache the modified files, ClientBehaviorContext.java and AjaxBehaviorRenderer.java. Thanks, Chris.

Comment by cduncan [ 24/Nov/13 02:26 AM ]

/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
  • and Distribution License("CDDL") (collectively, the "License"). You
  • may not use this file except in compliance with the License. You can
  • obtain a copy of the License at
  • https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
  • or packager/legal/LICENSE.txt. See the License for the specific
  • language governing permissions and limitations under the License.
    *
  • When distributing the software, include this License Header Notice in each
  • file and include the License file at packager/legal/LICENSE.txt.
    *
  • GPL Classpath Exception:
  • Oracle designates this particular file as subject to the "Classpath"
  • exception as provided by Oracle in the GPL Version 2 section of the License
  • file that accompanied this code.
    *
  • Modifications:
  • If applicable, add the following below the License Header, with the fields
  • enclosed by brackets [] replaced by your own identifying information:
  • "Portions Copyright [year] [name of copyright owner]"
    *
  • Contributor(s):
  • If you wish your version of this file to be governed by only the CDDL or
  • only the GPL Version 2, indicate your decision by adding "[Contributor]
  • elects to include this software in this distribution under the [CDDL or GPL
  • Version 2] license." If you don't indicate a single choice of license, a
  • recipient has the option to distribute your version of this file under
  • either the CDDL, the GPL Version 2 or to extend the choice of license to
  • its licensees as provided above. However, if you add GPL Version 2 code
  • and therefore, elected the GPL Version 2 license, then the option applies
  • only if the new code is made subject to such option by the copyright
  • holder.
    */

package javax.faces.component.behavior;

import java.util.Collection;
import java.util.Collections;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;

/**

  • <p class="changed_added_2_0"><strong>ClientBehaviorContext</strong>
  • provides context information that may be useful to
  • {@link javax.faces.component.behavior.ClientBehavior#getScript}
  • implementations.
  • </p>
    *
  • @since 2.0
    */
    public abstract class ClientBehaviorContext {

/**

  • <p class="changed_added_2_0">Creates a ClientBehaviorContext instance.</p>
    *
  • @param context the <code>FacesContext</code> for the current request.
  • @param component the component instance to which the
  • <code>ClientBehavior</code> is attached.
  • @param eventName the name of the behavior event to which the
  • <code>ClientBehavior</code> is attached.
  • @param sourceId the id to use as the ClientBehavior's "source".
  • @param parameters the collection of parameters for submitting
  • ClientBehaviors to include in the request.
  • @return a <code>ClientBehaviorContext</code> instance configured with the
  • provided values.
  • @throws NullPointerException if <code>context</code>,
  • <code>component</code> or <code>eventName</code>
  • is <code>null</code>
    *
  • @since 2.0
    */
    public static ClientBehaviorContext createClientBehaviorContext(FacesContext context,
    UIComponent component,
    String eventName,
    String sourceId,
    Collection<ClientBehaviorContext.Parameter> parameters) { return new ClientBehaviorContextImpl(context, component, eventName, sourceId, parameters); }

/**

  • <p class="changed_added_2_0">Returns the {@link FacesContext} for
  • the current request.</p>
    *
  • @since 2.0
    */
    abstract public FacesContext getFacesContext();

/**

  • <p class="changed_added_2_0">Returns the {@link UIComponent} that is
  • requesting the {@link ClientBehavior} script.</p>
    *
    * @since 2.0
    */
    abstract public UIComponent getComponent();

    /**
    * <p class="changed_added_2_0">Returns the name of the behavior event
    * for which the ClientBehavior script is being requested. </p>
    *
    * @since 2.0
    */
    abstract public String getEventName();

    /**
    * <p class="changed_added_2_0">Returns an id for use as the
    * {@link ClientBehavior} source. ClientBehavior implementations that submit back
  • to the Faces lifecycle are required to identify which component
  • triggered the ClientBehavior-initiated request via the
  • <code>javax.faces.source</code> request parameter. In
  • most cases, th source id can be trivially derived from the element
  • to which the behavior's client-side script is attached - ie. the
  • source id is typically the id of this element. However, in components
  • which produce more complex content, the behavior script may not be able to
  • determine the correct id to use for the javax.faces.source
  • value. The {@link ClientBehaviorContext#getSourceId} method allows the component
  • to pass this information into the {@link ClientBehavior#getScript}
  • implementation.</p>
    *
  • @return the id for the behavior's script to use as the "source", or
  • null if the Behavior's script can identify the source from the DOM.
    *
  • @since 2.0
    */
    abstract public String getSourceId();

/**

  • <p class="changed_added_2_0">Returns parameters that "submitting"
  • {@link ClientBehavior} implementations should include when posting back data
  • into the Faces lifecycle. If no parameters are specified, this method
  • returns an empty (non-null) collection.</p>
    *
  • @since 2.0
    */
    abstract public Collection<ClientBehaviorContext.Parameter> getParameters();

// Little static member class that provides a default implementation
private static final class ClientBehaviorContextImpl extends ClientBehaviorContext {
private FacesContext context;
private UIComponent component;
private String eventName;
private String sourceId;
private Collection<ClientBehaviorContext.Parameter> parameters;

private ClientBehaviorContextImpl(FacesContext context,
UIComponent component,
String eventName,
String sourceId,
Collection<ClientBehaviorContext.Parameter> parameters) {

if (null == context) { throw new NullPointerException(); }

if (null == component) { throw new NullPointerException(); } }

if (null == eventName) { throw new NullPointerException(); }

this.context = context;
this.component = component;
this.eventName = eventName;
this.sourceId = sourceId;

this.parameters = (parameters == null) ?
Collections.<ClientBehaviorContext.Parameter>emptyList() :
parameters;
}

@Override
public FacesContext getFacesContext() { return context; }

@Override
public UIComponent getComponent() { return component; }

@Override
public String getEventName() { return eventName; }

@Override
public String getSourceId() { return sourceId; }

@Override
public Collection<ClientBehaviorContext.Parameter> getParameters() { return parameters; }
}

/**
* <p class="changed_added_2_0"><strong>Parameter</strong> instances
* represent name/value pairs that "submitting" ClientBehavior implementations
* should include when posting back into the Faces lifecycle. ClientBehavior
* implementations can determine which Parameters to include by calling
* ClientBehaviorContext.getParameters().
* </p>
*
* @since 2.0
*/
public static class Parameter {

private String name;
private Object value;
private boolean quoteValue;

/**
* <p class="changed_added_2_0">Creates a Parameter instance.</p>
* @param name the name of the parameter
* @param value the value of the parameter
* @throws NullPointerException if <code>name</code>
* is null.
*
* @since 2.0
*/
public Parameter(String name, Object value) { this(name, value, true); }

/**
* <p class="changed_added_2_0">Creates a Parameter instance.</p>
* @param name the name of the parameter
* @param value the value of the parameter
* @param quoteValue indicator for value quotes.
* @throws NullPointerException if <code>name</code>
* is null.
*
* @since 2.2.6
*/
public Parameter(String name, Object value, boolean quoteValue) {

if (null == name) { throw new NullPointerException(); } }

this.name = name;
this.value = value;
this.quoteValue = quoteValue;
}

/**

  • <p class="changed_added_2_0">Returns the Parameter's name.</p>
    *
  • @since 2.0
    */
    public String getName() { return name; }

/**

  • <p class="changed_added_2_0">Returns the Parameter's value.</p>
    *
  • @since 2.0
    */
    public Object getValue() { return value; }

/**

  • <p class="changed_added_2_2_6">Returns the Parameter's quote value indicator.</p>
    *
  • @since 2.2.6
    */
    public boolean getQuoteValue() { return quoteValue; }
    }
    }
Comment by cduncan [ 24/Nov/13 02:27 AM ]

/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
  • and Distribution License("CDDL") (collectively, the "License"). You
  • may not use this file except in compliance with the License. You can
  • obtain a copy of the License at
  • https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
  • or packager/legal/LICENSE.txt. See the License for the specific
  • language governing permissions and limitations under the License.
    *
  • When distributing the software, include this License Header Notice in each
  • file and include the License file at packager/legal/LICENSE.txt.
    *
  • GPL Classpath Exception:
  • Oracle designates this particular file as subject to the "Classpath"
  • exception as provided by Oracle in the GPL Version 2 section of the License
  • file that accompanied this code.
    *
  • Modifications:
  • If applicable, add the following below the License Header, with the fields
  • enclosed by brackets [] replaced by your own identifying information:
  • "Portions Copyright [year] [name of copyright owner]"
    *
  • Contributor(s):
  • If you wish your version of this file to be governed by only the CDDL or
  • only the GPL Version 2, indicate your decision by adding "[Contributor]
  • elects to include this software in this distribution under the [CDDL or GPL
  • Version 2] license." If you don't indicate a single choice of license, a
  • recipient has the option to distribute your version of this file under
  • either the CDDL, the GPL Version 2 or to extend the choice of license to
  • its licensees as provided above. However, if you add GPL Version 2 code
  • and therefore, elected the GPL Version 2 license, then the option applies
  • only if the new code is made subject to such option by the copyright
  • holder.
    */

package com.sun.faces.renderkit.html_basic;

import com.sun.faces.util.FacesLogger;

import java.util.Collection;
import java.util.LinkedList;
import java.util.logging.Level;
import java.util.logging.Logger;

import javax.faces.FacesException;
import javax.faces.component.ActionSource;
import javax.faces.component.EditableValueHolder;
import javax.faces.component.UIComponent;
import javax.faces.component.behavior.AjaxBehavior;
import javax.faces.component.behavior.ClientBehavior;
import javax.faces.component.behavior.ClientBehaviorContext;
import javax.faces.context.FacesContext;
import javax.faces.event.AjaxBehaviorEvent;
import javax.faces.event.PhaseId;
import javax.faces.render.ClientBehaviorRenderer;

import com.sun.faces.renderkit.RenderKitUtils;

/*
*<b>AjaxBehaviorRenderer</b> renders Ajax behavior for a component.

  • It also
    */

public class AjaxBehaviorRenderer extends ClientBehaviorRenderer {

// Log instance for this class
protected static final Logger logger = FacesLogger.RENDERKIT.getLogger();

// ------------------------------------------------------ Rendering Methods

@Override
public String getScript(ClientBehaviorContext behaviorContext,
ClientBehavior behavior) {
if (!(behavior instanceof AjaxBehavior)) { // TODO: use MessageUtils for this error message? throw new IllegalArgumentException( "Instance of javax.faces.component.behavior.AjaxBehavior required: " + behavior); }

if (((AjaxBehavior)behavior).isDisabled()) { return null; }
return buildAjaxCommand(behaviorContext, (AjaxBehavior)behavior);
}


@Override
public void decode(FacesContext context,
UIComponent component,
ClientBehavior behavior) {
if (null == context || null == component || null == behavior) { throw new NullPointerException(); }

if (!(behavior instanceof AjaxBehavior)) { // TODO: use MessageUtils for this error message? throw new IllegalArgumentException( "Instance of javax.faces.component.behavior.AjaxBehavior required: " + behavior); }

AjaxBehavior ajaxBehavior = (AjaxBehavior)behavior;

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled()) { return; }

component.queueEvent(createEvent(component, ajaxBehavior));

if (logger.isLoggable(Level.FINE)) {
logger.fine("This command resulted in form submission " +
" AjaxBehaviorEvent queued.");
logger.log(Level.FINE,
"End decoding component {0}", component.getId());
}


}

// Creates an AjaxBehaviorEvent for the specified component/behavior
private static AjaxBehaviorEvent createEvent(UIComponent component,
AjaxBehavior ajaxBehavior) { AjaxBehaviorEvent event = new AjaxBehaviorEvent(component, ajaxBehavior); PhaseId phaseId = isImmediate(component, ajaxBehavior) ? PhaseId.APPLY_REQUEST_VALUES : PhaseId.INVOKE_APPLICATION; event.setPhaseId(phaseId); return event; }


// Tests whether we should perform immediate processing. Note
// that we "inherit" immediate from the parent if not specified
// on the behavior.
private static boolean isImmediate(UIComponent component,
AjaxBehavior ajaxBehavior) {

boolean immediate = false;

if (ajaxBehavior.isImmediateSet()) { immediate = ajaxBehavior.isImmediate(); } else if (component instanceof EditableValueHolder) { immediate = ((EditableValueHolder)component).isImmediate(); } else if (component instanceof ActionSource) { immediate = ((ActionSource)component).isImmediate(); }

return immediate;
}

private static String buildAjaxCommand(ClientBehaviorContext behaviorContext,
AjaxBehavior ajaxBehavior) {

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled()) { return null; } }

UIComponent component = behaviorContext.getComponent();
String eventName = behaviorContext.getEventName();

StringBuilder ajaxCommand = new StringBuilder(256);
Collection<String> execute = ajaxBehavior.getExecute();
Collection<String> render = ajaxBehavior.getRender();
String onevent = ajaxBehavior.getOnevent();
String onerror = ajaxBehavior.getOnerror();
String sourceId = behaviorContext.getSourceId();
String delay = ajaxBehavior.getDelay();
Boolean resetValues = null;
if (ajaxBehavior.isResetValuesSet()) { resetValues = ajaxBehavior.isResetValues(); }
Collection<ClientBehaviorContext.Parameter> params = behaviorContext.getParameters();

// Needed workaround for SelectManyCheckbox - if execute doesn't have sourceId,
// we need to add it - otherwise, we use the default, which is sourceId:child, which
// won't work.
ClientBehaviorContext.Parameter foundparam = null;
for (ClientBehaviorContext.Parameter param : params) {
if (param.getName().equals("incExec") && (Boolean)param.getValue()) { foundparam = param; }
}
if (foundparam != null && !execute.contains(sourceId)) { execute = new LinkedList<String>(execute); execute.add(component.getClientId()); }
if (foundparam != null) {
try { // And since this is a hack, we now try to remove the param params.remove(foundparam); } catch (UnsupportedOperationException uoe) {
if (logger.isLoggable(Level.FINEST)) { logger.log(Level.FINEST, "Unsupported operation", uoe); }
}
}

ajaxCommand.append("mojarra.ab(");

if (sourceId == null) { ajaxCommand.append("this"); } else { ajaxCommand.append("'"); ajaxCommand.append(sourceId); ajaxCommand.append("'"); }

ajaxCommand.append(",event,'");
ajaxCommand.append(eventName);
ajaxCommand.append("',");

appendIds(component, ajaxCommand, execute);
ajaxCommand.append(",");
appendIds(component, ajaxCommand, render);

if ((onevent != null) || (onerror != null) || (delay != null) ||
(resetValues != null) || !params.isEmpty()) {

ajaxCommand.append(",{");

if (onevent != null) { RenderKitUtils.appendProperty(ajaxCommand, "onevent", onevent, false); }

if (onerror != null) { RenderKitUtils.appendProperty(ajaxCommand, "onerror", onerror, false); }

if (delay != null) { RenderKitUtils.appendProperty(ajaxCommand, "delay", delay, true); }

if (resetValues != null) { RenderKitUtils.appendProperty(ajaxCommand, "resetValues", resetValues, false); }

if (!params.isEmpty()) {
for (ClientBehaviorContext.Parameter param : params) { RenderKitUtils.appendProperty(ajaxCommand, param.getName(), param.getValue(), param.getQuoteValue()); }
}

ajaxCommand.append("}");
}

ajaxCommand.append(")");

return ajaxCommand.toString();
}

// Appends an ids argument to the ajax command
private static void appendIds(UIComponent component,
StringBuilder builder,
Collection<String> ids) {

if ((null == ids) || ids.isEmpty()) { builder.append('0'); return; }

builder.append("'");

boolean first = true;

for (String id : ids) {
if (id.trim().length() == 0) { continue; }
if (!first) { builder.append(' '); } else { first = false; }

if (id.equals("@all") || id.equals("@none") ||
id.equals("@form") || id.equals("@this")) { builder.append(id); } else { builder.append(getResolvedId(component, id)); }
}

builder.append("'");
}

// Returns the resolved (client id) for a particular id.
private static String getResolvedId(UIComponent component, String id) {

UIComponent resolvedComponent = component.findComponent(id);
if (resolvedComponent == null) { // RELEASE_PENDING i18n throw new FacesException( "<f:ajax> contains an unknown id '" + id + "' - cannot locate it in the context of the component "+component.getId()); }

return resolvedComponent.getClientId();
}
}

Comment by Manfred Riem [ 25/Nov/13 03:02 PM ]

Hi Chris,

I understand your predicament, unfortunately because your change is in javax.faces.component.behavior which is an API package it would violate the TCK (note adding any method to an API package violates the TCK and thus the JSF specification). If you can do it without changing anything in a javax.faces.* package then I certainly would like to get this in, provided it passes all of our tests.

Comment by cduncan [ 25/Nov/13 06:13 PM ]

Manfred:

Thank you for your timely response to this issue and for clarifying changes to the javax.faces.* packages. I was wondering about that before posting the previous solution. I believe there is a simple solution keeping the improvement within the com.sun.faces.renderkit.RenderKitUtils.AjaxBehaviorRenderer class. I will code it up tonight and post a solution that will not interfere with the current usage and allows overrides by component developers.

Thank you,
Chris

Comment by cduncan [ 26/Nov/13 03:30 AM ]

Manfred:

This version of the method com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.buildAjaxCommand() explicitly sets the quoted value in the RenderKitUtils.appendProperty() call to false. Currently, it is not explicitly set and thus invokes the overloaded version of RenderKitUtils.appendProperty() which sets the value to true. All of the calls to RenderKitUtils.appendProperty() explicitly set the quoted value except this one. I am not sure if this was an oversight. This version needs to be thoroughly tested to make sure it does not cause any unwanted side effects.

There is another solution if this one does not pass all tests. We can overload the com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.getScript() method passing in a boolean indicating whether to quote the value. This boolean will be passed to com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.buildAjaxCommand() for the last RenderKitUtils.appendProperty() call.

Thank you,
Chris

private static String buildAjaxCommand(ClientBehaviorContext behaviorContext,
AjaxBehavior ajaxBehavior) {

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled()) { return null; }

UIComponent component = behaviorContext.getComponent();
String eventName = behaviorContext.getEventName();

StringBuilder ajaxCommand = new StringBuilder(256);
Collection<String> execute = ajaxBehavior.getExecute();
Collection<String> render = ajaxBehavior.getRender();
String onevent = ajaxBehavior.getOnevent();
String onerror = ajaxBehavior.getOnerror();
String sourceId = behaviorContext.getSourceId();
String delay = ajaxBehavior.getDelay();
Boolean resetValues = null;
if (ajaxBehavior.isResetValuesSet()) { resetValues = ajaxBehavior.isResetValues(); }
Collection<ClientBehaviorContext.Parameter> params = behaviorContext.getParameters();

// Needed workaround for SelectManyCheckbox - if execute doesn't have sourceId,
// we need to add it - otherwise, we use the default, which is sourceId:child, which
// won't work.
ClientBehaviorContext.Parameter foundparam = null;
for (ClientBehaviorContext.Parameter param : params) {
if (param.getName().equals("incExec") && (Boolean)param.getValue()) { foundparam = param; }
}
if (foundparam != null && !execute.contains(sourceId)) { execute = new LinkedList<String>(execute); execute.add(component.getClientId()); }
if (foundparam != null) {
try { // And since this is a hack, we now try to remove the param params.remove(foundparam); } catch (UnsupportedOperationException uoe) {
if (logger.isLoggable(Level.FINEST)) { logger.log(Level.FINEST, "Unsupported operation", uoe); }
}
}

ajaxCommand.append("mojarra.ab(");

if (sourceId == null) { ajaxCommand.append("this"); } else { ajaxCommand.append("'"); ajaxCommand.append(sourceId); ajaxCommand.append("'"); }

ajaxCommand.append(",event,'");
ajaxCommand.append(eventName);
ajaxCommand.append("',");

appendIds(component, ajaxCommand, execute);
ajaxCommand.append(",");
appendIds(component, ajaxCommand, render);

if ((onevent != null) || (onerror != null) || (delay != null) ||
(resetValues != null) || !params.isEmpty()) {

ajaxCommand.append(",{");

if (onevent != null) { RenderKitUtils.appendProperty(ajaxCommand, "onevent", onevent, false); }

if (onerror != null) { RenderKitUtils.appendProperty(ajaxCommand, "onerror", onerror, false); }

if (delay != null) { RenderKitUtils.appendProperty(ajaxCommand, "delay", delay, true); }

if (resetValues != null) { RenderKitUtils.appendProperty(ajaxCommand, "resetValues", resetValues, false); }

if (!params.isEmpty()) {
for (ClientBehaviorContext.Parameter param : params) { RenderKitUtils.appendProperty(ajaxCommand, param.getName(), param.getValue(), false); }
}

ajaxCommand.append("}");
}

ajaxCommand.append(")");

return ajaxCommand.toString();
}

Comment by cduncan [ 04/Dec/13 03:56 AM ]

It appears the MyFaces 2.2.0 implementation also automatically quotes the JavaScript parameter values when posting back. The following method is from the HtmlAjaxBehaviorRenderer.java class in the myfaces-impl-2.2.0-beta-sources.jar.

private void append(StringBuilder paramBuffer, List<String> parameterList, ClientBehaviorContext.Parameter param)

{ //TODO we may need a proper type handling in this part //lets leave it for now as it is //quotes etc.. should be transferred directly //and the rest is up to the toString properly implemented //ANS: Both name and value should be quoted paramBuffer.setLength(0); paramBuffer.append(QUOTE); paramBuffer.append(param.getName()); paramBuffer.append(QUOTE); paramBuffer.append(COLON); paramBuffer.append(QUOTE); paramBuffer.append(param.getValue().toString()); paramBuffer.append(QUOTE); parameterList.add(paramBuffer.toString()); }

What I take from this is that the JSF specification for the ClientBehaviorContext.Parameter class is not clear in regards to quoting, and as such, the JSF implementations default to automatic quoting.

In my first solution, I added a 'private boolean quoteValue' member variable to the ClientBehaviorContext.Parameter class and defaulted the value to true. This would not cause any side effects since implementations default to true anyway and would give custom component developers the power to decide if they want their JavaScript value params quoted or not.

As Manfred stated, this would require a change to the JSF spec, but from what I have seen, I believe it is the best route. I do realize that this would take some time, so I am writing my own handling of the client behaviors in my custom components. I cannot tightly couple my custom components to a particular implementation.

Please let me know how I can help further.

Thanks,
Chris

Comment by Manfred Riem [ 04/Dec/13 10:42 PM ]

Chris, thank you for doing the extra work you did. As you stated that MyFaces is also doing automatic quoting I think it might be time to move this issue to the spec issue tracker and put it on the radar for the next version of the JSF specification. What do you think?

Comment by cduncan [ 05/Dec/13 01:03 AM ]

Manfred:

I believe this needs a clarification in the JSF specification. A member variable in the ClientBehaviorContext.Parameter would remove all doubt for the JSF implementors on how to handle the value, and possible name parameter. It could be done in a way that would not affect all current implementations, since they default to quoted currently. Please see my original code solution for suggestions for the JSF specification.

Please let me know if I can help further.

Thanks,
Chris

Comment by Manfred Riem [ 05/Dec/13 07:23 PM ]

Chris, I will go ahead and move this issue to the SPEC issue tracker as it is a SPEC issue. Unfortunately that means resolution will have to wait till the next JSF specification. Thank!





[JAVASERVERFACES_SPEC_PUBLIC-1235] better integration of bv-groups Created: 31/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: gerhard_petracek Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gerhard_petracek

 Description   

in several cases different bv-groups should get used (in the validation-phase) depending on the triggered action.
(if there are e.g. multiple buttons in the same form which should lead to different bv-constraints.)

also see: https://issues.apache.org/jira/browse/EXTVAL-141






[JAVASERVERFACES_SPEC_PUBLIC-1234] HTML input elements without type attribute should be recognized as text inputs Created: 31/Oct/13  Updated: 13/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: kithouna Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kithouna

 Description   

As the type attribute for input elements is optional in HTML and the default value is "text" (as per HTML 4.01), input elements without type attribute should be handled like the type attribute was set to "text".

See also https://java.net/jira/browse/JAVASERVERFACES-3075



 Comments   
Comment by kithouna [ 12/Feb/14 03:52 PM ]

The reference implementation (Mojarra 2.2.5) has the strange behaviour that given

<input jsf:value="#{loginBean.loginName}" jsf:id="loginName"/>

the output becomes (assuming loginBean.loginName is not yet set, i. e. it’s null)

<input jsf:id="loginName"/>

so it seems as if the element is recognized as a JSF element (because the jsf:value seems to be interpreted in some way and therefore removed) but for some reason only the jsf:id attribute is not treated correctly.

Working on a new project, I spent way too much time (again) figuring out why the element was not working correctly. Having omitted the type attribute for several years on non-JSF projects, it’s a real unintuitive requirement to include it so maybe you could make sure to lift it for the next JSF version. Please? Maybe increase the priority? Reasoning: It is a major loss of function and the workaround (setting the attribute) is not exactly easy to find when you’re accustomed to rely on the default.





[JAVASERVERFACES_SPEC_PUBLIC-1233] Since 'var' is set by name on the request it is very easy to break. Created: 29/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jid1 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jid1

 Description   

IMO, composite components that contain tables or repeats that store variable on the request should be scoped as it very easy to get weird behaviour.
In the context of normal xhtml and includes, it could throw an error saying that the variable has already been defined, if user tries to define it again.

The reason behind the distinction is that you might end up with incompatible 3rd party components when you nest them. In addition, devs should pass the value as an attribute to the composite/custom component.






[JAVASERVERFACES_SPEC_PUBLIC-1232] Support for a Flow to start from direct URL path access Created: 28/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bruno Borges

 Description   

Support for a flow to start when user directly access the flow path from an URL.

If a user points to http://server/app/flow-folder/ the implementation throws an exception saying it couldn't find an index.xhtml page.

Right now, the only way to start a flow is by having the user accessing another page before, outside of the flow, and then an action to the flow (either by link, button, or some javascript to automatically click on something).






[JAVASERVERFACES_SPEC_PUBLIC-1231] Wrong name in spec for javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR Created: 16/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: 2.3

Type: Bug Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: lu4242

 Description   

Reported by Martin Koci in:

https://issues.apache.org/jira/browse/MYFACES-3790

In summary JSF 2.2 PDF section 3.5.3 Validation Registration has a reference to a config param javax.faces.validator.DISABLE_BEAN_VALIDATOR but the one used in both Mojarra and MyFaces is javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR.

Probably it was a change done with the objective of improve the meaning of the param. The param that should be used is javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR






[JAVASERVERFACES_SPEC_PUBLIC-1263] Add rowStatePreserved property to com.sun.faces.facelets.component.UIRepeat, exactly the same as javax.faces.component.UIData Created: 14/Oct/13  Updated: 06/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Dependency
blocks JAVASERVERFACES-2633 UIInput component state incorrect whe... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1230 VDLDoc for <ui:repeat> does not have ... Open
Tags:
Participants: Ed Burns

 Description   

This is the implementation work for JAVASERVERFACES_SPEC_PUBLIC-1230, but it can be done outside of the spec because properties can be added to Facelet backed components without having to change the TLD.






[JAVASERVERFACES_SPEC_PUBLIC-1230] VDLDoc for <ui:repeat> does not have concept of rowStatePreserved which <h:dataTable> does have. Created: 14/Oct/13  Updated: 06/Mar/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1263 Add rowStatePreserved property to com... Open
is related to JAVASERVERFACES-2243 h:form inside nested ui:repeat fails ... Closed
Tags:
Participants: Ed Burns

 Description   

JSF 2.1 added to UIData the ability to declare that row state should be preserved on iterations. This capability should also be added to <ui:repeat>



 Comments   
Comment by Ed Burns [ 06/Mar/14 07:06 PM ]

>>>>> On Fri, 14 Feb 2014 16:17:46 -0500, Leonardo Uribe said:

LU> There is still a problem related to the component row state and its
LU> relation with the model. In few words, if you remove a row, since the
LU> state is associated to the rowIndex, the state of the removed row is
LU> passed to the next row and so on, breaking the state. Long time
LU> ago, I did a solution to the problem in tomahawk adding some
LU> attributes (rowKey and derivedRowKeyPrefix).





[JAVASERVERFACES_SPEC_PUBLIC-1229] VDLDoc for <h:dataTable> does not document rowStatePreserved property. See UIData.setRowStatePreserved() Created: 14/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Issue Links:
Related
is related to JAVASERVERFACES-2633 UIInput component state incorrect whe... Closed
Tags:
Participants: Ed Burns

 Description   

The JavaDocs for UIData have the rowStatePreserved property.

This needs to be exposed on the vdldoc for <h:dataTable>.






[JAVASERVERFACES_SPEC_PUBLIC-1228] Consider UIInputFile as a means to deal with the problem of the "value" attribute with respect to state saving. Created: 08/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days

Issue Links:
Related
is related to JAVASERVERFACES-3037 h:inputFile Ajax File Upload: Works e... Closed
Tags:
Participants: Ed Burns

 Description   

JSF 2.2 added file upload but did so by leveraging the javax.faces.Input component-family with the newly-defined javax.faces.File renderer-type. There is one aspect in which this may be problematic: the storing of the "value" property in component state. Please see JAVASERVERFACES-3037.






[JAVASERVERFACES_SPEC_PUBLIC-1227] Add <f:protectClientWindowOpenInNewTab> JavaScript behavior tag Created: 07/Oct/13  Updated: 20/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days

Tags:
Participants: Ed Burns, tandraschko and Thomas Asel

 Description   

With the introduction of ClientWindow in JSF 2.2, it's possible to protect against multiple tabs being open on the same view. However, components that render links allow the user to do "open in new tab" or "open in new window". This can cause a situation where there are multiple tabs that still have the same ClientWindow, which is incorrect.

This feature proposal asks for the creation of a ClientBehavior tag that, when nested inside of a component that renders as a link, will make it so a new client window is created when the link is clicked.



 Comments   
Comment by Ed Burns [ 07/Oct/13 11:49 PM ]

Here's a sketch for how this could work.

Here's how you'd use it.

<h:link outcome="callB" value="Call B via GET">
<f:protectClientWindowOpenInNewTab />
</h:link>

This would cause the link to be rendered with some javascript that listens for an onclick on the link. In the handler, check if the right mouse button was pressed and take appropriate action.

Comment by Thomas Asel [ 08/Oct/13 06:28 AM ]

I am afraid that this feature would force unintuitive behavior and also advocates a rather patronizing development style.

How about creating a client behavior that creates a window id on demand?
So instead of blocking the contextmenu we could use the oncontextmenu handler to create a new id and append it as a parameter to the link.

Comment by Ed Burns [ 08/Oct/13 12:40 PM ]

Thanks for the feedback, Thomas. We can certainly change the name to be less patronizing.

Please note that the ClientWindow will be created on demand when the request comes in without having one already. This is why it is sufficient for the context menu handler to simply strip it off.

The client behavior for this tag does two things.

1. If the link is clicked without the context menu, no action is taken. The already-existing ClientWindow is allowed to remain on the link, causing the correct ClientWindow to be carried forward.

2. If the link is clicked with the context menu (new tab or new window), the ClientWindow is removed before the browser issues the GET. This will cause a new ClientWindow to be created for the new tab (or window), this is the correct action in this case.

Comment by tandraschko [ 20/Dec/13 02:13 PM ]

@Ed
is it really possible to listen on "onclick" when the link will be openend in new tab via context menu?
I'm sure onclick won't be called.

Maybe we should never render the windowId to a link und just add via onclick.
We could store the windowId globally in a JS varable in in the listener, we could add it to the href.





[JAVASERVERFACES_SPEC_PUBLIC-1226] Inconsistent handling of null/undeclared attributes, especially with nested components Created: 07/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Facelets/VDL
Affects Version/s: 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: fabmars Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF3 + JSF 2.1.26 or GF4 with JSF 2.2.3 with JDK7.0_45


Tags: composite composite-component null
Participants: fabmars

 Description   

The origin is here: https://java.net/jira/browse/JAVASERVERFACES-2614, but it's mainly worth reading the summary further down here.

The reproducer is on git@github.com:fabmars/JSF2614.git .
We have an outer component:

test1.xhtml
<composite:interface>
<composite:attribute name="val1" type="java.lang.String"/>
<composite:attribute name="val2" type="java.lang.String"/>
<composite:attribute name="val3" type="java.lang.String" default="#{null}"/>
<composite:attribute name="val4" type="java.lang.String" default="#{null}"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<h:outputText value="Outer1: #{cc.attrs.val1 == null ? 'null' : (empty cc.attrs.val1 ? 'empty' : cc.attrs.val1)}" />
<h:outputText value="Outer2: #{cc.attrs.val2 == null ? 'null' : (empty cc.attrs.val2 ? 'empty' : cc.attrs.val2)}" />
<h:outputText value="Outer3: #{cc.attrs.val3 == null ? 'null' : (empty cc.attrs.val3 ? 'empty' : cc.attrs.val3)}" />
<h:outputText value="Outer4: #{cc.attrs.val4 == null ? 'null' : (empty cc.attrs.val4 ? 'empty' : cc.attrs.val4)}" />
</h:panelGrid>
<sr:test2 val1="#{cc.attrs.val1}" val2="#{cc.attrs.val2}" val3="#{cc.attrs.val3}" val4="#{cc.attrs.val4}" /> 
</composite:implementation>

And an inner component:

test2.xhtml
<composite:interface>
	<composite:attribute name="val1" type="java.lang.String"/>
	<composite:attribute name="val2" type="java.lang.String" default="#{null}"/>
	<composite:attribute name="val3" type="java.lang.String"/>
	<composite:attribute name="val4" type="java.lang.String" default="#{null}"/>
</composite:interface>

<composite:implementation>
	<h:panelGrid>
		<h:outputText value="Inner1: #{cc.attrs.val1 == null ? 'null' : (empty cc.attrs.val1 ? 'empty' : cc.attrs.val1)}" />
		<h:outputText value="Inner2: #{cc.attrs.val2 == null ? 'null' : (empty cc.attrs.val2 ? 'empty' : cc.attrs.val2)}" />
		<h:outputText value="Inner3: #{cc.attrs.val3 == null ? 'null' : (empty cc.attrs.val3 ? 'empty' : cc.attrs.val3)}" />
		<h:outputText value="Inner4: #{cc.attrs.val4 == null ? 'null' : (empty cc.attrs.val4 ? 'empty' : cc.attrs.val4)}" />
	</h:panelGrid>
</composite:implementation>

And the actual page:

jsf2614.xhtml
<sr:test1 val1="AAA" val2="BBB" val3="CCC" val4="DDD"/>
<sr:test1/>
<sr:test1 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/>
<sr:test2  val1="DDD" val2="EEE" val3="FFF" val4="GGG"/>
<sr:test2/>
<sr:test2 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/>

When running one can notice a couple of odd things:

1st case:
On <sr:test1 .../>

  • feed <composite:attribute name="val1" type="java.lang.String"/> with null. Result: null
  • feed <composite:attribute name="val3" type="java.lang.String" default="#{null}"/> with null. Result: ""
    The developer, in the second line expects to get String var3 = null in the end. Instead he gets a real value.
    OK this is due to the mechanics of coertion but this is not consistent and imo should be fixed.


    2nd case:
    - Call the OUTER component dry <sr:test1/>. var1 isn't declared, so will be assumed null. In sr:test1 implementation is a call to <sr:test2 val1="#{cc.attrs.val1}"... The INNER(sr:test2) component is awaiting a String as val1 (<composite:attribute name="val1" type="java.lang.String"/>) and our non-declared attribute becomes "" (again) in the end! (see that lines 9 vs 13 of the output). In other words: feed a null to <composite:attribute name="val1" type="java.lang.String"/> directly, it stays null, feed it from a surrounding component, it becomes ""!


    3rd case:
    Calling directly the inner component <sr:test2/> and <sr:test2 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/> produce totally different results (see lines 29-32 vs 33-36 of the output). This is confusing for the developer and I'm not even sure this is a "feature".





[JAVASERVERFACES_SPEC_PUBLIC-1225] What to say about BCP47 Support? Created: 02/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Tags:
Participants: Ed Burns

 Description   

BCP47 defines new rules for the parsing of Locale objects. These rules are implemented in the java.util.Locale class in JDK7. There are several places in the JSF spec that place requirements on how a Locale is encoded as a String.

  • XSD for supported-locale
  • XSD for default-locale
  • Spec section "2.5.2.1 Determining the Active Locale" in the portion of that section that deals with the locale attribute on the <f:view> tag.

In all of these places statements are made regarding the use of "-" or "_" as a separator. This issue asks if we should go further and require the use of JDK7 Locale.forLanguageTag() to obtain the Locale instance before trying the existing methods of obtaining a Locale.






[JAVASERVERFACES_SPEC_PUBLIC-1224] HTML5 Form Validation Not Performed Before Ajax Submit Created: 30/Aug/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: rogerk

 Description   

Given an HTML5 form, with HTML% input types (such as email), form validation is not performed (for an invalid email entered) if the submit is over ajax.
This is because the current Ajax portion of the specification states specifically to collect form elements and pass on over ajax to server side.
We would need to specify (and implement) something to trigger form validation before even collecting elements for ajax submit.






[JAVASERVERFACES_SPEC_PUBLIC-1221] Please add support for populating data column headers from a list Created: 29/Aug/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: pratap_abhinav Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: pratap_abhinav

 Description   

Add support for populating data table headers from a managed bean list.

Eg.
Currently:

<h:datatable var="v" value=#{mybean.list}>
<h:column>
<f:facet name="header">
<h:outputText value="col1head"/>
</f:facet>
<h:outputText value=#{v.col1}/>
...
</h:column>
</h:datatable>

please add support for coding like this:
<h:datatable var="v" value=#{mybean}>
<h:columns>
<f:facet name="header">
<h:outputText value="#{v.col2headerList}"/>
</f:facet>
<h:outputText value=#{v.col1valuelist}/>

</h:columns>
...
</h:datatable>

or something like that as implemented in rich faces. It would be very useful for admin tool applications.






[JAVASERVERFACES_SPEC_PUBLIC-1220] Please add a attribute pagination="true", maxrows="" in h:datatable component of jsf. This will reduce a lot of coding and reduce dependency on another jsf implementations like primefaces. Created: 29/Aug/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: pratap_abhinav Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: pratap_abhinav

 Description   

Please add a attribute pagination="true", maxrows="" in h:datatable component of jsf. This will reduce a lot of coding and reduce dependency on another jsf implementations like primefaces






[JAVASERVERFACES_SPEC_PUBLIC-1219] Specify behavior in case of abandoned flow. Created: 26/Aug/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 6 hours
Time Spent: Not Specified
Original Estimate: 6 hours

Issue Links:
Dependency
depends on JAVASERVERFACES-2997 None flow command actions navigation ... Closed
Tags:
Participants: Ed Burns

 Description   

Currently trying to navigate away from a flow by any means other than a flow-return or flow-call node will cause the navigation to silently fail. This approach has the nice property in that it prevents abandoned flows. Unfortunately, as JAVASERVERFACES-2997 shows, this approach is overly restrictive.

This issue calls for the spec to say what should happen when the flow is abandoned.



 Comments   
Comment by Ed Burns [ 26/Aug/13 05:11 PM ]

The fix for JAVASERVERFACES-2997 did the following.

When looking for a navigation match in the midst of the flow, if no other way of finding a match is found, look for an implicit match outside of the flow. If that's not found, look in the root navigation map using the same three step process in normal JSF navigation.





[JAVASERVERFACES_SPEC_PUBLIC-1217] EnumConverter.getAsString() javadoc contains incorrect text, conflicts with its own @returns clause Created: 15/Aug/13  Updated: 14/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes

Issue Links:
Related
is related to JAVASERVERFACES-2919 selectOneMenu + EnumConverter and nul... Closed
Tags:
Participants: Ed Burns

 Description   

The Javadoc for EnumConverter.getAsString() contains the text,

If the value argument is null, return null.

This is conflict with the @returns clause, and also with the super-interface declaration of the method.






[JAVASERVERFACES_SPEC_PUBLIC-1216] Inconsistent exception handling for phaselisteners Created: 14/Aug/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: frederickkaempfer

 Description   

Exception handling for phase listeners behaves differently depending on if they are registered globally in faces-config.xml or with f:phaseListener for a particular view root.

In the first (global) case any exception thrown by them gets forwarded to an exception handler as described in the spec.

In the second (per view root) case all exceptions get logged and swallowed as described in the UIViewRoot documentation.

This inconsistent behavior adds increased complexity when implementing PhaseListeners. Ideally both cases should forward any exception to the exception handler so they can be handled there.

See also the discussion of the problem in: https://java.net/jira/browse/JAVASERVERFACES-2985






[JAVASERVERFACES_SPEC_PUBLIC-1215] Add warning to javadoc of DelegatingMetaTagHandler.getTagHandlerDelegate Created: 12/Aug/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes

Tags:
Participants: Ed Burns

 Description   

The current spec has no javadoc for DelegatingMetaTagHandler.getTagHandlerDelegate(). [1] This issue proposes adding the following warning to the javadoc for this method.

Code that extends from DelagatingMetaTagHandler (directly or indirectly, as through extending ComponentHandler) must take care to decorate, not replace, the TagHandlerDelegate instance returned by this method. Failure to do so may produce unexpected results.

[1] http://docs.oracle.com/javaee/6/api/javax/faces/view/facelets/DelegatingMetaTagHandler.html#getTagHandlerDelegate%28%29






[JAVASERVERFACES_SPEC_PUBLIC-1213] f:viewParam doesn't work when using xmlns:f="http://xmlns.jcp.org/jsf/core" Created: 06/Aug/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: irinipaci Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JavaEE 7 maven web application with JSF 2.2
GlassFish Server Open Source Edition 4.0 (build 89)


Issue Links:
Duplicate
is duplicated by JAVAEETUTORIAL-238 NullPoint error in chapter 8.5 Compo... Closed
Tags:
Participants: irinipaci

 Description   

Given

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:f="http://xmlns.jcp.org/jsf/core">

    <f:metadata>
        <f:viewParam name="id" value="#{myBean.id}" />
    </f:metadata>
</html>

myBean.id will never be populated. However, changing the xmlns to the following fixes it:

xmlns:f="http://java.sun.com/jsf/core"

Glassfish 4 should support the new xmlns for an EE7 project (JSF version 2.2).






[JAVASERVERFACES_SPEC_PUBLIC-1236] For Ajax File Uploads: Investigate the use of XMLHttpRequest2 (If available). Created: 31/Jul/13  Updated: 07/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File mojarra-trunk-xhr2-upload.patch    
Tags:
Participants: kfyten and rogerk

 Description   

Investigate the use of XMLHttpRequest (Level2) for file uploads (if available) and fall back to iframe if it is not available.



 Comments   
Comment by kfyten [ 10/Sep/13 11:27 PM ]

Reminder that ICEsoft has submitted a patch for this, would be nice if the JIRA reflected this, etc.

Also note that MyFaces has preliminary support for this already, see https://issues.apache.org/jira/browse/MYFACES-2852.

Comment by rogerk [ 30/Sep/13 05:54 PM ]

Contribution From IceSoft





[JAVASERVERFACES_SPEC_PUBLIC-1211] UIOutput.resetValue() and UIInput.resetValue() produce unwanted state that is equal to the default values of the property accessor methods Created: 30/Jul/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle-1211.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-2965 UIData performance and state saving i... Closed
Tags:
Participants: Hanspeter Duennenberger

 Description   

UIOutput/UIInput resetState() call set methods that cause StateHelper to add state that actually is the same as the default values that would be returned by the respective get-methods.

Proposed state neutral solution is be to remove the state from StateHelper using getStatehelper().remove(PropertyKey.xxx).



 Comments   
Comment by Hanspeter Duennenberger [ 30/Jul/13 12:50 PM ]

if resetValue() would remove the state UIData could make use of UIInput.resetValue() while restoring descendant state iterating the rows.

Comment by Hanspeter Duennenberger [ 30/Jul/13 02:20 PM ]

Added changebundle containing the proposed changes.





[JAVASERVERFACES_SPEC_PUBLIC-1210] Account for BCP47 Created: 26/Jul/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator)
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Related
is related to PORTLETSPEC3-6 Errata: Clarification for section "PL... Resolved
Tags:
Participants: Ed Burns

 Description   

Internet Best Current Practice 47 <http://tools.ietf.org/html/bcp47> defines new subtags for the "script" of a Locale. That is, the way in which the text is written. We need to update the JSF spec to account for this additional aspect of localization.

PORTLETSPEC3-6 mentions one area of impact,

<xsd:complexType name="faces-config-supported-localeType">

We also need to do this for default-locale.






[JAVASERVERFACES_SPEC_PUBLIC-1208] Allow page authors to define ordering of resources in the <head> Created: 10/Jul/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Facelets/VDL, Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75

 Description   

Right now, developers have no control over the ordering of resources loaded in the HEAD of the document. This can cause problems with ordering of CSS, JavaScript resources, or browser behavior. Something like PrimeFaces' solution (http://blog.primefaces.org/?p=1433) is definitely needed.

I ran into this requirement trying to force IE to use "IE 8 Standards Mode". This requires a <meta> header, but it must be the first element in the <head>. This isn't possible without a custom component or a third-party library like PrimeFaces.. See http://social.msdn.microsoft.com/Forums/ie/en-US/afb57ce6-d149-4a09-8811-63c0645c92e6/force-ie8-to-render-in-ie8-standard-mode.






[JAVASERVERFACES_SPEC_PUBLIC-1204] h:commandLink behaves different from h:commandButton Created: 08/Jul/13  Updated: 08/Jul/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0,


Tags: html5
Participants: Ed Burns and jasonzhang2002gmailcom

 Description   

If a submit button is generated, browser will perform some extra tasks in HTML5 when the button is clicked. For example, browser may need to validate the form, and include input fields for this form (but out of form in DOM structure). When a link is generated, script is used to perform submission. The extra tasks performed by the form will not be performed.

Given the new html5 validation support, validation could be moved to client side. The tasks performed by browser could be important. I suggest to generate a hidden button if link is requested. When link is clicked, the event is routed to the hidden button. By this way, the browser action is always invoked.

-jason



 Comments   
Comment by Ed Burns [ 08/Jul/13 01:48 PM ]

This is a spec issue and must be brought to the expert group.





[JAVASERVERFACES_SPEC_PUBLIC-1206] required attribute is not enforced for inputFile Created: 08/Jul/13  Updated: 10/Jul/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0, Firefox


Issue Links:
Related
is related to JAVASERVERFACES-2923 required attribute is not enforced fo... Closed
Tags: file file_upload require
Participants: Ed Burns, jasonzhang2002gmailcom and Manfred Riem

 Description   

When I select file at browser or not, I always have a part at server side. If no file is selected, the Part.size is zero.



 Comments   
Comment by Manfred Riem [ 08/Jul/13 08:39 PM ]

Can you please supply an example that reproduces the problem?

Comment by jasonzhang2002gmailcom [ 09/Jul/13 01:19 AM ]

This can be reproduced easily.

@RequestScoped
@Named
public class Test
{
	Part file;
	String str;
	public String getStr()
	{
		return str;
	}
	public void setStr(String str)
	{
		this.str = str;
	}
	public Part getFile()
	{
		return file;
	}
	public void setFile(Part file)
	{
		this.file = file;
	}
	public String save()
	{
		System.out.println("save is called");
		return null;
	}
}
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://xmlns.jcp.org/jsf/html"
	xmlns:f="http://xmlns.jcp.org/jsf/core"
	xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"
	xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
	
<h:body>
	<h:messages>
	</h:messages>
	<h:form enctype="multipart/form-data">
		<h:inputFile value="#{test.file}" id="file" required="true"></h:inputFile>
		<h:inputText value="#{test.str}" id="string" required="true"></h:inputText>
		<h:commandButton value="submit" action="#{test.save}">
		</h:commandButton>
	</h:form>
</h:body>
</html>
Comment by Ed Burns [ 09/Jul/13 08:33 PM ]

Manfred and I investigated this and determined that UIInput.isEmpty() doesn't correctly handle this case when there is a Part that is empty.

UIInput.isEmpty() was added in support of JAVASERVERFACES_SPEC_PUBLIC-426.





[JAVASERVERFACES_SPEC_PUBLIC-1203] Empty String as Null is not effective in 2.2.0 Created: 04/Jul/13  Updated: 10/Apr/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0, EL 3.0


Issue Links:
Related
is related to JAVASERVERFACES-3071 javax.faces.INTERPRET_EMPTY_STRING_SU... Closed
Tags: null string
Participants: Ed Burns, jasonzhang2002gmailcom and rekiem87

 Description   

GlassFish 4.0 uses EL 3.0.
Section 1.23.2 in EL 3.0 states that null String will be converted to empty String.
So we need a ELResolver to handle the conversion somethig like this

public class NullStringHanlder  extends ELResolver
{

	@Override
	public Class<?> getCommonPropertyType(ELContext context, Object base)
	{
		
		return String.class;
	}

	@Override
	public Iterator<FeatureDescriptor> getFeatureDescriptors(ELContext context,
			Object base)
	{
		return null;
	}

	@Override
	public Class<?> getType(ELContext context, Object base, Object property)
	{
		
		return null;
	}

	@Override
	public Object getValue(ELContext context, Object base, Object property)
	{
		
		return null;
	}

	@Override
	public boolean isReadOnly(ELContext context, Object base, Object property)
	{
		
		return true;
	}

	@Override
	public void setValue(ELContext context, Object base, Object property,
			Object value)
	{
		
		
	}

	@Override
	public Object convertToType(ELContext context, Object obj,
			Class<?> targetType)
	{
		if (obj==null && String.class.equals(targetType))
		{
			context.setPropertyResolved(true);;
			return null;
		}
		return null;
			
		
	}
	

}


 Comments   
Comment by Ed Burns [ 05/Jul/13 01:11 PM ]

Thanks for taking the time to report this. How do you suggest we reconcile this issue with the meaning of the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context-param? This param is described in section 11.1.3 Application Configuration Parameters of the spec.

javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL – If this param is set, and calling toLowerCase().equals("true") on a String representation of its value returns true, any implementation of UIInput.validate() must take the following additional action.
If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and UIInput.getSubmittedValue() returns a zero-length String call UIInput.setSubmittedValue(null) and continue processing using null as the current submitted value

Comment by jasonzhang2002gmailcom [ 05/Jul/13 08:11 PM ]

This is integration issue. Mojarra definitely follows the specification. However, the problem is deeply down into EL implementation/Spec. I am currently using a custom ELResolver(see above) only for this string conversion. By this way, no mojarra or EL is effected. Mojarra can come with such a resolver to explicitly to control the string conversion by default.

Comment by Ed Burns [ 08/Jul/13 01:46 PM ]

We need to move this to the spec issue tracker because what you are asking is a spec change. We understand that EL 3.0 allows this, but we would need to bring this issue up to the expert group.

Comment by rekiem87 [ 10/Apr/14 08:47 PM ]

Glassfish 4.0.1 with the latest mojarra still have the issue





[JAVASERVERFACES_SPEC_PUBLIC-1202] cc:attributes type attribute: fallback case: use what the ELResolver returns. Created: 03/Jul/13  Updated: 03/Jul/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Tags:
Participants: Ed Burns

 Description   

JAVASERVERFACES_SPEC_PUBLIC-745 amended the language for the Composite Component Attributes ELResolver's getType() method.

An additional change is needed for correctness to the cc:attribute tag's type attribute. The existing language states:

Declares that this attribute must be a ValueExpression whose expected type is given by the value of this attribute. If not specified, and no "method-signature" attribute is present, java.lang.Object is assumed. This attribute is mutually exclusive with the "method-signature" attribute. If both attributes are present, the "method-signature" attribute is ignored.

This needs to be changed. Instead of assuming java.lang.Object, the system must use the return from the CC attribute ELResolver's getType() method.






[JAVASERVERFACES_SPEC_PUBLIC-1201] Require that the cookie used to store the Flash key is setHttpOnly(true) Created: 02/Jul/13  Updated: 02/Jul/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Issue Links:
Dependency
depends on JAVASERVERFACES-2911 For JSF 2.2 and beyond, do setHttpOnl... Closed
Tags:
Participants: Ed Burns

 Description   

Require that the cookie used to store the Flash key is setHttpOnly(true)






[JAVASERVERFACES_SPEC_PUBLIC-1200] Search parent naming containers for component Created: 28/Jun/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: aplossystems Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 15 minutes
Time Spent: Not Specified
Original Estimate: 15 minutes
Environment:

JSF 2.1.24


Tags:
Participants: aplossystems

 Description   

It's logical that when you have a tree of components you shouldn't look in the child naming containers for a relative id name as duplicates are likely to exist. However it doesn't seem logical to not look in the parent container and take the first avaiable component with that relative id as no duplicates will exist in a single layer above.

I've therefore made an simple update in the UIComponentBase that will look in the parent for the component for the relative id. There's a number of places that this will work more intuitively, especailly for people with a more basic knowledge of JSF. The first is when using relative id's within a dataTable or repeat, all of a sudden relative ids no longer work which is quite confusing if you don't know why. The second is that when you pass a relative id into a custom component it won't be able to find it as the custom component will do the find method relative to itself. The other is when using cc.clientId or similar within a custom component (granted you can just easily add a : beforehand in this scenario). I'm sure there's other times as well where this would come in useful.

Below is the code that would need to be put in place of the existing code, there's only about 5 lines of code actually changed, I've already run this through the JSF tests and everything appeared to pass :

[code]

// Identify the base component from which we will perform our search
UIComponent base = this;
UIComponent initialBase = null;
if (expr.charAt(0) == sepChar) {
// Absolute searches start at the root of the tree
while (base.getParent() != null) { base = base.getParent(); }
// Treat remainder of the expression as relative
expr = expr.substring(1);
} else if (!(base instanceof NamingContainer)) {
// Relative expressions start at the closest NamingContainer or root
while (base.getParent() != null) {
if (base instanceof NamingContainer) { break; }
base = base.getParent();
}
initialBase = base;
}

// Evaluate the search expression (now guaranteed to be relative)
UIComponent result = null;
String[] segments = expr.split(SEPARATOR_STRING);
for (int i = 0, length = (segments.length - 1);
i < segments.length;
i++, length--) {
result = findComponent(base, segments[i], (i == 0));
// the first element of the expression may match base.id
// (vs. a child if of base)
if (i == 0 && result == null &&
segments[i].equals(base.getId())) { result = base; }
if (result Unable to render embedded object: File (= null && () not found.(result instanceof NamingContainer)) && length > 0) { throw new IllegalArgumentException(segments[i]); }
if (result == null) { break; }
base = result;
}

if( result == null && initialBase != null && initialBase.getParent() != null ) { initialBase.getParent().findComponent(expr); }
[/code]






[JAVASERVERFACES_SPEC_PUBLIC-1199] Missing throws clauses in javadoc for implementing classes. Created: 11/Jun/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A


File Attachments: Text File file_list.txt    
Tags:
Participants: dougd

 Description   

It appears that when we leave the javadoc of an Implementing classes method(s), that we are not getting all the throws clauses that we should be.

Example:
javax.faces.validator.MethodExpressionValidator implements the javax.faces.components.Stateholder interface, and implements saveState & restoreState methods. The API documents for these methods are copied automatically fro the StateHolder interface javadocs, but the "throws" clause is not being copied. We might need to implicitly tell the javadoc too do do this by adding something like the below.

/**

  • {@inheritDoc}
    * @throws{@inheritDoc}

    */

I have attached a file that contains a list of classes that have the "Description copied from" string in there Javadoc at some point. This file should help whom ever needs to go through and clean up the classes.






[JAVASERVERFACES_SPEC_PUBLIC-1198] Specify behavior when multiple phase-listener decls with same FQCN are encountered Created: 11/Jun/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

The XSD for <phase-listener> states:

The "phase-listener" element contains the fully qualified class
name of the concrete PhaseListener implementation class that will
be registered on the Lifecycle.

What is the correct behavior if multiple decls with the exact same FQCN are encountered? I think it should be "last one wins, log a message if more than one".






[JAVASERVERFACES_SPEC_PUBLIC-1197] Support multiple attribute on h:inputFile Created: 10/Jun/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-802 Ajax fileupload capabilities Closed
Tags:
Participants: Ed Burns

 Description   

HTML 5 has a new attribute on input file: multiple.

When present, the user agent must allow the file chooser to select multiple files.

While the pass through attributes feature allows this to render correctly:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
      xmlns:f="http://xmlns.jcp.org/jsf/core"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:p="http://xmlns.jcp.org/jsf/passthrough">
    <h:head></h:head>

    <h:form id="form" enctype="multipart/form-data" prependId="false">
        
        <p><h:inputFile id="file" value="#{fileUploadBean.uploadedFile}" p:multiple="multiple"> 
             <f:validator validatorId="FileValidator" />
           </h:inputFile>
        </p>
...

The renderer for javax.faces.Input javax.faces.File doesn't handle this case correctly.

Instead, as it iterates through the parts, it just overwrites the preceding part with each file in the uploaded collection.

I think a better strategy is to always have the value of the component be a List<Part> instead of just Part.






[JAVASERVERFACES_SPEC_PUBLIC-1196] CC-like conveniences for Facelet tags Created: 02/Jun/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use ease_of_development facelets tag taglib
Participants: arjan tijms and Ed Burns

 Description   

In JSF 2.x there are composite components and Facelets tags. A prime difference between these two is that composite components become a component themselves in the component tree, while Facelets tags cause their "child" components to be inserted but they themselves do not become part of the tree.

Both these two artifacts have their own unique use cases, and thus the newer composite component cannot totally replace the older Facelet tags.

However, composite components being the more modern variant have several ease of use features such as the ability for being auto-registering when put into the /resources folder and the definition of its attributes directly into the defining .xhtml file.

Since Facelets tags are still very useful in modern JSF programming, I'd like to request them being upgraded to support auto-registering and attribute definition in the .xhtml file as well.

E.g.

/resources/mytag.xhtml
<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
    
    <ui:attribute name="foo" />
    
    ...
</ui:composition>

The above would register a Facelets tag just like the following in a -taglib.xml would do:

<tag>
    <tag-name>mytag</tag-name>
    <source>tags/mytag.xhtml</source>
    <attribute>
        <name>foo</name>	
    </attribute>
</tag>


 Comments   
Comment by Ed Burns [ 10/Jun/13 11:40 PM ]

This is a nice idea.





[JAVASERVERFACES_SPEC_PUBLIC-1195] cc.attrs not avaiable when rendering h:outputStyleSheet Created: 24/May/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tiagoperes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apache Tomcat 7.0.34 running in Windows 8


Tags: outputStyleSheet composite-component
Participants: tiagoperes

 Description   

Situation:
A composite component has its attributes declared with the "composite-attribute" tags, one of these attributes is "theme", used to specify the css file to be used by the component.

<composite:interface>
<composite:attribute name="theme" required="false" default="rose" />
...
</composite:interface>

At the component's implementation I try to import the css file using the "h:outputStyleSheet" tag.

<composite:implementation>
<h:outputStylesheet library="components" name="calendar/#{theme}/calendar.css" />
...
</composite:implementation>

Expected behavior:
If no attribute "theme" is specified by the page calling the component, "h:outputStylesheet" should import "calendar/rose/calendar.css". If a theme is specified it should import the specified theme.

Actual behavior:
"h:outputStylesheet" tries to import "calendar//calendar.css", no matter if a theme was specified or not.

My thoughts:
I tried to specify the theme directly inside the EL expression (name="#{'rose'}"), it worked, so it's not an expression problem. I think the cc.attrs variables are not available when "h:outputStylesheet" is processed.

There's a similar problem described in Stack Overflow:
http://stackoverflow.com/questions/7386344/evaluating-the-rendered-attribute-of-houtputstylesheet-inside-a-composite






[JAVASERVERFACES_SPEC_PUBLIC-1193] Declaring component attributes via annotations Created: 11/May/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use ease_of_development no-xml annotation annotations
Participants: arjan tijms

 Description   

As of JAVASERVERFACES_SPEC_PUBLIC-594, custom components can be declared to be useable in Facelets via the @FacesComponent annotation. Via this it's no longer required to have an entry in a taglib.xml file.

However, if the component author wishes to declare the component's attributes (for documentation, tooling, etc), XML still has to be used.

I therefor would like to propose declaring these attributes via annotations as well.

E.g.

@FacesComponent(value="components.CustomComponent", createTag=true)
public class Foo extends UIComponentBase {

    @Attribute
    String color; // will be injected with getAttributes("color") 

    @Attribute(description="This will determine the ...", required=true)
    String style;

    @Attribute(description="The cost of ... ", default="100")
    Integer cost;

}





[JAVASERVERFACES_SPEC_PUBLIC-1192] setProperties for validator behaviour is not there for mojarra-2.1.1 , Created: 09/May/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.1 Rev a
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dorarajappan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: dorarajappan

 Description   

issue reference https://issues.apache.org/jira/browse/MYFACES-1892

As shown in this dtd:
http://java.sun.com/dtd/web-facesconfig_1_1.dtd

the validator element in a faces-config.xml file should support nested attribute and property elements:

<validator>
<validator-id>xyValidtor</validator-name>
<validator-class>com.xy.XyValidator</validator-class>
<property>
<property-name>length</property-name>
<property-class>java.lang.Integer</property>
<default-value>40</default-value>
</property>
</validator>

However this appears to never have been implemented in either 1.1.x or 1.2.x of core; only validator-id and validator-class are supported. Note that the equivalent feature exists for converters, and does appear to have been implemented.

What is the reason reference implementation is not having this behaviour?






[JAVASERVERFACES_SPEC_PUBLIC-1191] SelectMany with generic collection results in ClassCastException Created: 07/May/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: djmj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.12


Tags: selectmanylistbox selectmanycheckbox generic collection
Participants: djmj

 Description   

Using a generic wrapper class similar to java.util.Map.Entry with a collection as generic value argument within a selectmany-component will result in following ClassCastException on submit:

Bean.java
private List<String> values;

private Entry<TestType, List<String>> entry;
site.xhtml
<h:selectManyMenu value="#{bean.entry.value}">
	<f:selectItems value="#{bean.values}"
		var="var" itemLabel="#{var}" itemValue="#{var}"/>
</h:selectManyMenu>

"java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to java.util.Collection"

(the Entry class does not works since it does not follows bean conventions, but its just for understanding of the generic problem)






[JAVASERVERFACES_SPEC_PUBLIC-1190] Extend facelet-taglib schema Created: 30/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Schema
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: taglib facelets
Participants: arjan tijms

 Description   

The Facelet taglib XML file has a number of limitations and it might be a good idea to improve the format.

Currently when a component inherits from another component, each and every attribute of the parent component has to be copied into the tag declaration in the taglib file. This makes taglib files very verbose and makes it hard to see which attribute the new tag introduces. A solution to this would be adding a way to declare that a tag inherits from another tag.

For instance:

<tag extends-namespace="http://java.sun.com/jsf/html" extends-tag="form">
    <tag-name>form</tag-name>
    <component>
        <component-type>org.example.Form</component-type>
    </component>

    <attribute>
        <description>
            Whether to include all URL (GET) request parameters in the action URI.
        </description>
        <name>includeRequestParams</name>
        <required>false</required>
        <type>boolean</type>
    </attribute>

    <!-- 20+ attributes of h:form such as "render", "accept", etc inherited -->
</tag>

Components in JSF can introduce an (EL) variable for their children to consume, e.g. like the var attribute of a datatable. This can however not be declared in a taglib, so tools have to have hardcoded knowledge of which tag does what with which attribute. This means tools lack behind new tags from a certain component library and only well known component libraries are supported. It would be great if it could be declared that an attribute represents the name of an introduced (EL) variable.

For instance:

<attribute>
    <description>
        Name of a request-scope attribute under which the model data for the
        row selected by the current value of the "rowIndex" property
        (i.e. also the current value of the "rowData" property) will be exposed.
    </description>
    <name>var</name>
    <required>false</required>
    <type>java.lang.String</type>
    <output>
        <scope>request</scope>
        <type-ref-attribute>value</type-ref-attribute>
        <type-ref-collection-element>true</type-ref-collection-element>
    </output>
</attribute>

In the above example var is declared to be an "output variable", that has as its type the type of the "collection element" that's bound to the value attribute. E.g. if value is bound to a List<Foo>, then the type of var is Foo. Other options would be setting a fixed type or referring directly to the type of another attribute.

Another issue is that attributes often have a default and an allowed range of values. This now has to be communicated in the description of an attribute and that description has to be kept in sync with the actual code. Tools sometimes have hardcoded knowledge of the allowed values (for auto-completion and warning flagging) for some attribute, but this too can be out of sync with newer releases of a component lib and doesn't support lesser known or internal components.

It would help a lot of this could be declared in a taglib file as well. E.g.:

<attribute>
    <description>The ordering type.</description>
    <name>type</name>
    <required>false</required>
    <type>java.lang.String</type>
    <allowed-values>lt, lte, gt, gte</allowed-values>
    <default>lt</default>
</attribute>

Some JSF components, like e.g. datatable support multiple types for a given attribute. It might be an improvement if these types could be enumerated in the attribute's declaration, e.g.

<attribute>
    <description>
        The current value of this component.
    </description>
    <name>value</name>
    <required>false</required>
    <types>
        <type>javax.faces.model.DataModel</type>
        <type>java.util.List</type>
        <type>java.lang.Object[]</type>
        <type>java.sql.ResultSet</type>
        <type>javax.servlet.jsp.jstl.sql.Result</type>
        <type>java.util.Collection</type>
        <type>java.lang.Object </type>
    <types>
</attribute>

I'm sure there might be some other areas where taglib files can be improved besides the use cases mentioned above.






[JAVASERVERFACES_SPEC_PUBLIC-1189] Flow identifier in @FlowDefinition Created: 29/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: arungupta Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fishcat
Participants: arungupta

 Description   

@Produces @FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { String flowId = "flow1"; flowBuilder.id("unique", flowId); flowBuilder.viewNode(flowId, "/" + flowId + "/" + flowId + ".xhtml").markAsStartNode(); return flowBuilder.getFlow(); }

can be simplified to:

@Produces @FlowDefinition("flow1")
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { ... }






[JAVASERVERFACES_SPEC_PUBLIC-1188] Specify what should happen if the same flow is defined both in XML and via @FlowDefinition Created: 29/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

The spec for FlowHandler.addFlow() requires an IllegalStateException be thrown if there is already a flow with the same identification as the one trying to be added.

The spec does not say the ordering in which flows should be added

XML then Java
Java then XML

This needs to be clarified.






[JAVASERVERFACES_SPEC_PUBLIC-1187] SelectItem ignores null value if used with converter that returns null Created: 27/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: djmj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2


Tags: converter selectItem selectItems
Participants: djmj

 Description   

Using a 'selectItem' with a 'null' value and a converter that will return 'null' for this value will ignore the value in the html output.

If the value is ignored not renderd in html 'select' tag the submitted value will be the label since no value was provided.

site.xhtml
<f:selectItem itemLabel="None" itemValue="#{null}"/>
TestConverter.java
@Override
public String getAsString(final FacesContext context, final UIComponent component, final Object value)
{
	if (value == null)
		return null;
	else
		return String.valueOf(value);
}

@Override
public Object getAsObject(final FacesContext context, final UIComponent component, final String value)
{
	if (value == null || value.trim() == "")
		return null;

	// convert string to object here just example

	return null;
}
Html output
<option>None</option>

Submitting the form will lead to a conversion error: "None" cannot be converted...
since html takes the label as the value if no value is provided.

Should the desired html not be in which case the conversion would succeed.

Html output desired
<option value="">None</option>

Returning empty String would lead to desired behavior. But I would prefer returning null instead, and also because of issue: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1180






[JAVASERVERFACES_SPEC_PUBLIC-1185] Pass Through attribute should have priority when rendering Created: 25/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bruno Borges, Ed Burns, Frank Caputo and jyeary

 Description   

Tried the following code:

index.xhtml
<a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a>

The href attribute rendered contains the value anotherPage_fake.xhtml. In this case (and similar others), the pass through attribute should have priority in the rendering process, if it will compete with a static attribute.



 Comments   
Comment by Bruno Borges [ 13/Aug/13 05:34 AM ]

Digging more into Pass Through Attributes, I find this feature one of the best things I've ever seen in JSF in years, because it could bring development/designer preview without the need to run an app server. A feature that several frameworks permit, such as Apache Wicket and Tapestry. But if Pass Through Attributes doesn't override regular attributes, then it becomes not interesting.

The spec is not clear about this, and I think it should be provided an Errata, with a change in the current implementation.

Sample A

<script type="text/javascript"
             src="../../js/jQuery.js"
             p:src="${facesContext.externalContext.requestContextPath}/js/jQuery.js"></script>

Sample B

<script type="text/javascript" src="../../js/jQuery.js">
    <f:passThroughAttribute
       name="src"
       value="${facesContext.externalContext.requestContextPath}/js/jQuery.js" />
</script>

Either samples should end up with this:

<script type="text/javascript" src="/myapp-1.0-SNAPSHOT/js/jQuery.js"></script>
Comment by Frank Caputo [ 13/Aug/13 06:29 AM ]

Pass through attributes have priority as specified in the “Rendering Pass Through Attributes” section of the overview of the standard HTML_BASIC render kit: https://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_behavior_encoding

In <a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a> the href attribute becomes a pass through attribute and thus has priority.

Comment by Bruno Borges [ 13/Aug/13 06:37 AM ]

Hi Frank, thanks for pointing that out, but I disagree that "static" attributes should have priority when faced against calculated/dynamic attributes such as jsf:outcome.

If an element has both attributes (a static like 'href', and a dynamic as 'jsf:outcome'), the general idea is that the static attribute is for static preview/prototyping only, and should be replaced by the calculated value.

This is how other web frameworks have been doing for years.

Comment by jyeary [ 13/Aug/13 03:21 PM ]

The link you specified has some very specific text about priority.

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence. Pass through attributes are rendered as if they were passed to ResponseWriter.writeURIAttribute().

Unless I am reading this incorrectly, the jsf:outcome should take precedence over the static href attribute. I am on the fence on this though. I think that the pass through attributes are a great addition to the framework. However, if the renderer has the attribute defined, it can be set dynamically using EL. In this case, pass through attributes are simply duplicating the renderer specific attributes. This is for the case of the JSF components.

What advantages do we gain from the pass through taking precedence over the renderer specific attributes if they duplicate each other? I would say that the renderer specific attributes should take precedence.

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

Comment by Bruno Borges [ 13/Aug/13 04:01 PM ]

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

This is what I'm looking for. I don't want to loose the "previability" of the page.

Comment by Ed Burns [ 28/Aug/13 08:43 PM ]

From the spec section cited by John and Frank:

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence.

Consider Bruno's original markup:

<a href="anotherPage_fake.xhtml" 
   jsf:outcome="/anotherPage.xhtml">Another Page</a>

Because this is an <a> element with a jsf:outcome attribute, it is treated as an h:link, specified in the following.

http://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html

Perhaps the root problem here is that there is another set of attributes that must be considered, separate from the set of renderer specific attributes. This is the set of attributes that the renderer itself must use when rendering the component. Let's call these renderer required attributes. I suggest that the spec be modified to define the term renderer required attributes, and to say that renderer required attributes take precedence over pass through attributes on the markup.

Unfortunately, there is no runtime representation of the set of renderer required attributes, so it's not possible for the spec to say that, though. We would need to have a way for each renderer to declare its set of renderer required attributes, then we could require the ResponseWriter to act accordingly based on the priority.

There is no conflict because "href" is not a renderer specific attribute.





[JAVASERVERFACES_SPEC_PUBLIC-1184] Support using JSON for component updates instead of XML Created: 22/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript, Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and kito75

 Description   

One of the primary complaints about JSF is speed. We have paid a lot
of attention to optimizing server-side state over the past few years,
but we can also optimize the processing on the client. When a
component is updated via Ajax, currently we render the entire
component, even if only one property has changed. It would be much
more efficient if we sent only the changed properties via JSON and let
the client-side representation of the component update itself
accordingly. I have implemented a limited version of this for one of
my clients, and Ajax updates are noticeably faster. Updating the spec
to support this would not be a major change (because components would
opt-in to this feature), but it would have a dramatic affect on
client-side Ajax updates.

Initial EG thread: https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/105

I will post a more formal proposal later.



 Comments   
Comment by arjan tijms [ 11/May/13 04:19 PM ]

This sounds very useful! The title may not tell the whole story though; it's thus not just about JSON vs XML, but also about doing delta updates instead of full updates, right?

Comment by kito75 [ 13/May/13 12:36 PM ]

Arjun, you're exactly right.





[JAVASERVERFACES_SPEC_PUBLIC-1183] selectMany components swallow/forgets preselected disabled SeletItems Created: 18/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2555 selectMany components swallow/forgets... Closed
Tags:
Participants: Hanspeter Duennenberger and Manfred Riem

 Description   

Consider this situation: you have a number of options and some options are already selected but must not be unselected. SelectItem allows to pass a disable item state and the item will be correctly rendered as checked but disabled. If some other options/checkboxes are enabled during decode only the submitted options will survive - the preselected disabled option will be lost since the disabled items checked state is not submitted.

I have a fix ready for that and also a test application - what's currently missing is the unit test for it, but I hope Manfred could help me out with that.

The change works like this: during rendering selected & disabled itemValues will be added to a Set that is maintained on the component attributes map with name "selectedDisabledItems". This Set, if existing, will be merged to the newValues[] array with the submitted values.

See attached changebundle.txt and the sources of the test bean and page.



 Comments   
Comment by Manfred Riem [ 18/Apr/13 02:25 PM ]

Please see associated issue for attachments





Support for WAI ARIA (JAVASERVERFACES_SPEC_PUBLIC-462)

[JAVASERVERFACES_SPEC_PUBLIC-1181] Add support for WAI-ARIA to standard input components Created: 10/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript, Components/Renderers
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Sub-task Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75

 Description   

In cases where ARIA attributes have a reasonable mapping to existing component-level properties (eg. aria-required can be mapped to <h:inputText>'s required attribute, aria-invalid can be mapped to the EditableValueHolder's valid state), we should enhance the standard Renderers to automatically render the ARIA attributes. For other ARIA attributes, passthrough attributes can be used.

This task requires an analysis of the input controls to determine which ones need changes, but generally speaking any UI component that maps to a native HTML widget should support aria-invald and aria-rquired attributes, and possibly aria-readonly. For a full list of support states and properties, see: http://www.w3.org/TR/wai-aria/states_and_properties#state_prop_def.

Original thread: http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2013-03/message/124






[JAVASERVERFACES_SPEC_PUBLIC-1222] ValueChange method in POJO doesn't resolve correctly when POJO is a ui:param Created: 09/Apr/13  Updated: 09/Sep/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS X 10.8.3


File Attachments: Zip Archive cc-ui-param.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1223 Facelet ui:param doesn't work in comp... Open
Tags:
Participants: Manfred Riem and Thomas

 Description   

Normally a composite component can resolve a valueChange method in a POJO that is a property of managed bean.

This is often used to pass a POJO to a <ui:include>:

<ui:include src="part.xhtml">
    <ui:param name="pojo" value="#{managedColors.unmanaged}"/>
</ui:include>

The using page would be:

<custom:list list="#{pojo.colors}"
             selected="#{pojo.color1}"
             valueChangeListener="#{pojo.onColorChange}">
    <f:ajax event="valueChange" execute="@this" render="@this"/>
</custom:list>

However, when the unmanaged bean (POJO) is passed as a <ui:param>, attempting to change the value will result in the following exception:

javax.faces.event.AbortProcessingException
/part.xhtml @10,62 valueChangeListener="#{pojo.onColorChange}":
The class 'com.custom.beans.PojoColors' does not have the property 'onColorChange'.

The valueChange method seems to only be resolved correctly be writing out the complete EL expression:

<custom:list selected="#{managedColors.unmanaged.color1}"
             list="#{managedColors.unmanaged.colors}"
             valueChangeListener="#{managedColors.unmanaged.onColorChange}">
    <f:ajax event="valueChange" execute="@this" render="@this"/>
</custom:list>

A simple example project for NetBeans has been attached detailing this issue.



 Comments   
Comment by Thomas [ 09/Apr/13 07:27 PM ]

I can attach a sample project reproducing this issue once I have permissions to attach files.

EDIT:
Here's a link to a sample NetBeans project detailing the issue: https://www.dropbox.com/sh/ojdj6mbykzpxr9t/svlgMUzFw4

Comment by Manfred Riem [ 09/Apr/13 08:21 PM ]

Please send your sample zip file to issues@javaserverfaces.java.net. Can you please try it on the latest 2.1 release? Thanks!

Comment by Thomas [ 09/Apr/13 09:32 PM ]

I've sent the sample zip project.

I've also reproduced this issue on the latest 2.1 release, which I believe is Implementation-Version: 2.1.20.

I did this by replacing the 2.1.6-SNAPSHOT version of javax.faces.jar in

/Applications/NetBeans/glassfish-3.1.2.2/glassfish/modules/javax.faces.jar

and confirming the new version 2.1.20 was loading via

FacesContext.class.getPackage().getImplementationVersion();

Thanks for the fast responses!

Comment by Thomas [ 10/Apr/13 07:12 PM ]

Just tried it on the latest javax.faces.jar 2.2.0-m13-SNAPSHOT and got the same type of error of:

The class 'com.custom.beans.PojoColors' does not have the property 'onColorChange'
Comment by Thomas [ 10/Apr/13 08:30 PM ]

Actually this doesn't seem to be a POJO issue, but something wrong with EL resolution on the ui:param in a composite component.

I tried passing a managed bean in a ui:param and got a property not found type of exception as well:

<ui:include src="part.xhtml">
   <ui:param name="managed" value="#{managedColors}" />
</ui:include>
<ui:composition ..>
    <custom:list list="#{managed.colors}"
               selected="#{managed.color1}"
               valueChangeListener="#{managed.onColorChange}">
      <f:ajax event="valueChange" execute="@this" render="@this"/>
  </custom:list>
</ui:composition>

Attempting to change the value results in the same type of error, except now it also occurs for a managed bean:

The class 'com.custom.beans.ManagedColors' does not have the property 'onColorChange'.
Comment by Manfred Riem [ 30/Aug/13 04:52 PM ]

You have hit upon an area with respect to composite components and ui:include that has not been ironed out as much as needed. The problem is that the context of the ui:param is not available within a retargetted method expression. And as such the resolution of the value expression is unable to find the 'pojo' variable.

You are aware that instead of using a ui:include you can pass a bean to a composite component as an attribute and then use the attribute to resolve to the valuenChange method?

I am moving this to the spec issue tracker as the real issue still exists.





[JAVASERVERFACES_SPEC_PUBLIC-1180] Do not include empty view params using `includeViewParams=true` Created: 07/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript, Navigation
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: djmj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.12


Tags: includeviewparams navigation
Participants: djmj

 Description   

Having a command component with an action attribute and using 'includeViewParams=true' using Navigation will include all view parameters defined in `f:metadata`.

But empty parameters are passed as String representations creating ugly url's.

'site.xhtml?key1=value1&key2=&key3='



 Comments   
Comment by djmj [ 27/Apr/13 06:28 PM ]

In my Converter's I return now null instead of empty String. Since it seems null value's won't be included.

But this leads to other issue: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1187





[JAVASERVERFACES_SPEC_PUBLIC-1179] Clarify UIComponent.encodeAll requirements Created: 04/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: aschwart

 Description   

As requested by Manfred here:

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

I am logging this issue to request that the spec be more explicitly in stating that JSF implementations must call UIComponent.encodeAll() instead of directly calling each of encodeBegin/encodeChildren/encodeEnd() when rendering any component.

The reason for this is that UIComponent.encodeAll() is a non-final public method that components are free to override. JSF implementations should never bypass these overrides since this can result in bugs/loss of functionality.






[JAVASERVERFACES_SPEC_PUBLIC-1223] Facelet ui:param doesn't work in composite components (action) Created: 26/Mar/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dasago Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1222 ValueChange method in POJO doesn't re... Open
Tags:
Participants: dasago, Ed Burns, Manfred Riem and Thomas

 Description   

If i have a facelet file which includes a composite component and I want to pass ui:params for the action it doesn't work

File a.xhtml includes my template myTemplate.xhtml. I want to pass parameters for an action

<ui:include src="/pages/templates/myTemplate.xhtml">
      <ui:param name="resetAction" value="reset" />
      <ui:param name="bean" value="#{myBean}" />
</ui:include>

Following works / works not in myTemplate.xhtml:

value is displayed

<h:outputText value="Bean: #{bean}" />

value is displayed

<h:outputText value="resetAction: #{resetAction}" />

Action doesn't work if i pass it into a compositeComponent

<myCom:reset resetAction="#{bean[resetAction]}" />

for a commandButton it works.

<p:commandButton value="test reset" action="#{bean[resetAction]}" />

If I don't add my composite component to a facelet tempalte the action also works:

<myCom:reset resetAction="#{myBean.reset}" />



 Comments   
Comment by Manfred Riem [ 09/Apr/13 03:55 PM ]

Can you send the entire reproducer (including all the sources) to issues@javaserverfaces.java.net?

Comment by dasago [ 10/Apr/13 08:51 AM ]

I send you an example project.. (maven based, JBoss 6.0 Final, Mojarra 2.1.17, PrimeFaces 3.5, Omnifaces 1.4.1)

First example in reset page works - pass values directly to composite component

Second example in reset page doesn't work - pass values via facelet file to composite component

Third example in reset page works - pass values via facelet file to composite component with a workaround of omnifaces

Comment by Manfred Riem [ 30/Aug/13 05:31 PM ]

You have hit upon an area with respect to composite components and ui:include that has not been ironed out as much as needed. The problem is that the context of the ui:param is not available within a retargetted expression that the action needs to actually work.

I am moving this to the spec issue tracker as the real issue still exists.

Comment by Thomas [ 30/Aug/13 09:13 PM ]

This is probably a better description of the JAVASERVERFACES_SPEC_PUBLIC-1222 issue I filed. Being a POJO or a managed bean is unrelated if I recall correctly.

I've been working around this by placing the ui:param in the view outside of the ui:include so that evaluations can find the ui:param correctly.

<ui:param name="pojoOrManagedBean" value="#{bean}"/>
<ui:include src="innerPageWithCompositeComponentWithTarget"/>
Comment by Ed Burns [ 13/Sep/13 09:21 PM ]

Manfred, do you think we can close 1222 as a duplicate of this one?

Ed





[JAVASERVERFACES_SPEC_PUBLIC-1176] Separate implicit bean navigation from action method via additional outcome attribute Created: 18/Mar/13  Updated: 22/Mar/13

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: djmj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: action outcome separate view logic
Participants: djmj, Ed Burns and Manfred Riem

 Description   

The submit/command components: 'commandButton' and 'commandLink' use implicit navigation via their 'action' attribute and the returned String in the bean method that is invoked and referenced from the 'action' attribute.

Why is the navigation outcome handled in the called method of the bean and not within the the view?
Should the view not be as much separated from the logic as possible, especially if reusing code.

Adding the 'outcome' attribute of the 'button' and 'link' components to the related command components 'commandButton' and 'commandLink' would resolve this issue.

If the command component is invoked by the user the method of its 'action' attribute is called and navigates to the target defined in its 'outcome' attribute.

<h:commandButon action="#{bean.method()}" outcome="/index.xhtml"/>

Currently I used a workaround by adding my own outcome via an 'f:param' to my command, since for the few cases where I used bean-navigation the logic had to be reusable and not be bound to a specific view or application.



 Comments   
Comment by Manfred Riem [ 18/Mar/13 10:31 PM ]

Thank you for suggesting a new feature.

Note that feature requests that change existing behavior or add to it
need to be filed at the JAVASERVERFACES_SPEC_PUBLIC issue tracker.

Can you file the issue there? Thank you!

Comment by djmj [ 21/Mar/13 11:26 PM ]

I got an email that it was moved automatically to public issue tracker.

Is the closed status because of the wrong issue tracker?

So should it not be reopened, or is the issue itself invalid?

Comment by Ed Burns [ 22/Mar/13 12:43 AM ]

Re-open.





[JAVASERVERFACES_SPEC_PUBLIC-1175] Validation error removes all url parameters Created: 18/Mar/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: 2.2 Sprint 13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: a_ilyin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: a_ilyin and arjan tijms

 Description   

This bug was copied from Mojarra issue tracker. See details here:
http://java.net/jira/browse/JAVASERVERFACES-1653

When page has some url parameter(s) after server-side validation error or by
default navigation JSF navigates to the page with the same viewId but without
url parameters.

IMHO the problem is the POST method submits the form to viewId's url only
instead of using url with the parameters as original url has.

This issue makes problems with bookmarking such views with params after handling
some action(minor problem) and generating proper response after action handling
based on this parameters(major problem) .

P.S. Also this issue has another side effect. When handling some action the url
parameters are unavailable.

--------------------
I found some easy workaround for this problem.

I just slightly extend standard ViewHandler to add the queryString to the action
url:

public class UrlWorkaroundMultiViewHandler extends MultiViewHandler {

@Override
public String getActionURL(FacesContext context, String viewId) {

String result = super.getActionURL(context, viewId);
String queryString = ((HttpServletRequest) context.getExternalContext()
.getRequest()).getQueryString();
if (queryString != null) { result += "?" + queryString; }
return result;

}
}

and register it in the faces-config.xml

<application>

<view-handler>my.workaround.UrlWorkaroundMultiViewHandler</view-handler>
</application>

I'm not sure this will work for any cases and for all servlet containers. Also
I'm not sure about possible side effects.
I did check it with Jetty.

-----------------------------
UPDATE: I found that we have not add params when we handle new url. So I modify my workaround code to handle more cases:

@Override
public String getActionURL(FacesContext context, String viewId) {

String result = super.getActionURL(context, viewId);

HttpServletRequest request = ((HttpServletRequest) context
.getExternalContext().getRequest());

if (viewId.equals(request.getServletPath())) {
//Do it just if we are on the same page
String qs = request.getQueryString();
if (qs != null) { result += "?" + qs; }
}

return result;

}
===============================================
Conclusion: I believe that any valid url should be preserved as is(including query parameters). Even we do not use its url parmas on our page.



 Comments   
Comment by arjan tijms [ 20/Mar/13 04:02 PM ]

This looks like a duplicate of JAVASERVERFACES_SPEC_PUBLIC-1163.





[JAVASERVERFACES_SPEC_PUBLIC-1173] Handle gracefully the case of a link to flow based page copied to new browser tab Created: 16/Mar/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description