Hi Arjan, In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master". What's the main differences between the two branches? The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right? For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it? Thanks, Zhijun

Hi Zhijun, Since the public repo has been archived, how does Oracle plan to maintain the 2.3.x, 2.2.x, and 2.1.x versions of Mojarra? How can the community contribute fixes and bug reports for those versions? How often will those versions of Mojarra be released? - Kyle

Dear friends of JSF, Does anyone have the ability to get download statistics from Maven Central for Mojarra? I'm interested in seeing the download trends over the past year. My best guess is that whoever has the username+password at Oracle for publishing artifacts has the ability. It would be as simple as signing-in to https://oss.sonatype.org/ and clicking on "Central Statistics" Thanks, Neil

Hi, In the JAVAEE 8 Platform Specification there is Table EE.5-1 that lists component classes supporting injection. In this table the following JSF 2.3 artifacts are listed: JSF managed classes^b (support level Standard). b. See the JSF specification section “JSF Managed Classes and Java EE Annotations” for a list of these managed classes. The table in the JSF 2.3 specification for "JSF Managed Classes and Java EE Annotations" Table 5-3 lists the JSF artifacts that are eligible for injection. However, the example in the spec only details field and method injection and from the tests I've done neither MyFaces nor Mojarra support constructor injection on these artifacts. I believe this is by design, however it causes confusion when reading the two specifications because the JavaEE 8 Platform Specification also says the following: EE.5.24 Support for Dependency Injection .... .... "Therefore, to make injection support more uniform across all Java EE component types, Java EE containers are required to support field, method, and constructor injection using the javax.inject.Inject annotation into all component classes listed in Table EE.5-1 as having the “Standard” level of injection support, as well as the use of interceptors for these classes. " ... ... Should we add a note to the JSF spec to be more clear about not supporting Constructor injection in the JSF artifacts listed in Table 5-3 and then in turn open a spec issues against the platform spec to say JSF is limited vs standard for support of Injection in EE.5-1? Any additional thoughts? Thanks, Paul Nicolucci

So, I'll table the talks about javaserverfaces.com for now and turn the attention to jsfcentral.com. I've been meaning to move it to a new platform for years, and now it's time. Right now I'm thinking of using a modern look and feel and getting rid of everything except for the original content and adding some of the excellent of zeef.com widgets from folks like Arjan Tijms and Anghel Leonard. Thoughts? ___ Kito D. Mann | @kito99 | Java Champion | LinkedIn Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Polymer, Web Components, Angular Virtua, Inc. | virtua.tech JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com

Hello, According to the JSF spec section 5.4.1 “JSF Managed Classes and Java EE Annotations”, there are a bunch of JSF artifacts eligible for injection. On MyFaces, all these objects allow injection when they are registered globally via faces-config.xml. However, injection in ActionListener and PhaseListener don’t work if they are registered per component/view in a facelet using <f:actionListener/> and <f:phaseListener/>. The following MyFaces JIRA was opened to discuss the issue with the MyFaces community: https://issues.apache.org/jira/browse/MYFACES-4138 On Mojarra, I was not able to get these objects to support injection, I tried registering them globally via faces-config.xml and registering them per component/view in a facelet. Does injection in ActionListener or PhaseListener need to be supported when they are registered in a facelet using <f:actionListener/> and <f:phaseListener/>? Thanks, Paul Nicolucci

Hi Kito, Thanks indeed for doing this. It is very important to have a modern look and updated content. But the number of sites and URLs are just too much, too much: * The site you are updating which has easy to remember URLs: http://www.javaserverfaces.com (also dot org) * The Mojarra site, which has a URL that isn't quite as easy to remember: https://javaserverfaces.github.io/ * The Spec site, which has a URL that is difficult (for me, at least) to remember: https://javaee.github.io/javaserverfaces-spec/ I vote for #2 in order to unify all the sites with an easy to remember URL. Neil

Hello JSF Community, I have been delighted to see all the pull requests coming in over GitHub. Thank you very much for contributing them. Pull Requests or comments have been submitted by some of the following GitHub identities: 99sono Alin Constantin Andrew Arend v. Reinersdorf chris21k Clint Munden Cody Lerum Hantsym Bai Jens Berke Juri Berlanda kordirko Kyle J Stiemann laxman3018 martin654 Mauro Molinari Neil Griffin omolenkamp Piotrek -B Roland H Sebastien Lepage Sergey Morenets SuperPat Thomas Andraschko Toberumono Vladimir Dvorak zsalab As you know, Oracle is donating Java EE 8 (and only Java EE 8, no prior versions) to Eclipse as EE4J. If you are content for your Mojarra pull request to only go into EE4J (no prior versions of Mojarra, even JSF 2.3.x and earlier), then you have two choices regarding the legalities of getting a PR accepted: 1. Wait for the initial donation of EE4J, which will include Mojarra master branch, and follow the Eclipse contributor process for EE4J, once it is established. 2. Follow the Oracle Contributor Agreement (OCA) [1] and ALSO follow the Eclipse Contributor Process for EE4J once it is established. If you want to entertain the possibility of your PR being accepted before the Eclipse contributor process for EE4J is established, *OR* you want your PR to be considered for a version of Mojarra 2.3.0 or earlier, you must follow the OCA [1]. We cannot accept any pull requests into the existing <github.com/javaserverfaces/mojarra> project without a valid and confirmed OCA. It is our intent to look at every PR and evaluate the feasibility of accepting it. Thanks, Ed -- | edburns@... | office: 407 458 0017 | http://purl.oclc.org/NET/edburns/pgp/ [1] http://www.oracle.com/technetwork/community/oca-486395.html

Hi, The project page (see below) displays the Java EE 7 coordinates, and later on for Java EE 7 the same. I guess, the first coordinates mentioned here shall refer to Java EE 8? -- Herzliche Grüße - Best Regards, Michael Müller Brühl, Germany blog.mueller-bruehl.de it-rezension.de @muellermi Read my books "Web Development with Java and JSF": https://leanpub.com/jsf "Java Lambdas and Parallel Streams": http://www.apress.com/de/book/9781484224861 "Visitors" a photographic image book: https://leanpub.com/visitors The Best Way to Satisfy A Dependency on JSF The recommend way to use JSF with Maven is to develop on a Java EE certified container and declare a <provided> scope dependency on the appropriate version of the Java EE API jar. For example: <dependency> <groupId>javax</groupId> <artifactId>javaee-api</artifactId> <version>7.0</version> <scope>provided</scope> </dependency> [snip] Java EE 7 (also satisfies JSF 2.2 compile-time dependencies) <dependency> <groupId>javax</groupId> <artifactId>javaee-api</artifactId> <version>7.0</version> <scope>provided</scope> </dependency>

Hi everyone, First of all a test to see if the new mailing lists work, and just an open question of what things if any all of you think should be interesting for a next spec release of JSF? Kind regards, Arjan Tijms

Hi, Historically there's a gap between one spec cycle ending and the next one starting, and that gap has been widening a little over the years. What if we try to break this trend and plan for filing a JSR for the next version of JSF relatively soon, say in 1 to 2 months? For now theme proposals are: * Continued CDI alignment * Simplified component model * Tying up loose ends from 2.3 Ed, what do you think? Can we file a new JSR in that timeline and start with a new EG? Kind regards, Arjan Tijms