Date   
Filing for JSF.next?

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

Re: Filing for JSF.next?

Michael Müller
 

Hi Arjan, hi Ed,

personally I would prefer a kind of "continous" specification: Specify topics independently from any Java EE version and deliver the spec and RI as soon as possible.
--

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


Re: Test and what's next?

Neil Griffin
 

Rather than prune the Managed Bean Facility (MBF) entirely, If possible, I would rather see Mojarra and MyFaces extract their MBF implementations into a separate/companion jar. That would provide for a slimmer Faces impl for developers using CDI, yet still provide backwards compatibility for legacy apps.

Re: Test and what's next?

Arjan Tijms
 

Pruning the native managed bean facility would take 2 major releases, and in Mojarra if I understood correctly it would never be truly removed. It's the RI, so after being pruned it's made optional, which means the RI still has to provide an example (reference) implementation for it.

MyFaces would be allowed to drop it totally then.

But yes, I like your idea of trying to extract the MBF into a separate jar. I think we can even do that already outside the spec cycle as an implementation detail.

Re: Test and what's next?

Guillermo González de Agüero
 

Splitting it sounds good so people can create reduced runtimes.

Btw, what about the JSP view facility? Is it already deprecated? That could be another candidate to be moved to another module IMO.

Regards

Guillermo González de Agüero

El sáb., 13 de mayo de 2017 17:47, Arjan Tijms <arjan.tijms@...> escribió:

Pruning the native managed bean facility would take 2 major releases, and in Mojarra if I understood correctly it would never be truly removed. It's the RI, so after being pruned it's made optional, which means the RI still has to provide an example (reference) implementation for it.

MyFaces would be allowed to drop it totally then.

But yes, I like your idea of trying to extract the MBF into a separate jar. I think we can even do that already outside the spec cycle as an implementation detail.

Re: Test and what's next?

Arjan Tijms
 

On Sat, May 13, 2017 at 08:57 am, Guillermo González de Agüero wrote:
Btw, what about the JSP view facility? Is it already deprecated? That could be another candidate to be moved to another module IMO.

It's certainly effectively deprecated. Many newer features are not supported when JSP is used, which is in a way a strategy to slowly phase it out.

But indeed, I love to move that one to a separate module/jar file too so that people can totally exclude it. Some things in JSF (Mojarra at least) are a bit more difficult to exclude as it's interwoven into the code at various places.

Some of the native EL resolvers would be another candidate to move to a legacy module. The pre-UEL support that's still there in JSF would be more difficult to completely remove, as it shows up as (interface) methods in a wide variety of types. Removing that would be a breaking change, which under Java EE rules is not that easy.

 

Re: Test and what's next?

Guillermo González de Agüero
 

Regardinf pre-UEL, are there already alternative methods on thosw interfaces to use UEL? I imagine that would mean a lot of duplication, unless a new interface with the same purpose could be introduced, while deprecating the former one.

That could make it all even bigger, but I'm now thinking about cleaner stacktraces (using only new artifacts) more than in splitted modules.

Do you have a whole list of "legacy/deprecated" JSF features?


Regards,

Guillermo González de Agüero

El sáb., 13 de mayo de 2017 18:02, Arjan Tijms <arjan.tijms@...> escribió:
On Sat, May 13, 2017 at 08:57 am, Guillermo González de Agüero wrote:
Btw, what about the JSP view facility? Is it already deprecated? That could be another candidate to be moved to another module IMO.

It's certainly effectively deprecated. Many newer features are not supported when JSP is used, which is in a way a strategy to slowly phase it out.

But indeed, I love to move that one to a separate module/jar file too so that people can totally exclude it. Some things in JSF (Mojarra at least) are a bit more difficult to exclude as it's interwoven into the code at various places.

Some of the native EL resolvers would be another candidate to move to a legacy module. The pre-UEL support that's still there in JSF would be more difficult to completely remove, as it shows up as (interface) methods in a wide variety of types. Removing that would be a breaking change, which under Java EE rules is not that easy.

 

Re: Test and what's next?

Arjan Tijms
 

On Sat, May 13, 2017 at 10:05 am, Guillermo González de Agüero wrote:
Regardinf pre-UEL, are there already alternative methods on thosw interfaces to use UEL?

