[jira] [Created] (DELTASPIKE-452) Provide Bridge for JSF SystemEvents
Thomas Andraschko created DELTASPIKE-452: Summary: Provide Bridge for JSF SystemEvents Key: DELTASPIKE-452 URL: https://issues.apache.org/jira/browse/DELTASPIKE-452 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko To allow observing of e.g. the PostConstructApplicationEvent Sample: @Observers PostConstructApplicationEvent event I will provide an patch later. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DELTASPIKE-452) Provide Bridge for JSF SystemEvents
[ https://issues.apache.org/jira/browse/DELTASPIKE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-452: - Attachment: 452#2.patch Added Deactivatable Provide Bridge for JSF SystemEvents --- Key: DELTASPIKE-452 URL: https://issues.apache.org/jira/browse/DELTASPIKE-452 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Attachments: 452#2.patch, 452.patch To allow observing of e.g. the PostConstructApplicationEvent Sample: @Observers PostConstructApplicationEvent event I will provide an patch later. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans
Thomas Andraschko created DELTASPIKE-453: Summary: Provide @Eager for ApplicationScoped beans Key: DELTASPIKE-453 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-453: - Attachment: 453.patch Provide @Eager for ApplicationScoped beans -- Key: DELTASPIKE-453 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Thomas Andraschko Attachments: 453.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13834685#comment-13834685 ] Thomas Andraschko commented on DELTASPIKE-453: -- I think it's useful for users, which might migrate directly from JSF2. They just need to replace: @ManagedBean(eager = true) with @Named @Eager. Maybe we should start a vote about it. Provide @Eager for ApplicationScoped beans -- Key: DELTASPIKE-453 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Thomas Andraschko Attachments: 453.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DELTASPIKE-454) Provide a ClientWindowRenderMode similiar to CODI
Thomas Andraschko created DELTASPIKE-454: Summary: Provide a ClientWindowRenderMode similiar to CODI Key: DELTASPIKE-454 URL: https://issues.apache.org/jira/browse/DELTASPIKE-454 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Without LoadingScreen, JS, HTML and else. Its stable and works fine. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836702#comment-13836702 ] Thomas Andraschko commented on DELTASPIKE-453: -- +1 Romain It may not work for some special cases but it works fine for normal use cases and i never had a problem with it. Provide @Eager for ApplicationScoped beans -- Key: DELTASPIKE-453 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Thomas Andraschko Attachments: 453.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-475) auto. registration of jobs with cron-expressions
[ https://issues.apache.org/jira/browse/DELTASPIKE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855131#comment-13855131 ] Thomas Andraschko commented on DELTASPIKE-475: -- +1 Romain auto. registration of jobs with cron-expressions Key: DELTASPIKE-475 URL: https://issues.apache.org/jira/browse/DELTASPIKE-475 Project: DeltaSpike Issue Type: New Feature Components: Scheduler Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.6 includes: - support of any scheduler which allows to register jobs based on cron-expressions - default integration with quartz -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-499) Minify javascripts on release build
Thomas Andraschko created DELTASPIKE-499: Summary: Minify javascripts on release build Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-499) Minify javascripts on release build
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869344#comment-13869344 ] Thomas Andraschko commented on DELTASPIKE-499: -- +1 I will do that via a custom ResourceHandler Minify javascripts on release build --- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (DELTASPIKE-446) windowhandler.js doesn't handle nested ajax calls
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-446: Assignee: Thomas Andraschko (was: Mark Struberg) windowhandler.js doesn't handle nested ajax calls - Key: DELTASPIKE-446 URL: https://issues.apache.org/jira/browse/DELTASPIKE-446 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: JBoss AS 7.2 / EAP 6.1 Reporter: Gerald Turner Assignee: Thomas Andraschko I get the exception org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped from a commandButton ajax call that is nested in a form that had been updated by another commandLink ajax call. These pages had been working with CODI. Scenario is a delete confirmation dialog, using PrimeFaces (p:dialog dynamic=true may be the culprit): I have a p:dataTable, with a column with a p:commandLink (Delete), this link updates a p:dialog (Are you sure?). The p:dialog contains a p:commandButton (Yes). Both the contents of the dialog and the actionListener of the commandButton access a @WindowScoped bean. Tracing the XHR POSTs, I see dsPostWindowId being sent when the first delete button is click, and it is not present with the final confirmation button is clicked. Scrutinizing over windowhandler.js, I can imagine that when the page is first loaded, 'jsf.ajax.addOnEvent(ajaxOnClick)' works it's magic and 'applyWindowId()' is effective for the first ajax call, but then the page has new elements which have not been decorated, so the second/nested ajax call doesn't have the dsPostWindowId parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-446) windowhandler.js doesn't handle nested ajax calls
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869585#comment-13869585 ] Thomas Andraschko commented on DELTASPIKE-446: -- It's related how DS handles the windowId. It automatically attachs a hiddenInput in each form. 2 possible failures: - the hiddenInput won't be posted when PF partialSubmit is activated - after the ajax update, the registered handler for readding the windowId to the form won't be called, as jsf.ajax.addOnEvent doesn't work with PF I will take care of this. windowhandler.js doesn't handle nested ajax calls - Key: DELTASPIKE-446 URL: https://issues.apache.org/jira/browse/DELTASPIKE-446 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: JBoss AS 7.2 / EAP 6.1 Reporter: Gerald Turner Assignee: Mark Struberg I get the exception org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped from a commandButton ajax call that is nested in a form that had been updated by another commandLink ajax call. These pages had been working with CODI. Scenario is a delete confirmation dialog, using PrimeFaces (p:dialog dynamic=true may be the culprit): I have a p:dataTable, with a column with a p:commandLink (Delete), this link updates a p:dialog (Are you sure?). The p:dialog contains a p:commandButton (Yes). Both the contents of the dialog and the actionListener of the commandButton access a @WindowScoped bean. Tracing the XHR POSTs, I see dsPostWindowId being sent when the first delete button is click, and it is not present with the final confirmation button is clicked. Scrutinizing over windowhandler.js, I can imagine that when the page is first loaded, 'jsf.ajax.addOnEvent(ajaxOnClick)' works it's magic and 'applyWindowId()' is effective for the first ajax call, but then the page has new elements which have not been decorated, so the second/nested ajax call doesn't have the dsPostWindowId parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-446) Current windowhandler.js is incomaptible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869586#comment-13869586 ] Thomas Andraschko commented on DELTASPIKE-446: -- I will talk with Cagatay and propably fix it in PrimeFaces. PrimeFaces should IMO handle both cases better. Current windowhandler.js is incomaptible with PrimeFaces Key: DELTASPIKE-446 URL: https://issues.apache.org/jira/browse/DELTASPIKE-446 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: JBoss AS 7.2 / EAP 6.1 Reporter: Gerald Turner Assignee: Thomas Andraschko I get the exception org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped from a commandButton ajax call that is nested in a form that had been updated by another commandLink ajax call. These pages had been working with CODI. Scenario is a delete confirmation dialog, using PrimeFaces (p:dialog dynamic=true may be the culprit): I have a p:dataTable, with a column with a p:commandLink (Delete), this link updates a p:dialog (Are you sure?). The p:dialog contains a p:commandButton (Yes). Both the contents of the dialog and the actionListener of the commandButton access a @WindowScoped bean. Tracing the XHR POSTs, I see dsPostWindowId being sent when the first delete button is click, and it is not present with the final confirmation button is clicked. Scrutinizing over windowhandler.js, I can imagine that when the page is first loaded, 'jsf.ajax.addOnEvent(ajaxOnClick)' works it's magic and 'applyWindowId()' is effective for the first ajax call, but then the page has new elements which have not been decorated, so the second/nested ajax call doesn't have the dsPostWindowId parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-446) Current windowhandler.js is incompatible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-446: - Fix Version/s: 0.6 Current windowhandler.js is incompatible with PrimeFaces Key: DELTASPIKE-446 URL: https://issues.apache.org/jira/browse/DELTASPIKE-446 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: JBoss AS 7.2 / EAP 6.1 Reporter: Gerald Turner Assignee: Thomas Andraschko Fix For: 0.6 I get the exception org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped from a commandButton ajax call that is nested in a form that had been updated by another commandLink ajax call. These pages had been working with CODI. Scenario is a delete confirmation dialog, using PrimeFaces (p:dialog dynamic=true may be the culprit): I have a p:dataTable, with a column with a p:commandLink (Delete), this link updates a p:dialog (Are you sure?). The p:dialog contains a p:commandButton (Yes). Both the contents of the dialog and the actionListener of the commandButton access a @WindowScoped bean. Tracing the XHR POSTs, I see dsPostWindowId being sent when the first delete button is click, and it is not present with the final confirmation button is clicked. Scrutinizing over windowhandler.js, I can imagine that when the page is first loaded, 'jsf.ajax.addOnEvent(ajaxOnClick)' works it's magic and 'applyWindowId()' is effective for the first ajax call, but then the page has new elements which have not been decorated, so the second/nested ajax call doesn't have the dsPostWindowId parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (DELTASPIKE-499) Minify javascripts on release build
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-499: Assignee: Thomas Andraschko Minify javascripts on release build --- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-499) Minify javascripts on release build
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-499: - Fix Version/s: 0.6 Minify javascripts on release build --- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-446) Current windowhandler.js is incompatible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869592#comment-13869592 ] Thomas Andraschko commented on DELTASPIKE-446: -- A workaround would be: p:ajaxStatus oncomplete=applyWindowId() / The problem is that you can't just call applyWindowId as all methods in windowhandler.js are private scoped. Current windowhandler.js is incompatible with PrimeFaces Key: DELTASPIKE-446 URL: https://issues.apache.org/jira/browse/DELTASPIKE-446 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: JBoss AS 7.2 / EAP 6.1 Reporter: Gerald Turner Assignee: Thomas Andraschko Fix For: 0.6 I get the exception org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped from a commandButton ajax call that is nested in a form that had been updated by another commandLink ajax call. These pages had been working with CODI. Scenario is a delete confirmation dialog, using PrimeFaces (p:dialog dynamic=true may be the culprit): I have a p:dataTable, with a column with a p:commandLink (Delete), this link updates a p:dialog (Are you sure?). The p:dialog contains a p:commandButton (Yes). Both the contents of the dialog and the actionListener of the commandButton access a @WindowScoped bean. Tracing the XHR POSTs, I see dsPostWindowId being sent when the first delete button is click, and it is not present with the final confirmation button is clicked. Scrutinizing over windowhandler.js, I can imagine that when the page is first loaded, 'jsf.ajax.addOnEvent(ajaxOnClick)' works it's magic and 'applyWindowId()' is effective for the first ajax call, but then the page has new elements which have not been decorated, so the second/nested ajax call doesn't have the dsPostWindowId parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-446) Current windowhandler.js is incompatible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869874#comment-13869874 ] Thomas Andraschko commented on DELTASPIKE-446: -- Currently not, sorry! Current windowhandler.js is incompatible with PrimeFaces Key: DELTASPIKE-446 URL: https://issues.apache.org/jira/browse/DELTASPIKE-446 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: JBoss AS 7.2 / EAP 6.1 Reporter: Gerald Turner Assignee: Thomas Andraschko Fix For: 0.6 I get the exception org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped from a commandButton ajax call that is nested in a form that had been updated by another commandLink ajax call. These pages had been working with CODI. Scenario is a delete confirmation dialog, using PrimeFaces (p:dialog dynamic=true may be the culprit): I have a p:dataTable, with a column with a p:commandLink (Delete), this link updates a p:dialog (Are you sure?). The p:dialog contains a p:commandButton (Yes). Both the contents of the dialog and the actionListener of the commandButton access a @WindowScoped bean. Tracing the XHR POSTs, I see dsPostWindowId being sent when the first delete button is click, and it is not present with the final confirmation button is clicked. Scrutinizing over windowhandler.js, I can imagine that when the page is first loaded, 'jsf.ajax.addOnEvent(ajaxOnClick)' works it's magic and 'applyWindowId()' is effective for the first ajax call, but then the page has new elements which have not been decorated, so the second/nested ajax call doesn't have the dsPostWindowId parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-500) Implement ds:disableClientWindow
Thomas Andraschko created DELTASPIKE-500: Summary: Implement ds:disableClientWindow Key: DELTASPIKE-500 URL: https://issues.apache.org/jira/browse/DELTASPIKE-500 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Fix For: 0.6 similiar to Orchestra's separateConversationContext or JSF 2.2 disableClientWindow attribute Disables the rendering of the windowId to the URLs of all child components -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (DELTASPIKE-500) Implement ds:disableClientWindow
[ https://issues.apache.org/jira/browse/DELTASPIKE-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-500: Assignee: Thomas Andraschko Implement ds:disableClientWindow Key: DELTASPIKE-500 URL: https://issues.apache.org/jira/browse/DELTASPIKE-500 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 similiar to Orchestra's separateConversationContext or JSF 2.2 disableClientWindow attribute Disables the rendering of the windowId to the URLs of all child components -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-502) Finish LAZY ClientWindowRenderMode
Thomas Andraschko created DELTASPIKE-502: Summary: Finish LAZY ClientWindowRenderMode Key: DELTASPIKE-502 URL: https://issues.apache.org/jira/browse/DELTASPIKE-502 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-503) Add JSF playground module
Thomas Andraschko created DELTASPIKE-503: Summary: Add JSF playground module Key: DELTASPIKE-503 URL: https://issues.apache.org/jira/browse/DELTASPIKE-503 Project: DeltaSpike Issue Type: Task Components: Examples, JSF-Module, JSF22-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 For developers testing / playing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-501) windowhandler.js also handles NONE and CUSTOM
[ https://issues.apache.org/jira/browse/DELTASPIKE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-501. -- Resolution: Fixed windowhandler.js also handles NONE and CUSTOM - Key: DELTASPIKE-501 URL: https://issues.apache.org/jira/browse/DELTASPIKE-501 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 It should only handle LAZY and CLIENTWINDOW -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-454) Provide a ClientWindowRenderMode similiar to CODI
[ https://issues.apache.org/jira/browse/DELTASPIKE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-454. -- Resolution: Fixed Provide a ClientWindowRenderMode similiar to CODI - Key: DELTASPIKE-454 URL: https://issues.apache.org/jira/browse/DELTASPIKE-454 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 Without LoadingScreen, JS, HTML and else. Its stable and works fine. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-454) Provide a ClientWindowRenderMode similiar to CODI
[ https://issues.apache.org/jira/browse/DELTASPIKE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-454: - Fix Version/s: 0.6 Provide a ClientWindowRenderMode similiar to CODI - Key: DELTASPIKE-454 URL: https://issues.apache.org/jira/browse/DELTASPIKE-454 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 Without LoadingScreen, JS, HTML and else. Its stable and works fine. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-500) Implement ds:disableClientWindow
[ https://issues.apache.org/jira/browse/DELTASPIKE-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-500. -- Resolution: Fixed Implement ds:disableClientWindow Key: DELTASPIKE-500 URL: https://issues.apache.org/jira/browse/DELTASPIKE-500 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 similiar to Orchestra's separateConversationContext or JSF 2.2 disableClientWindow attribute Disables the rendering of the windowId to the URLs of all child components -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-446) Current windowhandler.js is incompatible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875857#comment-13875857 ] Thomas Andraschko commented on DELTASPIKE-446: -- Fixed it on DS side. For PF 4.0.6 and 5.0, i will add a check for the dsPostWindowId in PF to support partialSubmit. Current windowhandler.js is incompatible with PrimeFaces Key: DELTASPIKE-446 URL: https://issues.apache.org/jira/browse/DELTASPIKE-446 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: JBoss AS 7.2 / EAP 6.1 Reporter: Gerald Turner Assignee: Thomas Andraschko Fix For: 0.6 Attachments: DS-PF-Workaround.js I get the exception org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped from a commandButton ajax call that is nested in a form that had been updated by another commandLink ajax call. These pages had been working with CODI. Scenario is a delete confirmation dialog, using PrimeFaces (p:dialog dynamic=true may be the culprit): I have a p:dataTable, with a column with a p:commandLink (Delete), this link updates a p:dialog (Are you sure?). The p:dialog contains a p:commandButton (Yes). Both the contents of the dialog and the actionListener of the commandButton access a @WindowScoped bean. Tracing the XHR POSTs, I see dsPostWindowId being sent when the first delete button is click, and it is not present with the final confirmation button is clicked. Scrutinizing over windowhandler.js, I can imagine that when the page is first loaded, 'jsf.ajax.addOnEvent(ajaxOnClick)' works it's magic and 'applyWindowId()' is effective for the first ajax call, but then the page has new elements which have not been decorated, so the second/nested ajax call doesn't have the dsPostWindowId parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-502) Finish LAZY ClientWindowRenderMode
[ https://issues.apache.org/jira/browse/DELTASPIKE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-502: - Fix Version/s: 0.6 Finish LAZY ClientWindowRenderMode -- Key: DELTASPIKE-502 URL: https://issues.apache.org/jira/browse/DELTASPIKE-502 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-502) Finish LAZY ClientWindowRenderMode
[ https://issues.apache.org/jira/browse/DELTASPIKE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-502. -- Resolution: Fixed Finish LAZY ClientWindowRenderMode -- Key: DELTASPIKE-502 URL: https://issues.apache.org/jira/browse/DELTASPIKE-502 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-499) Minify javascripts
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-499. -- Resolution: Fixed Minify javascripts -- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-499) Minify javascripts
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-499: - Summary: Minify javascripts (was: Minify javascripts on release build) Minify javascripts -- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-506) [perf] use a shared StringBuilder
Thomas Andraschko created DELTASPIKE-506: Summary: [perf] use a shared StringBuilder Key: DELTASPIKE-506 URL: https://issues.apache.org/jira/browse/DELTASPIKE-506 Project: DeltaSpike Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Thomas Andraschko Priority: Minor Currently each generated actionURL will create a new StringBuilder instance, if renderClientWindowMode enabled... I would do the same as in MyFaces: Create a SharedStringBuilder with a get method - #get(key, facesContext) instances will be stored as FacesContext attribute -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-509) [perf] cache map in DefaultClientWindow#getQueryURLParameters
Thomas Andraschko created DELTASPIKE-509: Summary: [perf] cache map in DefaultClientWindow#getQueryURLParameters Key: DELTASPIKE-509 URL: https://issues.apache.org/jira/browse/DELTASPIKE-509 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Priority: Minor Currently a new map will be created for each actionUrl -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-516) ClientWindowHelper.handleInitialRedirect mutilates URL, pathInfo is omitted
[
https://issues.apache.org/jira/browse/DELTASPIKE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889053#comment-13889053
]
Thomas Andraschko commented on DELTASPIKE-516:
--
Fixed. Could you please try a trunk build?
ClientWindowHelper.handleInitialRedirect mutilates URL, pathInfo is omitted
---
Key: DELTASPIKE-516
URL: https://issues.apache.org/jira/browse/DELTASPIKE-516
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.6
Reporter: Thomas Frühbeck
Assignee: Thomas Andraschko
Labels: faces, path, pathinfo, redirect, window
On LAZY redirect, ClientWindowHelper rewrites the URL:
public static void handleInitialRedirect(FacesContext facesContext, String
newWindowId)
{
// store the new windowId as context attribute to prevent infinite
loops
snip
String url = externalContext.getRequestScheme()
+ :// + externalContext.getRequestServerName()
+ : + externalContext.getRequestServerPort()
+ externalContext.getRequestContextPath()
+ externalContext.getRequestServletPath();
Here it seems, that externalContext.getPathInfo() is missing, the rewritten
URL is mutilated and the redirected request fails
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-516) ClientWindowHelper.handleInitialRedirect mutilates URL, pathInfo is omitted
[
https://issues.apache.org/jira/browse/DELTASPIKE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-516.
--
Resolution: Fixed
Fix Version/s: 0.6
ClientWindowHelper.handleInitialRedirect mutilates URL, pathInfo is omitted
---
Key: DELTASPIKE-516
URL: https://issues.apache.org/jira/browse/DELTASPIKE-516
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.6
Reporter: Thomas Frühbeck
Assignee: Thomas Andraschko
Labels: faces, path, pathinfo, redirect, window
Fix For: 0.6
On LAZY redirect, ClientWindowHelper rewrites the URL:
public static void handleInitialRedirect(FacesContext facesContext, String
newWindowId)
{
// store the new windowId as context attribute to prevent infinite
loops
snip
String url = externalContext.getRequestScheme()
+ :// + externalContext.getRequestServerName()
+ : + externalContext.getRequestServerPort()
+ externalContext.getRequestContextPath()
+ externalContext.getRequestServletPath();
Here it seems, that externalContext.getPathInfo() is missing, the rewritten
URL is mutilated and the redirected request fails
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-516) ClientWindowHelper.handleInitialRedirect mutilates URL, pathInfo is omitted
[
https://issues.apache.org/jira/browse/DELTASPIKE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889059#comment-13889059
]
Thomas Andraschko commented on DELTASPIKE-516:
--
great :)
ClientWindowHelper.handleInitialRedirect mutilates URL, pathInfo is omitted
---
Key: DELTASPIKE-516
URL: https://issues.apache.org/jira/browse/DELTASPIKE-516
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.6
Reporter: Thomas Frühbeck
Assignee: Thomas Andraschko
Labels: faces, path, pathinfo, redirect, window
Fix For: 0.6
On LAZY redirect, ClientWindowHelper rewrites the URL:
public static void handleInitialRedirect(FacesContext facesContext, String
newWindowId)
{
// store the new windowId as context attribute to prevent infinite
loops
snip
String url = externalContext.getRequestScheme()
+ :// + externalContext.getRequestServerName()
+ : + externalContext.getRequestServerPort()
+ externalContext.getRequestContextPath()
+ externalContext.getRequestServletPath();
Here it seems, that externalContext.getPathInfo() is missing, the rewritten
URL is mutilated and the redirected request fails
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-503) Add JSF playground module
[ https://issues.apache.org/jira/browse/DELTASPIKE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889076#comment-13889076 ] Thomas Andraschko commented on DELTASPIKE-503: -- simple playground added for lazy and clientwindow windowhandling Add JSF playground module - Key: DELTASPIKE-503 URL: https://issues.apache.org/jira/browse/DELTASPIKE-503 Project: DeltaSpike Issue Type: Task Components: Examples, JSF-Module, JSF22-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 For developers testing / playing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-529) DeltaSpikeExceptionHandler construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-529: - Fix Version/s: 0.6 DeltaSpikeExceptionHandler construction issue in non EE --- Key: DELTASPIKE-529 URL: https://issues.apache.org/jira/browse/DELTASPIKE-529 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5, 0.6 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeExceptionHandler is created and exceptionQualifier is populated, but it throws an exception because the following will only work once the CDI container is started: this.exceptionQualifier = AnnotationInstanceProvider.of( BeanProvider.getContextualReference(JsfModuleConfig.class).getExceptionQualifier()); Recommend either not caching the exceptionQualifier, or moving the initialization to the handle() method if null. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (DELTASPIKE-529) DeltaSpikeExceptionHandler construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-529: Assignee: Thomas Andraschko DeltaSpikeExceptionHandler construction issue in non EE --- Key: DELTASPIKE-529 URL: https://issues.apache.org/jira/browse/DELTASPIKE-529 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5, 0.6 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeExceptionHandler is created and exceptionQualifier is populated, but it throws an exception because the following will only work once the CDI container is started: this.exceptionQualifier = AnnotationInstanceProvider.of( BeanProvider.getContextualReference(JsfModuleConfig.class).getExceptionQualifier()); Recommend either not caching the exceptionQualifier, or moving the initialization to the handle() method if null. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-529) DeltaSpikeExceptionHandler construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-529. -- Resolution: Fixed DeltaSpikeExceptionHandler construction issue in non EE --- Key: DELTASPIKE-529 URL: https://issues.apache.org/jira/browse/DELTASPIKE-529 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5, 0.6 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeExceptionHandler is created and exceptionQualifier is populated, but it throws an exception because the following will only work once the CDI container is started: this.exceptionQualifier = AnnotationInstanceProvider.of( BeanProvider.getContextualReference(JsfModuleConfig.class).getExceptionQualifier()); Recommend either not caching the exceptionQualifier, or moving the initialization to the handle() method if null. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-532) DeltaSpikeFacesContextFactory construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13917999#comment-13917999 ] Thomas Andraschko commented on DELTASPIKE-532: -- I will fix it with an lazy init DeltaSpikeFacesContextFactory construction issue in non EE --- Key: DELTASPIKE-532 URL: https://issues.apache.org/jira/browse/DELTASPIKE-532 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5, 0.6 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non-EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeFacesContextFactory is created and clientWindow is populated, but it throws an exception because the following will only work once the CDI container is started: this.clientWindow = BeanProvider.getContextualReference(ClientWindow.class, true); Recommend not caching the clientWindow. I can confirm that JSF seems to load OK after this is fixed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (DELTASPIKE-532) DeltaSpikeFacesContextFactory construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-532: Assignee: Thomas Andraschko DeltaSpikeFacesContextFactory construction issue in non EE --- Key: DELTASPIKE-532 URL: https://issues.apache.org/jira/browse/DELTASPIKE-532 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5, 0.6 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non-EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeFacesContextFactory is created and clientWindow is populated, but it throws an exception because the following will only work once the CDI container is started: this.clientWindow = BeanProvider.getContextualReference(ClientWindow.class, true); Recommend not caching the clientWindow. I can confirm that JSF seems to load OK after this is fixed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-532) DeltaSpikeFacesContextFactory construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-532: - Fix Version/s: 0.6 DeltaSpikeFacesContextFactory construction issue in non EE --- Key: DELTASPIKE-532 URL: https://issues.apache.org/jira/browse/DELTASPIKE-532 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5, 0.6 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non-EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeFacesContextFactory is created and clientWindow is populated, but it throws an exception because the following will only work once the CDI container is started: this.clientWindow = BeanProvider.getContextualReference(ClientWindow.class, true); Recommend not caching the clientWindow. I can confirm that JSF seems to load OK after this is fixed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-533) Introduce a global deltaspike qualifier
Thomas Andraschko created DELTASPIKE-533: Summary: Introduce a global deltaspike qualifier Key: DELTASPIKE-533 URL: https://issues.apache.org/jira/browse/DELTASPIKE-533 Project: DeltaSpike Issue Type: Improvement Components: Core Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 - @DeltaSpike to support co-existence of DS and JEE features in the future -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-532) DeltaSpikeFacesContextFactory construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13918339#comment-13918339 ] Thomas Andraschko commented on DELTASPIKE-532: -- fixed - please give it a try. DeltaSpikeFacesContextFactory construction issue in non EE --- Key: DELTASPIKE-532 URL: https://issues.apache.org/jira/browse/DELTASPIKE-532 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non-EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeFacesContextFactory is created and clientWindow is populated, but it throws an exception because the following will only work once the CDI container is started: this.clientWindow = BeanProvider.getContextualReference(ClientWindow.class, true); Recommend not caching the clientWindow. I can confirm that JSF seems to load OK after this is fixed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-532) DeltaSpikeFacesContextFactory construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-532. -- Resolution: Fixed DeltaSpikeFacesContextFactory construction issue in non EE --- Key: DELTASPIKE-532 URL: https://issues.apache.org/jira/browse/DELTASPIKE-532 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non-EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeFacesContextFactory is created and clientWindow is populated, but it throws an exception because the following will only work once the CDI container is started: this.clientWindow = BeanProvider.getContextualReference(ClientWindow.class, true); Recommend not caching the clientWindow. I can confirm that JSF seems to load OK after this is fixed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-533) Introduce a global deltaspike qualifier
[ https://issues.apache.org/jira/browse/DELTASPIKE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-533: - Attachment: DELTASPIKE-533.patch if there are no objections, i will commit it on thursday. Introduce a global deltaspike qualifier --- Key: DELTASPIKE-533 URL: https://issues.apache.org/jira/browse/DELTASPIKE-533 Project: DeltaSpike Issue Type: Improvement Components: Core Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 Attachments: DELTASPIKE-533.patch - @DeltaSpike to support co-existence of DS and JEE features in the future -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-532) DeltaSpikeFacesContextFactory construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919337#comment-13919337 ] Thomas Andraschko commented on DELTASPIKE-532: -- Yep, create an issue please. DeltaSpikeFacesContextFactory construction issue in non EE --- Key: DELTASPIKE-532 URL: https://issues.apache.org/jira/browse/DELTASPIKE-532 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 In non-EE environments you may be using Weld Servlet to initialize CDI. However because of JSF zeroconfig you cannot guarantee that weld servlet will be started before JSF. During JSF startup DeltaSpikeFacesContextFactory is created and clientWindow is populated, but it throws an exception because the following will only work once the CDI container is started: this.clientWindow = BeanProvider.getContextualReference(ClientWindow.class, true); Recommend not caching the clientWindow. I can confirm that JSF seems to load OK after this is fixed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-535) DeltaSpikeViewHandler construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-535: - Fix Version/s: 0.6 DeltaSpikeViewHandler construction issue in non EE -- Key: DELTASPIKE-535 URL: https://issues.apache.org/jira/browse/DELTASPIKE-535 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.5 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 DeltaSpikeViewHandler references the bean manager in the constructor. However because of JSF zeroconfig you can guarantee the bean manager will be around at this point. Similar to https://issues.apache.org/jira/browse/DELTASPIKE-532 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-535) DeltaSpikeViewHandler construction issue in non EE
[ https://issues.apache.org/jira/browse/DELTASPIKE-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-535. -- Resolution: Fixed DeltaSpikeViewHandler construction issue in non EE -- Key: DELTASPIKE-535 URL: https://issues.apache.org/jira/browse/DELTASPIKE-535 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Environment: Tomcat Reporter: Bryn Cooke Assignee: Thomas Andraschko Fix For: 0.6 DeltaSpikeViewHandler references the bean manager in the constructor. However because of JSF zeroconfig you can guarantee the bean manager will be around at this point. Similar to https://issues.apache.org/jira/browse/DELTASPIKE-532 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-533) Introduce a global deltaspike qualifier
[ https://issues.apache.org/jira/browse/DELTASPIKE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-533. -- Resolution: Fixed Introduce a global deltaspike qualifier --- Key: DELTASPIKE-533 URL: https://issues.apache.org/jira/browse/DELTASPIKE-533 Project: DeltaSpike Issue Type: Improvement Components: Core Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 Attachments: DELTASPIKE-533.patch - @DeltaSpike to support co-existence of DS and JEE features in the future -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-534) Replace @Web with @DeltaSpike
[ https://issues.apache.org/jira/browse/DELTASPIKE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-534. -- Resolution: Fixed Replace @Web with @DeltaSpike - Key: DELTASPIKE-534 URL: https://issues.apache.org/jira/browse/DELTASPIKE-534 Project: DeltaSpike Issue Type: Improvement Components: Servlet-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 Attachments: DELTASPIKE-534.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-545) DeltaSpikeExceptionHandler getRootCause assumes caught FacesException is wrapping another Exception
[
https://issues.apache.org/jira/browse/DELTASPIKE-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-545.
--
Resolution: Fixed
DeltaSpikeExceptionHandler getRootCause assumes caught FacesException is
wrapping another Exception
---
Key: DELTASPIKE-545
URL: https://issues.apache.org/jira/browse/DELTASPIKE-545
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.6
Environment: Myfaces 2.2.1 Tomcat 7.x Deltaspike 0.6
Reporter: Karl Kildén
Assignee: Thomas Andraschko
Fix For: 0.7
It may be incorrect by the underlying JSF implementation to not wrap another
exception with FacesException. However errors such as detection of duplicate
id's are in nature FacesExceptions and the opposite could be argued.
Regardless it's best if DeltaspikeExceptionHandler null checks rather then
assuming every FacesException wraps another Exception to ensure robustness.
This is the code Thomas Andraschko proposed as a fix. I have verified it
locally and it fixed my problem.
In DeltaspikeExceptionHandler, override getRootCause:
@Override
public Throwable getRootCause(Throwable throwable)
{
while ((ELException.class.isInstance(throwable) ||
FacesException.class.isInstance(throwable))
throwable.getCause() != null)
{
throwable = throwable.getCause();
}
return throwable;
}
Before local fix:
java.lang.IllegalArgumentException: exception must not be null
org.apache.deltaspike.core.api.exception.control.event.ExceptionStackEvent.init(ExceptionStackEvent.java:60)
org.apache.deltaspike.core.impl.exception.control.ExceptionHandlerBroadcaster.executeHandlers(ExceptionHandlerBroadcaster.java:75)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
After:
javax.faces.FacesException: Component with id:info not found
org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getComponentId(HtmlAjaxBehaviorRenderer.java:461)
org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.build(HtmlAjaxBehaviorRenderer.java:433)
org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.mapToString(HtmlAjaxBehaviorRenderer.java:405)
org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.makeAjax(HtmlAjaxBehaviorRenderer.java:158)
org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getScript(HtmlAjaxBehaviorRenderer.java:102)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (DELTASPIKE-546) NPE in observer method on Glassfish 4.x
[ https://issues.apache.org/jira/browse/DELTASPIKE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-546: Assignee: Thomas Andraschko NPE in observer method on Glassfish 4.x --- Key: DELTASPIKE-546 URL: https://issues.apache.org/jira/browse/DELTASPIKE-546 Project: DeltaSpike Issue Type: Bug Components: Core, JSF-Module Reporter: Rafael Assignee: Thomas Andraschko Fix For: 0.7 For some reason GF4 weld implementation is trying to get a bean passing a null creationalContext in @Observes(notifyObserver = Reception.IF_EXISTS) and thats causing NPE in custom contexts. More details here: http://mail-archives.apache.org/mod_mbox/myfaces-users/201403.mbox/%3C1395611275.78259.YahooMailNeo%40web124705.mail.ne1.yahoo.com%3E -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-546) NPE in observer method on Glassfish 4.x
[ https://issues.apache.org/jira/browse/DELTASPIKE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-546: - Component/s: Core NPE in observer method on Glassfish 4.x --- Key: DELTASPIKE-546 URL: https://issues.apache.org/jira/browse/DELTASPIKE-546 Project: DeltaSpike Issue Type: Bug Components: Core, JSF-Module Reporter: Rafael Assignee: Thomas Andraschko Fix For: 0.7 For some reason GF4 weld implementation is trying to get a bean passing a null creationalContext in @Observes(notifyObserver = Reception.IF_EXISTS) and thats causing NPE in custom contexts. More details here: http://mail-archives.apache.org/mod_mbox/myfaces-users/201403.mbox/%3C1395611275.78259.YahooMailNeo%40web124705.mail.ne1.yahoo.com%3E -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (DELTASPIKE-559) ExceptionHandler lifecycle
[ https://issues.apache.org/jira/browse/DELTASPIKE-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-559: Assignee: Thomas Andraschko ExceptionHandler lifecycle -- Key: DELTASPIKE-559 URL: https://issues.apache.org/jira/browse/DELTASPIKE-559 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Reporter: Moritz Bechler Assignee: Thomas Andraschko Priority: Critical Fix For: 0.7 From the original ticket: [quote] Generally, I'm also a bit confused by the exception handler setup, it looks like there is a application global instance held by the exception handler factory. Besides I don't think this is thread safe and the spec says ExceptionHandlers are request scoped - if there is an error while processing the exception or there is no other ExceptionHandler defined (e.g. Myfaces without org.apache.myfaces.ERROR_HANDLING=true) exceptions will not be removed and indefinitely delivered (ExceptionHandlerBroadcaster throws without marking as handled if there are no deltaspike handlers) for unrelated requests. [quote] Thought a bit more about this. By holding onto the wrapped exception handler in the exception handler factory, deltaspike effectively breaks the contract (application scoped vs. expected request scoped lifecycle) for all wrapped exception handlers. I can think of a very broad range of errors that may result from this - depending on the wrapped exception handlers (including the exceptions are delivered on every subsequent request error if unhandled). Imho, deltaspike must create a new exception handler in DeltaSpikeExceptionHandlerFactory.getExceptionHandler(). If retaining the exception events over requests is desired some out of band mechanism must be used. Moritz -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-559) ExceptionHandler lifecycle
[ https://issues.apache.org/jira/browse/DELTASPIKE-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-559: - Fix Version/s: 0.7 ExceptionHandler lifecycle -- Key: DELTASPIKE-559 URL: https://issues.apache.org/jira/browse/DELTASPIKE-559 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Reporter: Moritz Bechler Assignee: Thomas Andraschko Priority: Critical Fix For: 0.7 From the original ticket: [quote] Generally, I'm also a bit confused by the exception handler setup, it looks like there is a application global instance held by the exception handler factory. Besides I don't think this is thread safe and the spec says ExceptionHandlers are request scoped - if there is an error while processing the exception or there is no other ExceptionHandler defined (e.g. Myfaces without org.apache.myfaces.ERROR_HANDLING=true) exceptions will not be removed and indefinitely delivered (ExceptionHandlerBroadcaster throws without marking as handled if there are no deltaspike handlers) for unrelated requests. [quote] Thought a bit more about this. By holding onto the wrapped exception handler in the exception handler factory, deltaspike effectively breaks the contract (application scoped vs. expected request scoped lifecycle) for all wrapped exception handlers. I can think of a very broad range of errors that may result from this - depending on the wrapped exception handlers (including the exceptions are delivered on every subsequent request error if unhandled). Imho, deltaspike must create a new exception handler in DeltaSpikeExceptionHandlerFactory.getExceptionHandler(). If retaining the exception events over requests is desired some out of band mechanism must be used. Moritz -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-544) api for a fine-grained control of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963410#comment-13963410 ] Thomas Andraschko commented on DELTASPIKE-544: -- Any idea for the new API? Currently it would be possible to inject ViewAccessBeanHolder and call #destroBeans api for a fine-grained control of @ViewAccessScoped beans - Key: DELTASPIKE-544 URL: https://issues.apache.org/jira/browse/DELTASPIKE-544 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 0.7 in codi there is an unified approach for it (Conversation#close). see e.g.: http://s.apache.org/sF since the scope-implementations are splitted, we need a new api for it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-544) api for a fine-grained control of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963410#comment-13963410 ] Thomas Andraschko edited comment on DELTASPIKE-544 at 4/8/14 8:38 PM: -- Any idea for the new API? Currently it would be possible to inject ViewAccessBeanHolder and call #destroyBeans was (Author: tandraschko): Any idea for the new API? Currently it would be possible to inject ViewAccessBeanHolder and call #destroBeans api for a fine-grained control of @ViewAccessScoped beans - Key: DELTASPIKE-544 URL: https://issues.apache.org/jira/browse/DELTASPIKE-544 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 0.7 in codi there is an unified approach for it (Conversation#close). see e.g.: http://s.apache.org/sF since the scope-implementations are splitted, we need a new api for it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-559) ExceptionHandler lifecycle
[ https://issues.apache.org/jira/browse/DELTASPIKE-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13964608#comment-13964608 ] Thomas Andraschko commented on DELTASPIKE-559: -- Fixed now. Could you please give it a try? ExceptionHandler lifecycle -- Key: DELTASPIKE-559 URL: https://issues.apache.org/jira/browse/DELTASPIKE-559 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Reporter: Moritz Bechler Assignee: Thomas Andraschko Priority: Critical Fix For: 0.7 From the original ticket: [quote] Generally, I'm also a bit confused by the exception handler setup, it looks like there is a application global instance held by the exception handler factory. Besides I don't think this is thread safe and the spec says ExceptionHandlers are request scoped - if there is an error while processing the exception or there is no other ExceptionHandler defined (e.g. Myfaces without org.apache.myfaces.ERROR_HANDLING=true) exceptions will not be removed and indefinitely delivered (ExceptionHandlerBroadcaster throws without marking as handled if there are no deltaspike handlers) for unrelated requests. [quote] Thought a bit more about this. By holding onto the wrapped exception handler in the exception handler factory, deltaspike effectively breaks the contract (application scoped vs. expected request scoped lifecycle) for all wrapped exception handlers. I can think of a very broad range of errors that may result from this - depending on the wrapped exception handlers (including the exceptions are delivered on every subsequent request error if unhandled). Imho, deltaspike must create a new exception handler in DeltaSpikeExceptionHandlerFactory.getExceptionHandler(). If retaining the exception events over requests is desired some out of band mechanism must be used. Moritz -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-559) ExceptionHandler lifecycle
[ https://issues.apache.org/jira/browse/DELTASPIKE-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-559. -- Resolution: Fixed ExceptionHandler lifecycle -- Key: DELTASPIKE-559 URL: https://issues.apache.org/jira/browse/DELTASPIKE-559 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Reporter: Moritz Bechler Assignee: Thomas Andraschko Priority: Critical Fix For: 0.7 From the original ticket: [quote] Generally, I'm also a bit confused by the exception handler setup, it looks like there is a application global instance held by the exception handler factory. Besides I don't think this is thread safe and the spec says ExceptionHandlers are request scoped - if there is an error while processing the exception or there is no other ExceptionHandler defined (e.g. Myfaces without org.apache.myfaces.ERROR_HANDLING=true) exceptions will not be removed and indefinitely delivered (ExceptionHandlerBroadcaster throws without marking as handled if there are no deltaspike handlers) for unrelated requests. [quote] Thought a bit more about this. By holding onto the wrapped exception handler in the exception handler factory, deltaspike effectively breaks the contract (application scoped vs. expected request scoped lifecycle) for all wrapped exception handlers. I can think of a very broad range of errors that may result from this - depending on the wrapped exception handlers (including the exceptions are delivered on every subsequent request error if unhandled). Imho, deltaspike must create a new exception handler in DeltaSpikeExceptionHandlerFactory.getExceptionHandler(). If retaining the exception events over requests is desired some out of band mechanism must be used. Moritz -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-566) JSF always requires an active WindowContext
Thomas Andraschko created DELTASPIKE-566: Summary: JSF always requires an active WindowContext Key: DELTASPIKE-566 URL: https://issues.apache.org/jira/browse/DELTASPIKE-566 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.7 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-566) JSF always requires an active WindowContext
[ https://issues.apache.org/jira/browse/DELTASPIKE-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-566. -- Resolution: Fixed JSF always requires an active WindowContext --- Key: DELTASPIKE-566 URL: https://issues.apache.org/jira/browse/DELTASPIKE-566 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.7 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-567) Consistent post/get parameter naming
[ https://issues.apache.org/jira/browse/DELTASPIKE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966425#comment-13966425 ] Thomas Andraschko commented on DELTASPIKE-567: -- Currently we have: - dswid: windowId for GET requests - dsRid: requestId for CLIENT_WINDOW - dsprt: prevent double submit - dsPostWindowId: windowId for POST requests Changes: dsRid - dsrid dsPostWindowId = dspwid Consistent post/get parameter naming Key: DELTASPIKE-567 URL: https://issues.apache.org/jira/browse/DELTASPIKE-567 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Priority: Minor Fix For: 0.7 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-567) Consistent post/get parameter naming
Thomas Andraschko created DELTASPIKE-567: Summary: Consistent post/get parameter naming Key: DELTASPIKE-567 URL: https://issues.apache.org/jira/browse/DELTASPIKE-567 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Environment: Currently we have: - dswid: windowId for GET requests - dsRid: requestId for CLIENT_WINDOW - dsprt: prevent double submit - dsPostWindowId: windowId for POST requests Changes: dsRid - dsrid dsPostWindowId = dspwid Reporter: Thomas Andraschko Assignee: Thomas Andraschko Priority: Minor Fix For: 0.7 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-568) Client Window cookie name is different on server and client side
[ https://issues.apache.org/jira/browse/DELTASPIKE-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-568. -- Resolution: Fixed Client Window cookie name is different on server and client side Key: DELTASPIKE-568 URL: https://issues.apache.org/jira/browse/DELTASPIKE-568 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.7 Server side: private static final String WINDOW_ID_COOKIE_PREFIX = dsWindowId-; Client side: var cookieName = 'dsiWindowId-' + requestToken; -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-573) If you define h:head within your site and use ds:windowId (ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window ids are generated)
[
https://issues.apache.org/jira/browse/DELTASPIKE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969445#comment-13969445
]
Thomas Andraschko commented on DELTASPIKE-573:
--
I assume it only happens for the first get request without windowId?
If you define h:head within your site and use ds:windowId
(ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window
ids are generated)
---
Key: DELTASPIKE-573
URL: https://issues.apache.org/jira/browse/DELTASPIKE-573
Project: DeltaSpike
Issue Type: Bug
Affects Versions: 0.6
Environment: tomcat 7.0.50
java 7
myfaces-2.2.2, deltaspike-0.6 (and deltaspike-0.7-SNAPSHOT )
Reporter: Rene O
Attachments: jsftest22_lazywindow.zip
If you define h:head within your site and use ds:windowId
(ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window
ids are generated)
{code mypage.xhtml}
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://xmlns.jcp.org/jsf/core;
xmlns:h=http://xmlns.jcp.org/jsf/html;
xmlns:ui=http://xmlns.jcp.org/jsf/facelets;
xmlns:p=http://xmlns.jcp.org/jsf/passthrough;
xmlns:jsf=http://xmlns.jcp.org/jsf;
xmlns:ds=http://deltaspike.apache.org/jsf;
ui:removewithout h:head everything works correct/ui:remove
h:head/h:head
f:metadata
f:viewParam id=myid name=myid
value=#{viewParamBean.myId}/
f:viewAction action=#{initCtr.initApplication()}/
/f:metadata
h:body
ds:windowId/
h:form
#{viewParamBean.myId}
/h:form
/h:body
/html
{code}
A testcase is attached.
Start application and open http://localhost:8080/jsftest22/mypage.jsf
You can see in the logs, that the viewAction is called two times.
If you remove h:head from site, viewAction is called only once, which is the
correct behaviour.
If you don't use ds:windowId and have h:head defined, then viewAction is also
called only once, which is the correct behaviour.
I don't know if this is a deltaspike bug or a bug within myfaces.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-573) If you define h:head within your site and use ds:windowId (ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window ids are generated)
[
https://issues.apache.org/jira/browse/DELTASPIKE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-573:
-
Fix Version/s: 0.7
If you define h:head within your site and use ds:windowId
(ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window
ids are generated)
---
Key: DELTASPIKE-573
URL: https://issues.apache.org/jira/browse/DELTASPIKE-573
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.6
Environment: tomcat 7.0.50
java 7
myfaces-2.2.2, deltaspike-0.6 (and deltaspike-0.7-SNAPSHOT )
Reporter: Rene O
Assignee: Thomas Andraschko
Priority: Minor
Fix For: 0.7
Attachments: jsftest22_lazywindow.zip
If you define h:head within your site and use ds:windowId
(ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window
ids are generated)
{code mypage.xhtml}
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://xmlns.jcp.org/jsf/core;
xmlns:h=http://xmlns.jcp.org/jsf/html;
xmlns:ui=http://xmlns.jcp.org/jsf/facelets;
xmlns:p=http://xmlns.jcp.org/jsf/passthrough;
xmlns:jsf=http://xmlns.jcp.org/jsf;
xmlns:ds=http://deltaspike.apache.org/jsf;
ui:removewithout h:head everything works correct/ui:remove
h:head/h:head
f:metadata
f:viewParam id=myid name=myid
value=#{viewParamBean.myId}/
f:viewAction action=#{initCtr.initApplication()}/
/f:metadata
h:body
ds:windowId/
h:form
#{viewParamBean.myId}
/h:form
/h:body
/html
{code}
A testcase is attached.
Start application and open http://localhost:8080/jsftest22/mypage.jsf
You can see in the logs, that the viewAction is called two times.
If you remove h:head from site, viewAction is called only once, which is the
correct behaviour.
If you don't use ds:windowId and have h:head defined, then viewAction is also
called only once, which is the correct behaviour.
I don't know if this is a deltaspike bug or a bug within myfaces.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-573) f:viewAction is executed twice with LAZY window handling mode
[
https://issues.apache.org/jira/browse/DELTASPIKE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-573:
-
Summary: f:viewAction is executed twice with LAZY window handling mode
(was: If you define h:head within your site and use ds:windowId
(ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window ids
are generated))
f:viewAction is executed twice with LAZY window handling mode
-
Key: DELTASPIKE-573
URL: https://issues.apache.org/jira/browse/DELTASPIKE-573
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.6
Environment: tomcat 7.0.50
java 7
myfaces-2.2.2, deltaspike-0.6 (and deltaspike-0.7-SNAPSHOT )
Reporter: Rene O
Assignee: Thomas Andraschko
Priority: Minor
Fix For: 0.7
Attachments: jsftest22_lazywindow.zip
If you define h:head within your site and use ds:windowId
(ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window
ids are generated)
{code mypage.xhtml}
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://xmlns.jcp.org/jsf/core;
xmlns:h=http://xmlns.jcp.org/jsf/html;
xmlns:ui=http://xmlns.jcp.org/jsf/facelets;
xmlns:p=http://xmlns.jcp.org/jsf/passthrough;
xmlns:jsf=http://xmlns.jcp.org/jsf;
xmlns:ds=http://deltaspike.apache.org/jsf;
ui:removewithout h:head everything works correct/ui:remove
h:head/h:head
f:metadata
f:viewParam id=myid name=myid
value=#{viewParamBean.myId}/
f:viewAction action=#{initCtr.initApplication()}/
/f:metadata
h:body
ds:windowId/
h:form
#{viewParamBean.myId}
/h:form
/h:body
/html
{code}
A testcase is attached.
Start application and open http://localhost:8080/jsftest22/mypage.jsf
You can see in the logs, that the viewAction is called two times.
If you remove h:head from site, viewAction is called only once, which is the
correct behaviour.
If you don't use ds:windowId and have h:head defined, then viewAction is also
called only once, which is the correct behaviour.
I don't know if this is a deltaspike bug or a bug within myfaces.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-573) f:viewAction is executed twice with LAZY window handling mode
[
https://issues.apache.org/jira/browse/DELTASPIKE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-573:
-
Attachment: DELTASPIKE-573.patch
Please try to attached patch with trunk.
I will commit it later.
f:viewAction is executed twice with LAZY window handling mode
-
Key: DELTASPIKE-573
URL: https://issues.apache.org/jira/browse/DELTASPIKE-573
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.6
Environment: tomcat 7.0.50
java 7
myfaces-2.2.2, deltaspike-0.6 (and deltaspike-0.7-SNAPSHOT )
Reporter: Rene O
Assignee: Thomas Andraschko
Priority: Minor
Fix For: 0.7
Attachments: DELTASPIKE-573.patch, jsftest22_lazywindow.zip
If you define h:head within your site and use ds:windowId
(ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window
ids are generated)
{code mypage.xhtml}
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://xmlns.jcp.org/jsf/core;
xmlns:h=http://xmlns.jcp.org/jsf/html;
xmlns:ui=http://xmlns.jcp.org/jsf/facelets;
xmlns:p=http://xmlns.jcp.org/jsf/passthrough;
xmlns:jsf=http://xmlns.jcp.org/jsf;
xmlns:ds=http://deltaspike.apache.org/jsf;
ui:removewithout h:head everything works correct/ui:remove
h:head/h:head
f:metadata
f:viewParam id=myid name=myid
value=#{viewParamBean.myId}/
f:viewAction action=#{initCtr.initApplication()}/
/f:metadata
h:body
ds:windowId/
h:form
#{viewParamBean.myId}
/h:form
/h:body
/html
{code}
A testcase is attached.
Start application and open http://localhost:8080/jsftest22/mypage.jsf
You can see in the logs, that the viewAction is called two times.
If you remove h:head from site, viewAction is called only once, which is the
correct behaviour.
If you don't use ds:windowId and have h:head defined, then viewAction is also
called only once, which is the correct behaviour.
I don't know if this is a deltaspike bug or a bug within myfaces.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-573) f:viewAction is executed twice with LAZY window handling mode
[
https://issues.apache.org/jira/browse/DELTASPIKE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969810#comment-13969810
]
Thomas Andraschko commented on DELTASPIKE-573:
--
Did cleared your browser cache?
I just commited the example to the playground and my patch.
Works fine for me.
f:viewAction is executed twice with LAZY window handling mode
-
Key: DELTASPIKE-573
URL: https://issues.apache.org/jira/browse/DELTASPIKE-573
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.6
Environment: tomcat 7.0.50
java 7
myfaces-2.2.2, deltaspike-0.6 (and deltaspike-0.7-SNAPSHOT )
Reporter: Rene O
Assignee: Thomas Andraschko
Priority: Minor
Fix For: 0.7
Attachments: DELTASPIKE-573.patch, jsftest22_lazywindow.zip
If you define h:head within your site and use ds:windowId
(ClientWindowRenderMode.LAZY), then f:viewAction is called twice (2 window
ids are generated)
{code mypage.xhtml}
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://xmlns.jcp.org/jsf/core;
xmlns:h=http://xmlns.jcp.org/jsf/html;
xmlns:ui=http://xmlns.jcp.org/jsf/facelets;
xmlns:p=http://xmlns.jcp.org/jsf/passthrough;
xmlns:jsf=http://xmlns.jcp.org/jsf;
xmlns:ds=http://deltaspike.apache.org/jsf;
ui:removewithout h:head everything works correct/ui:remove
h:head/h:head
f:metadata
f:viewParam id=myid name=myid
value=#{viewParamBean.myId}/
f:viewAction action=#{initCtr.initApplication()}/
/f:metadata
h:body
ds:windowId/
h:form
#{viewParamBean.myId}
/h:form
/h:body
/html
{code}
A testcase is attached.
Start application and open http://localhost:8080/jsftest22/mypage.jsf
You can see in the logs, that the viewAction is called two times.
If you remove h:head from site, viewAction is called only once, which is the
correct behaviour.
If you don't use ds:windowId and have h:head defined, then viewAction is also
called only once, which is the correct behaviour.
I don't know if this is a deltaspike bug or a bug within myfaces.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-574) Versioning for DeltaSpike JSF resources
[ https://issues.apache.org/jira/browse/DELTASPIKE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-574: - Summary: Versioning for DeltaSpike JSF resources (was: versioning for windowhandler.js) Versioning for DeltaSpike JSF resources --- Key: DELTASPIKE-574 URL: https://issues.apache.org/jira/browse/DELTASPIKE-574 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 0.7 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-574) Versioning for DeltaSpike JSF resources
[ https://issues.apache.org/jira/browse/DELTASPIKE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-574. -- Resolution: Fixed Versioning for DeltaSpike JSF resources --- Key: DELTASPIKE-574 URL: https://issues.apache.org/jira/browse/DELTASPIKE-574 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 0.7 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-570) Provide prototype/example for proposed mix between LAZY and CLIENTWINDOW window handling
[ https://issues.apache.org/jira/browse/DELTASPIKE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-570: - Fix Version/s: (was: 0.7) 0.8 Provide prototype/example for proposed mix between LAZY and CLIENTWINDOW window handling Key: DELTASPIKE-570 URL: https://issues.apache.org/jira/browse/DELTASPIKE-570 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.8 and do a voting afterwards - provided that it works fine -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-544) api for a fine-grained control of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-544: - Fix Version/s: (was: 0.7) 0.8 api for a fine-grained control of @ViewAccessScoped beans - Key: DELTASPIKE-544 URL: https://issues.apache.org/jira/browse/DELTASPIKE-544 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 0.8 in codi there is an unified approach for it (Conversation#close). see e.g.: http://s.apache.org/sF since the scope-implementations are splitted, we need a new api for it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-584) ds:disableClientWindow prevents child rendering with CLIENTWINDOW mode
Thomas Andraschko created DELTASPIKE-584: Summary: ds:disableClientWindow prevents child rendering with CLIENTWINDOW mode Key: DELTASPIKE-584 URL: https://issues.apache.org/jira/browse/DELTASPIKE-584 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.7 ds:disableClientWindow h:link value=Link outcome=test.xhtml / /ds:disableClientWindow Link is not rendered with CLIENTWINDOW mode. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-585) HttpSession is not serializable
Thomas Andraschko created DELTASPIKE-585:
Summary: HttpSession is not serializable
Key: DELTASPIKE-585
URL: https://issues.apache.org/jira/browse/DELTASPIKE-585
Project: DeltaSpike
Issue Type: Bug
Components: Servlet-Module
Affects Versions: 0.6
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko
Fix For: 0.7
ServletObjectProducer:
@Produces
@DeltaSpike
@SessionScoped
public HttpSession getHttpSession()
{
...
}
We should change the scope to RequestScoped.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (DELTASPIKE-590) ExceptionHandlerBroadcaster should not rethrow exceptions from BridgeExceptionHandlerWrapper
Thomas Andraschko created DELTASPIKE-590: Summary: ExceptionHandlerBroadcaster should not rethrow exceptions from BridgeExceptionHandlerWrapper Key: DELTASPIKE-590 URL: https://issues.apache.org/jira/browse/DELTASPIKE-590 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.7 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.8 No other JSF Exception has the choice to handle it. I would add a new param to the ExceptionToCatchEvent - optional If optional is true, we should not rethrow it. Default is false of course. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-591) Add a ProjectStage aware resource Servlet
[ https://issues.apache.org/jira/browse/DELTASPIKE-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997522#comment-13997522 ] Thomas Andraschko commented on DELTASPIKE-591: -- +1 Romain. So the servlet would just listen to a static url pattern instead of filtering all requests. Add a ProjectStage aware resource Servlet - Key: DELTASPIKE-591 URL: https://issues.apache.org/jira/browse/DELTASPIKE-591 Project: DeltaSpike Issue Type: New Feature Components: Servlet-Module Reporter: Daniel Sachse Assignee: Christian Kaltepoth Attachments: DELTASPIKE-591.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-591) Add a ProjectStage aware resource Servlet
[ https://issues.apache.org/jira/browse/DELTASPIKE-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13996298#comment-13996298 ] Thomas Andraschko edited comment on DELTASPIKE-591 at 5/13/14 11:50 AM: I have no use-case for it but It would be OK for me if the filter is NOT automatically active/mapped. was (Author: tandraschko): I have not use-case for it but It would be OK for me if the filter is NOT automatically active/mapped. Add a ProjectStage aware resource Servlet - Key: DELTASPIKE-591 URL: https://issues.apache.org/jira/browse/DELTASPIKE-591 Project: DeltaSpike Issue Type: New Feature Components: Servlet-Module Reporter: Daniel Sachse Assignee: Christian Kaltepoth Attachments: DELTASPIKE-591.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-603) removeBy* - similiar to findBy*
Thomas Andraschko created DELTASPIKE-603: Summary: removeBy* - similiar to findBy* Key: DELTASPIKE-603 URL: https://issues.apache.org/jira/browse/DELTASPIKE-603 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Reporter: Thomas Andraschko It would be great to allow a removeBy* - simliar to findBy* e.g. void removeByBrandId(String brandId); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-604) Add #merge to EntityRepository
Thomas Andraschko created DELTASPIKE-604: Summary: Add #merge to EntityRepository Key: DELTASPIKE-604 URL: https://issues.apache.org/jira/browse/DELTASPIKE-604 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-604) Add #merge to EntityRepository
[ https://issues.apache.org/jira/browse/DELTASPIKE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14006957#comment-14006957 ] Thomas Andraschko commented on DELTASPIKE-604: -- I have an case where i would like to remove an detached entity. So merge is sometimes required :) Add #merge to EntityRepository -- Key: DELTASPIKE-604 URL: https://issues.apache.org/jira/browse/DELTASPIKE-604 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-613) Avoid windowhandler.html in GET requests from links
[ https://issues.apache.org/jira/browse/DELTASPIKE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009493#comment-14009493 ] Thomas Andraschko commented on DELTASPIKE-613: -- AFAICS it's a mix between LAZY and CLIENTWINDOW. I have an similiar idea and already created a ticket: https://issues.apache.org/jira/browse/DELTASPIKE-570 The idea is to NOT render the dswid on the link but overwrite the onclick to lazy add the windowId and add a cookie. So on a GET request, the server will check if a windowId and the cookie exists - otherwise stream windowhandler.html. Therefore if you do a open in new tab - no windowId in the url, windowhandler will be streamed. The streaming of the windowhandler is reduced to a minimum. Avoid windowhandler.html in GET requests from links --- Key: DELTASPIKE-613 URL: https://issues.apache.org/jira/browse/DELTASPIKE-613 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.7 Reporter: Janario Assignee: Mark Struberg Attachments: dsrid_in_url.patch Some generated url could already detect the windowId and send with the first get avoiding windowhandler.html. In the actual model basically this are the steps from a click in a link: - Click in link (GET) to new page Response windowhandler.html - windowhandler.html detect windowId by window.name and get page again adding dsrid and windowId in cookie So I suggest the detection of windowhandler.html be done before the first get avoing one more request. To this every urls should have a dsrid(could be equals as windowId) and the storeWindowTree function should also add the cookie, same as in windowhandler.html Clicking in a link the cookie will be generated and in server side read identifying the windowId To explain better I attatched a patch with some changes. Could anyone try this? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-620) BridgeExceptionHandlerWrapper interferes with wrapped ExceptionHandlers
[ https://issues.apache.org/jira/browse/DELTASPIKE-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013830#comment-14013830 ] Thomas Andraschko commented on DELTASPIKE-620: -- Could you please a snapshot? Should be fixed with: https://issues.apache.org/jira/browse/DELTASPIKE-590 BridgeExceptionHandlerWrapper interferes with wrapped ExceptionHandlers --- Key: DELTASPIKE-620 URL: https://issues.apache.org/jira/browse/DELTASPIKE-620 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.7 Reporter: Richard DiCroce BridgeExceptionHandlerWrapper prevents wrapped ExceptionHandlers from being called if an exception has occurred and no @Handles method handles it. BridgeExceptionHandlerWrapper fires the ExceptionToCatchEvent, which is observed by ExceptionHandlerBroadcaster.executeHandlers(). That method re-throws the exception if it doesn't find any handler methods. Because BridgeExceptionHandlerWrapper doesn't wrap the call to fireEvent in a try-catch, the exception propagates out and any wrapped ExceptionHandlers are never called. I am currently working around this by deactivating BridgeExceptionHandlerWraper. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-629) Initial redirect fails behind proxy/fw/apache redirects
Thomas Andraschko created DELTASPIKE-629: Summary: Initial redirect fails behind proxy/fw/apache redirects Key: DELTASPIKE-629 URL: https://issues.apache.org/jira/browse/DELTASPIKE-629 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.7 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 1.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-544) api for a fine-grained control of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-544: - Fix Version/s: (was: 1.0.0) 1.0.1 api for a fine-grained control of @ViewAccessScoped beans - Key: DELTASPIKE-544 URL: https://issues.apache.org/jira/browse/DELTASPIKE-544 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 1.0.1 in codi there is an unified approach for it (Conversation#close). see e.g.: http://s.apache.org/sF since the scope-implementations are splitted, we need a new api for it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-621) DeltaSpikeResourceHandler should implement Deactivatable
[ https://issues.apache.org/jira/browse/DELTASPIKE-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-621. -- Resolution: Fixed DeltaSpikeResourceHandler should implement Deactivatable Key: DELTASPIKE-621 URL: https://issues.apache.org/jira/browse/DELTASPIKE-621 Project: DeltaSpike Issue Type: Improvement Affects Versions: 0.7 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 1.0.0 everything which is preconfigured needs to implement it -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-634) Add documentation for Deactivatable
Thomas Andraschko created DELTASPIKE-634: Summary: Add documentation for Deactivatable Key: DELTASPIKE-634 URL: https://issues.apache.org/jira/browse/DELTASPIKE-634 Project: DeltaSpike Issue Type: Bug Components: Core, Documentation Reporter: Thomas Andraschko There is currently no docu available for how to disable our deactivatable artifacts -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-634) Add documentation for Deactivatable
[ https://issues.apache.org/jira/browse/DELTASPIKE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-634: - Issue Type: Task (was: Bug) Add documentation for Deactivatable --- Key: DELTASPIKE-634 URL: https://issues.apache.org/jira/browse/DELTASPIKE-634 Project: DeltaSpike Issue Type: Task Components: Core, Documentation Reporter: Thomas Andraschko There is currently no docu available for how to disable our deactivatable artifacts -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-635) Document last TODOs in the JSF module documentation
Thomas Andraschko created DELTASPIKE-635: Summary: Document last TODOs in the JSF module documentation Key: DELTASPIKE-635 URL: https://issues.apache.org/jira/browse/DELTASPIKE-635 Project: DeltaSpike Issue Type: Task Components: Documentation, JSF-Module Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-636) @Secures should trigger the ds-exception-handler
[ https://issues.apache.org/jira/browse/DELTASPIKE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028276#comment-14028276 ] Thomas Andraschko commented on DELTASPIKE-636: -- AFAIR you don't need to set optional on the event + rethrow it manually if it's not handled because it will automatically rethrow it if no exception handler is available. @Secures should trigger the ds-exception-handler Key: DELTASPIKE-636 URL: https://issues.apache.org/jira/browse/DELTASPIKE-636 Project: DeltaSpike Issue Type: Improvement Components: Security-Module Affects Versions: 0.7 Reporter: Pedro Igor Assignee: Gerhard Petracek Priority: Minor Fix For: 1.0.0 Attachments: AccessDeniedExceptionHandling.patch, DELTASPIKE-636.patch When using @Secures, if a validation fails the AccessDeniedException is thrown without letting the application to handle it properly. This ends up printing the stack trace on the logs. Ideally, users should be able to handle this exception before propagating it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-640) Document Scopes in Core module
Thomas Andraschko created DELTASPIKE-640: Summary: Document Scopes in Core module Key: DELTASPIKE-640 URL: https://issues.apache.org/jira/browse/DELTASPIKE-640 Project: DeltaSpike Issue Type: Task Components: Core, Documentation Reporter: Thomas Andraschko The API for all scopes is available in the Core API and we currently only have implementions for JSF. We should document this, all scopes and maybe give some hints how to implement it for other technologies. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-642) Better structure for Core documentation
Thomas Andraschko created DELTASPIKE-642: Summary: Better structure for Core documentation Key: DELTASPIKE-642 URL: https://issues.apache.org/jira/browse/DELTASPIKE-642 Project: DeltaSpike Issue Type: Task Components: Core, Documentation Reporter: Thomas Andraschko Currently we have this as root nodes below Core - API Exception Control Exception Handling - Usage Eventing into the exception handling framework Exception handlers Exception Chain Processing Handler ordinal APIs for exception information and flow control I would group it to Exception Handling below Core - API -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
Thomas Andraschko created DELTASPIKE-647: Summary: AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Thomas Hug Attachments: DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-647: - Attachment: DS-647.7z AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Thomas Hug Attachments: DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040508#comment-14040508 ] Thomas Andraschko commented on DELTASPIKE-647: -- run via mvn jetty:run open test1.xhtml - works as expected with a interface repo open test2.xhtml - Caused by: java.lang.AbstractMethodError: test.TestRepository2.saveAndFlush(Ljava/lang/Object;)Ljava/lang/Object; AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Thomas Hug Attachments: DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-506) [perf] use a shared StringBuilder
[ https://issues.apache.org/jira/browse/DELTASPIKE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-506: - Fix Version/s: (was: 1.0.1) 1.0.3 [perf] use a shared StringBuilder - Key: DELTASPIKE-506 URL: https://issues.apache.org/jira/browse/DELTASPIKE-506 Project: DeltaSpike Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Thomas Andraschko Priority: Minor Fix For: 1.0.3 Currently each generated actionURL will create a new StringBuilder instance, if renderClientWindowMode enabled... I would do the same as in MyFaces: Create a SharedStringBuilder with a get method - #get(key, facesContext) instances will be stored as FacesContext attribute -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-509) [perf] cache map in DefaultClientWindow#getQueryURLParameters
[ https://issues.apache.org/jira/browse/DELTASPIKE-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-509: - Fix Version/s: (was: 1.0.1) 1.0.3 [perf] cache map in DefaultClientWindow#getQueryURLParameters - Key: DELTASPIKE-509 URL: https://issues.apache.org/jira/browse/DELTASPIKE-509 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Priority: Minor Fix For: 1.0.3 Currently a new map will be created for each actionUrl -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (DELTASPIKE-662) Make insertion of port in URL in ClientWindowHelper optinal
[ https://issues.apache.org/jira/browse/DELTASPIKE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-662: Assignee: Thomas Andraschko Make insertion of port in URL in ClientWindowHelper optinal --- Key: DELTASPIKE-662 URL: https://issues.apache.org/jira/browse/DELTASPIKE-662 Project: DeltaSpike Issue Type: Wish Affects Versions: 1.0.0 Reporter: ulrich gratz Assignee: Thomas Andraschko Scenario: - Loadbalaner is terminated by https (port 443) - The tomcat behind it runs on http When adding the initial dswid in ClientWindowHelper, port 80 is written into the URL which breaks the redirect. It would be great, if the insertion of the port in the redirect URL could be switched off optionally. -- This message was sent by Atlassian JIRA (v6.2#6252)
