[PR] ci(github action): Docker integration tests [myfaces-tobago]
itno85 opened a new pull request, #4533: URL: https://github.com/apache/myfaces-tobago/pull/4533 * added a step to run ui tests for the tobago demo * the step uses the "docker" and "integration-tests" as profile * do not run when pull requests are from dependabot -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17789055#comment-17789055
]
Thomas Andraschko commented on MYFACES-4641:
Would you like to create a PR for 3.x, 4.x, 4.1 and master?
> 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-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789054#comment-17789054 ] Thomas Andraschko commented on MYFACES-4642: Faces 4.0 removed the whole ManagedBean stuff and the Faces @ViewScoped is CDI only. Do you use your own or JoinFaces Spring ViewScoped? Better create a issue there. > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] build(deps): bump spring.version from 5.3.30 to 5.3.31 [myfaces-tobago]
henningn merged PR #4515: URL: https://github.com/apache/myfaces-tobago/pull/4515 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MYFACES-4642) ViewScope doesn't work in non CDI environment
Carsten Dimmek created MYFACES-4642: --- Summary: ViewScope doesn't work in non CDI environment Key: MYFACES-4642 URL: https://issues.apache.org/jira/browse/MYFACES-4642 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.0.1 Reporter: Carsten Dimmek Attachments: demo.zip We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope is not working properly. The controller is re-instantiated with every Ajax request on the page. I have tried to analyze the problem and suspect it is because no viewScopeId is created in org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] fix(sheet): lazy loading + sorting [myfaces-tobago]
henningn opened a new pull request, #4532: URL: https://github.com/apache/myfaces-tobago/pull/4532 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789343#comment-17789343
]
Manuel K commented on MYFACES-4643:
---
I think it could be fixed:
!image-2023-11-24-07-37-06-948.png|width=553,height=255!
Here the connection now seems to be a _VirtualFileURLConnection.
conn.getContent()_ gives us an InputStream, from which we could probably read
the jar file:
!image-2023-11-24-07-38-54-840.png|width=313,height=291!
Let's first see what BalusC comes up with.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: image-2023-11-24-07-37-06-948.png,
> image-2023-11-24-07-38-54-840.png, primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
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=17789354#comment-17789354
]
Manuel K commented on MYFACES-4623:
---
[~volosied] We have been testing the fix for a while now (custom build 4.0.1 +
the relevant commit) and all seems well. Can you please include the fix in
4.0.2? Thank you very much in advance!
> 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
> Fix For: 4.1.0, 5.0.0
>
>
> 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-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789151#comment-17789151 ] Carsten Dimmek commented on MYFACES-4642: - The ViewScope implementation of JoinFaces is based on the ViewMap of JSF. And if a new ViewMap is created with every request, then in my opinion this is not a problem with joinfaces. At least there is code that deals with the non-CDI case and I would have expected that to work properly > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[
https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789174#comment-17789174
]
Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 3:30 PM:
--
Could you just try to add something like this
```if (viewScopeId == null) {
viewScopeId = Integer.toString(new Random().nextInt());
}`
in ViewScopeProxyMap#ln 75
if yes, we could fix it easily in old branches but we would need quite a big
refactoring in this whole area in our master
was (Author: tandraschko):
Could you just try to add something like this
`viewScopeId = Integer.toString(new Random().nextInt());`
in ViewScopeProxyMap#ln 75
if yes, we could fix it easily in old branches but we would need quite a big
refactoring in this whole area in our master
> ViewScope doesn't work in non CDI environment
> -
>
> Key: MYFACES-4642
> URL: https://issues.apache.org/jira/browse/MYFACES-4642
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.1
>Reporter: Carsten Dimmek
>Priority: Major
> Attachments: demo.zip, myfaces-viewmap.zip
>
>
> We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope
> is not working properly. The controller is re-instantiated with every Ajax
> request on the page. I have tried to analyze the problem and suspect it is
> because no viewScopeId is created in
> org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789200#comment-17789200
]
Thomas Andraschko commented on MYFACES-4643:
no, its not per definition incompatible.
OmniFaces could just add a "bean defining annotation" to it (check CDI spec) or
omnifaces / your application must set bean-discovery-mode=all. Anyway, its just
a CDI problem or configuration, we cant help here.
If you set org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING=false,
MyFaces has to manually open all JARs in the WAR and scan for `@FacesConverter`
and that should >actually work<
TBH i wont invest many time here. MF5.0 will rely on CDI scanning only. i would
try to fix your setup here or ask OmniFaces guys to add e.g. @ApplicationScoped.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reopened MYFACES-4642: > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789154#comment-17789154 ] Thomas Andraschko commented on MYFACES-4642: Can you check if a viewmap is created every request? The values, which you put manually into a viewmap, will be lost? > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[
https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789174#comment-17789174
]
Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 3:31 PM:
--
Could you just try to add something like this
{code:java}
if (viewScopeId == null) {
viewScopeId = Integer.toString(new Random().nextInt());
}
{code}
in ViewScopeProxyMap#ln 75
if yes, we could fix it easily in old branches but we would need quite a big
refactoring in this whole area in our master
was (Author: tandraschko):
Could you just try to add something like this
```if (viewScopeId == null) {
viewScopeId = Integer.toString(new Random().nextInt());
}`
in ViewScopeProxyMap#ln 75
if yes, we could fix it easily in old branches but we would need quite a big
refactoring in this whole area in our master
> ViewScope doesn't work in non CDI environment
> -
>
> Key: MYFACES-4642
> URL: https://issues.apache.org/jira/browse/MYFACES-4642
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.1
>Reporter: Carsten Dimmek
>Priority: Major
> Attachments: demo.zip, myfaces-viewmap.zip
>
>
> We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope
> is not working properly. The controller is re-instantiated with every Ajax
> request on the page. I have tried to analyze the problem and suspect it is
> because no viewScopeId is created in
> org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2266) Lazy loading sheet: tc:suggest breaks in header
Henning Nöth created TOBAGO-2266: Summary: Lazy loading sheet: tc:suggest breaks in header Key: TOBAGO-2266 URL: https://issues.apache.org/jira/browse/TOBAGO-2266 Project: MyFaces Tobago Issue Type: Bug Components: Core, JavaScript Affects Versions: 6.0.0, 5.8.0 Reporter: Henning Nöth If using tc:suggest in a sheet header, each lazy load add an empty div to the tc:suggest. The DIV is visible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789174#comment-17789174 ] Thomas Andraschko commented on MYFACES-4642: Could you just try to add something like this `viewScopeId = Integer.toString(new Random().nextInt());` in ViewScopeProxyMap#ln 75 if yes, we could fix it easily in old branches but we would need quite a big refactoring in this whole area in our master > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip, myfaces-viewmap.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789213#comment-17789213
]
Thomas Andraschko edited comment on MYFACES-4643 at 11/23/23 4:49 PM:
--
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
it might also be just broken on jakarta or newer java version.
just need to debug deeply through DefaultAnnotationProvider
was (Author: tandraschko):
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] fix(sheet): lazy loading + sorting [myfaces-tobago]
henningn merged PR #4532: URL: https://github.com/apache/myfaces-tobago/pull/4532 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MYFACES-4643) OmniFaces converters not found using CDI
Manuel K created MYFACES-4643:
-
Summary: OmniFaces converters not found using CDI
Key: MYFACES-4643
URL: https://issues.apache.org/jira/browse/MYFACES-4643
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 4.0.1
Reporter: Manuel K
Attachments: primefaces-test.zip
[As I wrote in the OmniFaces GitHub
repository|[https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540],]
When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
MyFaces 4.0.1), we get the following errors due to the change to the
_bean-discovery-mode_ discussed in the linked GitHub issue:
{code:java}
jakarta.faces.FacesException: Could not find any registered converter-class by
converterId : omnifaces.SelectItemsConverter {code}
It especially happens when using the following context-param:
{code:java}
// code placeholder
{code}
But in our application it even happens without it. Reproducer using
primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_ and
the exception appears.
I would have thought that it would be an OmniFaces issue, but melloware thinks
it's a MyFaces issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789155#comment-17789155 ] Carsten Dimmek commented on MYFACES-4642: - Yes, that is exactly the behavior. You can try it out with the example I have attached > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789154#comment-17789154 ] Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 2:53 PM: -- Can you check if a viewmap is created every request? The values, which you put manually into a viewmap, will be lost? If that would be the case, our own ViewScope would be broken, too? was (Author: tandraschko): Can you check if a viewmap is created every request? The values, which you put manually into a viewmap, will be lost? > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789171#comment-17789171 ] Thomas Andraschko commented on MYFACES-4642: Looks fine IMO [^myfaces-viewmap.zip] values are stored and restored in the viewmap AFAIK you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip, myfaces-viewmap.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] build(deps): bump spring-boot.version from 2.7.17 to 2.7.18 [myfaces-tobago]
dependabot[bot] opened a new pull request, #4534: URL: https://github.com/apache/myfaces-tobago/pull/4534 Bumps `spring-boot.version` from 2.7.17 to 2.7.18. Updates `org.springframework.boot:spring-boot` from 2.7.17 to 2.7.18 Release notes Sourced from https://github.com/spring-projects/spring-boot/releases;>org.springframework.boot:spring-boot's releases. v2.7.18 ⚠️ Noteworthy Changes Following the Paketo team's https://blog.paketo.io/posts/paketo-bionic-builder-is-unsafe/;>announcement that the Bionic CNB builders will be removed, the default builder using by bootBuildImage (Gradle) and spring-boot:build-image (Maven) has been changed to Paketo Jammy https://redirect.github.com/spring-projects/spring-boot/issues/38477;>#38477 :lady_beetle: Bug Fixes App fails to start with a NoSuchMethodError when using Flyway 10.0.0 https://redirect.github.com/spring-projects/spring-boot/issues/38164;>#38164 spring.webflux.multipart.max-disk-usage-per-part behaves incorrectly for values where the number of bytes overflows an int https://redirect.github.com/spring-projects/spring-boot/issues/38146;>#38146 Mail health indicator fails when host is not set in properties https://redirect.github.com/spring-projects/spring-boot/issues/38007;>#38007 :notebook_with_decorative_cover: Documentation Document supported SQL comment prefixes https://redirect.github.com/spring-projects/spring-boot/pull/38385;>#38385 Fix link to Elasticsearch health indicator https://redirect.github.com/spring-projects/spring-boot/pull/38330;>#38330 Improve --help and documentation for encodepassword -a/--algorithm in the Spring Boot CLI https://redirect.github.com/spring-projects/spring-boot/issues/38203;>#38203 Document that TomcatConnectorCustomizers are not applied to additional connectors https://redirect.github.com/spring-projects/spring-boot/issues/38183;>#38183 MyErrorWebExceptionHandler example in documentation isn't working https://redirect.github.com/spring-projects/spring-boot/issues/38104;>#38104 Document that SerializationFeature.WRITE_DURATIONS_AS_TIMESTAMPS is disabled by default https://redirect.github.com/spring-projects/spring-boot/issues/38083;>#38083 Update Running Behind a Front-end Proxy Server to include reactive and ForwardedHeaderTransformer https://redirect.github.com/spring-projects/spring-boot/issues/37282;>#37282 Improve documentation of classpath.idx file and its generation by the Maven and Gradle plugins https://redirect.github.com/spring-projects/spring-boot/issues/37125;>#37125 Document configuration for building images with Colima https://redirect.github.com/spring-projects/spring-boot/issues/34522;>#34522 Code sample in Developing Your First Spring Boot Application does not work https://redirect.github.com/spring-projects/spring-boot/issues/34513;>#34513 Document ConfigurationPropertyCaching https://redirect.github.com/spring-projects/spring-boot/issues/34172;>#34172 Document that application.* banner variables require a packaged jar or the use of Boot's launcher https://redirect.github.com/spring-projects/spring-boot/issues/33489;>#33489 Add section on AspectJ support https://redirect.github.com/spring-projects/spring-boot/issues/32642;>#32642 Document server.servlet.encoding.* properties and server.servlet.encoding.mapping in particular https://redirect.github.com/spring-projects/spring-boot/issues/32472;>#32472 Add a section on customizing embedded reactive servers https://redirect.github.com/spring-projects/spring-boot/issues/31917;>#31917 Clarify that MVC components provided through WebMvcRegistrations are subject to subsequent processing and configuration by MVC https://redirect.github.com/spring-projects/spring-boot/issues/31232;>#31232 Clarifying documentation on including a top-level @TestConfiguration class in a test https://redirect.github.com/spring-projects/spring-boot/issues/30513;>#30513 Clarify that @AutoConfigureWebTestClient binds WebTestClient to mock infrastructure https://redirect.github.com/spring-projects/spring-boot/issues/29890;>#29890 Improve systemd configuration documentation https://redirect.github.com/spring-projects/spring-boot/issues/28453;>#28453 Document how to customize the basePackages that auto-configurations consider (for example Spring Data Repositories) https://redirect.github.com/spring-projects/spring-boot/issues/27549;>#27549 Document additional user configuration that's required after setting spring.hateoas.use-hal-as-default-json-media-type to false https://redirect.github.com/spring-projects/spring-boot/issues/26814;>#26814 Add how-to documentation for test-only database migrations with Flyway/Liquibase https://redirect.github.com/spring-projects/spring-boot/issues/26796;>#26796 :hammer: Dependency Upgrades Upgrade to ActiveMQ 5.16.7
[jira] [Comment Edited] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789171#comment-17789171 ] Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 3:23 PM: -- Looks fine IMO [^myfaces-viewmap.zip] values are stored and restored in the viewmap AFAICS you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. was (Author: tandraschko): Looks fine IMO [^myfaces-viewmap.zip] values are stored and restored in the viewmap AFAIK you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip, myfaces-viewmap.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789171#comment-17789171 ] Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 3:26 PM: -- AFAICS values are stored and restored in the viewmap, even if no CDI is directly involved: [^myfaces-viewmap.zip] you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. was (Author: tandraschko): Looks fine IMO [^myfaces-viewmap.zip] values are stored and restored in the viewmap AFAICS you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip, myfaces-viewmap.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789195#comment-17789195
]
Manuel K commented on MYFACES-4643:
---
Thank you for your comment.
That sounds logical. Are you saying that USE_CDI_FOR_ANNOTATION_SCANNING and
OmniFaces are incompatible and that's okay?
I would be fine disabling this feature, but as I wrote above it doesn't help.
We get the same exception without this setting, but I can't reproduce it in
primefaces-test. Do you have any idea how that could happen or how I should
debug that?
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789213#comment-17789213
]
Thomas Andraschko edited comment on MYFACES-4643 at 11/23/23 4:51 PM:
--
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
it might also be just broken on jakarta or newer java version.
you just need to debug deeply through DefaultAnnotationProvider
was (Author: tandraschko):
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
it might also be just broken on jakarta or newer java version.
just need to debug deeply through DefaultAnnotationProvider
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2262) Lazy loading sheet: wrong scroll position if using attribute "first"
[ https://issues.apache.org/jira/browse/TOBAGO-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2262. -- Resolution: Fixed > Lazy loading sheet: wrong scroll position if using attribute "first" > > > Key: TOBAGO-2262 > URL: https://issues.apache.org/jira/browse/TOBAGO-2262 > Project: MyFaces Tobago > Issue Type: Bug > Components: JavaScript >Affects Versions: 5.8.0, 6.0.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Minor > Fix For: 5.9.0, 6.1.0 > > > If using "first=80" the scroll position is row=0 not row=80. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2264) Lazy loading sheet: duplicated IDs
[ https://issues.apache.org/jira/browse/TOBAGO-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2264. -- Resolution: Fixed > Lazy loading sheet: duplicated IDs > -- > > Key: TOBAGO-2264 > URL: https://issues.apache.org/jira/browse/TOBAGO-2264 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.8.0, 6.0.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Minor > Fix For: 5.9.0, 6.1.0 > > > Lazy loading in a sheet add temporary DIVs at the the end of the page. These > DIVs have an ID and are not removed. This leads to duplicated IDs. But even > without the duplicated IDs, these DIV elements should be removed. > The ID of the DIVs contain "jakarta.faces.ViewState" or > "jakarta.faces.ClientWindow". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2261) Sorting or Searching breaks sheet in case of lazy loading
[ https://issues.apache.org/jira/browse/TOBAGO-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2261. -- Resolution: Fixed > Sorting or Searching breaks sheet in case of lazy loading > - > > Key: TOBAGO-2261 > URL: https://issues.apache.org/jira/browse/TOBAGO-2261 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.8.0, 6.0.0 >Reporter: Marcus Kroeger >Assignee: Henning Nöth >Priority: Major > Fix For: 5.9.0, 6.1.0 > > > When using Sheet Component with lazy loading set to "true" values get loaded > on demand by scrolling the content. > Using sorting reduce to only part of the total. > When searching in this list the values get reduced correctly, removing the > search string will result in only showing reduced part of total values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789158#comment-17789158
]
Thomas Andraschko commented on MYFACES-4643:
IMO not a bug but didnt debug it
if you have USE_CDI_FOR_ANNOTATION_SCANNING, we only see all classes running
through CDI
that means that SelectItemsConverter isnt a CDI bean?
Just debug CdiAnnotationProviderExtension#processAnnotatedType and you will
propably see that CDI doesnt invoke it
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789158#comment-17789158
]
Thomas Andraschko edited comment on MYFACES-4643 at 11/23/23 3:05 PM:
--
IMO not a bug but didnt debug it
if you have USE_CDI_FOR_ANNOTATION_SCANNING, we only see all classes running
through CDI
that means that SelectItemsConverter isnt a CDI bean?
Just debug CdiAnnotationProviderExtension#processAnnotatedType and you will
propably see that CDI doesnt invoke it for SelectItemsConverter
was (Author: tandraschko):
IMO not a bug but didnt debug it
if you have USE_CDI_FOR_ANNOTATION_SCANNING, we only see all classes running
through CDI
that means that SelectItemsConverter isnt a CDI bean?
Just debug CdiAnnotationProviderExtension#processAnnotatedType and you will
propably see that CDI doesnt invoke it
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789208#comment-17789208
]
Manuel K commented on MYFACES-4643:
---
When debugging the MyFaces _DefaultAnnotationProvider_ the method
_getAnnotatedMetaInfClasses_ receives the following URLs, which are definitely
wrong (the directory _bin\content_ does not exist). But these are the URLs
returned by the ModuleClassLoader?
{code:java}
0 = {URL@44555}
"vfs:/C:/ourapp/server/bin/content/ourapp.ear/ourapp-web.war/WEB-INF/lib/rewrite-config-prettyfaces-10.0.0.Final.jar/META-INF/faces-config.xml"
1 = {URL@44556}
"vfs:/C:/ourapp/server/bin/content/ourapp.ear/ourapp-web.war/WEB-INF/lib/primefaces-extensions-13.0.3-jakarta.jar/META-INF/faces-config.xml"
2 = {URL@44557}
"jar:file:/C:/ourapp/server/modules/org/jboss/as/jsf-injection/myfaces/wildfly-jsf-injection-30.0.0.Final.jar!/META-INF/faces-config.xml"
3 = {URL@44558}
"vfs:/C:/ourapp/server/bin/content/ourapp.ear/ourapp-web.war/WEB-INF/lib/primefaces-13.0.3-jakarta.jar/META-INF/faces-config.xml"
4 = {URL@44559}
"vfs:/C:/ourapp/server/bin/content/ourapp.ear/ourapp-web.war/WEB-INF/lib/rain-theme-4.0.0-jakarta.jar/META-INF/faces-config.xml"
5 = {URL@44560}
"vfs:/C:/ourapp/server/bin/content/ourapp.ear/ourapp-web.war/WEB-INF/lib/omnifaces-4.3.jar/META-INF/faces-config.xml"
6 = {URL@44561}
"vfs:/C:/ourapp/server/bin/content/ourapp.ear/ourapp-web.war/WEB-INF/lib/rewrite-integration-faces-10.0.0.Final.jar/META-INF/faces-config.xml"
{code}
Looks like a bug to me...but maybe not? Let's see if BalusC replies in the
GitHub issue.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789213#comment-17789213
]
Thomas Andraschko edited comment on MYFACES-4643 at 11/23/23 4:47 PM:
--
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
was (Author: tandraschko):
If you would like to work on it, please create a new issue with something like
"Classpath scanning broken on wildfly" - but as i said, i wont invest time, i
can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789213#comment-17789213
]
Thomas Andraschko commented on MYFACES-4643:
If you would like to work on it, please create a new issue with something like
"Classpath scanning broken on wildfly" - but as i said, i wont invest time, i
can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] fix(sheet): lazy loading + sorting [myfaces-tobago]
henningn merged PR #4525: URL: https://github.com/apache/myfaces-tobago/pull/4525 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
