[jira] [Commented] (MYFACES-4676) Error Data Paylod Not Following Spec in Faces 4.0
[
https://issues.apache.org/jira/browse/MYFACES-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867854#comment-17867854
]
Melloware commented on MYFACES-4676:
[~tssmith04] what I do find strange is why does that faces.reponse.js say
copyright IBM 2015? I can't find that anywhere here in the MyFaces source code.
> Error Data Paylod Not Following Spec in Faces 4.0
> -
>
> Key: MYFACES-4676
> URL: https://issues.apache.org/jira/browse/MYFACES-4676
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 4.0.0
> Environment: Windows 11
>Reporter: Thomas Smith
>Priority: Trivial
> Attachments: Screenshot 2024-07-22 at 1.55.47 PM.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The [Error Data Payload (Table 16)|#a6973]] outlined in the spec isn't
> followed. As seen in the screenshot below something seems to be going wrong
> for responseText, responseCode, and status. Additionally, description and
> responseXML aren't included in the payload.
> !Screenshot 2024-07-22 at 1.55.47 PM.png|width=575,height=372!
> The response from the server still seems to be accurate:
> {code:java}
> encoding="UTF-8"?>org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException{code}
> The information seems to be lost somewhere in between the server response and
> error payload generation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4676) Error Data Paylod Not Following Spec in Faces 4.0
[
https://issues.apache.org/jira/browse/MYFACES-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867853#comment-17867853
]
Melloware commented on MYFACES-4676:
[~werpu] does this look familiar?
> Error Data Paylod Not Following Spec in Faces 4.0
> -
>
> Key: MYFACES-4676
> URL: https://issues.apache.org/jira/browse/MYFACES-4676
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 4.0.0
> Environment: Windows 11
>Reporter: Thomas Smith
>Priority: Trivial
> Attachments: Screenshot 2024-07-22 at 1.55.47 PM.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The [Error Data Payload (Table 16)|#a6973]] outlined in the spec isn't
> followed. As seen in the screenshot below something seems to be going wrong
> for responseText, responseCode, and status. Additionally, description and
> responseXML aren't included in the payload.
> !Screenshot 2024-07-22 at 1.55.47 PM.png|width=575,height=372!
> The response from the server still seems to be accurate:
> {code:java}
> encoding="UTF-8"?>org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException{code}
> The information seems to be lost somewhere in between the server response and
> error payload generation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4675) Faces #1936: resetValues() visit clientIds if not EditableValueHolder
Melloware created MYFACES-4675: -- Summary: Faces #1936: resetValues() visit clientIds if not EditableValueHolder Key: MYFACES-4675 URL: https://issues.apache.org/jira/browse/MYFACES-4675 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.1.0-RC2, 4.0.2 Reporter: Melloware Assignee: Melloware See Faces issue: https://github.com/jakartaee/faces/issues/1936 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4674) ResponseWriter: wrapped vs getWrapped() issue
Melloware created MYFACES-4674:
--
Summary: ResponseWriter: wrapped vs getWrapped() issue
Key: MYFACES-4674
URL: https://issues.apache.org/jira/browse/MYFACES-4674
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC2, 4.0.2
Reporter: Melloware
Original report to Mojarra: https://github.com/eclipse-ee4j/mojarra/issues/5456
After debugging BalusC determined that Mojarra was doing the correct thing and
MyFaces is somewhere in its chain calling the delegate/wrapped writer and not
the `getWrapped()` writer.
*BalusC: *
{quote}Hmm ok probably MyFaces still has a wrapped-vs-getWrapped bug in its
ResponseWriter(Wrapper) impl that it fails to invoke the
PrimePartialResponseWriter#endDocument when given a wrapped writer.{quote}
It is NOT currently affecting anything but I thought i would open this as
BalusC thought it was odd how MyFaces was treating the scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4673) Quarkus: Update to 3.8 LTS
[ https://issues.apache.org/jira/browse/MYFACES-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melloware resolved MYFACES-4673. Resolution: Fixed > Quarkus: Update to 3.8 LTS > -- > > Key: MYFACES-4673 > URL: https://issues.apache.org/jira/browse/MYFACES-4673 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC2 >Reporter: Melloware >Assignee: Melloware >Priority: Major > Fix For: 5.0.0, 4.0.3, 4.1.0-RC3 > > > Update to the Quarkus LTS 3.8.5 and change the dev card name to Apache > MyFaces. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4673) Quarkus: Update to 3.8 LTS
Melloware created MYFACES-4673: -- Summary: Quarkus: Update to 3.8 LTS Key: MYFACES-4673 URL: https://issues.apache.org/jira/browse/MYFACES-4673 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.1.0-RC2, 4.0.2, 5.0.0 Reporter: Melloware Update to the Quarkus LTS 3.8.5 and change the dev card name to Apache MyFaces. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4668) Quarkus: Programmatic Views not working
[
https://issues.apache.org/jira/browse/MYFACES-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Melloware resolved MYFACES-4668.
Fix Version/s: (was: 4.0.3)
(was: 4.1.0-RC3)
Resolution: Fixed
> Quarkus: Programmatic Views not working
> ---
>
> Key: MYFACES-4668
> URL: https://issues.apache.org/jira/browse/MYFACES-4668
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.2, 4.1.0-RC1, 5.0.0
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> Original report: [https://github.com/melloware/quarkus-faces/issues/444]
>
> I tried to add a programmatic view with the `@View` annotation, but when I
> access http://localhost:8080/facelet.xhml it returns 404
>
> {code:java}
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent) {
> if
> (!facesContext.getAttributes().containsKey(IS_BUILDING_INITIAL_STATE)) {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext) {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType) {
> return (T)
> facesContext.getApplication().createComponent(facesContext, componentType,
> null);
> }
> }
> }
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852185#comment-17852185
]
Melloware commented on MYFACES-4669:
OK its a Mojarra bug should we close this Myfaces bug?
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850692#comment-17850692
]
Melloware commented on MYFACES-4669:
What it seems to come down to is this.
{code:java}
var htmlTag = new UIOutput();
htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
rootChildren.add(htmlTag);
{code}
MyFaces escapes that but Mojarra just renders it exactly to browser. I don't
know what the Faces spec says about this
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850384#comment-17850384
]
Melloware commented on MYFACES-4669:
OK part of the issue I fixed the DOCTYPE by changing to this...
{code:java}
var htmlDoctype = new HtmlDoctype();
htmlDoctype.setRootElement("html");
rootChildren.add(htmlDoctype);
{code}
BUt I still don't see any way to add an "html" tag element that isn't escaped?
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
Melloware created MYFACES-4669: -- Summary: Programmatic Facelet Not Rendering Correctly Key: MYFACES-4669 URL: https://issues.apache.org/jira/browse/MYFACES-4669 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3 Reporter: Melloware Attachments: image-2024-05-28-17-42-16-539.png, image-2024-05-28-17-43-37-052.png, programmatic_view.zip Attached is an example: Run `mvn clean jetty:run -Pmojarra40` and you will see the programmatic view renders correctly. !image-2024-05-28-17-42-16-539.png! Run `mvn clean jetty:run -Pmyfaces40` and you will see the programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this looks like more double escaping for XML? !image-2024-05-28-17-43-37-052.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4668) Quarkus: Programmatic Views not working
Melloware created MYFACES-4668:
--
Summary: Quarkus: Programmatic Views not working
Key: MYFACES-4668
URL: https://issues.apache.org/jira/browse/MYFACES-4668
Project: MyFaces Core
Issue Type: Bug
Components: Extension Feature
Affects Versions: 4.1.0-RC1, 4.0.2, 5.0.0
Reporter: Melloware
Original report: [https://github.com/melloware/quarkus-faces/issues/444]
I tried to add a programmatic view with the `@View` annotation, but when I
access http://localhost:8080/facelet.xhml it returns 404
{code:java}
@View("/facelet.xhtml")
@ApplicationScoped
public class FaceletView extends Facelet {
@Override
public void apply(FacesContext facesContext, UIComponent parent) {
if
(!facesContext.getAttributes().containsKey(IS_BUILDING_INITIAL_STATE)) {
return;
}
var components = new ComponentBuilder(facesContext);
var rootChildren = parent.getChildren();
var doctype = new UIOutput();
doctype.setValue("");
rootChildren.add(doctype);
var htmlTag = new UIOutput();
htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
rootChildren.add(htmlTag);
HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
rootChildren.add(body);
HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
form.setId("form");
body.getChildren().add(form);
HtmlOutputText message =
components.create(HtmlOutputText.COMPONENT_TYPE);
message.setId("message");
HtmlCommandButton actionButton =
components.create(HtmlCommandButton.COMPONENT_TYPE);
actionButton.setId("button");
actionButton.addActionListener(
e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
Jakarta EE 10"));
actionButton.setValue("Greet");
form.getChildren().add(actionButton);
parent.getChildren().add(message);
htmlTag = new UIOutput();
htmlTag.setValue("");
rootChildren.add(htmlTag);
}
private static class ComponentBuilder {
FacesContext facesContext;
ComponentBuilder(FacesContext facesContext) {
this.facesContext = facesContext;
}
@SuppressWarnings("unchecked")
T create(String componentType) {
return (T)
facesContext.getApplication().createComponent(facesContext, componentType,
null);
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4667) UIData#invokeOnComponent does not find components
[
https://issues.apache.org/jira/browse/MYFACES-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848222#comment-17848222
]
Melloware commented on MYFACES-4667:
Oh good point it might be!
> UIData#invokeOnComponent does not find components
> -
>
> Key: MYFACES-4667
> URL: https://issues.apache.org/jira/browse/MYFACES-4667
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10
>Reporter: SteGr
>Priority: Major
>
> While working an a bug in [mojarra
> implementation|https://github.com/eclipse-ee4j/mojarra/issues/5445#issuecomment-2115154280]]
> I found an [old primefaces
> issue|https://github.com/primefaces/primefaces/issues/9245#issuecomment-2122507698]
> which was somehow related to my issue. Using the reproducer of that PF
> issue, I was able to really find the root cause of the issue and that even
> myfaces is affected - contrary to what was assumed at the time.
>
> *What happens?*
> A {{p:datatable}} with {{p:column*s*}} was updated by the backend using
> {{{}PrimeFaces#Ajax#update{}}}. The implementation used
> {{UIComponent#invokeOnComponent}} to find the component of the given
> clientId. As {{p:dataTable}} relies on {{UIData}} of myfaces, {{p:columns}}
> won't be handled. Nothing could be found and {{PrimeFaces#Ajax#update}} falls
> back to just forwarding the given clientId.
> *Why does it happen?*
> Like mojarra, myfaces filters the children on processing using {{{}instanceof
> UIColumn{}}}. But {{p:columns}} does not extend that class. Therefore
> {{p:columns}} is not a candiate and is simply ignored.
> *Possible fix* (not yet tested)
> Remove the check.
> *How to reproduce*
> Use the [reproducer
> |https://github.com/primefaces/primefaces/files/9664695/primefaces-test.zip]
> and change the PROJECT_STAGE to Development. Run the project using the
> myfaces23 profile. You should get a lot of logging entries like
> {quote}Mai 21, 2024 2:53:41 PM org.primefaces.PrimeFaces$Ajax update
> WARNUNG: PrimeFaces.current().ajax().update() called but component cant be
> resolved! Expression will just be added to the renderIds: \{0}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4667) UIData#invokeOnComponent does not find components
[
https://issues.apache.org/jira/browse/MYFACES-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848204#comment-17848204
]
Melloware commented on MYFACES-4667:
Mojarra fix: https://github.com/eclipse-ee4j/mojarra/pull/5446
> UIData#invokeOnComponent does not find components
> -
>
> Key: MYFACES-4667
> URL: https://issues.apache.org/jira/browse/MYFACES-4667
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10
>Reporter: SteGr
>Priority: Major
>
> While working an a bug in [mojarra implementation|#issuecomment-2115154280]]
> I found an [old primefaces
> issue|https://github.com/primefaces/primefaces/issues/9245#issuecomment-2122507698]
> which was somehow related to my issue. Using the reproducer of that PF
> issue, I was able to really find the root cause of the issue and that even
> myfaces is affected - contrary to what was assumed at the time.
>
> *What happens?*
> A {{p:datatable}} with {{p:column*s*}} was updated by the backend using
> {{{}PrimeFaces#Ajax#update{}}}. The implementation used
> {{UIComponent#invokeOnComponent}} to find the component of the given
> clientId. As {{p:dataTable}} relies on {{UIData}} of myfaces, {{p:columns}}
> won't be handled. Nothing could be found and {{PrimeFaces#Ajax#update}} falls
> back to just forwarding the given clientId.
> *Why does it happen?*
> Like mojarra, myfaces filters the children on processing using {{{}instanceof
> UIColumn{}}}. But {{p:columns}} does not extend that class. Therefore
> {{p:columns}} is not a candiate and is simply ignored.
> *Possible fix* (not yet tested)
> Remove the check.
> *How to reproduce*
> Use the [reproducer
> |https://github.com/primefaces/primefaces/files/9664695/primefaces-test.zip]
> and change the PROJECT_STAGE to Development. Run the project using the
> myfaces23 profile. You should get a lot of logging entries like
> {quote}Mai 21, 2024 2:53:41 PM org.primefaces.PrimeFaces$Ajax update
> WARNUNG: PrimeFaces.current().ajax().update() called but component cant be
> resolved! Expression will just be added to the renderIds: \{0}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844676#comment-17844676 ] Melloware commented on MYFACES-4378: I totally agree and the behavior you describe is what Mojarra does. Resource is only for resources not for scripts. > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844642#comment-17844642
]
Melloware commented on MYFACES-4378:
[~werpu] yes i don't think its your TS I was just wondering what s weird about
the issue is that Myfaces is sending the script back in both
`javax.faces.Resource` and in `EVAL` sections which to me is the bug. It
should only be in the `` section in this scenario.
{code:java}
{code}
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Task
>Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: pf-11780.zip, test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843567#comment-17843567
]
Melloware edited comment on MYFACES-4378 at 5/5/24 1:48 PM:
Reopened with simple reproducer provided:
[https://github.com/omnifaces/omnifaces/issues/804]
Reported in PrimeFaces: [https://github.com/primefaces/primefaces/issues/11780]
Because PrimeFaces constantly appends to the `head` this will eventually cause
the browser to fill up the head making the DOM slower and slower if you are on
a page with AJAX constantly.
{code:java}
else if (id === PrimeFaces.ajax.RESOURCE) {
$('head').append(content);
} {code}
That was discovered in this issue:
[https://github.com/primefaces/primefaces/issues/11714]
[~werpu] you may be interested in this as well...
was (Author: melloware):
Reopened with simple reproducer provided:
[https://github.com/omnifaces/omnifaces/issues/804]
Reported in PrimeFaces: [https://github.com/primefaces/primefaces/issues/11780]
Because PrimeFaces constantly appends to the `head` this will eventually cause
the browser to fill up the head making the DOM slower and slower if you are on
a page with AJAX constantly.
{code:java}
else if (id === PrimeFaces.ajax.RESOURCE) {
$('head').append(content);
} {code}
That was discovered in this issue:
[https://github.com/primefaces/primefaces/issues/11714]
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Task
>Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: pf-11780.zip, test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843567#comment-17843567
]
Melloware commented on MYFACES-4378:
Reopened with simple reproducer provided:
[https://github.com/omnifaces/omnifaces/issues/804]
Reported in PrimeFaces: [https://github.com/primefaces/primefaces/issues/11780]
Because PrimeFaces constantly appends to the `head` this will eventually cause
the browser to fill up the head making the DOM slower and slower if you are on
a page with AJAX constantly.
{code:java}
else if (id === PrimeFaces.ajax.RESOURCE) {
$('head').append(content);
} {code}
That was discovered in this issue:
[https://github.com/primefaces/primefaces/issues/11714]
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Task
>Affects Versions: 2.3.7, 2.3-next-M4, 3.0.0, 4.0.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melloware reopened MYFACES-4378: > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.7, 2.3-next-M4, 3.0.0, 4.0.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4663) Quarkus: Register RepeatStatus for reflection
[ https://issues.apache.org/jira/browse/MYFACES-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melloware resolved MYFACES-4663. Resolution: Fixed > Quarkus: Register RepeatStatus for reflection > - > > Key: MYFACES-4663 > URL: https://issues.apache.org/jira/browse/MYFACES-4663 > Project: MyFaces Core > Issue Type: Improvement > Components: Extension Feature >Affects Versions: 4.0.2, 4.1.0-RC1, 5.0.0 >Reporter: Melloware >Assignee: Melloware >Priority: Major > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > This class " > org.apache.myfaces.view.facelets.component.RepeatStatus" is a POJO and if > reference in EL like reference in the `index` you get `method index not found > on RepeatStatus" in native mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4663) Quarkus: Register RepeatStatus for reflection
[ https://issues.apache.org/jira/browse/MYFACES-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839104#comment-17839104 ] Melloware commented on MYFACES-4663: Fixed with: https://github.com/apache/myfaces/pull/702 > Quarkus: Register RepeatStatus for reflection > - > > Key: MYFACES-4663 > URL: https://issues.apache.org/jira/browse/MYFACES-4663 > Project: MyFaces Core > Issue Type: Improvement > Components: Extension Feature >Affects Versions: 4.0.2, 4.1.0-RC1, 5.0.0 >Reporter: Melloware >Priority: Major > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > This class " > org.apache.myfaces.view.facelets.component.RepeatStatus" is a POJO and if > reference in EL like reference in the `index` you get `method index not found > on RepeatStatus" in native mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4663) Quarkus: Register RepeatStatus for reflection
Melloware created MYFACES-4663: -- Summary: Quarkus: Register RepeatStatus for reflection Key: MYFACES-4663 URL: https://issues.apache.org/jira/browse/MYFACES-4663 Project: MyFaces Core Issue Type: Improvement Components: Extension Feature Affects Versions: 4.1.0-RC1, 4.0.2, 5.0.0 Reporter: Melloware This class " org.apache.myfaces.view.facelets.component.RepeatStatus" is a POJO and if reference in EL like reference in the `index` you get `method index not found on RepeatStatus" in native mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4661) SearchExpressions: Infinite Loop with SubView
[
https://issues.apache.org/jira/browse/MYFACES-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837835#comment-17837835
]
Melloware commented on MYFACES-4661:
I just tested with 2.3-next-M9-SNAPSHOT and can confirm its fixed `Caused by:
javax.faces.component.search.ComponentNotFoundException: Cannot find component
for expression ":subview1:txtString" referenced from "frmTest:j_id_k".`
> SearchExpressions: Infinite Loop with SubView
> -
>
> Key: MYFACES-4661
> URL: https://issues.apache.org/jira/browse/MYFACES-4661
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Melloware
>Priority: Major
> Attachments: subview.zip
>
>
> Attached is reproducible example using only core JSF code.
> [^subview.zip]
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ^The subview `render=":subview1:txtString"` gets stuck an infinite loop while
> `render="subview1:txtString"` works fine.^
> ^The request for the failed infinite loop...^
> {code:java}
> javax.faces.partial.render"j_id__v_0" {code}
> ^Running this same code with Mojarra 2.3 using `mvn clean jetty:run
> -Pmojarra23` the button works fine and the request looks like...^
> ^^
> {code:java}
> javax.faces.partial.render"frmTest:subview1:txtString" {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4661) SearchExpressions: Infinite Loop with SubView
[
https://issues.apache.org/jira/browse/MYFACES-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Melloware resolved MYFACES-4661.
Resolution: Duplicate
> SearchExpressions: Infinite Loop with SubView
> -
>
> Key: MYFACES-4661
> URL: https://issues.apache.org/jira/browse/MYFACES-4661
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Melloware
>Priority: Major
> Attachments: subview.zip
>
>
> Attached is reproducible example using only core JSF code.
> [^subview.zip]
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ^The subview `render=":subview1:txtString"` gets stuck an infinite loop while
> `render="subview1:txtString"` works fine.^
> ^The request for the failed infinite loop...^
> {code:java}
> javax.faces.partial.render"j_id__v_0" {code}
> ^Running this same code with Mojarra 2.3 using `mvn clean jetty:run
> -Pmojarra23` the button works fine and the request looks like...^
> ^^
> {code:java}
> javax.faces.partial.render"frmTest:subview1:txtString" {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4624) SearchExpressions must fail when component in viewroot is not resolvable
[ https://issues.apache.org/jira/browse/MYFACES-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837834#comment-17837834 ] Melloware commented on MYFACES-4624: I just tested with 2.3-next-M9-SNAPSHOT and can confirm its fixed `Caused by: javax.faces.component.search.ComponentNotFoundException: Cannot find component for expression ":subview1:txtString" referenced from "frmTest:j_id_k".` > SearchExpressions must fail when component in viewroot is not resolvable > > > Key: MYFACES-4624 > URL: https://issues.apache.org/jira/browse/MYFACES-4624 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 2.3.11, 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0-RC1 > > > when using something like: > ``` > > > > > ``` > the result was that it was resolved to "j_id__v_0" instead of throwing a > ComponentNotFoundException > ":mainForm:input" would be the right expression -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4661) SearchExpressions: Infinite Loop with SubView
Melloware created MYFACES-4661:
--
Summary: SearchExpressions: Infinite Loop with SubView
Key: MYFACES-4661
URL: https://issues.apache.org/jira/browse/MYFACES-4661
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 4.1.0-RC1, 4.0.2, 2.3-next-M8, 3.0.2, 2.3.10
Reporter: Melloware
Attachments: subview.zip
Attached is reproducible example using only core JSF code.
[^subview.zip]
{code:java}
{code}
^The subview `render=":subview1:txtString"` gets stuck an infinite loop while
`render="subview1:txtString"` works fine.^
^The request for the failed infinite loop...^
{code:java}
javax.faces.partial.render"j_id__v_0" {code}
^Running this same code with Mojarra 2.3 using `mvn clean jetty:run
-Pmojarra23` the button works fine and the request looks like...^
^^
{code:java}
javax.faces.partial.render"frmTest:subview1:txtString" {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4659) Hidden field autocomplete="off" is not valid anymore
[ https://issues.apache.org/jira/browse/MYFACES-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836641#comment-17836641 ] Melloware commented on MYFACES-4659: Sorry i fixed it! > Hidden field autocomplete="off" is not valid anymore > > > Key: MYFACES-4659 > URL: https://issues.apache.org/jira/browse/MYFACES-4659 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Melloware >Priority: Minor > Fix For: 2.3.11, 3.0.3, 2.3-next-M9, 5.0.0, 4.1.0-RC2, 4.0.3 > > > See Mojarra Explanation: [https://github.com/eclipse-ee4j/mojarra/issues/5434] > > This was an old Firefox hack and I propose we inverse > "o.a.m.AUTOCOMPLETE_OFF_VIEW_STATE" value to not have the "autocomplete="off" > by default > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4659) Hidden field autocomplete="off" is not valid anymore
[ https://issues.apache.org/jira/browse/MYFACES-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melloware resolved MYFACES-4659. Resolution: Fixed > Hidden field autocomplete="off" is not valid anymore > > > Key: MYFACES-4659 > URL: https://issues.apache.org/jira/browse/MYFACES-4659 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Melloware >Priority: Minor > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > See Mojarra Explanation: [https://github.com/eclipse-ee4j/mojarra/issues/5434] > > This was an old Firefox hack and I propose we inverse > "o.a.m.AUTOCOMPLETE_OFF_VIEW_STATE" value to not have the "autocomplete="off" > by default > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4659) Hidden field autocomplete="off" is not valid anymore
Melloware created MYFACES-4659: -- Summary: Hidden field autocomplete="off" is not valid anymore Key: MYFACES-4659 URL: https://issues.apache.org/jira/browse/MYFACES-4659 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 4.1.0-RC1, 4.0.2, 2.3-next-M8, 2.3.10 Reporter: Melloware See Mojarra Explanation: [https://github.com/eclipse-ee4j/mojarra/issues/5434] This was an old Firefox hack and I propose we inverse "o.a.m.AUTOCOMPLETE_OFF_VIEW_STATE" value to not have the "autocomplete="off" by default -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828307#comment-17828307
]
Melloware commented on MYFACES-4656:
IT looks like Mojarra submitted this PR
[https://github.com/eclipse-ee4j/mojarra/pull/5418] not sure if MyFaces has
similar code?
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827722#comment-17827722
]
Melloware commented on MYFACES-4656:
>From BalusC:
Again the EL literal vs VE matter.
Work around for now, use {{default="#\{false}"}} instead of
{{{}default="false"{}}}.
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4646) Incorrect formatting on String built by ValidatorException
[
https://issues.apache.org/jira/browse/MYFACES-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Melloware resolved MYFACES-4646.
Resolution: Fixed
> Incorrect formatting on String built by ValidatorException
> --
>
> Key: MYFACES-4646
> URL: https://issues.apache.org/jira/browse/MYFACES-4646
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8, 4.0.1
>Reporter: Markus Jung
>Priority: Minor
> Fix For: 2.3.11, 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
>
> See this example test:
> {code:java}
> @Test
> public void facesMessageEmptyDetail()
> {
> FacesMessage message = new FacesMessage("Summary", "");
> ValidatorException exception = new ValidatorException(message);
> assertEquals("Summary", exception.getMessage());
> } {code}
>
> It currenty fails as the Exception message being built is "Summary: " because
> ValidatorException#facesMessageToString only [only checks for
> null|https://github.com/apache/myfaces/blob/main/api/src/main/java/jakarta/faces/validator/ValidatorException.java#L78],
> empty strings are not being taken care of.
> Actually, if you create a FacesMessage with detail=null it will [return the
> summary as the
> detail|https://github.com/apache/myfaces/blob/main/api/src/main/java/jakarta/faces/application/FacesMessage.java#L218]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4641) MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)" imports
[
https://issues.apache.org/jira/browse/MYFACES-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790731#comment-17790731
]
Melloware commented on MYFACES-4641:
[~volosied] i think we should close this ticket if the other versions are OK
and we are not doing any 3.0 releases. Not worth the time to fix.
> MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)"
> imports
>
>
> Key: MYFACES-4641
> URL: https://issues.apache.org/jira/browse/MYFACES-4641
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 3.0.2
>Reporter: Maxime Leur
>Priority: Major
>
> Hi,
> In MyFaces web site, version "3.0.x" is supposed to be compatible with:
> * Java 1.8
> * Servlet 5.0
> * EL 4.0
> * CDI 3.0 (optional)
> * JSTL 2.0 (optional)
> * BV 2.0 (optional)
> But I see that in "MyFaces bundle" the MANIFEST file contains
> "jakarta.servlet.*;version="[3,5)" imports:
> {noformat}
> jakarta.servlet.annotation;version="[3,5)";resolution:=optional
> jakarta.servlet.http;version="[3,5)"
> jakarta.servlet.jsp.jstl.core;version="[1.1.2,2.0.0)"
> jakarta.servlet.jsp.jstl.sql
> jakarta.servlet.jsp.tagext;version="[2.1.0,3.1)"
> jakarta.servlet.jsp;version="[2.1.0,3.1)"
> jakarta.servlet;version="[3,5)"
> {noformat}
> So it seems not compatible on OSGI environment with "Servlet 5.0".
> Regards,
> Maxime
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4632) MyFaces doesnt not generate *.taglib.xml
[ https://issues.apache.org/jira/browse/MYFACES-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772337#comment-17772337 ] Melloware commented on MYFACES-4632: [~tandraschko] not sure but is taglib.xml the same as these TLD's which are generated and also XML? [https://github.com/apache/myfaces/pull/605#issuecomment-1660583634] it looks like they are generated from the Javadoc? > MyFaces doesnt not generate *.taglib.xml > > > Key: MYFACES-4632 > URL: https://issues.apache.org/jira/browse/MYFACES-4632 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Priority: Major > > I was checking if this is rendered correclty: > https://github.com/jakartaee/faces/issues/1811 > but it seems that myfaces doesnt generate a taglib.xml > i checked our codebase a bit and it seems that the "myfaces-faces-plugin" can > generate one, but this was mainly used for pre JSF2 AFAICS > myfaces-builder-plugin, which generates our component classes based on this > annotations, doesnt have this feature?! > TBH i dont know what we should do > maybe take the myfaces-builder-plugin, refactor it completely, add taglib.xml > generation and host it as submodule of myfaces-core? > i dont like to have it in a seperate module, release lifecycle and so on > just pain in the past and now its only used anymore in MF core > another way would be to get rid of the whole generation > but this is likely just more work > anyone interessted? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4581) Felix Bundle ConcurrentModificationException
[
https://issues.apache.org/jira/browse/MYFACES-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771825#comment-17771825
]
Melloware commented on MYFACES-4581:
So I can't build on Windows without the Felix 5.1.8 but we reported a bug to
Felix because 5.1.8 doesn't generate the same. It looks like there is little
to no activity on the Felix ticket we opened.
See: https://issues.apache.org/jira/browse/FELIX-6566
> Felix Bundle ConcurrentModificationException
>
>
> Key: MYFACES-4581
> URL: https://issues.apache.org/jira/browse/MYFACES-4581
> Project: MyFaces Core
> Issue Type: Bug
> Components: build process
>Affects Versions: 4.0.0
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> Running `mvn clean install` locally on my machine I get
> `ConcurrentModificationExcepiton` in the Felix plugin. Bumping to 5.1.8
> fixes the issue.
>
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: C:\Tools\apache-maven-3.9.0
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: C:\Tools\jdk-17
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771486#comment-17771486
]
Melloware commented on MYFACES-4536:
Thanks for your help! Got to the bottom of it! See my PR and I think all our
integration tests are passing again!
[https://github.com/primefaces/primefaces/pull/10759]
Basically had to get rid of our Wrapper as it was not doing anything and extend
PartialResponseWriter directly. Then I had to make our CSPPartial extend our
PrimePartial so `endDocument` was called correctly.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771454#comment-17771454
]
Melloware commented on MYFACES-4536:
I see the difference between your code and PrimeFaces code. Your code is
directly calling
{code:java}
_writer.startElement("eval", null); {code}
In PrimeFaces we have a PrimePartialResponseWriter that does this...
{code:java}
@Override
public void startEval() throws IOException {
startMetadataIfNecessary();
super.startEval();
} {code}
Then our code when its encoding is calling the Myfaces startEval and endEval()
directly its not calling start and end element.
{code:java}
protected void encodeScripts(PrimeRequestContext requestContext) throws
IOException {
List initScripts = requestContext.getInitScriptsToExecute();
List scripts = requestContext.getScriptsToExecute();
if (!initScripts.isEmpty() || !scripts.isEmpty()) {
startEval(); // START EVAL inherited
for (int i = 0; i < initScripts.size(); i++) {
getWrapped().write(initScripts.get(i));getWrapped().write(';');
}
for (int i = 0; i < scripts.size(); i++) {
getWrapped().write(scripts.get(i));
getWrapped().write(';');}
endEval(); // START EVAL inherited
}
} {code}
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771441#comment-17771441
]
Melloware commented on MYFACES-4536:
Let me do some more debugging and report back!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771239#comment-17771239
]
Melloware commented on MYFACES-4536:
OK I know in other places I have had to override the clone.
{code:java}
@Override
public ResponseWriter cloneWithWriter(Writer writer) {
return new CspResponseWriter(getWrapped().cloneWithWriter(writer),
this.cspState);
} {code}
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771222#comment-17771222
]
Melloware commented on MYFACES-4536:
OK I just wanted to check so I implemented the change in PrimeFaces again and
our integration tests pass in Mojarra and fail in MyFaces:
https://github.com/primefaces/primefaces/actions/runs/6383060016
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771191#comment-17771191
]
Melloware commented on MYFACES-4536:
OK I think I might know what is going on let me try something.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771077#comment-17771077
]
Melloware commented on MYFACES-4536:
[~tandraschko] I can try and take a look but I am definitely not fully
comfortable in this code base and understanding how some of these tests work.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4629) PrimeFaces.ajax.Request.handle response is missing validationFailed argument
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770039#comment-17770039 ] Melloware commented on MYFACES-4629: Attached is reproducer: Run `mvn clean jetty:run -Pmyfaces40` to see it not work. Run `mvn clean jetty:run -Pmojarra40` to see it DOES work. > PrimeFaces.ajax.Request.handle response is missing validationFailed argument > > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Critical > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770005#comment-17770005
]
Melloware commented on MYFACES-4536:
[~werpu] just found another similar one reported for Myfaces 4.0.1 its
stripping out custom data:
https://github.com/orgs/primefaces/discussions/123#discussioncomment-7133027
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4626) Quarkus: Native compilation can't find key attribute
[
https://issues.apache.org/jira/browse/MYFACES-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765828#comment-17765828
]
Melloware commented on MYFACES-4626:
OK got to the bottom of the issue and my OmniFaces Integration tests are
passing again!
> Quarkus: Native compilation can't find key attribute
>
>
> Key: MYFACES-4626
> URL: https://issues.apache.org/jira/browse/MYFACES-4626
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.1
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> Running integration tests for OmniFaces the tests pass in JVM mode but fail
> in Native mode with this error.
>
> {code:java}
> org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException:
> jakarta.el.PropertyNotFoundException: The class
> 'org.apache.myfaces.util.lang.AbstractThreadSafeAttributeMap$EntrySetEntry'
> does not have the property 'key'.
> 766 at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:104)
> 767 at
> org.apache.myfaces.view.facelets.el.ELText$ELTextVariable.writeText(ELText.java:238)
> 768 at
> org.apache.myfaces.view.facelets.compiler.TextInstruction.write(TextInstruction.java:45)
> 769 at
> org.apache.myfaces.view.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:46)
> 770 at
> org.apache.myfaces.view.facelets.compiler.UILeaf.encodeAll(UILeaf.java:362)
> 771 at
> org.apache.myfaces.view.facelets.component.RepeatRenderer.encodeChildren(RepeatRenderer.java:78)
> 772 at
> org.apache.myfaces.view.facelets.component.UIRepeat.process(UIRepeat.java:1056)
> 773 at
> org.apache.myfaces.view.facelets.component.UIRepeat.encodeChildren(UIRepeat.java:1698)
> {code}
> Basically the XML page has this just to print out the Session Scope
> {code:java}
> Session Scope
>
>
>
> #{s.key}
> #{s.value}
>
>
> {code}
> And my guess is the Native compilation needs to be aware of
> `org.apache.myfaces.util.lang.AbstractThreadSafeAttributeMap$EntrySetEntry`
> or exposed somehow as it must be getting compiled out?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4626) Quarkus: Native compilation can't find key attribute
Melloware created MYFACES-4626:
--
Summary: Quarkus: Native compilation can't find key attribute
Key: MYFACES-4626
URL: https://issues.apache.org/jira/browse/MYFACES-4626
Project: MyFaces Core
Issue Type: Bug
Components: Extension Feature
Affects Versions: 4.0.1
Reporter: Melloware
Running integration tests for OmniFaces the tests pass in JVM mode but fail in
Native mode with this error.
{code:java}
org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException:
jakarta.el.PropertyNotFoundException: The class
'org.apache.myfaces.util.lang.AbstractThreadSafeAttributeMap$EntrySetEntry'
does not have the property 'key'.
766 at
org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:104)
767 at
org.apache.myfaces.view.facelets.el.ELText$ELTextVariable.writeText(ELText.java:238)
768 at
org.apache.myfaces.view.facelets.compiler.TextInstruction.write(TextInstruction.java:45)
769 at
org.apache.myfaces.view.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:46)
770 at
org.apache.myfaces.view.facelets.compiler.UILeaf.encodeAll(UILeaf.java:362)
771 at
org.apache.myfaces.view.facelets.component.RepeatRenderer.encodeChildren(RepeatRenderer.java:78)
772 at
org.apache.myfaces.view.facelets.component.UIRepeat.process(UIRepeat.java:1056)
773 at
org.apache.myfaces.view.facelets.component.UIRepeat.encodeChildren(UIRepeat.java:1698)
{code}
Basically the XML page has this just to print out the Session Scope
{code:java}
Session Scope
#{s.key}
#{s.value}
{code}
And my guess is the Native compilation needs to be aware of
`org.apache.myfaces.util.lang.AbstractThreadSafeAttributeMap$EntrySetEntry` or
exposed somehow as it must be getting compiled out?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4623) DuplicateIdException when adding component with resource in JSTL tag handler
[
https://issues.apache.org/jira/browse/MYFACES-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755513#comment-17755513
]
Melloware commented on MYFACES-4623:
also have this issue creeping up when I use this PrimeFaces Extensions
component with MyFaces which writes a Head UIOutput?
See: https://github.com/primefaces-extensions/primefaces-extensions/issues/517
> DuplicateIdException when adding component with resource in JSTL tag handler
>
>
> Key: MYFACES-4623
> URL: https://issues.apache.org/jira/browse/MYFACES-4623
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
>
> The following error occurs when a JSF component adding a resource is added in
> a JSTL tag handler:
> {code:java}
> org.apache.myfaces.view.facelets.compiler.DuplicateIdException: Component
> with duplicate id "j_id__rd_5" found. The first component is {Component-Path
> : [Class: jakarta.faces.component.UIViewRoot,ViewId: /test.xhtml][Class:
> org.apache.myfaces.component.ComponentResourceContainer,Id:
> jakarta_faces_location_head][Class: jakarta.faces.component.UIOutput,Id:
> j_id__rd_5]}
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.createAndQueueException(CheckDuplicateIdFaceletUtils.java:139)
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:95)
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:109)
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:103)
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:81)
> at
> org.apache.myfaces.view.facelets.PartialStateManagementStrategy.saveView(PartialStateManagementStrategy.java:701)
> at
> jakarta.faces.application.StateManager.getViewState(StateManager.java:147)
> [...]{code}
> In our example, the resource that is apparently added to the component tree
> twice is _inputmask/inputmask.js_ of the _p:calendar_ component when using it
> in a {_}c:forEach{_}.
> The error only happens if _STRICT_JSF_2_FACELETS_COMPATIBILITY_ is enabled,
> but that is a requirement for our application. The error does not occur in
> Mojarra.
> I would appreciate you looking into this, as it is a pretty big problem for
> us. And before you ask: We're using c:forEach because in our application
> changing from c:forEach/c:if to ui:repeat/ui:fragment would result in an
> increase of components in the component tree by a factor of about 5 on some
> sites.
> I could copy and paste more of the code here, but I think it's easier to just
> look at the reproducer:
> [https://github.com/mkomko/primefaces-test/tree/inputmask-duplicateid]
> The error occurs when opening the dialog using the button and then clicking
> "Cancel".
> Thank you very much in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1775#comment-1775
]
Melloware commented on MYFACES-4536:
We were basically masking this bug in PrimeFaces by having our own
PartialResponseWriter that we now want to remove since we don't support older
JSF anymore only 2.3 and higher which exposed this issue.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753311#comment-17753311
]
Melloware commented on MYFACES-4536:
Attached is Mojarra from the PR with no wrapped writer.
[^mojarra-csp-new.txt]
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753309#comment-17753309
]
Melloware commented on MYFACES-4536:
Let me grab Mojarra but yes the ENTIRE `eval` section is gone. Attached in the
zip are 3 responses captured.
[^csp-results.zip]
In the zip
*myfaces-csp-current.txt* - is the response from PF13 with CSP enabled
*myfaces-csp-new.txt* - is the response from the PR which shows the `eval` is
completely missing
*myfaces-non-csp.txt* - is with CSP disabled
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753299#comment-17753299
]
Melloware commented on MYFACES-4536:
OK I ran both the old and the new code in PrimeFaces CSP mode and the only
difference in the Partial Response is in the non wrapped mode MyFaces is
stripping this from the end of the payload.
{code:java}
{code}
So its not evaluating our CSP.register() scripts thus breaking our integration
tests. I have a feeling it has to do with MyFaces
PartialResponseWriterImpl.java which does some double buffering [~werpu] ???
It has all kinds of logic in there trying to strip CDATA out??? This stuff
does not exist in Mojarra and its currently working. So to me this is a
MyFaces bug buried in this PartialResponseWriterImpl logic.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752096#comment-17752096
]
Melloware commented on MYFACES-4536:
[~tandraschko] it looks like this one is still using the wrapped in PF. I
think this is still the problem:
[https://github.com/primefaces/primefaces/blob/master/primefaces/src/main/java/org/primefaces/context/PartialResponseWriterWrapper.java]
???
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4618) Faces 4.1: ui:repeat clarification on attributes, such as offset and size
[ https://issues.apache.org/jira/browse/MYFACES-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751713#comment-17751713 ] Melloware commented on MYFACES-4618: Can someone add a new version so I can mark this for 5.0 please? > Faces 4.1: ui:repeat clarification on attributes, such as offset and size > - > > Key: MYFACES-4618 > URL: https://issues.apache.org/jira/browse/MYFACES-4618 > Project: MyFaces Core > Issue Type: Improvement >Reporter: Thomas Andraschko >Assignee: Melloware >Priority: Major > > See https://github.com/eclipse-ee4j/mojarra/pull/5289 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4609) Web.xml parameters evaluate as EL
[
https://issues.apache.org/jira/browse/MYFACES-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749201#comment-17749201
]
Melloware commented on MYFACES-4609:
As discussed on gitHub this would be a significant change not worth the
refactor.
> Web.xml parameters evaluate as EL
> -
>
> Key: MYFACES-4609
> URL: https://issues.apache.org/jira/browse/MYFACES-4609
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Based on the previous discussion that web.xml init parameters should be
> evaluated for EL expressions by default.
> for example:
> {code:java}
>
>jakarta.faces.FACELETS_REFRESH_PERIOD
>#{facesContext.application.projectStage eq 'Development' ? 2
> : -1}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4618) Faces 4.1: ui:repeat clarification on attributes, such as offset and size
[ https://issues.apache.org/jira/browse/MYFACES-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746422#comment-17746422 ] Melloware commented on MYFACES-4618: Yep just assigned myself. > Faces 4.1: ui:repeat clarification on attributes, such as offset and size > - > > Key: MYFACES-4618 > URL: https://issues.apache.org/jira/browse/MYFACES-4618 > Project: MyFaces Core > Issue Type: Improvement >Reporter: Thomas Andraschko >Assignee: Melloware >Priority: Major > Fix For: 4.1.0 > > > See https://github.com/eclipse-ee4j/mojarra/pull/5289 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4612) Quarkus: Duplicate messages
[
https://issues.apache.org/jira/browse/MYFACES-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739942#comment-17739942
]
Melloware commented on MYFACES-4612:
As discussed in the PF ticket this optimization does not outweigh the side
effect of removing a message from the iterator does not remove it from both
collections.
> Quarkus: Duplicate messages
> ---
>
> Key: MYFACES-4612
> URL: https://issues.apache.org/jira/browse/MYFACES-4612
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 4.0.1
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> See: [https://github.com/primefaces/primefaces/issues/10279]
>
> MyFaces stores the same message in two different lists and Mojarra does not:
> {code:java}
> _messages = new LinkedHashMap<>(5, 1f);
> _orderedMessages = new ArrayList<>();
> List lst = _messages.computeIfAbsent(clientId, k -> new
> ArrayList<>(3));
> lst.add(message);
> _orderedMessages.add(message); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MYFACES-4612) Quarkus: Duplicate messages
[
https://issues.apache.org/jira/browse/MYFACES-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Melloware reopened MYFACES-4612:
> Quarkus: Duplicate messages
> ---
>
> Key: MYFACES-4612
> URL: https://issues.apache.org/jira/browse/MYFACES-4612
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 4.0.1
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> See: [https://github.com/primefaces/primefaces/issues/10279]
>
> MyFaces stores the same message in two different lists and Mojarra does not:
> {code:java}
> _messages = new LinkedHashMap<>(5, 1f);
> _orderedMessages = new ArrayList<>();
> List lst = _messages.computeIfAbsent(clientId, k -> new
> ArrayList<>(3));
> lst.add(message);
> _orderedMessages.add(message); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4612) Quarkus: Duplicate messages
[
https://issues.apache.org/jira/browse/MYFACES-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739741#comment-17739741
]
Melloware commented on MYFACES-4612:
OK so in PrettyFaces the old code was doing this..
{code:java}
for (Iterator iter = facesContext.getMessages(null);
iter.hasNext(); ) {
messages.add(iter.next());
iter.remove();
} {code}
Expecting that would remove all global messages but since MyFaces stores things
in 2 different collection the other "Ordered" messages collection is never
touched. in Mojarra its one collection so this works.
> Quarkus: Duplicate messages
> ---
>
> Key: MYFACES-4612
> URL: https://issues.apache.org/jira/browse/MYFACES-4612
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 4.0.1
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> See: [https://github.com/primefaces/primefaces/issues/10279]
>
> MyFaces stores the same message in two different lists and Mojarra does not:
> {code:java}
> _messages = new LinkedHashMap<>(5, 1f);
> _orderedMessages = new ArrayList<>();
> List lst = _messages.computeIfAbsent(clientId, k -> new
> ArrayList<>(3));
> lst.add(message);
> _orderedMessages.add(message); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4612) Quarkus: Duplicate messages
Melloware created MYFACES-4612:
--
Summary: Quarkus: Duplicate messages
Key: MYFACES-4612
URL: https://issues.apache.org/jira/browse/MYFACES-4612
Project: MyFaces Core
Issue Type: New Feature
Components: General
Affects Versions: 4.0.1
Reporter: Melloware
See: [https://github.com/primefaces/primefaces/issues/10279]
MyFaces stores the same message in two different lists and Mojarra does not:
{code:java}
_messages = new LinkedHashMap<>(5, 1f);
_orderedMessages = new ArrayList<>();
List lst = _messages.computeIfAbsent(clientId, k -> new
ArrayList<>(3));
lst.add(message);
_orderedMessages.add(message); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4609) Web.xml parameters evaluate as EL
Melloware created MYFACES-4609:
--
Summary: Web.xml parameters evaluate as EL
Key: MYFACES-4609
URL: https://issues.apache.org/jira/browse/MYFACES-4609
Project: MyFaces Core
Issue Type: New Feature
Components: General
Affects Versions: 4.0.1
Reporter: Melloware
Based on the previous discussion that web.xml init parameters should be
evaluated for EL expressions by default.
for example:
{code:java}
jakarta.faces.FACELETS_REFRESH_PERIOD
#{facesContext.application.projectStage eq 'Development' ? 2 :
-1}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736261#comment-17736261
]
Melloware commented on MYFACES-4608:
Understood!
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736156#comment-17736156
]
Melloware commented on MYFACES-4608:
[~tandraschko] can you elaborate what you mean about EL support in the Context
Param? I am a little unclear but am happy to submit a PR once I get some
guidance!
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
Melloware created MYFACES-4608:
--
Summary: FACELETS_REFRESH_PERIOD Settings
Key: MYFACES-4608
URL: https://issues.apache.org/jira/browse/MYFACES-4608
Project: MyFaces Core
Issue Type: New Feature
Components: General
Affects Versions: 4.0.1, 2.3-next-M8, 3.0.2, 2.3.10
Reporter: Melloware
Original issue came up in Quarkus conversation:
[https://github.com/quarkiverse/quarkus-primefaces/issues/75]
User had this setting in web.xml and was wondering why he could not hot reload
pages in DEV Mode
{code:java}
jakarta.faces.FACELETS_REFRESH_PERIOD
-1
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733005#comment-17733005 ] Melloware commented on MYFACES-4605: [~werpu] thanks for looking into this! > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Joe Crichton >Assignee: Werner Punz >Priority: Major > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727569#comment-17727569 ] Melloware commented on MYFACES-4605: [~werpu] maybe something for you to investigate or validate? > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Joe Crichton >Priority: Major > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4603) Quarkus: Add ClientWindowScoped
Melloware created MYFACES-4603: -- Summary: Quarkus: Add ClientWindowScoped Key: MYFACES-4603 URL: https://issues.apache.org/jira/browse/MYFACES-4603 Project: MyFaces Core Issue Type: New Feature Components: Extension Feature Affects Versions: 4.0.0 Reporter: Melloware Assignee: Melloware >From a user: We are currently trying out Quarkus with JSF. We were trying to use the *@ClientWindowScoped* annotation, but this annotation is not being recognized by Quarkus. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4598) Quarkus: Over registering beans for reflection
[ https://issues.apache.org/jira/browse/MYFACES-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709981#comment-17709981 ] Melloware commented on MYFACES-4598: Follow up closing this as won't fix because these beans need to be registered and Quarkus is notifying about them in Native mode but JSF will not work in Native mode without these registrations. > Quarkus: Over registering beans for reflection > -- > > Key: MYFACES-4598 > URL: https://issues.apache.org/jira/browse/MYFACES-4598 > Project: MyFaces Core > Issue Type: Improvement > Components: Extension Feature >Affects Versions: 2.3-next-M7, 4.0.0 >Reporter: Melloware >Assignee: Melloware >Priority: Major > > MyFaces is over registering classes for reflection. > See original ticket: [https://github.com/quarkusio/quarkus/issues/32337] > basically the Quarkus team debugged and said we should not be registreing > `ClientProxy` classes for relfection. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4598) Quarkus: Over registering beans for reflection
Melloware created MYFACES-4598: -- Summary: Quarkus: Over registering beans for reflection Key: MYFACES-4598 URL: https://issues.apache.org/jira/browse/MYFACES-4598 Project: MyFaces Core Issue Type: Improvement Components: Extension Feature Affects Versions: 4.0.0 Reporter: Melloware MyFaces is over registering classes for reflection. See original ticket: [https://github.com/quarkusio/quarkus/issues/32337] basically the Quarkus team debugged and said we should not be registreing `ClientProxy` classes for relfection. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4597) Quarkus: Update DevUI Card and Hot Deployment Items
Melloware created MYFACES-4597: -- Summary: Quarkus: Update DevUI Card and Hot Deployment Items Key: MYFACES-4597 URL: https://issues.apache.org/jira/browse/MYFACES-4597 Project: MyFaces Core Issue Type: Improvement Components: Extension Feature Affects Versions: 4.0.0 Reporter: Melloware Two things need to update. # DevUI Card changes for 3.0.0.CR1 # Add Hot Deployment items to trigger restart in Dev on `web.xml` and `faces-config.xml` changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4589) PropertyNotFoundException in nested components if attribute has same name as bean
[
https://issues.apache.org/jira/browse/MYFACES-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702652#comment-17702652
]
Melloware commented on MYFACES-4589:
[~mkomko] BalusC is still around he just jumps in a does a bunch of Mojarra and
OmniFaces stuff when it fits his schedule. A lot of time he commits on
weekends when he must be free but he has not gone anywhere.
As for 4.0 it looks like EL is still noCahe and always recompile
{code:java}
@JSFWebConfigParam(since="2.0.8", defaultValue="noCache",
expectedValues="noCache, strict, allowCset, always,
alwaysRecompile",
group="EL", tags="performance")
public static final String CACHE_EL_EXPRESSIONS =
"org.apache.myfaces.CACHE_EL_EXPRESSIONS";
private static final String CACHE_EL_EXPRESSIONS_DEFAULT =
ELExpressionCacheMode.alwaysRecompile.name(); {code}
> PropertyNotFoundException in nested components if attribute has same name as
> bean
> -
>
> Key: MYFACES-4589
> URL: https://issues.apache.org/jira/browse/MYFACES-4589
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0, 4.0.1
> Environment: primefaces-test project, jakarta branch
>Reporter: Manuel K
>Priority: Major
>
> I apologize in advance if this one is a SOB to debug and hopefully fix. Maybe
> not though?
> Given the following nested component structure:
> panel (composite component) -> panel (taglib component) -> departmentInfo
> (composite component) -> outputIconText (composite component) -> icon (taglib
> component)
> The panel composite component and the panel taglib component have an
> attribute called "color". The departmentInfo component uses "color" in an EL
> expression, which is supposed to be a call to a named bean "Color":
> {code:java}
>
> http://www.w3.org/1999/xhtml;
> xmlns:cc="http://xmlns.jcp.org/jsf/composite;
> xmlns:ui="http://xmlns.jcp.org/jsf/facelets;
> xmlns:test="http://xmlns.jcp.org/jsf/composite/components;>
>
>required="true"
> type="org.primefaces.test.Department"/>
>
>
>
> value="#{cc.attrs.value.name}"/>
>
>
> {code}
> Somehow it seems to be interpreted as the attribute though, because the
> following exception occurs:
> {code:java}
> Caused by: jakarta.el.PropertyNotFoundException: Property [blue] not found on
> type [java.lang.String]
> at jakarta.el.BeanELResolver$BeanProperties.get (BeanELResolver.java:251)
> {code}
> The exception occurs only using MyFaces ({_}mvn clean jetty:run
> -Pmyfaces40{_}) but works using Mojarra ({_}mvn clean jetty:run
> -Pmojarra40{_}). You can find my reproducer here:
> [https://github.com/mkomko/primefaces-test/tree/expression-error-property-not-found]
> Of course, _org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY_ is set to
> _true_ but it does not matter in this case.
> Thank you very much in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4595) Quarkus: Add Dev UI card
Melloware created MYFACES-4595: -- Summary: Quarkus: Add Dev UI card Key: MYFACES-4595 URL: https://issues.apache.org/jira/browse/MYFACES-4595 Project: MyFaces Core Issue Type: Improvement Components: Extension Feature Affects Versions: 4.0.0 Reporter: Melloware Add a new Dev UI card similar to other Apache libraries like POI and FreeMarker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4590) NullPointerException when PrimeFaces FileUpload used in composite component
[
https://issues.apache.org/jira/browse/MYFACES-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698102#comment-17698102
]
Melloware commented on MYFACES-4590:
So this line is return NULL instead of the default MAX VALUE in MyFaces.
{code:java}
public Long getSizeLimit() {
return (Long) getStateHelper().eval(PropertyKeys.sizeLimit,
Long.MAX_VALUE);
} {code}
> NullPointerException when PrimeFaces FileUpload used in composite component
> ---
>
> Key: MYFACES-4590
> URL: https://issues.apache.org/jira/browse/MYFACES-4590
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0, 4.0.1
> Environment: primefaces-test project, jakarta branch
>Reporter: Manuel K
>Assignee: Melloware
>Priority: Major
>
> Using the following composite component, an exception occurs upon rendering
> only on MyFaces but not on Mojarra. Please let me know if this is a
> PrimeFaces bug instead and I'll open an issue there.
> {code:java}
>
> http://www.w3.org/1999/xhtml;
> xmlns:cc="http://xmlns.jcp.org/jsf/composite;
> xmlns:ui="http://xmlns.jcp.org/jsf/facelets;
> xmlns:p="http://primefaces.org/ui;
> xmlns:h="http://xmlns.jcp.org/jsf/html;>
>
>required="true"
> method-signature="void
> listener(org.primefaces.event.FileUploadEvent)"/>
>type="java.lang.String"/>
>default="/.*/"/>
>
>default="1"/>
>
>default="false"/>
>
>
>
>listener="#{cc.attrs.fileUploadListener}"
> update="#{cc.attrs.update}"
> fileLimit="#{cc.attrs.fileLimit}"
> sizeLimit="#{cc.attrs.sizeLimit}"
> auto="true"
> accept="#{cc.attrs.accept}"
> sequential="true"
> allowTypes="#{cc.attrs.allowTypes}"
> multiple="#{cc.attrs.multiple}"/>
>
>
> {code}
> The exception:
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because the return value of
> "org.primefaces.component.fileupload.FileUpload.getSizeLimit()" is null
> at org.primefaces.component.fileupload.FileUploadRenderer.encodeScript
> (FileUploadRenderer.java:127)
> at org.primefaces.component.fileupload.FileUploadRenderer.encodeEnd
> (FileUploadRenderer.java:79)
> at jakarta.faces.component.UIComponentBase.encodeEnd
> (UIComponentBase.java:634) {code}
> You can find my reproducer here:
> [https://github.com/mkomko/primefaces-test/tree/file-upload-npe]
> Thank you very much in advance as always :).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4590) NullPointerException when PrimeFaces FileUpload used in composite component
[
https://issues.apache.org/jira/browse/MYFACES-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698101#comment-17698101
]
Melloware commented on MYFACES-4590:
OK if I change
{code:java}
{code}
To
{code:java}
{code}
it works. So somehow Mojarra is interpreting that as a number and MyFaces is
setting it to NULL.
> NullPointerException when PrimeFaces FileUpload used in composite component
> ---
>
> Key: MYFACES-4590
> URL: https://issues.apache.org/jira/browse/MYFACES-4590
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0, 4.0.1
> Environment: primefaces-test project, jakarta branch
>Reporter: Manuel K
>Assignee: Melloware
>Priority: Major
>
> Using the following composite component, an exception occurs upon rendering
> only on MyFaces but not on Mojarra. Please let me know if this is a
> PrimeFaces bug instead and I'll open an issue there.
> {code:java}
>
> http://www.w3.org/1999/xhtml;
> xmlns:cc="http://xmlns.jcp.org/jsf/composite;
> xmlns:ui="http://xmlns.jcp.org/jsf/facelets;
> xmlns:p="http://primefaces.org/ui;
> xmlns:h="http://xmlns.jcp.org/jsf/html;>
>
>required="true"
> method-signature="void
> listener(org.primefaces.event.FileUploadEvent)"/>
>type="java.lang.String"/>
>default="/.*/"/>
>
>default="1"/>
>
>default="false"/>
>
>
>
>listener="#{cc.attrs.fileUploadListener}"
> update="#{cc.attrs.update}"
> fileLimit="#{cc.attrs.fileLimit}"
> sizeLimit="#{cc.attrs.sizeLimit}"
> auto="true"
> accept="#{cc.attrs.accept}"
> sequential="true"
> allowTypes="#{cc.attrs.allowTypes}"
> multiple="#{cc.attrs.multiple}"/>
>
>
> {code}
> The exception:
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because the return value of
> "org.primefaces.component.fileupload.FileUpload.getSizeLimit()" is null
> at org.primefaces.component.fileupload.FileUploadRenderer.encodeScript
> (FileUploadRenderer.java:127)
> at org.primefaces.component.fileupload.FileUploadRenderer.encodeEnd
> (FileUploadRenderer.java:79)
> at jakarta.faces.component.UIComponentBase.encodeEnd
> (UIComponentBase.java:634) {code}
> You can find my reproducer here:
> [https://github.com/mkomko/primefaces-test/tree/file-upload-npe]
> Thank you very much in advance as always :).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4590) NullPointerException when PrimeFaces FileUpload used in composite component
[
https://issues.apache.org/jira/browse/MYFACES-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698100#comment-17698100
]
Melloware commented on MYFACES-4590:
I think its relate to this:
[https://github.com/primefaces/primefaces/issues/9485]
A mismatch between INT and LONG?
> NullPointerException when PrimeFaces FileUpload used in composite component
> ---
>
> Key: MYFACES-4590
> URL: https://issues.apache.org/jira/browse/MYFACES-4590
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0, 4.0.1
> Environment: primefaces-test project, jakarta branch
>Reporter: Manuel K
>Assignee: Melloware
>Priority: Major
>
> Using the following composite component, an exception occurs upon rendering
> only on MyFaces but not on Mojarra. Please let me know if this is a
> PrimeFaces bug instead and I'll open an issue there.
> {code:java}
>
> http://www.w3.org/1999/xhtml;
> xmlns:cc="http://xmlns.jcp.org/jsf/composite;
> xmlns:ui="http://xmlns.jcp.org/jsf/facelets;
> xmlns:p="http://primefaces.org/ui;
> xmlns:h="http://xmlns.jcp.org/jsf/html;>
>
>required="true"
> method-signature="void
> listener(org.primefaces.event.FileUploadEvent)"/>
>type="java.lang.String"/>
>default="/.*/"/>
>
>default="1"/>
>
>default="false"/>
>
>
>
>listener="#{cc.attrs.fileUploadListener}"
> update="#{cc.attrs.update}"
> fileLimit="#{cc.attrs.fileLimit}"
> sizeLimit="#{cc.attrs.sizeLimit}"
> auto="true"
> accept="#{cc.attrs.accept}"
> sequential="true"
> allowTypes="#{cc.attrs.allowTypes}"
> multiple="#{cc.attrs.multiple}"/>
>
>
> {code}
> The exception:
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because the return value of
> "org.primefaces.component.fileupload.FileUpload.getSizeLimit()" is null
> at org.primefaces.component.fileupload.FileUploadRenderer.encodeScript
> (FileUploadRenderer.java:127)
> at org.primefaces.component.fileupload.FileUploadRenderer.encodeEnd
> (FileUploadRenderer.java:79)
> at jakarta.faces.component.UIComponentBase.encodeEnd
> (UIComponentBase.java:634) {code}
> You can find my reproducer here:
> [https://github.com/mkomko/primefaces-test/tree/file-upload-npe]
> Thank you very much in advance as always :).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4590) NullPointerException when PrimeFaces FileUpload used in composite component
[
https://issues.apache.org/jira/browse/MYFACES-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697893#comment-17697893
]
Melloware commented on MYFACES-4590:
Yep I assigned myself!
> NullPointerException when PrimeFaces FileUpload used in composite component
> ---
>
> Key: MYFACES-4590
> URL: https://issues.apache.org/jira/browse/MYFACES-4590
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0, 4.0.1
> Environment: primefaces-test project, jakarta branch
>Reporter: Manuel K
>Assignee: Melloware
>Priority: Major
>
> Using the following composite component, an exception occurs upon rendering
> only on MyFaces but not on Mojarra. Please let me know if this is a
> PrimeFaces bug instead and I'll open an issue there.
> {code:java}
>
> http://www.w3.org/1999/xhtml;
> xmlns:cc="http://xmlns.jcp.org/jsf/composite;
> xmlns:ui="http://xmlns.jcp.org/jsf/facelets;
> xmlns:p="http://primefaces.org/ui;
> xmlns:h="http://xmlns.jcp.org/jsf/html;>
>
>required="true"
> method-signature="void
> listener(org.primefaces.event.FileUploadEvent)"/>
>type="java.lang.String"/>
>default="/.*/"/>
>
>default="1"/>
>
>default="false"/>
>
>
>
>listener="#{cc.attrs.fileUploadListener}"
> update="#{cc.attrs.update}"
> fileLimit="#{cc.attrs.fileLimit}"
> sizeLimit="#{cc.attrs.sizeLimit}"
> auto="true"
> accept="#{cc.attrs.accept}"
> sequential="true"
> allowTypes="#{cc.attrs.allowTypes}"
> multiple="#{cc.attrs.multiple}"/>
>
>
> {code}
> The exception:
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because the return value of
> "org.primefaces.component.fileupload.FileUpload.getSizeLimit()" is null
> at org.primefaces.component.fileupload.FileUploadRenderer.encodeScript
> (FileUploadRenderer.java:127)
> at org.primefaces.component.fileupload.FileUploadRenderer.encodeEnd
> (FileUploadRenderer.java:79)
> at jakarta.faces.component.UIComponentBase.encodeEnd
> (UIComponentBase.java:634) {code}
> You can find my reproducer here:
> [https://github.com/mkomko/primefaces-test/tree/file-upload-npe]
> Thank you very much in advance as always :).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4588) faces.getClientWindow does not retrieve client id
[
https://issues.apache.org/jira/browse/MYFACES-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697589#comment-17697589
]
Melloware edited comment on MYFACES-4588 at 3/7/23 8:51 PM:
Yeah that is saying ONLY use `document.body` if `node` is NULL or undefined. I
think it needs to be two separate searches not an either or.
Something like (just psuedocode)...
{code:java}
let nodeRoot = new DQ(node).querySelectorAll(`form input
[name='${P_CLIENT_WINDOW}']`);
let docRoot = new DQ(document.body).querySelectorAll(`form input
[name='${P_CLIENT_WINDOW}']`); {code}
{code:java}
// combine both collections into the full result set
let searchRoot = nodeRoot.addAll(docRoot);{code}
was (Author: melloware):
Yeah that is saying ONLY use `document.body` if `node` is NULL or undefined. I
think it needs to be two separate searches not an either or.
> faces.getClientWindow does not retrieve client id
> -
>
> Key: MYFACES-4588
> URL: https://issues.apache.org/jira/browse/MYFACES-4588
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.1
>
>
> Code
> web.xml:
> {color:#d4d4d4} {color}
> {code:java}
>
> jakarta.faces.CLIENT_WINDOW_MODE
> url
> {code}
> {color:#808080}
> {color}
> facelet' script:
> {color:#d4d4d4} {color}
> {code:java}
> var clientWindowId = faces.getClientWindow(document.forms[0]);{code}
> When *faces.{color:#dcdcaa}getClientWindow{color}* is called, it returns null
> when it should return the client id instead.
> The older JS looks to retrieve the id from the this element (client is not
> part of the URL on the first request):
> {code:java}
> name="jakarta.faces.ClientWindow" value="-tw96zi9et">{code}
> 3.0 JS:
> [https://github.com/apache/myfaces/blob/3.0.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L862-L881]
> 4.0 JS:
> [https://github.com/apache/myfaces/blob/15baed38ba3425c9e8b988906ab5958bf491ec86/api/src/client/typescript/faces/impl/AjaxImpl.ts#L470-L515]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4588) faces.getClientWindow does not retreive client id
[
https://issues.apache.org/jira/browse/MYFACES-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697589#comment-17697589
]
Melloware commented on MYFACES-4588:
Yeah that is saying ONLY use `document.body` if `node` is NULL or undefined. I
think it needs to be two separate searches not an either or.
> faces.getClientWindow does not retreive client id
> -
>
> Key: MYFACES-4588
> URL: https://issues.apache.org/jira/browse/MYFACES-4588
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Code
> web.xml:
> {color:#d4d4d4} {color}
> {code:java}
>
> jakarta.faces.CLIENT_WINDOW_MODE
> url
> {code}
> {color:#808080}
> {color}
> facelet' script:
> {color:#d4d4d4} {color}
> {code:java}
> var clientWindowId = faces.getClientWindow(document.forms[0]);{code}
> When *faces.{color:#dcdcaa}getClientWindow{color}* is called, it returns null
> when it should return the client id instead.
> The older JS looks to retrieve the id from the this element (client is not
> part of the URL on the first request):
> {code:java}
> name="jakarta.faces.ClientWindow" value="-tw96zi9et">{code}
> 3.0 JS:
> [https://github.com/apache/myfaces/blob/3.0.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L862-L881]
> 4.0 JS:
> [https://github.com/apache/myfaces/blob/15baed38ba3425c9e8b988906ab5958bf491ec86/api/src/client/typescript/faces/impl/AjaxImpl.ts#L470-L515]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4587) Intermittent deployment error on WildFly 27
[
https://issues.apache.org/jira/browse/MYFACES-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697449#comment-17697449
]
Melloware commented on MYFACES-4587:
Add this to your pom.xml
{code:java}
apache.snapshots
Apache Development Snapshot Repository
https://repository.apache.org/content/repositories/snapshots/
false
true
{code}
And then use `4.0.1-SNAPSHOT` in your pom.xml
> Intermittent deployment error on WildFly 27
> ---
>
> Key: MYFACES-4587
> URL: https://issues.apache.org/jira/browse/MYFACES-4587
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0
> Environment: Windows 10, WildFly 27.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: stacktrace.txt
>
>
> When deploying our JSF application using MyFaces on WildFly 27.0.1, we
> intermittently get the following exception:
> {code:java}
> org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456: Argument
> bean must not be null{code}
> I have attached the full stack trace.
> Debugging leads me to CDIUtils#get, where the following statement returns an
> empty set:
> {code:java}
> bm.getBeans(clazz); // clazz is ClientWindowScopeContextualStorageHolder{code}
> It doesn't happen on every deployment but too often to ignore. Do you have
> any insight on this?
> It happens whether
> _org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING_ is _true_ or
> _false_ (just a wild experiment) and the following in the web.xml (another
> wild experiment):
> {code:java}
>
> Faces Servlet
> jakarta.faces.webapp.FacesServlet
> 1
> {code}
> Thank you very much in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4587) Intermittent deployment error on WildFly 27
[
https://issues.apache.org/jira/browse/MYFACES-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697422#comment-17697422
]
Melloware commented on MYFACES-4587:
OK 9.27.0.Final is of the MyFaces Galleon Pack is now in Maven Central based on
WildFly 27.0.1 and MyFaces 4.0.0.
I could have saved you a lot of trouble :)
> Intermittent deployment error on WildFly 27
> ---
>
> Key: MYFACES-4587
> URL: https://issues.apache.org/jira/browse/MYFACES-4587
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0
> Environment: Windows 10, WildFly 27.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: stacktrace.txt
>
>
> When deploying our JSF application using MyFaces on WildFly 27.0.1, we
> intermittently get the following exception:
> {code:java}
> org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456: Argument
> bean must not be null{code}
> I have attached the full stack trace.
> Debugging leads me to CDIUtils#get, where the following statement returns an
> empty set:
> {code:java}
> bm.getBeans(clazz); // clazz is ClientWindowScopeContextualStorageHolder{code}
> It doesn't happen on every deployment but too often to ignore. Do you have
> any insight on this?
> It happens whether
> _org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING_ is _true_ or
> _false_ (just a wild experiment) and the following in the web.xml (another
> wild experiment):
> {code:java}
>
> Faces Servlet
> jakarta.faces.webapp.FacesServlet
> 1
> {code}
> Thank you very much in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4587) Intermittent deployment error on WildFly 27
[
https://issues.apache.org/jira/browse/MYFACES-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697418#comment-17697418
]
Melloware commented on MYFACES-4587:
Yeah: [https://github.com/melloware/wildfly-myfaces-galleon-pack]
And I have a WildFly Faces project using it:
[https://github.com/melloware/wildfly-faces]
I am releasing 9.27.0 to Maven central now which uses MyFaces 4.0.0 Final on
Wildfly 27. So far I see no issues.
> Intermittent deployment error on WildFly 27
> ---
>
> Key: MYFACES-4587
> URL: https://issues.apache.org/jira/browse/MYFACES-4587
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0
> Environment: Windows 10, WildFly 27.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: stacktrace.txt
>
>
> When deploying our JSF application using MyFaces on WildFly 27.0.1, we
> intermittently get the following exception:
> {code:java}
> org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456: Argument
> bean must not be null{code}
> I have attached the full stack trace.
> Debugging leads me to CDIUtils#get, where the following statement returns an
> empty set:
> {code:java}
> bm.getBeans(clazz); // clazz is ClientWindowScopeContextualStorageHolder{code}
> It doesn't happen on every deployment but too often to ignore. Do you have
> any insight on this?
> It happens whether
> _org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING_ is _true_ or
> _false_ (just a wild experiment) and the following in the web.xml (another
> wild experiment):
> {code:java}
>
> Faces Servlet
> jakarta.faces.webapp.FacesServlet
> 1
> {code}
> Thank you very much in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4587) Intermittent deployment error on WildFly 27
[
https://issues.apache.org/jira/browse/MYFACES-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697397#comment-17697397
]
Melloware commented on MYFACES-4587:
I am the author of WildFly MyFaces Galleon pack. I will test it out today with
WildFly 27 Bootable.
> Intermittent deployment error on WildFly 27
> ---
>
> Key: MYFACES-4587
> URL: https://issues.apache.org/jira/browse/MYFACES-4587
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0
> Environment: Windows 10, WildFly 27.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: stacktrace.txt
>
>
> When deploying our JSF application using MyFaces on WildFly 27.0.1, we
> intermittently get the following exception:
> {code:java}
> org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456: Argument
> bean must not be null{code}
> I have attached the full stack trace.
> Debugging leads me to CDIUtils#get, where the following statement returns an
> empty set:
> {code:java}
> bm.getBeans(clazz); // clazz is ClientWindowScopeContextualStorageHolder{code}
> It doesn't happen on every deployment but too often to ignore. Do you have
> any insight on this?
> It happens whether
> _org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING_ is _true_ or
> _false_ (just a wild experiment) and the following in the web.xml (another
> wild experiment):
> {code:java}
>
> Faces Servlet
> jakarta.faces.webapp.FacesServlet
> 1
> {code}
> Thank you very much in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4578) Quarkus 3: UnsupportedOperation in BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696998#comment-17696998
]
Melloware commented on MYFACES-4578:
Reproducer: [^MYFACES-4578.zip]
Run `mvn quarkus:dev`
Hit [http://localhost:8080/] and click the "Rebuild View" button or "Navigate"
button.
> Quarkus 3: UnsupportedOperation in BeanManager
> --
>
> Key: MYFACES-4578
> URL: https://issues.apache.org/jira/browse/MYFACES-4578
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0-RC5
>Reporter: Melloware
>Priority: Major
> Attachments: MYFACES-4578.zip
>
>
> Getting this error not in native mode just running in *quarkus:dev* mode.
> Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
> {code:java}
> public void rebuildView() {
> log.info("OmniFaces rebuildView()");
> Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
> this);
> Faces.setViewRoot(Faces.getViewId());
> }{code}
>
>
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at
> io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
> at
> org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
> at
> org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
> at
> org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
> at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
> at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.apache.el.parser.AstValue.invoke(AstValue.java:253) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4578) Quarkus 3: UnsupportedOperation in BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696981#comment-17696981
]
Melloware commented on MYFACES-4578:
Yep this is happening with OmniFaces custom @ViewScoped annotation I can't make
it happen with MyFaces ViewScoped annotation.
> Quarkus 3: UnsupportedOperation in BeanManager
> --
>
> Key: MYFACES-4578
> URL: https://issues.apache.org/jira/browse/MYFACES-4578
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0-RC5
>Reporter: Melloware
>Priority: Major
>
> Getting this error not in native mode just running in *quarkus:dev* mode.
> Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
> {code:java}
> public void rebuildView() {
> log.info("OmniFaces rebuildView()");
> Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
> this);
> Faces.setViewRoot(Faces.getViewId());
> }{code}
>
>
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at
> io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
> at
> org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
> at
> org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
> at
> org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
> at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
> at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.apache.el.parser.AstValue.invoke(AstValue.java:253) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4578) Quarkus 3: UnsupportedOperation in BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696954#comment-17696954
]
Melloware commented on MYFACES-4578:
OK I have a feeling something changed with OmniFaces this is the bean its
trying getPassivationCapable on destroy.
*org.omnifaces.cdi.viewscope.ViewScopeStorageInSession*
{code:java}
/**
* Stores view scoped bean instances in a LRU map in HTTP session.
*
* @author Bauke Scholtz
* @see ViewScoped
* @see ViewScopeManager
* @since 2.6
*/
@SessionScoped
public class ViewScopeStorageInSession implements ViewScopeStorage,
Serializable { {code}
> Quarkus 3: UnsupportedOperation in BeanManager
> --
>
> Key: MYFACES-4578
> URL: https://issues.apache.org/jira/browse/MYFACES-4578
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0-RC5
>Reporter: Melloware
>Priority: Major
>
> Getting this error not in native mode just running in *quarkus:dev* mode.
> Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
> {code:java}
> public void rebuildView() {
> log.info("OmniFaces rebuildView()");
> Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
> this);
> Faces.setViewRoot(Faces.getViewId());
> }{code}
>
>
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at
> io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
> at
> org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
> at
> org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
> at
> org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
> at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
> at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.apache.el.parser.AstValue.invoke(AstValue.java:253) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4578) Quarkus 3: UnsupportedOperation in BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696921#comment-17696921
]
Melloware commented on MYFACES-4578:
I get a different error now. Let me try and update the MyFaces Extensions
Showcase to have this issue so you can see it.
{code:java}
Caused by: java.lang.ClassCastException: class java.lang.String cannot be cast
to class jakarta.enterprise.context.spi.Contextual (java.lang.String is in
module java.base of loader 'bootstrap';
jakarta.enterprise.context.spi.Contextual is in unnamed module of loader
io.quarkus.bootstrap.classloading.QuarkusClassLoader @4e4aea35)
at
org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:174)
at
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:217)
at
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:253)
at
org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
Source)
at
org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:222)
at
org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:148)
at
org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
at
org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
at
io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
at
io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
Source)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.el.parser.AstValue.invoke(AstValue.java:253)
... 64 more {code}
> Quarkus 3: UnsupportedOperation in BeanManager
> --
>
> Key: MYFACES-4578
> URL: https://issues.apache.org/jira/browse/MYFACES-4578
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0-RC5
>Reporter: Melloware
>Priority: Major
>
> Getting this error not in native mode just running in *quarkus:dev* mode.
> Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
> {code:java}
> public void rebuildView() {
> log.info("OmniFaces rebuildView()");
> Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
> this);
> Faces.setViewRoot(Faces.getViewId());
> }{code}
>
>
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at
> io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
> at
> org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
> at
> org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
> at
> org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
> at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
> at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
[jira] [Commented] (MYFACES-4581) Felix Bundle ConcurrentModificationException
[
https://issues.apache.org/jira/browse/MYFACES-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696916#comment-17696916
]
Melloware commented on MYFACES-4581:
Exact error:
{code:java}
[ERROR] Failed to execute goal
org.apache.felix:maven-bundle-plugin:4.0.0:manifest (bundle-manifest) on
project myfaces-api: Execution bundle-manifest of goal
org.apache.felix:maven-bundle-plugin:4.0.0:manifest failed.:
ConcurrentModificationException -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :myfaces-api {code}
> Felix Bundle ConcurrentModificationException
>
>
> Key: MYFACES-4581
> URL: https://issues.apache.org/jira/browse/MYFACES-4581
> Project: MyFaces Core
> Issue Type: Bug
> Components: build process
>Affects Versions: 4.0.0
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> Running `mvn clean install` locally on my machine I get
> `ConcurrentModificationExcepiton` in the Felix plugin. Bumping to 5.1.8
> fixes the issue.
>
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: C:\Tools\apache-maven-3.9.0
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: C:\Tools\jdk-17
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4582) Quarkus3 MyFaces 4 Hot Reload not working
Melloware created MYFACES-4582:
--
Summary: Quarkus3 MyFaces 4 Hot Reload not working
Key: MYFACES-4582
URL: https://issues.apache.org/jira/browse/MYFACES-4582
Project: MyFaces Core
Issue Type: Bug
Components: Extension Feature
Affects Versions: 4.0.0
Reporter: Melloware
Have the running application. Make a change to a Java class then hit another
page and you will get these errors.
{code:java}
2023-03-05 15:18:45,761 INFO [io.qua.dep.dev.RuntimeUpdatesProcessor]
(vert.x-worker-thread-0) Live reload total time: 2.519s
java.lang.reflect.InvocationTargetException
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at
org.apache.myfaces.core.extensions.quarkus.runtime.spi.QuarkusFactoryFinderProvider.getFactory(QuarkusFactoryFinderProvider.java:72)
at jdk.internal.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at jakarta.faces.FactoryFinder.getFactory(FactoryFinder.java:220)
at
org.apache.myfaces.context.FacesContextFactoryImpl.(FacesContextFactoryImpl.java:119)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at
org.apache.myfaces.core.extensions.quarkus.runtime.spi.QuarkusFactoryFinderProvider.getFactory(QuarkusFactoryFinderProvider.java:72)
at jdk.internal.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at jakarta.faces.FactoryFinder.getFactory(FactoryFinder.java:220)
at jakarta.faces.webapp.FacesServlet.init(FacesServlet.java:140)
at
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:118)
at
io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:295)
at
io.undertow.servlet.core.ManagedServlet.forceInit(ManagedServlet.java:207)
at
io.undertow.servlet.handlers.ServletChain.forceInit(ServletChain.java:130)
at
io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:63)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:67)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:133)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:65)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
[jira] [Created] (MYFACES-4581) Felix Bundle ConcurrentModificationException
Melloware created MYFACES-4581:
--
Summary: Felix Bundle ConcurrentModificationException
Key: MYFACES-4581
URL: https://issues.apache.org/jira/browse/MYFACES-4581
Project: MyFaces Core
Issue Type: Bug
Components: build process
Affects Versions: 4.0.0
Reporter: Melloware
Running `mvn clean install` locally on my machine I get
`ConcurrentModificationExcepiton` in the Felix plugin. Bumping to 5.1.8 fixes
the issue.
{code:java}
Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: C:\Tools\apache-maven-3.9.0
Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: C:\Tools\jdk-17
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows" {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4580) Quarkus3: ClientWindowScopeContextualStorageHolder not available
Melloware created MYFACES-4580: -- Summary: Quarkus3: ClientWindowScopeContextualStorageHolder not available Key: MYFACES-4580 URL: https://issues.apache.org/jira/browse/MYFACES-4580 Project: MyFaces Core Issue Type: Bug Components: Extension Feature Affects Versions: 4.0.0 Reporter: Melloware Running Quarkus 3 getting NULL on CDI BeanManager trying to resolve "ClientWindowScopeContextualStorageHolder". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4579) jakarta.el.ELResolver.getFeatureDescriptors method removed
[
https://issues.apache.org/jira/browse/MYFACES-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696571#comment-17696571
]
Melloware commented on MYFACES-4579:
Nevermind Had to remove GlassFish EL it looks like MyFaces includes JASPER EL
11.0.0-M1
> jakarta.el.ELResolver.getFeatureDescriptors method removed
> --
>
> Key: MYFACES-4579
> URL: https://issues.apache.org/jira/browse/MYFACES-4579
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0
>Reporter: Melloware
>Priority: Major
>
> I can't build in Quarkus 3 native because its reporting this error:
> {code:java}
> Caused by: com.oracle.graal.pointsto.constraints.UnresolvedElementException:
> Discovered unresolved method during parsing:
> jakarta.el.ELResolver.getFeatureDescriptors(jakarta.el.ELContext,
> java.lang.Object). This error is reported at image build time because class
> org.apache.myfaces.component.validate.CopyBeanInterceptorELResolver is
> registered for linking at image build time by command line {code}
>
> Basically it looks like the EL library has removed getFetaturesDescriptor?
> See commit:
> [https://github.com/jakartaee/expression-language/commit/a0df903fc559caabdaef00bae61bb19a432a9fe6]
>
> So should MyFaces 4 remove this override?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4579) jakarta.el.ELResolver.getFeatureDescriptors method removed
Melloware created MYFACES-4579:
--
Summary: jakarta.el.ELResolver.getFeatureDescriptors method removed
Key: MYFACES-4579
URL: https://issues.apache.org/jira/browse/MYFACES-4579
Project: MyFaces Core
Issue Type: Bug
Components: Extension Feature
Affects Versions: 4.0.0
Reporter: Melloware
I can't build in Quarkus 3 native because its reporting this error:
{code:java}
Caused by: com.oracle.graal.pointsto.constraints.UnresolvedElementException:
Discovered unresolved method during parsing:
jakarta.el.ELResolver.getFeatureDescriptors(jakarta.el.ELContext,
java.lang.Object). This error is reported at image build time because class
org.apache.myfaces.component.validate.CopyBeanInterceptorELResolver is
registered for linking at image build time by command line {code}
Basically it looks like the EL library has removed getFetaturesDescriptor? See
commit:
[https://github.com/jakartaee/expression-language/commit/a0df903fc559caabdaef00bae61bb19a432a9fe6]
So should MyFaces 4 remove this override?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4578) Quarkus3: UnsupportedOperation in BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696478#comment-17696478
]
Melloware edited comment on MYFACES-4578 at 3/4/23 7:05 PM:
Ahh I think its this commit that is causing it:
[https://github.com/apache/myfaces/commit/68b80ea305b2d3c9b9ea6603cf577f2e5d35cf9c]
was (Author: melloware):
Ahh I think its this commit that is causing it:
https://github.com/apache/myfaces/commit/c65508027ed8259f252927a27d3c211d8c9f5f17
> Quarkus3: UnsupportedOperation in BeanManager
> -
>
> Key: MYFACES-4578
> URL: https://issues.apache.org/jira/browse/MYFACES-4578
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0-RC5
>Reporter: Melloware
>Priority: Major
>
> Getting this error not in native mode just running in *quarkus:dev* mode.
> Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
> {code:java}
> public void rebuildView() {
> log.info("OmniFaces rebuildView()");
> Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
> this);
> Faces.setViewRoot(Faces.getViewId());
> }{code}
>
>
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at
> io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
> at
> org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
> at
> org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
> at
> org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
> at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
> at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.apache.el.parser.AstValue.invoke(AstValue.java:253) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4578) Quarkus3: UnsupportedOperation in BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696478#comment-17696478
]
Melloware commented on MYFACES-4578:
Ahh I think its this commit that is causing it:
https://github.com/apache/myfaces/commit/c65508027ed8259f252927a27d3c211d8c9f5f17
> Quarkus3: UnsupportedOperation in BeanManager
> -
>
> Key: MYFACES-4578
> URL: https://issues.apache.org/jira/browse/MYFACES-4578
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0-RC5
>Reporter: Melloware
>Priority: Major
>
> Getting this error not in native mode just running in *quarkus:dev* mode.
> Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
> {code:java}
> public void rebuildView() {
> log.info("OmniFaces rebuildView()");
> Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
> this);
> Faces.setViewRoot(Faces.getViewId());
> }{code}
>
>
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at
> io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
> at
> org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
> at
> org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
> at
> org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
> at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
> at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.apache.el.parser.AstValue.invoke(AstValue.java:253) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4578) Quarkus3: UnsupportedOperation in BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696466#comment-17696466
]
Melloware commented on MYFACES-4578:
What is interesting is that same code exists in Quarkus2 its not supported so
and MyFaces 2.3-next looks the same but seems to work?
> Quarkus3: UnsupportedOperation in BeanManager
> -
>
> Key: MYFACES-4578
> URL: https://issues.apache.org/jira/browse/MYFACES-4578
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0-RC5
>Reporter: Melloware
>Priority: Major
>
> Getting this error not in native mode just running in *quarkus:dev* mode.
> Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
> {code:java}
> public void rebuildView() {
> log.info("OmniFaces rebuildView()");
> Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
> this);
> Faces.setViewRoot(Faces.getViewId());
> }{code}
>
>
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at
> io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
> at
> org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
> at
> org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
> at
> org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
> at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
> at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.apache.el.parser.AstValue.invoke(AstValue.java:253) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4578) Quarkus3: UnsupportedOperation in BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696462#comment-17696462
]
Melloware commented on MYFACES-4578:
Ahh here is why:
[https://github.com/quarkusio/quarkus/blob/59e47e72c6c6ea64da3baaddc3b8b79485a706be/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/impl/BeanManagerImpl.java#L107-L110]
{code:java}
@Overridepublic Bean getPassivationCapableBean(String id) {
throw new UnsupportedOperationException();} {code}
> Quarkus3: UnsupportedOperation in BeanManager
> -
>
> Key: MYFACES-4578
> URL: https://issues.apache.org/jira/browse/MYFACES-4578
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.0-RC5
>Reporter: Melloware
>Priority: Major
>
> Getting this error not in native mode just running in *quarkus:dev* mode.
> Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
> {code:java}
> public void rebuildView() {
> log.info("OmniFaces rebuildView()");
> Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
> this);
> Faces.setViewRoot(Faces.getViewId());
> }{code}
>
>
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at
> io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
> at
> org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
> at
> org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
> at
> org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
> at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
> at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
> at
> io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.apache.el.parser.AstValue.invoke(AstValue.java:253) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4578) Quarkus3: UnsupportedOperation in BeanManager
Melloware created MYFACES-4578:
--
Summary: Quarkus3: UnsupportedOperation in BeanManager
Key: MYFACES-4578
URL: https://issues.apache.org/jira/browse/MYFACES-4578
Project: MyFaces Core
Issue Type: Bug
Components: Extension Feature
Affects Versions: 4.0.0-RC5
Reporter: Melloware
Getting this error not in native mode just running in *quarkus:dev* mode.
Java code using OmniFaces works in Qaurkus2 and outside of Quarkus:
{code:java}
public void rebuildView() {
log.info("OmniFaces rebuildView()");
Messages.addInfo("cdiViewScopedForm", "Rebuild view invoked: {0}",
this);
Faces.setViewRoot(Faces.getViewId());
}{code}
{code:java}
Caused by: java.lang.UnsupportedOperationException
at
io.quarkus.arc.impl.BeanManagerImpl.getPassivationCapableBean(BeanManagerImpl.java:109)
at
org.apache.myfaces.cdi.util.ContextualStorage.getBean(ContextualStorage.java:168)
at
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:213)
at
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:249)
at
org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder_ClientProxy.destroyAll(Unknown
Source)
at
org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:221)
at
org.apache.myfaces.cdi.view.ViewScopeCDIMap.clear(ViewScopeCDIMap.java:147)
at
org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:151)
at
org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:303)
at org.omnifaces.util.FacesLocal.setViewRoot(FacesLocal.java:489)
at org.omnifaces.util.Faces.setViewRoot(Faces.java:738)
at
io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean.rebuildView(OmniCdiViewScopedBean.java:72)
at
io.quarkiverse.omnifaces.it.OmniCdiViewScopedBean_ClientProxy.rebuildView(Unknown
Source)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.el.parser.AstValue.invoke(AstValue.java:253) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4577) ui:insert nested in ui:include not added to component tree
[
https://issues.apache.org/jira/browse/MYFACES-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695700#comment-17695700
]
Melloware commented on MYFACES-4577:
Thank you for the runnable reproducer!
> ui:insert nested in ui:include not added to component tree
> --
>
> Key: MYFACES-4577
> URL: https://issues.apache.org/jira/browse/MYFACES-4577
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC5
> Environment: primefaces-test project, jakarta branch
>Reporter: Manuel K
>Priority: Major
>
> When having a structure where a ui:insert is used in a file included by
> ui:include, the components that should be added by the ui:insert are not
> added to the component tree or at least not before other components are
> processed.
> So the structure is as follows:
> ui:composition (test.xhtml) uses template (template.xhtml) and defines a
> header that is included from another file using ui:include (test_header.xhtml)
> template (template.xhtml) includes a ui:composition (header.xhtml) that
> inserts the header into the template
> The composite component specified in test_header.xhtml is not added to the
> component tree before the update attribute of a commandButton is processed
> and throws a ComponentNotFoundException.
> You probably didn't understand a single thing, so the easiest is to take a
> look at the primefaces-test project I created here:
> https://github.com/mkomko/primefaces-test/tree/component-not-found
> I can't say for sure if this structure is supported by the spec, but it works
> in Mojarra.
> It works using
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> but not using
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> Thank you very much in advance for taking a look! We're evaluating migrating
> our large web application from Mojarra to MyFaces, so you might hear from me
> again ;).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4574) Integration Tests Failing With Chrome Driver Issue
Melloware created MYFACES-4574:
--
Summary: Integration Tests Failing With Chrome Driver Issue
Key: MYFACES-4574
URL: https://issues.apache.org/jira/browse/MYFACES-4574
Project: MyFaces Core
Issue Type: Improvement
Components: General
Affects Versions: 4.0.0-RC5
Reporter: Melloware
{code:java}
Runtime Unable to instantiate Drone via
org.openqa.selenium.chrome.ChromeDriver(ChromeOptions):
org.openqa.selenium.SessionNotCreatedException: Could not start a new session.
Response code 500. Message: session not created: This version of ChromeDriver
only supports Chrome version 108
Current browser version is 110.0.5481.100 with binary path
/usr/bin/google-chrome
Host info: host: 'fv-az357-369', ip: '10.1.1.53'
Build info: version: '4.7.2', revision: '4d4020c3b7'
System info: os.name: 'Linux', os.arch: 'amd64', os.version:
'5.15.0-1033-azure', java.version: '11.0.18'
Driver info: org.openqa.selenium.chrome.ChromeDriver
Command: [null, newSession {capabilities=[Capabilities {browserName: chrome,
browserVersion: 100, chromeDriverVersion: 108.0.5359.71, goog:chromeOptions:
{args: [--headless], extensions: []}, platformName: ANY}],
desiredCapabilities=Capabilities {browserName: chrome, browserVersion: 100,
chromeDriverVersion: 108.0.5359.71, goog:chromeOptions: {args: [--headless],
extensions: []}, platformName: ANY}}] {code}
[https://github.com/arquillian/arquillian-extension-drone/issues/381]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4573) Quarkus Native: Register web.xml and error pages
[
https://issues.apache.org/jira/browse/MYFACES-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Melloware resolved MYFACES-4573.
Resolution: Fixed
> Quarkus Native: Register web.xml and error pages
>
>
> Key: MYFACES-4573
> URL: https://issues.apache.org/jira/browse/MYFACES-4573
> Project: MyFaces Core
> Issue Type: Improvement
> Components: Extension Feature
>Affects Versions: 2.3-next-M7, 4.0.0-RC5
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
> Fix For: 2.3-next-M8, 4.0.0-RC6
>
>
> When running in Quarkus Native mode only:
> # resources in /META-INF/resources are registered which means
> `META-INF/web.xml` is not included but needs to be.
> # Resource registered in error pages must be registered with Reflection so
> things like OmniFacesExceptionHandler and PrimeExceptionHanlder can handle
> them and display them in EL on pages.
>
> {code:java}
>
> java.lang.Throwable
> /error.xhtml
>
>
>
> javax.faces.application.ViewExpiredException
> /viewExpired.xhtml
>
>
> 404
> /error.xhtml
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4573) Quarkus Native: Register web.xml and error pages
Melloware created MYFACES-4573:
--
Summary: Quarkus Native: Register web.xml and error pages
Key: MYFACES-4573
URL: https://issues.apache.org/jira/browse/MYFACES-4573
Project: MyFaces Core
Issue Type: Improvement
Components: Extension Feature
Affects Versions: 4.0.0-RC5, 2.3-next-M7
Reporter: Melloware
When running in Quarkus Native mode only:
# resources in /META-INF/resources are registered which means
`META-INF/web.xml` is not included but needs to be.
# Resource registered in error pages must be registered with Reflection so
things like OmniFacesExceptionHandler and PrimeExceptionHanlder can handle them
and display them in EL on pages.
{code:java}
java.lang.Throwable
/error.xhtml
javax.faces.application.ViewExpiredException
/viewExpired.xhtml
404
/error.xhtml
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
