New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<f:view transient="true" /> + org.omnifaces.cdi.ViewScoped instantiating the bean twice #463

Closed
BryanV91 opened this Issue May 4, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@BryanV91

BryanV91 commented May 4, 2018

Problem:

When using <f:view transient="true" /> with one or more beans annotated as org.omnifaces.cdi.ViewScoped all beans in the current view are getting instantiated twice.

Environment:

WildFly 11.0.0.Final
JSF Mojarra 2.3.3
OmniFaces 3.1

Steps to reproduce:

Page:

test.xhtml

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html>
<html lang="es" xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
	xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://xmlns.jcp.org/jsf/html" xmlns:f="http://xmlns.jcp.org/jsf/core">
<h:head id="head">
	<title>HTMC</title>
</h:head>
<h:body id="body">
<f:view transient="true">
	<h:form id="form">
		#{applicationBean}
		<br />
		#{utilityBean}
	</h:form>
</f:view>
</h:body>
</html>

CDI Beans:

ApplicationBean.java

import javax.annotation.PostConstruct;
import org.omnifaces.cdi.ViewScoped;
import javax.inject.Named;

@ViewScoped
@Named
public class ApplicationBean implements Serializable {

        @PostConstruct
	public void startUp() {

		System.out.println("AppBean: " + this);

	}
}

UtilityBean.java

import javax.annotation.PostConstruct;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;

@RequestScoped
@Named
public class UtilityBean implements Serializable {

        @PostConstruct
	public void startUp() {

		System.out.println("UtilityBean: " + this);

	}

}

Output:

17:29:34,541 INFO [stdout] (default task-117) AppBean: coreBeans.ApplicationBean@26d14bec
17:29:34,553 INFO [stdout] (default task-117) UtilityBean: utilities.UtilityBean@229f918c
17:29:34,594 INFO [stdout] (default task-119) AppBean: coreBeans.ApplicationBean@750bc969
17:29:34,599 INFO [stdout] (default task-119) UtilityBean: utilities.UtilityBean@714550db

Capture:

test

Beans don't get instantiated twice when:

We use <f:view transient="false" />
We use javax.faces.view.ViewScoped instead of org.omnifaces.cdi.ViewScoped
We don't use <h:form />

Additional notes:

We already know that ViewScoped's concept is not valid when using <f:view transient="true" />, but it shouldn't instantiate twice those beans.

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC May 15, 2018

Member

Cannot reproduce this.

Curiously in your case the request scoped bean is also instantiated twice.

I strongly suspect classpath pollution with multiple Mojarra libraries. Did you use WildFly-provided Mojarra, or did you install another one via the webapp?

Member

BalusC commented May 15, 2018

Cannot reproduce this.

Curiously in your case the request scoped bean is also instantiated twice.

I strongly suspect classpath pollution with multiple Mojarra libraries. Did you use WildFly-provided Mojarra, or did you install another one via the webapp?

@BryanV91

This comment has been minimized.

Show comment
Hide comment
@BryanV91

BryanV91 May 15, 2018

I strongly suspect classpath pollution with multiple Mojarra libraries. Did you use WildFly-provided Mojarra, or did you install another one via the webapp?

Actually using Mojarra library from server.

13:00:03,523 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 127) Initalizating Mojarra 2.3.3 ( 20171008-2230 673408fa9199477d87f44521ff873d709128c88b) for context '/test'

Curiously in your case the request scoped bean is also instantiated twice.

<f:view transient="true" /> + org.omnifaces.cdi.ViewScoped

Testing with:

13:00:03,329 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 127) Using OmniFaces version 2.0

Beans instantiated once.

Testing with:

13:05:15,423 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 101) Using OmniFaces version 2.2

Beans instantiated once.

Testing with:

13:14:14,502 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 36) Using OmniFaces version 2.3

Beans instantiated once.

Testing with:

13:24:57,701 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 66) Using OmniFaces version 2.5

Beans instantiated once.

Testing with:

13:27:14,921 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 122) Using OmniFaces version 2.5.1

Beans instantiated once.

Testing with:

13:32:41,870 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 127) Using OmniFaces version 2.6 Any clues here?

Beans instantiated twice.

Testing with:

13:35:30,365 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 43) Using OmniFaces version 2.6.7

Beans instantiated twice.

Testing with:

13:37:42,656 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 221) Using OmniFaces version 3.1

Beans instantiated twice.

BryanV91 commented May 15, 2018

I strongly suspect classpath pollution with multiple Mojarra libraries. Did you use WildFly-provided Mojarra, or did you install another one via the webapp?

Actually using Mojarra library from server.

13:00:03,523 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 127) Initalizating Mojarra 2.3.3 ( 20171008-2230 673408fa9199477d87f44521ff873d709128c88b) for context '/test'

Curiously in your case the request scoped bean is also instantiated twice.

<f:view transient="true" /> + org.omnifaces.cdi.ViewScoped

Testing with:

13:00:03,329 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 127) Using OmniFaces version 2.0

Beans instantiated once.

Testing with:

13:05:15,423 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 101) Using OmniFaces version 2.2

Beans instantiated once.

Testing with:

13:14:14,502 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 36) Using OmniFaces version 2.3

Beans instantiated once.

Testing with:

13:24:57,701 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 66) Using OmniFaces version 2.5

Beans instantiated once.

Testing with:

13:27:14,921 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 122) Using OmniFaces version 2.5.1

Beans instantiated once.

Testing with:

13:32:41,870 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 127) Using OmniFaces version 2.6 Any clues here?

Beans instantiated twice.

Testing with:

13:35:30,365 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 43) Using OmniFaces version 2.6.7

Beans instantiated twice.

Testing with:

13:37:42,656 INFO [org.omnifaces.ApplicationInitializer] (ServerService Thread Pool -- 221) Using OmniFaces version 3.1

Beans instantiated twice.

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC May 15, 2018

Member

I think I see what you're getting at.

On initial page load, the bean is instantiated only once. But when you reload the page, the beans are indeed instantiated twice. First one for the unload of the previous page and second one for the refreshed page. This is caused by the unload feature which is indeed basically useless when the view is stateless.

Member

BalusC commented May 15, 2018

I think I see what you're getting at.

On initial page load, the bean is instantiated only once. But when you reload the page, the beans are indeed instantiated twice. First one for the unload of the previous page and second one for the refreshed page. This is caused by the unload feature which is indeed basically useless when the view is stateless.

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC May 15, 2018

Member

Fixed in 2.7-SNAPSHOT and 3.2-SNAPSHOT. It will now skip registering the unload script and instead log a warning.

Member

BalusC commented May 15, 2018

Fixed in 2.7-SNAPSHOT and 3.2-SNAPSHOT. It will now skip registering the unload script and instead log a warning.

@BalusC BalusC closed this May 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment