from:"Dora Rajappan"


[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198723#comment-16198723
 ] 

Dora Rajappan commented on MYFACES-4162:


I got the redirect flag fundamental from the mkyong example. After all its just 
a display error of browser and cant we ignore it!!! at the cost of a redirect 
for all non ajaxed navigations!!!

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax


[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198563#comment-16198563
 ] 

Dora Rajappan commented on MYFACES-4162:


Its true that both mojarra and myfaces behave same way displaying previous page 
names in browser. Yes its the urls. Guess its how things work. And 4154 can be 
closed then.

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax


[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198540#comment-16198540
 ] 

Dora Rajappan edited comment on MYFACES-4162 at 10/10/17 12:01 PM:
---

I just checked below two are related and cause by repeated ajax calls. Only 
first ajax call one was succeeding. Subsequent calls whether to show another 
error message or navigate to a different page wasnt working. With the latest 
fix they both work very well. 
.https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4160 
https://issues.apache.org/jira/browse/MYFACES-4162 .
4154 is purely a navigation and page name error not related to ajax. Ie after 
login page (very first page) when navigated to a new page it shows in browser, 
name of the previous page while its at a current page rendered properly). 4154 
is not fixed. 4160, 4162 are fixed and works both with IE and chrome!!! Thanks 
to Werner!



was (Author: dorarajappan):
I just checked below two are related and cause by repeated ajax calls. Only 
first ajax call one was succeeding. Subsequent calls whether to show another 
error message or navigate to a different page wasnt working. With the latest 
fix they both work very well. 
.https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4160 
https://issues.apache.org/jira/browse/MYFACES-4162 .
4154 is purely a navigation and page name error not related to ajax. Ie after 
login page (very first page) when navigated to a new page it shows in browser 
name of the previous page while its at a current page rendered properly). 4154 
is not fixed. 4160, 4162 are fixed and works both with IE and chrome!!! Thanks 
to Werner!


> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax


[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198540#comment-16198540
 ] 

Dora Rajappan commented on MYFACES-4162:


I just checked below two are related and cause by repeated ajax calls. Only 
first ajax call one was succeeding. Subsequent calls whether to show another 
error message or navigate to a different page wasnt working. With the latest 
fix they both work very well. 
.https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4160 
https://issues.apache.org/jira/browse/MYFACES-4162 .
4154 is purely a navigation and page name error not related to ajax. Ie after 
login page (very first page) when navigated to a new page it shows in browser 
name of the previous page while its at a current page rendered properly). 4154 
is not fixed. 4160, 4162 are fixed and works both with IE and chrome!!! Thanks 
to Werner!


> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

2017-10-09 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197067#comment-16197067
 ] 

Dora Rajappan commented on MYFACES-4162:


Works fine with IE and not with chrome!

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: jsf.js post 2.3 plans

2017-10-09 Thread Dora Rajappan

  Hi Werner,
     I had a mvn clean package of core and checked it from IE 11 and it works 
very good.     The fix works fine with repeated ajax calls now!  
 Thanks & Regards, Dora Rajappan.
   
.On Monday, October 9, 2017, 3:19:19 PM GMT+5:30, Werner Punz 
<werner.p...@gmail.com> wrote:  
 
 Just to clarify it:

Before the update it looks like

https://gist.github.com/werpu/ 071e11cc6328f9f439a6342b0e128e c8

Both forms have a viewstate element.

Before my fixes, the viewstate of the first form was gone.
Hence you ran into issues:

After my yesterdays update the result now looks like following (I got a 
validation error so the viewstate is recycled in the response which 
looks like)

https://gist.github.com/werpu/ 172786afcdf6514b6120379ab5e236 ce

The final rendered form is now:

https://gist.github.com/werpu/ cd85343ddc42ef8857a806d8fe06e2 33


EjSU7V49OrNPDglILvevt4kDdHyuyO RwVxrmPKQfWqfKBXoi on form 1 and 2 being 
the same.


Before my patches, only the second form hat a valid viewstate element 
set and hence you ran into viewstate issues.

Please check the jsf.js your browser is loading, if you got the old 
version in, it looks like it. The build should have produced one
with the new version, but jsf.js is never checked in, it is built by the 
build system.

Check your browsers jsf.js for something like mfInternal.namingModeId
This is only in my patch but not in the old codebase.



Cheers

Werner




Am 09.10.17 um 11:34 schrieb Werner Punz:
> Hi Dora, what do you mean that the
> behavior of repeated ajax calls is same?
> 
> 
> I tried your example yesterday after building the final js file via a 
> mvn build and before
> only the second form got an ajax viestate update
> now both forms get one.
> 
> What behavior do you get?
> Did you make a proper mvn clean install to get the latest jsf.js in?
> 
> ajaxresponse22.js was deleted because it is dead code it accidentally 
> was in the codebase, ajaxresponse.js now updates all forms in a 
> multiform environment under a given view root. In your example
> the viewroot is the body element.
> 
> 
> 
> 
> 
> Werner
> 
> 
> 
> Am 09.10.17 um 10:46 schrieb Dora Rajappan:
>> Hi,
>>
>>   Thank you very much for the fix Werner.
>>   I took the latest core today and built it and tested from payara 
>> without any config changes. Found ajaxresponse22.js deleted and 
>> ajaxresponse.js changed.
>>   And the behavior of repeated ajax calls is same.
>>   Can we have the config changes exactly if any in this manner? I 
>> checked 4160 and quickly not make out the config changes.
>>     
>>          xyz
>>          abc
>>      
>>
>> Thanks & Regards,
>> Dora Rajappan.
>> On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz 
>> <werner.p...@gmail.com> wrote:
>>
>>
>> No sync with Mojarra I have discussed that a while ago.
>> The problem is a licensing problem. Mojarra basically can use
>> our code but not vice versa, because the CDDL cannot be implemented in
>> ASF2 code.
>>
>> The ASF2 license is a very liberal license, but due to the fact that it
>> is so liberal, it is impossible to integrate less liberal code in our
>> codebase.
>>
>> As for your repeated Ajax problems MYFACES-4160 that is a really old
>> spec bug which reared its ugly head in multiform scenarii.
>> I worked around that by providing a special config param.
>> With JSF 2.3 it finally will be fixed.
>>
>>
>>
>> Werner
>>
>>
>> Am 06.10.17 um 11:59 schrieb Dora Rajappan:
>>  > Thanks for detailing the future of browser and how jsf cope up with 
>> it.
>>  >
>>  > I was using mojarra for my application and the commandLink was not
>>  > working due to script problem.
>>  > So I switched to myfaces and we got some problem with repeated ajax
>>  > calls. (Myfaces 4160).
>>  >
>>  > Are we syncing with mojarra regarding the technology to be used 
>> with the
>>  > jsf.js, entire scripting arena.
>>  > Not sure spec say anything about the technology used for scripting.
>>  >
>>  > Thanks & Regards,
>>  > Dora Rajappan.
>>
>>
> 
> 
>

Re: jsf.js post 2.3 plans

2017-10-09 Thread Dora Rajappan

 Hi,
 Thank you very much for the fix Werner. I took the latest core today and built 
it and tested from payara without any config changes. Found ajaxresponse22.js 
deleted and ajaxresponse.js changed. And the behavior of repeated ajax calls is 
same. Can we have the config changes exactly if any in this manner? I checked 
4160 and quickly not make out the config changes.            
xyz        abc            

Thanks & Regards,Dora Rajappan.On Sunday, October 8, 2017, 7:39:48 PM 
GMT+5:30, Werner Punz <werner.p...@gmail.com> wrote:  

 No sync with Mojarra I have discussed that a while ago.
The problem is a licensing problem. Mojarra basically can use
our code but not vice versa, because the CDDL cannot be implemented in 
ASF2 code.

The ASF2 license is a very liberal license, but due to the fact that it 
is so liberal, it is impossible to integrate less liberal code in our 
codebase.

As for your repeated Ajax problems MYFACES-4160 that is a really old 
spec bug which reared its ugly head in multiform scenarii.
I worked around that by providing a special config param.
With JSF 2.3 it finally will be fixed.

Werner

Am 06.10.17 um 11:59 schrieb Dora Rajappan:
> Thanks for detailing the future of browser and how jsf cope up with it.
> 
> I was using mojarra for my application and the commandLink was not 
> working due to script problem.
> So I switched to myfaces and we got some problem with repeated ajax 
> calls. (Myfaces 4160).
> 
> Are we syncing with mojarra regarding the technology to be used with the 
> jsf.js, entire scripting arena.
> Not sure spec say anything about the technology used for scripting.
> 
> Thanks & Regards,
> Dora Rajappan.

[jira] [Comment Edited] (MYFACES-4153) h:selectOneRadio when rendered inside h:panelGroup which is right aligned stands out from the group

2017-10-06 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16194450#comment-16194450
 ] 

Dora Rajappan edited comment on MYFACES-4153 at 10/6/17 10:58 AM:
--

Thomas you can run this pom as it is and you will get the login page where you 
can find the alignment of selectOneRadio.


was (Author: dorarajappan):
Thomas you can run this pom as it it and you will get the login page where you 
can find the alignment of selectOneRadio.

> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group
> ---
>
> Key: MYFACES-4153
> URL: https://issues.apache.org/jira/browse/MYFACES-4153
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>Priority: Minor
> Attachments: login.xhtml, mf23test.zip
>
>
> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group towards the left since it gets rendered as html 
> table. This is same behaviour for mojarra 2.2 also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: jsf.js post 2.3 plans

2017-10-06 Thread Dora Rajappan

 Thanks for detailing the future of browser and how jsf cope up with it.
I was using mojarra for my application and the commandLink was not working due 
to script problem.So I switched to myfaces and we got some problem with 
repeated ajax calls. (Myfaces 4160).
Are we syncing with mojarra regarding the technology to be used with the 
jsf.js, entire scripting arena.Not sure spec say anything about the technology 
used for scripting.
Thanks & Regards,Dora Rajappan.

On Thursday, October 5, 2017, 11:32:23 PM GMT+5:30, Thomas Andraschko 
<andraschko.tho...@gmail.com> wrote:  
 
 yep. +1 for IE11 in JSF.next

2017-10-05 14:36 GMT+02:00 Werner Punz <werner.p...@gmail.com>:

Yeah given the timeframe, I guess IE11 is perfectly fine. We cannot
expect JSF 2.4 to hit the final spec before 2019, by then even
corporate support of Windows 7 will come to an end.

The main problem I see is that we probably will be stuck with supporting
IE11 for many years, since Microsoft still basically packs it in with every 
windows 10 sort of as secondary browser. So IE11 support will die about 10 
years after Microsoft stops doing it.

And believe me even IE11
is currently the bottom barrely quality and speedwise you currently get
in the browser space. Even frameworks like Angular 1 basically drive the IE11 
engine to its limits, the more shims you add it the bigger the browser becomes 
as a problem in day to day development.


I guess we once will hit the point where we will say we cannot support it 
anymore. Not now not in 2 years but sometime in the future.


Werner



Am 05.10.17 um 14:12 schrieb Mike Kienenberger:

I think it's ok for us to say that the baseline is IE11.   If you are
concerned, take a poll on the users list.

On Thu, Oct 5, 2017 at 3:43 AM, Thomas Andraschko
<andraschko.tho...@gmail.com> wrote:

Hi Werner,

big +1 for doing a completely new jsf.js!

Basically it would be really great to use another lang as plain js.
But there is also another downside: most webdevelopers and commiters of
MyFaces are fimilar with plain js but maybe not with TypeScript or else.
But i think we should do it if can we can easily integrate it somehow in our
maven builds.
My personal opinion is that i would prefer plain js if the developers must
install nodejs etc. on their machines. If everything is done by maven in the
background, it's ok for me.

As you already said, we actually must avoid dependencies like kotlin.js and
jquery.js - thats a no go and also not really required.

Regards,
Thomas



2017-10-05 9:19 GMT+02:00 Werner Punz <werner.p...@gmail.com>:


Hi guys


I just wanted to start a discussion on how we are going to proceed with
the jsf.js codebase.
The issue is following:

Our codebase which currently is adapted by me for 2.3 is rather old.
It by now is around 9-10 years old and back then most of the stuff I did
made sense
a) The library needed to be self contained
b) There were an awful lot of browsers in use, which did not adhere to any
standards whatsoever
c) There was no real inheritance system available just the prototype
system which is one level below inheritance by allowing to access the
class/object tree and manipulate it on the fly

So what I did was following
Implement my own class system for not having to deal with prototype
inheritance all the time
Since I needed to be self contained integrating a library like JQuery
(which also was it its infancy at that time) was out of the question
due to possible conflicts. There also was no widespread support
for querySelector on node level some browsers had it some browsers
had other workarounds to speed the dom node lookup up.

Also no unified ajax handling, the ajax api was at its infancy and I still
had to support the archaic IE way of doing things.

To the worse there were significant differences in dom and xml handling
between the various browsers out in the wild compared to the already
defined standards (I am speaking of you IE and mobile browsers in use back
then)

So in the end I ended up with a codebase which is about 40-50% there just
to support legacy browsers. While I did some work to isolate the quirks code
and compile it out of the codebase there still is work to be done.

Again all of this made sense back then...


Lots of things have been changed in those 10 years and now most of the
things do not make sense anymore.

a) We have saner meta languages which allow to compile to javascript,
following candidates come to my mind

- Typescript, a language which I amn very familiar with due to my day to
day work
- Coffeescript ... not very familiar with that one
- Kotlin... yes that one also has a javascript target compiler

We definitely should opt for a meta compiler instead of pure js.
The reasons are many, and I can speak here atm only for Typescript

- You can change ecma script levels on build level
- You can change the package management system in build level
- You get additional coding security by having the apis fortif

[jira] [Commented] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.

2017-09-27 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182191#comment-16182191
 ] 

Dora Rajappan commented on MYFACES-4156:


Yes I will open another bug then. It works with mojarra. Yes partial response 
omits the h:messages.

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MessageBean.java, mf23test.zip, 
> MyValidator.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.