There often are indeed, see for example this one:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource.html#getAction--

getAction returns a MethodBinding, which is the deprecated pre-UEL type that everyone desperately wants to get rid off.

It has been replaced by:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource2.html#getActionExpression--

Which in this case is in another interface. There are also cases (in abstract classes mostly) where the deprecated and replacement are in the same class.


Do you have a whole list of "legacy/deprecated" JSF features?

There's an initial list in the JSF spec document itself. At least those things would be a prime candidate to be actually removed, but as said that's not always easy because of Java EE's backward compatibility rules.

In some cases the deprecated methods just sit there and nothing would normally call them. In other cases, unfortunately, they are still called and chained to their replacements, again for backwards compatibility. Those show up in the stack traces and are really not so nice to have around. One example is the ResourceResolver and the ResourceHandler. The resolver is deprecated, but it's still called. See http://arjan-tijms.omnifaces.org/p/jsf-22.html#809

Kind regards,

Arjan Tijms





 

Re: Test and what's next?

Guillermo González de Agüero
 

Hi,

I have a rough idea, not sure how well could it work or if it would even work:

On cases where there are just some methods, create a class that delegates to the deprecated module. For example:

public ActionSource {
    public MethodBinding getAction() {
        return LegacyHelper.callLegacy(ActionSource.class, "getAction", MethodBinding.class, null, this);
    }
}
Parameters are: class, method to be invoked, return class, method parameters and instance to call on.

That method would somehow find the legacy version and call it, only if "mojarra-legacy.jar" classes are present. An UnsupportedOperationException would be thrown otherwise.

For cases when a class/method is used just to maintain BC, I think a "com.sun.jsf.enable_legacy_mode" context-param may be added to disable them. A propietary param would allow it to be done outside of an active JSR. The default value for this param would be false, while the legacy module would enable it with a web-fragment.xml or a ServletContainerInitializer.

JSF.next could state that @JsfConfig.version() >= 2.4 defaults to disabled legacy mode, allowing you to explicitly enable it.

Calls to deprecated classes could be encapsulated in a way like: invokeIfRunningOnLegacyMode(() -> new ResourceResolver().resolve(...));

The main benefit there is for users reading the code, probably trying to find out a bug or learning JSF internals. It is self explanatory that those calls are only for the legacy mode and that you can safely ignore them if you are running on the "modern" mode.

What do you think?


Regards,

Guillermo González de Agüero.

On Sat, May 13, 2017 at 7:22 PM, Arjan Tijms <arjan.tijms@...> wrote:
On Sat, May 13, 2017 at 10:05 am, Guillermo González de Agüero wrote:
Regardinf pre-UEL, are there already alternative methods on thosw interfaces to use UEL?

There often are indeed, see for example this one:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource.html#getAction--

getAction returns a MethodBinding, which is the deprecated pre-UEL type that everyone desperately wants to get rid off.

It has been replaced by:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource2.html#getActionExpression--

Which in this case is in another interface. There are also cases (in abstract classes mostly) where the deprecated and replacement are in the same class.


Do you have a whole list of "legacy/deprecated" JSF features?

There's an initial list in the JSF spec document itself. At least those things would be a prime candidate to be actually removed, but as said that's not always easy because of Java EE's backward compatibility rules.

In some cases the deprecated methods just sit there and nothing would normally call them. In other cases, unfortunately, they are still called and chained to their replacements, again for backwards compatibility. Those show up in the stack traces and are really not so nice to have around. One example is the ResourceResolver and the ResourceHandler. The resolver is deprecated, but it's still called. See http://arjan-tijms.omnifaces.org/p/jsf-22.html#809

Kind regards,

Arjan Tijms





 


Re: Filing for JSF.next?

Arjan Tijms
 

Hi,

It's been a few days, so just a friendly ping ;)

Are there any plans for the next spec cycle of JSF 2.3?

Kind regards,
Arjan Tijms




On Sat, May 13, 2017 at 4:38 PM, Michael Müller <michael.mueller@...> wrote:
Hi Arjan, hi Ed,

personally I would prefer a kind of "continous" specification: Specify topics independently from any Java EE version and deliver the spec and RI as soon as possible.
--

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



Re: Filing for JSF.next?

Michael Müller
 

Hi,

we have to handle a dataportal which is implemented with JSF. Over time, it became a huge gorilla. Since a couple of features are independent from others, I suggested to divide this application into about ten or twelwe and create a "navigation" app which is used to star the correct application. So we like to divide the screen into at least two squares. One to run the navigation app and the other as an edit window which hosts the different apps.

Because Portlets seems to fit for this requirement, I instructed a colleague to evaluate this technique. He reported about a couple of problems and could not get it to run till today. I don't know whether it is really complicated (in conjunction with GlassFish/Payara) or my colleague simply missed something. If it is really complicated, I would appreciate any JSF spec enhancement to run independent JSF apps within one browser window. Optional there should be the ability for a simple inter app communication (more lightweight than JMS).


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


On 05/17/2017 11:45 PM, Arjan Tijms wrote:
Hi,

It's been a few days, so just a friendly ping ;)

Are there any plans for the next spec cycle of JSF 2.3?

Kind regards,
Arjan Tijms




On Sat, May 13, 2017 at 4:38 PM, Michael Müller <michael.mueller@...> wrote:
Hi Arjan, hi Ed,

personally I would prefer a kind of "continous" specification: Specify topics independently from any Java EE version and deliver the spec and RI as soon as possible.
--

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




Re: Filing for JSF.next?

Neil Griffin
 

Hi Michael,

I'd be happy to help you with your evaluation of JSF portlets. What portal product/version are you using with GlassFish?

Neil

On 5/18/17 2:16 PM, Michael Müller wrote:
Hi,
we have to handle a dataportal which is implemented with JSF. Over time, it became a huge gorilla. Since a couple of features are independent from others, I suggested to divide this application into about ten or twelwe and create a "navigation" app which is used to star the correct application. So we like to divide the screen into at least two squares. One to run the navigation app and the other as an edit window which hosts the different apps.
Because Portlets seems to fit for this requirement, I instructed a colleague to evaluate this technique. He reported about a couple of problems and could not get it to run till today. I don't know whether it is really complicated (in conjunction with GlassFish/Payara) or my colleague simply missed something. If it is really complicated, I would appreciate any JSF spec enhancement to run independent JSF apps within one browser window. Optional there should be the ability for a simple inter app communication (more lightweight than JMS).
Herzliche Grüße - Best Regards,
Michael Müller
Brühl, Germany
blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
it-rezension.de <http://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
On 05/17/2017 11:45 PM, Arjan Tijms wrote:
Hi,

It's been a few days, so just a friendly ping ;)

Are there any plans for the next spec cycle of JSF 2.3?

Kind regards,
Arjan Tijms




On Sat, May 13, 2017 at 4:38 PM, Michael Müller <michael.mueller@... <mailto:michael.mueller@...>> wrote:

Hi Arjan, hi Ed,

personally I would prefer a kind of "continous" specification: Specify topics independently from any Java EE version and deliver the spec and RI as soon as possible.
--

Herzliche Grüße - Best Regards,

Michael Müller
Brühl, Germany
blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
it-rezension.de <http://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 <http://www.apress.com/de/book/9781484224861>
"Visitors" a photographic image book: https://leanpub.com/visitors


Re: Test and what's next?

Edward Burns
 

Hello Arjan and list.

Right now our total focus is completing and delivering Java EE 8 and
Java SE 9, and their new capabilities, and we hope to deliver them
this summer. I expect we will have more to say about our overall
Java strategy and plans at JavaOne following Java EE 8/Java SE 9
delivery.

In addition, I also plan to release Mojarra 2.3.1 with support for Servlet 4.0 push and integrate that into GlassFish 5.0.

Ed

JSF 2.3 Section 5.4.1 question regarding injection

pnicoluc@...
 

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

Re: JSF 2.3 Section 5.4.1 question regarding injection

Edward Burns
 

On Tue, 22 Aug 2017 07:18:25 -0700, pnicoluc@... 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
| @edburns | 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@...> 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
| @edburns | 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