Re: [VOTE] Release of Extensions Validator 1.2.6 and 2.0.6

2012-11-26 Thread Werner Punz 

+1

Am 25.11.12 22:32, schrieb Grant Smith:

+1

On Sunday, November 25, 2012, Hazem Saleh wrote:

+1

Sent from my iPhone

On Nov 25, 2012, at 2:16 AM, Thomas Andraschko
andraschko.tho...@gmail.com javascript:_e({}, 'cvml',
'andraschko.tho...@gmail.com'); wrote:


+1

2012/11/25 Gerhard Petracek javascript:_e({}, 'cvml',
'gerhard.petra...@gmail.com');gerhard.petra...@gmail.com
javascript:_e({}, 'cvml', 'gerhard.petra...@gmail.com');

+1

regards,
gerhard

http://www.irian.athttp://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces




2012/11/25 Gerhard Petracek javascript:_e({}, 'cvml',
'gpetra...@apache.org');gpetra...@apache.org
javascript:_e({}, 'cvml', 'gpetra...@apache.org');

Hi,

I was running the needed tasks to get the 6th release of
Apache MyFaces Extensions Validator out.
The artifacts are deployed to Nexus [1].

These 2 releases contain the following modules for JSF
1.2, JSF 2.x:
 - ExtVal Core
 - ExtVal Property-Validation
 - ExtVal Bean-Validation (Integration + additional
features for using JSR 303 with JSF 1.2 and 2.x)
 - Trinidad-Support-Module
 - Generic-Support-Module

Please take a look at the 1.2.6 and 2.0.6 artifacts and vote!

Please note:
This vote is majority approval with a minimum of three
+1 votes (see [2]).


[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to
be released, and why..


Thanks,
Gerhard

[1]

https://repository.apache.org/content/repositories/orgapachemyfaces-071/org/apache/myfaces/extensions/validator/https://repository.apache.org/content/repositories/orgapachemyfaces-071/org/apache/myfaces/extensions/validator/
[2]

http://www.apache.org/foundation/voting.html#ReleaseVoteshttp://www.apache.org/foundation/voting.html#ReleaseVotes






--
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.

Re: Documentation

2012-11-26 Thread Werner Punz 

Am 23.11.12 16:16, schrieb Grant Smith:

Leo  Werner,

Thanks for the update on this. For now, I want to be able to edit the
xdocs, and have the resulting changes appear on the website. Any Idea
how to accomplish this simple task ?


Guess only Leonardo can answer that for now.

Werner





On Thu, Nov 22, 2012 at 12:59 PM, Leonardo Uribe lu4...@gmail.com
mailto:lu4...@gmail.com wrote:

Hi

2012/11/22 Werner Punz werner.p...@gmail.com
mailto:werner.p...@gmail.com:
  As for the site. Not sure if this one already is served by
svnpubsub or
  still by the old system. Leonardo knows more. My guess is it
still is served
  by the old system. I guess his plan is to have the entire site
hosted by
  svnpubsub for now, and then gradually move over to the CMS once
it is in
  place. But I am not sure, Leo can you fill us in here?

svnpubsub is already working, which was the mandatory task to do
this year.
All myfaces site has been moved to:

http://svn.apache.org/repos/asf/myfaces/site/publish/

In theory the CMS was built on top of svnpubsub, so I suppose there is a
relationship between both:

... The publication links in the CMS are essentially merge + commit
operations in subversion which are tied into the live site via
svnpubsub.
That means publishing in the CMS is virtually instantaneous. ...

I still have not tried the details about how it works, but in theory
you need to
put the files inside a subfolder inside publish folder and later
this will be
consumed by the cms and published properly in the mirror (I'm
speculating
here).

regards,

Leonardo Uribe

--
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.

[jira] [Created] (MYFACESTEST-62) make composite components testable

2012-11-26 Thread dennis hoersch (JIRA) 
dennis hoersch created MYFACESTEST-62:
-

 Summary: make composite components testable
 Key: MYFACESTEST-62
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-62
 Project: MyFaces Test
  Issue Type: Improvement
  Components: Mock Objects
Affects Versions: 1.0.4
 Environment: MyFaces 2.1.6
Reporter: dennis hoersch
Priority: Trivial


May it be possible to move 'FaceletTestCase.java' 
('/myfaces/core/trunk/impl/src/test/java/org/apache/myfaces/view/facelets/FaceletTestCase.java')
 from internal MyFaces to the MyFaces Test project?

Additionally there are some lines commented out which will enable the testing 
of composite components. If I uncomment them I get some compilation errors. 
With the three patched (and attached) classes they disappear and I'm able to 
test a simple facelets page with a composite component used in it successfully.

The xhtml has a namespace declaration like:
xmlns:jsftests=http://java.sun.com/jsf/composite/components;
And the composite is in 'resources/components/' relative to the JUnit test.



Additionally it might be more readable (?) to set the 'servletPath' and the 
'pathInfo' on the internal request object like:

request.setPathElements(
context.getPath(),
getClass().getSimpleName(),
/ + name.getMethodName(),
context.getQuery());
where name is:
@Rule public TestName name = new TestName();


--
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-3656) ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true

