Re: MyFaces last 2.3.X 2.3.-next release?
I think these HTMLUnit ones are related to the new JS code and I think the tests have been updated in newer TCK's to not use HTMLUnit i think. On Tue, Jun 11, 2024 at 3:47 PM Volodymyr Siedlecki wrote: > Hello, > > Sorry for the long delay. I'm starting to get results for the > 2.3.11-snapshot back. > > Current tests that fail: > > ee.jakarta.ee4j8.cts.liberty_fat.jsf_api_javax_faces_application FAT tests > com.sun.ts.tests.jsf.api.javax_faces.application.resource.URLClient > resourceGetRequestPathLibTest > resourceGetRequestPathTest > resourceToStringTest > com.sun.ts.tests.jsf.api.javax_faces.application.resourcewrapper.URLClient > resourceWrapperGetRequestPathLibTest > resourceWrapperGetRequestPathTest > ee.jakarta.ee4j8.cts.liberty_fat.jsf_spec FAT tests > com.sun.ts.tests.jsf.spec.ajax.keyword.URLClient > ajaxAllKeywordTest > ajaxFormKeywordTest > ajaxNoneKeywordTest > ajaxThisKeywordTest > com.sun.ts.tests.jsf.spec.ajax.tagwrapper.URLClient > ajaxTagWrappingTest > com.sun.ts.tests.jsf.spec.render.commandlink.URLClient > clinkRenderDecodeTest > clinkRenderEncodeTest > clinkRenderPassthroughTest > com.sun.ts.tests.jsf.spec.view.protectedview.URLClient > viewProtectedViewSameWebAppAccessTest > > The latter test seems to fail because of JavaScript. For example: > > AssertionFailure: test result: Failed. Test case throws exception: > com.gargoylesoftware.htmlunit.ScriptException: syntax error (script in > http://localhost:9080/jsf_render_clink_web/faces/encodetest.jsp from (16, > 213) to (99, 1)#22) > test result: Failed. Test case throws exception: > com.gargoylesoftware.htmlunit.ScriptException: syntax error (script in > http://localhost:9080/jsf_render_clink_web/faces/encodetest.jsp from (16, > 213) to (99, 1)#22) > > The rest of the tests should finish up later in the day. > > Thanks, > Volodymyr > > On 2024/05/08 17:49:46 Volodymyr Siedlecki wrote: > > Hi, > > > > I've been focused on one other work, but I'm shifting priorities and am > starting to look into a release. > > > > I'm first running the TCK against the current 2.3.11 snapshot. I'll > share the results once I have them. > > > > Thanks, > > > > Volodymyr > > > > On 2024/04/22 14:59:55 Melloware Inc wrote: > > > Thank you for looking into this! > > > > > > On Mon, Apr 22, 2024 at 10:39 AM Volodymyr Siedlecki < > volos...@apache.org> > > > wrote: > > > > > > > Hi, > > > > > > > > I can look into doing releases for both. > > > > > > > > Only concern I have is that there may be TCK failures in the current > 2.3 > > > > branch. I tried to do a release sometime last year, but discovered a > number > > > > of failures. I'll run another build with teh current snapshot to > see if > > > > there are still there. > > > > > > > > Although, it's possible the failures may have been > infrastructure/network > > > > related? > > > > > > > > I'll let you know more once I found out. > > > > > > > > Best, > > > > Volodymyr > > > > > > > > On 2024/04/22 13:56:54 Melloware Inc wrote: > > > > > Hey team, > > > > > > > > > > I know we are slowing down stopping on the 2.3.x branch but one > last > > > > > release since it's been a year would be great. We have one bug with > > > > > PrimeFaces around SearchExpressions which has been fixed but not > released > > > > > in 2.3 and 2.3-next that is going to cause a lot of heartache > upgrading > > > > to > > > > > PF14. > > > > > > > > > > Volodymyr, I know this burden is on you and sorry in advance for > > > > asking. I > > > > > know the effort it takes. > > > > > > > > > > Mello > > > > > > > > > > -- > > > > > == > > > > > Melloware > > > > > melloware...@gmail.com > > > > > http://melloware.com > > > > > == > > > > > > > > > > > > > > > > > > -- > > > == > > > Melloware > > > melloware...@gmail.com > > > http://melloware.com > > > == > > > > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
[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)
Re: [VOTE] Release of MyFaces Core 4.10-RC2
+1 Melloware @melloware on GitHub > On Apr 26, 2024, at 4:54 PM, Volodymyr Siedlecki wrote: > > > Hi, > > I was running the needed tasks to get the 4.1.0-RC2 release of Apache > MyFaces core out. > > Please note that this vote concerns all of the following parts: >1. Maven artifact group “org.apache.myfaces.core” v4.1.0-RC2 [1] > > The artifacts were deployed on nexus repo [1] for binary and source > packages. > > The release notes could be found at [4]. > > The japicmp tool shows no binary incompatibilities with 4.1.0-RC1. > Please take a look at the attached results.html. > > This release has not yet been run against the TCK. > > Please take a look at the “4.1.0-RC2" artifacts and vote! (see [3]) > > Please note: This vote is “majority approval” with a minimum of three +1 > votes (see [2]). > > > [ ] +1 for community members who have reviewed the bits > [ ] +0 > [ ] -1 for fatal flaws that should cause these bits not to be released, and > why. > > > Thanks, > > Volodymyr > > [1] > https://repository.apache.org/content/repositories/orgapachemyfaces-1247/org/apache/myfaces/core/ > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes > [3] > https://repository.apache.org/content/repositories/orgapachemyfaces-1247/org/apache/myfaces/core/myfaces-core-assembly/ > [4] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12354226 >
Re: MyFaces last 2.3.X 2.3.-next release?
Thank you for looking into this! On Mon, Apr 22, 2024 at 10:39 AM Volodymyr Siedlecki wrote: > Hi, > > I can look into doing releases for both. > > Only concern I have is that there may be TCK failures in the current 2.3 > branch. I tried to do a release sometime last year, but discovered a number > of failures. I'll run another build with teh current snapshot to see if > there are still there. > > Although, it's possible the failures may have been infrastructure/network > related? > > I'll let you know more once I found out. > > Best, > Volodymyr > > On 2024/04/22 13:56:54 Melloware Inc wrote: > > Hey team, > > > > I know we are slowing down stopping on the 2.3.x branch but one last > > release since it's been a year would be great. We have one bug with > > PrimeFaces around SearchExpressions which has been fixed but not released > > in 2.3 and 2.3-next that is going to cause a lot of heartache upgrading > to > > PF14. > > > > Volodymyr, I know this burden is on you and sorry in advance for > asking. I > > know the effort it takes. > > > > Mello > > > > -- > > == > > Melloware > > melloware...@gmail.com > > http://melloware.com > > == > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
MyFaces last 2.3.X 2.3.-next release?
Hey team, I know we are slowing down stopping on the 2.3.x branch but one last release since it's been a year would be great. We have one bug with PrimeFaces around SearchExpressions which has been fixed but not released in 2.3 and 2.3-next that is going to cause a lot of heartache upgrading to PF14. Volodymyr, I know this burden is on you and sorry in advance for asking. I know the effort it takes. Mello -- == Melloware melloware...@gmail.com http://melloware.com ==
[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)
Re: MyFaces: Retire 3.0 (possibly 2.3?)
I am +1 for supporting 2.3. But -1 for 3.0. I guess 17% running 9.0 shocks me as it was just a namespace change? In fact my clients didn’t even bother with it and just waited for 4.0 final. Arjun and Balus said it was more for libraries and containers to practice the new namespace it was not meant to be production level suppported. Red Hat did not provide a supported 9.0 version for Jboss they simply provided a preview version until EE10 went final. Not that it matters but we do not get any reports at PrimeFacces or OmniFaces repos of anyone running Faces 3.0. Most issues being reported are on 2.3 or 4.0. I just want to make sure we are spending are limited resources on the right things?Melloware@melloware on GitHubOn Feb 12, 2024, at 9:35 AM, Paul Nicolucci wrote:Hi,I would like to see MyFaces continue to actively support both MyFaces 2.3 and MyFaces 3.0 until there is a time when we see the use of these releases drastically decrease. Looking at the 2023 Jakarta EE Survey: 28% of respondents still use Jakarta EE8 (Faces 2.3) in 2023. This is up 4% from 2022.17% of respondents are running Jakarta EE 9/9.1 in production (Faces 3.0) in 2023. This is up 3% from 2022.Given the above, we would discontinue active support for potentially 45% of our user base.Regards,Paul NicolucciOn Mon, Feb 12, 2024 at 9:17 AM Melloware Inc <melloware...@gmail.com> wrote:Team,As the Mojarra team has completely stopped supporting the 2.3 and 3.0 branches should MyFaces as well?Arjan and Balus said that 3.0 was just the namespace change and no one should be using it in production; they should be on 4.0 at this point now that it is official.As for 2.3 retiring I am not sure about this one because 2.3 is the most widely adopted version if I had to guess right now?Thoughts?Melloware -- == Melloware melloware...@gmail.comhttp://melloware.com ==
Fwd: MyFaces: Retire 3.0 (possibly 2.3?)
Team, As the Mojarra team has completely stopped supporting the 2.3 and 3.0 branches should MyFaces as well? Arjan and Balus said that 3.0 was just the namespace change and no one should be using it in production; they should be on 4.0 at this point now that it is official. As for 2.3 retiring I am not sure about this one because 2.3 is the most widely adopted version if I had to guess right now? Thoughts? Melloware -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [VOTE] Release of MyFaces Core 4.0.2
+1. I just tested the JAR for 4.0.2 locally and everything looks good. On Wed, Jan 24, 2024 at 4:30 PM Volodymyr Siedlecki wrote: > Hi, > > I was running the needed tasks to get the 4.0.2 release of Apache MyFaces > core out. > > Please note that this vote concerns all of the following parts: >1. Maven artifact group "org.apache.myfaces.core" v4.0.2 [1] > > The artifacts were deployed on nexus repo [1] for binary and source > packages. > > The release notes could be found at [4]. > > The japicmp tool shows no binary incompatibilities with 4.0.2 when > compared to the previous 4.0.1 jar. Please take a look at the attached > results html file. > If requested, I can provide a comparison to the Jakarta Faces 4.0.1 API. > > A recent snapshot was tested against the TCK and passed. I will run it > again to verify it again once more before releasing the jars. > > Please take a look at the "4.0.2" artifacts and vote! (see [3]) > > Please note: This vote is "majority approval" with a minimum of three +1 > votes (see [2]). > > > [ ] +1 for community members who have reviewed the bits > [ ] +0 > [ ] -1 for fatal flaws that should cause these bits not to be released, > and why. > > > Thanks, > > Volodymyr > > [1] > https://repository.apache.org/content/repositories/orgapachemyfaces-1243/org/apache/myfaces/core/ > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes > [3] > https://repository.apache.org/content/repositories/orgapachemyfaces-1243/org/apache/myfaces/core/myfaces-core-assembly/ > [4] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=1235 > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [VOTE] Release of MyFaces Core 4.1.0-RC1
+1 from me! On Wed, Jan 24, 2024 at 3:50 PM Volodymyr Siedlecki wrote: > Hello, again. > > Please review the new RC1 jars: > https://repository.apache.org/content/repositories/orgapachemyfaces-1242/org/apache/myfaces/core/ > > myfaces-core-module-4.1.0-RC1 Tag: > https://github.com/apache/myfaces/releases/tag/myfaces-core-module-4.1.0-RC1 > > Thanks, > > Volodymyr > > On 2024/01/24 19:54:52 Volodymyr Siedlecki wrote: > > I found a mistake -- let me re-stage. > > > > I dropped > https://repository.apache.org/content/repositories/orgapachemyfaces-1241/org/apache/myfaces/core/ > and the jars aren't available anymore. > > > > On 2024/01/24 19:16:53 Volodymyr Siedlecki wrote: > > > Hi, > > > > > > I was running the needed tasks to get the 4.1.0-RC1 release of Apache > > > MyFaces core out. > > > > > > Please note that this vote concerns all of the following parts: > > >1. Maven artifact group “org.apache.myfaces.core” v4.1.0-RC1 [1] > > > > > > The artifacts were deployed on nexus repo [1] for binary and source > > > packages. > > > > > > The release notes could be found at [4]. > > > > > > The japicmp tool shows some binary incompatibilities with 4.1.0-RC1 > and the > > > jakarta.faces-api-4.1.0-M1.jar. Please take a look at the attached > > > results.html. > > > > > > This release has not yet been run against the TCK. > > > > > > Please take a look at the “4.1.0-RC1" artifacts and vote! (see [3]) > > > > > > Please note: This vote is “majority approval” with a minimum of three > +1 > > > votes (see [2]). > > > > > > > > > [ ] +1 for community members who have reviewed the bits > > > [ ] +0 > > > [ ] -1 for fatal flaws that should cause these bits not to be > released, and > > > why. > > > > > > > > > Thanks, > > > > > > Volodymyr > > > > > > [1] > > > > https://repository.apache.org/content/repositories/orgapachemyfaces-1241/org/apache/myfaces/core/ > > > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes > > > [3] > > > > https://repository.apache.org/content/repositories/orgapachemyfaces-1241/org/apache/myfaces/core/myfaces-core-assembly/ > > > [4] > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12353454 > > > > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: 4.1 M1 Release?
As long as it has a dash like 4.1.0-M1 or 4.1.0-RC1 as Maven is very particular about that and not 4.0.1.M1 On Thu, Jan 18, 2024 at 2:17 PM Volodymyr Siedlecki wrote: > Just want to confirm that I should make 4.1 an M1? Or should it be a RC1? > > I'll start the release process on Monday. > > Volodymyr > > On 2024/01/16 17:54:49 Volodymyr Siedlecki wrote: > > Sounds good. I'll comment out the integration tests for the release. > > > > Expected a vote out sometime next week! > > > > Thanks, > > Volodymyr > > > > On 2024/01/16 13:45:46 Thomas Andraschko wrote: > > > Hi, > > > > > > in worst case you can comment out the integration modules in POM for > now. > > > i currently fix some bugs in MF 4.0.x and will merge them into 4.1 and > 5.0. > > > If you could do a release next week, it would be great (both 4.0 and > 4.1). > > > > > > Best regards, > > > Thomas > > > > > > > > > Am Mi., 10. Jan. 2024 um 16:57 Uhr schrieb Volodymyr Siedlecki < > > > volos...@apache.org>: > > > > > > > Hi, > > > > > > > > I've been trying to get a successful build locally on my machine for > the > > > > release, but I've encountered errors with the integration tests: > > > > > > > > Caused by: > > > > > org.jboss.arquillian.drone.webdriver.binary.downloading.source.MissingBinaryException: > > > > There wasn’t found any binary on the url: > > > > > https://chromedriver.storage.googleapis.com/114.0.5735.90/chromedriver_mac64_m1.zip > > > > at > > > > > org.jboss.arquillian.drone.webdriver.binary.handler.ChromeDriverBinaryHandler$ChromeStorageSources.getLatestRelease(ChromeDriverBinaryHandler.java:129) > > > > at > > > > > org.jboss.arquillian.drone.webdriver.binary.downloading.source.UrlStorageSource.getLatestRelease(UrlStorageSource.java:59) > > > > at > > > > > org.jboss.arquillian.drone.webdriver.binary.handler.AbstractBinaryHandler.downloadAndPrepare(AbstractBinaryHandler.java:175) > > > > at > > > > > org.jboss.arquillian.drone.webdriver.binary.handler.AbstractBinaryHandler.checkAndSetBinary(AbstractBinaryHandler.java:61) > > > > … 14 more > > > > > > > > The problem above should be fixed via > > > > https://github.com/arquillian/arquillian-extension-drone/pull/401 > > > > > > > > I then tried on Linux, but I can’t get it running either > > > > > > > > java.lang.RuntimeException: > > > > 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: unknown error: Chrome failed to > start: > > > > exited abnormally. > > > > (unknown error: DevToolsActivePort file doesn’t exist) > > > > (The process started from chrome location /usr/bin/google-chrome > is no > > > > longer running, so ChromeDriver is assuming that Chrome has crashed.) > > > > > > > > > > > > https://chromedriver.chromium.org/downloads recommends to use > "chrome for > > > > testing" instead. > > > > > > > > https://googlechromelabs.github.io/chrome-for-testing/ > > > > > > > > Current chrome binary is 120.0.6099.199, but the endpoints are down > for > > > > the stable upcoming API for a previous version. This also causes > errors > > > > since chrome binary and the chromedriver need to match versions > (which I > > > > also tried via '-Dwebdriver.chrome.driver', but it still failed). > > > > > > > > I'll try a few other things, and hope there are more updates to > chrome, > > > > selenium, and arquillian. Right now I'm a bit stuck. > > > > > > > > Volodymyr > > > > > > > > On 2024/01/04 10:04:14 Paul Nicolucci wrote: > > > > > +1 from me! > > > > > > > > > > Thanks, > > > > > > > > > > Paul Nicolucci > > > > > > > > > > On Thu, Jan 4, 2024, 4:32 AM Thomas Andraschko < > > > > andraschko.tho...@gmail.com> > > > > > wrote: > > > > > > > > > > > +1 (both 4.1 and 4.0) > > > > > > just fixing some minor issues and applying PRs, we are ready > tomorrow > > > > > > > > > > > > > > > > > > Am Mi., 3. Jan. 2024 um 22:17 Uhr schrieb Melloware < > > > > > > melloware...@gmail.com>: > > > > > > > > > > > >> No objection from me. > > > > > >> > > > > > >> On 1/3/2024 4:14 PM, Volodymyr Siedlecki wrote: > > > > > >> > Hello, > > > > > >> > > > > > > >> > May I start a 4.1 M1 release for MyFaces? Let me know if > there are > > > > > >> > objections. > > > > > >> > > > > > > >> > Additionally, I'm still working on a 4.0.2 release, but > focusing on > > > > > >> > getting a passing TCK first. > > > > > >> > > > > > > >> > Best, > > > > > >> > > > > > > >> > Volodymyr > > > > > >> > > > > > >> -- > > > > > >> Melloware > > > > > >> melloware@ > > > > > >> > > > > > >> > > > > > > > > > > > > > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: 4.1 M1 Release?
No objection from me. On 1/3/2024 4:14 PM, Volodymyr Siedlecki wrote: Hello, May I start a 4.1 M1 release for MyFaces? Let me know if there are objections. Additionally, I'm still working on a 4.0.2 release, but focusing on getting a passing TCK first. Best, Volodymyr -- Melloware melloware@
[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)
Re: Thoughts on 2.3, 2.3-next, 3.0, and 4.0 releases?
I think based on Mojarra conversations they have dropped 3.0 support entirely. See this conversation: https://github.com/eclipse-ee4j/mojarra/issues/5298#issuecomment-1677186825 So 2.3, 2.3-next, and 4.0 would be great with me! On 9/21/2023 3:08 PM, Volodymyr Siedlecki wrote: Hello, It's been a while since we've had 2.3, 2.3-next, and 3.0 releases. I could also do one for 4.0, if requested. Let me know. Thanks! -- Melloware melloware@
[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)
Re: [VOTE] Release of MyFaces Core 4.0.1
Perfect! Melloware @melloware on GitHub > On May 23, 2023, at 3:12 PM, Volodymyr Siedlecki wrote: > > Hi, > > Turns out these failures were infrastructure related. Manual tests show that > they pass. > > I'll change vote to a +1. > > If no objections, I'll release 4.0.1 tomorrow? > > Best, > Volodymyr > >> On 2023/05/22 13:39:11 Volodymyr Siedlecki via dev wrote: >> Hey Thomas, >> >> Yes, the TCK tests were passing previously on 4.0.0. I haven’t >> investigated into the root causes yet, but I’ll look soon. >> >> Thanks, >> >> Volodymyr >> >> From: Thomas Andraschko >> Date: Monday, May 22, 2023 at 4:05 AM >> To: MyFaces Development >> Subject: [EXTERNAL] Re: [VOTE] Release of MyFaces Core 4.0.1 >> and they are working on 4. 0. 0? Am So. , 21. Mai 2023 um 03: 23 Uhr schrieb >> Volodymyr Siedlecki : Sorry, I linked the classes, >> not the tests. Here are the 7 failing tests (from the old tck): com. sun. >> ts. tests. jsf. spec. appconfigresources. absolute_ordering. URLClient >> ZjQcmQRYFpfptBannerStart >> This Message Is From an Untrusted Sender >> You have not previously corresponded with this sender. >> ZjQcmQRYFpfptBannerEnd >> and they are working on 4.0.0? >> >> Am So., 21. Mai 2023 um 03:23 Uhr schrieb Volodymyr Siedlecki >> mailto:volos...@apache.org>>: >> Sorry, I linked the classes, not the tests. Here are the 7 failing tests >> (from the old tck): >> >> com.sun.ts.tests.jsf.spec.appconfigresources.absolute_ordering.URLClient >> - testDocumentAbsoluteOrdering >> com.sun.ts.tests.jsf.spec.appconfigresources.relative_ordering.URLClient >> - testDocumentRelativeOrderingTest1 >> com.sun.ts.tests.jsf.spec.appconfigresources.startupbehavior.URLClient >> - applicationConfigurationfilesTest1 >> - applicationConfigurationfilesTest2 >> com.sun.ts.tests.jsf.spec.composite.insertchildren.URLClient >> - compositeRenderUsingPageChildrenTagTest >> com.sun.ts.tests.jsf.spec.coretags.selectitems.URLClient >> - selectItemsValueTest >> com.sun.ts.tests.jsf.spec.coretags.viewaction.URLClient >> - viewActionTest >> >>> On 2023/05/21 01:18:57 Volodymyr Siedlecki wrote: >>> -1 for me. TCK results finally got back (sorry for the delay) and we have >>> failures for the following tests: >>> >>> com.sun.ts.tests.jsf.spec.appconfigresources.absolute_ordering.URLClient >>> com.sun.ts.tests.jsf.spec.appconfigresources.relative_ordering.URLClient >>> com.sun.ts.tests.jsf.spec.appconfigresources.startupbehavior.URLClient >>> com.sun.ts.tests.jsf.spec.composite.insertchildren.URLClient >>> com.sun.ts.tests.jsf.spec.coretags.selectitems.URLClient >>> com.sun.ts.tests.jsf.spec.coretags.viewaction.URLClient >>> >>> I will need to investigate them. >>> >>> On 2023/05/18 00:41:36 Thomas Andraschko wrote: >>>> +1 >>>> >>>> Melloware mailto:melloware...@gmail.com>> schrieb >>>> am Mi., 17. Mai 2023, 22:11: >>>> >>>>> +1 >>>>> >>>>> >>>>> On 5/17/2023 3:52 PM, Volodymyr Siedlecki wrote: >>>>>> Hi, >>>>>> >>>>>> I was running the needed tasks to get the 4.0.1 release of Apache >>>>>> MyFaces core out. >>>>>> >>>>>> Please note that this vote concerns all of the following parts: >>>>>> 1. Maven artifact group "org.apache.myfaces.core" v4.0.1 [1] >>>>>> >>>>>> The artifacts were deployed on nexus repo [1] for binary and source >>>>>> packages. >>>>>> >>>>>> The release notes could be found at [4]. >>>>>> >>>>>> The japicmp tool shows no binary incompatibilities with 4.0.1 when >>>>>> compared to the previous 4.0.0 jar. Please take a look at the attached >>>>>> results.html. >>>>>> If requested, I can provide a comparison to the Jakarta Faces 4.0.1 API. >>>>>> >>>>>> This release has not yet been run against the TCK, but I am working to >>>>>> create a build which will run against the TCK. I hope to have results >>>>>> by May 19. >>>>>> >>>>>> Please take a look at the "4.0.1" artifacts and vote! (see [3]) >>>>>> >>>>>> Please note: This vote is "majority approval&
Re: selenium chromium driver version [Was: [VOTE] Release of MyFaces Core 4.0.1]
Mike,
You bring up a great point. This is what the GitHub Actions workflow does.
mvn -B -V clean verify checkstyle:check apache-rat:check -Dformats=XML
-DchromeDriverVersion=112.0.5615.49 -f pom.xml
Where it forces a specific chrome driver. Not great i agree.
On 5/22/2023 7:59 AM, Mike Kienenberger wrote:
So I was trying to run the checklist to vote on MyFaces Core 4.0.1
(first time in a long while when I've had time), but I couldn't get
past trying to build the project from source.
The build process is downloading ChromeDriver 113.0.5672.63 for
integration tests but my version of linux is still at chromium
112.0.5615.165.
I could not figure out how to change the version of chromedriver used
for the test.
This does bring up a build-reproducibility issue though. If the build
depends on the end-user having a specific version of chromium
installed, this will cause issues down the road as the released
artifacts get older. Not sure if there's a simple solution for this,
though. If I have time later, I'll probably try running the build
from a docker container with the expected version of chrome
installed. Since Volodymyr already thinks we should not release yet,
I guess there's no time pressure.
On Wed, May 17, 2023 at 8:42 PM Thomas Andraschko
wrote:
+1
Melloware schrieb am Mi., 17. Mai 2023,
22:11:
+1
On 5/17/2023 3:52 PM, Volodymyr Siedlecki wrote:
> Hi,
>
> I was running the needed tasks to get the 4.0.1 release of
Apache
> MyFaces core out.
>
> Please note that this vote concerns all of the following parts:
> 1. Maven artifact group "org.apache.myfaces.core" v4.0.1 [1]
>
> The artifacts were deployed on nexus repo [1] for binary and
source
> packages.
>
> The release notes could be found at [4].
>
> The japicmp tool shows no binary incompatibilities with
4.0.1 when
> compared to the previous 4.0.0 jar. Please take a look at
the attached
> results.html.
> If requested, I can provide a comparison to the Jakarta
Faces 4.0.1 API.
>
> This release has not yet been run against the TCK, but I am
working to
> create a build which will run against the TCK. I hope to
have results
> by May 19.
>
> Please take a look at the "4.0.1" artifacts and vote! (see [3])
>
> Please note: This vote is "majority approval" with a minimum
of three
> +1 votes (see [2]).
>
>
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be
> released, and why.
>
>
> Thanks,
>
> Volodymyr
>
> [1]
>
https://repository.apache.org/content/repositories/orgapachemyfaces-1231/org/apache/myfaces/core/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3]
>
https://repository.apache.org/content/repositories/orgapachemyfaces-1231/org/apache/myfaces/core/myfaces-core-assembly/
> [4]
>
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12352978
<https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12352978>
>
<https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12352978
<https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12352978>>
>
--
Melloware
melloware@
--
Melloware
melloware@
Re: [VOTE] Release of MyFaces Core 4.0.1
+1 On 5/17/2023 3:52 PM, Volodymyr Siedlecki wrote: Hi, I was running the needed tasks to get the 4.0.1 release of Apache MyFaces core out. Please note that this vote concerns all of the following parts: 1. Maven artifact group "org.apache.myfaces.core" v4.0.1 [1] The artifacts were deployed on nexus repo [1] for binary and source packages. The release notes could be found at [4]. The japicmp tool shows no binary incompatibilities with 4.0.1 when compared to the previous 4.0.0 jar. Please take a look at the attached results.html. If requested, I can provide a comparison to the Jakarta Faces 4.0.1 API. This release has not yet been run against the TCK, but I am working to create a build which will run against the TCK. I hope to have results by May 19. Please take a look at the "4.0.1" artifacts and vote! (see [3]) Please note: This vote is "majority approval" with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why. Thanks, Volodymyr [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1231/org/apache/myfaces/core/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] https://repository.apache.org/content/repositories/orgapachemyfaces-1231/org/apache/myfaces/core/myfaces-core-assembly/ [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12352978 <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12352978> -- Melloware melloware@
Re: 4.0.0 Release Plan
Thank you! On 5/15/2023 2:23 PM, Volodymyr Siedlecki wrote: I'm back. Catching up on things, but I will to start on the 4.0.1 release tomorrow. Best, Volodymyr On 2023/05/07 12:30:35 Melloware wrote: Volodymyr, just a gentle reminder for a 4.0.1 :) Thanks! On 4/5/2023 10:27 PM, Volodymyr Siedlecki wrote: It's on me for being so slow. I'll have 2.3-next started tomorrow and 4.0.1 afterwards. Thanks for your patience! On 2023/04/05 19:17:27 Melloware wrote: Volodymyr, I know you are busy but I would love a 4.0.1 and 2.3-next release if possible? Sorry to be a pain! Melloware -- Melloware melloware@ -- Melloware melloware@
[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)
Re: 4.0.0 Release Plan
Volodymyr, just a gentle reminder for a 4.0.1 :) Thanks! On 4/5/2023 10:27 PM, Volodymyr Siedlecki wrote: It's on me for being so slow. I'll have 2.3-next started tomorrow and 4.0.1 afterwards. Thanks for your patience! On 2023/04/05 19:17:27 Melloware wrote: Volodymyr, I know you are busy but I would love a 4.0.1 and 2.3-next release if possible? Sorry to be a pain! Melloware -- Melloware melloware@
Re: [VOTE] release of MyFaces Core 2.3-next-M8
+1 On 4/10/2023 2:40 PM, Volodymyr Siedlecki wrote: Hi, I was running the needed tasks to get the 2.3-next-M8 release of Apache MyFaces core out. Please note that this vote concerns all of the following parts: 1. Maven artifact group "org.apache.myfaces.core" v2.3-next-M8 [1] The artifacts were deployed on nexus repo [1] for binary and source packages. The release notes could be found at [4]. This new vote contains the revert of MYFACES-4598: https://github.com/apache/myfaces/commit/f42a12fdf80bf2b8478d018fd2a039128e1a0830 Also the japicmp tool (similar to clirr) shows one minor binary incompatibility with the previous 2.3-next-M7 myfaces-api. The PropertyDescriptorWrapper is missing a constructor due to this change: https://github.com/apache/myfaces/commit/f58a71758cab0d1b879e57dde36ac35441cda123#diff-35f4c66ab5eea233526be05aaf2c83a951dd1b99e0403a53743b81452b3a03daL39-L43 The results.html file is attached to this email. There were a few other small changes (i.e generics). Please take a look at the "2.3-next-M8" artifacts and vote! (see [3]) Please note: This vote is "majority approval" with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why. Thanks, Volodymyr [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1229/org/apache/myfaces/core/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] https://repository.apache.org/content/repositories/orgapachemyfaces-1229/org/apache/myfaces/core/myfaces-core-assembly/ [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12351789 <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12351789> -- Melloware melloware@
[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)
Re: 4.0.0 Release Plan
OK I just reverted a Quarkus change I made. I realize now why it was being done and Quarkus is just warning about it. On 4/5/2023 10:27 PM, Volodymyr Siedlecki wrote: It's on me for being so slow. I'll have 2.3-next started tomorrow and 4.0.1 afterwards. Thanks for your patience! On 2023/04/05 19:17:27 Melloware wrote: Volodymyr, I know you are busy but I would love a 4.0.1 and 2.3-next release if possible? Sorry to be a pain! Melloware -- Melloware melloware@
Re: [VOTE] release of MyFaces Core 2.3-next-M8
+1 On 4/6/2023 12:30 PM, Volodymyr Siedlecki wrote: Hi, I was running the needed tasks to get the 2.3-next-M8 release of Apache MyFaces core out. Please note that this vote concerns all of the following parts: 1. Maven artifact group "org.apache.myfaces.core" v2.3-next-M8 [1] The artifacts were deployed on nexus repo [1] for binary and source packages. The release notes could be found at [4]. Also the japicmp tool (similar to clirr) shows one minor binary incompatibility with the previous 2.3-next-M7 myfaces-api. The PropertyDescriptorWrapper is missing a constructor due to this change: https://github.com/apache/myfaces/commit/f58a71758cab0d1b879e57dde36ac35441cda123#diff-35f4c66ab5eea233526be05aaf2c83a951dd1b99e0403a53743b81452b3a03daL39-L43 The results.html file is attached to this email. Please take a look at the "2.3-next-M8" artifacts and vote! (see [3]) Please note: This vote is "majority approval" with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why. Thanks, Volodymyr [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1228/org/apache/myfaces/core/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] https://repository.apache.org/content/repositories/orgapachemyfaces-1228/org/apache/myfaces/core/myfaces-core-assembly/ [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12351789 <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12351789> -- Melloware melloware@
Re: 4.0.0 Release Plan
Volodymyr, I know you are busy but I would love a 4.0.1 and 2.3-next release if possible? Sorry to be a pain! Melloware
[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)
Re: Selenium test issue
Yes we have been fighting chrome issues. I think it’s related to the grapheme driver as I use Selenium with the automatic driver downloading on other projects and have no issues. But yes it’s broken the MyFaces build multiple times in the last 2 months every time Chrome updates. Melloware@melloware on GitHubOn Mar 8, 2023, at 9:01 PM, Paul Nicolucci wrote:I did just come across this: https://groups.google.com/g/chromedriver-users/c/xL5-13_qGaAOn Wed, Mar 8, 2023 at 8:51 PM Paul Nicolucci <pnicolu...@gmail.com> wrote:Is anyone else hitting issues with building the main branch? I pulled the latest this evening and initially, the build failed and told me I needed to update to Chrome 111. I updated chrome and now I'm getting the following error:[ERROR] Errors:[ERROR] IntegrationTest.test ▒ Runtime Unable to instantiate Drone via org.openqa.selenium.chrome.ChromeDriver(ChromeOptions): org.openqa.selenium.remote.http.ConnectionFailedException: Unable to establish websocket connection to http://localhost:56058/devtools/browser/a64ea175-1a1b-47dd-a3fd-e9b1d23d4d54Build info: version: '4.7.2', revision: '4d4020c3b7'System info: os.name: 'Windows 11', os.arch: 'amd64', os.version: '10.0', java.version: '11.0.18'Driver info: driver.version: ChromeDriver[ERROR] IntegrationTest.testPlainHtml ▒ Runtime Unable to instantiate Drone via org.openqa.selenium.chrome.ChromeDriver(ChromeOptions): org.openqa.selenium.remote.http.ConnectionFailedException: Unable to establish websocket connection to http://localhost:56041/devtools/browser/1843c22a-1678-43f4-891e-085b77c6263dBuild info: version: '4.7.2', revision: '4d4020c3b7'System info: os.name: 'Windows 11', os.arch: 'amd64', os.version: '10.0', java.version: '11.0.18'Driver info: driver.version: ChromeDriver[INFO][ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0Can we pin these test artifacts at a specific version so we don't risk hitting issues whenever Chrome updates?Werner, any suggestions? Thanks,Paul Nicolucci
[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:
