This comment has been minimized.

edited

I have prepared a copy of codes for Java EE 7, and reverted the dependencies and configurations to Java EE 7 APIs. The codes are almost same, but it works in Java EE 7 and Glassfish v4. The difference is the Java EE version for APIs and configuration.

This comment has been minimized.

Just curious: Have you used @ManagedBean (JSF 2.0) or @Named (JSF 2.2) to give your backing bean a name? And have you used import javax.enterprise.context.*Scoped (JSF 2.2) and not deprecated javax.faces.bean.*Scoped (JSF 2.0). As a mixture of both versions don't work and is a common mistake to only change @ManagedBean to @Named.

This comment has been minimized.

edited

@Andrew-Gr I found the some helpful info from GF issues. Maybe it clarified our confusion, but I think it is a very bad idea when I used JSF 2.3 in a Java EE 8 compatible application server, such as GF v5.

This comment has been minimized.

edited

@xinyuan-zhang Personally I dislike use @FacesConfig to enable CDI as InejctionProvider.

The approaches in development stage was working well.

faces-config.xml version to indicate the JSF version, but I think this version should only affect this config file itself, only indicates if the config xml schema is valid. A higher JSF implementations should be compatible with a lower-versioned faces-config.xml file, eg. mojarra 2.3.x should work well with faces-config.xml 2.2(version="2.2" in the namespace declaration.).

Use javax.faces.ENABLE_CDI_RESOLVER_CHAIN(true) in web.xml to enable CDI as InjectionProvider, I think it should be set to true by default in a Java EE 8 application server. Set it to false explicitly only for those guys who do not want to use CDI to handle injection at the moment.

Remember nowdays all of us like the Convention over Configuration rule in project developments. Currently I migrated my sample from Java EE 7 to Java EE 8 and JSF 2.3, it should work without any modification. But I have to add more configuration to make it work, such as @FacesConfig and change bean-discovery-mode to all, it is unreasonable .

This comment has been minimized.

edited

@hantsy I was able to successfully run the empty "hello world" JSF 2.3.2 app on Payara 5 with the bean-discovery-mode="all" in beans.xml and standalone ConfigurationBean , but once I am configuring my target project with the same settings - I am getting issues with CDI.
Looks like adding @FacesConfig(version = FacesConfig.Version.JSF_2_3) to 'problem' beans partially solves the issue, but other exceptions comes during app deployment like:

WARN: WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.glassfish.jersey.ext.cdi1x.servlet.internal.CdiExternalRequestScope is deprecated from CDI 1.1!
Warning: The following warnings have been detected: WARNING: Parameter interceptedBean of type javax.enterprise.inject.spi.Bean<?> from private javax.enterprise.inject.spi.Bean<?> org.glassfish.soteria.cdi.LoginToContinueInterceptor.interceptedBean is not resolvable to a concrete type.
Warning: The following warnings have been detected: WARNING: Parameter interceptedBean of type javax.enterprise.inject.spi.Bean<?> from private javax.enterprise.inject.spi.Bean<?> org.glassfish.soteria.cdi.RememberMeInterceptor.interceptedBean is not resolvable to a concrete type.
Severe: Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408: Unsatisfied dependencies for type LocaleBean with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject private local.test.beans.PageBean._localeBean
at local.test.beans.PageBean._localeBean(PageBean.java:0)
WELD-001475: The following beans match by type, but none have matching qualifiers:
- Managed Bean [class local.test.beans.LocaleBean] with qualifiers [@Any @FacesConfig @Named]

So now I am trying to understand is it a part of the same issue discussed here, or this is something not related to this topic...
P.S. all changes are done in the absolutely stable code, which works fine in JSF 2.2 mode...

This comment has been minimized.

BTW, It seems mojarra development is inactive in these months, from the Github commit logs, there are no resources on processing issues from reporters.

Indeed, it's a little inactive. Not because of disinterest or anything, but simply a matter of time. I'm personally very busy with preparing Payara 5, of which we're planning to release the first alpha this week.

Especially the Mojarra 2.4 branch was hanging mid-development (I had to flush out my changes when we moved from java.net to GitHub) and it's high on my TODO level to resume that, but there are always higher level items popping up :(

This comment has been minimized.

This comment has been minimized.

edited

@xinyuan-zhang, I didn't see this answered, but I had the same issue, and I worked out why adding @FacesConfig to a bean fixes the CDI issue. Essentially, in CdiExtension's collect method, it looks up all beans with the @FacesConfig annotation on them and, provided that the last bean found with that annotation has its value set to at least Version.JSF_2_3, it sets a flag on itself (CdiExtension) which is checked in a couple of places. In this case, the two important ones are the afterBean method in CdiExtension (where it is referenced as a field) and ELUtils#tryAddCDIELResolver (where it is referenced via the getter).

In CdiExtension#afterBean, it loads the CdiProducer-based implementations of the implicit JSF objects (i.e. "request", "session", etc) if the flag is true. While this does not have a direct effect on loading other beans, it is important when considering the new injection features.

Similarly, in ELUtils#tryAddCDIELResolver, it will only add the CDI BeanManager-based ELResolver if the flag is true. Thus, if the @FacesConfig annotation is not present on at least one resolved bean, the CDI BeanManager-based EL resolver is not added to the chain, and, as a result, any beans that were discovered purely through CDI annotations (i.e. those that are in the BeanManager) will not be resolved.

This comment has been minimized.

The major problem is that JSF 2.3 by default runs in a pseudo JSF 2.2 mode (a kind of JSF 2.2 compatibility mode). To make it truly JSF 2.3 you need to switch it to JSF 2.3 via the @FacesConfig annotation with, indeed, version 2.3.

This comment has been minimized.

edited

@arjantijms is it any plans for JSF 2.3.3 to be release in the nearest future with your latest changes on this? Thanks! Edit: ...ah, I see: JSF 2.3.3 -> Due by October 4, 2017. Okay, look forward to having it released soon! )

This comment has been minimized.

edited

I hope in Java EE 8 compatible environment(eg. Glassfish 5, it was just released) JSF 2.3 should be enabled by default, no need global @FacesConfig or adding it every beans, and also should free my CDI settings (both annotated or all discovery mode should work, in a Java EE 8 application, CDI is not just for JSF ).

And for those cases who want to use JSF 2.3 with Java EE 7 or Servlet 3.1 container, maybe @FacesConfig is an option. Currently I do not care about this case.

This comment has been minimized.

@hantsy first of all thank you for mentioning that GF 5 was released - I haven't noticed that! Re "JSF 2.3 enabled by default in GF 5" - are you sure about that? ) ...didn't have time to check it, will start practicing with GF5 from tomorrow by moving my apps to it.

This comment has been minimized.

I hope in Java EE 8 compatible environment(eg. Glassfish 5, it was just released), JSF 2.3 is enabled by default,

Unfortunately, this is not the case. In a full or web profile Java EE 8 environment the specification says that JSF should by default run into this 2.2 pseudo compatibility mode. I'm personally not a fan of this either. For Payara, but only for Payara, I may be able to make 2.3 the default.

no need global @facesconfig

Don't forget that you always need something to enable JSF. Like a FacesServlet mapping in web.xml, an (empty) faces-config.xml, or the use of any one of the JSF specific annotations.

Next to the empty faces-config.xml, the @FacesConfig annotation is one of the simplest ways to activate JSF. You can have JSF activated with that without any web.xml present.

This comment has been minimized.

edited

The major problem is that JSF 2.3 by default runs in a pseudo JSF 2.2 mode (a kind of JSF 2.2 compatibility mode). To make it truly JSF 2.3 you need to switch it to JSF 2.3 via the @facesconfig annotation with, indeed, version 2.3.

> ~~~JSF 2.3 is fully backward compatible with previous releases of JSF unless a CDI managed bean is included in the application with the annotation @javax.faces.annotation.FacesConfig.~~~
Never mind, it looks like it -is- working as expected when a faces-config.xml with version="2.2" is used; resolving `@Named` beans only stops working when version="2.3" is used without also adding `@FacesConfig`. A bit weird (I'd expect version="2.3" to either activate the 2.3 features, or to do nothing without `@FacesConfig`), but workable.

This comment has been minimized.

@omolenkamp When you change the version to 2.2 in faces-config.xml, all of the new features added in JSF 2.3 are worked(such as websocket, datetime, inject in converter, cdi alignment, el in facelets etc) ?

This comment has been minimized.

@nAmed beans only stops working when version="2.3" is used without also adding @FacesConfig. A bit weird (I'd expect version="2.3" to either activate the 2.3 features, or to do nothing without @FacesConfig), but workable.

That's because of a very unfortunate bug that somehow went unnoticed despite all the testing that we did. I fixed it here: 9662b55

Hoping to release 2.3.3 soon with the help of @ren-zhijun-oracle and @edburns . This bug causes a lot of confusion really. If you have the time, please try building 2.3.3-SNAPSHOT and see if that works for you.

This comment has been minimized.

That should definitely not have any influence. @FacesConfig is an annotation that's only read by a CDI Extension to enable a certain amount of build-in beans. Repeating it for multiple classes should have no effect. You might want to take a look at the Mojarra tests for this feature and see where it differs with your code.