2017-09-27 Thread Dora Rajappan (JIRA)


 [ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dora Rajappan reopened MYFACES-4156:


FacesMessage is not displayed for more than one wrong entries(eg password retry 
max 3 attempts). This scenario is replicated with the project you have provided 
as it is. FacesMessage is correctly displayed for the first wrong entry and not 
for the subsequent entries unless page is refreshed.

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MessageBean.java, mf23test.zip, 
> MyValidator.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.

2017-09-26 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180465#comment-16180465
 ] 

Dora Rajappan commented on MYFACES-4156:


Yes now I got it. I ran your test for input and got the Facesmessage. 

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MessageBean.java, mf23test.zip, 
> MyValidator.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.

2017-09-26 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180441#comment-16180441
 ] 

Dora Rajappan commented on MYFACES-4156:


I tried to run your example and its not getting a dependency from central.

[ERROR] Failed to execute goal 
org.eclipse.jetty:jetty-maven-plugin:9.3.17.RC0:run (default-cli) on project 
mf23test: Execution default-cli of goal 
org.eclipse.jetty:jetty-maven-plugin:9.3.17.RC0:run failed: Plugin 
org.eclipse.jetty:jetty-maven-plugin:9.3.17.RC0 or one of its dependencies 
could not be resolved: Could not transfer artifact 
org.eclipse.jdt.core.compiler:ecj:jar:4.4.2 from/to central 
(http://repo.maven.apache.org/maven2): GET request of: 
org/eclipse/jdt/core/compiler/ecj/4.4.2/ecj-4.4.2.jar from central failed: 
Premature end of Content-Length delimited message body (expected: 2310271; 
received: 101132 -> [Help 1]
[ERROR]

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MessageBean.java, mf23test.zip, 
> MyValidator.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178907#comment-16178907
 ] 

Dora Rajappan edited comment on MYFACES-4156 at 9/25/17 2:18 PM:
-

{color:#f691b2} 
  
  
  
  
  
 
  
   
 
  
{color}
I missed to include it in this comment. I changed it to the way u got the 
message still for ajax its not displayed.


was (Author: dorarajappan):
{color:#59afe1} 
  
  
  
  
  
 
  
   
 
  

I missed to include it in this comment. I changed it to the way u got the 
message still for ajax its not displayed.{color}

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MessageBean.java, MyValidator.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178896#comment-16178896
 ] 

Dora Rajappan edited comment on MYFACES-4156 at 9/25/17 12:58 PM:
--

{color:#f691b2}bq. 
bq.   
bq.   
bq. Still partial response not contain facesmessage!
bq. {color}


was (Author: dorarajappan):
bq. 
bq.   
bq.   
bq. Still partial response not contain facesmessage!
bq. 

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MyValidator.java, UserBean.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178819#comment-16178819
 ] 

Dora Rajappan edited comment on MYFACES-4156 at 9/25/17 12:57 PM:
--

{color:#f6c342}I used a method of the backing bean to validate the input Text 
submitted form via ajax. 
I followed your custom validator example also with ajax submit.

I got no message at client side. I got below response of view state. I have two 
forms in a page and hence submitting via ajax.



 


 
   
  
  
  

   
  
  
  
  
  
  
  {color}


was (Author: dorarajappan):
I used a method of the backing bean to validate the input Text submitted form 
via ajax. 
I followed your custom validator example also with ajax submit.

I got no message at client side. I got below response of view state. I have two 
forms in a page and hence submitting via ajax.



 


 
   
  
  
  

   
  
  
  
  
  
  
  

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MyValidator.java, UserBean.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178907#comment-16178907
 ] 

Dora Rajappan edited comment on MYFACES-4156 at 9/25/17 12:56 PM:
--

{color:#59afe1} 
  
  
  
  
  
 
  
   
 
  

I missed to include it in this comment. I changed it to the way u got the 
message still for ajax its not displayed.{color}


was (Author: dorarajappan):
 
  
  
  
  
  
 
  
   
 
  

I missed to include it in this comment. I changed it to the way u got the 
message still for ajax its not displayed.

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MyValidator.java, UserBean.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178896#comment-16178896
 ] 

Dora Rajappan edited comment on MYFACES-4156 at 9/25/17 12:54 PM:
--

bq. 
bq.   
bq.   
bq. Still partial response not contain facesmessage!
bq. 


was (Author: dorarajappan):

  
  
Still partial response not contain facesmessage!


> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
> Attachments: login.xhtml, MyValidator.java, UserBean.java
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4155) For inputFile upload when multipart form is submitted the actionListener is not able to get the file.getSubmittedFileName()


[ 
https://issues.apache.org/jira/browse/MYFACES-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178922#comment-16178922
 ] 

Dora Rajappan commented on MYFACES-4155:


Thank you very much. It works.

> For inputFile upload when multipart form is submitted the actionListener is 
> not able to get the file.getSubmittedFileName() 
> 
>
> Key: MYFACES-4155
> URL: https://issues.apache.org/jira/browse/MYFACES-4155
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
>
> For inputFile upload when multipart form is submitted the actionListener is 
> not able to get the file.getSubmittedFileName() . It throws below exception 
> with myfaces while its passed with mojarra.
> Class org.apache.myfaces.shared.renderkit.html.util.HttpPartWrapper can not 
> access a member of class org.apache.catalina.fileupload.PartItem with 
> modifiers "public"
>   at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
>   at 
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
>   at 
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
>   at java.lang.reflect.Method.invoke(Method.java:491)
>   at 
> org.apache.myfaces.shared.renderkit.html.util.HttpPartWrapper.getSubmittedFileName(HttpPartWrapper.java:96)
>   at UserBean.save(UserBean.java:595)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178907#comment-16178907
 ] 

Dora Rajappan commented on MYFACES-4156:


 
  
  
  
  
  
 
  
   
 
  

I missed to include it in this comment. I changed it to the way u got the 
message still for ajax its not displayed.

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178898#comment-16178898
 ] 

Dora Rajappan commented on MYFACES-4156:


without render works with mojarra

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178898#comment-16178898
 ] 

Dora Rajappan edited comment on MYFACES-4156 at 9/25/17 11:53 AM:
--

without render works with mojarra :)


was (Author: dorarajappan):
without render works with mojarra

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178896#comment-16178896
 ] 

Dora Rajappan commented on MYFACES-4156:



  
  
Still partial response not contain facesmessage!


> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.


[ 
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178819#comment-16178819
 ] 

Dora Rajappan commented on MYFACES-4156:


I used a method of the backing bean to validate the input Text submitted form 
via ajax. 
I followed your custom validator example also with ajax submit.

I got no message at client side. I got below response of view state. I have two 
forms in a page and hence submitting via ajax.



 


 
   
  
  
  

   
  
  
  
  
  
  
  

> Myface is not showing the FacesMessage after validation when 
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>
> Myfaces 2.3 is not showing the FacesMessage after validation when 
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should 
> not exceed 32");
> 
> throw new ValidatorException(msg);
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4157) Myfaces parses commented code from xhtml and throws property not found exception

2017-09-22 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176377#comment-16176377
 ] 

Dora Rajappan commented on MYFACES-4157:


thank you very much. I will close this then?

> Myfaces parses commented code from xhtml and throws property not found 
> exception
> 
>
> Key: MYFACES-4157
> URL: https://issues.apache.org/jira/browse/MYFACES-4157
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>Priority: Minor
>
> Myfaces parses commented code from xhtml and throws property not found 
> exception.
> Myfaces should ignore commented code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYFACES-4157) Myfaces parses commented code from xhtml and throws property not found exception

2017-09-22 Thread Dora Rajappan (JIRA)

Dora Rajappan created MYFACES-4157:
--

 Summary: Myfaces parses commented code from xhtml and throws 
property not found exception
 Key: MYFACES-4157
 URL: https://issues.apache.org/jira/browse/MYFACES-4157
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.0-beta
Reporter: Dora Rajappan
Priority: Minor


Myfaces parses commented code from xhtml and throws property not found 
exception.
Myfaces should ignore commented code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.

2017-09-21 Thread Dora Rajappan (JIRA)

Dora Rajappan created MYFACES-4156:
--

 Summary: Myface is not showing the FacesMessage after validation 
when ValidatorException is thown.
 Key: MYFACES-4156
 URL: https://issues.apache.org/jira/browse/MYFACES-4156
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.0-beta
Reporter: Dora Rajappan


Myfaces 2.3 is not showing the FacesMessage after validation when 
ValidatorException is thrown. Same works with mojarra 2.2.

if (param.length() > 32) {
  FacesMessage msg = new FacesMessage("Username should 
not exceed 32");
  
  throw new ValidatorException(msg);
  }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4153) h:selectOneRadio when rendered inside h:panelGroup which is right aligned stands out from the group


[ 
https://issues.apache.org/jira/browse/MYFACES-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170015#comment-16170015
 ] 

Dora Rajappan edited comment on MYFACES-4153 at 9/18/17 2:03 PM:
-

I will provide the application. Its huge with ejbs etc.. So I have to find out 
how i can give that to you.
I am new to  rendering to quickly tweak a solution.:)


was (Author: dorarajappan):
I will provide the application. Its huge with ejbs etc.. So I have to find out 
how i can give that to you.
I am new to  rendering to quickly tweak a solution.

> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group
> ---
>
> Key: MYFACES-4153
> URL: https://issues.apache.org/jira/browse/MYFACES-4153
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>Priority: Minor
>
> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group towards the left since it gets rendered as html 
> table. This is same behaviour for mojarra 2.2 also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4153) h:selectOneRadio when rendered inside h:panelGroup which is right aligned stands out from the group


[ 
https://issues.apache.org/jira/browse/MYFACES-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170015#comment-16170015
 ] 

Dora Rajappan commented on MYFACES-4153:


I will provide the application. Its huge with ejbs etc.. So I have to find out 
how i can give that to you.
I am new to  rendering to quickly tweak a solution.

> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group
> ---
>
> Key: MYFACES-4153
> URL: https://issues.apache.org/jira/browse/MYFACES-4153
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>Priority: Minor
>
> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group towards the left since it gets rendered as html 
> table. This is same behaviour for mojarra 2.2 also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYFACES-4155) For inputFile upload when multipart form is submitted the actionListener is not able to get the file.getSubmittedFileName()

Dora Rajappan created MYFACES-4155:
--

 Summary: For inputFile upload when multipart form is submitted the 
actionListener is not able to get the file.getSubmittedFileName() 
 Key: MYFACES-4155
 URL: https://issues.apache.org/jira/browse/MYFACES-4155
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Dora Rajappan


For inputFile upload when multipart form is submitted the actionListener is not 
able to get the file.getSubmittedFileName() . It throws below exception with 
myfaces while its passed with mojarra.
Class org.apache.myfaces.shared.renderkit.html.util.HttpPartWrapper can not 
access a member of class org.apache.catalina.fileupload.PartItem with modifiers 
"public"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
at 
java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
at 
java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
at java.lang.reflect.Method.invoke(Method.java:491)
at 
org.apache.myfaces.shared.renderkit.html.util.HttpPartWrapper.getSubmittedFileName(HttpPartWrapper.java:96)
at UserBean.save(UserBean.java:595)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly


[ 
https://issues.apache.org/jira/browse/MYFACES-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169963#comment-16169963
 ] 

Dora Rajappan commented on MYFACES-4154:


Mojarra also has same behaviour . Chrome shows  the previous page name while 
its at a  current page.

> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>    Reporter: Dora Rajappan
>Priority: Minor
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

2017-09-14 Thread Dora Rajappan (JIRA)

Dora Rajappan created MYFACES-4154:
--

 Summary: The browser (chrome) always show the previous page name 
while its on the current page rendered properly
 Key: MYFACES-4154
 URL: https://issues.apache.org/jira/browse/MYFACES-4154
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.0-beta
Reporter: Dora Rajappan
Priority: Minor


The browser (chrome) always show the previous page name while its on the 
current page rendered properly . This bug is already logged in jira not sure of 
the bug id. Not sure its browser problem  or jsf. Not checked this with mojarra 
also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYFACES-4153) h:selectOneRadio when rendered inside h:panelGroup which is right aligned stands out from the group

2017-09-14 Thread Dora Rajappan (JIRA)

Dora Rajappan created MYFACES-4153:
--

 Summary: h:selectOneRadio when rendered inside h:panelGroup which 
is right aligned stands out from the group
 Key: MYFACES-4153
 URL: https://issues.apache.org/jira/browse/MYFACES-4153
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.3.0-beta
Reporter: Dora Rajappan
Priority: Minor


h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
stands out from the group towards the left since it gets rendered as html 
table. This is same behaviour for mojarra 2.2 also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

2017-08-17 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130165#comment-16130165
 ] 

Dora Rajappan commented on MYFACES-4131:


Thanks Eduardo for committing the patch.

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Fix For: 2.3.0
>
> Attachments: MYFACES-4131-WITH-TEST.patch
>
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

2017-08-07 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116456#comment-16116456
 ] 

Dora Rajappan commented on MYFACES-4131:


If no one has objection I like to commit this patch.

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: MYFACES-4131.patch, MYFACES-4131-WITH-TEST.patch
>
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

2017-08-07 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116162#comment-16116162
 ] 

Dora Rajappan commented on MYFACES-4131:


One difference I notice while implemeting this is if offset + size is used with 
UI repeat it.(offset 0, size 10). It will print 0..9. While begin + end is used 
with UIRepeat (begin 0, end 9 )It will print 0..9. (According to Paul). So 
begin end prints including begin and  end. 

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: MYFACES-4131.patch
>
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

2017-08-07 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116156#comment-16116156
 ] 

Dora Rajappan commented on MYFACES-4131:


Please read this .https://github.com/javaee/javaserverfaces-spec/issues/1102.  
Here it mentions the offset is just an overriding alias for begin. 
They are same but begin is more meaningfully matching end attribute..

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: MYFACES-4131.patch
>
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

2017-08-04 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114244#comment-16114244
 ] 

Dora Rajappan commented on MYFACES-4131:


Can I commit this in 2.3.x?

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: MYFACES-4131.patch
>
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

2017-08-03 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112730#comment-16112730
 ] 

Dora Rajappan commented on MYFACES-4131:


This feature is not implemented in myfaces. Im working out a patch.

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4129) When @FacesConfig annotation is used in a CDI bean, implicit EL objects don't work

2017-07-31 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107342#comment-16107342
 ] 

Dora Rajappan commented on MYFACES-4129:


Applied patch and built 2.3.0  , deployed the war and tested this with pluto 
3.0.0. Application scope is fine.

> When @FacesConfig annotation is used in a CDI bean, implicit EL objects don't 
> work
> --
>
> Key: MYFACES-4129
> URL: https://issues.apache.org/jira/browse/MYFACES-4129
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
> Attachments: ImplicitELObjects.war, MYFACES-4129.patch
>
>
> When the @javax.faces.annotation.FacesConfig annotation is used in a CDI 
> bean, the implicit EL Objects from JSF 2.3 spec section 5.9.2 don't work. 
> This is because when that FacesConfig annotation is in a bean we remove the 
> implicit EL resolver from the chain so we don't have any mechanism for CDI to 
> do the resolution of the implicit objects.
> Tested this on Mojarra and it works fine, with or without @FacesConfig 
> annotation.
> A sample app is provided. It can be deployed on tomcat:
> 1) Drive a request to: http://localhost:8080/ImplicitELObjects/index.jsf
> 2) You should see that Application: ApplicationScope: and Component: are 
> empty since they cannot be resolved



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

2017-07-31 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107287#comment-16107287
 ] 

Dora Rajappan commented on MYFACES-4127:


Myfaces CDI integration to route the call via 
DefaultContextualInstanceStrategy.getIfExists rather than via 
DefaultContextualInstanceStrategy.get to show the ContextNotActiveException. 
Throwing ContextNotActiveException from FlowHandlerImpl (public Flow 
getCurrentFlow(FacesContext context)) when window is null fails lifecycle 
execute testcase. Hence not an option.

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Priority: Minor
> Attachments: ConfigItems.java
>
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map<Object, Object>] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

2017-07-28 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104993#comment-16104993
 ] 

Dora Rajappan commented on MYFACES-4127:


If the  
FacesContext.getCurrentInstance().getApplication().getFlowHandler().getCurrentFlowScope()
 returns null for various reasons (includes invalid declarations such as 
postconstruct method in which case session will be null, or when its not inside 
a flow window will be null ); cdi throws the said exception. How to notify CDI 
whats the reason for the nulls will solve the problem. Need to throw 
appropriate exceptions from getCurrentFlowScope method so cdi can capture it 
show meaningful exception to the user.

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Priority: Minor
> Attachments: ConfigItems.java
>
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map<Object, Object>] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Migrate all MyFaces projects to Git

2017-07-28 Thread Dora Rajappan

mojarra download url of github.com is also mirror and it actually goes to 
java.net 
domain.https://maven.java.net/content/repositories/releases/org/glassfish/javax.faces/2.3.2/


On Friday, July 28, 2017, 2:22:03 PM GMT+5:30, Dora Rajappan 
<dorarajap...@yahoo.com> wrote:

Hi ,
 Thanks for the information on Git hub for apache. I found mojarra latest 
downloads in github.com and understand the domain is a trusted site from this 
discussion. https://github.com/javaserverfaces/mojarra/releases/tag/2.3.2.    
Nice to know myfaces projects are going to apache git. I can find the myfaces 
mirrors already in github.com!
Thanks & Regards,Dora Rajappan,9986201824.


On Thursday, July 27, 2017, 9:03:55 PM GMT+5:30, Bernd Bohmann 
<bernd.bohm...@googlemail.com> wrote:

Hello Dora
this is not possible for apache projects
see: https://git-wip-us.apache.org

and
https://www.apache.org/dev/writable-git

but there are readonly mirrors at https://github.com/apache
Regards
Bernd
On Thu, Jul 27, 2017 at 4:10 PM, Dora Rajappan <dorarajap...@yahoo.com> wrote:

Is it github.com where you are going to migrate myfaces to?

On Thursday, July 27, 2017, 7:06:06 PM GMT+5:30, Bernd Bohmann 
<bernd.bohm...@googlemail.com> wrote:

for Trinidad as well
On Thu, Jul 27, 2017 at 2:29 PM, Udo Schnurpfeil <lof...@apache.org> wrote:

Hi,

for Tobago I think, we can do it now!

Regards,

Udo

Am 27.07.17 um 13:03 schrieb Bernd Bohmann:
> Ok
>
> we have some agreement about moving to git.
> Now we should define some time line.
> Any suggestions from the active subprojects?
>
> Something like
> 'I would like to move to git after blah blah release'
> 'I would like to move now'
> 'I would like to move in 2 weeks'
> or whatever
>
> I can support the migration to git.
>
> Regards
>
> Bernd
>
>
>
>
> On Thu, Apr 20, 2017 at 5:16 PM, Kito Mann <kito.m...@virtua.com
> <mailto:kito.m...@virtua.com>> wrote:
>
>     Ah, this may be why it's worked for me -- smaller projects with
>     defined release cycles.
>
>     Anyway, I never meant to imply that git == git flow. We will need
>     some sort of process, though, and the DeltaSpike one seems like a
>     good place to start.
>
>     ___
>
>     Kito D. Mann | @kito99 | Author, JSF in Action
>     Web Components, Polymer, JSF, PrimeFaces, Java EE training and
>     consulting
>     Virtua, Inc. | virtua.tech
>     JSFCentral.com | @jsfcentral | knowesis.io <http://knowesis.io> -
>     fresh Web Components info
>     +1 203-998-0403 <tel:(203)%20998-0403>
>
>     * See me speak at the ng-conf April 5th-8th: http://bit.ly/2mw7HBj
>     <http://bit.ly/2kr0fWI>
>     * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com
>
>
>     On Thu, Apr 20, 2017 at 8:02 AM, Mark Struberg <strub...@yahoo.de
>     <mailto:strub...@yahoo.de>> wrote:
>
>         gitflow is pure pita ;)
>         It basically only works for companies where you have a single
>         manager who decides what goes in and what not.
>
>         But GIT != gitflow. gitflow has nothing to do with the GIT scm
>         itself, but is just a fancy name for a development process with
>         an explicit build-branch and a build-master.
>
>         +0 on moving to GIT.
>         SVN works good enough imo, but GIT ofc also would work.
>
>         LIeGrue,
>         strub
>
>         > Am 19.04.2017 um 12:57 schrieb Kito Mann <kito.m...@virtua.com
>         <mailto:kito.m...@virtua.com> > :
>         >
>         > +1
>         >
>         > Wha's wrong with GitFlow?
>         >
>         > ___
>         >
>         > Kito D. Mann | @kito99 | Author, JSF in Action
>         > Web Components, Polymer, JSF, PrimeFaces, Java EE training and
>         consulting
>         > Virtua, Inc. | virtua.tech
>         > JSFCentral.com | @jsfcentral | knowesis.io
>         <http://knowesis.io> - fresh Web Components info
>         > +1 203-998-0403 <tel:%2B1%20203-998-0403>
>         >
>         > * See me speak at the ng-conf April 5th-8th: http://bit.ly/2mw7HBj
>         > * Listen to the Enterprise Java Newscast:
>         http://enterprisejavanews.com
>         >
>         >
>         > On Wed, Apr 19, 2017 at 4:29 AM, Bernd Bohmann
>         <bernd.bohm...@googlemail.com
>         <mailto:bernd.bohmann@ googlemail.com>> wrote:
>         > Hello
>         >
>         > I think the changes will be not so complicated. The deltaspike
>         pom looks nice :-)
>         > If someone talks about git-flow process i'm out.
>         >
>         > Regards
>

Re: Migrate all MyFaces projects to Git

2017-07-28 Thread Dora Rajappan

Hi ,
 Thanks for the information on Git hub for apache. I found mojarra latest 
downloads in github.com and understand the domain is a trusted site from this 
discussion. https://github.com/javaserverfaces/mojarra/releases/tag/2.3.2.    
Nice to know myfaces projects are going to apache git. I can find the myfaces 
mirrors already in github.com!
Thanks & Regards,Dora Rajappan,9986201824.


On Thursday, July 27, 2017, 9:03:55 PM GMT+5:30, Bernd Bohmann 
<bernd.bohm...@googlemail.com> wrote:

Hello Dora
this is not possible for apache projects
see: https://git-wip-us.apache.org

and
https://www.apache.org/dev/writable-git

but there are readonly mirrors at https://github.com/apache
Regards
Bernd
On Thu, Jul 27, 2017 at 4:10 PM, Dora Rajappan <dorarajap...@yahoo.com> wrote:

Is it github.com where you are going to migrate myfaces to?

On Thursday, July 27, 2017, 7:06:06 PM GMT+5:30, Bernd Bohmann 
<bernd.bohm...@googlemail.com> wrote:

for Trinidad as well
On Thu, Jul 27, 2017 at 2:29 PM, Udo Schnurpfeil <lof...@apache.org> wrote:

Hi,

for Tobago I think, we can do it now!

Regards,

Udo

Am 27.07.17 um 13:03 schrieb Bernd Bohmann:
> Ok
>
> we have some agreement about moving to git.
> Now we should define some time line.
> Any suggestions from the active subprojects?
>
> Something like
> 'I would like to move to git after blah blah release'
> 'I would like to move now'
> 'I would like to move in 2 weeks'
> or whatever
>
> I can support the migration to git.
>
> Regards
>
> Bernd
>
>
>
>
> On Thu, Apr 20, 2017 at 5:16 PM, Kito Mann <kito.m...@virtua.com
> <mailto:kito.m...@virtua.com>> wrote:
>
>     Ah, this may be why it's worked for me -- smaller projects with
>     defined release cycles.
>
>     Anyway, I never meant to imply that git == git flow. We will need
>     some sort of process, though, and the DeltaSpike one seems like a
>     good place to start.
>
>     ___
>
>     Kito D. Mann | @kito99 | Author, JSF in Action
>     Web Components, Polymer, JSF, PrimeFaces, Java EE training and
>     consulting
>     Virtua, Inc. | virtua.tech
>     JSFCentral.com | @jsfcentral | knowesis.io <http://knowesis.io> -
>     fresh Web Components info
>     +1 203-998-0403 <tel:(203)%20998-0403>
>
>     * See me speak at the ng-conf April 5th-8th: http://bit.ly/2mw7HBj
>     <http://bit.ly/2kr0fWI>
>     * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com
>
>
>     On Thu, Apr 20, 2017 at 8:02 AM, Mark Struberg <strub...@yahoo.de
>     <mailto:strub...@yahoo.de>> wrote:
>
>         gitflow is pure pita ;)
>         It basically only works for companies where you have a single
>         manager who decides what goes in and what not.
>
>         But GIT != gitflow. gitflow has nothing to do with the GIT scm
>         itself, but is just a fancy name for a development process with
>         an explicit build-branch and a build-master.
>
>         +0 on moving to GIT.
>         SVN works good enough imo, but GIT ofc also would work.
>
>         LIeGrue,
>         strub
>
>         > Am 19.04.2017 um 12:57 schrieb Kito Mann <kito.m...@virtua.com
>         <mailto:kito.m...@virtua.com> > :
>         >
>         > +1
>         >
>         > Wha's wrong with GitFlow?
>         >
>         > ___
>         >
>         > Kito D. Mann | @kito99 | Author, JSF in Action
>         > Web Components, Polymer, JSF, PrimeFaces, Java EE training and
>         consulting
>         > Virtua, Inc. | virtua.tech
>         > JSFCentral.com | @jsfcentral | knowesis.io
>         <http://knowesis.io> - fresh Web Components info
>         > +1 203-998-0403 <tel:%2B1%20203-998-0403>
>         >
>         > * See me speak at the ng-conf April 5th-8th: http://bit.ly/2mw7HBj
>         > * Listen to the Enterprise Java Newscast:
>         http://enterprisejavanews.com
>         >
>         >
>         > On Wed, Apr 19, 2017 at 4:29 AM, Bernd Bohmann
>         <bernd.bohm...@googlemail.com
>         <mailto:bernd.bohmann@ googlemail.com>> wrote:
>         > Hello
>         >
>         > I think the changes will be not so complicated. The deltaspike
>         pom looks nice :-)
>         > If someone talks about git-flow process i'm out.
>         >
>         > Regards
>         >
>         > Bernd
>         >
>         > On Wed, Apr 19, 2017 at 12:28 AM, Leonardo Uribe
>         <lu4...@gmail.com <mailto:lu4...@gmail.com>> wrote:
>         > +1
>         >
>         > Change the release process is a pain, but I a

Re: Migrate all MyFaces projects to Git

2017-07-27 Thread Dora Rajappan

Is it github.com where you are going to migrate myfaces to?

On Thursday, July 27, 2017, 7:06:06 PM GMT+5:30, Bernd Bohmann 
 wrote:

for Trinidad as well
On Thu, Jul 27, 2017 at 2:29 PM, Udo Schnurpfeil  wrote:

Hi,

for Tobago I think, we can do it now!

Regards,

Udo

Am 27.07.17 um 13:03 schrieb Bernd Bohmann:
> Ok
>
> we have some agreement about moving to git.
> Now we should define some time line.
> Any suggestions from the active subprojects?
>
> Something like
> 'I would like to move to git after blah blah release'
> 'I would like to move now'
> 'I would like to move in 2 weeks'
> or whatever
>
> I can support the migration to git.
>
> Regards
>
> Bernd
>
>
>
>
> On Thu, Apr 20, 2017 at 5:16 PM, Kito Mann  > wrote:
>
>     Ah, this may be why it's worked for me -- smaller projects with
>     defined release cycles.
>
>     Anyway, I never meant to imply that git == git flow. We will need
>     some sort of process, though, and the DeltaSpike one seems like a
>     good place to start.
>
>     ___
>
>     Kito D. Mann | @kito99 | Author, JSF in Action
>     Web Components, Polymer, JSF, PrimeFaces, Java EE training and
>     consulting
>     Virtua, Inc. | virtua.tech
>     JSFCentral.com | @jsfcentral | knowesis.io  -
>     fresh Web Components info
>     +1 203-998-0403 
>
>     * See me speak at the ng-conf April 5th-8th: http://bit.ly/2mw7HBj
>     
>     * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com
>
>
>     On Thu, Apr 20, 2017 at 8:02 AM, Mark Struberg      > wrote:
>
>         gitflow is pure pita ;)
>         It basically only works for companies where you have a single
>         manager who decides what goes in and what not.
>
>         But GIT != gitflow. gitflow has nothing to do with the GIT scm
>         itself, but is just a fancy name for a development process with
>         an explicit build-branch and a build-master.
>
>         +0 on moving to GIT.
>         SVN works good enough imo, but GIT ofc also would work.
>
>         LIeGrue,
>         strub
>
>         > Am 19.04.2017 um 12:57 schrieb Kito Mann          > :
>         >
>         > +1
>         >
>         > Wha's wrong with GitFlow?
>         >
>         > ___
>         >
>         > Kito D. Mann | @kito99 | Author, JSF in Action
>         > Web Components, Polymer, JSF, PrimeFaces, Java EE training and
>         consulting
>         > Virtua, Inc. | virtua.tech
>         > JSFCentral.com | @jsfcentral | knowesis.io
>          - fresh Web Components info
>         > +1 203-998-0403 
>         >
>         > * See me speak at the ng-conf April 5th-8th: http://bit.ly/2mw7HBj
>         > * Listen to the Enterprise Java Newscast:
>         http://enterprisejavanews.com
>         >
>         >
>         > On Wed, Apr 19, 2017 at 4:29 AM, Bernd Bohmann
>                  > wrote:
>         > Hello
>         >
>         > I think the changes will be not so complicated. The deltaspike
>         pom looks nice :-)
>         > If someone talks about git-flow process i'm out.
>         >
>         > Regards
>         >
>         > Bernd
>         >
>         > On Wed, Apr 19, 2017 at 12:28 AM, Leonardo Uribe
>         > wrote:
>         > +1
>         >
>         > Change the release process is a pain, but I agree there are
>         some benefits moving to git.
>         >
>         > But when I see here:
>         >
>         > https://github.com/apache/ myfaces
>         
>         >
>         > It says:
>         >
>         > mirrored from git://git.apache.org/myfaces. git
>         
>         >
>         > But I have never checked where that file is or how to change it.
>         >
>         > Looking in deltaspike, the svn repo only has the site (for the
>         CMS) and the source code lives on git. If that so, we still need
>         the svn, so I agree it is a good idea to move only some
>         subprojects to git.
>         >
>         > regards,
>         >
>         > Leonardo Uribe
>         >
>         >
>         >       Virus-free. www.avast.com 
>         >
>         > 2017-04-17 11:40 GMT-05:00 Grant Smith          > :
>         > +1
>         >
>         > Couldn't agree more.
>         >
>         > Grant Smith - V.P. Information Technology
>         > Marathon Computer Systems, LLC.
>         >
>         > On Thu, Apr 13, 2017 at 2:39 AM, Bernd Bohmann
>

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

2017-07-27 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103105#comment-16103105
 ] 

Dora Rajappan commented on MYFACES-4127:


Could you please put and war and source for this scenario. I am getting the 
same exception if I made the bean to @Applicationscoped also!!!

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Priority: Minor
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map<Object, Object>] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

2017-07-27 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103055#comment-16103055
 ] 

Dora Rajappan commented on MYFACES-4127:


Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
Cannot return null from a non-dependent producer method:  Producer for Producer 
Method [Map<Object, Object>] with qualifiers [@FlowMap @Any] declared as 
[[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped public 
org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
declared on Managed Bean [class 
org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
[@Any @Default]
at 
org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
at 
org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:184)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:94)
at 
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98)
at 
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
at 
org.jboss.weld.proxies.Map$1822649053$Proxy$_$$_WeldClientProxy.isEmpty(Unknown 
Source)
at guess.ConfigItems.postConstruct(ConfigItems.java:29)
Got the above exception for the said scenario. Trying to resolve.

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Priority: Minor
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map<Object, Object>] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4126) Implicit objects flowScope and view cannot be injected using CDI


[ 
https://issues.apache.org/jira/browse/MYFACES-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16098402#comment-16098402
 ] 

Dora Rajappan commented on MYFACES-4126:


Thats great then. It might some interfacing classes in core to cdi. I applied 
this patch to 2.3.x and built it and all tests passed.

> Implicit objects flowScope and view cannot be injected using CDI
> 
>
> Key: MYFACES-4126
> URL: https://issues.apache.org/jira/browse/MYFACES-4126
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
> Attachments: MYFACES-4126.patch
>
>
> The implicit objects {code:java}#{flowScope}{code} annotated @FlowMap and 
> {code:java}#{view}{code} which results in UIViewRoot cannot be injected using 
> CDI.
> For example:
> @Inject
> private UIViewRoot viewRoot;
> @Inject
> @FlowMap
> private Map<Object, Object> flowMap;
> The above results in the following errors respectively:
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type UIViewRoot with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.viewRoot
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type Map<Object, Object> with qualifiers @FlowMap
>   at injection point [BackedAnnotatedField] @Inject @FlowMap private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.flowMap
> A patch is provided.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4126) Implicit objects flowScope and view cannot be injected using CDI


[ 
https://issues.apache.org/jira/browse/MYFACES-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16098290#comment-16098290
 ] 

Dora Rajappan commented on MYFACES-4126:


True. I referred to 2.2 set up in my eclipse. Its in current 2.3.x. Why was 
this moved form codi to core? 

> Implicit objects flowScope and view cannot be injected using CDI
> 
>
> Key: MYFACES-4126
> URL: https://issues.apache.org/jira/browse/MYFACES-4126
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
> Attachments: MYFACES-4126.patch
>
>
> The implicit objects {code:java}#{flowScope}{code} annotated @FlowMap and 
> {code:java}#{view}{code} which results in UIViewRoot cannot be injected using 
> CDI.
> For example:
> @Inject
> private UIViewRoot viewRoot;
> @Inject
> @FlowMap
> private Map<Object, Object> flowMap;
> The above results in the following errors respectively:
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type UIViewRoot with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.viewRoot
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type Map<Object, Object> with qualifiers @FlowMap
>   at injection point [BackedAnnotatedField] @Inject @FlowMap private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.flowMap
> A patch is provided.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean


[ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16098220#comment-16098220
 ] 

Dora Rajappan commented on MYFACES-4127:


This bug also should be opened in in myfaces extensions codi? Cant find 
ApplicationScopeObjectProducer.java in myfaces core.

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Priority: Minor
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map<Object, Object>] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4126) Implicit objects flowScope and view cannot be injected using CDI


[ 
https://issues.apache.org/jira/browse/MYFACES-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16098215#comment-16098215
 ] 

Dora Rajappan commented on MYFACES-4126:


This bug should be opened in extensions codi? I cannot find both 
ApplicationScopeObjectProducer.java, FacesScopeObjectProducer.java in myfaces 
core.

> Implicit objects flowScope and view cannot be injected using CDI
> 
>
> Key: MYFACES-4126
> URL: https://issues.apache.org/jira/browse/MYFACES-4126
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
> Attachments: MYFACES-4126.patch
>
>
> The implicit objects {code:java}#{flowScope}{code} annotated @FlowMap and 
> {code:java}#{view}{code} which results in UIViewRoot cannot be injected using 
> CDI.
> For example:
> @Inject
> private UIViewRoot viewRoot;
> @Inject
> @FlowMap
> private Map<Object, Object> flowMap;
> The above results in the following errors respectively:
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type UIViewRoot with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.viewRoot
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type Map<Object, Object> with qualifiers @FlowMap
>   at injection point [BackedAnnotatedField] @Inject @FlowMap private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.flowMap
> A patch is provided.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4125) Response committed too early due to flush from StateWriter

2017-07-21 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096219#comment-16096219
 ] 

Dora Rajappan commented on MYFACES-4125:


The same State Writer flush is carried over to 2.3.x.

> Response committed too early due to flush from StateWriter
> --
>
> Key: MYFACES-4125
> URL: https://issues.apache.org/jira/browse/MYFACES-4125
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12
>Reporter: Eduardo Breijo
> Attachments: server.log, StateWriter.war
>
>
> We've found a problem where it seems that MyFaces is flushing output too 
> early in the RENDER_RESPONSE PHASE. As a result the response is committed 
> before we have a chance to handle an error in that phase. 
> This is because the renderView method from FaceletViewDeclarationLanguage 
> calls writer.endDocument() which ends up calling the flush() method from 
> StateWriter. This commit behavior is different between 2.0 and 2.2.  It looks 
> like a flush() was empty on 2.0, and now a call was added, which causes the 
> issue we are seeing.
> Here's a sample app:
> 1) Drive a request: localhost:9080/StateWriter/index.xhtml
> 2) You should be able to see in the logs that response was committed, so 
> redirect to error.xhtml cannot be performed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4125) Response committed too early due to flush from StateWriter

2017-07-21 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096214#comment-16096214
 ] 

Dora Rajappan commented on MYFACES-4125:


I commented the flush. Ran build. All tests passed. Deployed and ran the test 
it works like mojarra.

StateWriter
 public void flush() throws IOException
{
   /* if (!this.writtenState)
{
this.out.flush();
}*/
}

Is this the solution?

> Response committed too early due to flush from StateWriter
> --
>
> Key: MYFACES-4125
> URL: https://issues.apache.org/jira/browse/MYFACES-4125
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12
>Reporter: Eduardo Breijo
> Attachments: server.log, StateWriter.war
>
>
> We've found a problem where it seems that MyFaces is flushing output too 
> early in the RENDER_RESPONSE PHASE. As a result the response is committed 
> before we have a chance to handle an error in that phase. 
> This is because the renderView method from FaceletViewDeclarationLanguage 
> calls writer.endDocument() which ends up calling the flush() method from 
> StateWriter. This commit behavior is different between 2.0 and 2.2.  It looks 
> like a flush() was empty on 2.0, and now a call was added, which causes the 
> issue we are seeing.
> Here's a sample app:
> 1) Drive a request: localhost:9080/StateWriter/index.xhtml
> 2) You should be able to see in the logs that response was committed, so 
> redirect to error.xhtml cannot be performed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4125) Response committed too early due to flush from StateWriter

2017-07-21 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096116#comment-16096116
 ] 

Dora Rajappan commented on MYFACES-4125:


True in myfaces 2.2  drive request is not going to the error page and logs got 
in console given below.
java.lang.RuntimeException: after Render Response.
- Resonse commited = true.
Trying to resolve. Pluto3/,myfaces 2.2 StateWrite app is deployed and simulated 
this bug.
Pluto3 lib requires commons-beanutils-1.9.2, commons-collections-3.2.2, 
commons-digester-2.1,commons-logging-1.1.1 in its lib to deploy StateWriter 
with myfaces 2.2 jars.

> Response committed too early due to flush from StateWriter
> --
>
> Key: MYFACES-4125
> URL: https://issues.apache.org/jira/browse/MYFACES-4125
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12
>Reporter: Eduardo Breijo
> Attachments: server.log, StateWriter.war
>
>
> We've found a problem where it seems that MyFaces is flushing output too 
> early in the RENDER_RESPONSE PHASE. As a result the response is committed 
> before we have a chance to handle an error in that phase. 
> This is because the renderView method from FaceletViewDeclarationLanguage 
> calls writer.endDocument() which ends up calling the flush() method from 
> StateWriter. This commit behavior is different between 2.0 and 2.2.  It looks 
> like a flush() was empty on 2.0, and now a call was added, which causes the 
> issue we are seeing.
> Here's a sample app:
> 1) Drive a request: localhost:9080/StateWriter/index.xhtml
> 2) You should be able to see in the logs that response was committed, so 
> redirect to error.xhtml cannot be performed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4125) Response committed too early due to flush from StateWriter

2017-07-20 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094770#comment-16094770
 ] 

Dora Rajappan commented on MYFACES-4125:


This is not getting deployed in pluto 2.0. Trying with pluto 3.0/myfaces 2.2. 
Its deployed and throws exception in mojarra2.2 with glassfish. Is mojarra 
behaviour correct? http://localhost:8080/StateWriter/error.xhtml.

 This page isn’t working

localhost redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS

> Response committed too early due to flush from StateWriter
> --
>
> Key: MYFACES-4125
> URL: https://issues.apache.org/jira/browse/MYFACES-4125
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12
>Reporter: Eduardo Breijo
> Attachments: server.log, StateWriter.war
>
>
> We've found a problem where it seems that MyFaces is flushing output too 
> early in the RENDER_RESPONSE PHASE. As a result the response is committed 
> before we have a chance to handle an error in that phase. 
> This is because the renderView method from FaceletViewDeclarationLanguage 
> calls writer.endDocument() which ends up calling the flush() method from 
> StateWriter. This commit behavior is different between 2.0 and 2.2.  It looks 
> like a flush() was empty on 2.0, and now a call was added, which causes the 
> issue we are seeing.
> Here's a sample app:
> 1) Drive a request: localhost:9080/StateWriter/index.xhtml
> 2) You should be able to see in the logs that response was committed, so 
> redirect to error.xhtml cannot be performed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4114) Add disabled attribute to h:button

2017-07-20 Thread Dora Rajappan (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094554#comment-16094554
 ] 

Dora Rajappan commented on MYFACES-4114:


This feature is in myfaces 2.3.x branch. I tested it today from portlet bridge 
also and works fine . Please close this.

> Add disabled attribute to h:button
> --
>
> Key: MYFACES-4114
> URL: https://issues.apache.org/jira/browse/MYFACES-4114
> Project: MyFaces Core
>  Issue Type: New Feature
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Attachments: myfaces-4114.patch
>
>
> Implemented, but not in HtmlOutcomeTargetButton



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Anonymous checkout of core

2017-07-19 Thread Dora Rajappan

Hi Volker,
 Thank you very much...
 I substituted x because normally its numbers and the latest release version 
was also 2.3.0.
 The repo browser is so easy... I am able to checkout now from 2.3.x. But trunk 
should point to 2.3.x.
 Else they have to contact the mail list instead of the myfaces core site.
Thanks & Regards,Dora Rajappan.

On Wednesday, July 19, 2017, 5:04:14 PM GMT+5:30, Volker Weber 
<v.we...@inexso.de> wrote:

Hi Dora,

you can browse the repository in the browser to find the valid urls, e.g 
https://svn.apache.org/repos/asf/myfaces/core/branches/

To check out the 2.3 development branch this is 2.3.x: 
https://svn.apache.org/repos/asf/myfaces/core/branches/2.3.x/

regards,

  Volker

2017-07-19 9:25 GMT+02:00 Dora Rajappan <dorarajap...@yahoo.com>:

Thank you very much Dennis. 
Trunk should point to latest source.Whats the exact version of  2.3 so I can 
checkout core. I tried checkout of 2.3.0-beta and its not existing. svn 
checkout https://svn.apache.org/repos/ asf/myfaces/core/branches/2.3. 0-beta.
Thanks & Regards,Dora Rajappan,

On Wednesday, July 19, 2017, 12:13:33 PM GMT+5:30, Dennis Kieselhorst 
<d...@apache.org> wrote:

> It should be 2.3 right?

Trunk still points to 2.2.x, for 2.3.x use: https://svn.apache.org/repos/ 
asf/myfaces/core/branches/2.3. x/

Regards
Dennis




-- 
inexso - information exchange solutions GmbH
Ofener Straße 30 | 26121 Oldenburg
www.inexso.de

Re: Anonymous checkout of core

2017-07-19 Thread Dora Rajappan

Thank you very much Dennis. 
Trunk should point to latest source.Whats the exact version of  2.3 so I can 
checkout core. I tried checkout of 2.3.0-beta and its not existing. svn 
checkout https://svn.apache.org/repos/asf/myfaces/core/branches/2.3.0-beta.
Thanks & Regards,Dora Rajappan,

On Wednesday, July 19, 2017, 12:13:33 PM GMT+5:30, Dennis Kieselhorst 
<d...@apache.org> wrote:

> It should be 2.3 right?

Trunk still points to 2.2.x, for 2.3.x use: 
https://svn.apache.org/repos/asf/myfaces/core/branches/2.3.x/

Regards
Dennis

Anonymous checkout of core

2017-07-18 Thread Dora Rajappan

Hi,
   The anonymous checkout is bringing me 2.2.13 version source or latest 2.3 