2012-11-26 Thread Paul Nicolucci (JIRA) 
Paul Nicolucci created MYFACES-3656:
---

 Summary: ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is 
set to true
 Key: MYFACES-3656
 URL: https://issues.apache.org/jira/browse/MYFACES-3656
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.15
 Environment: WebSphere V8 and Tomcat 2.0.27
Reporter: Paul Nicolucci


My beans are defined as follows:

   managed-bean
managed-bean-nameappManagerBean/managed-bean-name

managed-bean-classcom.ibm.ws.jsf.beans.AppManagerBean/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
/managed-bean
 
managed-bean
managed-bean-nameemailBean/managed-bean-name

managed-bean-classcom.ibm.ws.jsf.beans.EmailBean/managed-bean-class
managed-bean-scopesession/managed-bean-scope
/managed-bean
managed-bean
managed-bean-nameviewScopedBean/managed-bean-name

managed-bean-classcom.ibm.ws.jsf.beans.ViewScopedManagedBean/managed-bean-class
managed-bean-scopeview/managed-bean-scope

managed-property
property-nameemailBean/property-name
value#{emailBean}/value
/managed-property
managed-property
property-nameappManagerBean/property-name
value#{appManagerBean}/value
/managed-property
  
/managed-bean

I've provided an application that reproduces this issue.  To reproduce follow 
these steps:

1) install application 
2) drive a request into the following URL 
host:port/context-root/ViewScopeTest1.jsf
3) leave the email field empty
4) press the submit button.
5) you should be taken to the error page
6) the following text should appear in the textArea but it does not Invalid 
Email: Email can Not be empty

The second test ViewScopeTest2.jsf is similar it does not contain the binding 
attribute and just references a value from the ViewScoped bean and the problem 
can again be reproduced.  

It seems as though the AppManager errorMessage field is null but it has not 
been reset.  I would think that the application scoped bean would still be 
accessible even though the view scoped bean is out of scope.

If you set the SERIALIZE_STATE_IN_SESSION to false and redeploy the application 
then everything works as expected, which seems odd to me but if you un-comment 
this from the web.xml you'll see we get the text on the error page as expected.

I've been working to debug this issue and can't seem to figure out where the 
problem is in the MyFaces code.  I tested the same application on WAS and 
Tomcat to ensure that it was not something specific to a server.  It seems as 
though this is a implementation issue.

Any help that folks can provide would be greatly appreciated!!

--
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] [Commented] (MYFACES-3656) ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true

2012-11-26 Thread Thomas Andraschko (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503939#comment-13503939
 ] 

Thomas Andraschko commented on MYFACES-3656:


does your bean implement serializable?

 ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true
 

 Key: MYFACES-3656
 URL: https://issues.apache.org/jira/browse/MYFACES-3656
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.15
 Environment: WebSphere V8 and Tomcat 2.0.27
Reporter: Paul Nicolucci
 Attachments: ViewScopeProblemMyFaces.war

   Original Estimate: 24h
  Remaining Estimate: 24h

 My beans are defined as follows:
managed-bean
   managed-bean-nameappManagerBean/managed-bean-name
   
 managed-bean-classcom.ibm.ws.jsf.beans.AppManagerBean/managed-bean-class
   managed-bean-scopeapplication/managed-bean-scope
   /managed-bean
  
   managed-bean
   managed-bean-nameemailBean/managed-bean-name
   
 managed-bean-classcom.ibm.ws.jsf.beans.EmailBean/managed-bean-class
   managed-bean-scopesession/managed-bean-scope
   /managed-bean
 managed-bean
 managed-bean-nameviewScopedBean/managed-bean-name
 
 managed-bean-classcom.ibm.ws.jsf.beans.ViewScopedManagedBean/managed-bean-class
 managed-bean-scopeview/managed-bean-scope
 
 managed-property
   property-nameemailBean/property-name
   value#{emailBean}/value
   /managed-property
   managed-property
   property-nameappManagerBean/property-name
   value#{appManagerBean}/value
   /managed-property
   
 /managed-bean
 I've provided an application that reproduces this issue.  To reproduce follow 
 these steps:
 1) install application 
 2) drive a request into the following URL 
 host:port/context-root/ViewScopeTest1.jsf
 3) leave the email field empty
 4) press the submit button.
 5) you should be taken to the error page
 6) the following text should appear in the textArea but it does not Invalid 
 Email: Email can Not be empty
 The second test ViewScopeTest2.jsf is similar it does not contain the 
 binding attribute and just references a value from the ViewScoped bean and 
 the problem can again be reproduced.  
 It seems as though the AppManager errorMessage field is null but it has not 
 been reset.  I would think that the application scoped bean would still be 
 accessible even though the view scoped bean is out of scope.
 If you set the SERIALIZE_STATE_IN_SESSION to false and redeploy the 
 application then everything works as expected, which seems odd to me but if 
 you un-comment this from the web.xml you'll see we get the text on the error 
 page as expected.
 I've been working to debug this issue and can't seem to figure out where the 
 problem is in the MyFaces code.  I tested the same application on WAS and 
 Tomcat to ensure that it was not something specific to a server.  It seems as 
 though this is a implementation issue.
 Any help that folks can provide would be greatly appreciated!!  

--
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] [Commented] (MYFACES-3656) ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true

2012-11-26 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503942#comment-13503942
 ] 

Paul Nicolucci commented on MYFACES-3656:
-

All the beans do implement serializable.  Also note that if I make the 
viewScoped bean session scoped then everything also works as expected.  So 
this seems to be something with the view scope implementation from what I've 
seen in my testing thus far.

 ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true
 

 Key: MYFACES-3656
 URL: https://issues.apache.org/jira/browse/MYFACES-3656
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.15
 Environment: WebSphere V8 and Tomcat 2.0.27
Reporter: Paul Nicolucci
 Attachments: ViewScopeProblemMyFaces.war

   Original Estimate: 24h
  Remaining Estimate: 24h

 My beans are defined as follows:
managed-bean
   managed-bean-nameappManagerBean/managed-bean-name
   
 managed-bean-classcom.ibm.ws.jsf.beans.AppManagerBean/managed-bean-class
   managed-bean-scopeapplication/managed-bean-scope
   /managed-bean
  
   managed-bean
   managed-bean-nameemailBean/managed-bean-name
   
 managed-bean-classcom.ibm.ws.jsf.beans.EmailBean/managed-bean-class
   managed-bean-scopesession/managed-bean-scope
   /managed-bean
 managed-bean
 managed-bean-nameviewScopedBean/managed-bean-name
 
 managed-bean-classcom.ibm.ws.jsf.beans.ViewScopedManagedBean/managed-bean-class
 managed-bean-scopeview/managed-bean-scope
 
 managed-property
   property-nameemailBean/property-name
   value#{emailBean}/value
   /managed-property
   managed-property
   property-nameappManagerBean/property-name
   value#{appManagerBean}/value
   /managed-property
   
 /managed-bean
 I've provided an application that reproduces this issue.  To reproduce follow 
 these steps:
 1) install application 
 2) drive a request into the following URL 
 host:port/context-root/ViewScopeTest1.jsf
 3) leave the email field empty
 4) press the submit button.
 5) you should be taken to the error page
 6) the following text should appear in the textArea but it does not Invalid 
 Email: Email can Not be empty
 The second test ViewScopeTest2.jsf is similar it does not contain the 
 binding attribute and just references a value from the ViewScoped bean and 
 the problem can again be reproduced.  
 It seems as though the AppManager errorMessage field is null but it has not 
 been reset.  I would think that the application scoped bean would still be 
 accessible even though the view scoped bean is out of scope.
 If you set the SERIALIZE_STATE_IN_SESSION to false and redeploy the 
 application then everything works as expected, which seems odd to me but if 
 you un-comment this from the web.xml you'll see we get the text on the error 
 page as expected.
 I've been working to debug this issue and can't seem to figure out where the 
 problem is in the MyFaces code.  I tested the same application on WAS and 
 Tomcat to ensure that it was not something specific to a server.  It seems as 
 though this is a implementation issue.
 Any help that folks can provide would be greatly appreciated!!  

--
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

Result: (Was: [VOTE] release of MyFaces Core 2.0.16)

2012-11-26 Thread Leonardo Uribe 
Hi

Thanks to all people who vote.

We have 5 +1

Mark Struberg
Grant Smith
Hazem Saleh
Werner Punz
Leonardo Uribe

so we can continue with the necessary steps to release MyFaces Core 2.0.16

regards,

Leonardo Uribe

Result: (Was: [VOTE] release of MyFaces Core 2.1.10 )

2012-11-26 Thread Leonardo Uribe 
Hi

Thanks to all people who vote.

We have 5 +1

Mark Struberg
Grant Smith
Hazem Saleh
Werner Punz
Leonardo Uribe

so we can continue with the necessary steps to release MyFaces Core 2.1.10

regards,

Leonardo Uribe

[jira] [Commented] (TOBAGO-1221) Remove JSF 1.1 support

2012-11-26 Thread Hudson (JIRA) 

[ 
https://issues.apache.org/jira/browse/TOBAGO-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504068#comment-13504068
 ] 

Hudson commented on TOBAGO-1221:


Integrated in tobago-trunk #916 (See 
[https://builds.apache.org/job/tobago-trunk/916/])
TOBAGO-1221: Remove JSF 1.1 support (Revision 1413689)

 Result = ABORTED
lofwyr : http://svn.apache.org/viewvc/?view=revrev=1413689
Files : 
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/Sorter.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/UIViewRoot.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/ajax/AjaxResponseRenderer.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIData.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIForm.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIPage.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIPopup.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUISheet.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUITabGroup.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUITree.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/AttributeTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/ConverterTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/DataAttributeTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/FileItemValidatorTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/GridLayoutConstraintTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/LoadBundleTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/PopupReferenceTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/ResetInputActionListenerTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/SubmittedValueLengthValidatorTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/TabChangeListenerTag.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/util/ComponentUtils.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-facelets/src/main/java/org/apache/myfaces/tobago/facelets/PopupReferenceHandler.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-facelets/src/main/java/org/apache/myfaces/tobago/facelets/ResetInputActionListenerHandler.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-facelets/src/main/java/org/apache/myfaces/tobago/facelets/TabChangeListenerHandler.java
* /myfaces/tobago/trunk/tobago-jsf-compat/src/main/java-jsf-1.1
* 
/myfaces/tobago/trunk/tobago-jsf-compat/src/main/java/org/apache/myfaces/tobago/compat/FacesUtils.java
* 
/myfaces/tobago/trunk/tobago-jsf-compat/src/main/java/org/apache/myfaces/tobago/compat/FacesUtilsEL.java
* 
/myfaces/tobago/trunk/tobago-jsf-compat/src/main/java/org/apache/myfaces/tobago/event/ValueExpressionResetInputActionListener.java
* 
/myfaces/tobago/trunk/tobago-jsf-compat/src/main/java/org/apache/myfaces/tobago/util/MessageUtils.java
* 
/myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/DatePickerRenderer.java
* 
/myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/TabGroupRenderer.java
* 
/myfaces/tobago/trunk/tobago-tool/tobago-tool-apt/src/main/resources/org/apache/myfaces/tobago/apt/tagAbstract1.2.stg


 Remove JSF 1.1 support
 --

 Key: TOBAGO-1221
 URL: https://issues.apache.org/jira/browse/TOBAGO-1221
 Project: MyFaces Tobago
  Issue Type: Task
  Components: Core
Affects Versions: 1.6.0-beta-2
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
Priority: Minor

 Tobago 1.6 and above will not support JSF 1.1, so the special code for that 
 version can be removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please

[jira] [Commented] (TOBAGO-1221) Remove JSF 1.1 support

2012-11-26 Thread Hudson (JIRA) 

[ 
https://issues.apache.org/jira/browse/TOBAGO-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504252#comment-13504252
 ] 

Hudson commented on TOBAGO-1221:


Integrated in tobago-trunk #917 (See 
[https://builds.apache.org/job/tobago-trunk/917/])
TOBAGO-1221: Remove JSF 1.1 support
- also applied checkstyle fixes (Revision 1413733)

 Result = ABORTED
lofwyr : http://svn.apache.org/viewvc/?view=revrev=1413733
Files : 
* /myfaces/tobago/trunk/pom.xml
* /myfaces/tobago/trunk/tobago-core/src/main/java-jsf-1.1-todo
* 
/myfaces/tobago/trunk/tobago-example/tobago-example-experimental/src/main/java-jsf-1.1
* 
/myfaces/tobago/trunk/tobago-example/tobago-example-experimental/src/main/java-jsf-1.2
* 
/myfaces/tobago/trunk/tobago-example/tobago-example-experimental/src/main/java/org/apache/myfaces/tobago/example/reference/DynamicController.java
* /myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java-jsf-1.1
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java-jsf-1.2/org/apache/myfaces/tobago/security/CheckAuthorisationMethodExpression.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java-jsf-1.2/org/apache/myfaces/tobago/security/UISecuredButton.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java-jsf-1.2/org/apache/myfaces/tobago/security/UISecuredCommand.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java-jsf-1.2/org/apache/myfaces/tobago/security/UISecuredLink.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java-jsf-1.2/org/apache/myfaces/tobago/security/UISecuredLinkCommand.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java-jsf-1.2/org/apache/myfaces/tobago/security/UISecuredMenuCommand.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java-jsf-1.2/org/apache/myfaces/tobago/security/UISecuredToolBarCommand.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java/org/apache/myfaces/tobago/security/CheckAuthorisationMethodExpression.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java/org/apache/myfaces/tobago/security/UISecuredButton.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java/org/apache/myfaces/tobago/security/UISecuredCommand.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java/org/apache/myfaces/tobago/security/UISecuredLink.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java/org/apache/myfaces/tobago/security/UISecuredLinkCommand.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java/org/apache/myfaces/tobago/security/UISecuredMenuCommand.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-security/src/main/java/org/apache/myfaces/tobago/security/UISecuredToolBarCommand.java
* /myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java-jsf-1.1
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java-jsf-1.2
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/DateExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/ExtensionPanelTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/FileExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/InExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/LabelExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/MenuCheckboxExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/MenuRadioExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/SelectBooleanCheckboxExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/SelectManyCheckboxExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/SelectManyListboxExtensionTag.java
* 
/myfaces/tobago/trunk/tobago-extension/tobago-taglib-extension/src/main/java/org/apache/myfaces/tobago/internal/taglib/extension/SelectManyShuttleExtensionTag.java
*

[jira] [Commented] (MYFACES-3656) ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true

2012-11-26 Thread Leonardo Uribe (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504324#comment-13504324
 ] 

Leonardo Uribe commented on MYFACES-3656:
-

I think the behavior described is expected (different to say that the behavior 
described is desired or intentionally done in that way). 

What's happening here is in MyFaces serialization is set to true by default 
(some old lines from JSF 1.0 spec says so, even if RI does not implement it in 
this way). In JSF 2.2 spec, SERIALIZE_STATE_IN_SESSION param will be 
standarized and set to false by default.

Serialization causes that all beans under view scope are in fact recreated. 
If the param is set to false, the beans are stored into session and on further 
requests are used, looking like everything is ok, but that fact is not true 
because in a cluster configuration the same application will fail.

Only the first time the view scope bean is created, the references from 
managed-property takes effect, but if the bean is serialized/deserialized, the 
references are not restored back, because on the serialization step, even the 
application and session scope beans are serialized too.

This issue is similar to the one described in MYFACES-3581. In this case, a 
view scope bean is annotated with @EJB, but the effect is more or less the 
same. The same issue happens even with session scope beans instead window scope 
beans and when the session is stored in some place. 

How to solve it? I haven't found a decent solution to this issue. One could 
think on just restore the view scope bean and reapply @ManagedProperty 
annotations or entries found in faces-config.xml, but the problem is the view 
scope bean still is storing information that shouldn't be there from start 
(only marking the fields as transient will do the trick, any suggestion?). It 
is possible define an special mode were this hack or some variant is done, but 
it will be only in myfaces and it cannot be enabled by default (or can we? in 
theory RI behave the same as MyFaces but that does not mean we should be bug 
compatible, maybe an SPI interface to make it pluggable and allow CODI 
@ViewAccessScope and other alternatives do the same trick). In theory, it 
should be solved on the bean container level.

The suggested way to deal with this problem is use view scope beans only for 
store info related to the view, and use request scope beans to deal with 
@ManagedProperty stuff. In the request scope you have a reference for the view 
scope and other application/session scope beans. This means you'll have more 
beans and some extra references.

Maybe an extra interface for classes implementing LifecycleProvider2? 
BeanSerializationProvider? suggestions are welcome.

 ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true
 

 Key: MYFACES-3656
 URL: https://issues.apache.org/jira/browse/MYFACES-3656
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.15
 Environment: WebSphere V8 and Tomcat 2.0.27
Reporter: Paul Nicolucci
 Attachments: ViewScopeProblemMyFaces.war

   Original Estimate: 24h
  Remaining Estimate: 24h

 My beans are defined as follows:
managed-bean
   managed-bean-nameappManagerBean/managed-bean-name
   
 managed-bean-classcom.ibm.ws.jsf.beans.AppManagerBean/managed-bean-class
   managed-bean-scopeapplication/managed-bean-scope
   /managed-bean
  
   managed-bean
   managed-bean-nameemailBean/managed-bean-name
   
 managed-bean-classcom.ibm.ws.jsf.beans.EmailBean/managed-bean-class
   managed-bean-scopesession/managed-bean-scope
   /managed-bean
 managed-bean
 managed-bean-nameviewScopedBean/managed-bean-name
 
 managed-bean-classcom.ibm.ws.jsf.beans.ViewScopedManagedBean/managed-bean-class
 managed-bean-scopeview/managed-bean-scope
 
 managed-property
   property-nameemailBean/property-name
   value#{emailBean}/value
   /managed-property
   managed-property
   property-nameappManagerBean/property-name
   value#{appManagerBean}/value
   /managed-property
   
 /managed-bean
 I've provided an application that reproduces this issue.  To reproduce follow 
 these steps:
 1) install application 
 2) drive a request into the following URL 
 host:port/context-root/ViewScopeTest1.jsf
 3) leave the email field empty
 4) press the submit button.
 5) you should be taken to the error page
 6) the following text should appear in the textArea but it does not Invalid 
 Email: Email can Not be empty
 The second test

FW: [TRINIDAD]: selectManyShuttle seems to block when there is a selected item

2012-11-26 Thread Rich Schaaf 
Apologies for the cross-posting.  I'm not sure if this is appropriate for
the developers list but there was no response to my post on the Trinidad
users list.

Can anyone suggest a workaround or provide advice on what I'm doing wrong
with the selectManyShuttle component?

- Rich
-Original Message-
From: Rich Schaaf [mailto:rsch...@commoninf.com] 
Sent: Tuesday, October 23, 2012 8:15 AM
To: us...@myfaces.apache.org
Subject: [Trinidad]: selectManyShuttle seems to block when there is a
selected item

I'm trying to use the Trinidad selectManyShuttle component and I find that
if I bind the value of the component, then while an item is selected in
either the leading or trailing lists of the shuttle component, commandLinks
on the page are blocked.  If I click either the move all, or remove all
buttons to move all of the items in the shuttle to either the trailing or
leading list (thereby deselecting individual items in the list), then the
commandLinks on the page become unblocked.  I've boiled the problem down to
the simple example given below.


Any suggestions for either what I'm doing wrong in my use of the component
or a workaround?

Library versions:
Originally encountered on MyFaces 2.0.5 / Trinidad 2.0.0 Reproduced on the
latest versions: MyFaces 2.1.9 / Trinidad 2.0.1

Browsers:
Problem happens in both FireFox 16.0.1 and IE 8.


Page1.xhtml:

tr:document
   xmlns:ui=http://java.sun.com/jsf/facelets;
   xmlns:h=http://java.sun.com/jsf/html;
   xmlns:f=http://java.sun.com/jsf/core;
   xmlns:tr=http://myfaces.apache.org/trinidad;

tr:form
tr:commandLink text=Link
action=#{selectmanyshuttlebacking.someAction}/

tr:selectManyShuttle value = #{selectmanyshuttlebacking.shuttleItems}
tr:selectItem label=Apple value=1 /
tr:selectItem label=Orange value=2 / /tr:selectManyShuttle  

/tr:form
/tr:document



SelectManyShuttleBacking.java:

package org.apache.myfaces.trinidad.blank;

import javax.faces.bean.ManagedBean;

@ManagedBean(name=selectmanyshuttlebacking)
public class SelectManyShuttleBacking {
public SelectManyShuttleBacking() { 
}

private Integer[] m_shuttleItems = null;
public Integer[] getShuttleItems() {
return m_shuttleItems;
}   

public void setShuttleItems(Integer[] shuttleItems) {
m_shuttleItems = shuttleItems;
}

public String someAction() {
return outcome;
}
}

[jira] [Commented] (MYFACES-3586) Performance improvement in Resource loading - HIGH CPU inflating bytes in ResourceHandlerImpl.handleResourceRequest

