[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877520#comment-17877520 ] Werner Punz edited comment on MYFACES-4679 at 8/29/24 7:44 AM: --- Sorry for the delay, I have been busy in my sparetime with 4676 which I have resolved tonight, I will start to investigate this issue tomorrow! I would not revert 4606 because it was added for a reason, probably the best fix would be to adapt the decode method accordingly to deal with this! Adding additional behaviors for our implementation of faces.js wont break the code of other frameworks which have their own faces.js implementation we just have to make sure that it does not replace the existing behavior just that it augments it! But as I said I will look tonight deeper into it! was (Author: werpu): Sorry for the delay, I have been busy in my sparetime with 4676 which I have resolved tonight, I will start to investigate this issue tomorrow! I would not revert 4606 because it was added for a reason, probably the best fix would be to adapt the decode method accordingly to deal with this! Adding additional behaviors for our implementation of faces.js wont break the code of other frameworks which have their own faces.js implementation we just have to make sure that it does not replace the existing behavior just that it augments it! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877869#comment-17877869 ] Werner Punz commented on MYFACES-4679: -- Ok I finally had time to read this, in my opinion the following behavior should be correct a) Click move out release should not trigger anything at all b) Click on the second button release move click out only the blur event should occur. a) should not trigger a request at all (or one where nothing happens) b) should trigger a request but only with blur being handled! I will look at the example tomorrow and will try to figure it out on the code side! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877869#comment-17877869 ] Werner Punz edited comment on MYFACES-4679 at 8/29/24 7:01 PM: --- Ok I finally had time to read this, in my opinion the following behavior should be correct a) Click move out release should not trigger anything at all b) Click on the second button release move click out only the blur event should occur. a) should not trigger a request at all (or one where nothing happens) b) should trigger a request but only with blur being handled! I will look at the example tomorrow and will try to figure it out on the code side! was (Author: werpu): Ok I finally had time to read this, in my opinion the following behavior should be correct a) Click move out release should not trigger anything at all b) Click on the second button release move click out only the blur event should occur. a) should not trigger a request at all (or one where nothing happens) b) should trigger a request but only with blur being handled! I will look at the example tomorrow and will try to figure it out on the code side! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878274#comment-17878274 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 11:47 PM: Ok full analysis: Following what happens is, that the code relies on a key value pair being present on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered on top in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! I also have to reread the ajax spec for this case, its been a while! was (Author: werpu): Ok full analysis: Following what happens is, that the code relies on a key value pair being present on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered on top in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! I also have to reread the ajax spec for this case, its been a while! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878267#comment-17878267 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 10:29 PM: Ok I have setup the example, took me a while, I had to port it to the jakarta namespace to get it working here: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! The server side code is correct here, because it does not have to deal with special events like blur, in case of non ajax cases! was (Author: werpu): Ok I have setup the example, took me a while, I had to port it to the jakarta namespace to get it working here: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878267#comment-17878267 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 10:28 PM: Ok I have setup the example, took me a while, I had to port it to the jakarta namespace to get it working here: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! was (Author: werpu): Ok I have setup the example: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878271#comment-17878271 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 11:19 PM: The issue is indeed in the HTMLButtonRendererBase: boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; isSubmitted is triggered no matter what and that code checks for a key which is identical to the button! The most likely fix is in the isSubmitted method! in case of pre 4606 this returned a false, in case of 4606 it returns true and hence triggers an action event at this stage was (Author: werpu): The issue is indeed in the HTMLButtonRendererBase: boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; isSubmitted is triggered no matter what and that code checks for a key which is identical to the button! in case of pre 4606 this returned a false, in case of 4606 it returns true and hence triggers an action event at this stage > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878448#comment-17878448 ] Werner Punz edited comment on MYFACES-4679 at 9/2/24 5:27 AM: -- Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases. I have the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem, so that we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) was (Author: werpu): Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases, I get the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878329#comment-17878329 ] Werner Punz edited comment on MYFACES-4679 at 8/31/24 10:40 AM: I had to sleep over this to get some distance and my mind clear again (it was 2 am when I stopped working on this). I would propose following On the scripts side, I would remove the issuing element as key value pair for every case except for the case of triggering an action (click etc...) this can be done by simply checking whether an event is issued in combination and then checking which event and whitelist a click event for having the key value pair in! This should fix the issue for good while still retaining the original intention of 4606 of having the action element as key value pair in the request for action calls triggered via ajax which mimicks then the original submit behavior! If I follow this approach, I am rather confident that we will not have to fix anything on the Java side of things! Any objections? was (Author: werpu): I had to sleep over this to get some distance and my mind clear again (it was 2 am when I stopped working on this). I would propose following On the scripts side, I would remove the issuing element as key value pair for every case except for the case of triggering an action (click etc...) this can be done by simply checking whether an event is issued in combination and then checking which event and whitelist a click event for having the key value pair in! This should fix the issue for good while still retaining the original intention of 4606 of having the action element as key value pair in the request for action calls triggered via ajax which mimicks then the original submit behavior! If I follow this approach, I am rather confident that we do not have to fix anything on the java side of things! Any objections? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878274#comment-17878274 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 11:47 PM: Ok full analysis: Following what happens is, that the code relies on a key value pair being present on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered on top in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! I also have to reread the ajax spec for this case, its been a while! was (Author: werpu): Ok full analysis: Following what happens is, that the code relies on a key value pair being bresent on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878267#comment-17878267 ] Werner Punz commented on MYFACES-4679: -- Ok I have setup the example: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878268#comment-17878268 ] Werner Punz commented on MYFACES-4679: -- Ok addendum. Not fixable on the client side, a simple button press causes 2 action events. What happens is that the added key:value pair simply triggers a normal action event just like it would come from the server. The second one is an ajax behavior event which has an action event added. The second one is probably the normal behavior we had for 4606, by added the key value pair we trigger basically the ajax and non ajax case. The server side code needs to be adapted that it does not go into the non ajax event case if we have an ajax request (this is detectable), to restore the pre 4606 behavior! The other solution would be to roll back 4606, but do we really want that? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878268#comment-17878268 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 10:36 PM: Ok addendum. Not fixable on the client side, a simple button press causes 2 action events. What happens is that the added key:value pair simply triggers a normal action event just like it would come from the server. The second one is an ajax behavior event which has an action event added. The second one is probably the normal behavior we had for 4606, by added the key value pair we trigger basically the ajax and non ajax case. The server side code needs to be adapted that it does not go into the non ajax event case if we have an ajax request (this is detectable), to restore the pre 4606 behavior! The other solution would be to roll back 4606, but do we really want that? It was added to get a parameter parity between the non ajax and the ajax case for easier debugging and testing! was (Author: werpu): Ok addendum. Not fixable on the client side, a simple button press causes 2 action events. What happens is that the added key:value pair simply triggers a normal action event just like it would come from the server. The second one is an ajax behavior event which has an action event added. The second one is probably the normal behavior we had for 4606, by added the key value pair we trigger basically the ajax and non ajax case. The server side code needs to be adapted that it does not go into the non ajax event case if we have an ajax request (this is detectable), to restore the pre 4606 behavior! The other solution would be to roll back 4606, but do we really want that? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878262#comment-17878262 ] Werner Punz commented on MYFACES-4679: -- Ok took me a while to set it up, we have indeed a problem here a) 4.0.1 works properly like expected b) 4.0.2 onwards trigger the issue and also issue 2 actions! The patch indeed causes an action to be triggered on a blur event! I will look into the root cause of this! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878271#comment-17878271 ] Werner Punz commented on MYFACES-4679: -- The issue is indeed in the HTMLButtonRendererBase: boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; isSubmitted is triggered no matter what and that code checks for a key which is identical to the button! in case of pre 4606 this returned a false, in case of 4606 it returns true and hence triggers an action event at this stage > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878448#comment-17878448 ] Werner Punz edited comment on MYFACES-4679 at 9/1/24 7:29 PM: -- Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases, I get the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) was (Author: werpu): Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases, I get the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem we can merge! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878329#comment-17878329 ] Werner Punz commented on MYFACES-4679: -- I had to sleep over this to get some distance and my mind clear again (it was 2 am when I stopped working on this). I would propose following On the scripts side, I would remove the issuing element as key value pair for every case except for the case of triggering an action (click etc...) this can be done by simply checking whether an event is issued in combination and then checking which event and whitelist a click event for having the key value pair in! This should fix the issue for good while still retaining the original intention of 4606 of having the action element as key value pair in the request for action calls triggered via ajax which mimicks then the original submit behavior! If I follow this approach, I am rather confident that we do not have to fix anything on the java side of things! Any objections? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878448#comment-17878448 ] Werner Punz commented on MYFACES-4679: -- Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases, I get the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem we can merge! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878274#comment-17878274 ] Werner Punz commented on MYFACES-4679: -- Ok full analysis: Following what happens is, that the code relies on a key value pair being bresent on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878448#comment-17878448 ] Werner Punz edited comment on MYFACES-4679 at 9/2/24 11:43 AM: --- Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases. I have the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! PS: We will have to fix this for 2.3 as well, I will add the fix later this week! [~volosied] please review it and if it solves your problem, so that we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) was (Author: werpu): Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases. I have the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem, so that we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878624#comment-17878624 ] Werner Punz commented on MYFACES-4679: -- [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878624#comment-17878624 ] Werner Punz edited comment on MYFACES-4679 at 9/2/24 4:24 PM: -- [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! was (Author: werpu): [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! A select many check box as issuer was not covered yet, that is independent of the 4606! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878624#comment-17878624 ] Werner Punz edited comment on MYFACES-4679 at 9/2/24 4:24 PM: -- [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! A select many check box as issuer was not covered yet, that is independent of the 4606! was (Author: werpu): [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] Commented: (TOMAHAWK-205) inputCalendar Popup positioned incorrectly in scrollable div
[ https://issues.apache.org/jira/browse/TOMAHAWK-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566542#action_12566542 ] Werner Punz commented on TOMAHAWK-205: -- Ok I am working on it again, I finally seem to have fixed this. Once I am fully sure I will do the commit in the trunk! The issue was a bigger one. First of all the componet at the current Tomahawk 1.1.7 codebase simply correctly was doing some offset calculation and then stopped at the first position absolute or relative. It then tried two different calculation methods to determine how to show the popup which is in a relative position to the control. This is not the correct way to do it, you run into boxing issues in no time like that. The best bet for floating div positioning always is, to use a floating div as child to the body and then do a full calculation of the offsets against all parents and then move the div to exactly that position, also you have to calculate all scroller positions and then subtract it from the offsets to get the actual position. The positioning then can be done relatively save because we are relativ to the body not to any other element and no boxing bugs can change our calculated position! > inputCalendar Popup positioned incorrectly in scrollable div > > > Key: TOMAHAWK-205 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-205 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Calendar >Affects Versions: 1.1.2-SNAPSHOT >Reporter: Geoffrey Longo >Assignee: Werner Punz > > The popup for the inputCalendar is positioned relative to the body of the > page, not the containing div. Therefore, a calendar that is inside a > scrollable div (overflow: auto) may not be positioned correctly if the > containing div's left and top positons are not the same as the body. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TOMAHAWK-1184) Vertical Week Divider incorrectly rendered in IE
[
https://issues.apache.org/jira/browse/TOMAHAWK-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz reopened TOMAHAWK-1184:
---
sorry wanted to set it to resolved
> Vertical Week Divider incorrectly rendered in IE
>
>
> Key: TOMAHAWK-1184
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1184
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
>Affects Versions: 1.1.7-SNAPSHOT
> Environment: Windows XP SP3 w/IE7
>Reporter: Gunther Schmidl
>Assignee: Werner Punz
>Priority: Minor
> Fix For: 1.1.7-SNAPSHOT
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The latest version of popcalendar.js does not correctly render the vertical
> week divider due to a typo in the javascript file.
> The solution is to replace
> org/apache/myfaces/custom/calendar/resource/popcalendar.js line 1217
> dividerCell.setAttribute("rowspan", "7");
> with
> dividerCell.setAttribute("rowSpan", "7");
> and IE will work correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1184) Vertical Week Divider incorrectly rendered in IE
[
https://issues.apache.org/jira/browse/TOMAHAWK-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved TOMAHAWK-1184.
---
Resolution: Fixed
Fixed in 1.1.7 snapshot trunk:
http://svn.apache.org/viewvc?view=rev&revision=619397
> Vertical Week Divider incorrectly rendered in IE
>
>
> Key: TOMAHAWK-1184
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1184
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
>Affects Versions: 1.1.7-SNAPSHOT
> Environment: Windows XP SP3 w/IE7
>Reporter: Gunther Schmidl
>Assignee: Werner Punz
>Priority: Minor
> Fix For: 1.1.7-SNAPSHOT
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The latest version of popcalendar.js does not correctly render the vertical
> week divider due to a typo in the javascript file.
> The solution is to replace
> org/apache/myfaces/custom/calendar/resource/popcalendar.js line 1217
> dividerCell.setAttribute("rowspan", "7");
> with
> dividerCell.setAttribute("rowSpan", "7");
> and IE will work correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-205) inputCalendar Popup positioned incorrectly in scrollable div
[ https://issues.apache.org/jira/browse/TOMAHAWK-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved TOMAHAWK-205. -- Resolution: Fixed Fixed in 1.1.7 snapshot trunk: http://svn.apache.org/viewvc?view=rev&revision=619397 > inputCalendar Popup positioned incorrectly in scrollable div > > > Key: TOMAHAWK-205 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-205 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Calendar >Affects Versions: 1.1.2-SNAPSHOT >Reporter: Geoffrey Longo >Assignee: Werner Punz > > The popup for the inputCalendar is positioned relative to the body of the > page, not the containing div. Therefore, a calendar that is inside a > scrollable div (overflow: auto) may not be positioned correctly if the > containing div's left and top positons are not the same as the body. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-192) not working in IE
[ https://issues.apache.org/jira/browse/TOMAHAWK-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz updated TOMAHAWK-192: - Resolution: Fixed Status: Resolved (was: Patch Available) ok we have two problems here first there were some bugs regarding positioning which are resolved but we still have pending prototype references which have to be removed I will work on this later. I will resolve this isse for now and will reopen another one regarding the pending prototype references! the positioning problems and some popup problems have been resolved in: Fixed in 1.1.7 snapshot trunk: http://svn.apache.org/viewvc?view=rev&revision=619397 the prototype references will be worked on in the following weeks! > not working in IE > --- > > Key: TOMAHAWK-192 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-192 > Project: MyFaces Tomahawk > Issue Type: Task > Components: Calendar > Environment: TOMCAT 5, windows >Reporter: Garima Shrivastava > > I am using for pop up calendar for dates. It works fine in > fire fox but it does not in IE. When I click on the image I see an error at > the bottom of the page "Error on page", after clicking on that error it says > "Object required". I have MyFacesExtensionFilter in web.xml > I have tomahawk1.1.1 and commons-lang2.1 jar. > Any help will be greatly appreciated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-570) Problem showing popup under absolute DIV's
[ https://issues.apache.org/jira/browse/TOMAHAWK-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved TOMAHAWK-570. -- Resolution: Fixed The description is rather vague, I assume it is meant that the popup div does not position itself properly to the parent position. There was a positioning bug in the code which has been resolved. Fixed in 1.1.7 snapshot trunk: http://svn.apache.org/viewvc?view=rev&revision=619397 > Problem showing popup under absolute DIV's > -- > > Key: TOMAHAWK-570 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-570 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Calendar, Date >Affects Versions: 1.1.3 > Environment: Mozilla Firefox 1.5.x and IE 6 >Reporter: Alberto Dominguez >Priority: Minor > > Using some DIV's for templating purposes t:inputDate or t:inputCalendar > doesn't fit the associated fields. I tried to change the DIV CSS style > position attribute but it didn't work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1191) Calendar has prototype.js dependencies
Calendar has prototype.js dependencies -- Key: TOMAHAWK-1191 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1191 Project: MyFaces Tomahawk Issue Type: Bug Components: Calendar Environment: All Reporter: Werner Punz The inputCalendar has prototype.js dependencies, which are not really that necessesary, they cause problems in certain environments which also use the prototype.js in some versions. https://issues.apache.org/jira/browse/TOMAHAWK-192 this issue has been reopend as a new issue because some of the bugs reported in 192 have been fixed! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-796) inputCalendar doesn't work under Opera 9 when renderAsPopup is 'true'
[
https://issues.apache.org/jira/browse/TOMAHAWK-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566587#action_12566587
]
Werner Punz commented on TOMAHAWK-796:
--
Actually opera 9.5 still has some positioning bugs, I was working on the
positioning code today, and
one of my testcases for the new positioning code was three divs nested with
scrollers, some positioning
and a table in between doing another few layouts.
All browsers rendered fine without any browser specific fork:
ie6 and 7, Mozilla 2, Safari 3 aka webkit, only opera again did a
mispositioning,
I will setup a public site somewhere next week and will give opera a bugreport!
> inputCalendar doesn't work under Opera 9 when renderAsPopup is 'true'
> -
>
> Key: TOMAHAWK-796
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-796
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
>Affects Versions: 1.1.3, 1.1.5-SNAPSHOT
> Environment: Windows, Opera 9.02 (also 9.01), Sun Java Runtime
> Environment version 1.4
>Reporter: Safronov Sergey
>Priority: Critical
> Attachments: popcalendar.js
>
>
> after click on calendar image we have errors in Opera error console:
> Event thread: click
> Error:
> Unhandled exception: [Object DOMException]
> code: 5
> message: INVALID_CHARACTER_ERR
> Backtrace:
> Line 124 of linked script
> http://localhost:8080/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11642727/calendar.HtmlCalendarRenderer/popcalendar.js;jsessionid=9B5EA2BE7C36884AD86ABDEC32B2A84E
> iframe = document.createElement(" style='visibility:hidden; position: absolute; top:0px;left:0px;'/>");
> Line 1393 of linked script
> http://localhost:8080/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11642727/calendar.HtmlCalendarRenderer/popcalendar.js;jsessionid=9B5EA2BE7C36884AD86ABDEC32B2A84E
> this._hideElement(this.calendarDiv);
> Line 1282 of linked script
> http://localhost:8080/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11642727/calendar.HtmlCalendarRenderer/popcalendar.js;jsessionid=9B5EA2BE7C36884AD86ABDEC32B2A84E
> this._popUpCalendar_Show(ctl);
> Line 1 of script
> form_3AbeginDateCalendarVar._popUpCalendar(this,
> document.getElementById("form:beginDate"), "dd.MM.");
> At unknown location
> [statement source code not available]
> Timeout thread: delay 200 ms
> Error:
> Unhandled exception: [Object DOMException]
> code: 5
> message: INVALID_CHARACTER_ERR
> Backtrace:
> Line 124 of linked script
> http://localhost:8080/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11642727/calendar.HtmlCalendarRenderer/popcalendar.js;jsessionid=9B5EA2BE7C36884AD86ABDEC32B2A84E
> iframe = document.createElement(" style='visibility:hidden; position: absolute; top:0px;left:0px;'/>");
> Line 1390 of linked script
> http://localhost:8080/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11642727/calendar.HtmlCalendarRenderer/popcalendar.js;jsessionid=9B5EA2BE7C36884AD86ABDEC32B2A84E
> this._hideElement(this.calendarDiv);
> Line 52 of linked script
> http://localhost:8080/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11642727/prototype.PrototypeResourceLoader/prototype.js;jsessionid=9B5EA2BE7C36884AD86ABDEC32B2A84E
> return __method.apply(object, args.concat($A(arguments)));
> At unknown location
> [statement source code not available]
> you can try http://example.irian.at/example-simple-20061123/calendar.jsf
> (MyFaces Tomahawk Examples latest build) to see it.
> --
> Best regards, Sergey
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-735) ForceId does not work in inputCalendar anymore
[ https://issues.apache.org/jira/browse/TOMAHAWK-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved TOMAHAWK-735. -- Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT This issue definitely does not occur in the latest trunk I tried it with a form once forceId set then not set the id is rendered correctly in both cases! I will resolve this issue for now! > ForceId does not work in inputCalendar anymore > -- > > Key: TOMAHAWK-735 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-735 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Calendar >Affects Versions: 1.1.3 > Environment: MyFaces 1.1.4, Tomahawk 1.1.3 >Reporter: Rolf Kulemann > Fix For: 1.1.7-SNAPSHOT > > > ForceId does not work anymore. The effect is that the cleintId is always > written instead of the froced id. > I guess the offending code is: > 1.) HtmlCalendarRenderer.encodeEnd > RendererUtils.copyHtmlInputTextAttributes(inputCalendar, inputText); > 2.) RenderUtils.copyHtmlInputTextAttributes > does not copy the foceId property -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1130) Calendar component is not working with Tabbed Pane
[
https://issues.apache.org/jira/browse/TOMAHAWK-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566596#action_12566596
]
Werner Punz commented on TOMAHAWK-1130:
---
There is a better workaround, get the resources out, and push them into a dir
of your webapp and add the manual includes,
you then can use
addResources="false"
to omit the includes for the page (just to get the same behavior in all modes.
This however is a bug, I will investigate it later, but I am not sure if it can
be fixed on the calendar side, it probably
has to be fixed on the Tabbed pane side.
> Calendar component is not working with Tabbed Pane
> --
>
> Key: TOMAHAWK-1130
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1130
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar, Tabbed Pane
>Affects Versions: 1.1.7-SNAPSHOT
> Environment: Windows XP, IE 6.0 & Firefox 2.0, Apache-tomcat 6.0,
>Reporter: Nirav Patel
>
> Assume cal.jsp that renders calendar component. Below is the code snippet I
> used to render it. It works fine when I invoke the page from IE/Firefox.
> value="#{propertyListMB.property.registryCertificateDate}"
> renderAsPopup="true" popupTodayString="today is" popupDateFormat="MM/dd/"
> helpText="MM/DD/" forceId="true"/>
> After that I created tab.jsp that includes cal.jsp as one of its tab. Below
> is the code snippet for it...
>
> rendered="#{propertyValuationMB.propListVisible}" styleClass="pvsTabHeader">
>
>
>
>
>
> Now, if I try to render tab.jsp on IE/Firefox it throws java-script error -
> "org_apache_myfaces_PopupCalendar is undefined".
> My debugging showed that generated HTML code includes required java scripts -
> "calendar.HtmlCalendarRenderer/date.js" and
> "HtmlCalendarRenderer/popcalendar.js" much after in the code before a
> reference to one of its function [org_apache_myfaces_PopupCalendar()] is
> made. Hence, we are getting java-script error.
> But, if you set "serverSideTabSwitch" to "true", surprisingly, it resolves
> the issue.
> Further investigation showed that if I set "serverSideTabSwitch" to true, it
> includes the required java scripts in the header info. Otherwise, it is not
> included in header. Below are the snipped of generated HTML code...
> When "serverSideTabSwitch" is set to "false"
>
>
> Building Valuation
>
>
> When "serverSideTabSwitch" is set to "true"
>
>href="/PVS-PL/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11925166/tabbedpane.HtmlTabbedPaneRenderer/defaultStyles.css"
> type="text/css" />
>href="/PVS-PL/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11925166/calendar.HtmlCalendarRenderer/WH/theme.css"
> type="text/css" />
>href="/PVS-PL/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11925166/calendar.HtmlCalendarRenderer/DB/theme.css"
> type="text/css" />
>src="/PVS-PL/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11925166/prototype.PrototypeResourceLoader/prototype.js">
>
>src="/PVS-PL/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11925166/calendar.HtmlCalendarRenderer/date.js">
>
>src="/PVS-PL/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11925166/calendar.HtmlCalendarRenderer/popcalendar.js">
>
>src="/PVS-PL/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11925166/inputTextHelp.HtmlTextHelpRenderer/inputTextHelp.js">
>
> Property List
>
>
>
> Though, I have temporarily fixed my probelm. But I would like to use
> serverSideSwitch=false for better user experience. Would you please fix the
> issue in libraries or show me some better work around?
> Thanks,
> Nirav.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1107) component does not handle submission via the enter key in IE6
[
https://issues.apache.org/jira/browse/TOMAHAWK-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566593#action_12566593
]
Werner Punz commented on TOMAHAWK-1107:
---
I dont see that as a bug, the inputCalendar just uses a standard input field,
and you will get the exactly same behavior as with a standard input field!
in my testcase there was a fom with a submit button
and the button was triggering fine on enter after editing the field (aka
focusing the field)
of course command links are an entirely different issue.
if you dont get this behavior, check if you get it on normal input fields, you
probably wont!
The correct way to achieve the wanted behavior of course is to add the
onkeypress to the tag,
but as I said I dont see this as a bug, this is a html limitation in itself!
> component does not handle submission via the enter key in
> IE6
> ---
>
> Key: TOMAHAWK-1107
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1107
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
>Affects Versions: 1.1.6
> Environment: Windows XP, IE 6, MyFaces 1.1.5, Tomahawk 1.1.6
>Reporter: Todd Gould
>
> When using a tag such as:
> value="#{alertSummaryController.sinceTime}"
> popupDateFormat="MM/dd/ HH:mm:ss"
> helpText="MM/dd/ HH:mm:ss"
> title="MM/dd/ HH:mm:ss"
> popupSelectDateMessage="Select [date] as date"
> renderAsPopup="true" renderPopupButtonAsImage="true">
> in a JSP, pressing the enter key in the associated text entry field (say
> after manually adjusting the date and/or time) does not produce the desired
> result in IE6. In Firefox, this does work fine - it submits the form and
> applies the specified value. However, in IE 6, this does not result in form
> submission for some reason.
> A work around to achieve the desired affect is to add the following to the
> tag:
> onkeypress="if( event.keyCode == 13 ) { this.form.submit();
> return false; }"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-908) t:div and t::inputCalendar confilict
[
https://issues.apache.org/jira/browse/TOMAHAWK-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566609#action_12566609
]
Werner Punz commented on TOMAHAWK-908:
--
this issue might be resolved by the latest trunk, the positioning code was
broken, it should work now.
give it a try!
> t:div and t::inputCalendar confilict
> -
>
> Key: TOMAHAWK-908
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-908
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
> Environment: Tomahawk1.1.5 and Tomahawk-sandbox1.1.5 Windows XP
> tomcat 5.5.15
>Reporter: Cathy Gates
>
> When I include a calendar within a fieldset using tomahawk 1.5 calendar and
> and tomahawk sandbox fieldset the calendar pop-up window always display at
> the bottom right corner of the screen. When I replace the fieldset with a
> panelGrid everything works fine and the calendar popup window appears near
> the calendar textbox.
> Below is part of the jsp I'm using.
> Any help is appreciated!
>
>
>
> currentDayCellClass="currentDayCell" value="#{companyReport.startDate}"
> renderAsPopup="true" popupTodayString="#{commonMsg.popupTodayString}"
> popupWeekString="#{commonMsg.popupWeekString}"
> renderPopupButtonAsImage="true" helpText="MM/DD/"/>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-410) inputCalendar doesn't respect displayValueOnly attribute and renderAsPopup="false"
[ https://issues.apache.org/jira/browse/TOMAHAWK-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566603#action_12566603 ] Werner Punz commented on TOMAHAWK-410: -- Yes, good question is, this bug is resolvable, but how should it be resolved displayValueOnly falls back into a plain html string, one line that way renderAsPopup="false" occupies a lot of space should the fallback also revert to one line displaying the date? or should it still occupy the space mimicking the original layout but without the links! > inputCalendar doesn't respect displayValueOnly attribute and > renderAsPopup="false" > -- > > Key: TOMAHAWK-410 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-410 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Calendar >Affects Versions: 1.1.3-SNAPSHOT >Reporter: Mike Kienenberger >Priority: Minor > > inputCalendar doesn't respect displayValueOnly attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1051) SelectMany Shuttle javascripted links not properly rendered if url parameter is set
SelectMany Shuttle javascripted links not properly rendered if url parameter is
set
---
Key: TRINIDAD-1051
URL: https://issues.apache.org/jira/browse/TRINIDAD-1051
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.8-core
Environment: All environments
Reporter: Werner Punz
Assignee: Werner Punz
The problem is that the selectmany shuttle component renders its links via href
and javascript and then refers to
org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedActionURI
value = context.getExternalContext().encodeActionURL(value.toString());
While this is a proper way to handle an incoming url in this case it is not
because
if you pass down javascripts and put them into this method incoming url
parameters will be attached
ie
javascript:TrXXX.doMyAction();?myparam=1
This exactly happens in the shuttle component in such a case and renders the
javascript links invalid.
Now:
The solution would be to change the code
in the selectManyShuttleRenderer responsible for rendering the link from
if(href != null) {
renderEncodedActionURI(context, "href", href);
}
to
if(href != null && href.startsWith("javascript:")) {
rw.writeAttribute("href", href, null);
} else {
renderEncodedActionURI(context, "href", href);
}
Problem is the writeAttribute probably also belongs to a base class
any comments by the trinidad core committers on this (Matze?)?
I need feedback before fixing this in the trunk!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1051) SelectMany Shuttle javascripted links not properly rendered if url parameter is set
[
https://issues.apache.org/jira/browse/TRINIDAD-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590325#action_12590325
]
Werner Punz commented on TRINIDAD-1051:
---
Orchestra could be the issue here.
> SelectMany Shuttle javascripted links not properly rendered if url parameter
> is set
> ---
>
> Key: TRINIDAD-1051
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1051
> Project: MyFaces Trinidad
> Issue Type: Bug
>Affects Versions: 1.0.8-core
> Environment: All environments
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The problem is that the selectmany shuttle component renders its links via
> href
> and javascript and then refers to
> org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedActionURI
>value = context.getExternalContext().encodeActionURL(value.toString());
> While this is a proper way to handle an incoming url in this case it is not
> because
> if you pass down javascripts and put them into this method incoming url
> parameters will be attached
> ie
> javascript:TrXXX.doMyAction();?myparam=1
> This exactly happens in the shuttle component in such a case and renders the
> javascript links invalid.
> Now:
> The solution would be to change the code
> in the selectManyShuttleRenderer responsible for rendering the link from
> if(href != null) {
> renderEncodedActionURI(context, "href", href);
> }
> to
> if(href != null && href.startsWith("javascript:")) {
> rw.writeAttribute("href", href, null);
>} else {
> renderEncodedActionURI(context, "href", href);
>}
> Problem is the writeAttribute probably also belongs to a base class
> any comments by the trinidad core committers on this (Matze?)?
> I need feedback before fixing this in the trunk!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1051) SelectMany Shuttle javascripted links not properly rendered if url parameter is set
[
https://issues.apache.org/jira/browse/TRINIDAD-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590328#action_12590328
]
Werner Punz commented on TRINIDAD-1051:
---
I am still not entirely convinced if we dont have a problem here. Orchestra
might have fixed it but what happens with other libs which do the same.
My guess is Trinidad itself should look for javascripts in hrefs and then omit
the encodeActionURL, since technically spoken
in a javascript trigger no other url info should be appended nor the code has
to be altered by other layers!
> SelectMany Shuttle javascripted links not properly rendered if url parameter
> is set
> ---
>
> Key: TRINIDAD-1051
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1051
> Project: MyFaces Trinidad
> Issue Type: Bug
>Affects Versions: 1.0.8-core
> Environment: All environments
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The problem is that the selectmany shuttle component renders its links via
> href
> and javascript and then refers to
> org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedActionURI
>value = context.getExternalContext().encodeActionURL(value.toString());
> While this is a proper way to handle an incoming url in this case it is not
> because
> if you pass down javascripts and put them into this method incoming url
> parameters will be attached
> ie
> javascript:TrXXX.doMyAction();?myparam=1
> This exactly happens in the shuttle component in such a case and renders the
> javascript links invalid.
> Now:
> The solution would be to change the code
> in the selectManyShuttleRenderer responsible for rendering the link from
> if(href != null) {
> renderEncodedActionURI(context, "href", href);
> }
> to
> if(href != null && href.startsWith("javascript:")) {
> rw.writeAttribute("href", href, null);
>} else {
> renderEncodedActionURI(context, "href", href);
>}
> Problem is the writeAttribute probably also belongs to a base class
> any comments by the trinidad core committers on this (Matze?)?
> I need feedback before fixing this in the trunk!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1051) SelectMany Shuttle javascripted links not properly rendered if url parameter is set
[
https://issues.apache.org/jira/browse/TRINIDAD-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590329#action_12590329
]
Werner Punz commented on TRINIDAD-1051:
---
On a second thought there are usecases where this is even viable in javascript
like some context listeners which do filtering for javascript urls etc...
Ok I will close this bug now since it is orchestra related and fixed for 2.0
> SelectMany Shuttle javascripted links not properly rendered if url parameter
> is set
> ---
>
> Key: TRINIDAD-1051
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1051
> Project: MyFaces Trinidad
> Issue Type: Bug
>Affects Versions: 1.0.8-core
> Environment: All environments
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The problem is that the selectmany shuttle component renders its links via
> href
> and javascript and then refers to
> org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedActionURI
>value = context.getExternalContext().encodeActionURL(value.toString());
> While this is a proper way to handle an incoming url in this case it is not
> because
> if you pass down javascripts and put them into this method incoming url
> parameters will be attached
> ie
> javascript:TrXXX.doMyAction();?myparam=1
> This exactly happens in the shuttle component in such a case and renders the
> javascript links invalid.
> Now:
> The solution would be to change the code
> in the selectManyShuttleRenderer responsible for rendering the link from
> if(href != null) {
> renderEncodedActionURI(context, "href", href);
> }
> to
> if(href != null && href.startsWith("javascript:")) {
> rw.writeAttribute("href", href, null);
>} else {
> renderEncodedActionURI(context, "href", href);
>}
> Problem is the writeAttribute probably also belongs to a base class
> any comments by the trinidad core committers on this (Matze?)?
> I need feedback before fixing this in the trunk!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-26) extend the core loading strategies so that they react to the state the annotation reloading is in
[ https://issues.apache.org/jira/browse/EXTSCRIPT-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-26. -- Resolution: Fixed Assignee: Werner Punz > extend the core loading strategies so that they react to the state the > annotation reloading is in > - > > Key: EXTSCRIPT-26 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-26 > Project: MyFaces Extensions Scripting > Issue Type: Sub-task >Reporter: Werner Punz >Assignee: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-26) extend the core loading strategies so that they react to the state the annotation reloading is in
[ https://issues.apache.org/jira/browse/EXTSCRIPT-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778366#action_12778366 ] Werner Punz commented on EXTSCRIPT-26: -- Most if not all JSF2 core annotations now can cope with annotation changes... testcases for all supported annotations have been added but not refactored yet. Whow what a load of work, but I hope it pays off. > extend the core loading strategies so that they react to the state the > annotation reloading is in > - > > Key: EXTSCRIPT-26 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-26 > Project: MyFaces Extensions Scripting > Issue Type: Sub-task >Reporter: Werner Punz >Assignee: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-21) ASM version conflicts
[ https://issues.apache.org/jira/browse/EXTSCRIPT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787819#action_12787819 ] Werner Punz commented on EXTSCRIPT-21: -- We probably can avoid asm entirely by checking the classloaders for the dynamic classes instead of checking the annotations, I will start to work on that very soon > ASM version conflicts > - > > Key: EXTSCRIPT-21 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-21 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz > > ASM seems to be widely used by many libs, the main issue is that ASM itself > does not provide stable APIs between versions, we probably should go with the > source embedding route instead of binary linking, check if we can modify the > build process so that asm is linked as source and refactored into the project > in its own subpackage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-20) dependency injection resolution
[ https://issues.apache.org/jira/browse/EXTSCRIPT-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787821#action_12787821 ] Werner Punz commented on EXTSCRIPT-20: -- Resolved in the latest batch commits (sorry no exact commit numbers) > dependency injection resolution > --- > > Key: EXTSCRIPT-20 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-20 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz > > Currently dependency injection is ignored at reloading level, we should not > do that, we should check if a managed property also has to be reloaded and > instead of traversing the old property we should reload on copyproperties > level -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-20) dependency injection resolution
[ https://issues.apache.org/jira/browse/EXTSCRIPT-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-20. -- Resolution: Fixed Assignee: Werner Punz > dependency injection resolution > --- > > Key: EXTSCRIPT-20 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-20 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz > > Currently dependency injection is ignored at reloading level, we should not > do that, we should check if a managed property also has to be reloaded and > instead of traversing the old property we should reload on copyproperties > level -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-27) myfaces 1.2. example doesn't run on Windoze...
[ https://issues.apache.org/jira/browse/EXTSCRIPT-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787820#action_12787820 ] Werner Punz commented on EXTSCRIPT-27: -- probably a regexp issue due to File.separator being\ > myfaces 1.2. example doesn't run on Windoze... > -- > > Key: EXTSCRIPT-27 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-27 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Matthias Weßendorf >Assignee: Werner Punz > > 2009-12-05 13:46:20.312::WARN: Error starting handlers > java.lang.ExceptionInInitializerError > at > org.apache.myfaces.shared_impl.webapp.webxml.WebXml.init(WebXml.java:243) > at > org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getWebXml(WebXml.java:228) > at > org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:74) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:139) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:332) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:277) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:195) > at > org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: java.lang.StringIndexOutOfBoundsException: String index out of > range: 1 > at java.lang.String.charAt(String.java:687) > at java.util.regex.Matcher.appendReplacement(Matcher.java:703) > at java.util.regex.Matcher.replaceAll(Matcher.java:813) > at java.lang.String.replaceAll(String.java:2190) > at > org.apache.myfaces.script
[jira] Resolved: (EXTSCRIPT-23) Class rescanning upon class reloading to handle changed managed properties or names etc...
[ https://issues.apache.org/jira/browse/EXTSCRIPT-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-23. -- Resolution: Fixed Assignee: Werner Punz > Class rescanning upon class reloading to handle changed managed properties or > names etc... > -- > > Key: EXTSCRIPT-23 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-23 > Project: MyFaces Extensions Scripting > Issue Type: Sub-task >Reporter: Werner Punz >Assignee: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-23) Class rescanning upon class reloading to handle changed managed properties or names etc...
[ https://issues.apache.org/jira/browse/EXTSCRIPT-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787823#action_12787823 ] Werner Punz commented on EXTSCRIPT-23: -- The latest batch commit readjusted the bean loading strategies, the beans are now dropped we wont need this anymore > Class rescanning upon class reloading to handle changed managed properties or > names etc... > -- > > Key: EXTSCRIPT-23 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-23 > Project: MyFaces Extensions Scripting > Issue Type: Sub-task >Reporter: Werner Punz >Assignee: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-24) Source recompilation if a jsf artefact has not been found
[ https://issues.apache.org/jira/browse/EXTSCRIPT-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-24. -- Resolution: Fixed Assignee: Werner Punz > Source recompilation if a jsf artefact has not been found > - > > Key: EXTSCRIPT-24 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-24 > Project: MyFaces Extensions Scripting > Issue Type: Sub-task >Reporter: Werner Punz >Assignee: Werner Punz > > if a jsf artefact cannot be found compile all source files > currently not found in the tracker and then do a full rescan of the new and > changed classes > and update their configuration, deleted ones should be removed from the > configuration -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-24) Source recompilation if a jsf artefact has not been found
[ https://issues.apache.org/jira/browse/EXTSCRIPT-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787825#action_12787825 ] Werner Punz commented on EXTSCRIPT-24: -- the entire compile cycle now happens on request level we now have a better grasp on those things > Source recompilation if a jsf artefact has not been found > - > > Key: EXTSCRIPT-24 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-24 > Project: MyFaces Extensions Scripting > Issue Type: Sub-task >Reporter: Werner Punz >Assignee: Werner Punz > > if a jsf artefact cannot be found compile all source files > currently not found in the tracker and then do a full rescan of the new and > changed classes > and update their configuration, deleted ones should be removed from the > configuration -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-1) Make extensions-scripting compatible with myfaces 2.0
[ https://issues.apache.org/jira/browse/EXTSCRIPT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787826#action_12787826 ] Werner Punz commented on EXTSCRIPT-1: - works more or less but I will open issues for what is pending > Make extensions-scripting compatible with myfaces 2.0 > - > > Key: EXTSCRIPT-1 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-1 > Project: MyFaces Extensions Scripting > Issue Type: New Feature > Environment: Make the scripting extensions compatible with myfaces 2.0 >Reporter: Werner Punz >Assignee: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-28) Session bean multiuser reloading
Session bean multiuser reloading Key: EXTSCRIPT-28 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-28 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Currently the sessionb bean handling probably is not correctly handled over all sessions in the system, we have to add some mechanism which drops all session beans the one from the user triggering the recompile, and from the others at the next request -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-1) Make extensions-scripting compatible with myfaces 2.0
[ https://issues.apache.org/jira/browse/EXTSCRIPT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-1. - Resolution: Fixed > Make extensions-scripting compatible with myfaces 2.0 > - > > Key: EXTSCRIPT-1 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-1 > Project: MyFaces Extensions Scripting > Issue Type: New Feature > Environment: Make the scripting extensions compatible with myfaces 2.0 >Reporter: Werner Punz >Assignee: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-30) Add JSF 2 annotation support to groovy
Add JSF 2 annotation support to groovy -- Key: EXTSCRIPT-30 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-30 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz The JSF2 annotation support currently is only available for dynamic java, we need it for groovy as well, since we now have the infrastructure in place we have to add the scanning mechanisms for groovy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-29) Multiuser compile
Multiuser compile - Key: EXTSCRIPT-29 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-29 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz We have to check of the compile trigger locks correctly for multiuser operations, due to the fact that windows otherwise might run into file locking issues (shared temp dir) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-31) File change daemon is flakey
File change daemon is flakey Key: EXTSCRIPT-31 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-31 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz In conjunction with compile errors, a compile error should keep a class tainted, currently the class is untainted. Also we have hangs of the file change daemon which have to be investigated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-32) Classloader reinitialisation frequency
Classloader reinitialisation frequency -- Key: EXTSCRIPT-32 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-32 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Priority: Minor To avoid class registration issues, our class loader recreation frequency is too high, we should trim it down to the compile case and rescan case (aka a check if a class is already registered over the classloader in the request and then recreate it for the reregistration of the same class within the same request) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-33) Move annotation scanning from source to binary
Move annotation scanning from source to binary -- Key: EXTSCRIPT-33 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-33 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Move the source scanning over to binary scanning to get rid of the qdox dependency, now that we have full compile cycles this is a minor task. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-34) Refresh adaptors not entirely done yet
Refresh adaptors not entirely done yet -- Key: EXTSCRIPT-34 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-34 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Priority: Minor while most interfaces now refresh properly according to their structure, artefacts with delegators have to be coded yet in their proper refresh behavior -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-31) File change daemon is flakey
[ https://issues.apache.org/jira/browse/EXTSCRIPT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-31. -- Resolution: Fixed Assignee: Werner Punz > File change daemon is flakey > > > Key: EXTSCRIPT-31 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-31 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz >Assignee: Werner Punz > > In conjunction with compile errors, a compile error should keep a class > tainted, currently the class is untainted. Also we have hangs of the file > change daemon which have to be investigated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-28) Session bean multiuser reloading
[ https://issues.apache.org/jira/browse/EXTSCRIPT-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-28. -- Resolution: Fixed Assignee: Werner Punz > Session bean multiuser reloading > > > Key: EXTSCRIPT-28 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-28 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz >Assignee: Werner Punz > > Currently the sessionb bean handling probably is not correctly handled over > all sessions in the system, we have to add some mechanism which drops all > session beans the one from the user triggering the recompile, and from the > others at the next request -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-28) Session bean multiuser reloading
[ https://issues.apache.org/jira/browse/EXTSCRIPT-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789897#action_12789897 ] Werner Punz commented on EXTSCRIPT-28: -- done but has to be tested yet > Session bean multiuser reloading > > > Key: EXTSCRIPT-28 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-28 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz >Assignee: Werner Punz > > Currently the sessionb bean handling probably is not correctly handled over > all sessions in the system, we have to add some mechanism which drops all > session beans the one from the user triggering the recompile, and from the > others at the next request -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-35) unify the compiler interfaces
unify the compiler interfaces - Key: EXTSCRIPT-35 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-35 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Priority: Minor we currently use two different compiler interfaces which are historically grown out of two codebases, for now we use a facade which islates the two, we have to unify the compiler interface into one which is shared over all engines. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790041#action_12790041
]
Werner Punz commented on EXTSCRIPT-36:
--
Ok I have to investigate that, aclass should not be null, but do a quick fix...
the reload on components only can happen anyway if you do a full refresh on the
page (that is expected behavior)
So the fix wont break anything.
I will investigate the error on friday when I can work on the project again, so
please leave the bug open!
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.reloadInvoke(MethodLevelReloadingHandler.java:87)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.invoke(MethodLevelReloadingHandler.java:6
[jira] Issue Comment Edited: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790041#action_12790041
]
Werner Punz edited comment on EXTSCRIPT-36 at 12/14/09 8:41 AM:
Ok I have to investigate that, aclass should not be null, but do a quick fix...
the reload on components only can happen anyway if the component tree is built
cleanly anewa instead of going through a post lifecycle from the same page
(that is expected behavior, due to the restore mechanism in the component which
gets out of sync with the components attributes)
So the fix wont break anything.
I will investigate the error on friday when I can work on the project again, so
please leave the bug open!
was (Author: werpu):
Ok I have to investigate that, aclass should not be null, but do a quick
fix...
the reload on components only can happen anyway if you do a full refresh on the
page (that is expected behavior)
So the fix wont break anything.
I will investigate the error on friday when I can work on the project again, so
please leave the bug open!
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(H
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790052#action_12790052
]
Werner Punz commented on EXTSCRIPT-36:
--
Ok this issue is reproducable in a Unix environment as well, the quick fix is
an NPE check in the affected class, but I have to investigate why aClass is
null at all which it should not be!
I will investigate the issue asap (either today in the evening or on friday as
I said)
Thanks for reporting the bug.
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.reloadInvoke(MethodLevelReloadingHandler.java:87)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.invoke(MethodLevelReloadingHandler.java:65)
> at $Proxy6.va
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790374#action_12790374
]
Werner Punz commented on EXTSCRIPT-36:
--
Hello dont touch those, they are for interface type artefacts which are
stateless the components are none of those...
The issue here simply is another one, let me debug into it and fix it, and dont
worry for now with it, we are not even alpha so issues like this can crop up ;-)
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.reloadInvoke(MethodLevelReloadingHandler.java:87)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.invoke(MethodLevelReloadingHandler.java:65)
> at $Proxy6.validate(Unknown Source)
>
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790375#action_12790375
]
Werner Punz commented on EXTSCRIPT-36:
--
Actually both are soon to be removed, since I dont use them anyore (at least
not the constructor reloading, hence this broken code there)
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.reloadInvoke(MethodLevelReloadingHandler.java:87)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.invoke(MethodLevelReloadingHandler.java:65)
> at $Proxy6.validate(Unknown Source)
> at
> javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:159)
> at javax.faces.component.UIInput.validateValue(UI
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790383#action_12790383
]
Werner Punz commented on EXTSCRIPT-36:
--
Ok short explanation, the method level reloading handler is for flyweight
interface exposing classes and for classes which generally are stateless and
are bound by interface definitions,
I changed some parts of the classloading recently to fix a bug seems I
introduced another one in this area.
The method level reloading handler is currently used, but I think of
eliminating it in the long run for performance reasons (who needs a reload on
every method call)
The Constructor level reloading handler has never been used afair and is
incorrect codewise.
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
> at
> org.
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790389#action_12790389
]
Werner Punz commented on EXTSCRIPT-36:
--
Ok the issue seems to be improper serialisation code in the
MethodLevelReloadingHandler
It gets restored but some attributes are nulled and then the code fails.
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.reloadInvoke(MethodLevelReloadingHandler.java:87)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.invoke(MethodLevelReloadingHandler.java:65)
> at $Proxy6.validate(Unknown Source)
> at
> javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:159)
> at javax.faces.componen
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790628#action_12790628
]
Werner Punz commented on EXTSCRIPT-36:
--
Ok I found the issue, it as too much proxying, validators and converters are
implicit parts of the component tree attached to the components, if a reloading
proxy is created on them it survives exactly one lifecycle. The Lifetime of
those artefacts is similar to the components, aka refreshed upon a full tree
rebuild.
the fix is simple but I am not sure if I can commit it:
public Validator createValidator(String s) throws FacesException {
weaveDelegate();
Validator retVal = _delegate.createValidator(s);
if (WeavingContext.isDynamic(retVal.getClass()) &&
!Proxy.isProxyClass(retVal.getClass())) {
retVal = (Validator) reloadInstance(retVal,
ScriptingConst.ARTEFACT_TYPE_VALIDATOR); }
return retVal;
}
I will fix it on the code, but I am not sure if I manage a commit today due to
private circumstances (first birthday of my son)
Give it simply a try and remember the validator is refreshed only
if you do a full tree rebuild, the same applies to components as well!
This is a limitation imposed by JSF and unless we do dynamic class rewriting on
those artefacts this cannot be changed!
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.conte
[jira] Issue Comment Edited: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790628#action_12790628
]
Werner Punz edited comment on EXTSCRIPT-36 at 12/15/09 9:16 AM:
Ok I found the issue, it as too much proxying, validators and converters are
implicit parts of the component tree attached to the components, if a reloading
proxy is created on them it survives exactly one lifecycle. The Lifetime of
those artefacts is similar to the components, aka refreshed upon a full tree
rebuild.
the fix is simple but I am not sure if I can commit it:
public Validator createValidator(String s) throws FacesException {
weaveDelegate();
Validator retVal = _delegate.createValidator(s);
if (WeavingContext.isDynamic(retVal.getClass()) &&
!Proxy.isProxyClass(retVal.getClass())) {
retVal = (Validator) reloadInstance(retVal,
ScriptingConst.ARTEFACT_TYPE_VALIDATOR);
}
return retVal;
}
I will fix it on the code, but I am not sure if I manage a commit today due to
private circumstances (first birthday of my son)
Give it simply a try and remember the validator is refreshed only
if you do a full tree rebuild, the same applies to components as well!
This is a limitation imposed by JSF and unless we do dynamic class rewriting on
those artefacts this cannot be changed!
was (Author: werpu):
Ok I found the issue, it as too much proxying, validators and converters
are implicit parts of the component tree attached to the components, if a
reloading proxy is created on them it survives exactly one lifecycle. The
Lifetime of those artefacts is similar to the components, aka refreshed upon a
full tree rebuild.
the fix is simple but I am not sure if I can commit it:
public Validator createValidator(String s) throws FacesException {
weaveDelegate();
Validator retVal = _delegate.createValidator(s);
if (WeavingContext.isDynamic(retVal.getClass()) &&
!Proxy.isProxyClass(retVal.getClass())) {
retVal = (Validator) reloadInstance(retVal,
ScriptingConst.ARTEFACT_TYPE_VALIDATOR); }
return retVal;
}
I will fix it on the code, but I am not sure if I manage a commit today due to
private circumstances (first birthday of my son)
Give it simply a try and remember the validator is refreshed only
if you do a full tree rebuild, the same applies to components as well!
This is a limitation imposed by JSF and unless we do dynamic class rewriting on
those artefacts this cannot be changed!
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
>
[jira] Issue Comment Edited: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790628#action_12790628
]
Werner Punz edited comment on EXTSCRIPT-36 at 12/15/09 9:17 AM:
Ok I found the issue, it as too much proxying, validators and converters are
implicit parts of the component tree attached to the components, if a reloading
proxy is created on them it survives exactly one lifecycle. The Lifetime of
those artefacts is similar to the components, aka refreshed upon a full tree
rebuild.
the fix is simple but I am not sure if I can commit it:
public Validator createValidator(String s) throws FacesException {
weaveDelegate();
Validator retVal = _delegate.createValidator(s);
if (WeavingContext.isDynamic(retVal.getClass()) &&
!Proxy.isProxyClass(retVal.getClass())) {
retVal = (Validator) reloadInstance(retVal,
ScriptingConst.ARTEFACT_TYPE_VALIDATOR);
}
return retVal;
}
I will fix it on the code, but I am not sure if I manage a commit today due to
private circumstances (first birthday of my son)
Give it simply a try and remember the validator is refreshed only
if you do a full tree rebuild, the same applies to components as well!
This is a limitation imposed by JSF and unless we do dynamic class rewriting on
those artefacts this cannot be changed!
was (Author: werpu):
Ok I found the issue, it as too much proxying, validators and converters
are implicit parts of the component tree attached to the components, if a
reloading proxy is created on them it survives exactly one lifecycle. The
Lifetime of those artefacts is similar to the components, aka refreshed upon a
full tree rebuild.
the fix is simple but I am not sure if I can commit it:
public Validator createValidator(String s) throws FacesException {
weaveDelegate();
Validator retVal = _delegate.createValidator(s);
if (WeavingContext.isDynamic(retVal.getClass()) &&
!Proxy.isProxyClass(retVal.getClass())) {
retVal = (Validator) reloadInstance(retVal,
ScriptingConst.ARTEFACT_TYPE_VALIDATOR);
}
return retVal;
}
I will fix it on the code, but I am not sure if I manage a commit today due to
private circumstances (first birthday of my son)
Give it simply a try and remember the validator is refreshed only
if you do a full tree rebuild, the same applies to components as well!
This is a limitation imposed by JSF and unless we do dynamic class rewriting on
those artefacts this cannot be changed!
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790686#action_12790686
]
Werner Punz commented on EXTSCRIPT-36:
--
resolved
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.reloadInvoke(MethodLevelReloadingHandler.java:87)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.invoke(MethodLevelReloadingHandler.java:65)
> at $Proxy6.validate(Unknown Source)
> at
> javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:159)
> at javax.faces.component.UIInput.validateValue(UIInput.java:357)
> at javax.faces.component.UIInput.validate(UIInput.java:405)
> ... 35 more
> The debugger says that ac
[jira] Created: (EXTSCRIPT-37) compiler tests broken
compiler tests broken - Key: EXTSCRIPT-37 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-37 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Some commit in the recent days broke the compiler tests... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved EXTSCRIPT-36.
--
Resolution: Fixed
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.reloadInvoke(MethodLevelReloadingHandler.java:87)
> at
> org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.invoke(MethodLevelReloadingHandler.java:65)
> at $Proxy6.validate(Unknown Source)
> at
> javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:159)
> at javax.faces.component.UIInput.validateValue(UIInput.java:357)
> at javax.faces.component.UIInput.validate(UIInput.java:405)
> ... 35 more
> The debugger says that aclass is null.
> Since this statement is o
[jira] Commented: (EXTSCRIPT-37) compiler tests broken
[ https://issues.apache.org/jira/browse/EXTSCRIPT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790701#action_12790701 ] Werner Punz commented on EXTSCRIPT-37: -- The project still works, but someone has checked in new compiler tests as it seems, which fail, please use -Dmaven.test.skip=true until this is resolved, I will look into this issue tomorrow and will fix the tests or the underlying cause! > compiler tests broken > - > > Key: EXTSCRIPT-37 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-37 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz > > Some commit in the recent days broke the compiler tests... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-37) compiler tests broken
[ https://issues.apache.org/jira/browse/EXTSCRIPT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790741#action_12790741 ] Werner Punz commented on EXTSCRIPT-37: -- Ok I have deactivated the test, since the code which is triggered is not yet enabled in the core I guess disabling it is valid ! I will notfiy the author of the code about it! > compiler tests broken > - > > Key: EXTSCRIPT-37 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-37 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz > > Some commit in the recent days broke the compiler tests... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-38) NPE after reloading NavigationHandler
[ https://issues.apache.org/jira/browse/EXTSCRIPT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790957#action_12790957 ] Werner Punz commented on EXTSCRIPT-38: -- Will fix this tomorrow... > NPE after reloading NavigationHandler > - > > Key: EXTSCRIPT-38 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-38 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Jan-Kees van Andel >Assignee: Werner Punz > > I see the explanation in the createMethodReloadingProxyFromObject JavaDocs, > but since the example crashes, I thought, let's file this issue anyway. > When a new NavigationHandler is loaded and I click on a button in the example > page, I get the following NPE (because _delegate is null): > java.lang.NullPointerException > at > org.apache.myfaces.scripting.core.reloading.SimpleReloadingStrategy.reload(SimpleReloadingStrategy.java:70) > at > org.apache.myfaces.scripting.core.reloading.GlobalReloadingStrategy.reload(GlobalReloadingStrategy.java:79) > at > org.apache.myfaces.scripting.api.BaseWeaver.reloadScriptingInstance(BaseWeaver.java:98) > at > org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingInstance(CoreWeaver.java:62) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.weaveDelegate(NavigationHandlerProxy.java:36) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.handleNavigation(NavigationHandlerProxy.java:45) > at > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:82) > at javax.faces.component.UICommand.broadcast(UICommand.java:127) > at > javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:369) > at javax.faces.component.UIViewRoot.process(UIViewRoot.java:264) > at > javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:153) > at > org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) > at > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074) > at > org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) > at > org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:50) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-38) NPE after reloading NavigationHandler
[ https://issues.apache.org/jira/browse/EXTSCRIPT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791275#action_12791275 ] Werner Punz commented on EXTSCRIPT-38: -- Ok this issue is partially a bug in my code and partially a groovy code related bug. I did not pass the weaver to the groovy reloading strategy, but the issue is there is a groovy bug were a super(parameter) is not set properly and instead super() is called. I had to work around that one on 2-3 occasions as well. I will fix both things and the next commit should pick the nav handler properly up! > NPE after reloading NavigationHandler > - > > Key: EXTSCRIPT-38 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-38 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Jan-Kees van Andel >Assignee: Werner Punz > > I see the explanation in the createMethodReloadingProxyFromObject JavaDocs, > but since the example crashes, I thought, let's file this issue anyway. > When a new NavigationHandler is loaded and I click on a button in the example > page, I get the following NPE (because _delegate is null): > java.lang.NullPointerException > at > org.apache.myfaces.scripting.core.reloading.SimpleReloadingStrategy.reload(SimpleReloadingStrategy.java:70) > at > org.apache.myfaces.scripting.core.reloading.GlobalReloadingStrategy.reload(GlobalReloadingStrategy.java:79) > at > org.apache.myfaces.scripting.api.BaseWeaver.reloadScriptingInstance(BaseWeaver.java:98) > at > org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingInstance(CoreWeaver.java:62) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.weaveDelegate(NavigationHandlerProxy.java:36) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.handleNavigation(NavigationHandlerProxy.java:45) > at > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:82) > at javax.faces.component.UICommand.broadcast(UICommand.java:127) > at > javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:369) > at javax.faces.component.UIViewRoot.process(UIViewRoot.java:264) > at > javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:153) > at > org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) > at > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074) > at > org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) > at > org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:50) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) -- This messa
[jira] Resolved: (EXTSCRIPT-38) NPE after reloading NavigationHandler
[ https://issues.apache.org/jira/browse/EXTSCRIPT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-38. -- Resolution: Fixed > NPE after reloading NavigationHandler > - > > Key: EXTSCRIPT-38 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-38 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Jan-Kees van Andel >Assignee: Werner Punz > > I see the explanation in the createMethodReloadingProxyFromObject JavaDocs, > but since the example crashes, I thought, let's file this issue anyway. > When a new NavigationHandler is loaded and I click on a button in the example > page, I get the following NPE (because _delegate is null): > java.lang.NullPointerException > at > org.apache.myfaces.scripting.core.reloading.SimpleReloadingStrategy.reload(SimpleReloadingStrategy.java:70) > at > org.apache.myfaces.scripting.core.reloading.GlobalReloadingStrategy.reload(GlobalReloadingStrategy.java:79) > at > org.apache.myfaces.scripting.api.BaseWeaver.reloadScriptingInstance(BaseWeaver.java:98) > at > org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingInstance(CoreWeaver.java:62) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.weaveDelegate(NavigationHandlerProxy.java:36) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.handleNavigation(NavigationHandlerProxy.java:45) > at > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:82) > at javax.faces.component.UICommand.broadcast(UICommand.java:127) > at > javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:369) > at javax.faces.component.UIViewRoot.process(UIViewRoot.java:264) > at > javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:153) > at > org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) > at > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074) > at > org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) > at > org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:50) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-38) NPE after reloading NavigationHandler
[ https://issues.apache.org/jira/browse/EXTSCRIPT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791289#action_12791289 ] Werner Punz commented on EXTSCRIPT-38: -- Done, partially caused by a bug in the groovy2java stub compiler, I have worked around that one. > NPE after reloading NavigationHandler > - > > Key: EXTSCRIPT-38 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-38 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Jan-Kees van Andel >Assignee: Werner Punz > > I see the explanation in the createMethodReloadingProxyFromObject JavaDocs, > but since the example crashes, I thought, let's file this issue anyway. > When a new NavigationHandler is loaded and I click on a button in the example > page, I get the following NPE (because _delegate is null): > java.lang.NullPointerException > at > org.apache.myfaces.scripting.core.reloading.SimpleReloadingStrategy.reload(SimpleReloadingStrategy.java:70) > at > org.apache.myfaces.scripting.core.reloading.GlobalReloadingStrategy.reload(GlobalReloadingStrategy.java:79) > at > org.apache.myfaces.scripting.api.BaseWeaver.reloadScriptingInstance(BaseWeaver.java:98) > at > org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingInstance(CoreWeaver.java:62) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.weaveDelegate(NavigationHandlerProxy.java:36) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.handleNavigation(NavigationHandlerProxy.java:45) > at > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:82) > at javax.faces.component.UICommand.broadcast(UICommand.java:127) > at > javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:369) > at javax.faces.component.UIViewRoot.process(UIViewRoot.java:264) > at > javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:153) > at > org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) > at > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) > at > org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074) > at > org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) > at > org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:50) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-21) ASM version conflicts
[ https://issues.apache.org/jira/browse/EXTSCRIPT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791348#action_12791348 ] Werner Punz commented on EXTSCRIPT-21: -- Done, the class rewriting code is dropped we simply check for the correct classloader having loaded the class > ASM version conflicts > - > > Key: EXTSCRIPT-21 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-21 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz >Assignee: Werner Punz > > ASM seems to be widely used by many libs, the main issue is that ASM itself > does not provide stable APIs between versions, we probably should go with the > source embedding route instead of binary linking, check if we can modify the > build process so that asm is linked as source and refactored into the project > in its own subpackage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-29) Multiuser compile
[ https://issues.apache.org/jira/browse/EXTSCRIPT-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791350#action_12791350 ] Werner Punz commented on EXTSCRIPT-29: -- Ok after checking out the latest checkins, I have to say we probably should wait until Bernhard has merged his code, there might be some general overhaul of the compiler /classloader part coming, after that we will tackle this problem (which is partially tackled by his code already) > Multiuser compile > - > > Key: EXTSCRIPT-29 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-29 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz > > We have to check of the compile trigger locks correctly for multiuser > operations, due to the fact that windows otherwise might run into file > locking issues (shared temp dir) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-21) ASM version conflicts
[ https://issues.apache.org/jira/browse/EXTSCRIPT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-21. -- Resolution: Fixed Assignee: Werner Punz > ASM version conflicts > - > > Key: EXTSCRIPT-21 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-21 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz >Assignee: Werner Punz > > ASM seems to be widely used by many libs, the main issue is that ASM itself > does not provide stable APIs between versions, we probably should go with the > source embedding route instead of binary linking, check if we can modify the > build process so that asm is linked as source and refactored into the project > in its own subpackage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-33) Move annotation scanning from source to binary
[ https://issues.apache.org/jira/browse/EXTSCRIPT-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-33. -- Resolution: Fixed Assignee: Werner Punz > Move annotation scanning from source to binary > -- > > Key: EXTSCRIPT-33 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-33 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz > > Move the source scanning over to binary scanning to get rid of the qdox > dependency, now that we have full compile cycles this is a minor task. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-33) Move annotation scanning from source to binary
[ https://issues.apache.org/jira/browse/EXTSCRIPT-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791387#action_12791387 ] Werner Punz commented on EXTSCRIPT-33: -- resolved the entire qdox dependency now is eliminated the example still works, now we can add the scanning mechanism to groovy as well > Move annotation scanning from source to binary > -- > > Key: EXTSCRIPT-33 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-33 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz > > Move the source scanning over to binary scanning to get rid of the qdox > dependency, now that we have full compile cycles this is a minor task. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-30) Add JSF 2 annotation support to groovy
[ https://issues.apache.org/jira/browse/EXTSCRIPT-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791439#action_12791439 ] Werner Punz commented on EXTSCRIPT-30: -- done > Add JSF 2 annotation support to groovy > -- > > Key: EXTSCRIPT-30 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-30 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz > > The JSF2 annotation support currently is only available for dynamic java, we > need it for groovy as well, since we now have the infrastructure in place we > have to add the scanning mechanisms for groovy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-30) Add JSF 2 annotation support to groovy
[ https://issues.apache.org/jira/browse/EXTSCRIPT-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-30. -- Resolution: Fixed Assignee: Werner Punz > Add JSF 2 annotation support to groovy > -- > > Key: EXTSCRIPT-30 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-30 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz > > The JSF2 annotation support currently is only available for dynamic java, we > need it for groovy as well, since we now have the infrastructure in place we > have to add the scanning mechanisms for groovy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-39) Add class dependency scanning and resolution
Add class dependency scanning and resolution Key: EXTSCRIPT-39 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-39 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Up until now we tried to resolve the dependencies via jsf artefacts, that only works out partially. Constructs like renderer which directly cast components in their code fail with this approach, a direct class dependency scanning system has to be added which can improve the currently implemented tainting algorithm, by also allowing to taint dependend classes on cast and import level, instead of plain jsf level. For the reload algorithms nothing changes, just the current tainting algorithm will be improved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-39) Add class dependency scanning and resolution
[ https://issues.apache.org/jira/browse/EXTSCRIPT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-39. -- Resolution: Fixed Assignee: Werner Punz > Add class dependency scanning and resolution > > > Key: EXTSCRIPT-39 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-39 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz > > Up until now we tried to resolve the dependencies via jsf artefacts, that > only works out partially. Constructs like renderer which directly cast > components in their code fail with this approach, a direct class dependency > scanning system has to be added which can improve the currently implemented > tainting algorithm, by also allowing to taint dependend classes on cast and > import level, instead of plain jsf level. For the reload algorithms nothing > changes, just the current tainting algorithm will be improved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-39) Add class dependency scanning and resolution
[ https://issues.apache.org/jira/browse/EXTSCRIPT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794561#action_12794561 ] Werner Punz commented on EXTSCRIPT-39: -- resolved the dependency scanning is now in, and works as expected > Add class dependency scanning and resolution > > > Key: EXTSCRIPT-39 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-39 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz > > Up until now we tried to resolve the dependencies via jsf artefacts, that > only works out partially. Constructs like renderer which directly cast > components in their code fail with this approach, a direct class dependency > scanning system has to be added which can improve the currently implemented > tainting algorithm, by also allowing to taint dependend classes on cast and > import level, instead of plain jsf level. For the reload algorithms nothing > changes, just the current tainting algorithm will be improved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-32) Classloader reinitialisation frequency
[ https://issues.apache.org/jira/browse/EXTSCRIPT-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-32. -- Resolution: Fixed Assignee: Werner Punz > Classloader reinitialisation frequency > -- > > Key: EXTSCRIPT-32 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-32 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > > To avoid class registration issues, our class loader recreation frequency is > too high, we should trim it down to the compile case and rescan case (aka a > check if a class is already registered over the classloader in the request > and then recreate it for the reregistration of the same class within the same > request) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-34) Refresh adaptors not entirely done yet
[ https://issues.apache.org/jira/browse/EXTSCRIPT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-34. -- Resolution: Fixed Assignee: Werner Punz > Refresh adaptors not entirely done yet > -- > > Key: EXTSCRIPT-34 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-34 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > > while most interfaces now refresh properly according to their structure, > artefacts with delegators have to be coded yet in their proper refresh > behavior -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-40) Reloading for system events missing
Reloading for system events missing --- Key: EXTSCRIPT-40 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-40 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Somehow the system events have slipped under the radar, they need a reload binding as well in the jsf2 submodule -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-41) Write the documentation
Write the documentation --- Key: EXTSCRIPT-41 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-41 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-41) Write the documentation
[ https://issues.apache.org/jira/browse/EXTSCRIPT-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797312#action_12797312 ] Werner Punz commented on EXTSCRIPT-41: -- done on the wiki for the initial version later on snapshots of the wiki pages will be moved into the official documentations, the link for the wiki version is: http://wiki.apache.org/myfaces/Extensions/Scripting > Write the documentation > --- > > Key: EXTSCRIPT-41 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-41 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-42) Add Resource handlers
Add Resource handlers - Key: EXTSCRIPT-42 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-42 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Add Resource handlers on facelets and JSF level so that redirection of resource pickup paths to our source paths become possible without symlinking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-42) Add Resource handlers
[ https://issues.apache.org/jira/browse/EXTSCRIPT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798402#action_12798402 ] Werner Punz commented on EXTSCRIPT-42: -- Done > Add Resource handlers > - > > Key: EXTSCRIPT-42 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-42 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > > Add Resource handlers on facelets and JSF level so that redirection of > resource pickup paths to our source paths become possible > without symlinking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-42) Add Resource handlers
[ https://issues.apache.org/jira/browse/EXTSCRIPT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-42. -- Resolution: Fixed > Add Resource handlers > - > > Key: EXTSCRIPT-42 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-42 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > > Add Resource handlers on facelets and JSF level so that redirection of > resource pickup paths to our source paths become possible > without symlinking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
