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] 

<dependency>
  <groupId>javax</groupId>
  <artifactId>javaee-api</artifactId>
  <version>7.0</version>
  <scope>provided</scope>
</dependency>

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

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

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

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.

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.