Date   

Re: JSF 2.3 Section 5.4.1 question regarding injection

Edward Burns
 

On Tue, 22 Aug 2017 07:18:25 -0700, pnicoluc@us.ibm.com said:
PN> According to the JSF spec section 5.4.1 JSF Managed Classes and Java
PN> EE Annotations, there are a bunch of JSF artifacts eligible for
PN> injection.

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/>?

Hello Paul,

Looking at 5.4.1, there is no specific exclusion for ActionListener or
PhaseListener when they happen to be declared in a Facelet. Indeed,
looking at the code for both tags, I see we simply are just using new.

if (instance == null && type != null) {
try {
instance = (PhaseListener) ReflectionUtil.forName(
this.type).newInstance();
} catch (ClassNotFoundException | InstantiationException |
IllegalAccessException e)

I have opened
<https://github.com/javaee/javaserverfaces-spec/issues/1449>:

I propose we add to the errata an issue excluding these two from having
to be injectable when they are created via a facelet.

Ed

--
| 23 business days until JavaOne 2017
| 103 business days until JavaLand 2018
| edward.burns@oracle.com | office: +1 407 458 0017


JSF 2.3 Table 5-3 JSF artifacts eligible for injection - Constructor Injection question

pnicoluc@...
 

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


https://javaserverfaces.github.io/download.html

Michael Müller
 

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>


Re: https://javaserverfaces.github.io/download.html

Arjan Tijms
 

The JSF homepage is quite out of date, mentioning EE 7 is probably one of the least outdated parts :(

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...


Re: https://javaserverfaces.github.io/download.html

Edward Burns
 

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


Re: https://javaserverfaces.github.io/download.html

Dennis Kieselhorst
 

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


Re: JSF 2.3 Table 5-3 JSF artifacts eligible for injection - Constructor Injection question

pnicoluc@...
 

Anyone have any thoughts on this one? 

Thanks!


Mojarra Pull Requests now and at EE4J

Edward Burns
 

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


Re: New javaserverfaces.com

Neil Griffin
 

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

On 10/31/17 8:05 AM, Josh Juneau wrote:
Hi Kito,
Thanks for doing this!  I really like the look of the updated site.  It provides a fresh and modern feel, and I think it is exactly the face lift that JSF needs.  I personally think it is important to have a user-facing site for JSF, like the one you've created, and still maintain a project spec site separately.  In my opinion, the users of JSF do not necessarily have to get into the nitty gritty details of the specification work, so the sites should be separate, or at a minimum there should be a separate section of the site devoted to the specification work for those who wish to see that level of detail.
Nice work, and I vote for either 1 or 2 in your list.  One question would remain if we chose #2 is if the other specifications for EE4J will be following a similar strategy for their web presence.  It would be good to try and maintain a similar strategy across the platform specs in my opinion.  So if the others are going to choose single location to host spec sites (GitHub perhaps) then JSF should do the same in my opinion.  That is still not yet decided though and I think it will be a while before decisions like that are made.  So in the meantime, I vote for moving forward with a site like the one you've created for the user-facing site.
Josh Juneau
juneau001@gmail.com <mailto:juneau001@gmail.com>
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Tue, Oct 31, 2017 at 6:39 AM, Kito Mann <kito.mann@virtua.com <mailto:kito.mann@virtua.com>> wrote:
Hello,
As many of you know, javaserverfaces.com <http://javaserverfaces.com> has been out of date for quite some time. I had a contractor of mine create a new version of the site using Jekyll and github so we could have something more collaborative and easy to maintain. The first draft of the site is finished, but still needs to be updated with new content and cleaned up a bit: http://dev.javaserverfaces.com. I started this initiative before the EE4J news, in order to give the community an easy way to update the site. However, with the move to EE4J, it's possible the main JSF spec site may be easier for the community to edit collaboritvely. So, basically, I see three options here:
(1) Update javaserverfaces.com <http://javaserverfaces.com> as originally planned; separate from the JSF spec site
(2) Use javaserveraces.com <http://javaserveraces.com> as the starting point for the new JSF spec site once it has been moved to EE4J
(3) Scrap javaserverfaces.com <http://javaserverfaces.com> and update the spec site collaboratively (once it moves to EE4J?)
Thoughts?
___
Kito D. Mann | @kito99
Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Polymer, Web Components, Angular
Virtua, Inc. | virtua.tech <http://virtua.tech>
JSFCentral.com <http://JSFCentral.com> | @jsfcentral
+1 203-998-0403 <tel:(203)%20998-0403>
* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com <http://enterprisejavanews.com/>


New javaserverfaces.com

Kito Mann
 

Hello,

As many of you know, javaserverfaces.com has been out of date for quite some time. I had a contractor of mine create a new version of the site using Jekyll and github so we could have something more collaborative and easy to maintain. The first draft of the site is finished, but still needs to be updated with new content and cleaned up a bit: http://dev.javaserverfaces.com. I started this initiative before the EE4J news, in order to give the community an easy way to update the site. However, with the move to EE4J, it's possible the main JSF spec site may be easier for the community to edit collaboritvely. So, basically, I see three options here:

(1) Update javaserverfaces.com as originally planned; separate from the JSF spec site
(2) Use javaserveraces.com as the starting point for the new JSF spec site once it has been moved to EE4J
(3) Scrap javaserverfaces.com and update the spec site collaboratively (once it moves to EE4J?)

Thoughts?

___

Kito D. Mann | @kito99
Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Polymer, Web Components, Angular
Virtua, Inc. | virtua.tech 
JSFCentral.com | @jsfcentral 

* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com



Re: New javaserverfaces.com

 

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


Re: New javaserverfaces.com

Arjan Tijms
 

Hi,

As for the domain name, I have to agree with Ed and be careful about using anything with the name “java” in it.

Once tEE4J (or whatever name the actual project will get) is fullly established, I’d love to see sub domains being used to somewhat emphasise the correlation between the specs.

Eg 


Etc

(The JSF and jpa names are not decided either but just as placeholder)

Just my 2 cents

Kind regards,
Arjan Tijms


On Tuesday, October 31, 2017, Ed Burns <edburns@...> wrote:
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




Re: New javaserverfaces.com

Kito Mann
 

Hey Ed,

I think it's fair to point out that javaserverfaces.com/org has been up and running for several years without any complaints with Oracle, and that was before all of the Java EE drama of the past few years.

With respect to the spec site, will there be more extensive collaboration before the EE4J move?

___

Kito D. Mann | @kito99
Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Polymer, Web Components, Angular
Virtua, Inc. | virtua.tech 
JSFCentral.com | @jsfcentral 

* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com



On Tue, Oct 31, 2017 at 12:51 PM, Ed Burns <edburns@...> wrote:
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





Re: New javaserverfaces.com

Michael Müller
 

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


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" (available for short time only): https://leanpub.com/jsf
  "Practical JSF in Java EE 8" (from 2018): http://www.apress.com/us/book/9781484230299
  "Java Lambdas and Parallel Streams": http://www.apress.com/de/book/9781484224861
  "Visitors" a photographic image book: https://leanpub.com/visitors


On 02.11.2017 17:26, Arjan Tijms wrote:
Hi,

As for the domain name, I have to agree with Ed and be careful about using anything with the name “java” in it.

Once tEE4J (or whatever name the actual project will get) is fullly established, I’d love to see sub domains being used to somewhat emphasise the correlation between the specs.

Eg 


Etc

(The JSF and jpa names are not decided either but just as placeholder)

Just my 2 cents

Kind regards,
Arjan Tijms

On Tuesday, October 31, 2017, Ed Burns <edburns@...> wrote:
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





Re: New javaserverfaces.com

Kito Mann
 

Ed,

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

___

Kito D. Mann | @kito99
Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Polymer, Web Components, Angular
Virtua, Inc. | virtua.tech 
JSFCentral.com | @jsfcentral 

* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com



On Tue, Oct 31, 2017 at 12:51 PM, Ed Burns <edburns@...> wrote:
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





Re: New javaserverfaces.com

Edward Burns
 

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


Re: JSF 2.3 Section 5.4.1 question regarding injection

Edward Burns
 

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


jsfcentral.com

Kito Mann
 

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 

* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com



Re: jsfcentral.com

reza_rahman <reza_rahman@...>
 

It's definitely time. The site could use a facelift. I know a lot of people that rely on the site as a JSF resource still.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Kito Mann <kito.mann@...>
Date: 11/27/17 8:22 AM (GMT-05:00)
To: jsf-spec@javaee.groups.io
Subject: [jsf-spec] jsfcentral.com

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 

* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com



Re: JSF 2.3 Table 5-3 JSF artifacts eligible for injection - Constructor Injection question

pnicoluc@...
 

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

21 - 40 of 64