source? Cause when I build from anonymous checkout from here (svn checkout 
http://svn.apache.org/repos/asf/myfaces/core/trunk) it builds 
myfaces-impl-2.2.13-SNAPSHOT.jarI submitted the patch for jira issue 4114 based 
on this source. But the anonymous checkout version is confusing. It should be 
2.3 right?
Thanks & Regards,
Dora Rajappan,9986201824.

Re: [jira] [Commented] (MYFACES-3984) Unable to add an ELResolver programmatically when application includes flows defined with xml

2015-05-05 Thread Dora Rajappan

How are you adding the ELResolver programmatically before first request? Using
servlet init? You cant access the facesContext in your Servlet via
ServletContext because myface destroys the first facesContext used by
StartupServletContextListener
(_facesInitializer.destroyStartupFacesContext(facesContext);)

On Thursday, April 30, 2015 5:40 PM, Dora Rajappan
dorarajap...@yahoo.com wrote:

You can add ELResolver via CDI . Just name and scope the bean and use the name
directly in your xhtml. Its not registered with Application interface. So the
sorting caching of the configured EL Resolver is unaffected. When you try to
add ELResolver programmatically before first request happens its not behaving
correctly. And you have suggested two solutions.

On Wednesday, April 29, 2015 10:11 PM, Mike Kienenberger (JIRA)
dev@myfaces.apache.org wrote:

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

Mike Kienenberger commented on MYFACES-3984:

Can you discuss this issue and the two possible solutions on the
dev@myfaces.apache.org mailing list?
Perhaps you could also provide a patch demonstrating which approach you believe
works best.

Unable to add an ELResolver programmatically when application includes flows
defined with xml
-

Key: MYFACES-3984
URL: https://issues.apache.org/jira/browse/MYFACES-3984
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.8
Reporter: Sami Korhonen

Current implementation of Application interfaces caches CompositeELResolver
internally. According to Application interface definition ELResolvers may be
added until application receives first request. This means that, if
ELResolver is retrieved before first request, Application implementation does
not behave correctly.
There are several ways to resolve this issue. One solution is to create a
lazy initializing ELResolver when Application (Impl) is instantiated. This
lazy ELResolver should be initialized on first actual call.
Second possible solution also requires creating ELResolver instance when
Application is instatiated. In this solution you add new ELResolvers after
reading configuration files. In order to support MyFaces specific sorting
feature, you are required to cache and sort entries in another structure
before registering them to Application's ELResolver.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Commented] (MYFACES-3984) Unable to add an ELResolver programmatically when application includes flows defined with xml

2015-04-30 Thread Dora Rajappan

On Wednesday, April 29, 2015 10:11 PM, Mike Kienenberger (JIRA)
dev@myfaces.apache.org wrote:

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

Mike Kienenberger commented on MYFACES-3984:

Can you discuss this issue and the two possible solutions on the
dev@myfaces.apache.org mailing list?
Perhaps you could also provide a patch demonstrating which approach you believe
works best.

Unable to add an ELResolver programmatically when application includes flows
defined with xml
-

Key: MYFACES-3984
URL: https://issues.apache.org/jira/browse/MYFACES-3984
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.8
Reporter: Sami Korhonen

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Fw: Intimation on Bill Amount

2014-07-15 Thread Dora Rajappan

This is how bill is. I can resume some work while I work with lawyer.

 
On Tuesday, July 15, 2014 3:52 AM, TATA DOCOMO ALERT al...@tatadocomo.com 
wrote:
  



Hi,

Thank You for being a part of Tata Docomo family.

This Email alert service keeps you updated on your Outstanding and Bill Due 
Date for your Tata Docomo Service No 9241160737

Your JUL-2014 bill of Rs. 843 is due on 18-JUL-14.

Depending on your convenience, you can choose from a variety of options below, 
to make your payment.

* To make an instant payment please click on the below link:
https://www.billdesk.com/pgmerc/tatadocomo/DOCOMODetails.htm All you need to 
know is your Account Number or Mobile Number and Payment Amount. You can pay by 
credit card (MasterCard, VISA, Diners, AMEX) or through an online bank account 
payment transfer.

* You can view your bill and make payments online through My Account by 
registering for the service at http://www.tatadocomo.com/myaccount.aspx.

* You can also pay through the bill payment slip with your credit card. 
Just mention your credit card (MasterCard, Visa, Diners, and AMEX) details  
payment amount on the Bill Payment Slip (tear-away portion of your bill copy) 
and drop it in any Tata Docomo drop box.

* For more convenient payment options in your city, please visit our 
website www.tatadocomo.com/bill-payment.aspx.

* You can also find out the nearest Payment locations for CASH/ Credit 
Card/ Cheque by sending an SMS CASH/ CHQ/ CC PIN Code to 121 - as the case 
may be - from your Tata Docomo number.This is a free mail service, please 
ignore if already paid

Go Green! We urge you to take a stand on saving our environment and do your 
part.To begin with, all you need to do is stop your paper bill and subscribe to 
EBill.On your subscription you will not only get free itemized bill worth Rs 25 
but also its delivery in your inbox within 3 days.
To stop paper bill and subscribe to EBill - SMS EBILL to 121 or you can also 
log into My Account on our website www.tatadocomo.com and opt for EBill.

For any further assistance, please feel free to contact us via email at 
lis...@tatadocomo.com or you can reach us 24x7 by dialing 121(customer care 
number) from you Tata Docomo number and 1860-266- if you want to reach us 
from any other number.
Photon and Photon 3G customers can get in touch with us on our 24x7 helpline 
number 1800-266-121.

Look forward to hearing from you.


Warm regards,
Team Tata Docomo 

***This is an automated message. Please do not reply***

Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project

2014-05-21 Thread Dora Rajappan

 
*Regarding #{ma:sourceActionURL('renderOptions') : render the URL of the action 
How is the URL rendered? Through the RequestMapping of the method as defined 
with the Bean?
And the attribute, params of the action defined are appended to the URL?
 
For $.post with this URL, when its not appended with the attribute or params, 
execute=@form attribute of ma:defineAction is not used.
Purpose of this attribute out of scope of jQuery post?
 
*autocomplete is transient and hence its not required to update viewstate
 
Script integration via jQuery with action is flowless and awesome!
 
Regards,
Dora Rajappa
 
On Monday, May 19, 2014 9:13 PM, Leonardo Uribe lu4...@gmail.com wrote:
  


Hi

DR How about @ViewAction(/section1, action=exportExcel)

It will not work because you can't change the annotation definition.
In other words, we should make action parameter a reserved one.
Also, the parameter by itself can have a converter or validator or a
EL binding, so you need to define that too. That's why @ViewParam or
something that define the parameter is required.

regards,

Leonardo


2014-05-15 14:30 GMT+02:00 Dora Rajappan dorarajap...@yahoo.com:
 a href=#{ma:getLink('/section1/mypage?action=exportExcel')}Export
 excel/a  can work
 when the definition is
  @ViewAction(/section1/*, action=exportExcel)
 How about
  @ViewAction(/section1, action=exportExcel)
 On Wednesday, May 14, 2014 12:01 AM, Dora Rajappan dorarajap...@yahoo.com
 wrote:
 How will  a href=#{ma:getLink('mypage?action=exportExcel')}Export
 excel/a
 work when ViewAction is not defined as

 @ViewAction(value=/sayhello.xhtml,
                           params= {
                               @ViewParam(name=action,
 expectedValue=exportExcel)
                           })
     public void method3(@ViewParam String param1,
 @ViewParam(someOther) Integer param2)
     {
 but  as @ViewAction(/section1/*, action=exportExcel)
 Is the latter not supported now?

 facelet function getLink for action processing is not a bad idea.
 On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe lu4...@gmail.com wrote:
 Hi

 Ok, I think the idea about @ViewAction and @ViewParam is clear, I have
 implemented a fast prototype and it works well, there is a lot of things we
 can do for improvement, however we should focus the attention in other
 areas so we can give the module a better structure.

 The next thing we need is how to combine javascript with JSF, specifically
 in cases like this:

 input id=search/
 script type=text/javascript
     $('#search').autocomplete({
         source: #{some EL that return a link to an action goes here}
     });
 /script

 The idea is provide an input box and then write some javascript lines to
 make the component an autocomplete box, but the problem is we need to
 provide
 a URL that can be used to retrieve the values to fill the box. In my
 opinion,
 mix EL and javascript is the best in these cases, but things get complex
 quickly when you need to provide parameters and so on. So I would like to
 propose these facelet functions (better with examples):

     a href=#{ma:getLink('mypage?action=exportExcel')}Export excel/a

 and

     ma:defineLink id=mylink
         f:param name=action value=renderMessage/
     /ma:defineLink

     a href=#{ma:getLinkFrom('mylink')}Render url from EL expression/a

 #{ma:getLink(...)} work just like h:link but receives the outcome as
 parameter.
 The function append the request path and the client window id, so the final
 generated link will be something like this:

 http://localhost:8080/myfaces-mvc-examples/sayhello.jsf?id=5jfwid=1di8uhetf9action=exportExcel

 #{ma:getLinkFrom(...)} just inject the link from a component that works just
 like h:link but it is just a wrapper, so the user can customize the
 parameters,
 when the EL function is called, the link is rendered taking the parameters
 in the definition. The outcome by default is the page itself.


 Please note this proposal is something different from the one that suggest
 to
 create the link just pointing to the method in the bean like
 #{ma:getLink('mybean', 'mymethod', params)}. After thinking about it, the
 problem with that approach is the difficulty to do the match between the
 link
 to generate and the method. EL does not consider annotated methods, so it is
 not possible to scan the annotations from the EL unless you do a bypass over
 CDI.

 I think the approach proposed is something simple to understand, and it has
 the advantage that you can isolate the declaration of the link from the
 rendering, so the final javascript code will be easier to read.

 Finally we need something for the POST case, so the idea is append something
 like this:

     form action=#{ma:encodeActionURL()}
           method=post
           enctype=application/x-www-form-urlencoded
         
     /form

 #{ma:encodeActionURL()} do what h:form does for encode the action url. Then,
 it is responsibility of the user to provide the view state and client window
 token

Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project

2014-05-16 Thread Dora Rajappan

a href=#{ma:getLink('/section1/mypage?action=exportExcel')}Export excel/a 
 can work
when the definition is
 @ViewAction(/section1/*, action=exportExcel)
How about
 @ViewAction(/section1, action=exportExcel)
On Wednesday, May 14, 2014 12:01 AM, Dora Rajappan dorarajap...@yahoo.com 
wrote:
  
How will  a href=#{ma:getLink('mypage?action=exportExcel')}Export excel/a
work when ViewAction is not defined as  
 
@ViewAction(value=/sayhello.xhtml,
                          params= {
                               @ViewParam(name=action,
expectedValue=exportExcel)
                          })
    public void method3(@ViewParam String param1,
@ViewParam(someOther) Integer param2)
    {
but  as @ViewAction(/section1/*, action=exportExcel)
Is the latter not supported now?
 
facelet function getLink for action processing is not a bad idea.
On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe lu4...@gmail.com wrote:
  
Hi

Ok, I think the idea about @ViewAction and @ViewParam is clear, I have
implemented a fast prototype and it works well, there is a lot of things we
can do for improvement, however we should focus the attention in other
areas so we can give the module a better structure.

The next thing we need is how to combine javascript with JSF, specifically
in cases like this:

input id=search/
script type=text/javascript
    $('#search').autocomplete({
        source: #{some EL that return a link to an action goes here}
    });
/script

The idea is provide an input box and then write some javascript lines to
make the component an autocomplete box, but the problem is we need to provide
a URL that can be used to retrieve the values to fill the box. In my opinion,
mix EL and javascript is the best in these cases, but things get complex
quickly when
 you need to provide parameters and so on. So I would like to
propose these facelet functions (better with examples):

    a href=#{ma:getLink('mypage?action=exportExcel')}Export excel/a

and

    ma:defineLink id=mylink
        f:param name=action value=renderMessage/
    /ma:defineLink

    a href=#{ma:getLinkFrom('mylink')}Render url from EL expression/a

#{ma:getLink(...)} work just like h:link but receives the outcome as parameter.
The function append the request path and the client window id, so the final
generated link will be something like this:

http://localhost:8080/myfaces-mvc-examples/sayhello.jsf?id=5jfwid=1di8uhetf9action=exportExcel

#{ma:getLinkFrom(...)} just inject the link from a component that works just
like h:link but it is just a wrapper, so the user can customize the parameters,
when the EL function is called, the link is rendered taking the parameters
in the definition. The outcome by default is the page itself.


Please note this proposal is something different from the one that suggest to
create the link just pointing to the method in the bean like
#{ma:getLink('mybean', 'mymethod', params)}. After thinking about it, the
problem with that approach is
 the difficulty to do the match between the link
to generate and the method. EL does not consider annotated methods, so it is
not possible to scan the annotations from the EL unless you do a bypass over
CDI.

I think the approach proposed is something simple to understand, and it has
the advantage that you can isolate the declaration of the link from the
rendering, so the final javascript code will be easier to read.

Finally we need something for the POST case, so the idea is append something
like this:

    form action=#{ma:encodeActionURL()}
          method=post
          enctype=application/x-www-form-urlencoded
       
 
    /form

#{ma:encodeActionURL()} do what h:form does for encode the action url. Then,
it is responsibility of the user to provide the view state and client window
token in the request as data, so the postback can be processed properly.
In this case, the idea is the view scope will be available, but the component
tree state will not be updated when POST goes back to the client, so any
changes on the component tree in the action will be ignored.

JSF does not make any difference between GET and POST, so viewParam will
work just the same. What defines a postback in JSF is if the view state
field is in the request or not. Theoretically, use #{ma:getLink(...)} should
work too, but I think there are different cases.

There is a contradiction in this case. Send a POST, provide the view state
token, do not restore the view but restore the view scope bean. The problem is
after you make changes on the view scope beans you need to save those changes,
and that could mean update the view state token, even if the beans are stored
in the server (remember the beans can be serialized, for example in a cluster).

If we take a look at the proposed goals:

1) possibility to use a normal JSF lifecycle for the first GET request
2) allow action handling and custom response for POST actions
3) normal action handling like in asp.net MVC + a EL util function to
generate the action URL

we cannot

Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project

2014-05-13 Thread Dora Rajappan

How will  a href=#{ma:getLink('mypage?action=exportExcel')}Export excel/a
work when ViewAction is not defined as  
 
@ViewAction(value=/sayhello.xhtml,
                          params= {
                               @ViewParam(name=action,
expectedValue=exportExcel)
                          })
    public void method3(@ViewParam String param1,
@ViewParam(someOther) Integer param2)
    {
but  as @ViewAction(/section1/*, action=exportExcel)
Is the latter not supported now?
 
facelet function getLink for action processing is not a bad idea.
On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe lu4...@gmail.com wrote:
  
Hi

Ok, I think the idea about @ViewAction and @ViewParam is clear, I have
implemented a fast prototype and it works well, there is a lot of things we
can do for improvement, however we should focus the attention in other
areas so we can give the module a better structure.

The next thing we need is how to combine javascript with JSF, specifically
in cases like this:

input id=search/
script type=text/javascript
    $('#search').autocomplete({
        source: #{some EL that return a link to an action goes here}
    });
/script

The idea is provide an input box and then write some javascript lines to
make the component an autocomplete box, but the problem is we need to provide
a URL that can be used to retrieve the values to fill the box. In my opinion,
mix EL and javascript is the best in these cases, but things get complex
quickly when you need to provide parameters and so on. So I would like to
propose these facelet functions (better with examples):

    a href=#{ma:getLink('mypage?action=exportExcel')}Export excel/a

and

    ma:defineLink id=mylink
        f:param name=action value=renderMessage/
    /ma:defineLink

    a href=#{ma:getLinkFrom('mylink')}Render url from EL expression/a

#{ma:getLink(...)} work just like h:link but receives the outcome as parameter.
The function append the request path and the client window id, so the final
generated link will be something like this:

http://localhost:8080/myfaces-mvc-examples/sayhello.jsf?id=5jfwid=1di8uhetf9action=exportExcel

#{ma:getLinkFrom(...)} just inject the link from a component that works just
like h:link but it is just a wrapper, so the user can customize the parameters,
when the EL function is called, the link is rendered taking the parameters
in the definition. The outcome by default is the page itself.


Please note this proposal is something different from the one that suggest to
create the link just pointing to the method in the bean like
#{ma:getLink('mybean', 'mymethod', params)}. After thinking about it, the
problem with that approach is the difficulty to do the match between the link
to generate and the method. EL does not consider annotated methods, so it is
not possible to scan the annotations from the EL unless you do a bypass over
CDI.

I think the approach proposed is something simple to understand, and it has
the advantage that you can isolate the declaration of the link from the
rendering, so the final javascript code will be easier to read.

Finally we need something for the POST case, so the idea is append something
like this:

    form action=#{ma:encodeActionURL()}
          method=post
          enctype=application/x-www-form-urlencoded
        
    /form

#{ma:encodeActionURL()} do what h:form does for encode the action url. Then,
it is responsibility of the user to provide the view state and client window
token in the request as data, so the postback can be processed properly.
In this case, the idea is the view scope will be available, but the component
tree state will not be updated when POST goes back to the client, so any
changes on the component tree in the action will be ignored.

JSF does not make any difference between GET and POST, so viewParam will
work just the same. What defines a postback in JSF is if the view state
field is in the request or not. Theoretically, use #{ma:getLink(...)} should
work too, but I think there are different cases.

There is a contradiction in this case. Send a POST, provide the view state
token, do not restore the view but restore the view scope bean. The problem is
after you make changes on the view scope beans you need to save those changes,
and that could mean update the view state token, even if the beans are stored
in the server (remember the beans can be serialized, for example in a cluster).

If we take a look at the proposed goals:

1) possibility to use a normal JSF lifecycle for the first GET request
2) allow action handling and custom response for POST actions
3) normal action handling like in asp.net MVC + a EL util function to
generate the action URL

we cannot really make number 2 exactly as POST actions. It doesn't fit because
... JSF’s core architecture is designed to be independent of specific
protocols and markup. 

Really the problem proposed in number 2 is not simple and we should analyze it
carefully. In which cases do we really need that

[jira] Dora Rajappan shared MYFACES-3816: missing window-handling for initial requests with you

2014-04-29 Thread Dora Rajappan (JIRA)

Dora Rajappan shared an issue with you


Hi, 

I tried the redirect but  jsf is not able to support it now. 
externaltContext.redirect(url) makes it response complete and ajax request will 
not get processed. Question is to have a new method that to makes it not 
response complete. If its not made response complete also jsf cannot send 
consecutive responses in one request lifecycle.

Regards,
Dora Rajappan

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

2013-12-18 Thread Dora Rajappan (JIRA)


 [ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dora Rajappan updated MYFACES-3817:
---

Status: Patch Available  (was: Reopened)

  ajax redirect/navigation loosing state information when changes are executed 
 with redirect/navigation
 --

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
 with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Re: [core] [discuss] Re: [jira] [Reopened] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

2013-12-17 Thread Dora Rajappan

It is found that jsf is not able to send two responses to a request.
It is good to send view state with redirect response
partial-responsechangesupdate 
id=j_id__v_0:javax.faces.ViewState:1![CDATA[XwZtxeX0oVV/pnTpYxnYBjkE26xY0NEL6/EG8tk4DMwc26zV]]/update/changesredirect
 
url=/portlet-bridge-facelets-guess/guesscdiPartial.jsf/redirect/partial-response
Its not possible to support maximum sequential views to 100% with this 
constraint.



On Friday, December 13, 2013 10:54 PM, Dora Rajappan dorarajap...@yahoo.com 
wrote:
  
 
How about sending view state  to client side for navigation cases via action 
listener (including ajax) as below?
?xml version=1.0 encoding=UTF-8?partial-responsechangesupdate 
id=j_id__v_0:javax.faces.ViewState:1![CDATA
[t9QSM5G6nfM6AJSbI5c1b4flUv63+nMJEut/BNVSBvDhSnkg]]/update/changes/partial-response



On Thursday, December 12, 2013 6:22 PM, Dora Rajappan (JIRA) 
dev@myfaces.apache.org wrote:
  

     [ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

Dora Rajappan reopened MYFACES-3817:



According to http://myfaces.apache.org/core21/myfaces-impl/webconfig.html
NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION  include redirect.

org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION 2.0.6  Indicates the 
amount of views (default is not active) that should be stored in session 
between sequential
 POST or POST-REDIRECT-GET if org .

Hence the in NavigationHandler the viewmap need not be cleared for redirect. 
After redirect from page1 to page2 subsequent navigation to page1 can fetch the 
view from viewmap when serialisation is applied. Now it fetches the view from 
tree.





  ajax redirect/navigation loosing state information when changes are executed 
with redirect/navigation
 --

                 Key: MYFACES-3817
                 URL: https://issues.apache.org/jira/browse/MYFACES-3817
             Project: MyFaces Core
          Issue Type: Bug
 
         Components: General
    Affects Versions: 2.2.0-beta
         Environment: Windows 8
            Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Re: [core] [discuss] Re: [jira] [Reopened] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

2013-12-17 Thread Dora Rajappan

It is found that jsf is not able to send two responses to a request.
It is good to send view state with redirect response
partial-responsechangesupdate 
id=j_id__v_0:javax.faces.ViewState:1![CDATA[XwZtxeX0oVV/pnTpYxnYBjkE26xY0NEL6/EG8tk4DMwc26zV]]/update/changesredirect
 
url=/portlet-bridge-facelets-guess/guesscdiPartial.jsf/redirect/partial-response
Its not possible to support maximum sequential views to 100% with this 
constraint.



On Friday, December 13, 2013 10:54 PM, Dora Rajappan dorarajap...@yahoo.com 
wrote:
  
 
How about sending view state  to client side for navigation cases via action 
listener (including ajax) as below?
?xml version=1.0 encoding=UTF-8?partial-responsechangesupdate 
id=j_id__v_0:javax.faces.ViewState:1![CDATA
[t9QSM5G6nfM6AJSbI5c1b4flUv63+nMJEut/BNVSBvDhSnkg]]/update/changes/partial-response



On Thursday, December 12, 2013 6:22 PM, Dora Rajappan (JIRA) 
dev@myfaces.apache.org wrote:
  

     [ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

Dora Rajappan reopened MYFACES-3817:



According to http://myfaces.apache.org/core21/myfaces-impl/webconfig.html
NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION  include redirect.

org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION 2.0.6  Indicates the 
amount of views (default is not active) that should be stored in session 
between sequential
 POST or POST-REDIRECT-GET if org .

Hence the in NavigationHandler the viewmap need not be cleared for redirect. 
After redirect from page1 to page2 subsequent navigation to page1 can fetch the 
view from viewmap when serialisation is applied. Now it fetches the view from 
tree.





  ajax redirect/navigation loosing state information when changes are executed 
with redirect/navigation
 --

                 Key: MYFACES-3817
                 URL: https://issues.apache.org/jira/browse/MYFACES-3817
             Project: MyFaces Core
          Issue Type: Bug
 
         Components: General
    Affects Versions: 2.2.0-beta
         Environment: Windows 8
            Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

2013-12-16 Thread Dora Rajappan

 
Thanks for explaining viewpool and viewstate. I will go through the code later 
and understand.
I was wondering what happens when state saving method param is not set. I got 
your point it that the state saving algorithm is performed and when its not 
mentioned whether it state saving method is client/server its assumed to save 
views in session and that might not have changed with view pool else it can 
affect maximum sequential views in session. I  have to go through the code to 
follow that. 
 
Regards,
Dora Rajappan.



On Saturday, December 14, 2013 3:53 AM, Leonardo Uribe lu4...@gmail.com wrote:
  
Hi

... When views are not transient and view pool enabled with no state saving or 
serialisation enabled ... 


I don't get anything about what you mean. But I understand that the topic of 
state management is really, really complex, and has been a misunderstood 
problem for years in the world of web application development. So I'm going to 
clarify your confusion:

1. If the view is transient then the view is considered stateless. No state 
saving is performed over stateless views, but since the view pool reuses state 
saving algorithm the view is not reused by the view pool algorithm.
2. If the view is not transient, state saving algorithm is performed.
3. You CAN'T disable state saving. There is no web config parameter to do that, 
not to mention that a param to do that would be completely pointless, because 
the whole point of JSF is solve with the state problem to make applications in 
the web easier. 

4. StateManagementStrategy deals with the problem of how the vdl calculates the 
state, but it is not responsible of store the state. 
5. ResponseStateManger deals with two problems.

- Restore and save the state somewhere. In myfaces we included some classes for 
that: org.apache.myfaces.application.StateCacheFactory, 
org.apache.myfaces.application.StateCache. There are two basic implementations: 
ServerSideStateCacheImpl and ClientSideStateCacheImpl, but it can be more and 
it has been proposed to include a mixed mode. There is still work and some 
discussions to do in that part but they are not prioritary for now, but in the 
past it has been a controversial matter. The solution we have right now works 
just fine.

- Modify the response to include the necessary information to save and restore 
the state. This is done usually writing the javax.faces.ViewState and the 
javax.faces.ClientWindow.
6. StateManagementStrategy is affected by the view pool because in the 
calculation step we store or retrieve a view from the pool, but 
ResponseStateManger is not affected by the pool. Take a look at the code first.

regards,

Leonardo Uribe






2013/12/13 Dora Rajappan dorarajap...@yahoo.com

 
Hi Leonardo,
 
 Thanks for explaining that the statemanagementstrategy is unaffected by the 
view pooling. 
 When views are not transient and view pool enabled with no state saving or 
serialisation enabled, the view pool processing remain the same and the state 
is saved in session. 
  
Regards
Dora Rajappan.



On Friday, December 13, 2013 8:17 PM, Leonardo Uribe lu4...@gmail.com wrote:
  
Hi



2013/12/13 Dora Rajappan dorarajap...@yahoo.com

Not bad +1 for view pool. 
 
When VIEW_POOL_ENABLED the param  
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is not considered 
and not required to set. 
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is valid for state 
saving client/server. 


View Pooling is all about efficient memory management. The state saving 
algorithm is another different thing, and the view pool does not affect the 
way how state saving restoring works. I unfortunately have to say that your 
comment does not have sense. This feature is something new, ouside JSF 2.2 
spec but proposed to be included in MyFaces 2.2. What we are doing here and we 
have done for more than 1 year is discuss and justify the addition of this 
feature.


regards,

Leonardo Uribe






Regards,
Dora Rajappan.



On Friday, December 13, 2013 2:21 PM, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:
  
Cool leo! Thanks for your effort :)





2013/12/13 Leonardo Uribe lu4...@gmail.com

Hi

Finally the code for View Pooling has been comitted. After some performance 
tests with the know demo application, it has been confirmed the following 
improvements: 

- A reduction of 25% of the transient memory used, which means a lot less 
memory is used and it is used at a slower pace. It also means less GC calls
and a better CPU usage.
- An improvement of 9% over throughput for non ajax requests. 
- An improvement from 9% to 30% or even more for ajax request, according to
the tree size.

These improvements are very good and justify the use of the view pool. But
in order to be transparent and open with the community we have not explained
the details behind how the view pool really works. So, I created a blog 
about this topic that I hope to move it into MyFaces documentation once
a release of 2.2.0 is out

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

2013-12-13 Thread Dora Rajappan

Not bad +1 for view pool. 
 
When VIEW_POOL_ENABLED the param  
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is not considered and 
not required to set.
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is valid for state 
saving client/server.
 
Regards,
Dora Rajappan.



On Friday, December 13, 2013 2:21 PM, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:
  
Cool leo! Thanks for your effort :)





2013/12/13 Leonardo Uribe lu4...@gmail.com

Hi

Finally the code for View Pooling has been comitted. After some performance 
tests with the know demo application, it has been confirmed the following 
improvements: 

- A reduction of 25% of the transient memory used, which means a lot less 
memory is used and it is used at a slower pace. It also means less GC calls
and a better CPU usage.
- An improvement of 9% over throughput for non ajax requests. 
- An improvement from 9% to 30% or even more for ajax request, according to
the tree size.

These improvements are very good and justify the use of the view pool. But
in order to be transparent and open with the community we have not explained
the details behind how the view pool really works. So, I created a blog 
about this topic that I hope to move it into MyFaces documentation once
a release of 2.2.0 is out (we have some pending work to do in the 
documentation area, so I hope to do everything in one step).

http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html

The blog summarize all information about this topic, its origins,
the reasons behind them and the solution proposed, so we can discuss it later
if there is any doubt or critic about it. It is a long story but this is 
something we need to document properly.

regards,

Leonardo Uribe




2013/12/9 Leonardo Uribe lu4...@gmail.com

Hi

It seems we have an inconsistency between what was proposed to enable the 
view pool and the inclusion of the new parameter.

At start we have this:


org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the 
app, by default false)



But if we use an attribute in f:view like oamEnableViewPool, aiming to 
select the views that will use the pool, the previous param does not look 
good because it overlaps the attribute.


In this case, I think it is better to keep things simple and remove the web 
config param and let the pool to be enabled only through the attribute or the 
entry in faces-config-extension. I'll do that.
 

regards,

Leonardo Uribe





2013/12/9 Thomas Andraschko andraschko.tho...@gmail.com

Hi Leo,

sounds fine! thanks :)




2013/12/9 Leonardo Uribe lu4...@gmail.com

Hi


I think we could add it as a parameter for f:view tag, for example call it 
oamEnableViewPool. The patch proposed uses already an attribute for disable 
the pool in some cases, but after doing some experiments (MYFACES-3831) I 
have found we need to change some parts of the algorithm. Specifically I 
have found that it is not really necessary the check to disable the pool 
when VariableMapper  is used because with the code we have in place there 
is no way an EL expression should not be the same each time the view is 
built.


A phaselistener is not necessary. I think the best place to set the param 
manually is ViewHandler.createView(...).



regards,


Leonardo Uribe

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

2013-12-13 Thread Dora Rajappan

 
Hi Leonardo,
 
 Thanks for explaining that the statemanagementstrategy is unaffected by the 
view pooling.
 When views are not transient and view pool enabled with no state saving or 
serialisation enabled, the view pool processing remain the same and the state 
is saved in session. 
 
Regards
Dora Rajappan.



On Friday, December 13, 2013 8:17 PM, Leonardo Uribe lu4...@gmail.com wrote:
  
Hi



2013/12/13 Dora Rajappan dorarajap...@yahoo.com

Not bad +1 for view pool. 
 
When VIEW_POOL_ENABLED the param  
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is not considered and 
not required to set. 
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is valid for state 
saving client/server. 

View Pooling is all about efficient memory management. The state saving 
algorithm is another different thing, and the view pool does not affect the way 
how state saving restoring works. I unfortunately have to say that your comment 
does not have sense. This feature is something new, ouside JSF 2.2 spec but 
proposed to be included in MyFaces 2.2. What we are doing here and we have done 
for more than 1 year is discuss and justify the addition of this feature.


regards,

Leonardo Uribe





Regards,
Dora Rajappan.



On Friday, December 13, 2013 2:21 PM, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:
  
Cool leo! Thanks for your effort :)





2013/12/13 Leonardo Uribe lu4...@gmail.com

Hi

Finally the code for View Pooling has been comitted. After some performance 
tests with the know demo application, it has been confirmed the following 
improvements: 

- A reduction of 25% of the transient memory used, which means a lot less 
memory is used and it is used at a slower pace. It also means less GC calls
and a better CPU usage.
- An improvement of 9% over throughput for non ajax requests. 
- An improvement from 9% to 30% or even more for ajax request, according to
the tree size.

These improvements are very good and justify the use of the view pool. But
in order to be transparent and open with the community we have not explained
the details behind how the view pool really works. So, I created a blog 
about this topic that I hope to move it into MyFaces documentation once
a release of 2.2.0 is out (we have some pending work to do in the 
documentation area, so I hope to do everything in one step).

http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html

The blog summarize all information about this topic, its origins,
the reasons behind them and the solution proposed, so we can discuss it later
if there is any doubt or critic about it. It is a long story but this is 
something we need to document properly.

regards,

Leonardo Uribe




2013/12/9 Leonardo Uribe lu4...@gmail.com

Hi

It seems we have an inconsistency between what was proposed to enable the 
view pool and the inclusion of the new parameter.

At start we have this:


org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the 
app, by default false)



But if we use an attribute in f:view like oamEnableViewPool, aiming to 
select the views that will use the pool, the previous param does not look 
good because it overlaps the attribute.


In this case, I think it is better to keep things simple and remove the web 
config param and let the pool to be enabled only through the attribute or 
the entry in faces-config-extension. I'll do that.
 

regards,

Leonardo Uribe





2013/12/9 Thomas Andraschko andraschko.tho...@gmail.com

Hi Leo,

sounds fine! thanks :)




2013/12/9 Leonardo Uribe lu4...@gmail.com

Hi


I think we could add it as a parameter for f:view tag, for example call it 
oamEnableViewPool. The patch proposed uses already an attribute for 
disable the pool in some cases, but after doing some experiments 
(MYFACES-3831) I have found we need to change some parts of the algorithm. 
Specifically I have found that it is not really necessary the check to 
disable the pool when VariableMapper  is used because with the code we 
have in place there is no way an EL expression should not be the same each 
time the view is built.


A phaselistener is not necessary. I think the best place to set the param 
manually is ViewHandler.createView(...).



regards,


Leonardo Uribe

[core] [discuss] Re: [jira] [Reopened] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

2013-12-13 Thread Dora Rajappan

 
How about sending view state  to client side for navigation cases via action 
listener (including ajax) as below?
?xml version=1.0 encoding=UTF-8?partial-responsechangesupdate 
id=j_id__v_0:javax.faces.ViewState:1![CDATA
[t9QSM5G6nfM6AJSbI5c1b4flUv63+nMJEut/BNVSBvDhSnkg]]/update/changes/partial-response



On Thursday, December 12, 2013 6:22 PM, Dora Rajappan (JIRA) 
dev@myfaces.apache.org wrote:
  

     [ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

Dora Rajappan reopened MYFACES-3817:



According to http://myfaces.apache.org/core21/myfaces-impl/webconfig.html
NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION  include redirect.

org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION 2.0.6  Indicates the 
amount of views (default is not active) that should be stored in session 
between sequential POST or POST-REDIRECT-GET if org .

Hence the in NavigationHandler the viewmap need not be cleared for redirect. 
After redirect from page1 to page2 subsequent navigation to page1 can fetch the 
view from viewmap when serialisation is applied. Now it fetches the view from 
tree.





  ajax redirect/navigation loosing state information when changes are executed 
with redirect/navigation
 --

                 Key: MYFACES-3817
                 URL: https://issues.apache.org/jira/browse/MYFACES-3817
             Project: MyFaces Core
          Issue Type: Bug
          Components: General
    Affects Versions: 2.2.0-beta
         Environment: Windows 8
            Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Reopened] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

2013-12-12 Thread Dora Rajappan (JIRA)

[
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dora Rajappan reopened MYFACES-3817:

According to http://myfaces.apache.org/core21/myfaces-impl/webconfig.html
NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION include redirect.

org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION 2.0.6 Indicates the
amount of views (default is not active) that should be stored in session
between sequential POST or POST-REDIRECT-GET if org .

Hence the in NavigationHandler the viewmap need not be cleared for redirect.
After redirect from page1 to page2 subsequent navigation to page1 can fetch the
view from viewmap when serialisation is applied. Now it fetches the view from
tree.

ajax redirect/navigation loosing state information when changes are executed
with redirect/navigation
--

Key: MYFACES-3817
URL: https://issues.apache.org/jira/browse/MYFACES-3817
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.2.0-beta
Environment: Windows 8
Reporter: Dora Rajappan
Original Estimate: 0.8h
Remaining Estimate: 0.8h

Ajax redirect/navigation loosing state information when changes are executed
with redirect. This can be addressed
#1 By putting a flag in redirect and write it in response after save state
in rendering phase.
#2 This behaviour true for redirect via navigation handler. In render phase
it goes to response complete and state saving is avoided. When its a redirect
not make the response complete true and flag it so that in rendering phase
state is saved.

--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Resolved] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

2013-11-25 Thread Dora Rajappan (JIRA)


 [ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dora Rajappan resolved MYFACES-3817.


Resolution: Fixed

ViewExpiredException is fixed. state change under these conditions is lost due 
to overwrite and not supported this time for client and server side state 
saving to remain in sync.

  ajax redirect/navigation loosing state information when changes are executed 
 with redirect/navigation
 --

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
 with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (MYFACES-3737) Remove _Html*.class from myface api.jar

2013-11-25 Thread Dora Rajappan (JIRA)


 [ 
https://issues.apache.org/jira/browse/MYFACES-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dora Rajappan resolved MYFACES-3737.


Resolution: Fixed

Api pom is changed and api.jar not containing the _Html* classes that are only 
required for myfaces builder plugin.

 Remove _Html*.class from myface api.jar
 ---

 Key: MYFACES-3737
 URL: https://issues.apache.org/jira/browse/MYFACES-3737
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.1.12
 Environment: NA
Reporter: Dora Rajappan
Priority: Trivial
   Original Estimate: 168h
  Remaining Estimate: 168h

 _Html classes are used by the builder plugin and not required to be there in 
 api.jar to have it lighter.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

2013-11-20 Thread Dora Rajappan (JIRA)

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

Dora Rajappan commented on MYFACES-3817:

In order not to loose state change for the redirect/navigation if you save
state in execute cycle before overwrite the viewroot the server side state
saving remains in good state but with the client side state saving you simply
cannot send two separate viewstate information. And that is the reason the
state is not saved in execute. This conflict has to be addressed. Easiest
solution is send a viewstate information after state saving and before
overwriting viewroot and then save the new view and send the response. For all
responseComplete navigation cases in execute cycle the overwritten view can be
saved in execute cycle to avoid ViewExpiredException. And this will not
conflict the clientside and serverside state saving.

ajax redirect/navigation loosing state information when changes are executed
with redirect/navigation
--

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect

2013-11-14 Thread Dora Rajappan (JIRA)

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

Dora Rajappan commented on MYFACES-3817:

A redirect from page1 is clearing the viewmap and hence the next access to
page1 cause the view to be built form tree and it get the state change. Not
sure the spec mentioning to clear the viewmap for redirect. Not sure
NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is excluded for redirect. Redirect
generates a non faces response is mentioned in spec and it can exclude render
cycle. Spec not mention about viewstate handling for redirect.

ajax redirect/navigation loosing state information when changes are executed
with redirect
---

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3737) Remove _Html*.class from myface api.jar

2013-11-13 Thread Dora Rajappan (JIRA)


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

Dora Rajappan commented on MYFACES-3737:


Having file names in the exclude list for compilation in the pom is better.

 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 configuration

excludes


exclude**/javax/faces/component/html/_HtmlBody.java/exclude


exclude**/javax/faces/component/html/_HtmlColumn.java/exclude 


exclude**/javax/faces/component/html/_HtmlCommandButton.java/exclude


exclude**/javax/faces/component/html/_HtmlCommandLink.java/exclude


exclude**/javax/faces/component/html/_HtmlDataTable.java/exclude


exclude**/javax/faces/component/html/_HtmlDoctype.java/exclude


exclude**/javax/faces/component/html/_HtmlForm.java/exclude


exclude**/javax/faces/component/html/_HtmlGraphicImage.java/exclude


exclude**/javax/faces/component/html/_HtmlHead.java/exclude


exclude**/javax/faces/component/html/_HtmlInputFile.java/exclude


exclude**/javax/faces/component/html/_HtmlInputSecret.java/exclude


exclude**/javax/faces/component/html/_HtmlInputText.java/exclude


exclude**/javax/faces/component/html/_HtmlInputTextarea.java/exclude


exclude**/javax/faces/component/html/_HtmlMessage.java/exclude


exclude**/javax/faces/component/html/_HtmlMessages.java/exclude


exclude**/javax/faces/component/html/_HtmlOutcomeTargetButton.java/exclude


exclude**/javax/faces/component/html/_HtmlOutcomeTargetLink.java/exclude


exclude**/javax/faces/component/html/_HtmlOutputFormat.java/exclude


exclude**/javax/faces/component/html/_HtmlOutputLabel.java/exclude


exclude**/javax/faces/component/html/_HtmlOutputLink.java/exclude


exclude**/javax/faces/component/html/_HtmlOutputText.java/exclude


exclude**/javax/faces/component/html/_HtmlPanelGrid.java/exclude


exclude**/javax/faces/component/html/_HtmlPanelGroup.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectBooleanCheckbox.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectManyCheckbox.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectManyListbox.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectManyMenu.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectOneListbox.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectOneMenu.java/exclude

[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

2013-11-13 Thread Dora Rajappan (JIRA)


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

Dora Rajappan commented on MYFACES-3817:


In order to support NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION it is required to 
save state in Navigation Handler in execute cycle before viewroot is 
overwritten. Not required to flag it and follow till render phase to save state.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [jira] [Comment Edited] (MYFACES-3804) Use the same key in server side state saving for ajax requests

2013-11-13 Thread Dora Rajappan

 
 What happens now is  in invoke application executor the action is processed 
and navigation handled and next view is created and this view is in same 
execute cycle and this overwrites the ajax view and gets rendered with ajax 
view id in the page.

This behaviour of showing a previous view id in the page with new view gives 
rise to ViewExpiredException after a few navigations back and forth. It is 
required to show the view id of the new view in the page when navigating 
through action listener.

 



On Wednesday, November 6, 2013 2:40 PM, Dora Rajappan dorarajap...@yahoo.com 
wrote:
  
Well thanks Mike. Its possible to view the unedited comments from mail list and 
edited ones in Jira. But expressions such as smileys are not good in mail list 
:) 
 
 
Regarding use the same key in server side state saving for ajax requests it is 
ok since use of navigation with ajax is  rare and so may be redirect.
 
 



On Tuesday, November 5, 2013 9:56 PM, Mike Kienenberger (JIRA) 
dev@myfaces.apache.org wrote:
  

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

Mike Kienenberger edited comment on MYFACES-3804 at 11/5/13 4:24 PM:
-

Dora,

We need to move discussion to the developer mailing list, and reserve the JIRA 
for resolving issues.
There are a number of reasons why the JIRA issue is not the best place for 
discussion, which I wrote
 about here:

http://mail-archives.apache.org/mod_mbox/myfaces-dev/201311.mbox/%3CCAM1yOjZHhSRwrAQ2Va_Em0yAcPD9mA9D-7daCG7z-eHfr%3DZ0-g%40mail.gmail.com%3E

I'm sorry that I didn't speak up a while back when I first noticed it 
happening, but we need to resume using the developer mailing list for its 
intended purpose.   Please repost your comments from here directly on the 
developer mailing list.



was (Author: mkienenb):
Dora,

We need to move discussion to the developer mailing list, and reserve the JIRA 
for resolving issues.
There are a number of reasons why the
 JIRA issue is not the best place for discussion, which I wrote about here:

http://mail-archives.apache.org/mod_mbox/myfaces-dev/201311.mbox/%3CCAM1yOjZHhSRwrAQ2Va_Em0yAcPD9mA9D-7daCG7z-eHfr%3DZ0-g%40mail.gmail.com%3E

I'm sorry that I didn't speak up a while back when I first noticed it 
happening, but we need to resume using the developer mailing list for its 
intended purpose.


 Use the same key in server side state saving for ajax requests
 --

                 Key: MYFACES-3804
                 URL: https://issues.apache.org/jira/browse/MYFACES-3804
         
    Project: MyFaces Core
          Issue Type: Improvement
          Components: JSR-344
            Reporter: Leonardo Uribe
         Attachments: ajaxviewkeytest.patch, ajaxviewkeytest2.patch, 
ajaxviewsamekey.patch, ajaxviewsamekey2.patch, ajaxviewsamekey3.patch


 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent
 does not need to change, what changes is the internal state of the view. From 
the client side the page is
 the same. We can take advantage of this fact and just update the state stored 
in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3737) Remove _Html*.class from myface api.jar

2013-11-07 Thread Dora Rajappan (JIRA)


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

Dora Rajappan commented on MYFACES-3737:


It is required to add  below in api pom after myfaces-builder-plugin to remove 
unused _Html*.java files from api binary.

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration

  excludes
 
exclude**/javax/faces/component/html/_Html*.java/exclude
  /excludes
/configuration
  /plugin

 Remove _Html*.class from myface api.jar
 ---

 Key: MYFACES-3737
 URL: https://issues.apache.org/jira/browse/MYFACES-3737
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.1.12
 Environment: NA
Reporter: Dora Rajappan
Priority: Trivial
   Original Estimate: 168h
  Remaining Estimate: 168h

 _Html classes are used by the builder plugin and not required to be there in 
 api.jar to have it lighter.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [jira] [Comment Edited] (MYFACES-3804) Use the same key in server side state saving for ajax requests

2013-11-06 Thread Dora Rajappan

Well thanks Mike. Its possible to view the unedited comments from mail list and 
edited ones in Jira. But expressions such as smileys are not good in mail list 
:) 
 
 
Regarding use the same key in server side state saving for ajax requests it is 
ok since use of navigation with ajax is  rare and so may be redirect.
 
 



On Tuesday, November 5, 2013 9:56 PM, Mike Kienenberger (JIRA) 
dev@myfaces.apache.org wrote:
  

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

Mike Kienenberger edited comment on MYFACES-3804 at 11/5/13 4:24 PM:
-

Dora,

We need to move discussion to the developer mailing list, and reserve the JIRA 
for resolving issues.
There are a number of reasons why the JIRA issue is not the best place for 
discussion, which I wrote about here:

http://mail-archives.apache.org/mod_mbox/myfaces-dev/201311.mbox/%3CCAM1yOjZHhSRwrAQ2Va_Em0yAcPD9mA9D-7daCG7z-eHfr%3DZ0-g%40mail.gmail.com%3E

I'm sorry that I didn't speak up a while back when I first noticed it 
happening, but we need to resume using the developer mailing list for its 
intended purpose.   Please repost your comments from here directly on the 
developer mailing list.



was (Author: mkienenb):
Dora,

We need to move discussion to the developer mailing list, and reserve the JIRA 
for resolving issues.
There are a number of reasons why the JIRA issue is not the best place for 
discussion, which I wrote about here:

http://mail-archives.apache.org/mod_mbox/myfaces-dev/201311.mbox/%3CCAM1yOjZHhSRwrAQ2Va_Em0yAcPD9mA9D-7daCG7z-eHfr%3DZ0-g%40mail.gmail.com%3E

