[JBoss JIRA] (RF-12832) Tomcat 6 test Deployments should define the expressionFactory
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12832?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12832:
---------------------------------
We can simply fix this in M!.
> Tomcat 6 test Deployments should define the expressionFactory
> -------------------------------------------------------------
>
> Key: RF-12832
> URL: https://issues.jboss.org/browse/RF-12832
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Reporter: Brian Leathem
> Assignee: Lukáš Fryč
> Fix For: 5.0.0.M1
>
>
> JBoss EL is added as a dependency for tomcat deployments, however the expressionFactory needs to be configured to use the bundled EL implementation.
> Without the configuration below, tests that use advanced EL features will fail on Tomcat.
> For Mojarra implementations, the web.xml of the Deployment should contain:
> {code}
> <context-param>
> <param-name>com.sun.faces.expressionFactory</param-name>
> <param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
> </context-param>
> {code}
> And MyFaces implementations, the web.xml of the Deployment should contain:
> {code}
> <context-param>
> <param-name>org.apache.myfaces.EXPRESSION_FACTORY</param-name>
> <param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
> </context-param>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12832) Tomcat 6 test Deployments should define the expressionFactory
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12832?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-12832:
----------------------------
Fix Version/s: 5.0.0.M1
> Tomcat 6 test Deployments should define the expressionFactory
> -------------------------------------------------------------
>
> Key: RF-12832
> URL: https://issues.jboss.org/browse/RF-12832
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Reporter: Brian Leathem
> Assignee: Lukáš Fryč
> Fix For: 5.0.0.M1
>
>
> JBoss EL is added as a dependency for tomcat deployments, however the expressionFactory needs to be configured to use the bundled EL implementation.
> Without the configuration below, tests that use advanced EL features will fail on Tomcat.
> For Mojarra implementations, the web.xml of the Deployment should contain:
> {code}
> <context-param>
> <param-name>com.sun.faces.expressionFactory</param-name>
> <param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
> </context-param>
> {code}
> And MyFaces implementations, the web.xml of the Deployment should contain:
> {code}
> <context-param>
> <param-name>org.apache.myfaces.EXPRESSION_FACTORY</param-name>
> <param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
> </context-param>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12833) richfaces.js conflicts with prototype.js
by Mark Torres (JIRA)
Mark Torres created RF-12833:
--------------------------------
Summary: richfaces.js conflicts with prototype.js
Key: RF-12833
URL: https://issues.jboss.org/browse/RF-12833
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.3.1
Reporter: Mark Torres
Getting some javascript errors on richfaces.js.
Upon inspection, it is using
(function(jQuery, richfaces) {
...
instead of
(function($, richfaces) {
...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12832) Tomcat 6 test Deployments should define the expressionFactory
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12832?page=com.atlassian.jira.plugin.s... ]
Brian Leathem reassigned RF-12832:
----------------------------------
Assignee: Lukáš Fryč
Lukas, please assess and schedule accordingly
> Tomcat 6 test Deployments should define the expressionFactory
> -------------------------------------------------------------
>
> Key: RF-12832
> URL: https://issues.jboss.org/browse/RF-12832
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Reporter: Brian Leathem
> Assignee: Lukáš Fryč
>
> JBoss EL is added as a dependency for tomcat deployments, however the expressionFactory needs to be configured to use the bundled EL implementation.
> Without the configuration below, tests that use advanced EL features will fail on Tomcat.
> For Mojarra implementations, the web.xml of the Deployment should contain:
> {code}
> <context-param>
> <param-name>com.sun.faces.expressionFactory</param-name>
> <param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
> </context-param>
> {code}
> And MyFaces implementations, the web.xml of the Deployment should contain:
> {code}
> <context-param>
> <param-name>org.apache.myfaces.EXPRESSION_FACTORY</param-name>
> <param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
> </context-param>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12832) Tomcat 6 test Deployments should define the expressionFactory
by Brian Leathem (JIRA)
Brian Leathem created RF-12832:
----------------------------------
Summary: Tomcat 6 test Deployments should define the expressionFactory
Key: RF-12832
URL: https://issues.jboss.org/browse/RF-12832
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: tests - functional
Reporter: Brian Leathem
JBoss EL is added as a dependency for tomcat deployments, however the expressionFactory needs to be configured to use the bundled EL implementation.
Without the configuration below, tests that use advanced EL features will fail on Tomcat.
For Mojarra implementations, the web.xml of the Deployment should contain:
{code}
<context-param>
<param-name>com.sun.faces.expressionFactory</param-name>
<param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
</context-param>
{code}
And MyFaces implementations, the web.xml of the Deployment should contain:
{code}
<context-param>
<param-name>org.apache.myfaces.EXPRESSION_FACTORY</param-name>
<param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
</context-param>
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12512) Repeat: input inside repeat in not updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12512?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-12512.
--------------------------------
Assignee: Brian Leathem
Fix Version/s: (was: 4.3.2)
Resolution: Rejected
This turns out then to be entirely an upstream issue: JAVASERVERFACES-2578. Resolving would require a patch to the Mojarra 2.1.13 impl bundled with EAP.
> Repeat: input inside repeat in not updated
> ------------------------------------------
>
> Key: RF-12512
> URL: https://issues.jboss.org/browse/RF-12512
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core, regression
> Affects Versions: 4.2.3.Final, 4.3.0.M2
> Environment: RichFaces 4.3.0-SNAPSHOT
> Metamer 4.3.0-SNAPSHOT
> Mojarra 2.1.7
> JBoss AS 7.1.2.Final-redhat-1
> Java(TM) SE Runtime Environment 1.6.0_32-b05 @ Linux
> Chrome 22.0.1229.79 @ Linux x86_64
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Attachments: repeat.png
>
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/a4jRepeat/matrix.xhtml
> # click the top-left "+" link
> # click the top-left "C" link
> result:
> * output below is reset but input's value not
> * worked fine in all previous versions
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12512) Repeat: input inside repeat in not updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12512?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-12512 at 3/8/13 3:05 PM:
------------------------------------------------------------
This in fact has nothing to do with _<a4j:repeat>_ nor any RichFaces component for that matter. I was able to reproduce the behaviour with the following "plain old" JSF:
{code}
<h:form id='myForm'>
<h:inputText id='input' value='#{ajaxBean.value}'/>
<h:commandButton id='submit' value = 'Submit Input'>
<f:ajax execute='input' render='input' />
</h:commandButton>
<h:commandButton id='clear' value = 'Clear Input'>
<f:ajax listener='#{ajaxBean.clearValue}' render='input' />
</h:commandButton>
</h:form>
{code}
was (Author: bleathem):
This in fact has nothing to do with _<a4j:repeat>_ nor any RichFaces component for that matter. I was able to reproduce the behaviour with the following "plain old" JSF:
{code}
<h:form id='myForm'> ");
<h:inputText id='input' value='#{ajaxBean.value}'/> ");
<h:commandButton id='submit' value = 'Submit Input'> ");
<f:ajax execute='input' render='input' /> ");
</h:commandButton> ");
<h:commandButton id='clear' value = 'Clear Input'> ");
<f:ajax listener='#{ajaxBean.clearValue}' render='input' /> ");
</h:commandButton> ");
</h:form>
{code}
> Repeat: input inside repeat in not updated
> ------------------------------------------
>
> Key: RF-12512
> URL: https://issues.jboss.org/browse/RF-12512
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core, regression
> Affects Versions: 4.2.3.Final, 4.3.0.M2
> Environment: RichFaces 4.3.0-SNAPSHOT
> Metamer 4.3.0-SNAPSHOT
> Mojarra 2.1.7
> JBoss AS 7.1.2.Final-redhat-1
> Java(TM) SE Runtime Environment 1.6.0_32-b05 @ Linux
> Chrome 22.0.1229.79 @ Linux x86_64
> Reporter: Pavol Pitonak
> Fix For: 4.3.2
>
> Attachments: repeat.png
>
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/a4jRepeat/matrix.xhtml
> # click the top-left "+" link
> # click the top-left "C" link
> result:
> * output below is reset but input's value not
> * worked fine in all previous versions
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12512) Repeat: input inside repeat in not updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12512?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12512:
------------------------------------
This in fact has nothing to do with _<a4j:repeat>_ nor any RichFaces component for that matter. I was able to reproduce the behaviour with the following "plain old" JSF:
{code}
<h:form id='myForm'> ");
<h:inputText id='input' value='#{ajaxBean.value}'/> ");
<h:commandButton id='submit' value = 'Submit Input'> ");
<f:ajax execute='input' render='input' /> ");
</h:commandButton> ");
<h:commandButton id='clear' value = 'Clear Input'> ");
<f:ajax listener='#{ajaxBean.clearValue}' render='input' /> ");
</h:commandButton> ");
</h:form>
{code}
> Repeat: input inside repeat in not updated
> ------------------------------------------
>
> Key: RF-12512
> URL: https://issues.jboss.org/browse/RF-12512
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core, regression
> Affects Versions: 4.2.3.Final, 4.3.0.M2
> Environment: RichFaces 4.3.0-SNAPSHOT
> Metamer 4.3.0-SNAPSHOT
> Mojarra 2.1.7
> JBoss AS 7.1.2.Final-redhat-1
> Java(TM) SE Runtime Environment 1.6.0_32-b05 @ Linux
> Chrome 22.0.1229.79 @ Linux x86_64
> Reporter: Pavol Pitonak
> Fix For: 4.3.2
>
> Attachments: repeat.png
>
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/a4jRepeat/matrix.xhtml
> # click the top-left "+" link
> # click the top-left "C" link
> result:
> * output below is reset but input's value not
> * worked fine in all previous versions
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12512) Repeat: input inside repeat in not updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12512?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12512:
------------------------------------
I wrote a _fundamental_ test to reproduce this behaviour. I can confirm:
# it worked in Mojarra 2.1.7 (shipped with AS 7.1.1.Final)
# it starts failing in Mojarra 2.1.8
# starts working again in Mojarra 2.1.15
I'll next use the _fundamental_ test to investigate if there is something we can do to workaround this issue.
> Repeat: input inside repeat in not updated
> ------------------------------------------
>
> Key: RF-12512
> URL: https://issues.jboss.org/browse/RF-12512
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core, regression
> Affects Versions: 4.2.3.Final, 4.3.0.M2
> Environment: RichFaces 4.3.0-SNAPSHOT
> Metamer 4.3.0-SNAPSHOT
> Mojarra 2.1.7
> JBoss AS 7.1.2.Final-redhat-1
> Java(TM) SE Runtime Environment 1.6.0_32-b05 @ Linux
> Chrome 22.0.1229.79 @ Linux x86_64
> Reporter: Pavol Pitonak
> Fix For: 4.3.2
>
> Attachments: repeat.png
>
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/a4jRepeat/matrix.xhtml
> # click the top-left "+" link
> # click the top-left "C" link
> result:
> * output below is reset but input's value not
> * worked fine in all previous versions
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (RF-12831) <rich:validator/> performs ajax validation without updating underlying model field
by Kamil Roman (JIRA)
[ https://issues.jboss.org/browse/RF-12831?page=com.atlassian.jira.plugin.s... ]
Kamil Roman updated RF-12831:
-----------------------------
Description:
Not sure if it's a bug or a feature, but field annotated with {code}<rich:validator/>{code} with a validation method set with {code}validator{code} attribute gets validated without updating the underlying model field. My code is something like this:
{code:title=Model.java}
public class Model {
//...
public Date getValidFrom() {/*...*/}
public Date getValidTo() {/*...*/}
}
{code}
{code:title=ModelValidator.java}
public class ModelValidator{
private Model model;
public boolean isValidToAfterValidFrom() {
return model.getValidTo().after(model.getValidFrom());
}
}
{code}
{code:title=model_form.xml}
<c:set var="model" value="#{ModelBean.model}"/>
<h:outputLabel value="#{labels.getLabel('valid_from')}" for="validFrom" />
<rich:calendar value="#{model.validFrom}" id="validFrom" >
<rich:validator/>
</rich:calendar>
<rich:message for="validFrom"/>
<h:outputLabel value="#{labels.getLabel('valid_to')}" for="validTo" />
<rich:calendar value="#{model.validTo}" id="validTo" validator="#{modelBean.validateValidTo}">
<rich:validator event="inputblur"/>
</rich:calendar>
<rich:message for="validTo"/>
{code}
{code:title=ModelBean.java}
public class ModelBean {
public Model getModel() {/*..*/}
private ModelValidator validator;
//...
public validateValidTo(FacesContext context, UIComponent toValidate, Object value) {
if(!validator.isValidToAfterValidFrom()) {
FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_ERROR, labelBean.getLabel("valid.to.not.after.valid.from.error"), null);
throw new ValidatorException(message);
}
}
{code}
The getModel() method returns the same Model instance as is used by the ModelValidator in ModelBean.
Now, the testcase is:
1. User selects validTo earlier than ValidFrom (on a valid Model instance)
2. Validation passes as the underlying model value is not updated (validator refers to the same Model instance as ModelBean)
3. User submits the form.
4. System displays error message as server-side validation on submit is performed after applying request values.
5. User corrects the value in validTo field.
6. System still displays error message as validation fails, because the new value is not applied to the model (model holds the invalid value applied during failed submit).
If this is not a bug, but a feature, it would be great if you included this behaviour in the docs!
was:
Not sure if it's a bug or a feature, but field annotated with {code}<rich:validator/>{code} with a validation method set with {code}validator{code} attribute gets validated without updating the underlying model field. My code is something like this:
{code:title=Model.java}
public class Model {
//...
public Date getValidFrom() {/*...*/}
public Date getValidTo() {/*...*/}
}
{code}
{code:title=ModelValidator.java}
public class ModelValidator{
private Model model;
public boolean isValidToAfterValidFrom() {
return model.getValidTo().after(model.getValidFrom());
}
}
{code}
{code:title=model_form.xml}
<c:set var="model" value="#{ModelBean.model}"/>
<h:outputLabel value="#{labels.getLabel('valid_from')}" for="validFrom" />
<rich:calendar value="#{model.validFrom}" id="validFrom" >
<rich:validator/>
</rich:calendar>
<rich:message for="validFrom"/>
<h:outputLabel value="#{labels.getLabel('valid_to')}" for="validTo" />
<rich:calendar value="#{model.validTo}" id="validTo" validator="#{modelBean.validateValidTo}">
<rich:validator event="inputblur"/>
</rich:calendar>
<rich:message for="validTo"/>
{code}
{code:title=ModelBean.java}
public class ModelBean {
public Model getModel() {/*..*/}
private ModelValidator validator;
//...
public validateValidTo(FacesContext context, UIComponent toValidate, Object value) {
if(!validator.isValidToAfterValidFrom()) {
FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_ERROR, labelBean.getLabel("valid.to.not.after.valid.from.error"), null);
throw new ValidatorException(message);
}
{code}
The getModel() method returns the same Model instance as is used by the ModelValidator in ModelBean.
Now, the testcase is:
1. User selects validTo earlier than ValidFrom (on a valid Model instance)
2. Validation passes as the underlying model value is not updated (validator refers to the same Model instance as ModelBean)
3. User submits the form.
4. System displays error message as server-side validation on submit is performed after applying request values.
5. User corrects the value in validTo field.
6. System still displays error message as validation fails, because the new value is not applied to the model (model holds the invalid value applied during failed submit).
If this is not a bug, but a feature, it would be great if you included this behaviour in the docs!
> <rich:validator/> performs ajax validation without updating underlying model field
> ----------------------------------------------------------------------------------
>
> Key: RF-12831
> URL: https://issues.jboss.org/browse/RF-12831
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.0.Final
> Environment: JBoss eap 6.0.0, Win 7
> Reporter: Kamil Roman
> Priority: Minor
>
> Not sure if it's a bug or a feature, but field annotated with {code}<rich:validator/>{code} with a validation method set with {code}validator{code} attribute gets validated without updating the underlying model field. My code is something like this:
> {code:title=Model.java}
> public class Model {
> //...
> public Date getValidFrom() {/*...*/}
> public Date getValidTo() {/*...*/}
> }
> {code}
> {code:title=ModelValidator.java}
> public class ModelValidator{
> private Model model;
> public boolean isValidToAfterValidFrom() {
> return model.getValidTo().after(model.getValidFrom());
> }
> }
> {code}
> {code:title=model_form.xml}
> <c:set var="model" value="#{ModelBean.model}"/>
> <h:outputLabel value="#{labels.getLabel('valid_from')}" for="validFrom" />
> <rich:calendar value="#{model.validFrom}" id="validFrom" >
> <rich:validator/>
> </rich:calendar>
> <rich:message for="validFrom"/>
>
> <h:outputLabel value="#{labels.getLabel('valid_to')}" for="validTo" />
> <rich:calendar value="#{model.validTo}" id="validTo" validator="#{modelBean.validateValidTo}">
> <rich:validator event="inputblur"/>
> </rich:calendar>
> <rich:message for="validTo"/>
> {code}
> {code:title=ModelBean.java}
> public class ModelBean {
> public Model getModel() {/*..*/}
> private ModelValidator validator;
> //...
> public validateValidTo(FacesContext context, UIComponent toValidate, Object value) {
> if(!validator.isValidToAfterValidFrom()) {
> FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_ERROR, labelBean.getLabel("valid.to.not.after.valid.from.error"), null);
> throw new ValidatorException(message);
> }
> }
> {code}
> The getModel() method returns the same Model instance as is used by the ModelValidator in ModelBean.
> Now, the testcase is:
> 1. User selects validTo earlier than ValidFrom (on a valid Model instance)
> 2. Validation passes as the underlying model value is not updated (validator refers to the same Model instance as ModelBean)
> 3. User submits the form.
> 4. System displays error message as server-side validation on submit is performed after applying request values.
> 5. User corrects the value in validTo field.
> 6. System still displays error message as validation fails, because the new value is not applied to the model (model holds the invalid value applied during failed submit).
> If this is not a bug, but a feature, it would be great if you included this behaviour in the docs!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months