Re: Go CDI only in 4.0?

[Bill Lucy]

Hi Thomas,

>From my POV removing this InjectionProvider SPI is very reasonable, given
the move towards CDI.

Do you have any other SPI removals in mind, at this point?

Thanks,
Bill

On Thu, Sep 23, 2021 at 11:18 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> Hi,
>
> we have some internal SPI like InjectionProvider, which could be used to
> inject e.g. Spring Services in JSF internal artifacts ActionListener,
> NavigationHandler, ResourceHandler.
> Should we remove it? JSF goes CDI more and more.
>
> Spring could still be used for ManagedBeans by custom ELResolver like in
> the past.
>
> I would like to remove it, i think its even unused.
>
> Best regards,
> Thomas
>

[jira] [Commented] (MYFACES-4402) Broken link to http://myfaces.apache.org/trinidad/

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417376#comment-17417376
 ] 

Bill Lucy commented on MYFACES-4402:


To be honest I borrowed the redirect from elsewhere on the site - but IMO it it 
gives users extra visibility that they should update their links/bookmarks to 
the new locations

> Broken link to http://myfaces.apache.org/trinidad/
> --
>
> Key: MYFACES-4402
> URL: https://issues.apache.org/jira/browse/MYFACES-4402
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Assignee: Bill Lucy
>Priority: Major
>
> The link http://myfaces.apache.org/trinidad/ no longer works.
> There should be a redirect to 
> http://myfaces.apache.org/#/inactiveProjects?id=apache-myfaces-trinidad



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4402) Broken link to http://myfaces.apache.org/trinidad/

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417359#comment-17417359
 ] 

Bill Lucy commented on MYFACES-4402:


Good call Thomas, adding a trinidad file with a redirect on the new site does 
the trick - 
[https://github.com/apache/myfaces-homepage/commit/f8ecc5f86c1b99635130c69f55c058669263b200]

> Broken link to http://myfaces.apache.org/trinidad/
> --
>
> Key: MYFACES-4402
> URL: https://issues.apache.org/jira/browse/MYFACES-4402
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The link http://myfaces.apache.org/trinidad/ no longer works.
> There should be a redirect to 
> http://myfaces.apache.org/#/inactiveProjects?id=apache-myfaces-trinidad



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MYFACES-4402) Broken link to http://myfaces.apache.org/trinidad/

[Bill Lucy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4402.

  Assignee: Bill Lucy
Resolution: Fixed

> Broken link to http://myfaces.apache.org/trinidad/
> --
>
> Key: MYFACES-4402
> URL: https://issues.apache.org/jira/browse/MYFACES-4402
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Assignee: Bill Lucy
>Priority: Major
>
> The link http://myfaces.apache.org/trinidad/ no longer works.
> There should be a redirect to 
> http://myfaces.apache.org/#/inactiveProjects?id=apache-myfaces-trinidad



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4402) Broken link to http://myfaces.apache.org/trinidad/

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417335#comment-17417335
 ] 

Bill Lucy commented on MYFACES-4402:


We had to set up a redirect for the old wiki in 
https://issues.apache.org/jira/browse/MYFACES-4383 - I can explore adding these 
redirects, and I'll add some instructions here for future updates [~melloware]

> Broken link to http://myfaces.apache.org/trinidad/
> --
>
> Key: MYFACES-4402
> URL: https://issues.apache.org/jira/browse/MYFACES-4402
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The link http://myfaces.apache.org/trinidad/ no longer works.
> There should be a redirect to 
> http://myfaces.apache.org/#/inactiveProjects?id=apache-myfaces-trinidad



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [Vote] release of MyFaces Core 3.0.1

[Bill Lucy]

+1 from me, the artifacts look fine.

Thans,
Bill

On Wed, Jun 2, 2021 at 2:25 PM Paul Nicolucci  wrote:

> Hi,
>
> I was running the needed tasks to get the 3.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" 3.0.1  [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) does not show binary 
> incompatibilities with myfaces-api.
> I compared the 3.0.0 MyFaces API JAR and the 3.0.1 MyFaces API JAR.
> See the attached "resultsMyFaces.html" for the output of the japicmp tool.
>
>
> Please take a look at the "3.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,
> Paul Nicolucci
>
> [1]
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1193/*
> 
> [2] *https://www.apache.org/foundation/voting.html#ReleaseVotes*
> 
> [3]
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1193/org/apache/myfaces/core/myfaces-core-assembly/*
> 
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12349588
>

Re: [VOTE] release of MyFaces Core 2.3-next-M6

[Bill Lucy]

+1, everything looks fine to me

Thanks,
Bill

On Tue, May 25, 2021 at 7:57 PM Paul Nicolucci  wrote:

> Hi,
>
> I was running the needed tasks to get the 2.3-next-M6 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-M6  [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) does not show binary 
> incompatibilities with myfaces-api.
> See the attached "results.html" for the output of the japicmp tool.
>
>
> Please take a look at the "2.3-next-M6" 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,
> Paul Nicolucci
>
> [1]
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1188/*
> 
> [2] *https://www.apache.org/foundation/voting.html#ReleaseVotes*
> 
> [3]
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1188/org/apache/myfaces/core/myfaces-core-assembly/*
> 
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12349695
>

[jira] [Commented] (MYFACES-4399) No obvious link to MYFACES issue tracker on website

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346389#comment-17346389
 ] 

Bill Lucy commented on MYFACES-4399:


Thanks for pointing that out [~sebb] - I've made a few updates to the page.

> No obvious link to MYFACES issue tracker on website
> ---
>
> Key: MYFACES-4399
> URL: https://issues.apache.org/jira/browse/MYFACES-4399
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> I could not find an obvious link to the MyFaces issue tracker on the website.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4399) No obvious link to MYFACES issue tracker on website

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343969#comment-17343969
 ] 

Bill Lucy commented on MYFACES-4399:


I've added links to to the top level menu for the myfaces core and tobago Jira 
pages.

> No obvious link to MYFACES issue tracker on website
> ---
>
> Key: MYFACES-4399
> URL: https://issues.apache.org/jira/browse/MYFACES-4399
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> I could not find an obvious link to the MyFaces issue tracker on the website.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4399) No obvious link to MYFACES issue tracker on website

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343819#comment-17343819
 ] 

Bill Lucy commented on MYFACES-4399:


For core there is a link under 
[https://myfaces.apache.org/#/coregettingstarted] - "Issue Management: 
[JIRA|https://issues.apache.org/jira/projects/MYFACES/]; - but I agree we could 
make that more obvious. It might make sense to add another link at 
[https://myfaces.apache.org/#/community] or perhaps as a standalone link in the 
nav?

> No obvious link to MYFACES issue tracker on website
> ---
>
> Key: MYFACES-4399
> URL: https://issues.apache.org/jira/browse/MYFACES-4399
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> I could not find an obvious link to the MyFaces issue tracker on the website.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release of MyFaces Core 2.0.0

[Bill Lucy]

+1 from me. Thanks for running this older release.

Regards,
Bill

On Thu, Apr 29, 2021 at 11:11 AM Volodymyr Siedlecki 
wrote:

> Hi,
>
> I was running the needed tasks to get the 2.0.25 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.0.0  [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 (similar to clirr) did show binary incompatibilities when
> compared to javax.faces-api v2.0.0 [5] but did not show incompatibilities
> when compared to the previous MyFaces 2.0.24 release. Results for both are
> attached.
>
> Please take a look at the “2.0.25” 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 Siedlecki
>
> [1]
> https://repository.apache.org/content/repositories/orgapachemyfaces-1186/org/apache/myfaces/core/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3]
> https://repository.apache.org/content/repositories/orgapachemyfaces-1186/org/apache/myfaces/core/myfaces-core-assembly/
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12335487
> [5] https://repo1.maven.org/maven2/javax/faces/javax.faces-api/2.0/
>

Re: [VOTE] release of MyFaces Core 2.3.9

[Bill Lucy]

+1

Thanks for getting this out,
Bill

On Thu, Apr 15, 2021 at 1:55 PM Paul Nicolucci  wrote:
>
> Hi,
>
> I was running the needed tasks to get the 2.3.9 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.9  [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 there are no API changes from 
> 2.3.8 to 2.3.9. I've attached the results to this email as well 
> (results.html).
>
> Please take a look at the "2.3.9" 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,
> Paul Nicolucci
>
> [1] 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1184/org/apache/myfaces/core/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3] 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1184/org/apache/myfaces/core/myfaces-core-assembly/
> [4] https://issues.apache.org/jira/projects/MYFACES/versions/12349634

Re: Potential Releases for 2.0.25 & 2.1.19

[Bill Lucy]

+1, like you've said we haven't released those versions in years but
our users of those versions might appreciate this.

Regards,
Bill

On Tue, Apr 13, 2021 at 7:14 AM Udo Schnurpfeil  wrote:
>
> +1
>
> sounds very reasonable
>
> Regards,
>
> Udo
>
> Am 12.04.21 um 21:30 schrieb Volodymyr Siedlecki:
>
> Hello,
>
> I understand we haven't done releases for 2.0 & 2.1 in years, but, due to 
> MYFACES-4376,  I was thinking it might be beneficial? I wouldn't mind 
> creating them if no one has objections.
>
> Thank you,
>
> Volodymyr
>
>
>
>

[jira] [Commented] (MYFACES-4383) Stale website http://myfaces.apache.org/wiki

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317557#comment-17317557
 ] 

Bill Lucy commented on MYFACES-4383:


The INFRA ticket has been resolved, and it looks like the old website and wiki 
are finally inaccessible. [~sebb] any objections to closing this issue?

[~mkienenb] I agree with you about preserving the confluence wiki. The source 
content of the old site is still available under 
[http://svn.apache.org/viewvc/myfaces/site/] - there's a lot of content that 
would be great to have on the new site, it's just a matter of having time to 
work on porting.

> Stale website http://myfaces.apache.org/wiki
> 
>
> Key: MYFACES-4383
> URL: https://issues.apache.org/jira/browse/MYFACES-4383
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The site http://myfaces.apache.org/wiki/ appears to be obsolete; most of its 
> links are broken.
> Is it still supposed to be available to the public?
> If so, the links ought to be fixed; if not, it should be removed to avoid 
> confusing anyone who happens upon it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4383) Stale website http://myfaces.apache.org/wiki

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317235#comment-17317235
 ] 

Bill Lucy commented on MYFACES-4383:


INFRA ticket created: https://issues.apache.org/jira/browse/INFRA-21685

> Stale website http://myfaces.apache.org/wiki
> 
>
> Key: MYFACES-4383
> URL: https://issues.apache.org/jira/browse/MYFACES-4383
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The site http://myfaces.apache.org/wiki/ appears to be obsolete; most of its 
> links are broken.
> Is it still supposed to be available to the public?
> If so, the links ought to be fixed; if not, it should be removed to avoid 
> confusing anyone who happens upon it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4383) Stale website http://myfaces.apache.org/wiki

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316808#comment-17316808
 ] 

Bill Lucy commented on MYFACES-4383:


OK, the wiki homepage now redirects to 
[https://cwiki.apache.org/confluence/display/MYFACES2/Home] - but we still have 
the problem that all of the old links under the wiki site are still accessible, 
eg. [http://myfaces.apache.org/wiki/sitemap.html.] There are a number of such 
pages, so IMO rather than duplicating them all it makes more sense to pursue 
removing the old site.

> Stale website http://myfaces.apache.org/wiki
> 
>
> Key: MYFACES-4383
> URL: https://issues.apache.org/jira/browse/MYFACES-4383
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The site http://myfaces.apache.org/wiki/ appears to be obsolete; most of its 
> links are broken.
> Is it still supposed to be available to the public?
> If so, the links ought to be fixed; if not, it should be removed to avoid 
> confusing anyone who happens upon it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4383) Stale website http://myfaces.apache.org/wiki

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316803#comment-17316803
 ] 

Bill Lucy commented on MYFACES-4383:


Thanks Sebb, that was a good idea. I merged your PR and now the html you added 
is served from [http://myfaces.apache.org/wiki/]. I'll do an update soon to set 
up a redirect, and I'll open an INFRA ticket tomorrow to get the old site taken 
down.

> Stale website http://myfaces.apache.org/wiki
> 
>
> Key: MYFACES-4383
> URL: https://issues.apache.org/jira/browse/MYFACES-4383
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The site http://myfaces.apache.org/wiki/ appears to be obsolete; most of its 
> links are broken.
> Is it still supposed to be available to the public?
> If so, the links ought to be fixed; if not, it should be removed to avoid 
> confusing anyone who happens upon it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4383) Stale website http://myfaces.apache.org/wiki

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316400#comment-17316400
 ] 

Bill Lucy commented on MYFACES-4383:


I've tried what's been discussed here - I added a .htaccess file with a 
redirect and deleted (renamed) the production/myfaces/content/wiki dir - but 
the wiki site is still active. I also poked around the CMS management at 
[https://cms.apache.org/myfaces/] but there are no longer any site builders 
registered. Does anyone have any other ideas or pointers?

> Stale website http://myfaces.apache.org/wiki
> 
>
> Key: MYFACES-4383
> URL: https://issues.apache.org/jira/browse/MYFACES-4383
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The site http://myfaces.apache.org/wiki/ appears to be obsolete; most of its 
> links are broken.
> Is it still supposed to be available to the public?
> If so, the links ought to be fixed; if not, it should be removed to avoid 
> confusing anyone who happens upon it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4391) Disabled/ReadOnly HTML attributes should not use boolean

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312450#comment-17312450
 ] 

Bill Lucy commented on MYFACES-4391:


Okay, thanks for the background. You're right, seems safe - thanks for the PRs!

> Disabled/ReadOnly HTML attributes should not use boolean
> 
>
> Key: MYFACES-4391
> URL: https://issues.apache.org/jira/browse/MYFACES-4391
> Project: MyFaces Core
>  Issue Type: Improvement
>Reporter: Melloware
>Priority: Major
> Fix For: 4.0.0-RC1
>
>
> For `readonly` and `disabled` attributes MyFaces is sending "true" when the 
> right value is `readonly="readoly"`
> Current:
> {code:java}
> if (inputFile.isDisabled())
> {
>  writer.writeAttribute(HTML.DISABLED_ATTR, Boolean.TRUE, null);
> } {code}
>  
> Should be:
> {code:java}
>  if (inputFile.isDisabled()) 
> { 
>writer.writeAttribute(HTML.DISABLED_ATTR, HTML.DISABLED_ATTR, null); 
> } {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4391) Disabled/ReadOnly HTML attributes should not use boolean

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312427#comment-17312427
 ] 

Bill Lucy commented on MYFACES-4391:


Is there a chance this attribute change could change behavior on older 
browsers? For example https://stackoverflow.com/a/37706358/3864977

> Disabled/ReadOnly HTML attributes should not use boolean
> 
>
> Key: MYFACES-4391
> URL: https://issues.apache.org/jira/browse/MYFACES-4391
> Project: MyFaces Core
>  Issue Type: Improvement
>Reporter: Melloware
>Priority: Major
> Fix For: 4.0.0-RC1
>
>
> For `readonly` and `disabled` attributes MyFaces is sending "true" when the 
> right value is `readonly="readoly"`
> Current:
> {code:java}
> if (inputFile.isDisabled())
> {
>  writer.writeAttribute(HTML.DISABLED_ATTR, Boolean.TRUE, null);
> } {code}
>  
> Should be:
> {code:java}
>  if (inputFile.isDisabled()) 
> { 
>writer.writeAttribute(HTML.DISABLED_ATTR, HTML.DISABLED_ATTR, null); 
> } {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Dependabot config for MyFaces Core?

[Bill Lucy]

I agree that dependabot is nice for general guidance, even if that guidance
is for dependencies we aren't providing at runtime.

On Thu, Feb 11, 2021 at 11:36 AM Volodymyr Siedlecki <
volodymyr.siedle...@ibm.com> wrote:

> Lot of emails from dependabot, however.
>
>
> - Original message -
> From: "Volodymyr Siedlecki" 
> To: dev@myfaces.apache.org
> Cc:
> Subject: [EXTERNAL] RE: Dependabot config for MyFaces Core?
> Date: Wed, Feb 10, 2021 4:27 PM
>
> +1
>
> I peeked around the Tobago GitHub page, and the dependabot feature looked
> pretty nice.
> I think some automation would be good to have -- would be easier for us to
> know which dependencies could/should be updated.
>
> Volodymyr
>
>
>
>
> - Original message -
> From: Bernd Bohmann 
> To: MyFaces Development 
> Cc:
> Subject: [EXTERNAL] Re: Dependabot config for MyFaces Core?
> Date: Wed, Feb 10, 2021 11:09 AM
>
> Maven plugins and Master pom updates as well?
>
> Of course we have dependencies. I don't want to go into this dependencies
> or not dependencies discussion.
> What I see is that many of the versions are outdated. I would take any
> automated help!
>
> Regards
>
> Bernd
>
>
>
> On Wed, Feb 10, 2021 at 4:46 PM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
> +0
>
> we dont have dependencies, only for testing and building
> and IMO the bot is only nice to get updates for real dependencies, which
> could contain fixes and security fixes
>
> Am Mi., 10. Feb. 2021 um 16:42 Uhr schrieb Bernd Bohmann <
> bom...@apache.org>:
>
> Hello Team,
>
> any interest in adding dependabot configuration to MyFaces Core?
>
> I have added it to the Tobago and MyFaces Master Pom Projects.
>
>
> https://docs.github.com/en/github/administering-a-repository/keeping-your-dependencies-updated-automatically
> 
>
> Regards
>
> Bernd
>
>
>
>
>
>

Re: [VOTE] release of MyFaces Core 2.3-next-M5

[Bill Lucy]

Thanks for running this Paul, looks good to me

+1

On Wed, Feb 10, 2021 at 3:45 PM Paul Nicolucci  wrote:

> Hi,
>
> I was running the needed tasks to get the 2.3-next-M5 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-M5  [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 there are a few new API
> clases from 2.3-next-M4 to 2.3-next-M5. I've attached the results to this
> email as well (results.html).
>
> If any concerns with the above let me know.
>
> Please take a look at the "2.3-next-M5" 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,
> Paul Nicolucci
>
> [1]
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1182/*
> 
> [2] *http://www.apache.org/foundation/voting.html#ReleaseVotes*
> 
> [3]
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1182/org/apache/myfaces/core/myfaces-core-assembly/*
> 
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12348727
>

Re: [VOTE] Release of MyFaces Core 2.2.14

[Bill Lucy]

+1, thanks Paul

Regards,
Bill

On Thu, Feb 4, 2021 at 8:30 AM Bernd Bohmann 
wrote:

> Here is my +1
>
> Regards
>
> Bernd
>
> On Thu, Feb 4, 2021 at 2:18 PM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> +1
>> could someone also take care of 2.3-next-M5?
>>
>>
>> 
>>  Virenfrei.
>> www.avast.com
>> 
>> <#m_379450714435186650_m_-7639062556836404796_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> Am Do., 4. Feb. 2021 um 13:47 Uhr schrieb Paul Nicolucci <
>> pnicolu...@gmail.com>:
>>
>>> Hi,
>>>
>>> I was running the needed tasks to get the 2.2.14 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.2.14  [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) does not show binary 
>>> incompatibilities with myfaces-api.
>>> See the attached "results.html" for the output of the japicmp tool.
>>>
>>> I would also like to note that there was no TCK execution as I could not 
>>> find any instructions.
>>>
>>> Please take a look at the "2.2.14" 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,
>>> Paul Nicolucci
>>>
>>> [1] 
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1181/org/apache/myfaces/core/
>>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>> [3] 
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1181/org/apache/myfaces/core/myfaces-core-assembly/
>>> [4] 
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12348436
>>>
>>>

Re: [VOTE] release of MyFaces Core 2.3.8

[Bill Lucy]

+1

Thanks,
Bill

On Fri, Jan 29, 2021 at 10:33 AM Paul Nicolucci 
wrote:

> My +1 also.
>
> Thanks,
>
> Paul Nicolucci
>
> On Fri, Jan 29, 2021 at 9:42 AM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> +1
>>
>> Am Fr., 29. Jan. 2021 um 15:29 Uhr schrieb Bernd Bohmann <
>> bom...@apache.org>:
>>
>>> Here is my +1
>>>
>>> Regards
>>>
>>> Bernd
>>>
>>> Paul Nicolucci  schrieb am Do., 28. Jan. 2021,
>>> 18:53:
>>>
 Hi,

 I was running the needed tasks to get the 2.3.8 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.8  [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 there are no API changes
 from 2.3.7 to 2.3.8. I've attached the results to this email as well
 (results.html).

 If any concerns with the above let me know.

 Please take a look at the "2.3.8" 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,
 Paul Nicolucci

 [1]
 *https://repository.apache.org/content/repositories/orgapachemyfaces-1178/*
 
 [2] *http://www.apache.org/foundation/voting.html#ReleaseVotes*
 
 [3]
 *https://repository.apache.org/content/repositories/orgapachemyfaces-1178/org/apache/myfaces/core/myfaces-core-assembly/*
 
 [4]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12349324

>>>

Re: [VOTE] Release of MyFaces Core 3.0.0

[Bill Lucy]

+1 from me

Thanks!

On Thu, Jan 28, 2021 at 7:40 AM Bernd Bohmann  wrote:

> Here is my +1
>
> Regards
>
> Bernd
>
> On Wed, Jan 27, 2021 at 5:59 PM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> +1
>>
>> Am Mi., 27. Jan. 2021 um 16:48 Uhr schrieb Volodymyr Siedlecki <
>> volodymyr.siedle...@ibm.com>:
>>
>>> Hi,
>>>
>>>
>>> I am again running the needed tasks to release version 3.0.0 of Apache
>>> MyFaces core out.
>>>
>>> Please note that this vote concerns all of the following parts:
>>>1. Maven artifact group "org.apache.myfaces.core" v3.0.0  [1]
>>>
>>> The artifacts were deployed on nexus repository [1] for binary and
>>> source packages.
>>> The release notes could be found at [4].
>>>
>>> The japicmp tool does show some differences. See attached results.
>>>  - I compared the 3.0.0 release to the previous 3.0.0-RC1 and it only
>>> showed the corrected @Deprecated annotations.
>>>  - I compared the 3.0.0 release to jakarta-faces.api-3.0.0.jar [5] and
>>> it shows some unrelated serialize ID differences.
>>>Additionally, it showed differences between classes, but this is due
>>> to how the jakarta.faces.component.html.* classes are generated in MyFaces.
>>> (These differences occurred in the 3.0.0-RC1 release, too) Nothing
>>> concerning, in my opinion.
>>>
>>> Please take a look at the "3.0.0" 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 Siedlecki
>>>
>>>
>>> [1]
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1177/org/apache/myfaces/core/
>>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>> [3]
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1177/org/apache/myfaces/core/myfaces-core-assembly/3.0.0/
>>> [4]
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12348851
>>> [5]
>>> https://repo1.maven.org/maven2/jakarta/faces/jakarta.faces-api/3.0.0/
>>>
>>>
>>>
>>>

Re: 2.3.8 / 2.2.14 Release

[Bill Lucy]

+1, please do

On Wed, Jan 27, 2021 at 10:50 AM Volodymyr Siedlecki <
volodymyr.siedle...@ibm.com> wrote:

> +1
>
>
> - Original message -
> From: Thomas Andraschko 
> To: MyFaces Development 
> Cc:
> Subject: [EXTERNAL] Re: 2.3.8 / 2.2.14 Release
> Date: Wed, Jan 27, 2021 10:07 AM
>
> +1
>
> Paul Nicolucci  schrieb am Mi., 27. Jan. 2021,
> 14:53:
>
> Hi,
>
> Any objections to me starting a 2.3.8 release? I'll follow up with a
> 2.2.14 release soon after.
>
> Thanks,
>
> Paul Nicolucci
>
>
>
>

Re: 3.0.0 Release Go Ahead

[Bill Lucy]

+1 from me, thanks!

On Sat, Jan 23, 2021 at 9:15 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1 from my side
>
> Volodymyr Siedlecki  schrieb am Sa., 23.
> Jan. 2021, 14:44:
>
>> Hello,
>>
>>
>> I see that there are no active PRs and all others have been merged in.
>>
>> Will there be more updates done to the 3.0.x branch or am I clear to redo
>> the release?
>>
>> Thank you,
>>
>> Volodymyr
>>
>>

[jira] [Resolved] (MYFACES-4373) Use SecureRandom for Token Generation

[Bill Lucy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4373.

Fix Version/s: 2.3.8
   3.0.0-RC2
   2.2.14
   2.1.19
   2.0.25
   Resolution: Fixed

> Use SecureRandom for Token Generation
> -
>
> Key: MYFACES-4373
> URL: https://issues.apache.org/jira/browse/MYFACES-4373
> Project: MyFaces Core
>  Issue Type: Bug
>    Reporter: Bill Lucy
>Assignee: Bill Lucy
>Priority: Major
> Fix For: 2.0.25, 2.1.19, 2.2.14, 3.0.0-RC2, 2.3.8
>
>
> We should default to using _java.security.SecureRandom_ instead of 
> _java.util.Random_ for ViewState and CSRF token generation.  The default 
> values for the following two props will be updated:
> org.apache.myfaces.RANDOM_KEY_IN_CSRF_SESSION_TOKEN to "secureRandom"
> org.apache.myfaces.RANDOM_KEY_IN_VIEW_STATE_SESSION_TOKEN to "secureRandom"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4373) Use SecureRandom for Token Generation

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264391#comment-17264391
 ] 

Bill Lucy commented on MYFACES-4373:


Thanks for the quick reviews [~tandraschko] and [~bommel] - I'll close this out 
and make that update now.

> Use SecureRandom for Token Generation
> -
>
> Key: MYFACES-4373
> URL: https://issues.apache.org/jira/browse/MYFACES-4373
> Project: MyFaces Core
>  Issue Type: Bug
>    Reporter: Bill Lucy
>Assignee: Bill Lucy
>Priority: Major
>
> We should default to using _java.security.SecureRandom_ instead of 
> _java.util.Random_ for ViewState and CSRF token generation.  The default 
> values for the following two props will be updated:
> org.apache.myfaces.RANDOM_KEY_IN_CSRF_SESSION_TOKEN to "secureRandom"
> org.apache.myfaces.RANDOM_KEY_IN_VIEW_STATE_SESSION_TOKEN to "secureRandom"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MYFACES-4373) Use SecureRandom for Token Generation

[Bill Lucy (Jira)]

Bill Lucy created MYFACES-4373:
--

 Summary: Use SecureRandom for Token Generation
 Key: MYFACES-4373
 URL: https://issues.apache.org/jira/browse/MYFACES-4373
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Bill Lucy
Assignee: Bill Lucy


We should default to using _java.security.SecureRandom_ instead of 
_java.util.Random_ for ViewState and CSRF token generation.  The default values 
for the following two props will be updated:

org.apache.myfaces.RANDOM_KEY_IN_CSRF_SESSION_TOKEN to "secureRandom"

org.apache.myfaces.RANDOM_KEY_IN_VIEW_STATE_SESSION_TOKEN to "secureRandom"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4318) [docs] c:forEach problem with client side state saving

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258229#comment-17258229
 ] 

Bill Lucy commented on MYFACES-4318:


[~tandraschko] sure, I'll try to come up with some basic documentation for JSTL 
that covers this problem

> [docs] c:forEach problem with client side state saving
> --
>
> Key: MYFACES-4318
> URL: https://issues.apache.org/jira/browse/MYFACES-4318
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Bill Lucy
>Priority: Major
> Attachments: jsf_foreach_client_state.war, 
> jsf_foreach_client_state_mvn.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There appears to be a problem with c:forEach when client side state saving is 
> enabled -  component states are not restored correctly after a submit.  For 
> example, the text entered into this inputText is lost:
> {{{color:#80} {color:#ff}var{color}{color:#00}={color}{color:#ff}"current"{color}
>  
> {color:#ff}items{color}{color:#00}={color}{color:#ff}"#\{list.items}"{color}{color:#80}>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"#\{current.value}"{color}{color:#80}/>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"submit"{color}{color:#80}/>{color}}}
> {{{color:#80}{color}}}
>  
> This example works (the inputText is not lost) with server side state saving 
> enabled, and it also works on Mojarra with client side state saving. I 
> haven't figured out what exactly is causing this behavior yet - if anyone 
> else has insight in this area I'd appreciate hints.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [Vote] Release of MyFaces Core 2.3.7

[Bill Lucy]

+1

Thanks Paul

On Mon, Nov 2, 2020 at 9:25 AM Paul Nicolucci  wrote:

> My +1 as well.
>
> Regards,
>
> Paul Nicolucci
>
> On Mon, Nov 2, 2020 at 8:29 AM Werner Punz  wrote:
>
>> +1
>>
>> Werner
>>
>>
>> Am Mo., 2. Nov. 2020 um 06:27 Uhr schrieb Udo Schnurpfeil <
>> lof...@apache.org>:
>>
>>> +1
>>>
>>> regards
>>>
>>> Udo
>>> Am 30.10.20 um 21:00 schrieb Bernd Bohmann:
>>>
>>> Hi
>>>
>>> here is my +1
>>>
>>> Regards
>>>
>>> Bernd
>>>
>>> On Thu, Oct 29, 2020 at 9:10 AM Thomas Andraschko <
>>> andraschko.tho...@gmail.com> wrote:
>>>
 +1

 Am Mi., 28. Okt. 2020 um 21:32 Uhr schrieb Paul Nicolucci <
 pnicolu...@gmail.com>:

> Hi,
>
> I was running the needed tasks to get the 2.3.7 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.7  [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 there are no API
> changes from 2.3.6 to 2.3.7. I've attached the results to this email as
> well (results.html).
>
> If there are any concerns about the above let me know.
>
> Please take a look at the "2.3.7" 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,
> Paul Nicolucci
>
> [1]
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1172/*
> 
> [2] *http://www.apache.org/foundation/voting.html#ReleaseVotes*
> 
> [3]
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1172/org/apache/myfaces/core/myfaces-core-assembly/*
> 
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12346524
>

Re: [VOTE] release of MyFaces Core 2.3-next-M4

[Bill Lucy]

+1 from me, thanks Thomas

Regards,
Bill

On Mon, Aug 31, 2020 at 2:46 AM Czarnecki, Piotr <
piotr.czarne...@sbb.spk-berlin.de> wrote:

> +1
>
>
>
> Thanks!
>
>
>
>
>
>
>
> *Von:* Thomas Andraschko 
> *Gesendet:* Samstag, 29. August 2020 11:23
> *An:* MyFaces Development 
> *Betreff:* Re: [VOTE] release of MyFaces Core 2.3-next-M4
>
>
>
> My own +1
>
>
>
> Thomas Andraschko  schrieb am Mi., 26. Aug.
> 2020, 18:53:
>
> Hi,
>
>
>
> I was running the needed tasks to get the 2.3-next-M4 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-M4 [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) does not show binary 
> incompatibilities with myfaces-api.
>
>
>
> Please take a look at the "2.3-next-M4" 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,
>
> Thomas Andraschko
>
>
>
> [1] 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1170/org/apache/myfaces/core/
>
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>
> [3] 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1170/org/apache/myfaces/core/myfaces-core-assembly/
>
> [4] 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12348458
>
>

Re: [VOTE] release of MyFaces Core 3.0.0-RC1

[Bill Lucy]

I've done some basic tests with help from Volodymyr; +1 from me

Thanks,
Bill

On Sat, Aug 15, 2020 at 8:08 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1
>
> Am Do., 13. Aug. 2020 um 18:45 Uhr schrieb Volodymyr Siedlecki <
> volos...@gmail.com>:
>
>> Hello,
>>
>> I am working on the 3.0.0-RC1 release of Apache MyFaces Core.
>>
>> Please note that this vote concerns all of the following parts:
>>1. Maven artifact group "org.apache.myfaces.core" v3.0.0-RC1  [1]
>>
>> The artifacts were deployed on nexus repo [1] for binary and source packages.
>> The release notes could be found at [2].
>> We do not have any issues tracking the jakarta to javax rename, let me know 
>> if any should be created.
>>
>> I used the japicmp tool to compare the 3.0.0-RC1 API to the Jakarta Faces 
>> API (see [3]). The jakarta-results are attached.
>> While the majority of the API was the same, the tool found a few differences:
>> 1) serialVersionUID
>> 2) "COMPONENT_FAMILY"* FIELD_STATIC_AND_OVERRIDES_STATIC* change.
>> 3) Some methods were considered new since they aren't in the Jakarta Faces 
>> API.
>> However, the similar differences exist when I compared the 2.3.6 MyFaces API 
>> with the 2.3 Javax Faces API (see [4]). The javax results are also attached 
>> for reference.
>>
>> No TCK testing was performed as I had not found any available TCK to use.
>>
>> Please take a look at the "3.0.0" artifacts and vote! (see [5])
>>
>> Please note: This vote is "majority approval" with a minimum of three +1 
>> votes (see [6]).
>>
>> 
>> [ ] +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 Siedlecki
>>
>> [1] 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1164/org/apache/myfaces/core/
>> [2] 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12347158
>> [3] https://repo1.maven.org/maven2/jakarta/faces/jakarta.faces-api/3.0.0-RC1/
>> [4] https://mvnrepository.com/artifact/javax.faces/javax.faces-api/2.3
>> [5] 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1164/org/apache/myfaces/core/myfaces-core-assembly/
>> [6] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>
>>

[jira] [Resolved] (MYFACES-4353) PreDestroy method (still) not invoked on javax.faces.bean.ViewScoped beans on Session invalidation

[Bill Lucy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4353.

Resolution: Fixed

> PreDestroy method (still) not invoked on javax.faces.bean.ViewScoped beans on 
> Session invalidation
> --
>
> Key: MYFACES-4353
> URL: https://issues.apache.org/jira/browse/MYFACES-4353
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.13, 2.3.6, 3.0.0-RC1
>    Reporter: Bill Lucy
>Assignee: Bill Lucy
>Priority: Major
>
>  
> It seems to me that the issue reported in 
> https://issues.apache.org/jira/browse/MYFACES-4047 wasn't fixed completely.  
> I'm currently looking at a scenario with a basic javax.faces.bean.ViewScoped 
> bean and a short session timeout: @PostConstruct is invoked as expected, 
> however @PreDestroy is not invoked when the backing session is invalidated 
> via a timeout.  @PreDestroy is invoked correctly in the normal non-timeout 
> cases, and it's also invoked on session timeout for CDI 
> javax.faces.view.ViewScoped beans.
> This gets into how ManagedBeanDestroyer.sessionDestroyed() is implemented:
> [https://github.com/apache/myfaces/blob/2.2.x/impl/src/main/java/org/apache/myfaces/webapp/ManagedBeanDestroyerListener.java#L121]
> if we don't have an active FacesContext when we get the sessionDestroyed() 
> event, then we create a new StartupServletExternalContextImpl and pass that 
> to the current ViewScopeProvider.  That's a problem: the non-CDI 
> ViewScopeProvider needs to be able to get at the session from the external 
> context, and StartupServletExternalContextImpl is implemented such that it 
> always returns null for getSession() and getSessionMap().  So in this case 
> the non-CDI DefaultViewScopeProvider will never clean up or call PreDestroy 
> on the ViewScoped beans.
> My idea for a fix is to allow an HtppSession to be set on the 
> StartupServletExternalContextImpl.  I'll attach a PR shortly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: MyFaces Homepage

[Bill Lucy]

I think it could be helpful to add a dependencies section for the commons-*
runtime libs the older releases need?  But yeah, most of the important info
is here.

On Tue, Jul 28, 2020 at 11:57 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> IMO core is now almost done, please check it. We just need to add the SPI
> secion to each version:
> https://myfaces.apache.org/wiki/core/user-guide/configuration-of-special-features/integration-with-application-and-web-servers.html
>
> Am Di., 28. Juli 2020 um 14:33 Uhr schrieb Bill Lucy :
>
>> I agree, the menu looks good - the search bar in particular is helpful.
>> The content layout for each release (I see that you've filled out them all
>> now) makes sense to me.
>>
>> On Mon, Jul 27, 2020 at 11:16 AM Thomas Andraschko <
>> andraschko.tho...@gmail.com> wrote:
>>
>>> *quite good
>>>
>>> Am Mo., 27. Juli 2020 um 17:11 Uhr schrieb Thomas Andraschko <
>>> andraschko.tho...@gmail.com>:
>>>
>>>> Please checkout Core and 2.2 again :)
>>>> I added all context params by modifying the WebContextParamsLogger
>>>>
>>>> I think also the menu structure is quite now.
>>>>
>>>> Am Mo., 27. Juli 2020 um 15:10 Uhr schrieb Paul Nicolucci <
>>>> pnicolu...@gmail.com>:
>>>>
>>>>> +1 for the link to javadoc.io, I think that would actually work very
>>>>> nicely.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Paul Nicolucci
>>>>>
>>>>> On Mon, Jul 27, 2020 at 8:59 AM Thomas Andraschko <
>>>>> andraschko.tho...@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> i think we could still host the javadoc by ourself if we want. We can
>>>>>> just generate the javadoc html (without the other site stuff) + copy it 
>>>>>> in
>>>>>> a subfolder of the homepage.
>>>>>> But in general i would i add a link to: https://javadoc.io/
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Best regards,
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>> Am Mo., 27. Juli 2020 um 14:42 Uhr schrieb Paul Nicolucci <
>>>>>> pnicolu...@gmail.com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Having had to update the site recently a few times I like the idea
>>>>>>> of making this easier to do.
>>>>>>>
>>>>>>> One thing that comes to mind is would we still be able to generate
>>>>>>> and deploy the docs? For example:
>>>>>>> https://myfaces.apache.org/core23/javadoc.html
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Paul Nicolucci
>>>>>>>
>>>>>>> On Mon, Jul 27, 2020 at 8:31 AM Bill Lucy  wrote:
>>>>>>>
>>>>>>>> I'm absolutely in favor of updating the site if we can improve the
>>>>>>>> ease of maintainability.  The current site has a lot of stale 
>>>>>>>> information
>>>>>>>> which would be nice to update or get rid of.  Markdown is great for
>>>>>>>> lowering the barrier to making updates - I like the example you've 
>>>>>>>> come up
>>>>>>>> with.  I think losing the automatic context param configuration doc
>>>>>>>> generation is a small downside - it won't be difficult to add the 
>>>>>>>> markdown
>>>>>>>> for a new param in the rare event that we create a new one.
>>>>>>>>
>>>>>>>> Overall +1 from me for overhauling the site.  I like the format of
>>>>>>>> what you've gotten started with.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Bill
>>>>>>>>
>>>>>>>> On Mon, Jul 27, 2020 at 5:21 AM Thomas Andraschko <
>>>>>>>> andraschko.tho...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> up ;)
>>>>>>>>>
>>>>>>>>> Am Mi., 22. Juli 2020 um 14:48 Uhr schrieb Thomas Andraschko <
>>>>>>>>> andraschko.tho...@gmail.com>:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> as you all know, the MyFaces homepage is very old. I also tried
>>>>>>>>>> to get the site plugin running for Core 2.3-next but i didn't get it
>>>>>>>>>> working.
>>>>>>>>>>
>>>>>>>>>> I really would like to get rid of the whole maven generation site
>>>>>>>>>> and just a something MUCH easier like asciidoctor or markdown.
>>>>>>>>>>
>>>>>>>>>> I setup something here:
>>>>>>>>>> https://github.com/tandraschko/myfaces-homepage
>>>>>>>>>> Preview:
>>>>>>>>>> https://raw.githack.com/tandraschko/myfaces-homepage/master/
>>>>>>>>>>
>>>>>>>>>> It uses markdown and docsify! This makes the maintenance very
>>>>>>>>>> very easy for the future.
>>>>>>>>>>
>>>>>>>>>> What needs to be done:
>>>>>>>>>> - Transfer content
>>>>>>>>>> - Styling
>>>>>>>>>>
>>>>>>>>>> Whats the downside of it?
>>>>>>>>>> We cant use our maven plugins to generate the "context param
>>>>>>>>>> config" page, it needs to be done manually.
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Thomas
>>>>>>>>>>
>>>>>>>>>

Re: MyFaces Homepage

[Bill Lucy]

I agree, the menu looks good - the search bar in particular is helpful.
The content layout for each release (I see that you've filled out them all
now) makes sense to me.

On Mon, Jul 27, 2020 at 11:16 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> *quite good
>
> Am Mo., 27. Juli 2020 um 17:11 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
>> Please checkout Core and 2.2 again :)
>> I added all context params by modifying the WebContextParamsLogger
>>
>> I think also the menu structure is quite now.
>>
>> Am Mo., 27. Juli 2020 um 15:10 Uhr schrieb Paul Nicolucci <
>> pnicolu...@gmail.com>:
>>
>>> +1 for the link to javadoc.io, I think that would actually work very
>>> nicely.
>>>
>>> Regards,
>>>
>>> Paul Nicolucci
>>>
>>> On Mon, Jul 27, 2020 at 8:59 AM Thomas Andraschko <
>>> andraschko.tho...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> i think we could still host the javadoc by ourself if we want. We can
>>>> just generate the javadoc html (without the other site stuff) + copy it in
>>>> a subfolder of the homepage.
>>>> But in general i would i add a link to: https://javadoc.io/
>>>>
>>>> WDYT?
>>>>
>>>> Best regards,
>>>> Thomas
>>>>
>>>>
>>>> Am Mo., 27. Juli 2020 um 14:42 Uhr schrieb Paul Nicolucci <
>>>> pnicolu...@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> Having had to update the site recently a few times I like the idea of
>>>>> making this easier to do.
>>>>>
>>>>> One thing that comes to mind is would we still be able to generate and
>>>>> deploy the docs? For example:
>>>>> https://myfaces.apache.org/core23/javadoc.html
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Paul Nicolucci
>>>>>
>>>>> On Mon, Jul 27, 2020 at 8:31 AM Bill Lucy  wrote:
>>>>>
>>>>>> I'm absolutely in favor of updating the site if we can improve the
>>>>>> ease of maintainability.  The current site has a lot of stale information
>>>>>> which would be nice to update or get rid of.  Markdown is great for
>>>>>> lowering the barrier to making updates - I like the example you've come 
>>>>>> up
>>>>>> with.  I think losing the automatic context param configuration doc
>>>>>> generation is a small downside - it won't be difficult to add the 
>>>>>> markdown
>>>>>> for a new param in the rare event that we create a new one.
>>>>>>
>>>>>> Overall +1 from me for overhauling the site.  I like the format of
>>>>>> what you've gotten started with.
>>>>>>
>>>>>> Regards,
>>>>>> Bill
>>>>>>
>>>>>> On Mon, Jul 27, 2020 at 5:21 AM Thomas Andraschko <
>>>>>> andraschko.tho...@gmail.com> wrote:
>>>>>>
>>>>>>> up ;)
>>>>>>>
>>>>>>> Am Mi., 22. Juli 2020 um 14:48 Uhr schrieb Thomas Andraschko <
>>>>>>> andraschko.tho...@gmail.com>:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> as you all know, the MyFaces homepage is very old. I also tried to
>>>>>>>> get the site plugin running for Core 2.3-next but i didn't get it 
>>>>>>>> working.
>>>>>>>>
>>>>>>>> I really would like to get rid of the whole maven generation site
>>>>>>>> and just a something MUCH easier like asciidoctor or markdown.
>>>>>>>>
>>>>>>>> I setup something here:
>>>>>>>> https://github.com/tandraschko/myfaces-homepage
>>>>>>>> Preview:
>>>>>>>> https://raw.githack.com/tandraschko/myfaces-homepage/master/
>>>>>>>>
>>>>>>>> It uses markdown and docsify! This makes the maintenance very very
>>>>>>>> easy for the future.
>>>>>>>>
>>>>>>>> What needs to be done:
>>>>>>>> - Transfer content
>>>>>>>> - Styling
>>>>>>>>
>>>>>>>> Whats the downside of it?
>>>>>>>> We cant use our maven plugins to generate the "context param
>>>>>>>> config" page, it needs to be done manually.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>

Re: MyFaces Builder Plugin v1.0.11 Release Vote

[Bill Lucy]

+1, everything looks fine to me

Thanks for getting this done Volodymyr!

On Tue, Jul 28, 2020 at 5:08 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> up! Paul / Bill?
>
> Am Mi., 22. Juli 2020 um 09:28 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
>> +1, thanks
>>
>> Am Di., 21. Juli 2020 um 21:55 Uhr schrieb Volodymyr Siedlecki <
>> volodymyr.siedle...@ibm.com>:
>>
>>> Hi Thomas,
>>>
>>> I tried to add my key to the link provided, but I receive the following
>>> error:
>>>
>>>
>>> svn: E195023: Changing file '/Users/siedlecki/open-source/svn/myfaces/KEYS' 
>>> is forbidden by the server
>>> svn: E175013: Access to 
>>> '/repos/dist/!svn/txr/40616-y98/release/myfaces/KEYS' forbidden
>>>
>>>
>>> I don't believe I have enough permissions to commit to
>>> https://dist.apache.org/repos/dist/release/myfaces/
>>> ?
>>>
>>> https://infra.apache.org/release-publishing.html says that "only
>>> PMC/PPMC members have write access to the dist/release directories."
>>>
>>> However, was able to successfully add my key to
>>> https://svn.apache.org/repos/asf/myfaces/keys/KEYS
>>>
>>> Thanks,
>>>
>>> Volodymyr
>>>
>>>
>>>
>>> - Original message -
>>> From: Thomas Andraschko 
>>> To: MyFaces Development 
>>> Cc:
>>> Subject: [EXTERNAL] Re: MyFaces Builder Plugin v1.0.11 Release Vote
>>> Date: Tue, Jul 21, 2020 12:35 PM
>>>
>>> Hi,
>>>
>>> could you please add your key in
>>> https://dist.apache.org/repos/dist/release/myfaces/KEYS?
>>> can can do it with SVN
>>>
>>> Am Di., 21. Juli 2020 um 17:13 Uhr schrieb Volodymyr Siedlecki <
>>> volos...@gmail.com>:
>>>
>>> Hello,
>>>
>>> I am running the needed tasks to get the 1.0.11 release of Apache
>>> MyFaces Builder Plugin out.
>>>
>>> Please note that this vote concerns all of the following parts:
>>>1. Maven artifact
>>> org.apache.myfaces.buildtools:myfaces-builder-plugin  v1.0.11  [1]The
>>> artifacts were deployed on nexus repo [1] for binary and source packages.
>>>
>>> I did not create release notes as I do not see a Jira Issue Tracker for
>>> the build tools. (Please correct me if there is, and I can create the
>>> release notes)
>>>
>>> Also the japicmp tool (similar to clirr) does not show binary
>>> incompatibilities with the previous version (1.0.10). See the attached
>>> "results.html" for the output of the japicmp tool.
>>>
>>> Please take a look at the "1.0.11" 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 Siedlecki
>>>
>>>
>>> [1]
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1163/org/apache/myfaces/buildtools/
>>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>> [3]
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1163/org/apache/myfaces/buildtools/myfaces-builder-plugin/1.0.11/
>>>
>>>
>>>
>>>

Re: MyFaces Homepage

[Bill Lucy]

I'm absolutely in favor of updating the site if we can improve the ease of
maintainability.  The current site has a lot of stale information which
would be nice to update or get rid of.  Markdown is great for lowering the
barrier to making updates - I like the example you've come up with.  I
think losing the automatic context param configuration doc generation is a
small downside - it won't be difficult to add the markdown for a new param
in the rare event that we create a new one.

Overall +1 from me for overhauling the site.  I like the format of what
you've gotten started with.

Regards,
Bill

On Mon, Jul 27, 2020 at 5:21 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> up ;)
>
> Am Mi., 22. Juli 2020 um 14:48 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
>> Hi,
>>
>> as you all know, the MyFaces homepage is very old. I also tried to get
>> the site plugin running for Core 2.3-next but i didn't get it working.
>>
>> I really would like to get rid of the whole maven generation site and
>> just a something MUCH easier like asciidoctor or markdown.
>>
>> I setup something here: https://github.com/tandraschko/myfaces-homepage
>> Preview: https://raw.githack.com/tandraschko/myfaces-homepage/master/
>>
>> It uses markdown and docsify! This makes the maintenance very very easy
>> for the future.
>>
>> What needs to be done:
>> - Transfer content
>> - Styling
>>
>> Whats the downside of it?
>> We cant use our maven plugins to generate the "context param config"
>> page, it needs to be done manually.
>>
>> WDYT?
>>
>> Best regards,
>> Thomas
>>
>

[jira] [Created] (MYFACES-4353) PreDestroy method (still) not invoked on javax.faces.bean.ViewScoped beans on Session invalidation

[Bill Lucy (Jira)]

Bill Lucy created MYFACES-4353:
--

 Summary: PreDestroy method (still) not invoked on 
javax.faces.bean.ViewScoped beans on Session invalidation
 Key: MYFACES-4353
 URL: https://issues.apache.org/jira/browse/MYFACES-4353
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.6, 2.2.13
Reporter: Bill Lucy
Assignee: Bill Lucy


 

It seems to me that the issue reported in 
https://issues.apache.org/jira/browse/MYFACES-4047 wasn't fixed completely.  
I'm currently looking at a scenario with a basic javax.faces.bean.ViewScoped 
bean and a short session timeout: @PostConstruct is invoked as expected, 
however @PreDestroy is not invoked when the backing session is invalidated via 
a timeout.  @PreDestroy is invoked correctly in the normal non-timeout cases, 
and it's also invoked on session timeout for CDI javax.faces.view.ViewScoped 
beans.

This gets into how ManagedBeanDestroyer.sessionDestroyed() is implemented:

[https://github.com/apache/myfaces/blob/2.2.x/impl/src/main/java/org/apache/myfaces/webapp/ManagedBeanDestroyerListener.java#L121]

if we don't have an active FacesContext when we get the sessionDestroyed() 
event, then we create a new StartupServletExternalContextImpl and pass that to 
the current ViewScopeProvider.  That's a problem: the non-CDI ViewScopeProvider 
needs to be able to get at the session from the external context, and 
StartupServletExternalContextImpl is implemented such that it always returns 
null for getSession() and getSessionMap().  So in this case the non-CDI 
DefaultViewScopeProvider will never clean up or call PreDestroy on the 
ViewScoped beans.

My idea for a fix is to allow an HtppSession to be set on the 
StartupServletExternalContextImpl.  I'll attach a PR shortly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4352) Facing issues 'An error occured while initializing MyFaces' in WAS 8.5.5.16 with Myfaces 2.3

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158244#comment-17158244
 ] 

Bill Lucy commented on MYFACES-4352:


[~tandraschko] yeah, I'll close this.  [~amehta47] if you're still having 
problems with this it would be better to continue the discussion on 
stackoverflow, or you can engage IBM.

> Facing issues 'An error occured while initializing MyFaces' in WAS 8.5.5.16 
> with Myfaces 2.3
> 
>
> Key: MYFACES-4352
> URL: https://issues.apache.org/jira/browse/MYFACES-4352
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.6
> Environment: Websphere 8.5.5.16
>Reporter: Aditya Mehta
>Priority: Blocker
>
> I am trying to deploy Myfaces 2.3 base application in WAS 8.5.5.16 with Java 
> 8 but facing below mention error.
> 005c AbstractFaces E An error occured while initializing MyFaces: Class 
> com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no 
> org.apache.myfaces.spi.AnnotationProvider java.lang.IllegalArgumentException: 
> Class com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no 
> org.apache.myfaces.spi.AnnotationProvider at 
> org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:567)
>  at 
> org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:534)
>  at 
> org.apache.myfaces.spi.impl.DefaultAnnotationProviderFactory.resolveAnnotationProviderFromService(DefaultAnnotationProviderFactory.java:138)
>  at 
> org.apache.myfaces.spi.impl.DefaultAnnotationProviderFactory.createAnnotationProvider(DefaultAnnotationProviderFactory.java:93)
>  at 
> org.apache.myfaces.spi.impl.DefaultAnnotationProviderFactory.getAnnotationProvider(DefaultAnnotationProviderFactory.java:62)
>  at 
> org.apache.myfaces.config.annotation.AnnotationConfigurator.createFacesConfig(AnnotationConfigurator.java:90)
>  at 
> org.apache.myfaces.config.DefaultFacesConfigurationProvider.getAnnotationsFacesConfig(DefaultFacesConfigurationProvider.java:201)
>  at 
> org.apache.myfaces.config.DefaultFacesConfigurationMerger.getFacesConfigData(DefaultFacesConfigurationMerger.java:92)
>  at 
> org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:603)
>  at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:456)
>  at 
> org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:70)
>  at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:190)
>  at 
> org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:103)
>  at 
> com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1736)
>  at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:415) 
> at 
> com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
>  at 
> com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:171)
>  at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:904) 
> at 
> com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:789)
>  at 
> com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:427)
>  at 
> com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:719)
>  at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1211)
>  at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1462)
>  at 
> com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:641)
>  at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:1040)
>  at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:795)
>  at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl$5.run(ApplicationMgrImpl.java:2279)
>  at 
> com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5482)
>  at 
> com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:5698)
>  at 
> com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255)
>  at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2284)
>  at 
> com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:436)
>  at 
> com.ibm

[jira] [Commented] (MYFACES-4352) Facing issues 'An error occured while initializing MyFaces' in WAS 8.5.5.16 with Myfaces 2.3

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158237#comment-17158237
 ] 

Bill Lucy commented on MYFACES-4352:


Did you already ask about this on StackOverflow?? 
[https://stackoverflow.com/questions/62634466/facing-issues-an-error-occured-while-initializing-myfaces-in-was-8-5-5-16-with/62637864#62637864|https://stackoverflow.com/questions/62634466/facing-issues-an-error-occured-while-initializing-myfaces-in-was-8-5-5-16-with/]

This is related to WebSphere configuration - you need to make sure your app is 
configured correctly there.  There is nothing here that can be addressed by the 
MyFaces community, raise an issue with IBM support if you have further problems 
with this.

> Facing issues 'An error occured while initializing MyFaces' in WAS 8.5.5.16 
> with Myfaces 2.3
> 
>
> Key: MYFACES-4352
> URL: https://issues.apache.org/jira/browse/MYFACES-4352
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.6
> Environment: Websphere 8.5.5.16
>Reporter: Aditya Mehta
>Priority: Blocker
>
> I am trying to deploy Myfaces 2.3 base application in WAS 8.5.5.16 with Java 
> 8 but facing below mention error.
> 005c AbstractFaces E An error occured while initializing MyFaces: Class 
> com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no 
> org.apache.myfaces.spi.AnnotationProvider java.lang.IllegalArgumentException: 
> Class com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no 
> org.apache.myfaces.spi.AnnotationProvider at 
> org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:567)
>  at 
> org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:534)
>  at 
> org.apache.myfaces.spi.impl.DefaultAnnotationProviderFactory.resolveAnnotationProviderFromService(DefaultAnnotationProviderFactory.java:138)
>  at 
> org.apache.myfaces.spi.impl.DefaultAnnotationProviderFactory.createAnnotationProvider(DefaultAnnotationProviderFactory.java:93)
>  at 
> org.apache.myfaces.spi.impl.DefaultAnnotationProviderFactory.getAnnotationProvider(DefaultAnnotationProviderFactory.java:62)
>  at 
> org.apache.myfaces.config.annotation.AnnotationConfigurator.createFacesConfig(AnnotationConfigurator.java:90)
>  at 
> org.apache.myfaces.config.DefaultFacesConfigurationProvider.getAnnotationsFacesConfig(DefaultFacesConfigurationProvider.java:201)
>  at 
> org.apache.myfaces.config.DefaultFacesConfigurationMerger.getFacesConfigData(DefaultFacesConfigurationMerger.java:92)
>  at 
> org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:603)
>  at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:456)
>  at 
> org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:70)
>  at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:190)
>  at 
> org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:103)
>  at 
> com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1736)
>  at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:415) 
> at 
> com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
>  at 
> com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:171)
>  at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:904) 
> at 
> com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:789)
>  at 
> com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:427)
>  at 
> com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:719)
>  at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1211)
>  at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1462)
>  at 
> com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:641)
>  at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:1040)
>  at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:795)
>  at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl$5.run(ApplicationMgrImpl.java:2279)
>  at 
> com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5482)
>  at 
> com.ibm.ws.

[jira] [Commented] (MYFACES-4348) MyFaces2.0 is not loading with WAS9.0.5.4

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151549#comment-17151549
 ] 

Bill Lucy commented on MYFACES-4348:


This is not a MyFaces bug.  That _WebSphere-MyFaces208-annotation-provider.jar_ 
is IBM-provided, and it is used to allow MyFaces to hook in to to WebSphere's 
annotation provider implementation.  However it's not compatible with WebSphere 
9 and was never intended to be used on that release.  WebSphere 9 provides 
MyFaces 2.2 out of the box, so your easiest option would be to remove your 
shared lib and use the WebSphere implementation directly.  If that doesn't work 
for you then you will need to get support from IBM.

> MyFaces2.0 is not loading with WAS9.0.5.4
> -
>
> Key: MYFACES-4348
> URL: https://issues.apache.org/jira/browse/MYFACES-4348
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344
>Affects Versions: 2.0.7, 2.2.12
>Reporter: Kishore Vadivel
>Priority: Critical
>
> Hi
> We are performing WAS7.0.0.45 to WAS9.0.5.4 migration. We have JSF2 
> components running on WAS7.
> After WAS9 Migration, JSF2(MyFaces2.0.7 or 2.2.12) applications are not 
> loading as expected.
> We configured with shared library(My Faces 2.0) with below jars:
> commons-digester-1.8.jar
>  commons-beanutils-1.8.3.jar
>  commons-codec-1.3.jar
>  commons-logging-1.1.1.jar
>  myfaces-api-2.2.12.jar
>  myfaces-impl-2.2.12.jar
>  commons-collections-3.2.jar
>  WebSphere-MyFaces208-annotation-provider.jar
>  
> Below errors occurs while loading the application:
> Error 500: javax.servlet.ServletException: 
> com/ibm/wsspi/webcontainer/annotation/AnnotationHelper.inject(Ljava/lang/Object;)V
>  (loaded from 
> [file:/opt/IBM/WebSphere/plugins/com.ibm.ws.webcontainer.jar|file://opt/IBM/WebSphere/plugins/com.ibm.ws.webcontainer.jar]
>  by 
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@a41850d1[*com.ibm.ws.webcontainer:8.1.0(id=203)]**)*
>  called from class 
> com.ibm.ws.jsf.config.annotation.WebSphere208AnnotationLifecycleProvider 
> (loaded from 
> [file:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/WebSphere-MyFaces208-annotation-provider.jar|file://opt/IBM/WebSphere/optionalLibraries/Apache/JSF/WebSphere-MyFaces208-annotation-provider.jar]
>  by com.ibm.ws.classloader.CompoundClassLoader@4df7fecd[library:MyFaces2.0] 
> Local ClassPath: 
> /opt/IBM/WebSphere/optionalLibraries/Apache/JSF/commons-digester-1.8.jar:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/commons-beanutils-1.8.3.jar:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/commons-codec-1.3.jar:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/commons-logging-1.1.1.jar:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/myfaces-api-2.2.12.jar:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/myfaces-impl-2.2.12.jar:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/commons-collections-3.2.jar:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/hibernate-jpa-2.0-api-1.0.1.Final.jar:/opt/IBM/WebSphere/optionalLibraries/Apache/JSF/WebSphere-MyFaces208-annotation-provider.jar
>  Parent: com.ibm.ws.classloader.ProtectionClassLoader@1b958d2c Delegation 
> Mode: PARENT_LAST).
>  
> Please do the needful in identifying the root cause of the issue:
>  
> Best Regards
> Kishore Vadivel



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: "[VOTE] release of MyFaces Core 2.3-next-M3"

[Bill Lucy]

+1 from me, looks good.

Thanks Thomas

On Fri, Jul 3, 2020 at 2:30 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> My own +1
>
> Udo Schnurpfeil  schrieb am Mi., 1. Juli 2020, 11:04:
>
>> +1
>> Am 30.06.20 um 14:11 schrieb Thomas Andraschko:
>>
>> Hi,
>>
>> I was running the needed tasks to get the 2.3-next-M3 release of Apache
>> MyFaces core out.
>>
>> It contains new features, performance improvements, bugfixes and provides 
>> compatibility with Quarkus 1.5.2.
>>
>> Please note that this vote concerns all of the following parts:
>>1. Maven artifact group "org.apache.myfaces.core" v2.3-next-M3  [1]
>>
>> The artifacts were deployed on nexus repo [1] for binary and source packages.
>>
>> The release notes could be found at [4].
>>
>> Please take a look at the "2.3-next-M3" 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,
>> Thomas
>>
>> [1] 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1162/org/apache/myfaces/core/
>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> [3] 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1162/org/apache/myfaces/core/myfaces-core-assembly/
>> [4] 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12347873
>>
>>

Re: [VOTE] release of MyFaces Core 2.2.13

[Bill Lucy]

+1

That's an impressive fix list.  Everything looks fine to me, thanks Paul.

On Fri, Jun 26, 2020 at 4:08 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1
>
> thanks for driving the release
>
> Am Do., 25. Juni 2020 um 21:45 Uhr schrieb Paul Nicolucci <
> pnicolu...@gmail.com>:
>
>> Hi,
>>
>> I was running the needed tasks to get the 2.2.13 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.2.13  [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) does not show binary 
>> incompatibilities with myfaces-api.
>> See the attached "results.html" for the output of the japicmp tool.
>>
>> I would also like to note that there was no TCK execution as I could not 
>> find any instructions [5].
>>
>> Please take a look at the "2.2.13" 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,
>> Paul Nicolucci
>>
>> [1] 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1161/org/apache/myfaces/core/
>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> [3] 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1161/org/apache/myfaces/core/myfaces-core-assembly/
>> [4] 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12339346
>> [5] https://markmail.org/message/2bkkesp53wp2lxa7
>>
>>

[jira] [Commented] (MYFACES-4335) Unable to resolve SessionScoped bean in PhaseListener after forward

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17099927#comment-17099927
 ] 

Bill Lucy commented on MYFACES-4335:


It would be nice if this could be replicated in a different environment, as 
[~tandraschko] said.  I had overlooked that the OpenLiberty issue was created, 
but someone will take a look from that angle as well.

> Unable to resolve SessionScoped bean in PhaseListener after forward
> ---
>
> Key: MYFACES-4335
> URL: https://issues.apache.org/jira/browse/MYFACES-4335
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Steven De Groote
>Priority: Major
>
> In a regular Phaselistener, as of JSF 2.2, it is usually possible to 
> [@Inject|https://github.com/Inject] a bean. In my case, I'm injecting a 
> SessionScoped bean, which works well in normal conditions.
> However, if an exception occurs, and the PhaseListener is called again for 
> the error page, then the injection point fails. This should not happen.
> {{org.jboss.weld.contexts.ContextNotActiveException: WELD-001303:
>  No active contexts for scope type 
> javax.enterprise.context.SessionScoped at 
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
>  at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>  at 
> org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:164)
>  at 
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>  at 
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>  at 
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
>  at 
> org.primefaces.test.WebSession$Proxy$_$$_WeldClientProxy.getName(Unknown
>  Source) at 
> org.primefaces.test.LoginController.afterPhase(LoginController.java:26) 
> at 
> org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:117)
>  at 
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:210)
>  at 
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:142)
>  at javax.faces.webapp.FacesServlet.service(FacesServlet.java:204) at 
> com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
>  at 
> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:729)
>  at 
> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:426)
>  at 
> com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:182)
>  at 
> com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:93)
>  at 
> com.ibm.ws.security.jaspi.JaspiServletFilter.doFilter(JaspiServletFilter.java:56)
>  }}
> {{}}
> Note this is the same issue as I posted on OpenLiberty (but without response).
> Over there, I uploaded a reprocase: 
> https://github.com/OpenLiberty/open-liberty/issues/9929{{}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4333) ElContext#getFunctionMapper returns null

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095480#comment-17095480
 ] 

Bill Lucy commented on MYFACES-4333:


[~tandraschko] I'm not sure if it's possible to get a completely invalid 
facesVersion at this point, but I don't see a problem with the check, thanks.

> ElContext#getFunctionMapper returns null
> 
>
> Key: MYFACES-4333
> URL: https://issues.apache.org/jira/browse/MYFACES-4333
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344, JSR-372
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Volodymyr Siedlecki
>Priority: Minor
> Fix For: 2.2.13, 2.3.7, 3.0.0, 2.3-next-M3
>
> Attachments: JSF22-MyFaces-4333.patch, JSF23-MyFaces-4333-Fix.patch, 
> MYFACES-4333.zip
>
>
> {color:#0e101a}Hello,{color}
> {color:#0e101a}When retrieving the functionMapper from the ELContext, null is 
> returned.{color}
> {code:java}
> FacesContext facesContext = FacesContext.getCurrentInstance(); ELContext 
> elContext = facesContext.getELContext(); FunctionMapper functionMapper = 
> elContext.getFunctionMapper(){code}
> {color:#0e101a} A sample application is also attached. It works with the 
> reference implementation, but not with MyFaces. {color}
>  After looking over the code, I noticed that 
> _{color:#0e101a}FacesELContext{color}_ {color:#0e101a}is not initialized with 
> a default function mapper, and the 
> {color}_{color:#0e101a}FacesELContext{color}_{color:#0e101a}#setFunctionMapper
>  was never called. I addressed this by setFunctionMapper in the 
> {color}_{color:#0e101a}NamespaceHandler{color}_{color:#0e101a}. Please let me 
> know if you have any improvements to this fix. The behavior with my fix 
> matches how the reference implementation behaves. {color}
>  
> {color:#0e101a}Additionally, this fix worked for version 2.2, but version 2.3 
> needed another change with the partialStateSavingDefault variable. I believe 
> It's to false by accident when it's checked here: {color}
>  
> {code:java}
>    partialStateSavingDefault = "2.0".equals(facesVersion) || 
> "2.1".equals(facesVersion) || "2.2".equals(facesVersion) || (facesVersion == 
> null);
> {code}
>  
> {color:#0e101a}I wasn't sure whether to add 
> {color}_{color:#0e101a}"2.3".equals(facesVersion){color}_{color:#0e101a}, but 
> I thought it would be better to create a default state variable and keep it 
> within the StateManager.  Please advice if this change should also be applied 
> to 3.0 & master?
>  
>  Thank you{color}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4333) ElContext#getFunctionMapper returns null

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094762#comment-17094762
 ] 

Bill Lucy commented on MYFACES-4333:


Updating the partialStateSavingDefault logic isn't completely necessary since 
the check has been refactored out in the master branch, but I think it's a good 
improvement to make nonetheless.  I'll merge - thanks for the PRs [~volosied]

> ElContext#getFunctionMapper returns null
> 
>
> Key: MYFACES-4333
> URL: https://issues.apache.org/jira/browse/MYFACES-4333
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344, JSR-372
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Volodymyr Siedlecki
>Priority: Minor
> Fix For: 2.2.13, 2.3.7, 3.0.0, 2.3-next-M3
>
> Attachments: JSF22-MyFaces-4333.patch, JSF23-MyFaces-4333-Fix.patch, 
> MYFACES-4333.zip
>
>
> {color:#0e101a}Hello,{color}
> {color:#0e101a}When retrieving the functionMapper from the ELContext, null is 
> returned.{color}
> {code:java}
> FacesContext facesContext = FacesContext.getCurrentInstance(); ELContext 
> elContext = facesContext.getELContext(); FunctionMapper functionMapper = 
> elContext.getFunctionMapper(){code}
> {color:#0e101a} A sample application is also attached. It works with the 
> reference implementation, but not with MyFaces. {color}
>  After looking over the code, I noticed that 
> _{color:#0e101a}FacesELContext{color}_ {color:#0e101a}is not initialized with 
> a default function mapper, and the 
> {color}_{color:#0e101a}FacesELContext{color}_{color:#0e101a}#setFunctionMapper
>  was never called. I addressed this by setFunctionMapper in the 
> {color}_{color:#0e101a}NamespaceHandler{color}_{color:#0e101a}. Please let me 
> know if you have any improvements to this fix. The behavior with my fix 
> matches how the reference implementation behaves. {color}
>  
> {color:#0e101a}Additionally, this fix worked for version 2.2, but version 2.3 
> needed another change with the partialStateSavingDefault variable. I believe 
> It's to false by accident when it's checked here: {color}
>  
> {code:java}
>    partialStateSavingDefault = "2.0".equals(facesVersion) || 
> "2.1".equals(facesVersion) || "2.2".equals(facesVersion) || (facesVersion == 
> null);
> {code}
>  
> {color:#0e101a}I wasn't sure whether to add 
> {color}_{color:#0e101a}"2.3".equals(facesVersion){color}_{color:#0e101a}, but 
> I thought it would be better to create a default state variable and keep it 
> within the StateManager.  Please advice if this change should also be applied 
> to 3.0 & master?
>  
>  Thank you{color}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4333) ElContext#getFunctionMapper Returns NULL

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1709#comment-1709
 ] 

Bill Lucy commented on MYFACES-4333:


[~tandraschko] right, for partialStateSavingDefault the 2.2 impl was already 
correct.  But in 2.3+ we need to check the current faces version for the newer 
versions.

> ElContext#getFunctionMapper Returns NULL
> 
>
> Key: MYFACES-4333
> URL: https://issues.apache.org/jira/browse/MYFACES-4333
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344, JSR-372
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Volodymyr Siedlecki
>Priority: Minor
> Fix For: 2.2.13, 2.3.7, 3.0.0, 2.3-next-M3
>
> Attachments: JSF22-MyFaces-4333.patch, JSF23-MyFaces-4333-Fix.patch, 
> MYFACES-4333.zip
>
>
> {color:#0e101a}Hello,{color}
> {color:#0e101a}When retrieving the functionMapper from the ELContext, null is 
> returned.{color}
> {code:java}
> FacesContext facesContext = FacesContext.getCurrentInstance(); ELContext 
> elContext = facesContext.getELContext(); FunctionMapper functionMapper = 
> elContext.getFunctionMapper(){code}
> {color:#0e101a} A sample application is also attached. It works with the 
> reference implementation, but not with MyFaces. {color}
>  After looking over the code, I noticed that 
> _{color:#0e101a}FacesELContext{color}_ {color:#0e101a}is not initialized with 
> a default function mapper, and the 
> {color}_{color:#0e101a}FacesELContext{color}_{color:#0e101a}#setFunctionMapper
>  was never called. I addressed this by setFunctionMapper in the 
> {color}_{color:#0e101a}NamespaceHandler{color}_{color:#0e101a}. Please let me 
> know if you have any improvements to this fix. The behavior with my fix 
> matches how the reference implementation behaves. {color}
>  
> {color:#0e101a}Additionally, this fix worked for version 2.2, but version 2.3 
> needed another change with the partialStateSavingDefault variable. I believe 
> It's to false by accident when it's checked here: {color}
>  
> {code:java}
>    partialStateSavingDefault = "2.0".equals(facesVersion) || 
> "2.1".equals(facesVersion) || "2.2".equals(facesVersion) || (facesVersion == 
> null);
> {code}
>  
> {color:#0e101a}I wasn't sure whether to add 
> {color}_{color:#0e101a}"2.3".equals(facesVersion){color}_{color:#0e101a}, but 
> I thought it would be better to create a default state variable and keep it 
> within the StateManager.  Please advice if this change should also be applied 
> to 3.0 & master?
>  
>  Thank you{color}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4333) ElContext#getFunctionMapper Returns NULL

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091902#comment-17091902
 ] 

Bill Lucy commented on MYFACES-4333:


One thing - for the 2.3 patch, we shouldn't assume that 
partialStateSavingDefault should be true, since that could change behavior for 
apps with faces-config versions less than 2.  Aside from that, the patch makes 
sense to fix this behavior - can you do github PRs?

> ElContext#getFunctionMapper Returns NULL
> 
>
> Key: MYFACES-4333
> URL: https://issues.apache.org/jira/browse/MYFACES-4333
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344, JSR-372
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Volodymyr Siedlecki
>Priority: Minor
> Attachments: JSF22-MyFaces-4333.patch, JSF23-MyFaces-4333-Fix.patch, 
> MYFACES-4333.zip
>
>
> {color:#0e101a}Hello,{color}
> {color:#0e101a}When retrieving the functionMapper from the ELContext, null is 
> returned.{color}
> {code:java}
> FacesContext facesContext = FacesContext.getCurrentInstance(); ELContext 
> elContext = facesContext.getELContext(); FunctionMapper functionMapper = 
> elContext.getFunctionMapper(){code}
> {color:#0e101a} A sample application is also attached. It works with the 
> reference implementation, but not with MyFaces. {color}
>  After looking over the code, I noticed that 
> _{color:#0e101a}FacesELContext{color}_ {color:#0e101a}is not initialized with 
> a default function mapper, and the 
> {color}_{color:#0e101a}FacesELContext{color}_{color:#0e101a}#setFunctionMapper
>  was never called. I addressed this by setFunctionMapper in the 
> {color}_{color:#0e101a}NamespaceHandler{color}_{color:#0e101a}. Please let me 
> know if you have any improvements to this fix. The behavior with my fix 
> matches how the reference implementation behaves. {color}
>  
> {color:#0e101a}Additionally, this fix worked for version 2.2, but version 2.3 
> needed another change with the partialStateSavingDefault variable. I believe 
> It's to false by accident when it's checked here: {color}
>  
> {code:java}
>    partialStateSavingDefault = "2.0".equals(facesVersion) || 
> "2.1".equals(facesVersion) || "2.2".equals(facesVersion) || (facesVersion == 
> null);
> {code}
>  
> {color:#0e101a}I wasn't sure whether to add 
> {color}_{color:#0e101a}"2.3".equals(facesVersion){color}_{color:#0e101a}, but 
> I thought it would be better to create a default state variable and keep it 
> within the StateManager.  Please advice if this change should also be applied 
> to 3.0 & master?
>  
>  Thank you{color}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] release of MyFaces Core 2.3-next-M2

[Bill Lucy]

+1

In addition to the other improvements, I appreciate the java 11 test
fixes.  Thanks!

On Wed, Apr 1, 2020 at 5:58 PM Hazem Saleh  wrote:

> +1
>
> On Wed, Apr 1, 2020 at 5:46 PM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> Hi,
>>
>> I was running the needed tasks to get the 2.3-next-M2 release of Apache
>> MyFaces core out.
>> It contains some smaller bugfixes and provides compatibility with Quarkus 
>> 1.3.1.
>> Native image generation is now also supported.
>>
>> Please note that this vote concerns all of the following parts:
>>1. Maven artifact group "org.apache.myfaces.core" v2.3-next-M2  [1]
>>
>> The artifacts were deployed on nexus repo [1] for binary and source packages.
>>
>> The release notes could be found at [4].
>>
>> Please take a look at the "2.3-next-M2" 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,
>> Thomas
>>
>> [1] 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1157/org/apache/myfaces/core/
>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> [3] 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1157/org/apache/myfaces/core/myfaces-core-assembly/
>> [4] https://issues.apache.org/jira/projects/MYFACES/versions/12346645
>>
>>
>
> --
> Hazem Saleh
>

[jira] [Resolved] (MYFACES-4320) Startup ConcurrentModificationException in DefaultFacesConfigurationProvider

[Bill Lucy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4320.

Fix Version/s: 3.0.0
   2.3.7-SNAPSHOT
   2.2.13-SNAPSHOT
   Resolution: Fixed

> Startup ConcurrentModificationException in DefaultFacesConfigurationProvider
> 
>
> Key: MYFACES-4320
> URL: https://issues.apache.org/jira/browse/MYFACES-4320
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.6, 3.0.0
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
> Fix For: 2.2.13-SNAPSHOT, 2.3.7-SNAPSHOT, 3.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> In an environment with multiple apps, it's possible to hit a 
> _ConcurrentModificationException_ during startup:
> Caused by: java.util.ConcurrentModificationException
>  at java.util.HashMap$HashIterator.nextNode(HashMap.java:1456)
>  at java.util.HashMap$KeyIterator.next(HashMap.java:1480)
>  at 
> org.apache.myfaces.config.DefaultFacesConfigurationProvider.getMetaInfServicesFacesConfig(DefaultFacesConfigurationProvider.java:218)
> This occurs because _Set FACTORY_NAMES_ is static, but the 
> initialization block following it is not. So it's possible for that 
> initialization block to get run - if a new 
> _DefaultFacesConfigurationProvider_ is initialized at the right time - while 
> another instance is iterating over the set. The fix is to make the 
> initialization block static, which we just need to backport from the master 
> branch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MYFACES-4320) Startup ConcurrentModificationException in DefaultFacesConfigurationProvider

[Bill Lucy (Jira)]

Bill Lucy created MYFACES-4320:
--

 Summary: Startup ConcurrentModificationException in 
DefaultFacesConfigurationProvider
 Key: MYFACES-4320
 URL: https://issues.apache.org/jira/browse/MYFACES-4320
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.6, 2.2.12
Reporter: Bill Lucy
Assignee: Bill Lucy


In an environment with multiple apps, it's possible to hit a 
_ConcurrentModificationException_ during startup:

Caused by: java.util.ConcurrentModificationException
 at java.util.HashMap$HashIterator.nextNode(HashMap.java:1456)
 at java.util.HashMap$KeyIterator.next(HashMap.java:1480)
 at 
org.apache.myfaces.config.DefaultFacesConfigurationProvider.getMetaInfServicesFacesConfig(DefaultFacesConfigurationProvider.java:218)

This occurs because _Set FACTORY_NAMES_ is static, but the 
initialization block following it is not. So it's possible for that 
initialization block to get run - if a new _DefaultFacesConfigurationProvider_ 
is initialized at the right time - while another instance is iterating over the 
set. The fix is to make the initialization block static, which we just need to 
backport from the master branch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4318) c:forEach problem with client side state saving

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045696#comment-17045696
 ] 

Bill Lucy commented on MYFACES-4318:


Is there anywhere we can (or should) better document that "c:forEach just does 
not play well with JSF lifecycle", outside of this JIRA issue?

> c:forEach problem with client side state saving
> ---
>
> Key: MYFACES-4318
> URL: https://issues.apache.org/jira/browse/MYFACES-4318
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Bill Lucy
>Priority: Major
> Attachments: jsf_foreach_client_state.war, 
> jsf_foreach_client_state_mvn.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There appears to be a problem with c:forEach when client side state saving is 
> enabled -  component states are not restored correctly after a submit.  For 
> example, the text entered into this inputText is lost:
> {{{color:#80} {color:#ff}var{color}{color:#00}={color}{color:#ff}"current"{color}
>  
> {color:#ff}items{color}{color:#00}={color}{color:#ff}"#\{list.items}"{color}{color:#80}>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"#\{current.value}"{color}{color:#80}/>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"submit"{color}{color:#80}/>{color}}}
> {{{color:#80}{color}}}
>  
> This example works (the inputText is not lost) with server side state saving 
> enabled, and it also works on Mojarra with client side state saving. I 
> haven't figured out what exactly is causing this behavior yet - if anyone 
> else has insight in this area I'd appreciate hints.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4318) c:forEach problem with client side state saving

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023126#comment-17023126
 ] 

Bill Lucy commented on MYFACES-4318:


Thanks for the feedback [~lu4242]!  I understand that the value of "current" in 
this case doesn't have to map to the "real" backing instance.  It's unfortunate 
that this invalid example works with the legacy handler (and Mojarra), but I 
suppose that's why the legacy handler was left available for users.

> c:forEach problem with client side state saving
> ---
>
> Key: MYFACES-4318
> URL: https://issues.apache.org/jira/browse/MYFACES-4318
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Bill Lucy
>Priority: Major
> Attachments: jsf_foreach_client_state.war, 
> jsf_foreach_client_state_mvn.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There appears to be a problem with c:forEach when client side state saving is 
> enabled -  component states are not restored correctly after a submit.  For 
> example, the text entered into this inputText is lost:
> {{{color:#80} {color:#ff}var{color}{color:#00}={color}{color:#ff}"current"{color}
>  
> {color:#ff}items{color}{color:#00}={color}{color:#ff}"#\{list.items}"{color}{color:#80}>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"#\{current.value}"{color}{color:#80}/>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"submit"{color}{color:#80}/>{color}}}
> {{{color:#80}{color}}}
>  
> This example works (the inputText is not lost) with server side state saving 
> enabled, and it also works on Mojarra with client side state saving. I 
> haven't figured out what exactly is causing this behavior yet - if anyone 
> else has insight in this area I'd appreciate hints.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4318) c:forEach problem with client side state saving

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022642#comment-17022642
 ] 

Bill Lucy commented on MYFACES-4318:


[~volosied] I don't think we should bother with checking the state saving 
method here - as I understand the flow here (and like you said) the swap should 
work all cases.

[~tandraschko] I agree I'm not completely happy with this patch, but so far 
I've struggled to come up with something more generic.  The legacy TagHandler 
for this - LegacyForEachHandler - is a lot simpler, and closer to what Mojarra 
does in its default ForEach implementation.  The LegacyForEachHandler doesn't 
keep track of the iteration state as closely as ForEachHandler does (and that's 
what causes the behavior/problem I've reported here.)  [~lu4242] hinted at the 
complexity of keeping track of all of this state in MYFACES-3811.

> c:forEach problem with client side state saving
> ---
>
> Key: MYFACES-4318
> URL: https://issues.apache.org/jira/browse/MYFACES-4318
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Bill Lucy
>Priority: Major
> Attachments: jsf_foreach_client_state.war, 
> jsf_foreach_client_state_mvn.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There appears to be a problem with c:forEach when client side state saving is 
> enabled -  component states are not restored correctly after a submit.  For 
> example, the text entered into this inputText is lost:
> {{{color:#80} {color:#ff}var{color}{color:#00}={color}{color:#ff}"current"{color}
>  
> {color:#ff}items{color}{color:#00}={color}{color:#ff}"#\{list.items}"{color}{color:#80}>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"#\{current.value}"{color}{color:#80}/>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"submit"{color}{color:#80}/>{color}}}
> {{{color:#80}{color}}}
>  
> This example works (the inputText is not lost) with server side state saving 
> enabled, and it also works on Mojarra with client side state saving. I 
> haven't figured out what exactly is causing this behavior yet - if anyone 
> else has insight in this area I'd appreciate hints.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4318) c:forEach problem with client side state saving

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021593#comment-17021593
 ] 

Bill Lucy commented on MYFACES-4318:


This is related to MYFACES-3811 - when the legacy TagHandlers are used 
(org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY=true) then the input 
value is not lost.  State is lost with the default TagHandler because we end up 
using a deserialized copy of the backing bean.  I have an idea for a patch: 
ForEachHandler can check to see if the local iterator bean instance (which is 
correct) matches the restored instance (which might have been deserialized), 
and replace the incorrect one.  Feedback on this would be helpful.

> c:forEach problem with client side state saving
> ---
>
> Key: MYFACES-4318
> URL: https://issues.apache.org/jira/browse/MYFACES-4318
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Bill Lucy
>Priority: Major
> Attachments: jsf_foreach_client_state.war, 
> jsf_foreach_client_state_mvn.zip
>
>
> There appears to be a problem with c:forEach when client side state saving is 
> enabled -  component states are not restored correctly after a submit.  For 
> example, the text entered into this inputText is lost:
> {{{color:#80} {color:#ff}var{color}{color:#00}={color}{color:#ff}"current"{color}
>  
> {color:#ff}items{color}{color:#00}={color}{color:#ff}"#\{list.items}"{color}{color:#80}>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"#\{current.value}"{color}{color:#80}/>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"submit"{color}{color:#80}/>{color}}}
> {{{color:#80}{color}}}
>  
> This example works (the inputText is not lost) with server side state saving 
> enabled, and it also works on Mojarra with client side state saving. I 
> haven't figured out what exactly is causing this behavior yet - if anyone 
> else has insight in this area I'd appreciate hints.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MYFACES-4318) c:forEach problem with client side state saving

[Bill Lucy (Jira)]

Bill Lucy created MYFACES-4318:
--

 Summary: c:forEach problem with client side state saving
 Key: MYFACES-4318
 URL: https://issues.apache.org/jira/browse/MYFACES-4318
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.6, 2.2.12
Reporter: Bill Lucy
 Attachments: jsf_foreach_client_state.war, 
jsf_foreach_client_state_mvn.zip

There appears to be a problem with c:forEach when client side state saving is 
enabled -  component states are not restored correctly after a submit.  For 
example, the text entered into this inputText is lost:


{{{color:#80}{color}}}
{{{color:#80}{color}}}
{{{color:#80}{color}}}
{{{color:#80}{color}}}
 
This example works (the inputText is not lost) with server side state saving 
enabled, and it also works on Mojarra with client side state saving. I haven't 
figured out what exactly is causing this behavior yet - if anyone else has 
insight in this area I'd appreciate hints.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] release of MyFaces Core 2.3-next-M1

[Bill Lucy]

Thanks for driving this Thomas!  I've done some testing and taken a look at
the Quarkus showcase, and this looks good to me as a M1.

+1

On Fri, Jan 3, 2020 at 4:54 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> up!
>
> my own +1
>
> Am Mo., 23. Dez. 2019 um 15:22 Uhr schrieb Werner Punz <
> werner.p...@gmail.com>:
>
>> +1
>>
>> Werner
>>
>> Vicente Rossello  schrieb am Sa., 21. Dez. 2019,
>> 23:39:
>>
>>> Hi Thomas,
>>>
>>> FYI, tested in our project, everything works.
>>>
>>> Thank you for the effort
>>>
>>> On 2019/12/19 12:43:19, Thomas Andraschko 
>>> wrote:
>>> > Hi,
>>> >
>>> > I was running the needed tasks to get the 2.3-next-M1 release of Apache
>>> > MyFaces core out.
>>> >
>>> > 2.3-next contains the following big changes compared to 2.3:
>>> >
>>> > - big refactoring and cleanup of our codebase!
>>> > - removed FacesEL implementation (API still stays) as its unused since
>>> 2.0
>>> > - removed the ManagedBean impl (API still stays) and register all
>>> > found @ManagedBeans as CDI beans
>>> > - reduced myfaces-jar sizes (including dependencies) about 1MB!
>>> >   No commons-* dependencies required anymore
>>> > - up to 15% better performance
>>> > - we have a running quarkus extension
>>> >   there also is a showcase:
>>> >
>>> https://github.com/apache/myfaces/tree/master/extensions/quarkus/showcase
>>> >   you can run it via "mvn compile quarkus:dev"
>>> >
>>> > I will write a blogpost when it's released.
>>> >
>>> >
>>> > Please note that this vote concerns all of the following parts:
>>> >1. Maven artifact group "org.apache.myfaces.core" v2.3-next-M1  [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) does not show binary
>>> > incompatibilities with myfaces-api.
>>> >
>>> > Please take a look at the "2.3-next-M1" 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,
>>> > Thomas Andraschko
>>> >
>>> > [1]
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1155/org/apache/myfaces/core/
>>> > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>> > [3]
>>> https://repository.apache.org/service/local/repositories/orgapachemyfaces-1155/org/apache/myfaces/core/myfaces-core-assembly/
>>> > [4]
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12344343
>>> >
>>>
>>

Re: Release MyFaces Core 3.0.0-M1?

[Bill Lucy]

+1 for doing a M1 release - all of the points you've made are great,
Thomas.  For versioning, I think the 2.3-modern proposal is good (although
somefaces isn't bad!)

The quarkus extension is interesting as well.  I haven't done any testing
with that yet, but adding it to the myfaces repo seems reasonable.

Regards,
Bill

On Thu, Dec 12, 2019 at 1:20 PM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> Hi,
>
> for me it doesn't matter if we call it 2.3-modern or 3.0-M1 or even
> org.github.somefaces.
>
> I just think that 3.0-M1 isn't a good choice as
> - i would still like to release it with javax instead jakarta
> - releasing a 3.0-M1 with the old javax namespace AND with the knowledge
> that the next 2.x will be with jakarta namespace sounds weird
>
> I generel would just like to cut a release to make it usable and to show
> the people that:
> - we are active
> - we are (almost) completely refactored our code and make it more modern
> - better performance
> - much less jar size (1 MB!)
> - we have a working quarkus extension (!) (
> https://github.com/tandraschko/quarkus-myfaces)
> - we reimplemented the jsf.js with TypeScript (i would like that Werner
> can commit it after we cut the M1 release)
>
> Just again, the current master now is:
> API: 100% JSF2.3, also with the javax namespace
> IMPL: without FacesEL, ManagedBeans implemented as CDI-Delegate and
> annotation-config only.
>
> About quarkus:
> i tried to make it into quarkus directly but they don't like it and it
> also doesn't work on native (EL requires to much reflection).
> It would be great if we can add the quarkus-extension to the myfaces
> codebase as i dont lke to maintain it under my repository. Maybe in
> myfaces-core/extensions/quarkus.
>
> Best regards,
> Thomas
>
>
>
> Am Do., 12. Dez. 2019 um 18:48 Uhr schrieb Paul Nicolucci <
> pnicolu...@gmail.com>:
>
>> Hi,
>>
>> What are the long term consequences of releasing something like
>> 2.3.6-modern or  org.apache.myfaces.core:myfaces-api-modern:2.3.0? Can we
>> just rename it to myfaces 4.0 or whatever the spec version ends up being
>> for Jakarta EE10 once we know what it is going to involve? We already know
>> that MyFaces 3.0 will be Jakarta EE 9 as far as I can tell. As we discussed
>> previously Jakarta EE9 would likely just be taking JSF 2.3 and using the
>> new Jakarta namespace.
>>
>> I just want to ensure that whatever we do now we're not left supporting a
>> 2.3.modern long term and we can replace it with whatever the appropriate
>> version of JSF is once we have a new specification from Jakarta.
>>
>> I agree that it would be nice to get something out there for folks to
>> start working with and testing.
>>
>> Whatever we do we'll want to clearly document what the new version is so
>> users know what they're getting.
>>
>> Regards,
>>
>> Paul Nicolucci
>>
>> On Sun, Dec 8, 2019 at 3:39 PM Thomas Andraschko <
>> andraschko.tho...@gmail.com> wrote:
>>
>>> Commited something now. managed-beans in XML are not supported for now.
>>> Would be great if we can agree on some version/artifact-id, to release
>>> something like a M1.
>>>
>>> Am So., 8. Dez. 2019 um 13:14 Uhr schrieb Thomas Andraschko <
>>> andraschko.tho...@gmail.com>:
>>>
 Or leave the same artifact and Version and do a: 2.3.6-modern

 The we dont have to add new Versions in jira. Makes everything bit
 easier

 Thomas Andraschko  schrieb am So., 8.
 Dez. 2019, 13:03:

> I also thought about another way of releasing it.
> Whats the big difference between 2.3 and 3.0 currently:
> - removed ManagedBeans
> - removed FacesEL
> - big cleanup
>
> If we would simply readd the ManagedBean API, we could register the
> found beans as CDI beans. Thats what DeltaSpike makes.
> We could also add back the FacesEL API but not the impl. Its not used
> anymore by any component lib.
>
> So we would have a JSF 2.3 compatible release which delegates the
> ManagedBeans to CDI. That will make it usable by all CDI users.
>
> Wdyt?
> We could call it:
> org.apache.myfaces.core:myfaces-api-modern:2.3.0
>
>
>
>
>
>
> Thomas Andraschko  schrieb am Di., 19.
> Nov. 2019, 22:21:
>
>> no problem, lets wait.
>> we could also release it as something like 2.3-minmal or something.
>>
>> Am Di., 19. Nov. 2019 um 22:05 Uhr schrieb Paul Nicolucci <
>> pnicolu...@gmail.com>:
>>
>>> This actually came up on the platform dev call this morning. A
>>> thread was started here for discussion:
>>> https://www.eclipse.org/lists/jakartaee-platform-dev/msg00907.html
>>> I think we should follow that conversation and wait for a release until
>>> those details are hammered out.
>>>
>>> I just don't want us to release a JSF 3.0 with new functionality in
>>> it when it might be true that 3.0 would be the version for just the 
>>> Jakarta
>>> namespace update and 

Re: [VOTE] release of MyFaces Core 2.3.6

[Bill Lucy]

+1, thanks for running this quickly Paul.

On Tue, Nov 19, 2019 at 3:51 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1
>
> Am Mo., 18. Nov. 2019 um 18:39 Uhr schrieb Paul Nicolucci <
> pnico...@us.ibm.com>:
>
>> Hi,
>>
>> I was running the needed tasks to get the 2.3.6 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.6  [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 there are no API changes
>> from 2.3.5 to 2.3.6. I've attached the results to this email as well
>> (results.html).
>>
>> *(See attached file: results.html)*
>>
>> If any concerns with the above let me know.
>>
>> Please take a look at the "2.3.6" 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,
>> Paul Nicolucci
>>
>> [1]
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1154/
>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> [3]
>> 
>> https://repository.apache.org/content/repositories/orgapachemyfaces-1154/org/apache/myfaces/core/myfaces-core-assembly/
>> [4]
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12346352
>>
>

Re: Status of MyFaces 2.3.6 and 2.2.13 releases

[Bill Lucy]

+1 sounds good to me, thanks Paul.

On Wed, Nov 13, 2019 at 12:44 PM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1
>
> Am Mi., 13. Nov. 2019 um 18:33 Uhr schrieb Paul Nicolucci <
> pnico...@us.ibm.com>:
>
>> Hi,
>>
>> Just to keep everyone informed we had an issue in 2.3.5 [1] that we have
>> fixed and have targeted for 2.3.6. I'd like to start a 2.3.6 release to get
>> that fix out and then I'll get back to the 2.2.13 release.
>>
>> Any questions or objections let me know.
>>
>> Thanks,
>>
>> Paul Nicolucci
>>
>> [1]: https://issues.apache.org/jira/browse/MYFACES-4309
>>
>

[jira] [Resolved] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4309.

Fix Version/s: 2.3.6
   3.0.0-SNAPSHOT
   2.2.13
   Resolution: Fixed

> Session is broken in some cases due to MYFACES-4297
> ---
>
> Key: MYFACES-4309
> URL: https://issues.apache.org/jira/browse/MYFACES-4309
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.5
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
> Fix For: 2.2.13, 3.0.0-SNAPSHOT, 2.3.6
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The changes made for MYFACES-4297 introduced a problem: in some cases a 
> session is not created early enough for a session cookie to be written out on 
> a response before it is committed, due to the small default response buffer 
> size.  As mentioned in the comments for 4297, that behavior causes a problem 
> for the ViewScope (and I expect the session as well.) 
> As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a 
> workaround, but that's not ideal for a few reasons:
> 1. apps using the default buffer size value will be broken by the new 
> behavior when updating to 2.3.5
> 2. there doesn't appear to be a way to update the buffer size for JSPs
> We should consider revisiting the changes made in MYFACES-4297.  Or, if 
> nothing else, we might want to add some way to change the default buffer size 
> on the JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16972823#comment-16972823
 ] 

Bill Lucy commented on MYFACES-4309:


Thanks for the feedback [~tandraschko].  I've gone ahead and merged these fixes 
for 2.2 and 2.3, and 3.0 with the flipped default property value.

> Session is broken in some cases due to MYFACES-4297
> ---
>
> Key: MYFACES-4309
> URL: https://issues.apache.org/jira/browse/MYFACES-4309
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.5
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The changes made for MYFACES-4297 introduced a problem: in some cases a 
> session is not created early enough for a session cookie to be written out on 
> a response before it is committed, due to the small default response buffer 
> size.  As mentioned in the comments for 4297, that behavior causes a problem 
> for the ViewScope (and I expect the session as well.) 
> As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a 
> workaround, but that's not ideal for a few reasons:
> 1. apps using the default buffer size value will be broken by the new 
> behavior when updating to 2.3.5
> 2. there doesn't appear to be a way to update the buffer size for JSPs
> We should consider revisiting the changes made in MYFACES-4297.  Or, if 
> nothing else, we might want to add some way to change the default buffer size 
> on the JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970158#comment-16970158
 ] 

Bill Lucy commented on MYFACES-4309:


Thanks for the recommendations - I've added both improvements (let me know if 
the description can be further improved.)

> Session is broken in some cases due to MYFACES-4297
> ---
>
> Key: MYFACES-4309
> URL: https://issues.apache.org/jira/browse/MYFACES-4309
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.5
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The changes made for MYFACES-4297 introduced a problem: in some cases a 
> session is not created early enough for a session cookie to be written out on 
> a response before it is committed, due to the small default response buffer 
> size.  As mentioned in the comments for 4297, that behavior causes a problem 
> for the ViewScope (and I expect the session as well.) 
> As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a 
> workaround, but that's not ideal for a few reasons:
> 1. apps using the default buffer size value will be broken by the new 
> behavior when updating to 2.3.5
> 2. there doesn't appear to be a way to update the buffer size for JSPs
> We should consider revisiting the changes made in MYFACES-4297.  Or, if 
> nothing else, we might want to add some way to change the default buffer size 
> on the JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969535#comment-16969535
 ] 

Bill Lucy commented on MYFACES-4309:


Ok, I've updated [https://github.com/apache/myfaces/pull/71] : it adds 
RenderResponseExecutor.forceSessionCreation(), which checks for a new prop 
ALWAYS_FORCE_SESSION_CREATION || (view != transient && stateSaving != client) 
and creates a session. I've left out checking for scopes as I'm hoping 
ALWAYS_FORCE_SESSION_CREATION can better cover that case.

Which brings up a question about ALWAYS_FORCE_SESSION_CREATION: should we 
default it to true?  My interpretation of 4297 is that it's more of 
long-standing bug than a security concern, so I don't think we should have 
changed our behavior in 2.2 and 2.3 in such a way that existing apps are 
required to update their config.  It then makes sense to default 
ALWAYS_FORCE_SESSION_CREATION=false in 3.0.

> Session is broken in some cases due to MYFACES-4297
> ---
>
> Key: MYFACES-4309
> URL: https://issues.apache.org/jira/browse/MYFACES-4309
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.5
>Reporter: Bill Lucy
>Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The changes made for MYFACES-4297 introduced a problem: in some cases a 
> session is not created early enough for a session cookie to be written out on 
> a response before it is committed, due to the small default response buffer 
> size.  As mentioned in the comments for 4297, that behavior causes a problem 
> for the ViewScope (and I expect the session as well.) 
> As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a 
> workaround, but that's not ideal for a few reasons:
> 1. apps using the default buffer size value will be broken by the new 
> behavior when updating to 2.3.5
> 2. there doesn't appear to be a way to update the buffer size for JSPs
> We should consider revisiting the changes made in MYFACES-4297.  Or, if 
> nothing else, we might want to add some way to change the default buffer size 
> on the JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969392#comment-16969392
 ] 

Bill Lucy commented on MYFACES-4309:


I agree with your point on getResponseEncoding - the spec says we shouldn't 
create a session there.  It would make more sense in general to create the 
session earlier on, as you suggest.  I'll work on an updated patch.

> Session is broken in some cases due to MYFACES-4297
> ---
>
> Key: MYFACES-4309
> URL: https://issues.apache.org/jira/browse/MYFACES-4309
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.5
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The changes made for MYFACES-4297 introduced a problem: in some cases a 
> session is not created early enough for a session cookie to be written out on 
> a response before it is committed, due to the small default response buffer 
> size.  As mentioned in the comments for 4297, that behavior causes a problem 
> for the ViewScope (and I expect the session as well.) 
> As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a 
> workaround, but that's not ideal for a few reasons:
> 1. apps using the default buffer size value will be broken by the new 
> behavior when updating to 2.3.5
> 2. there doesn't appear to be a way to update the buffer size for JSPs
> We should consider revisiting the changes made in MYFACES-4297.  Or, if 
> nothing else, we might want to add some way to change the default buffer size 
> on the JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969360#comment-16969360
 ] 

Bill Lucy commented on MYFACES-4309:


Sorry, my comment wasn't very clear.  With my patch, the buffer size increase 
is no longer required in any of the cases I've looked at (including both CDI 
and ManagedBeans.)  But I understand the tradeoff with my patch is that there 
will be some cases where a session will be created incorrectly.  

The reason that I've raised this issue is that the change in 4297 causes a 
large number of failures in the test suite we run.  Many of those tests can be 
fixed by increasing FACELETS_BUFFER_SIZE - it's just concerning to me that a 
potentially high number of users will need to change their app config for 
2.3.5.  

Perhaps as an alternative to my current patch, we could update 
getResponseEncoding to only create a session if the current view is not 
transient or client side state saving is not enabled?  Even a simpler change 
like that would limit the need for increasing the buffer size in a lot of 
existing apps.

> Session is broken in some cases due to MYFACES-4297
> ---
>
> Key: MYFACES-4309
> URL: https://issues.apache.org/jira/browse/MYFACES-4309
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.5
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The changes made for MYFACES-4297 introduced a problem: in some cases a 
> session is not created early enough for a session cookie to be written out on 
> a response before it is committed, due to the small default response buffer 
> size.  As mentioned in the comments for 4297, that behavior causes a problem 
> for the ViewScope (and I expect the session as well.) 
> As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a 
> workaround, but that's not ideal for a few reasons:
> 1. apps using the default buffer size value will be broken by the new 
> behavior when updating to 2.3.5
> 2. there doesn't appear to be a way to update the buffer size for JSPs
> We should consider revisiting the changes made in MYFACES-4297.  Or, if 
> nothing else, we might want to add some way to change the default buffer size 
> on the JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968852#comment-16968852
 ] 

Bill Lucy commented on MYFACES-4309:


Even in the CDI case currently, the session cookie isn't added properly - 
leading to the IllegalStateException: Response is committed.  And that behavior 
can only be corrected by increasing the FACELETS_BUFFER_SIZE param.  I agree 
that PR 71 is not as effective at limiting session creation as the fix for 
4297, but the tradeoff of not breaking some user's apps might be worth it.

> Session is broken in some cases due to MYFACES-4297
> ---
>
> Key: MYFACES-4309
> URL: https://issues.apache.org/jira/browse/MYFACES-4309
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.5
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The changes made for MYFACES-4297 introduced a problem: in some cases a 
> session is not created early enough for a session cookie to be written out on 
> a response before it is committed, due to the small default response buffer 
> size.  As mentioned in the comments for 4297, that behavior causes a problem 
> for the ViewScope (and I expect the session as well.) 
> As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a 
> workaround, but that's not ideal for a few reasons:
> 1. apps using the default buffer size value will be broken by the new 
> behavior when updating to 2.3.5
> 2. there doesn't appear to be a way to update the buffer size for JSPs
> We should consider revisiting the changes made in MYFACES-4297.  Or, if 
> nothing else, we might want to add some way to change the default buffer size 
> on the JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968611#comment-16968611
 ] 

Bill Lucy commented on MYFACES-4309:


I've done a PR at [https://github.com/apache/myfaces/pull/71] that in my 
(limited so far) testing preserves the pre-4297 behavior for the correct app 
configs and scopes.  That is, FACELETS_BUFFER_SIZE doesn't need to be set.  
These changes will be a lot less strict for creating sessions than the original 
4297 fix, but I think the primary cases for 4297 should still be covered.  What 
do you think [~tandraschko] and [~ncister] ?

> Session is broken in some cases due to MYFACES-4297
> ---
>
> Key: MYFACES-4309
> URL: https://issues.apache.org/jira/browse/MYFACES-4309
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.5
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The changes made for MYFACES-4297 introduced a problem: in some cases a 
> session is not created early enough for a session cookie to be written out on 
> a response before it is committed, due to the small default response buffer 
> size.  As mentioned in the comments for 4297, that behavior causes a problem 
> for the ViewScope (and I expect the session as well.) 
> As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a 
> workaround, but that's not ideal for a few reasons:
> 1. apps using the default buffer size value will be broken by the new 
> behavior when updating to 2.3.5
> 2. there doesn't appear to be a way to update the buffer size for JSPs
> We should consider revisiting the changes made in MYFACES-4297.  Or, if 
> nothing else, we might want to add some way to change the default buffer size 
> on the JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MYFACES-4309) Session is broken in some cases due to MYFACES-4297

[Bill Lucy (Jira)]

Bill Lucy created MYFACES-4309:
--

 Summary: Session is broken in some cases due to MYFACES-4297
 Key: MYFACES-4309
 URL: https://issues.apache.org/jira/browse/MYFACES-4309
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.5
Reporter: Bill Lucy
Assignee: Bill Lucy


The changes made for MYFACES-4297 introduced a problem: in some cases a session 
is not created early enough for a session cookie to be written out on a 
response before it is committed, due to the small default response buffer size. 
 As mentioned in the comments for 4297, that behavior causes a problem for the 
ViewScope (and I expect the session as well.) 

As discussed, increasing the javax.faces.FACELETS_BUFFER_SIZE is a workaround, 
but that's not ideal for a few reasons:
1. apps using the default buffer size value will be broken by the new behavior 
when updating to 2.3.5
2. there doesn't appear to be a way to update the buffer size for JSPs

We should consider revisiting the changes made in MYFACES-4297.  Or, if nothing 
else, we might want to add some way to change the default buffer size on the 
JSP path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4307) FacesValidator seems to not be working as expected

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959908#comment-16959908
 ] 

Bill Lucy commented on MYFACES-4307:


Thomas is correct for 3), see 
https://github.com/eclipse-ee4j/mojarra#activating-cdi-in-jsf-23

> FacesValidator seems to not be working as expected
> --
>
> Key: MYFACES-4307
> URL: https://issues.apache.org/jira/browse/MYFACES-4307
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.4
> Environment: Apache Netbeans 11.1
> OpenJDK 12
> Windows 10
> Apache TomEE Plus 8.0
> MyFaces 2.3.4
> OpenWebbeans 2.0.9
>Reporter: Cédric Servais
>Priority: Major
> Attachments: UserExistValidator.java
>
>
> Hello,
> I've generated a basic FacesValidator which uses CDI to retrieve FacesContext 
> and other Container Managed-Bean.
> I've noted several issues while doing so:
>  * @FacesValidator with "managed = true" isn't enough to make this Validator 
> a managed-bean being "Injectable".
>  * @Dependent (or any other scope) must be added to workaround the previous 
> point.
>  * If you want to inject FacesContext as described in JSF 2.3 spec, you also 
> need to add @FacesConfig(version = FacesConfig.Version.JSF_2_3), without that 
> setting, injecting a FacesContext will result in NullPointerException.
>  
> It may be that not all of this is related to MyFaces or that I misunderstood 
> some part of the JSF 2.3 specs but I'm not able to run the attachec validator 
> without these additions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MYFACES-4307) FacesValidator seems to not be working as expected

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959908#comment-16959908
 ] 

Bill Lucy edited comment on MYFACES-4307 at 10/25/19 4:33 PM:
--

For 3), see [https://github.com/eclipse-ee4j/mojarra#activating-cdi-in-jsf-23]


was (Author: wtlucy):
Thomas is correct for 3), see 
https://github.com/eclipse-ee4j/mojarra#activating-cdi-in-jsf-23

> FacesValidator seems to not be working as expected
> --
>
> Key: MYFACES-4307
> URL: https://issues.apache.org/jira/browse/MYFACES-4307
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.4
> Environment: Apache Netbeans 11.1
> OpenJDK 12
> Windows 10
> Apache TomEE Plus 8.0
> MyFaces 2.3.4
> OpenWebbeans 2.0.9
>Reporter: Cédric Servais
>Priority: Major
> Attachments: UserExistValidator.java
>
>
> Hello,
> I've generated a basic FacesValidator which uses CDI to retrieve FacesContext 
> and other Container Managed-Bean.
> I've noted several issues while doing so:
>  * @FacesValidator with "managed = true" isn't enough to make this Validator 
> a managed-bean being "Injectable".
>  * @Dependent (or any other scope) must be added to workaround the previous 
> point.
>  * If you want to inject FacesContext as described in JSF 2.3 spec, you also 
> need to add @FacesConfig(version = FacesConfig.Version.JSF_2_3), without that 
> setting, injecting a FacesContext will result in NullPointerException.
>  
> It may be that not all of this is related to MyFaces or that I misunderstood 
> some part of the JSF 2.3 specs but I'm not able to run the attachec validator 
> without these additions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] release of MyFaces Core 2.3.5

[Bill Lucy]

+1

Looks good to me, thanks Paul.

On Thu, Oct 10, 2019 at 2:32 PM Dennis Kieselhorst  wrote:

> +1
>
> Thanks Paul!
>

Re: Remove GAE support in 3.x?

[Bill Lucy]

I don't know the history behind the inclusion of GAE support - but I'm not
familiar with any current users.  I'd consider removing that support out of
core (and potentially into some extension) an improvement.

Regards,
Bill

On Wed, Oct 2, 2019 at 7:10 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> also note:
> i think we can still add GAE support (if someone really needs it!) to a
> own extension, which just overwrites/enhances some SPI of MyFaces.
> Thats similar to what i did for quarkus (
> https://github.com/tandraschko/quarkus-myfaces). I'm also not sure where
> to host it.
>
>
>
> Am Mi., 2. Okt. 2019 um 13:06 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
>> Hi,
>>
>> we still have GAE support in MyFaces Core and i'm really unsure if it was
>> ever used.
>> I would like to get rid of it in trunk, which targets 3.0.
>> WDYT?
>>
>> Regards,
>> Thomas
>>
>

[jira] [Resolved] (MYFACES-4300) Upgrade Apache Commons Beanutils to 1.9.4

[Bill Lucy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4300.

Fix Version/s: 2.3.5-SNAPSHOT
   3.0.0-SNAPSHOT
   2.2.13-SNAPSHOT
   2.1.19-SNAPSHOT
   2.0.25-SNAPSHOT
   Resolution: Fixed

> Upgrade Apache Commons Beanutils to 1.9.4
> -
>
> Key: MYFACES-4300
> URL: https://issues.apache.org/jira/browse/MYFACES-4300
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-344, JSR-372
>Affects Versions: 2.2.12, 2.3.4
>Reporter: Volodymyr Siedlecki
>Assignee: Bill Lucy
>Priority: Minor
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT, 
> 3.0.0-SNAPSHOT, 2.3.5-SNAPSHOT
>
> Attachments: MYFACES-4300-22x.patch, MYFACES-4300-23x.patch, 
> MYFACES-4300-master.patch
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Hello,
> A security vulnerability (CVE-2019-10086) was discovered in Apache Commons 
> Beanutils 1.9.2. Previously, MyFaces had updated to 1.9.2 in this issue 
> https://issues.apache.org/jira/browse/MYFACES-4032 relating to another 
> security issue (CVE-2014-0114) but was found *not* vulnerable.
> As for the current vulnerability, 1.9.2 had added a special BeanIntrospector 
> class that prevents attackers from using the class property of all java 
> objects to access the class loader. However, _this behavior was not set as 
> the default_ (1).
> It does not appear that MyFaces is vulnerable to this new vulnerability since 
> there are only a few non-vulnerable startup uses of Apache Commons Beanutils 
> in the MyFaces code:
> impl/src/main/java/org/apache/myfaces/application/ApplicationImpl.java
>  BeanUtils.setProperty(converter, property.getPropertyName(), 
> property.getDefaultValue())
> impl/src/main/java/org/apache/myfaces/config/ManagedBeanBuilder.java
>  if (PropertyUtils.isReadable(bean, property.getPropertyName()))
>  if (PropertyUtils.isReadable(bean, property.getPropertyName()))
> However, I hope you may still upgrade MyFaces to use the latest update of 
> Apache Commons Beanutil, version 1.9.4.
> I’ve added patches for 2.2.x, 2.3.x, master. All three have build 
> successfully when I tested the update.
> 1. 
> [http://mail-archives.apache.org/mod_mbox/www-announce/201908.mbox/%3cc628798f-315d-4428-8cb1-4ed1ecc95...@apache.org%3E]
>  2. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10086]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4300) Upgrade Apache Commons Beanutils to 1.9.4

[Bill Lucy (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16933712#comment-16933712
 ] 

Bill Lucy commented on MYFACES-4300:


Thanks for the patch, [~volosied]!  I've applied your patch from the 2.0 - 
master branches.

> Upgrade Apache Commons Beanutils to 1.9.4
> -
>
> Key: MYFACES-4300
> URL: https://issues.apache.org/jira/browse/MYFACES-4300
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-344, JSR-372
>Affects Versions: 2.2.12, 2.3.4
>Reporter: Volodymyr Siedlecki
>Priority: Minor
> Attachments: MYFACES-4300-22x.patch, MYFACES-4300-23x.patch, 
> MYFACES-4300-master.patch
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Hello,
> A security vulnerability (CVE-2019-10086) was discovered in Apache Commons 
> Beanutils 1.9.2. Previously, MyFaces had updated to 1.9.2 in this issue 
> https://issues.apache.org/jira/browse/MYFACES-4032 relating to another 
> security issue (CVE-2014-0114) but was found *not* vulnerable.
> As for the current vulnerability, 1.9.2 had added a special BeanIntrospector 
> class that prevents attackers from using the class property of all java 
> objects to access the class loader. However, _this behavior was not set as 
> the default_ (1).
> It does not appear that MyFaces is vulnerable to this new vulnerability since 
> there are only a few non-vulnerable startup uses of Apache Commons Beanutils 
> in the MyFaces code:
> impl/src/main/java/org/apache/myfaces/application/ApplicationImpl.java
>  BeanUtils.setProperty(converter, property.getPropertyName(), 
> property.getDefaultValue())
> impl/src/main/java/org/apache/myfaces/config/ManagedBeanBuilder.java
>  if (PropertyUtils.isReadable(bean, property.getPropertyName()))
>  if (PropertyUtils.isReadable(bean, property.getPropertyName()))
> However, I hope you may still upgrade MyFaces to use the latest update of 
> Apache Commons Beanutil, version 1.9.4.
> I’ve added patches for 2.2.x, 2.3.x, master. All three have build 
> successfully when I tested the update.
> 1. 
> [http://mail-archives.apache.org/mod_mbox/www-announce/201908.mbox/%3cc628798f-315d-4428-8cb1-4ed1ecc95...@apache.org%3E]
>  2. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10086]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: MyFaces 2.3.5 and 2.2.13 releases

[Bill Lucy]

+1, the 2.2 branch in particular has many unreleased fixes!

On Tue, Jul 30, 2019 at 3:26 PM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1
> would be great :)
>
> Am Di., 30. Juli 2019 um 20:25 Uhr schrieb Paul Nicolucci <
> pnico...@us.ibm.com>:
>
>> Hi,
>>
>> Any objections to starting the 2.3.5 and 2.2.13 releases of MyFaces?
>>
>> I'll do the 2.3 release first as that is fresh in my mind and then work
>> on the 2.2 release, Thomas and Bill had pointed out it has been quite
>> awhile since we released 2.2 so I think it is a good idea!
>>
>> I should have the ability to start this in the coming weeks.
>>
>> Regards,
>>
>> Paul Nicolucci
>>
>

[jira] [Comment Edited] (MYFACES-4299) ManagedProperty & Websocket: NullPointerException

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896237#comment-16896237
 ] 

Bill Lucy edited comment on MYFACES-4299 at 7/30/19 3:34 PM:
-

Thanks [~tandraschko]!  A 2.3 release a good idea, by my count we already have 
6 issues fixed since 2.3.4.  A 2.2 release is an even better idea, it's been 
well over two years since 2.2.12) not found.  I'll look into getting those 
started.


was (Author: wtlucy):
Thanks [~tandraschko]!  A 2.3 release a good idea, by my count we already have 
6 issues fixed since 2.3.4.  A 2.2 release is an even better idea, it's been 
well over two years since 2.2.12!  I'll look into getting those started.

> ManagedProperty & Websocket: NullPointerException 
> --
>
> Key: MYFACES-4299
> URL: https://issues.apache.org/jira/browse/MYFACES-4299
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-372
>Affects Versions: 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4
> Environment: Tomcat 
>Reporter: Volodymyr Siedlecki
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 3.0.0-SNAPSHOT, 2.3.5
>
> Attachments: MYFACES-4299-app.zip
>
>
> Hello,
>  
> I have a sample JSF 2.3.3 application  that uses @ManagedProperty with a web 
> socket observer class. This application throws a null pointer exception.  
> In the createManagedProperty of the ManagedPropertyProducer class,  
> FacesContext.getCurrentInstance() returns null.
> In the createManagedProperty method, if you catch the error and create a new 
> facesContext via BeanProvider.getContextualReference, the example still won’t 
> work. Is there any way around this error?
> Or can anyone confirm that this example is not a valid use of 
> ManagedProperty?  It doesn’t seem like it since the communication is going 
> through web sockets and therefore isn’t hitting the Faces Servlet. 
>  
> Also, this application doesn't work with the mojarra 2.3 code either.
>  
> I’ve provided the sample application. 
> Here is the stack trace:
> java.lang.NullPointerException
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.createManagedProperty(ManagedPropertyProducer.java:83)
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.lambda$new$0(ManagedPropertyProducer.java:77)
>      at 
> org.apache.myfaces.cdi.util.AbstractDynamicProducer.create(AbstractDynamicProducer.java:97)
>      at 
> org.apache.webbeans.component.third.ThirdpartyBeanImpl.create(ThirdpartyBeanImpl.java:97)
>      at 
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:68)
>      at 
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:125)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:813)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:673)
>  
> Thank you



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (MYFACES-4299) ManagedProperty & Websocket: NullPointerException

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896237#comment-16896237
 ] 

Bill Lucy commented on MYFACES-4299:


Thanks [~tandraschko]!  A 2.3 release a good idea, by my count we already have 
6 issues fixed since 2.3.4.  A 2.2 release is an even better idea, it's been 
well over two years since 2.2.12!  I'll look into getting those started.

> ManagedProperty & Websocket: NullPointerException 
> --
>
> Key: MYFACES-4299
> URL: https://issues.apache.org/jira/browse/MYFACES-4299
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-372
>Affects Versions: 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4
> Environment: Tomcat 
>Reporter: Volodymyr Siedlecki
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 3.0.0-SNAPSHOT, 2.3.5
>
> Attachments: MYFACES-4299-app.zip
>
>
> Hello,
>  
> I have a sample JSF 2.3.3 application  that uses @ManagedProperty with a web 
> socket observer class. This application throws a null pointer exception.  
> In the createManagedProperty of the ManagedPropertyProducer class,  
> FacesContext.getCurrentInstance() returns null.
> In the createManagedProperty method, if you catch the error and create a new 
> facesContext via BeanProvider.getContextualReference, the example still won’t 
> work. Is there any way around this error?
> Or can anyone confirm that this example is not a valid use of 
> ManagedProperty?  It doesn’t seem like it since the communication is going 
> through web sockets and therefore isn’t hitting the Faces Servlet. 
>  
> Also, this application doesn't work with the mojarra 2.3 code either.
>  
> I’ve provided the sample application. 
> Here is the stack trace:
> java.lang.NullPointerException
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.createManagedProperty(ManagedPropertyProducer.java:83)
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.lambda$new$0(ManagedPropertyProducer.java:77)
>      at 
> org.apache.myfaces.cdi.util.AbstractDynamicProducer.create(AbstractDynamicProducer.java:97)
>      at 
> org.apache.webbeans.component.third.ThirdpartyBeanImpl.create(ThirdpartyBeanImpl.java:97)
>      at 
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:68)
>      at 
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:125)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:813)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:673)
>  
> Thank you



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: Core: is ClassLoaderExtension used?

[Bill Lucy]

Hi Thomas,

The only use of this extension that I can find is in the MyFaces
Extension-Scripting project[1].  I'm not sure if compatibility with
ExtScripting is already broken - but given the status of that project I
don't think getting rid of the ClassLoaderExtension in 3.0 will be a
problem.

[1]
https://github.com/apache/myfaces-scripting/blob/trunk/extscript-core-root/extscript-myfaces/src/main/java/org/apache/myfaces/extensions/scripting/jsf/adapters/MyFacesSPI.java

Regards,
Bill

On Mon, Jul 15, 2019 at 3:45 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> Hi,
>
> we have a ClassLoaderExtension, which basically is a mechanism to exchange
> the classForName implementation.
> Does this really make sense? Its there since 1.x...
>
> I would like to get rid of such code in 3.x, if it was never used.
>
> Best regards,
> Thomas
>

[jira] [Commented] (MYFACES-4299) ManagedProperty & Websocket: NullPointerException

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896107#comment-16896107
 ] 

Bill Lucy commented on MYFACES-4299:


[~tandraschko] would you mind if I port your 3.x change to 2.3?

> ManagedProperty & Websocket: NullPointerException 
> --
>
> Key: MYFACES-4299
> URL: https://issues.apache.org/jira/browse/MYFACES-4299
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-372
>Affects Versions: 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4
> Environment: Tomcat 
>Reporter: Volodymyr Siedlecki
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 3.0.0-SNAPSHOT
>
> Attachments: MYFACES-4299-app.zip
>
>
> Hello,
>  
> I have a sample JSF 2.3.3 application  that uses @ManagedProperty with a web 
> socket observer class. This application throws a null pointer exception.  
> In the createManagedProperty of the ManagedPropertyProducer class,  
> FacesContext.getCurrentInstance() returns null.
> In the createManagedProperty method, if you catch the error and create a new 
> facesContext via BeanProvider.getContextualReference, the example still won’t 
> work. Is there any way around this error?
> Or can anyone confirm that this example is not a valid use of 
> ManagedProperty?  It doesn’t seem like it since the communication is going 
> through web sockets and therefore isn’t hitting the Faces Servlet. 
>  
> Also, this application doesn't work with the mojarra 2.3 code either.
>  
> I’ve provided the sample application. 
> Here is the stack trace:
> java.lang.NullPointerException
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.createManagedProperty(ManagedPropertyProducer.java:83)
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.lambda$new$0(ManagedPropertyProducer.java:77)
>      at 
> org.apache.myfaces.cdi.util.AbstractDynamicProducer.create(AbstractDynamicProducer.java:97)
>      at 
> org.apache.webbeans.component.third.ThirdpartyBeanImpl.create(ThirdpartyBeanImpl.java:97)
>      at 
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:68)
>      at 
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:125)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:813)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:673)
>  
> Thank you



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (MYFACES-4299) ManagedProperty & Websocket: NullPointerException

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895575#comment-16895575
 ] 

Bill Lucy commented on MYFACES-4299:


I've opened a spec issue for this 
https://github.com/javaee/javaserverfaces-spec/issues/1470

> ManagedProperty & Websocket: NullPointerException 
> --
>
> Key: MYFACES-4299
> URL: https://issues.apache.org/jira/browse/MYFACES-4299
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-372
>Affects Versions: 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4
> Environment: Tomcat 
>Reporter: Volodymyr Siedlecki
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 3.0.0-SNAPSHOT
>
> Attachments: MYFACES-4299-app.zip
>
>
> Hello,
>  
> I have a sample JSF 2.3.3 application  that uses @ManagedProperty with a web 
> socket observer class. This application throws a null pointer exception.  
> In the createManagedProperty of the ManagedPropertyProducer class,  
> FacesContext.getCurrentInstance() returns null.
> In the createManagedProperty method, if you catch the error and create a new 
> facesContext via BeanProvider.getContextualReference, the example still won’t 
> work. Is there any way around this error?
> Or can anyone confirm that this example is not a valid use of 
> ManagedProperty?  It doesn’t seem like it since the communication is going 
> through web sockets and therefore isn’t hitting the Faces Servlet. 
>  
> Also, this application doesn't work with the mojarra 2.3 code either.
>  
> I’ve provided the sample application. 
> Here is the stack trace:
> java.lang.NullPointerException
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.createManagedProperty(ManagedPropertyProducer.java:83)
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.lambda$new$0(ManagedPropertyProducer.java:77)
>      at 
> org.apache.myfaces.cdi.util.AbstractDynamicProducer.create(AbstractDynamicProducer.java:97)
>      at 
> org.apache.webbeans.component.third.ThirdpartyBeanImpl.create(ThirdpartyBeanImpl.java:97)
>      at 
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:68)
>      at 
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:125)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:813)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:673)
>  
> Thank you



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (MYFACES-4299) ManagedProperty & Websocket: NullPointerException

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893863#comment-16893863
 ] 

Bill Lucy commented on MYFACES-4299:


I've been able to reproduce this as well.  I agree that throwing a better 
exception in 3.x is the right thing to do for this case.  As for 2.3, we 
probably shouldn't NPE here - I'll check to see what Mojarra does.

The 2.3 spec and the @ManagedProperty javadoc don't list this as a limitation - 
so this scenario might have been an oversight.

> ManagedProperty & Websocket: NullPointerException 
> --
>
> Key: MYFACES-4299
> URL: https://issues.apache.org/jira/browse/MYFACES-4299
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-372
>Affects Versions: 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4
> Environment: Tomcat 
>Reporter: Volodymyr Siedlecki
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 3.0.0-SNAPSHOT
>
> Attachments: MYFACES-4299-app.zip
>
>
> Hello,
>  
> I have a sample JSF 2.3.3 application  that uses @ManagedProperty with a web 
> socket observer class. This application throws a null pointer exception.  
> In the createManagedProperty of the ManagedPropertyProducer class,  
> FacesContext.getCurrentInstance() returns null.
> In the createManagedProperty method, if you catch the error and create a new 
> facesContext via BeanProvider.getContextualReference, the example still won’t 
> work. Is there any way around this error?
> Or can anyone confirm that this example is not a valid use of 
> ManagedProperty?  It doesn’t seem like it since the communication is going 
> through web sockets and therefore isn’t hitting the Faces Servlet. 
>  
> Also, this application doesn't work with the mojarra 2.3 code either.
>  
> I’ve provided the sample application. 
> Here is the stack trace:
> java.lang.NullPointerException
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.createManagedProperty(ManagedPropertyProducer.java:83)
>      at 
> org.apache.myfaces.cdi.managedproperty.ManagedPropertyProducer.lambda$new$0(ManagedPropertyProducer.java:77)
>      at 
> org.apache.myfaces.cdi.util.AbstractDynamicProducer.create(AbstractDynamicProducer.java:97)
>      at 
> org.apache.webbeans.component.third.ThirdpartyBeanImpl.create(ThirdpartyBeanImpl.java:97)
>      at 
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:68)
>      at 
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:125)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:813)
>      at 
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:673)
>  
> Thank you



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (MYFACES-4292) String Out of Bounds Exception Thrown

[Bill Lucy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4292.

Resolution: Fixed

> String Out of Bounds Exception Thrown
> -
>
> Key: MYFACES-4292
> URL: https://issues.apache.org/jira/browse/MYFACES-4292
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344
>Affects Versions: 2.0.24, 2.1.18, 2.2.12
>Reporter: Volodymyr Siedlecki
>Assignee: Bill Lucy
>Priority: Minor
> Fix For: 2.0.25, 2.1.19, 2.2.13
>
> Attachments: MYFACES-4292.diff
>
>
> When deploying an application, the placement of the MANIFEST.MF file in a 
> loose application xml can cause a java.lang.StringIndexOutOfBoundsException 
> during MyFaces initialization. This problem occurs with the following path: 
> /tmp/war/MANIFEST.MF 
> This issue was solved in JSF 2.3 with MYFACES-4273, but not in JSF 2.2.
> By moving the catch block to the outer try block in 
> myfaces/view/facelets/util/Classpath.java, the 
> StringIndexOutOfBoundsException will be caught, and the  faces initialization 
> will continue normally.  
> Stack Trace:
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: 0
>      at java.base/java.lang.String.substring(String.java:2628)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath._searchFromURL(Classpath.java:246)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath._searchResource(Classpath.java:119)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath.search(Classpath.java:69)
>      at 
> org.apache.myfaces.config.DefaultFacesConfigResourceProvider.getMetaInfConfigurationResources(DefaultFacesConfigResourceProvider.java:90)
>      at 
> org.apache.myfaces.config.DefaultFacesConfigurationProvider.getClassloaderFacesConfig(DefaultFacesConfigurationProvider.java:312)
>      … 21 more



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4292) String Out of Bounds Exception Thrown

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858867#comment-16858867
 ] 

Bill Lucy commented on MYFACES-4292:


Thanks for the patch and PR [~volosied] - I've pulled down the PR and it looks 
good.  I'll merge your PR and backport this to 2.0 and 2.1.

> String Out of Bounds Exception Thrown
> -
>
> Key: MYFACES-4292
> URL: https://issues.apache.org/jira/browse/MYFACES-4292
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344
>Affects Versions: 2.2.12
>Reporter: Volodymyr Siedlecki
>Priority: Minor
> Fix For: 2.2.13
>
> Attachments: MYFACES-4292.diff
>
>
> When deploying an application, the placement of the MANIFEST.MF file in a 
> loose application xml can cause a java.lang.StringIndexOutOfBoundsException 
> during MyFaces initialization. This problem occurs with the following path: 
> /tmp/war/MANIFEST.MF 
> This issue was solved in JSF 2.3 with MYFACES-4273, but not in JSF 2.2.
> By moving the catch block to the outer try block in 
> myfaces/view/facelets/util/Classpath.java, the 
> StringIndexOutOfBoundsException will be caught, and the  faces initialization 
> will continue normally.  
> Stack Trace:
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: 0
>      at java.base/java.lang.String.substring(String.java:2628)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath._searchFromURL(Classpath.java:246)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath._searchResource(Classpath.java:119)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath.search(Classpath.java:69)
>      at 
> org.apache.myfaces.config.DefaultFacesConfigResourceProvider.getMetaInfConfigurationResources(DefaultFacesConfigResourceProvider.java:90)
>      at 
> org.apache.myfaces.config.DefaultFacesConfigurationProvider.getClassloaderFacesConfig(DefaultFacesConfigurationProvider.java:312)
>      … 21 more



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4292) String Out of Bounds Exception Thrown

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858859#comment-16858859
 ] 

Bill Lucy commented on MYFACES-4292:


I was able to reproduce this by following along with 
[https://github.com/OpenLiberty/open-liberty/issues/5898]

What's happening is a similar case to the existing comment - so I think the 
patch is fine.
_// This can happen if the classloader provided us a URL that it thinks exists_
_// but really doesn't.  In particular, if a JAR contains META-INF/MANIFEST.MF_
_// but not META-INF/, some classloaders may incorrectly report that META-INF/_
_// exists and we'll end up here.  Just ignore this case._

> String Out of Bounds Exception Thrown
> -
>
> Key: MYFACES-4292
> URL: https://issues.apache.org/jira/browse/MYFACES-4292
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344
>Affects Versions: 2.2.12
>Reporter: Volodymyr Siedlecki
>Priority: Minor
> Fix For: 2.2.13
>
> Attachments: MYFACES-4292.diff
>
>
> When deploying an application, the placement of the MANIFEST.MF file in a 
> loose application xml can cause a java.lang.StringIndexOutOfBoundsException 
> during MyFaces initialization. This problem occurs with the following path: 
> /tmp/war/MANIFEST.MF 
> This issue was solved in JSF 2.3 with MYFACES-4273, but not in JSF 2.2.
> By moving the catch block to the outer try block in 
> myfaces/view/facelets/util/Classpath.java, the 
> StringIndexOutOfBoundsException will be caught, and the  faces initialization 
> will continue normally.  
> Stack Trace:
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: 0
>      at java.base/java.lang.String.substring(String.java:2628)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath._searchFromURL(Classpath.java:246)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath._searchResource(Classpath.java:119)
>      at 
> org.apache.myfaces.view.facelets.util.Classpath.search(Classpath.java:69)
>      at 
> org.apache.myfaces.config.DefaultFacesConfigResourceProvider.getMetaInfConfigurationResources(DefaultFacesConfigResourceProvider.java:90)
>      at 
> org.apache.myfaces.config.DefaultFacesConfigurationProvider.getClassloaderFacesConfig(DefaultFacesConfigurationProvider.java:312)
>      … 21 more



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: MyFaces 2.3.4 Announce rejected / infra issue

[Bill Lucy]

Hey Paul,

Thanks for working all this out!  All of the corrections you've mentioned
here look fine to me.  I've verified a) b) and c) on a few different
systems / networks.  Hopefully the INFRA issue you've opened will ensure we
don't have to deal with this type of release problem in the future.

Regards,
Bill

On Sat, May 25, 2019 at 11:51 AM Paul Nicolucci  wrote:

> Hi folks,
>
> If you're wondering why you did not see the official annou...@apache.org
> mail it is because it was rejected for the following reasons that I'm
> working to correct:
>
> 1) Missing new lines between commands in the "Verifying signatures"
> section of the download page here: http://myfaces.apache.org/download.html
> - I have corrected this here:
> http://svn.apache.org/viewvc/myfaces/site/trunk/src/site/apt/download.apt?r1=1859898=1859897=1859898
> - Note this wasn't specific to the 2.3.4 release it has been like this for
> awhile.
>
> 2) Mention of MD5 when we supply SHA512 checksums in our new releases /
> KEYs, signatures and checksum links should be https rather than http.
> - I have corrected this here:
> http://svn.apache.org/viewvc/myfaces/site/trunk/src/site/apt/download.apt?r1=1859902=1859901=1859902
> basically adding some words around md5 or sha512 etc to avoid confusion in
> the future.
> - Note this wasn't specific to the 2.3.4 release it has been like this for
> awhile.
>
> 3) The moderator for announcements stated they could not see any of the
> 2.3.4 updates on the download page. I was eventually able to sometimes
> reproduce this and tracked it down to an infra issue that I worked with
> some folks in slack to get a solution, however today it seems the latest
> updates are showing the same sort of problem.
>
> I've opened the following infra ticket today to get a resolution:
> https://issues.apache.org/jira/browse/INFRA-18484
>
> ** Assistance requested **
> Would folks please go to the website: mvn http://myfaces.apache.org , and
> verify the following to give me some extra testing:
> a) Verify that the upper left corner states "Last Published: 24 May 2019"
> b) Verify it shows "May 23, 2019 - MyFaces Core 2.3.4 released"
> c) Go to the download page and ensure that each of the 2.3.4 links (12 of
> them) function correctly and we don't get any 404s or "not found on mirror"
> issues.
>
> If a couple people can help with the testing above it would be great,
> please add issues to the INFRA ticket if you find a problem that is related.
>
> Any comments on the changes I made to the site please let me know and I'll
> make requested changes over the weekend. Once all of this is sorted out
> I'll resubmit the announce.
>
> Thanks,
>
> Paul Nicolucci
>

Re: [VOTE] release of MyFaces Core 2.3.4

[Bill Lucy]

Everything looks good to me, +1

Thanks,
Bill

On Sun, May 19, 2019 at 12:55 PM Eduardo Breijo  wrote:

> +1
>
> Thanks!
> Eduardo Breijo
>
> On Sat, May 18, 2019 at 8:22 AM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> +1
>> thanks
>>
>> Am Fr., 17. Mai 2019 um 20:24 Uhr schrieb Paul Nicolucci <
>> pnico...@us.ibm.com>:
>>
>>>
>>>Hi,
>>>
>>>I was running the needed tasks to get the 2.3.4 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.4  [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 the only api changes
>>>from 2.3.3 to 2.3.4 are the changes to UIForm.java in:
>>>https://issues.apache.org/jira/browse/MYFACES-4283. I've attached
>>>the results to this email as well (results-2.3.4.html).
>>>
>>>*(See attached file: results-2.3.4.html)*
>>>
>>>If any concerns with the above let me know.
>>>
>>>Please take a look at the "2.3.4" 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,
>>>Paul Nicolucci
>>>
>>>[1]
>>>https://repository.apache.org/content/repositories/orgapachemyfaces-1151/
>>>[2] *http://www.apache.org/foundation/voting.html#ReleaseVotes*
>>>
>>>[3]
>>>
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1151/org/apache/myfaces/core/myfaces-core-assembly/
>>>[4]
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12344874
>>>
>>>
>>>

Re: MyFaces 2.3.4 release?

[Bill Lucy]

+1, let me know if you can use any assistance

Regards,
Bill

On Tue, May 14, 2019 at 1:54 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +1
>
> Paul Nicolucci  schrieb am Di., 14. Mai 2019, 01:33:
>
>> Any objection to me starting a 2.3.4 MyFaces Core release?
>>
>> Thanks,
>>
>> Paul Nicolucci
>>
>

[jira] [Resolved] (MYFACES-4282) Incompatibility with DeltaSpike JSF Module 1.x

[Bill Lucy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4282.

Resolution: Fixed

> Incompatibility with DeltaSpike JSF Module 1.x
> --
>
> Key: MYFACES-4282
> URL: https://issues.apache.org/jira/browse/MYFACES-4282
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.3
> Environment: Tomcat 9.0.14
> OpenWebBeans 2.0.8
> DeltaSpike 1.x (tested 1.0.0, 1.8.2, 1.9.0)
>Reporter: Juri Berlanda
>Assignee: Bill Lucy
>Priority: Major
> Fix For: 2.2.13, 3.0.0-SNAPSHOT, 2.3.4
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Some change in 2.3.3 causes and incompatibility with Apache DeltaSpike's JSF 
> Module. I am not sure yet what exactly causes it, but MyFaces 2.3.2 is NOT 
> affected.
> The issue arose on our side, as we noticed @PostConstruct of some of our 
> @ViewScope @Model is called twice.
> Mojarra 2.3.8 is NOT affected, which - together with the fact that MyFaces 
> 2.3.2 is not affected either - brings me to the conclusion this is a bug 
> introduced with MyFaces 2.3.3.
> I have a minimal project showing the issue, which I will link here shortly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4282) Incompatibility with DeltaSpike JSF Module 1.x

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830368#comment-16830368
 ] 

Bill Lucy commented on MYFACES-4282:


I'll go ahead and close this out since we haven't heard back from [~j-be] and 
the fix I've merged fixes the test case - please reopen if more work is needed 
here.

> Incompatibility with DeltaSpike JSF Module 1.x
> --
>
> Key: MYFACES-4282
> URL: https://issues.apache.org/jira/browse/MYFACES-4282
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.3
> Environment: Tomcat 9.0.14
> OpenWebBeans 2.0.8
> DeltaSpike 1.x (tested 1.0.0, 1.8.2, 1.9.0)
>Reporter: Juri Berlanda
>Assignee: Bill Lucy
>Priority: Major
> Fix For: 2.2.13, 3.0.0-SNAPSHOT, 2.3.4
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Some change in 2.3.3 causes and incompatibility with Apache DeltaSpike's JSF 
> Module. I am not sure yet what exactly causes it, but MyFaces 2.3.2 is NOT 
> affected.
> The issue arose on our side, as we noticed @PostConstruct of some of our 
> @ViewScope @Model is called twice.
> Mojarra 2.3.8 is NOT affected, which - together with the fact that MyFaces 
> 2.3.2 is not affected either - brings me to the conclusion this is a bug 
> introduced with MyFaces 2.3.3.
> I have a minimal project showing the issue, which I will link here shortly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MYFACES-4287) Unable to restore view which contains a stateless template

[Bill Lucy (JIRA)]

Bill Lucy created MYFACES-4287:
--

 Summary: Unable to restore view which contains a stateless template
 Key: MYFACES-4287
 URL: https://issues.apache.org/jira/browse/MYFACES-4287
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.3, 2.2.12
Reporter: Bill Lucy
Assignee: Bill Lucy


The fix for https://issues.apache.org/jira/browse/MYFACES-4164 has introduced a 
new problem - views which contain templates with the transient attribute set 
throw an error during restoreView:

_Caused by: javax.faces.FacesException: unable to create view "/index.xhtml"_
     _at 
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:2130)_
     _at 
org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:338)_

 

This can be reproduced with a very simple view and template:
 {color:#80}<{color}{color:#cd3131}h:body{color}{color:#80}>{color}
 {color:#80} <{color}{color:#cd3131}ui:composition{color} 
{color:#ff}template{color}{color:#00}={color}{color:#ff}"template/layout.xhtml"{color}{color:#80}/>{color}
 {color:#80}{color}
 {color:#80}...{color}
 {color:#80}<{color}{color:#cd3131}h:body{color}{color:#80}>{color}
 {color:#80} <{color}{color:#cd3131}f:view{color} 
{color:#ff}transient{color}{color:#00}={color}{color:#ff}"true"{color}{color:#80}>{color}
 {color:#80} <{color}{color:#cd3131}h:form{color}{color:#80}>{color}
 {color:#80} <{color}{color:#cd3131}h:commandButton{color} 
{color:#ff}value{color}{color:#00}={color}{color:#ff}"submit"{color}
 
{color:#ff}action{color}{color:#00}={color}{color:#ff}"index"{color}{color:#80}/>{color}
 {color:#80} {color}
 {color:#80} {color}
 {color:#80}


The fix for this is to modify the change made in MYFACES-4146 to check if the 
view is transient _after_ buildView has been called.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (MYFACES-4284) ClassNotFoundException during initialization

[Bill Lucy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy resolved MYFACES-4284.

Resolution: Fixed

> ClassNotFoundException during initialization
> 
>
> Key: MYFACES-4284
> URL: https://issues.apache.org/jira/browse/MYFACES-4284
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.3
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
> Fix For: 2.2.13, 2.3.4
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> A ClassNotFoundException can occur during initialization when a servlet 
> mapping is defined which cannot be loaded by MyFaces.  We should update 
> WebXml.getFacesServletMappings() to not throw an exception when it can't load 
> a class.
> javax.faces.FacesException: java.lang.ClassNotFoundException: 
>      at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:239)
>      at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:215)
>      at 
> org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getFacesServletMappings(WebXml.java:136)
>      at 
> org.apache.myfaces.spi.impl.DefaultWebConfigProvider.getFacesServletMappings(DefaultWebConfigProvider.java:46)
>      at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:161)
> This is related to the fix made in MYFACES-3629 
> Any servlet defined in the web.xml that can't be loaded by at the time of JSF 
> initialization will cause this problem.  As an example, this definition will 
> cause MyFaces initialization to fail:
>     __ 
>         _unloadable_ 
>         _does.not.Exist_ 
>         _1_ 
>     __



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4284) ClassNotFoundException during initialization

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795314#comment-16795314
 ] 

Bill Lucy commented on MYFACES-4284:


[~tandraschko] we don't appear to need this fix in 3.x.  This logic was 
refactored, and now the safe invocation of 
_ClassUtils.simpleClassForName(className, false)_ is used - see 
_FacesServletMappingUtils.isFacesServlet()._

> ClassNotFoundException during initialization
> 
>
> Key: MYFACES-4284
> URL: https://issues.apache.org/jira/browse/MYFACES-4284
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.3
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
> Fix For: 2.2.13, 2.3.4
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> A ClassNotFoundException can occur during initialization when a servlet 
> mapping is defined which cannot be loaded by MyFaces.  We should update 
> WebXml.getFacesServletMappings() to not throw an exception when it can't load 
> a class.
> javax.faces.FacesException: java.lang.ClassNotFoundException: 
>      at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:239)
>      at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:215)
>      at 
> org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getFacesServletMappings(WebXml.java:136)
>      at 
> org.apache.myfaces.spi.impl.DefaultWebConfigProvider.getFacesServletMappings(DefaultWebConfigProvider.java:46)
>      at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:161)
> This is related to the fix made in MYFACES-3629 
> Any servlet defined in the web.xml that can't be loaded by at the time of JSF 
> initialization will cause this problem.  As an example, this definition will 
> cause MyFaces initialization to fail:
>     __ 
>         _unloadable_ 
>         _does.not.Exist_ 
>         _1_ 
>     __



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4282) Incompatibility with DeltaSpike JSF Module 1.x

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795229#comment-16795229
 ] 

Bill Lucy commented on MYFACES-4282:


[~tandraschko] this new fix just skips clearing out the view map when we're 
building view metadata, so there won't be any new destroy calls.  In my testing 
the changes in MYFACES-4260 combined with PR # 46 don't cause any other 
problems - but it would be nice to verify that everything is OK from the 
Deltaspike side.

> Incompatibility with DeltaSpike JSF Module 1.x
> --
>
> Key: MYFACES-4282
> URL: https://issues.apache.org/jira/browse/MYFACES-4282
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.3
> Environment: Tomcat 9.0.14
> OpenWebBeans 2.0.8
> DeltaSpike 1.x (tested 1.0.0, 1.8.2, 1.9.0)
>Reporter: Juri Berlanda
>Assignee: Bill Lucy
>Priority: Major
> Fix For: 3.0.0-SNAPSHOT, 2.3.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Some change in 2.3.3 causes and incompatibility with Apache DeltaSpike's JSF 
> Module. I am not sure yet what exactly causes it, but MyFaces 2.3.2 is NOT 
> affected.
> The issue arose on our side, as we noticed @PostConstruct of some of our 
> @ViewScope @Model is called twice.
> Mojarra 2.3.8 is NOT affected, which - together with the fact that MyFaces 
> 2.3.2 is not affected either - brings me to the conclusion this is a bug 
> introduced with MyFaces 2.3.3.
> I have a minimal project showing the issue, which I will link here shortly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4284) ClassNotFoundException during initialization

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793900#comment-16793900
 ] 

Bill Lucy commented on MYFACES-4284:


Interestingly, with this fix Tomcat inits the JSF app and doesn't log any 
errors.  On Open Liberty, the JSF app is initialized and an error message is 
logged for the bad servlet.  Regardless, I'll go ahead and work on merging the 
PRs.

> ClassNotFoundException during initialization
> 
>
> Key: MYFACES-4284
> URL: https://issues.apache.org/jira/browse/MYFACES-4284
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.3
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> A ClassNotFoundException can occur during initialization when a servlet 
> mapping is defined which cannot be loaded by MyFaces.  We should update 
> WebXml.getFacesServletMappings() to not throw an exception when it can't load 
> a class.
> javax.faces.FacesException: java.lang.ClassNotFoundException: 
>      at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:239)
>      at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:215)
>      at 
> org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getFacesServletMappings(WebXml.java:136)
>      at 
> org.apache.myfaces.spi.impl.DefaultWebConfigProvider.getFacesServletMappings(DefaultWebConfigProvider.java:46)
>      at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:161)
> This is related to the fix made in MYFACES-3629 
> Any servlet defined in the web.xml that can't be loaded by at the time of JSF 
> initialization will cause this problem.  As an example, this definition will 
> cause MyFaces initialization to fail:
>     __ 
>         _unloadable_ 
>         _does.not.Exist_ 
>         _1_ 
>     __



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4284) ClassNotFoundException during initialization

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792746#comment-16792746
 ] 

Bill Lucy commented on MYFACES-4284:


I've done a PR for this: [https://github.com/apache/myfaces/pull/47]

Any comments?

> ClassNotFoundException during initialization
> 
>
> Key: MYFACES-4284
> URL: https://issues.apache.org/jira/browse/MYFACES-4284
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.3
>Reporter: Bill Lucy
>    Assignee: Bill Lucy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> A ClassNotFoundException can occur during initialization when a servlet 
> mapping is defined which cannot be loaded by MyFaces.  We should update 
> WebXml.getFacesServletMappings() to not throw an exception when it can't load 
> a class.
> javax.faces.FacesException: java.lang.ClassNotFoundException: 
>     at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:239)
>     at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:215)
>     at 
> org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getFacesServletMappings(WebXml.java:136)
>     at 
> org.apache.myfaces.spi.impl.DefaultWebConfigProvider.getFacesServletMappings(DefaultWebConfigProvider.java:46)
>     at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:161)
> This is related to the fix made in MYFACES-3629 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MYFACES-4284) ClassNotFoundException during initialization

[Bill Lucy (JIRA)]

Bill Lucy created MYFACES-4284:
--

 Summary: ClassNotFoundException during initialization
 Key: MYFACES-4284
 URL: https://issues.apache.org/jira/browse/MYFACES-4284
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.3
Reporter: Bill Lucy
Assignee: Bill Lucy


A ClassNotFoundException can occur during initialization when a servlet mapping 
is defined which cannot be loaded by MyFaces.  We should update 
WebXml.getFacesServletMappings() to not throw an exception when it can't load a 
class.

javax.faces.FacesException: java.lang.ClassNotFoundException: 
    at 
org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:239)
    at 
org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:215)
    at 
org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getFacesServletMappings(WebXml.java:136)
    at 
org.apache.myfaces.spi.impl.DefaultWebConfigProvider.getFacesServletMappings(DefaultWebConfigProvider.java:46)
    at 
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:161)

This is related to the fix made in MYFACES-3629 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4282) Incompatibility with DeltaSpike JSF Module 1.x

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16790557#comment-16790557
 ] 

Bill Lucy commented on MYFACES-4282:


The problem here occurs when DeltaSpike's ViewHandler calls setViewRoot during 
its createView method - which leads to MyFaces clearing out the view map, since 
we believe a view scope has ended.  This is the stack of the clear() that 
destroys ViewScopeModel after it's first built, which leads to the second 
PostConstruct:

    _at 
org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:148)_
    _at 
org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:299)_
    _at 
javax.faces.context.FacesContextWrapper.setViewRoot(FacesContextWrapper.java:247)_
    _at 
org.apache.deltaspike.jsf.impl.security.SecurityAwareViewHandler.createView(SecurityAwareViewHandler.java:106)_
    _at 
org.apache.deltaspike.jsf.impl.view.DeltaSpikeViewHandler.createView(DeltaSpikeViewHandler.java:70)_
    _at 
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage$FaceletViewMetadata.createMetadataView(FaceletViewDeclarationLanguage.java:2750)_

A potential fix on our side is to skip calling clear() on the view scope map on 
this path - while we're building the view metadata.  I've done a PR at 
[https://github.com/apache/myfaces/pull/46].  [~j-be] I've tested this PR 
against your sample and the behavior appears correct; can you verify this?

> Incompatibility with DeltaSpike JSF Module 1.x
> --
>
> Key: MYFACES-4282
> URL: https://issues.apache.org/jira/browse/MYFACES-4282
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.3
> Environment: Tomcat 9.0.14
> OpenWebBeans 2.0.8
> DeltaSpike 1.x (tested 1.0.0, 1.8.2, 1.9.0)
>Reporter: Juri Berlanda
>Assignee: Eduardo Breijo
>Priority: Major
> Fix For: 3.0.0-SNAPSHOT, 2.3.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Some change in 2.3.3 causes and incompatibility with Apache DeltaSpike's JSF 
> Module. I am not sure yet what exactly causes it, but MyFaces 2.3.2 is NOT 
> affected.
> The issue arose on our side, as we noticed @PostConstruct of some of our 
> @ViewScope @Model is called twice.
> Mojarra 2.3.8 is NOT affected, which - together with the fact that MyFaces 
> 2.3.2 is not affected either - brings me to the conclusion this is a bug 
> introduced with MyFaces 2.3.3.
> I have a minimal project showing the issue, which I will link here shortly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)