[jira] [Created] (MYFACES-3911) Can't execute a second form from another form
Rene O created MYFACES-3911:
---
Summary: Can't execute a second form from another form
Key: MYFACES-3911
URL: https://issues.apache.org/jira/browse/MYFACES-3911
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.4
Environment: java 7, tomcat 7
Reporter: Rene O
Priority: Blocker
I have 2 forms within a site. I try to execute form B from form A, but it
doesn't work.
{code}
?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;
xmlns:h=http://xmlns.jcp.org/jsf/html;
xmlns:ui=http://xmlns.jcp.org/jsf/facelets;
xmlns:p=http://xmlns.jcp.org/jsf/passthrough;
xmlns:jsf=http://xmlns.jcp.org/jsf;
h:head/h:head
h:body
h:panelGroup id=pagePanel
1. type a character into input-field
br/
2. click button 'Button B'
br/
3. input-field validates and a message appears, which
is the expected behaviour
br/
4. change the character within input-field
br/
5. click 'Button A'
br/
6. now no validation takes place and no message
appears, which is not the expected behaviour
br/
--- formB is not executed, if you submit the page via
ajax from formA
br/
--- you can also see, that no value is submitted if you
insert a valid input in this case
br/
br/
h:messages /
h:form id=formA
h:commandButton value=Button A
f:ajax execute=pagePanel
event=click render=pagePanel /
/h:commandButton
/h:form
br/
br/
h:form id=formB
Input:
h:inputText id=inputA value=#{model.value}
required=true
f:validateLength minimum=5/
/h:inputText
br/
br/
h:commandButton value=Button B
f:ajax execute=pagePanel
event=click render=pagePanel /
/h:commandButton
br/
br/
Submitted input value: #{model.value}
/h:form
/h:panelGroup
/h:body
/html
{code}
A testcase is attached.
Open URL
{code}
http://localhost:8080/jsftest22/mypage.jsf
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3903) Allow custom validation message per validator
Rene O created MYFACES-3903:
---
Summary: Allow custom validation message per validator
Key: MYFACES-3903
URL: https://issues.apache.org/jira/browse/MYFACES-3903
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 2.2.3
Environment: myfaces 2.2.3, java 7, tomcat 7
Reporter: Rene O
At the moment only this is possible:
{code}
h:inputText value=#{myBean.value} validationMessage=My validation message
f:validateLength minimum=1 maximum=30/
f:validateRegex pattern=^\d{5}$ /
/h:inputText
{code}
You can't define a validation message per validation event, but only one
message for all validations.
As a workaround you can write a custom validator, which contains all
validations rules, and then throw ValidatorExceptions containing your desired
messages.
I think, that this limits the usablity.
It should be possible to do the following without writing a custom validator
{code}
h:inputText id=myFieldA value=#{myBean.value}
f:validateLength minimum=1 maximum=5 validationMessage=My custom
validation message for validateLength/
f:validateRegex pattern=^\d{5}$ validationMessage=My custom
validation message for validateRegex/
/h:inputText
h:inputText id=myFieldB value=#{myBean.value}
f:validateLength minimum=1 maximum=5 validationMessage=Another
custom validation message for validateLength/
f:validateRegex pattern=^\d{5}$ validationMessage=Another custom
validation message for validateRegex/
/h:inputText
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3901) f:selectItems ignore itemDescription within h:selectOneListbox
Rene O created MYFACES-3901:
---
Summary: f:selectItems ignore itemDescription within
h:selectOneListbox
Key: MYFACES-3901
URL: https://issues.apache.org/jira/browse/MYFACES-3901
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.3
Environment: java 7, tomcat 7
Reporter: Rene O
Priority: Minor
I have a h:selectOneListbox with underlying List:
{code}
ListSelectItem mylist = new ArrayListSelectItem();
mylist.add(new SelectItem(testvalue, testlabel,testdescription));
{code}
I want to show a tooltip over any option of a selectbox.
Therefore I tried two options:
1.
{code}
h:selectOneListbox value=#{bean.myvalue} ...
f:selectItems value=#{bean.mylist} var=item
itemValue=#{item.value} itemLabel=#{item.label}
itemDescription=yyy#{item.label}/
/h:selectOneListbox
{code}
2.
{code}
h:selectOneListbox value=#{bean.myvalue} ...
f:selectItems value=#{bean.mylist} var=item
itemValue=#{item.value} itemLabel=#{item.label}
passtrough:title=yyy#{item.label}/
/h:selectOneListbox
{code}
Option 1 ignores itemDescription. Only label and value are rendered.
Option 2 renders title attribute, but fills title only with yyy and ignores
value of #{item.label}
I think, that this behaviour is a bug.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3901) f:selectItems ignore itemDescription within h:selectOneListbox
[
https://issues.apache.org/jira/browse/MYFACES-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033605#comment-14033605
]
Rene O commented on MYFACES-3901:
-
2.2.4-SNAPSHOT has the same behaviour. Static content is rendered, but dynamic
one not.:
{code}
f:selectItems value=#{bean.mylist} var=item itemValue=#{item.value}
itemLabel=#{item.label} passtrough:title=yyy#{item.label}/
{code}
renders only:
{code}
option title=yyy value=testvaluetestlabel/option
{code}
but not expected:
{code}
option title=yyytestlabel value=testvaluetestlabel/option
{code}
f:selectItems ignore itemDescription within h:selectOneListbox
--
Key: MYFACES-3901
URL: https://issues.apache.org/jira/browse/MYFACES-3901
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.3
Environment: java 7, tomcat 7
Reporter: Rene O
Priority: Minor
I have a h:selectOneListbox with underlying List:
{code}
ListSelectItem mylist = new ArrayListSelectItem();
mylist.add(new SelectItem(testvalue, testlabel,testdescription));
{code}
I want to show a tooltip over any option of a selectbox.
Therefore I tried two options:
1.
{code}
h:selectOneListbox value=#{bean.myvalue} ...
f:selectItems value=#{bean.mylist} var=item
itemValue=#{item.value} itemLabel=#{item.label}
itemDescription=yyy#{item.label}/
/h:selectOneListbox
{code}
2.
{code}
h:selectOneListbox value=#{bean.myvalue} ...
f:selectItems value=#{bean.mylist} var=item
itemValue=#{item.value} itemLabel=#{item.label}
passtrough:title=yyy#{item.label}/
/h:selectOneListbox
{code}
Option 1 ignores itemDescription. Only label and value are rendered.
Option 2 renders title attribute, but fills title only with yyy and ignores
value of #{item.label}
I think, that this behaviour is a bug.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3892) Create a option to execute BeanValidation before JSF-Validation
[
https://issues.apache.org/jira/browse/MYFACES-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999644#comment-13999644
]
Rene O commented on MYFACES-3892:
-
Your solution works, but generally mixing of Bean-Validation and JSF-Validation
leads to another problem:
{code}
h:inputText id=myfield value=#{myBean.myField}
f:validateBean /
f:validateRegex pattern=[A-Z] /
/h:inputText
h:message for=myfield /
{code}
{code}
MyBean {
@NotNull
@Size(min=6,max=10)
String myField;
...
}
{code}
= user input: 1234
If beanvalidation fails and the regex fails, then there occurs a warning from
the regexvalidator, because messagefield is already used by
beanvalidationmessage:
GUI:
{noformat}
muss zwischen 6 und 10 liegen
{noformat}
Log:
{noformat}
Warnung: There are some unhandled FacesMessages, this means not every
FacesMessage had a chance to be rendered.
These unhandled FacesMessages are:
- myField: Der eingegebene Wert ([A-Z]) ist nicht korrekt.
{noformat}
Can I prevent this warning?
Create a option to execute BeanValidation before JSF-Validation
---
Key: MYFACES-3892
URL: https://issues.apache.org/jira/browse/MYFACES-3892
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 2.2.3
Reporter: Rene O
As stated in this answer: http://stackoverflow.com/a/19835645 BeanValidation
is executed after JSF-Validation.
But it would be very useful to have a way to change this behaviour.
Now you can't decide within jsf-validator wether a component is valid or not
in terms of BeanValidation
{code}
//My JSF-Validator
//...
UIInput input = (UIInput) component;
if (!input.isValid()) {
return;
}
//...my own jsf-validation rules...
//...
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3892) Create a option to execute BeanValidation before JSF-Validation
[
https://issues.apache.org/jira/browse/MYFACES-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998672#comment-13998672
]
Rene O commented on MYFACES-3892:
-
A workaround is to call BeanValidation manually within JSF-Validator before
JSF-validation is done:
{code:title=MyJsfValidatorClass.java}
//...
public void validateMyData(FacesContext context, UIComponent component, Object
value) throws ValidatorException {
//call beanvalidation manually
SetConstraintViolationMyDataModel violationsSet =
validator.validateValue(MyDataModel.class, myFieldName, value, Default.class);
//if beanvalidation error exists do not validate my own jsf-validation
rules
if(!violationsSet.isEmpty()){
return;
}
//...my own jsf-validation rules...
//...throw new ValidatorException(new FacesMessage(validation
error,null));
}
{code}
Create a option to execute BeanValidation before JSF-Validation
---
Key: MYFACES-3892
URL: https://issues.apache.org/jira/browse/MYFACES-3892
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 2.2.3
Reporter: Rene O
As stated in this answer: http://stackoverflow.com/a/19835645 BeanValidation
is executed after JSF-Validation.
But it would be very useful to have a way to change this behaviour.
Now you can't decide within jsf-validator wether a component is valid or not
in terms of BeanValidation
{code}
//My JSF-Validator
//...
UIInput input = (UIInput) component;
if (!input.isValid()) {
return;
}
//...my own jsf-validation rules...
//...
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3892) Create a option to execute BeanValidation before JSF-Validation
Rene O created MYFACES-3892:
---
Summary: Create a option to execute BeanValidation before
JSF-Validation
Key: MYFACES-3892
URL: https://issues.apache.org/jira/browse/MYFACES-3892
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 2.2.3
Reporter: Rene O
As stated in this answer: http://stackoverflow.com/a/19835645 BeanValidation is
executed after JSF-Validation.
But it would be very useful to have a way to change this behaviour.
Now you can't decide within jsf-validator wether a component is valid or not in
terms of BeanValidation
{code}
//My JSF-Validator
//...
UIInput input = (UIInput) component;
if (!input.isValid()) {
return;
}
//...my own jsf-validation rules...
//...
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3881) CLIENT_WINDOW_MODE generates new windowid even if one exists
[ https://issues.apache.org/jira/browse/MYFACES-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969440#comment-13969440 ] Rene O commented on MYFACES-3881: - Using Deltaspikes LAZY mode works if you use @ViewAccessScoped beans. But then there is another problem: see DELTASPIKE-573 for more informations. And I think it is a good idea to implement a url-redirect mode within myfaces to be independent of 3rd party libraries. CLIENT_WINDOW_MODE generates new windowid even if one exists Key: MYFACES-3881 URL: https://issues.apache.org/jira/browse/MYFACES-3881 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.2 Environment: java 7, tomcat 7.0.50 Reporter: Rene O Attachments: jsftest22.zip, jsftest22_new.zip If you use @ViewScoped beans and activate CLIENT_WINDOW_MODE (url or client) a page refresh generates a new windowid although the application in the current browser window already has a windowid. I think a new windowid should only be generated, if no windowid exists, e.g. open new window or tab with the same url. context-param param-namejavax.faces.CLIENT_WINDOW_MODE/param-name param-valueurl/param-value !--client doesn't work too-- /context-param A testcase is attached. call url: http://localhost:8080/jsftest22/mypage.jsf Fill some values into field Press F5 to refresh the page = new windowid is generated = inputdata is lost, because a new @ViewScoped bean was created -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3881) CLIENT_WINDOW_MODE generates new windowid even if one exists
[
https://issues.apache.org/jira/browse/MYFACES-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968186#comment-13968186
]
Rene O commented on MYFACES-3881:
-
I have found a workaround for my current usecase:
My idea is similar to client mode (javax.faces.CLIENT_WINDOW_MODE - client),
but doesn't use requestparam 'mfRid'.
Implementation:
- using of deltaspikes @WindowScoped for my beans (@ViewScoped doesn't work
here)
- using of special viewAction
{code:title=web.xml}
context-param
param-namejavax.faces.CLIENT_WINDOW_MODE/param-name
param-valueurl/param-value
/context-param
{code}
{code:title=mypage.xhtml}
f:metadata
f:viewAction action=#{initCtr.initApplication()}/
/f:metadata
{code}
{code:title=InitCtr.java}
public void initApplication(){
FacesContext ctx = FacesContext.getCurrentInstance();
ExternalContext exCtx = ctx.getExternalContext();
String windowid = exCtx.getClientWindow().getId();
System.out.println(windowid: +windowid);
//get current requestparams
MapString,String reqparams = exCtx.getRequestParameterMap();
//only redirect if no jfwid exists yet or an old unknown jfwid
is used within the browser
if(!reqparams.containsKey(jfwid) ||
!windowid.equals(reqparams.get(jfwid))){
try {
StringBuilder sb = new StringBuilder();
sb.append(?);
//append all requestparams
for (Map.EntryString,String entry :
reqparams.entrySet()) {
sb.append(entry.getKey()).append(=).append(entry.getValue()).append();
}
//append jfwid to be able to decide if a new
'windowsession' is needed or not
sb.append(jfwid=).append(exCtx.getClientWindow().getId());
//redirect to same page with new added jfwid
param
exCtx.redirect(exCtx.getRequestContextPath()+exCtx.getRequestServletPath()+sb.toString());
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
{code}
A new showcase (jsftest22_new.zip) is attached:
http://localhost:8080/jsftest22/mypage.jsf
CLIENT_WINDOW_MODE generates new windowid even if one exists
Key: MYFACES-3881
URL: https://issues.apache.org/jira/browse/MYFACES-3881
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.2
Environment: java 7, tomcat 7.0.50
Reporter: Rene O
Attachments: jsftest22.zip, jsftest22_new.zip
If you use @ViewScoped beans and activate CLIENT_WINDOW_MODE (url or client)
a page refresh generates a new windowid although the application in the
current browser window already has a windowid.
I think a new windowid should only be generated, if no windowid exists, e.g.
open new window or tab with the same url.
context-param
param-namejavax.faces.CLIENT_WINDOW_MODE/param-name
param-valueurl/param-value
!--client doesn't work too--
/context-param
A testcase is attached.
call url: http://localhost:8080/jsftest22/mypage.jsf
Fill some values into field
Press F5 to refresh the page
= new windowid is generated = inputdata is lost, because a new @ViewScoped
bean was created
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3881) CLIENT_WINDOW_MODE generates new windowid even if one exists
Rene O created MYFACES-3881: --- Summary: CLIENT_WINDOW_MODE generates new windowid even if one exists Key: MYFACES-3881 URL: https://issues.apache.org/jira/browse/MYFACES-3881 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.2 Environment: java 7, tomcat 7.0.50 Reporter: Rene O If you use @ViewScoped beans and activate CLIENT_WINDOW_MODE (url or client) a page refresh generates a new windowid although the application in the current browser window already has a windowid. I think a new windowid should only be generated, if no windowid exists, e.g. open new window or tab with the same url. context-param param-namejavax.faces.CLIENT_WINDOW_MODE/param-name param-valueurl/param-value !--client doesn't work too-- /context-param A testcase is attached. call url: http://localhost:8080/jsftest22/mypage.jsf Fill some values into field Press F5 to refresh the page = new windowid is generated = inputdata is lost, because a new @ViewScoped bean was created -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MYFACES-3873) Problems while using javax.faces.view.ViewScoped for dynamic css generation
Rene O created MYFACES-3873: --- Summary: Problems while using javax.faces.view.ViewScoped for dynamic css generation Key: MYFACES-3873 URL: https://issues.apache.org/jira/browse/MYFACES-3873 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.1 Environment: tomcat-7.0.50, java7 Reporter: Rene O Attachments: jsftest22.zip In my testcase i use javax.faces.view.ViewScoped for a bean (net.jsftest.Theme) which generates my theme. You can see, that this doesn't work inside the used css file (resources/main.css): http://localhost:8080/jsftest22/pages/theme/themetest1.jsf @PostConstruct is never called, so the bean is not initialized It works inside page: http://localhost:8080/jsftest22/pages/theme/themetest2.jsf If you use javax.enterprise.context.SessionScoped within net.jsftest.Theme both cases works. The problem also occurs in current mojarra implementation -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MYFACES-3871) Problems while loading resources of richfaces 5
Rene O created MYFACES-3871:
---
Summary: Problems while loading resources of richfaces 5
Key: MYFACES-3871
URL: https://issues.apache.org/jira/browse/MYFACES-3871
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.1
Environment: tomcat-7.0.50, java 7
Reporter: Rene O
Attachments: jsftest22.zip
If you use myfaces (2.2.1 or current 2.2.2-SNAPSHOT), Richfaces 5 is not able
to load its css-resources correctly.
If you use current mojarra implementation (2.2.5) all resources load without
any complications.
A testcase (mavenproject) is attached. Within the pom.xml you can change the
jsf implementation.
You can start the testcase with the following URL:
{code}
http://localhost:8080/jsftest22/pages/richfacesskintest.jsf
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3609) rendered attribute of f:selectItem is not evaluated within h:selectOneListbox
Rene O created MYFACES-3609:
---
Summary: rendered attribute of f:selectItem is not evaluated
within h:selectOneListbox
Key: MYFACES-3609
URL: https://issues.apache.org/jira/browse/MYFACES-3609
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.8
Reporter: Rene O
If you use the rendered attribute of f:selectItem within h:selectOneListBox, it
is not evaluated. In the example below you can see, that an item with
rendered-condition false is rendered, which is not the expected behaviour.
Example:
!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://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:head
titleJSF Test/title
/h:head
h:body
h:form id=myForm
h:selectOneListbox id=mySelect value=none size=1
style=width:100px;
f:selectItem itemValue=A itemLabel=A /
f:selectItem itemValue=B itemLabel=B
rendered=#{'1' eq '2'}/
/h:selectOneListbox
br/
output rendered condition selectItem 'B': #{'1' eq '2'}
br/
you can see, that selectItem is rendered while rendered
condition is false.
br/
it looks like, that attribute 'rendered' is not
evaluated at all.
/h:form
/h:body
/html
--
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
[jira] [Created] (MYFACES-3296) Allow custom attributes within jsf-components
Allow custom attributes within jsf-components - Key: MYFACES-3296 URL: https://issues.apache.org/jira/browse/MYFACES-3296 Project: MyFaces Core Issue Type: New Feature Affects Versions: 2.1.2 Reporter: Rene O It would be good, if all jsf-components allow the usage of custom attributes: Example: h:inputText id=testcomponent value=value myattribute=test / A common usecase for this issue is the usage of HTML5 data-* attributes ( http://dev.w3.org/html5/spec/elements.html#custom-data-attribute ) Currently all custom attributes are ignored and not rendered. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3245) [h:selectManyCheckbox] hideNoSelectionOption=true is ignored
[h:selectManyCheckbox] hideNoSelectionOption=true is ignored -- Key: MYFACES-3245 URL: https://issues.apache.org/jira/browse/MYFACES-3245 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2-SNAPSHOT Reporter: Rene O Attachments: jsftest.war A testcase to reproduce this issue is attached. Steps to reproduce this issue: 1. http://localhost:8080/jsftest/testselect.jsf The choice Select... should not be rendered, but it is rendered when the page is initially rendered. After selection of Item A or Item B and form submit it disappears If you then clear the selection (action: this.selectedItems = new ArrayListString();) and page is rerendered, the choice Select... is there again. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3200) All values of self-defined composite-component attributes disappear unexpected.
[ https://issues.apache.org/jira/browse/MYFACES-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060308#comment-13060308 ] Rene O commented on MYFACES-3200: - Now everything works as excpected. Thanks for fixing this so fast. All values of self-defined composite-component attributes disappear unexpected. --- Key: MYFACES-3200 URL: https://issues.apache.org/jira/browse/MYFACES-3200 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2-SNAPSHOT Environment: Java 6, Tomcat 6, latest SNAPSHOT of myfaces-2.1.2 (30.06.2011) Reporter: Rene O Assignee: Leonardo Uribe Fix For: 2.0.8, 2.1.2 Attachments: jsf2testcase.war, jsf2testcasewithoutrichfaces.war, jsftest.war A testcase to reproduce this issue is attached. Steps to reproduce this issue: 1. http://localhost:8080/jsf2testcase/components.jsf 2. you can see the value of one of the attributes of the self-defined composite component at 'Panel1' 2. click 'Panel2' 3. click 'Panel1' 4. value at 'Panel1' is not shown anymore. (if you refresh the page with 'F5' after that, the value is there again) Note: This behaviour occurs with the latest myfaces-2.1.2-SNAPSHOT (30.06.2011) With an older version of myfaces-2.1.2-SNAPSHOT (22.06.2011) and with myfaces-2.1.1 everything works as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MYFACES-3200) All values of self-defined composite-component attributes disappear unexpected.
[ https://issues.apache.org/jira/browse/MYFACES-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene O reopened MYFACES-3200: - The issue is still not solved entirely. With javax.faces.PARTIAL_STATE_SAVING set to false in web.xml, the value still disappear (the only good thing is, that there are no further exceptions like in my comment before). Only with the parameter set to true it will now work as expected. But with myfaces-2.1.1 it works in both cases. All values of self-defined composite-component attributes disappear unexpected. --- Key: MYFACES-3200 URL: https://issues.apache.org/jira/browse/MYFACES-3200 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2-SNAPSHOT Environment: Java 6, Tomcat 6, latest SNAPSHOT of myfaces-2.1.2 (30.06.2011) Reporter: Rene O Assignee: Leonardo Uribe Fix For: 2.0.8, 2.1.2 Attachments: jsf2testcase.war, jsf2testcasewithoutrichfaces.war, jsftest.war A testcase to reproduce this issue is attached. Steps to reproduce this issue: 1. http://localhost:8080/jsf2testcase/components.jsf 2. you can see the value of one of the attributes of the self-defined composite component at 'Panel1' 2. click 'Panel2' 3. click 'Panel1' 4. value at 'Panel1' is not shown anymore. (if you refresh the page with 'F5' after that, the value is there again) Note: This behaviour occurs with the latest myfaces-2.1.2-SNAPSHOT (30.06.2011) With an older version of myfaces-2.1.2-SNAPSHOT (22.06.2011) and with myfaces-2.1.1 everything works as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MYFACES-3200) All values of self-defined composite-component attributes disappear unexpected.
[ https://issues.apache.org/jira/browse/MYFACES-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene O reopened MYFACES-3200: - All values of self-defined composite-component attributes disappear unexpected. --- Key: MYFACES-3200 URL: https://issues.apache.org/jira/browse/MYFACES-3200 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2-SNAPSHOT Environment: Java 6, Tomcat 6, latest SNAPSHOT of myfaces-2.1.2 (30.06.2011) Reporter: Rene O Assignee: Leonardo Uribe Fix For: 2.0.8, 2.1.2 Attachments: jsf2testcase.war, jsf2testcasewithoutrichfaces.war, jsftest.war A testcase to reproduce this issue is attached. Steps to reproduce this issue: 1. http://localhost:8080/jsf2testcase/components.jsf 2. you can see the value of one of the attributes of the self-defined composite component at 'Panel1' 2. click 'Panel2' 3. click 'Panel1' 4. value at 'Panel1' is not shown anymore. (if you refresh the page with 'F5' after that, the value is there again) Note: This behaviour occurs with the latest myfaces-2.1.2-SNAPSHOT (30.06.2011) With an older version of myfaces-2.1.2-SNAPSHOT (22.06.2011) and with myfaces-2.1.1 everything works as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3200) All values of self-defined composite-component attributes disappear unexpected.
All values of self-defined composite-component attributes disappear unexpected. --- Key: MYFACES-3200 URL: https://issues.apache.org/jira/browse/MYFACES-3200 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2-SNAPSHOT Environment: Java 6, Tomcat 6, latest SNAPSHOT of myfaces-2.1.2 (30.06.2011) Reporter: Rene O A testcase to reproduce this issue is attached. Steps to reproduce this issue: 1. http://localhost:8080/jsf2testcase/components.jsf 2. you can see the value of one of the attributes of the self-defined composite component at 'Panel1' 2. click 'Panel2' 3. click 'Panel1' 4. value at 'Panel1' is not shown anymore. (if you refresh the page with 'F5' after that, the value is there again) Note: This behaviour occurs with the latest myfaces-2.1.2-SNAPSHOT (30.06.2011) With an older version of myfaces-2.1.2-SNAPSHOT (22.06.2011) and with myfaces-2.1.1 everything works as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3159) ViewExpiredException occurs if you heavy use ajax within more than one form
ViewExpiredException occurs if you heavy use ajax within more than one form --- Key: MYFACES-3159 URL: https://issues.apache.org/jira/browse/MYFACES-3159 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.0 Environment: Java 6, Tomcat 6 and 7, latest SNAPSHOT of MyFaces 2.1.0 Reporter: Rene O Attachments: jsf2testcase-webapp-0.0.1-SNAPSHOT.war I have an usecase with more than one form on a page and heavy use of ajax. After several ajax requests within one of the forms and after that, another ajax request in one of the other forms, a ViewExpiredException occurs. A simplified testcase to reproduce this issue is attached. Steps to reproduce: 1. http://localhost:8080/jsf2testcase/test.jsf 2. click minimum 21 times (one more time than the default value for numberOfViewsInSession) one of the first two buttons 3. click the third button in the other from 4. ViewExpiredException occurs If you only use the two buttons within the first form, the ViewExpiredException never occurs, so i think this is a bug. To use only one form is no option for my usecase and to increase the number of views in session is also no good solution for this, because this only delays the problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3159) ViewExpiredException occurs if you heavy use ajax within more than one form
[ https://issues.apache.org/jira/browse/MYFACES-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13040399#comment-13040399 ] Rene O commented on MYFACES-3159: - thanks for showing this js-snippet. I think that will work for me. ViewExpiredException occurs if you heavy use ajax within more than one form --- Key: MYFACES-3159 URL: https://issues.apache.org/jira/browse/MYFACES-3159 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.0 Environment: Java 6, Tomcat 6 and 7, latest SNAPSHOT of MyFaces 2.1.0 Reporter: Rene O Attachments: jsf2testcase-webapp-0.0.1-SNAPSHOT.war I have an usecase with more than one form on a page and heavy use of ajax. After several ajax requests within one of the forms and after that, another ajax request in one of the other forms, a ViewExpiredException occurs. A simplified testcase to reproduce this issue is attached. Steps to reproduce: 1. http://localhost:8080/jsf2testcase/test.jsf 2. click minimum 21 times (one more time than the default value for numberOfViewsInSession) one of the first two buttons 3. click the third button in the other from 4. ViewExpiredException occurs If you only use the two buttons within the first form, the ViewExpiredException never occurs, so i think this is a bug. To use only one form is no option for my usecase and to increase the number of views in session is also no good solution for this, because this only delays the problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3156) jsf.js event handler is working incorrect in 2.1.0
jsf.js event handler is working incorrect in 2.1.0 -- Key: MYFACES-3156 URL: https://issues.apache.org/jira/browse/MYFACES-3156 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.0 Environment: Java 1.6.0_24, Tomcat 7.0.14, Richfaces 4 Reporter: Rene O It looks like this issue is the same as MYFACES-3080 and MYFACES-3115, which was solved in MyFaces 2.0.6, but now in 2.1.0 it appears again. A testcase to reproduce is attached. Do the following steps: 1.: call http://localhost:8080/jsftest/test.jsf 2.: fill something into the input field and press the Render-Button 3.: you can see in the infobox at top, that no begin-event is recieved. With the current 2.0.6-SNAPSHOT a begin-event is recieved, which is the correct behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3156) jsf.js event handler is working incorrect in 2.1.0
[ https://issues.apache.org/jira/browse/MYFACES-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038441#comment-13038441 ] Rene O commented on MYFACES-3156: - Sorry, it was my fault. In my local mavenrepository there was an older version of the 2.1.0-SNAPSHOT. With the latest SNAPSHOT from https://repository.apache.org/content/groups/snapshots/org/apache/myfaces/core/myfaces-api/2.1.0-SNAPSHOT/ and https://repository.apache.org/content/groups/snapshots/org/apache/myfaces/core/myfaces-impl/2.1.0-SNAPSHOT/ everything works as expected. This issue can be closed. jsf.js event handler is working incorrect in 2.1.0 -- Key: MYFACES-3156 URL: https://issues.apache.org/jira/browse/MYFACES-3156 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.0 Environment: Java 1.6.0_24, Tomcat 7.0.14, Richfaces 4 Reporter: Rene O Attachments: jsftest.zip It looks like this issue is the same as MYFACES-3080 and MYFACES-3115, which was solved in MyFaces 2.0.6, but now in 2.1.0 it appears again. A testcase to reproduce is attached. Do the following steps: 1.: call http://localhost:8080/jsftest/test.jsf 2.: fill something into the input field and press the Render-Button 3.: you can see in the infobox at top, that no begin-event is recieved. With the current 2.0.6-SNAPSHOT a begin-event is recieved, which is the correct behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3156) jsf.js event handler is working incorrect in 2.1.0
[ https://issues.apache.org/jira/browse/MYFACES-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene O resolved MYFACES-3156. - Resolution: Invalid jsf.js event handler is working incorrect in 2.1.0 -- Key: MYFACES-3156 URL: https://issues.apache.org/jira/browse/MYFACES-3156 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.0 Environment: Java 1.6.0_24, Tomcat 7.0.14, Richfaces 4 Reporter: Rene O Attachments: jsftest.zip It looks like this issue is the same as MYFACES-3080 and MYFACES-3115, which was solved in MyFaces 2.0.6, but now in 2.1.0 it appears again. A testcase to reproduce is attached. Do the following steps: 1.: call http://localhost:8080/jsftest/test.jsf 2.: fill something into the input field and press the Render-Button 3.: you can see in the infobox at top, that no begin-event is recieved. With the current 2.0.6-SNAPSHOT a begin-event is recieved, which is the correct behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3080) 'begin' event does not have 'status' property set
[ https://issues.apache.org/jira/browse/MYFACES-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene O updated MYFACES-3080: Status: Patch Available (was: Open) 'begin' event does not have 'status' property set - Key: MYFACES-3080 URL: https://issues.apache.org/jira/browse/MYFACES-3080 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5-SNAPSHOT Reporter: Nick Belaevski With the current 2.0.5-SNAPSHOT 'begin' event does not have 'status' property set. This is due to missing argument in _Impl.sendEvent() call: _Impl.sendEvent(this._xhr, _Impl.BEGIN); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3080) 'begin' event does not have 'status' property set
[ https://issues.apache.org/jira/browse/MYFACES-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016362#comment-13016362 ] Rene O commented on MYFACES-3080: - To solve this problem change in file META-INF\resources\javax.faces\jsf.js B.sendEvent(this._xhr, B.BEGIN); to: B.sendEvent(this._xhr, this._context, B.BEGIN); 'begin' event does not have 'status' property set - Key: MYFACES-3080 URL: https://issues.apache.org/jira/browse/MYFACES-3080 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5-SNAPSHOT Reporter: Nick Belaevski With the current 2.0.5-SNAPSHOT 'begin' event does not have 'status' property set. This is due to missing argument in _Impl.sendEvent() call: _Impl.sendEvent(this._xhr, _Impl.BEGIN); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