I'm sorry that I didn't speak up a while back when I first noticed it 
happening, but we need to resume using the developer mailing list for its 
intended purpose.


 Use the same key in server side state saving for ajax requests
 --

                 Key: MYFACES-3804
                 URL: https://issues.apache.org/jira/browse/MYFACES-3804
             Project: MyFaces Core
          Issue Type: Improvement
          Components: JSR-344
            Reporter: Leonardo Uribe
         Attachments: ajaxviewkeytest.patch, ajaxviewkeytest2.patch, 
ajaxviewsamekey.patch, ajaxviewsamekey2.patch, ajaxviewsamekey3.patch


 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

2013-11-06 Thread Dora Rajappan (JIRA)


 [ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dora Rajappan reopened MYFACES-3817:



Reopening bug with a better test case.

Ajax redirect is loosing state information when changes are executed with 
redirect  normal navigation.

Navigate or Redirect from page1 to page2 through ajax request. And navigate 
(not redirect) from page2 to page1. In this case page1 is built from 
SerialisedViewCollection and it is found that the state changes are lost.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests

2013-11-05 Thread Dora Rajappan (JIRA)

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

Dora Rajappan commented on MYFACES-3804:

Thanks for your reply. Let this discussion go in here for ease.
You are talking about the tab characters in testcase. I will submit new patch
for that. I had not saved the format.
I am not using checkstyle for now. I will configure it.
I use maven for build/test, svn yes but outside of eclipse.

add() can change to update. I will make that change.

In normal navigation you have a key and next key for the new view built which
passed to add of SerialisedViewCollection.
But in the case of ajax and normal navigation same thing happens new view built
is passed to add of SerialisedViewCollection. What happens now is in invoke
application executor the action is processed and navigation handled and next
view is created and this view is in same execute cycle and this overwrites the
ajax view and gets rendered with ajax view id in the page.

Not altering this behaviour above ajaxwithsameviewkey fix is extended to normal
navigation by means of add instead of update of SerialisedViewCollection.

Regarding the condition in restoreSerializedView looks suspicious, this bypass
is only for ajax request and hence its affects only ajax requests. But I have
changed code to put the state id in SERVER_STATE_ID and not in SEQUENCE_PARAM.

Is this fine tuning required for ajax since redirect and navigation are avoided
:)

Use the same key in server side state saving for ajax requests
--

Key: MYFACES-3804
URL: https://issues.apache.org/jira/browse/MYFACES-3804
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-344
Reporter: Leonardo Uribe
Attachments: ajaxviewkeytest.patch, ajaxviewkeytest2.patch,
ajaxviewsamekey.patch, ajaxviewsamekey2.patch, ajaxviewsamekey3.patch

The current code for server side state saving creates one key per request to
store the view state. This is ok, but it is not necessary for ajax requests.
The reason why is not necessary is because you can never go back to a page
when using ajax. If you are on page A and the current request is an ajax
request and it returns to the same page and the view is the same that the one
that has been restored, the key or the token sent does not need to change,
what changes is the internal state of the view. From the client side the page
is the same. We can take advantage of this fact and just update the state
stored in SerializedViewCollection for the view.
The challenge here is detect when this strategy is applicable. For example,
what happen if there is an ajax redirect? It looks is a good idea for
implement in 2.2, because it avoids to store unnecessary information into
session and optimize the use of each view slot.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests


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

Dora Rajappan commented on MYFACES-3816:


What have you decided about the current behaviour of ajax redirect loosing 
state information when changes are executed with redirect? Have you decided to 
flag in redirect and write it in response after save state in rendering phase?

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests


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

Dora Rajappan commented on MYFACES-3816:


And this behaviour true for redirect via navigation handler. In render phase it 
goes to response complete and state saving is avoided.

h:commandButton action=#{bean.action} value=Invoke and redirect
 f:ajax execute=@this/
 /h:commandButton 

 navigation-rules
 navigation-rule
 from-view-id/form.xhtml/from-view-id
 navigation-case
 from-action#{bean.action}/from-action
 from-outcomesuccess/from-outcome
 to-view-id/target.xhtml/to-view-id
redirect/
 /navigation-case
 /navigation-rule
 /navigation-rules 

 @RequestScoped @ManagedBean
 public class Bean {
 public String action() { return success; }
 } 

I think its a good idea to follow client side state saving behaviour for ajax 
redirect.

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests


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

Dora Rajappan commented on MYFACES-3816:


The topic about window-handling is different but it exposes a scenario related 
to 3804. Probably this redirect behaviour and server side state handling can be 
included in #3804 or a new jira issue.

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests


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

Dora Rajappan commented on MYFACES-3804:


Including relevant comments from 3816
What have you decided about the current behaviour of ajax redirect loosing 
state information when changes are executed with redirect? Have you decided to 
flag in redirect and write it in response after save state in rendering phase?

And this behaviour true for redirect via navigation handler. In render phase it 
goes to response complete and state saving is avoided.

h:commandButton action=#
{bean.action} value=Invoke and redirect
 f:ajax execute=@this/
 /h:commandButton 

 navigation-rules
 navigation-rule
 from-view-id/form.xhtml/from-view-id
 navigation-case
 from-action#{bean.action} 
/from-action
 from-outcomesuccess/from-outcome
 to-view-id/target.xhtml/to-view-id
 redirect/
 /navigation-case
 /navigation-rule
 /navigation-rules 

@RequestScoped @ManagedBean
 public class Bean {
 public String action() 
{ return success; } 
} 

I think its a good idea to follow client side state saving behaviour for ajax 
redirect. 


 Use the same key in server side state saving for ajax requests
 --

 Key: MYFACES-3804
 URL: https://issues.apache.org/jira/browse/MYFACES-3804
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: ajaxviewkey.patch, ajaxviewkeytest.patch, 
 ajaxviewkeytest2.patch


 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

Dora Rajappan created MYFACES-3817:
--

 Summary:  ajax redirect loosing state information when changes are 
executed with redirect
 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan


 Ajax redirect loosing state information when changes are executed with 
redirect.  This can be addressed 
#1 By putting a  flag in redirect and write it in response after save state in 
rendering phase.
#2 This behaviour true for redirect via navigation handler. In render phase it 
goes to response complete and state saving is avoided. When its a redirect not 
make the response complete true and flag it so that in rendering phase state is 
saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect


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

Dora Rajappan commented on MYFACES-3817:


#1 for redirect via ExternalContext
#2 for redirect via NaviagtionHandler.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests

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

Dora Rajappan commented on MYFACES-3804:

I have opened a jira issue 3817 for state saving problem with ajax redirect.
Once that is fixed the view key fix automatically applies to redirect scenario.
Shall I commit this code. This address when there is no key initially in
client window mode and an ajax request is made.

Use the same key in server side state saving for ajax requests
--

Key: MYFACES-3804
URL: https://issues.apache.org/jira/browse/MYFACES-3804
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-344
Reporter: Leonardo Uribe
Attachments: ajaxviewkey.patch, ajaxviewkeytest.patch,
ajaxviewkeytest2.patch

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect


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

Dora Rajappan commented on MYFACES-3817:


With Client side state saving the changes executed with ajax redirect are saved 
in state. Hence the same behaviour is expected in server side state saving also.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

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

Dora Rajappan edited comment on MYFACES-3817 at 11/4/13 4:42 PM:
-

Both client and server side state saving ajax redirect loose changes executed
with redirect. partial-responseredirect
url=/portlet-bridge-facelets-guess/guessroleoriginal.jsf/redirect/partial-response
No state information is sent to the page. In the case of redirect the view is
built in a different way and you still get the state changes. Hence this bug
can be closed and need not be handled.

was (Author: dorarajappan):
With Client side state saving the changes executed with ajax redirect are saved
in state. Hence the same behaviour is expected in server side state saving also.

ajax redirect loosing state information when changes are executed with
redirect

Ajax redirect loosing state information when changes are executed with
redirect. This can be addressed
#1 By putting a flag in redirect and write it in response after save state
in rendering phase.
#2 This behaviour true for redirect via navigation handler. In render phase
it goes to response complete and state saving is avoided. When its a redirect
not make the response complete true and flag it so that in rendering phase
state is saved.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect


 [ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dora Rajappan resolved MYFACES-3817.


Resolution: Invalid

When tested it is found that the fix is not required.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect