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

Hello Paul,

I secured some time to think about this today. If you like, you can
skip right to the CONCLUSION by searching for CONCLUSION:.

First, the general rationale for ctor injection is adequately described
in this stackoverflow post
https://stackoverflow.com/questions/19381846/why-use-constructor-over-setter-injection-in-cdi .
Given that rationale, ctor injection seems to make the most sense for
domain objects, rather than the classes in Table 5-3.

Let's take a look at each of the classes in Table 5-3 and ask ourselves
if it makes sense to have ctor injection for that class, and what it
would mean to have ctor injection. I will also suggest a potential use
for ctor injection for a future revision of JSF.

javax.el.ELResolver

Section 5.5.2.1 states "ELResolver instances have application lifetime
and scope." Since this is lifetime scope, we really don't know what
would make sense to pass to a ctor injection.

Future: Perhaps the presence of @Inject with an ELResolver argument
could be used to provide a reference to the parent ELResolver in the
chain.

javax.faces.application.ApplicationFactory

Section 7.2 states, "A single instance of
javax.faces.application.ApplicationFactory must be made available to
each JSF- based web application running in a servlet or portlet
container." Since this is a singleton, what would make sense to pass to
the ctor?

Also, this class is mentioned in section 11.4.7 Delegating
Implementation Support. In that section, the spec says, "For all of
these artifacts, the decorator design pattern is leveraged, so that if
one provides a constructor that takes a single argument of the
appropriate type, the custom implementation receives a reference to
the implementation that was previously fulfilling the role." So in
this sense we already support ctor injection for this class. Future
occurrences of this explanation will be labeled as "See 11.4.7
Delegating Implementation Support"

Future: Perhaps this @Inject could be passed the
javax.enterprise.inject.spi.CDI.

javax.faces.application.NavigationHandler

Section 7.4.1 states, "A single NavigationHandler instance is
responsible for consuming the logical outcome returned by an application
action that was invoked, along with additional state information that is
available from the FacesContext instance for the current request, and
(optionally) selecting a new view to be rendered." So, this is a singleton.

See 11.4.7 Delegating Implementation Support

javax.faces.application.ResourceHandler

This is also an application singleton. See 11.4.7 Delegating
Implementation Support.

See 11.4.7 Delegating Implementation Support

Future: Perhaps this @Inject could be passed the default
ViewDeclarationLanguage?

javax.faces.application.StateManager

Section 7.8 makes it clear the StateManager is an application
singleton, therefore ctor injection doesn't make a lot of sense.

See 11.4.7 Delegating Implementation Support

Future: Perhaps this @Inject could be passed the default
ViewDeclarationLanguage?

javax.faces.component.visit.VisitContextFactory

This is a singleton factory. I don't see what it would be useful to
pass for ctor injection.

See 11.4.7 Delegating Implementation Support

javax.faces.context.ExceptionHandlerFactory

This is a singleton factory. I don't see what it would be useful to
pass for ctor injection.

See 11.4.7 Delegating Implementation Support

javax.faces.context.ExternalContextFactory

Section 6.8 states, "A single instance of
javax.faces.context.ExternalContextFactory must be made available to
each JSF-based web application running in a servlet or portlet
container."

This is a singleton factory. I don't see what it would be useful to
pass for ctor injection.

See 11.4.7 Delegating Implementation Support

javax.faces.context.FacesContextFactory

This is a singleton factory.

Future: Since the default one simply turns around and calls the
exceptionHandlerFactory() and externalContextFactory, it would make
sense to allow these to be @Inject ctor injected, but that would be a
new feature.

See 11.4.7 Delegating Implementation Support

javax.faces.context.PartialViewContextFactory

Since this is an application singletion, I don't know it would make
sense to pass for ctor injection.

javax.faces.event.ActionListener

See 11.4.7 Delegating Implementation Support

javax.faces.event.SystemEventListener

This one is implemented by application code.

Future: Perhaps ctor injection could be passed the Application?

javax.faces.lifecycle.ClientWindowFactory

This is a singleton factory.

Future: the default impl gets a handle to the Application and
subscribes to the PostConstructApplicationEvent. Perhaps ctor
injection could be useful to pass the Application.

javax.faces.lifecycle.LifecycleFactory

This is a singleton factory.

Future: Perhaps this @Inject could be passed the
javax.enterprise.inject.spi.CDI.

See 11.4.7 Delegating Implementation Support

javax.faces.event.PhaseListener

These are application singletons.

Future: Perhaps ctor injection could pass a reference to the
Application, or the Lifecycle?

javax.faces.render.RenderKitFactory

This is a singleton factory.

Future: Perhaps ctor injection could pass a reference to the
Application.

See 11.4.7 Delegating Implementation Support

javax.faces.view.ViewDeclarationLanguageFactory

This is a singleton factory.

Future: Perhaps ctor injection could pass a reference to the
Application.

javax.faces.view.facelets.FaceletCacheFactory

This is a singleton factory.

Future: Perhaps ctor injection could pass a reference to the
Application.

javax.faces.view.facelets. TagHandlerDelegateFactory

This is a singleton factory.

Future: Perhaps ctor injection could pass a reference to the
Application.

CONCLUSION:

In conclusion I will propose the JSF maintenance lead to make the
following change to the spec.

In section 5.4.1, please change the text

In addition to managed beans being injectable in this manner, the
following JSF artifacts are also injectable.

to be instead

In addition to managed beans being injectable in this manner, the
following JSF artifacts are also injectable via field and setter
injection. Constructor injection does not make sense for these
artifacts and is not supported.

Thanks,

Ed

The Platform spec issue is here: https://github.com/javaee/javaee-spec/issues/62

I have the following JSF 2.3 Spec issue opened: https://github.com/javaee/javaserverfaces-spec/issues/1455

I'm working to open an issue with the EE8 platform spec. I'll post that in this thread once opened.

I reached out to Ed Burns directly and got the following response:

Hello Paul,

Thanks for following the correct protocol for reaching out to us as
stewards of JSF.  I'm very sorry that I was unable to meet your correct
action with correct action of my own in the form of a timely response.

First, let me introduce you to Ren Zhijun.  Zhijun is taking over as
maintenance lead of JSF for all versions of JSF 2.3 and earlier.  What
happens with new JSRs after 2.3 is up to EE4J.  We can consider this
mail a handoff.

Second, the matter at hand.  I have reviewed the table in question and
agree with your implementation analysis.  Therefore, I agree with your
suggestion to file an issue against the platform spec and an errata for
JSF 2.3.

PN> What would you suggest is the next action for the JSF spec? Should I
PN> open an issue against the EE platform spec to say JSF offers limited
PN> support rather than standard support? Can we also add this to the
PN> errata for JSF 2.3 as we did for:
PN> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_javaee_javaserverfaces-2Dspec_issues_1449-3F&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=n-2RUhyQkncKQNTGKy9UmSKIHKSZzEVYEqiy1H7hEwA&m=1XeUXyQF2NN8NdkZRzOxQ-tvQs1V0C7RflEpt4634d8&s=MKFR7U02PkRFXolrm89sB-YE4L9Db2wM-JKFAqVfwNA&e=

Zhijun, can you please add this issue to the JSF 2.3 change log for when
we are able to release an MR for JSF 2.3?

Ed

On Tue, 22 Aug 2017 07:18:25 -0700, pnicoluc@us.ibm.com said:

PN> Hello, According to the JSF spec section 5.4.1 JSF Managed Classes
PN> and Java EE Annotations, there are a bunch of JSF artifacts eligible
PN> for injection.

On Fri, 17 Nov 2017 05:23:29 -0800, Edward Burns <edward.burns@oracle.com> said:

EB> First, let me introduce you to Ren Zhijun. Zhijun is taking over as
EB> maintenance lead of JSF for all versions of JSF 2.3 and earlier.
EB> What happens with new JSRs after 2.3 is up to EE4J.


PN> On MyFaces, all these objects allow injection when they are
PN> registered globally via faces-config.xml.  However, injection in
PN> ActionListener and PhaseListener dont work if they are registered
PN> per component/view in a facelet using  <f:actionListener/> and
PN> <f:phaseListener/>.

PN> The following MyFaces JIRA was opened to discuss the issue with the
PN> MyFaces community:
PN> https://issues.apache.org/jira/browse/MYFACES-4138

PN> On Mojarra, I was not able to get these objects to support
PN> injection,  I tried registering them globally via faces-config.xml
PN> and registering them per component/view in a facelet.

PN> Does injection in ActionListener or PhaseListener need to be
PN> supported when they are registered in a facelet using
PN> <f:actionListener/> and <f:phaseListener/>?

I think they should support injection, but I will leave that for Zhijun
to decide.

Thanks,

Ed

--
| 7 business days until CodeEurope Poland 2017
| 53 business days until JavaLand 2018
| edward.burns@oracle.com | office: +1 407 458 0017

On Mon, 13 Nov 2017 10:19:08 -0500, "Kito Mann" <kito.mann@virtua.com> said:

KM> Is there a particular reason you think Oracle would act differently
KM> regarding javaserverfaces.com than they have since Dan Allen and co put up
KM> the site many, many years ago?

I am not party to that side of the business but I can say that it seems
reasonable that part of the business would be paying more attention to
this sort of thing now, given the desire to do the Java EE to EE4J
transition correctly for all stakeholders.

Thanks,

Ed

--
| 10 business days until CodeEurope Poland 2017
| 56 business days until JavaLand 2018
| edward.burns@oracle.com | office: +1 407 458 0017

Java is an island, isn't is? ;-)

Hi,

Hello Kito,

Thanks for reactivating that site. I hate to be the spoilsport here, but based on empirical observations, names that start with "java" tend to be at risk for Oracle asserting their right to use that name. Therefore, I can only advise option 3:

KM> (3) Scrap javaserverfaces.com and update the spec site collaboratively (once it moves to EE4J?)

Thanks,

Ed

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@acm.org | office: 407 458 0017
| http://purl.oclc.org/NET/edburns/pgp/

[1] http://www.oracle.com/technetwork/community/oca-486395.html

Anyone have any thoughts on this one? 

Thanks!

Just did some changes: https://github.com/javaserverfaces/javaserverfaces.github.io/pull/2

users@... and dev@... are both replaced by https://javaee.groups.io/g/mojarra/ right?

The "Contribute - How to get involved" link still needs an update. Seems that the Wiki no longer exists...

Regards
Dennis

On Sun, 08 Oct 2017 04:06:34 -0700, "Arjan Tijms" <arjan.tijms@gmail.com> said:

AT> The JSF homepage is quite out of date, mentioning EE 7 is probably one of the least outdated parts :(
AT> I've had it on my TODO to at least somewhat update it for well over 4 months now, but haven't found the time yet...

Yes that's an important PR!

Ed

--
| 33 business days until CodeEurope Poland 2017
| 79 business days until JavaLand 2018
| edward.burns@oracle.com | office: +1 407 458 0017