[JAVASERVERFACES_SPEC_PUBLIC-1196] CC-like conveniences for Facelet tags Created: 02/Jun/13  Updated: 29/Aug/15

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

Type: New Feature Priority: Minor
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use, ease_of_development, facelets, tag, taglib

 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 ]

This is a nice idea.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by djmj [ 29/Aug/15 ]

What about conditionally allowing composite component's behave like a tag or not to be a naming container?

I don't know much about the implementation background but was a developer these concepts seem much alike with little difference.
I only use tags when i dont want a naming container or i want to render the tag "as is". (for instance in a <h:panelGrid> to produce multiple cells)





[JAVASERVERFACES_SPEC_PUBLIC-1190] Extend facelet-taglib schema Created: 30/Apr/13  Updated: 13/Aug/14

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

Type: New Feature Priority: Minor
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: facelets, taglib

 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.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1024] Allow parents of forms as render targets of ajax requests Created: 11/Jul/11  Updated: 12/Aug/14

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

Type: Bug Priority: Minor
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 10
Labels: None
Remaining Estimate: 5 hours
Time Spent: Not Specified
Original Estimate: 5 hours

Tags: ajax, facelets, javascript

 Description   

Currently it is not possible to use parents of forms as render targets in <f:ajax/> or jsf.ajax.request. If an element containing one or more forms is specified in the render attribute, these forms' ViewState is not updated during the Ajax request. In my opinion it is not clear from the JSDocs, if parents of forms are allowed as render targets or not. Mojarra currently does not create an error in that case, however the jsf.ajax.request method does not create a ViewState field for descendant forms either.

Judging from the JSDoc the request method's execute parameter is not limited to forms and children of forms, it just takes a list of arbitrary client ids. It's also possible to specify '@all' for the whole view thus most likely a parent of multiple forms, which works as expected.

However the JSDoc for jsf.ajax.response states the following for ViewState updates:

If an update element is found in the response with the identifier javax.faces.ViewState:

<update id="javax.faces.ViewState">
<![CDATA[...]]>
</update>

locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response. Locate and update the javax.faces.ViewState value for all forms specified in the render target list.

This will clearly not work if only forms that are contained in the render target list directly are considered, because the list could also contain parents of forms.

For more information see the corresponding Mojarra bug report:

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



 Comments   
Comment by frederickkaempfer [ 12/Jul/11 ]

"Judging from the JSDoc the request method's execute parameter "

This was meant to be the render parameter.

Comment by frederickkaempfer [ 12/Sep/11 ]

This issue is related to (or even included in) http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790. Since this is obviously a spec bug and a fix is quite simple (updating all forms instead of only a subset defined by the render attribute on an ajax request, see Ed Burns' comment on 790) it would definitely be worth considering for 2.2.

Comment by arjan tijms [ 08/Jan/12 ]

Simple test case from duplicate issue JAVASERVERFACES-1788:

<h:panelGroup layout="block" id="group">
    <h:form>
        <h:commandLink value="Link A">
            <f:ajax />
        </h:commandLink>
    </h:form>
</h:panelGroup>

<h:form>
    <h:commandLink value="Link B">
        <f:ajax render=":group" />
    </h:commandLink>
</h:form>
  1. Press Link A - view state is submitted
  2. Press Link B, then Link A - view state is not submitted anymore
Comment by swathireddy12 [ 22/Aug/13 ]

I am making use of JSF 1.2 version of jars (myfaces-api-1.2.9.jar ,myfaces-impl-1.2.9.jar,trinidad-api-1.2.13.jar,trinidad-impl-1.2.13.jar).
I am trying to retrieve the javax.faces.ViewState using the id attribute in a Javascript which works.

But i still don't see the id attribute in the loaded page
<input type="hidden" name="javax.faces.ViewState" value="!-14uywjgjai">

Could you please tell me if this is an issue with JSF 1.2 version as well?
Or once the page is rendered the id attribute associated with "javax.faces.ViewState" is not seen anymore.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES-3682] f:param ignores disable attribute with null value causes NPE Created: 13/Jan/15  Updated: 22/Jan/15  Resolved: 22/Jan/15

Status: Closed
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.2.5, 2.2.6, 2.2.7, 2.2.8, 2.2.9
Fix Version/s: None

Type: Bug Priority: Major
Reporter: djmj Assignee: Manfred Riem
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1


Tags: converter, facelets, mojarra, nullpointerexception, parameter

 Description   

There are many very similar issues regarding this new NPE problem. Here is a new case when it occurs.

This issue is not fixed and still prevents me from updating to any version larger then 2.2.4.

<h:link>
    <f:param name="foo" value="#{cc.attrs.fooValue}" disabled="#{cc.attrs.fooValue eq null}"/>
</h:link>


 Comments   
Comment by djmj [ 13/Jan/15 ]

The error occurs if `fooValue` equals null. But thats what disabled attribute is there for, to prevent it being evaluated (similar to rendered).

Comment by Manfred Riem [ 13/Jan/15 ]

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

Comment by djmj [ 16/Jan/15 ]

I could not reproduce it using a new test project. I tried for many hours yesterday.

In my application it only happens if it evaluates to "null". I could make my values evaluate to empty string instead but this would create ugly URL's with empty parameters.

Comment by Manfred Riem [ 16/Jan/15 ]

OK, if you are having a hard time reproducing it using a new project what do you suggest? Thanks!

Comment by djmj [ 17/Jan/15 ]

I will first try an hour more to reproduce it by adding some dependencies to the project.

Comment by djmj [ 20/Jan/15 ]

Cannot reproduce it in a new empty test project or narrow it down by reducing project.
Project uses omnifaces and primefaces, but adding those to test project had no effect.

But i made a strange observation.

It only happens if two or more `<f:param>` with null values are used. It seems the `disabled` attribute of the second or any other `<f:param>` is not evaluated.

	<?xml version="1.0" encoding="UTF-8" ?>
	<!DOCTYPE html>
	<html xmlns="http://www.w3.org/1999/xhtml"
		xmlns:f="http://xmlns.jcp.org/jsf/core" 
		xmlns:h="http://xmlns.jcp.org/jsf/html">
		<f:view encoding="UTF-8">
			<h:head></h:head>
			<h:body>
				<h:link outcome="/index.xhtml" value="link">
					<f:param name="foo" value="#{foo}" disable="#{foo eq null}"/>
					<f:param name="bar" value="#{bar}" disabled="#{true}"/>
				</h:link>
			</h:body>
		</f:view>
	</html>
Comment by Manfred Riem [ 20/Jan/15 ]

So you can reproduce it with 2 params? If so can you send that reproducer to issues@javaserverfaces.java.net Thanks!

Comment by djmj [ 22/Jan/15 ]

Oh my good, i think my 4 week vacation and programming absence was not good. It was just a typo! I am really sorry to have wasted your time.

disabled instead of disable, and unfortunately while copy-pasting i always at least pasted once 'disabled'.

2.2.4 and below was very convenient just to ignore null values in this case. (And its the only JSF component where it is `disable` instead of `disabled`.)

Can be closed.

Comment by Manfred Riem [ 22/Jan/15 ]

Closing as per reporter





[JAVASERVERFACES-3190] f:param within a h:button causing a NullPointerException Created: 24/Feb/14  Updated: 27/Mar/14  Resolved: 25/Mar/14

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

Type: Bug Priority: Major
Reporter: Hildeberto Mendonça Assignee: Manfred Riem
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WildFly 8 Final


Issue Links:
Duplicate
duplicates JAVASERVERFACES-3154 NPE on f:param with null value Closed
Tags: facelets, mojarra, nullpointerexception

 Description   

I'm using WildFly 8 Final and deploying a JSF application on it. I've noticed that every time a xhtml page contains a f:param within a h:button, like the example below:

<h:button id="create" outcome="group_form" value="Create" class="btn btn-default pull-right">
     <f:param name="appId" value="#{groupMBean.selectedApplication}"/>
</h:button>

a ServletException ocurrs when I try to open it. I get the following Stacktrace:

10:17:53,839 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-3) Error Rendering View[/systems/groups.xhtml]: java.lang.NullPointerException at 
java.net.URLEncoder.encode(URLEncoder.java:205) [rt.jar:1.7.0_40] at 
com.sun.faces.context.UrlBuilder.addValuesToParameter(UrlBuilder.java:318) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.context.UrlBuilder.addParameters(UrlBuilder.java:127) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.context.ExternalContextImpl.encodeBookmarkableURL(ExternalContextImpl.java:1045) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.application.view.MultiViewHandler.getBookmarkableURL(MultiViewHandler.java:407) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
javax.faces.application.ViewHandlerWrapper.getBookmarkableURL(ViewHandlerWrapper.java:272) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
org.jboss.weld.jsf.ConversationAwareViewHandler.getBookmarkableURL(ConversationAwareViewHandler.java:132) [weld-core-jsf-2.1.2.Final.jar:2014-01-09 09:23] at 
javax.faces.application.ViewHandlerWrapper.getBookmarkableURL(ViewHandlerWrapper.java:272) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
com.sun.faces.renderkit.html_basic.OutcomeTargetRenderer.getEncodedTargetURL(OutcomeTargetRenderer.java:194) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.renderkit.html_basic.OutcomeTargetButtonRenderer.encodeBegin(OutcomeTargetButtonRenderer.java:98) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:864) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.render.Renderer.encodeChildren(Renderer.java:176) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1856) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at 
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at 
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] at 
java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] 10:17:53,845 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /architect/systems/groups.xhtml: javax.servlet.ServletException at 
javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at 
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at
 io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at 
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] at 
java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] Caused by: java.lang.NullPointerException at 
java.net.URLEncoder.encode(URLEncoder.java:205) [rt.jar:1.7.0_40] at 
com.sun.faces.context.UrlBuilder.addValuesToParameter(UrlBuilder.java:318) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.context.UrlBuilder.addParameters(UrlBuilder.java:127) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.context.ExternalContextImpl.encodeBookmarkableURL(ExternalContextImpl.java:1045) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.application.view.MultiViewHandler.getBookmarkableURL(MultiViewHandler.java:407) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
javax.faces.application.ViewHandlerWrapper.getBookmarkableURL(ViewHandlerWrapper.java:272) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
org.jboss.weld.jsf.ConversationAwareViewHandler.getBookmarkableURL(ConversationAwareViewHandler.java:132) [weld-core-jsf-2.1.2.Final.jar:2014-01-09 09:23] at 
javax.faces.application.ViewHandlerWrapper.getBookmarkableURL(ViewHandlerWrapper.java:272) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
com.sun.faces.renderkit.html_basic.OutcomeTargetRenderer.getEncodedTargetURL(OutcomeTargetRenderer.java:194) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.renderkit.html_basic.OutcomeTargetButtonRenderer.encodeBegin(OutcomeTargetButtonRenderer.java:98) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:864) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.render.Renderer.encodeChildren(Renderer.java:176) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1856) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] at 
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.5-jbossorg-3.jar:] at 
javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] ... 24 more

It doesn't happen in WildFly 8 CR1 neither in JBoss EAP 6.

More discussions about the issue can be found here: https://community.jboss.org/thread/237063



 Comments   
Comment by Manfred Riem [ 24/Feb/14 ]

Please provide us with a reproducer that does not contain any 3rd party libraries. Thanks!

Comment by Hildeberto Mendonça [ 19/Mar/14 ]

Apparently, I don't have rights to attach a file here. What I've noticed lately was that, considering the given example, if #

{groupMBean.selectedApplication}

is null the error occurs, but in a previous version it was ok to be null.

Comment by Manfred Riem [ 25/Mar/14 ]

Please see the associated issue for an explanation why this is not a bug.





[JAVASERVERFACES-2586] Composite component (CC): clientBehavior + EL with ui:param Created: 09/Nov/12  Updated: 12/Jun/13  Resolved: 12/Jun/13

Status: Closed
Project: javaserverfaces
Component/s: ajax, composite components, expression language, facelets
Affects Version/s: 2.1.13
Fix Version/s: 2.1.22

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

Attachments: Zip Archive CCAjaxTest.zip    
Issue Links:
Related
is related to JAVASERVERFACES-2838 f:ajax umbrella task Closed
is related to JAVASERVERFACES-2839 composite component umbrella task Closed
Tags: ajax, component, composite, facelets

 Description   

First, excuse my english writting. Hello everybody, the problem is when I use ui:param to create an EL expression in the render attribute an pass to my composite component like a clientBehavior, for example:

Page where I pass the reportBean param

page.xhtml
<ui:composition template="/WEB-INF/template/layouts/report-layout.xhtml">
  <ui:param name="reportBean" value="#{bean}" />

  <ui:define name="report-params">
    <ui:include src="/WEB-INF/template/partials/report-parameters.xhtml" />        
  </ui:define>
</ui:composition>

Page(facelets composition) being included in page.xhtml, we can see my composite component ups:person with f:ajax

report-parameters.xhtml
<h:form id="form-report-params" >
  ////////

  <ups:person id="report-param" value="#{reportBean.person}">
    <f:ajax event="change" render=":form-report-params:report-param-group #{reportBean.isGroupRendered()?':form-report-params:report-param-group':''}"
  </ups:person>
  
  ////////
</h:form>

Composite Component

person.xhtml
<composite:interface componentType="components.PersonComponent">
  <composite:attribute name="value" required="true" />
  <composite:clientBehavior name="change" event="action" targets="accept-button-hidden" />
</composite:interface>

<composite:implementation>
/////////
</composite:implementation>

The problem is in f:ajax, escifically in:

render=":form-report-params:report-param-class #{reportBean.isGroupRendered()?':form-report-params:report-param-group':''}"

the renderized code is: "render:report-param-class" ignoring the EL expression, this only happens with CC.

I'm trying to check the source code to find a solution, but I need your help to clarify this. bug or not?



 Comments   
Comment by Manfred Riem [ 09/Nov/12 ]

Can you please attach an example application (with sources) that demonstrates the problem?

Comment by Lynx6 [ 09/Nov/12 ]

My project is large to simplify it, but the next week on Monday I'll work with this. I guess my explaining is clear. Meanwhile, you can try to understand this code. Thanks.

Comment by Lynx6 [ 10/Nov/12 ]

I got a extra time, I hope you can help as soon as you can.

Run the project(Primefaces included but not affecting this test) with netbeans, my version is 7.1.1

First Test:
1) Click in the search button
2) Select a row and click OK
3) The first inputtext (average) is updated but the second one (total) not.

The event is assigned to 'accept-button-hidden', this button was created because PF has a problem (http://code.google.com/p/primefaces/issues/detail?id=4851).

Second Test:

Replace this:

report-parameters.xhtml
<f:ajax execute="@this" 
  event="change"
  render=":form-report-params:report-param-average 
  #{reportBean.isTotalRendered()?':form-report-params:report-param-total':''}" />

with this

report-parameters.xhtml
<f:ajax execute="@this" 
  event="change"
  render=":form-report-params:report-param-average :form-report-params:report-param-total" />

test again, 'average' and 'total' are updated.

In adition, I styled the 'average' and 'total' labels, red when is false and green when is true, both values are readed from TestBean

The problem is with f:ajax and CC.

Comment by Manfred Riem [ 22/Mar/13 ]

Can you attach an example application (with sources) that reproduces the problem with PrimeFaces in the mix? Thanks!

Comment by Lynx6 [ 22/Mar/13 ]

The file that is attached include PrimeFaces 3.4, but the problem is with f:ajax. Anyway I'm going to test again with the lastest version of both Mojarra and Primefaces...

Comment by Manfred Riem [ 22/Mar/13 ]

Please remove PrimeFaces out of the mix. This so we can make sure it is not adding something into the mix.

Comment by Lynx6 [ 22/Mar/13 ]

Hello Manfred, How I can attach the file?... I simplified this sample, now is easy to understand...

Comment by Manfred Riem [ 10/Apr/13 ]

Please send it to issues@javaserverfaces.java.net

Comment by Lynx6 [ 10/Apr/13 ]

yes, was sent... the sample is attached like "CCAjaxTest.zip", the subject is: "Example for JAVASERVERFACES-2720, JAVASERVERFACES-2586‏"

Comment by Lynx6 [ 13/May/13 ]

I've checked this issue today with 2.1.22 but I can't reproduce it again... Manfred, Can you confirm if some change was applied?

Comment by Manfred Riem [ 12/Jun/13 ]

Several fixes related to composite component have gone in since 2.1.13. I will mark this issue as fixed in 2.1.22. Thanks!





[JAVASERVERFACES-2347] No-args action listener can't be called if EL expression based on variable mapper Created: 17/Mar/12  Updated: 10/Jan/13  Resolved: 20/Mar/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.7
Fix Version/s: 2.1.8, 2.2.0-m02

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

Attachments: Text File 2347.patch     Zip Archive actionlistenertest.zip     Text File changebundle-2347.txt    
Issue Links:
Related
is related to JAVASERVERFACES-2681 Migrate JAVASERVERFACES-2347 to new t... Closed
Tags: el, expression, facelets

 Description   

When a no-args action listener is bound to e.g. a command button, it can't be called if the EL expression is dependent on a variable mapper in any Facelet context except the top level one (like includes and Facelet tags).

For instance, the following will fail:

top-level Facelet:

<h:form>
    <ui:include src="/include.xhtml" />
</h:form>

include.xhtml:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:h="http://java.sun.com/jsf/html">

    <ui:param name="test" value="#{actionListenerBean}" />

    <h:commandButton actionListener="#{test.listener}"
        value="invoke listener no param" />

</ui:composition>

actionListenerBean:

@ManagedBean
public class ActionListenerBean {
    public void listener() {	
    }
}

Clicking the button will throw the following exception:

 javax.el.PropertyNotFoundException: Target Unreachable, identifier 'test' resolved to null
	at org.apache.el.parser.AstValue.getTarget(AstValue.java:98)
	at org.apache.el.parser.AstValue.invoke(AstValue.java:244)
	at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278)
	at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:153)

If the method expression binds to a method with an ActionEvent attribute everything works as expected.

As it appears, the problem has its root in the way how MethodExpressionActionListener is implemented. It copies the given method expression into a version without the ActionEvent attribute as follows:

public MethodExpressionActionListener(MethodExpression methodExpressionOneArg) {

        super();
        this.methodExpressionOneArg = methodExpressionOneArg;
        FacesContext context = FacesContext.getCurrentInstance();
        ELContext elContext = context.getELContext();
        this.methodExpressionZeroArg = context.getApplication().
                getExpressionFactory().createMethodExpression(elContext, 
                  methodExpressionOneArg.getExpressionString(), Void.class, 
                  ACTION_LISTENER_ZEROARG_SIG);

    }

The copy is made based on the expression string and the EL Context obtained from the TLS FacesContext, but this EL Context can not resolve the expression string. Is doesn't have the variable mapper of the EL Context in which the original expression was created.

Attached is a simple application that reproduces the problem (included ant file builds the .war in /dist).



 Comments   
Comment by arjan tijms [ 19/Mar/12 ]

After looking into it some more, I think something like the following in ActionSourceRule might do the trick:

final static class ActionListenerMapper2 extends Metadata {

    private final TagAttribute attr;

    public ActionListenerMapper2(TagAttribute attr) {
        this.attr = attr;
    }

    public void applyMetadata(FaceletContext ctx, Object instance) {
        
        ExpressionFactory expressionFactory = ctx.getExpressionFactory();

        MethodExpression methodExpressionOneArg = attr.getMethodExpression(
            ctx, null, ActionSourceRule.ACTION_LISTENER_SIG);
        
        MethodExpression methodExpressionZeroArg = 
                expressionFactory.createMethodExpression(
                    ctx, methodExpressionOneArg.getExpressionString(), 
                    Void.class, ActionSourceRule.ACTION_LISTENER_ZEROARG_SIG);            
        
        ((ActionSource2) instance)
                .addActionListener(new MethodExpressionActionListener(
                        methodExpressionOneArg, methodExpressionZeroArg));

    }

}

Note that I haven't tested this yet, but will do so later today.

Comment by arjan tijms [ 19/Mar/12 ]

Patch for issue against Mojarra 2.2 trunk including test case

Comment by arjan tijms [ 19/Mar/12 ]

The proposed code indeed fixes the issue in my local test.

I ran the automated tests and no tests were failing because of this new change (a small handful of tests was already failing on my system before I applied the change, like scrumtesttoys).

Comment by rogerk [ 20/Mar/12 ]

Thanks for the patch.
Fixed some minor problems in test (xhtml pages).

Comment by rogerk [ 20/Mar/12 ]

Committed to MOJARRA_2_1X_ROLLING branch:
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ActionSourceRule.java
Adding jsf-test/JAVASERVERFACES-2347
Adding jsf-test/JAVASERVERFACES-2347/build.xml
Adding jsf-test/JAVASERVERFACES-2347/htmlunit
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com/sun/faces/systest/Issue2347TestCase.java
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/pom.xml
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/java
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/java/i_jsf_2347
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/java/i_jsf_2347/ActionListenerBean.java
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp/actionlistener.xhtml
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp/include.xhtml
Sending jsf-test/build.xml
Transmitting file data ..........
Committed revision 9770.

Comment by rogerk [ 20/Mar/12 ]

Committed to trunk:
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ActionSourceRule.java
Adding jsf-test/JAVASERVERFACES-2347
Adding jsf-test/JAVASERVERFACES-2347/build.xml
Adding jsf-test/JAVASERVERFACES-2347/htmlunit
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2347/htmlunit/src/main/java/com/sun/faces/systest/Issue2347TestCase.java
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/pom.xml
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/java
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/java/i_jsf_2347
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/java/i_jsf_2347/ActionListenerBean.java
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp/actionlistener.xhtml
Adding jsf-test/JAVASERVERFACES-2347/i_jsf_2347/src/main/webapp/include.xhtml
Sending jsf-test/build.xml
Transmitting file data ..........
Committed revision 9771.

Comment by rogerk [ 20/Mar/12 ]

Fix version

Comment by rogerk [ 20/Mar/12 ]

Committed.

Comment by rogerk [ 20/Mar/12 ]

fix version

Comment by rogerk [ 20/Mar/12 ]

fix version

Comment by rogerk [ 20/Mar/12 ]

fix version





[JAVASERVERFACES-2198] javax.el.MethodNotFoundException when method binding in nested composite components Created: 16/Sep/11  Updated: 08/May/13  Resolved: 08/May/13

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

Type: Bug Priority: Trivial
Reporter: tommy.a Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7.0
Mojarra 2.1.3
Windows7 64Bit


Attachments: File testWebApp.war    
Issue Links:
Related
is related to JAVASERVERFACES-2839 composite component umbrella task Closed
Tags: CC, EL, composite, facelets

 Description   

I get an javax.el.MethodNotFoundException when I use method binding in an element within a composite component that has a component type.
That element is passed as child to another composite component. The EL expression is evaluated there instead in the calling composite component.

Expected behaviour:
It is expected for me that any EL expressions with #

{cc.xxx}

should be evaluated within the current composite component even if they are passed as child to another component.

The exception is:
SCHWERWIEGEND: JSF1073: javax.faces.event.AbortProcessingException erfasst während Verarbeitung von INVOKE_APPLICATION 5 : UIComponent-ClientId=j_idt7:j_idt9:j_idt11:j_idt12, Message=Method not found: javax.faces.component.UINamingContainer@127208e4.myMethod()
16.09.2011 08:38:11 com.sun.faces.context.ExceptionHandlerImpl log
SCHWERWIEGEND: Method not found: javax.faces.component.UINamingContainer@127208e4.myMethod()
javax.faces.event.AbortProcessingException: Method not found: javax.faces.component.UINamingContainer@127208e4.myMethod()
at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:182)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.el.MethodNotFoundException: Method not found: javax.faces.component.UINamingContainer@127208e4.myMethod()
at org.apache.el.util.ReflectionUtil.getMethod(ReflectionUtil.java:225)
at org.apache.el.parser.AstValue.invoke(AstValue.java:253)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278)
at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:153)
... 25 more

Deploy attached WAR to tomcat 7.0 and call:
http://localhost:8080/testWebApp/index.xhtml
Press the button to reproduce (look at the logging).
There is also a short explanation on the index page.

index.xhtml:

<h:form>
<my:panelWithOwnButton/>
</h:form>

my:panelWithOwnButton:

<composite:interface componentType="panelWithOwnButton">
</composite:interface>
<composite:implementation>
<my:panelWithChildren>
<h:commandButton value="Hit me" actionListener="#

{cc.myMethod}

"/>
</my:panelWithChildren>
</composite:implementation>

PanelWithOwnButton.java:

@FacesComponent(value="panelWithOwnButton")
public class PanelWithOwnButton extends UIComponentBase implements NamingContainer {
public PanelWithOwnButton() {
}
@Override
public String getFamily()

{ return UINamingContainer.COMPONENT_FAMILY; }

public void myMethod()

{ System.out.println("This message should appear if method was called successfully!"); }

}

my:panelWithChildren:

<composite:interface>
</composite:interface>
<composite:implementation>
<composite:insertChildren></composite:insertChildren>
</composite:implementation>



 Comments   
Comment by tommy.a [ 16/Sep/11 ]

I found a workaround for this issue:

In panelWithOwnButton.xhtml use c:set with scope="request" for the current component:

<composite:implementation>
<c:set var="myMethodBinding" scope="request" value="#

{cc}

"></c:set>

<my:panelWithChildren>
<h:commandButton value="Hit me" actionListener="#

{myMethodBinding.myMethod}

">
</h:commandButton>
</my:panelWithChildren>
</composite:implementation>

Comment by tommy.a [ 21/Sep/11 ]

I changed my implementation to use composite:actionSource which works well.
Nevertheless I had problems passing any attributes (types String/int) from the outer component to the inner component if they have the same attribute name.
I solved that by using component binding on the nested component and set any attributes within my java bean instead of the xhtml file.

Comment by Ed Burns [ 24/Jan/12 ]

Because a workaround exists, downgrading to minor.

Comment by Manfred Riem [ 06/Mar/13 ]

Can you verify if this is still an issue on the latest 2.1 release?

Comment by Manfred Riem [ 03/Apr/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 08/May/13 ]

Closing because of inactivity





[ADFEMG-108] ADF Show Printable Page Behavior Tag doesn't show printable page in a new window. Created: 19/Feb/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Closed
Project: adfemg
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

JDEveloper 11.1.2.3, Windows - tested and reproduces with IE 8, IE 7, Firefox 3.6.6.
Works like expexted with current versions of Chrome (24.0.1312.57 m) and Firefox (10.0.12)


Tags: ADF, Facelets, JDeveloper, R2, show_printable_page_behavior

 Description   

ADF Show Printable Page Behavior Tag doesn't show printable page in a new window.
The page rendered in a new window (or tab) shows a default layout insted of printable one.

Only the second click on a button in a
new window renders printable page layout in it.

Steps to reproduce:

1. Open a sample Workspace attached
2. Run home.jsf in JDeveloper
3. Click on a button print
4a. Doesn't work like expected in IE 8, IE 7, Firefox 3.6.6. -> the same page is displaed in a new window. The button Print is still visible.
4b. Works like expected in Chrome (24.0.1312.57 m) and Firefox (10.0.12) -> printable page is displayed in a new window. The button Print is not visible.



 Comments   
Comment by donatas [ 19/Feb/13 ]

JDeveloper workspace to reproduce this issue:
https://github.com/donatasnicequestion/Blog-on-Software-and-Beyond-it-/raw/master/samples/adf/TestFaceletsTemplates.zip

Comment by chriscmuir [ 20/Feb/13 ]

Hi Donatas

Thanks for logging the issue. Is there a known bug or SR on this issue?

CM.

Comment by donatas [ 22/Feb/13 ]

Hi Chris,

Update after further investigation:

the issue is already resolved by the Patch Nr. 13863292
available at My Oracle Support.

This one-off patch 13863292 PRINTABLE BEHAVIOR IN IE 9 CAUSES INFINITE JS REDIRECT LOOP
also resolves (like the name states) a similar issue in IE9.

Regards, Donatas

Comment by chriscmuir [ 24/Feb/13 ]

Thanks for the update Donatas.

Given a patch is available I believe this issue can be closed. Can you close if you agree please.

CM.

Comment by chriscmuir [ 27/Mar/13 ]

No reply from Donatas. Closing on his behalf.





Generated at Thu Sep 03 03:07:25 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.