2012-11-26 Thread EAG (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504418#comment-13504418
 ] 

EAG commented on MYFACES-3586:
--

Hi, I am also facing the same issue with myfaces 2.1. I am using Primefaces for 
my web application. Run a test for 500 users on 4core system. The CPU chocked 
to 100% when concurreny reached 300 users. The following exception is coming:

Error trying to load resource primefaces.css with library primefaces :Broken 
pipe

The resource handler definitely needs to be fixed. Otherwise me or the others 
using myfaces 2.x will not able be to scale the application. Please provide 
myfaces jar with upgraded resource handler.

Also let me know a way to integrate this available patch so that in future i 
can upgrade myfaces with ease.

 Performance improvement in Resource loading - HIGH CPU inflating bytes in 
 ResourceHandlerImpl.handleResourceRequest
 ---

 Key: MYFACES-3586
 URL: https://issues.apache.org/jira/browse/MYFACES-3586
 Project: MyFaces Core
  Issue Type: Improvement
 Environment: ALL
Reporter: Rohit Dilip Kelapure
 Attachments: MYFACES-3586.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 In a high concurrency load test with Apache MyFaces + RichFaces component 
 library we found that under peak load majority of our web container threads 
 were stuck in this call stack 
 at java/util/zip/Inflater.inflateBytes(Native Method)
 at java/util/zip/Inflater.inflate(Inflater.java:249(Compiled Code))
 at 
 java/util/zip/InflaterInputStream.read(InflaterInputStream.java:146(Compiled 
 Code))
 at 
 java/util/zip/InflaterInputStream.read(InflaterInputStream.java:116(Compiled 
 Code))
 at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code))
 at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code))
 at java/io/PushbackInputStream.read(PushbackInputStream.java:133(Compiled 
 Code))
 at 
 org/apache/myfaces/shared_impl/resource/ResourceImpl$ValueExpressionFilterInputStream.read(ResourceImpl.java:117(Compiled
  Code))
 at java/io/InputStream.read(InputStream.java:175(Compiled Code))
 at java/io/InputStream.read(InputStream.java:97(Compiled Code))
 at 
 org/apache/myfaces/application/ResourceHandlerImpl.pipeBytes(ResourceHandlerImpl.java:402(Compiled
  Code))
 at 
 org/apache/myfaces/application/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:357(Compiled
  Code))
 at 
 org/richfaces/resource/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:257(Compiled
  Code))
 at javax/faces/webapp/FacesServlet.service(FacesServlet.java:183(Compiled 
 Code))
 at 
 org/richfaces/webapp/ResourceServlet.httpService(ResourceServlet.java:110(Compiled
  Code))
 at 
 org/richfaces/webapp/ResourceServlet.service(ResourceServlet.java:105(Compiled
  Code)) 
 After looking at the src code of  
 org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(FacesContext)
   I can see that the ResourceHandlerCache caches the Resource metadata ; 
 however the actual output of the resource which is written to the 
 outputstream in ResourceHandlerImpl.pipeBytes is NEVER cached. 
 This causes a scalability problem in our case because each access to the 
 resource involves cracking open a jar, inflating the bytes and parsing a 
 stream of bytes. This is done multiple times for the same resource(say a css 
 file) inside the richfaces jar inspite of the resource not changing. 
 I propose a much needed performance optimization wherein we cache the output 
 of the Resource handled and stash the output byte[] it as softReference in 
 the ResourceHandlerCache.ResourceValue. 

--
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] [Comment Edited] (MYFACES-3586) Performance improvement in Resource loading - HIGH CPU inflating bytes in ResourceHandlerImpl.handleResourceRequest

2012-11-26 Thread EAG (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504418#comment-13504418
 ] 

EAG edited comment on MYFACES-3586 at 11/27/12 7:50 AM:


Hi, I am also facing the same issue with myfaces 2.1. I am using Primefaces for 
my web application. Run a test for 500 users on 4core system. The CPU chocked 
to 100% when concurreny reached 300 users. The following exception is coming:

org.apache.myfaces.application.ResourceHandlerImpl handleResourceRequest. 
SEVERE: Error trying to load resource primefaces.css with library primefaces 
:Broken pipe (errno:32)

The resource handler definitely needs to be fixed. Otherwise me or the others 
using myfaces 2.x will not able be to scale the application. Please provide 
myfaces jar with upgraded resource handler.

Also let me know a way to integrate this available patch so that in future i 
can upgrade myfaces with ease.

  was (Author: eag):
Hi, I am also facing the same issue with myfaces 2.1. I am using Primefaces 
for my web application. Run a test for 500 users on 4core system. The CPU 
chocked to 100% when concurreny reached 300 users. The following exception is 
coming:

Error trying to load resource primefaces.css with library primefaces :Broken 
pipe

The resource handler definitely needs to be fixed. Otherwise me or the others 
using myfaces 2.x will not able be to scale the application. Please provide 
myfaces jar with upgraded resource handler.

Also let me know a way to integrate this available patch so that in future i 
can upgrade myfaces with ease.
  
 Performance improvement in Resource loading - HIGH CPU inflating bytes in 
 ResourceHandlerImpl.handleResourceRequest
 ---

 Key: MYFACES-3586
 URL: https://issues.apache.org/jira/browse/MYFACES-3586
 Project: MyFaces Core
  Issue Type: Improvement
 Environment: ALL
Reporter: Rohit Dilip Kelapure
 Attachments: MYFACES-3586.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 In a high concurrency load test with Apache MyFaces + RichFaces component 
 library we found that under peak load majority of our web container threads 
 were stuck in this call stack 
 at java/util/zip/Inflater.inflateBytes(Native Method)
 at java/util/zip/Inflater.inflate(Inflater.java:249(Compiled Code))
 at 
 java/util/zip/InflaterInputStream.read(InflaterInputStream.java:146(Compiled 
 Code))
 at 
 java/util/zip/InflaterInputStream.read(InflaterInputStream.java:116(Compiled 
 Code))
 at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code))
 at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code))
 at java/io/PushbackInputStream.read(PushbackInputStream.java:133(Compiled 
 Code))
 at 
 org/apache/myfaces/shared_impl/resource/ResourceImpl$ValueExpressionFilterInputStream.read(ResourceImpl.java:117(Compiled
  Code))
 at java/io/InputStream.read(InputStream.java:175(Compiled Code))
 at java/io/InputStream.read(InputStream.java:97(Compiled Code))
 at 
 org/apache/myfaces/application/ResourceHandlerImpl.pipeBytes(ResourceHandlerImpl.java:402(Compiled
  Code))
 at 
 org/apache/myfaces/application/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:357(Compiled
  Code))
 at 
 org/richfaces/resource/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:257(Compiled
  Code))
 at javax/faces/webapp/FacesServlet.service(FacesServlet.java:183(Compiled 
 Code))
 at 
 org/richfaces/webapp/ResourceServlet.httpService(ResourceServlet.java:110(Compiled
  Code))
 at 
 org/richfaces/webapp/ResourceServlet.service(ResourceServlet.java:105(Compiled
  Code)) 
 After looking at the src code of  
 org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(FacesContext)
   I can see that the ResourceHandlerCache caches the Resource metadata ; 
 however the actual output of the resource which is written to the 
 outputstream in ResourceHandlerImpl.pipeBytes is NEVER cached. 
 This causes a scalability problem in our case because each access to the 
 resource involves cracking open a jar, inflating the bytes and parsing a 
 stream of bytes. This is done multiple times for the same resource(say a css 
 file) inside the richfaces jar inspite of the resource not changing. 
 I propose a much needed performance optimization wherein we cache the output 
 of the Resource handled and stash the output byte[] it as softReference in 
 the ResourceHandlerCache.ResourceValue. 

--
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