Managed beans aren't constructed running on JBoss 5.1.0 (works fine with Tomcat 6)

[Max Neves]

Hi everybody,

This is my first post here

I'm migrating an application from Tomcat 6.0.0.20 (working fine) to JBoss 5.1.0 and I'm facing the following problem:
The application starts fine without error but firstly I realized that the functions marked with the notation @PostContruction wasn't being called and then I figured out that the managed beans simply weren't being constructed/initialized.

For example, I have the following managed bean

  
public class Welcome extends BaseBean {
	
	private static final Logger log = Logger
	.getLogger(Welcome.class);
	
	public Welcome() {
	}
	
	@PostConstruct
	public void init() {
		log.debug("hello init");
	}

	public void doSomeThing() {
		// do the job
	}

}

When doSomeThing() is fired, I checked by logs that Welcome isn't created and init() isn't called.

Extract of my faces-config.xml

 
<?xml version="1.0" encoding="UTF-8"?>
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xi="http://www.w3.org/2001/XInclude"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">

  <managed-bean>
  <managed-bean-name>welcome</managed-bean-name>
  <managed-bean-class>com.abc.view.bean.Welcome</managed-bean-class>
  <managed-bean-scope>request</managed-bean-scope>
 </managed-bean>
 

The application uses JSF 1.2 (libraries supplied by JBoss) and RichFaces 3.3.1.

Any thoughts?
Hope anyone can help me.
Thanks

[Tim Holloway]

Welcome to the JavaRanch, Neves!

There's absolutely no reason I can see why you should have this problem, but that's probably because of the things I'm not seeing.

Given your bean definitions and your faces-config snipper, a commandButton with an 'action="#{welcome.doSomething}"' should see the construction of a request-scope object of type Welcome and the firing of the action method.

The only flaw I can see is that you're using inheritance, and there are issues with inheriting annotations, but I don't think that applies in your case, since the annotation is on the inheriting object class.

[Max Neves]

Hi Tim,

Thanks for your reply

Tim Holloway wrote:
There's absolutely no reason I can see why you should have this problem, but that's probably because of the things I'm not seeing.

Yes, that's a weird situation...
The worst thing is I've no clue about what's happening here.

Here's my web.xml used to deploy the application on Tomcat 6:

 
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.5"
 xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
 <display-name>abc</display-name>
 <context-param>
  <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
  <param-value>.xhtml</param-value>
 </context-param>
 <context-param>
  <param-name>facelets.REFRESH_PERIOD</param-name>
  <param-value>1</param-value>
 </context-param>
 <context-param>
  <param-name>facelets.SKIP_COMMENTS</param-name>
  <param-value>true</param-value>
 </context-param>
 
  <!-- Environment  -->
 <context-param>
  <param-name>facelets.DEVELOPMENT</param-name>
  <param-value>true</param-value>
 </context-param>
 <context-param>
  <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
  <param-value>server</param-value>
 </context-param>

 <context-param>
  <param-name>com.sun.faces.enableRestoreViewCompatibility</param-name>
  <param-value>true</param-value>
 </context-param>
  
 <!-- Rich Faces -->
  <context-param>
 		<param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
 		<param-value>com.sun.facelets.FaceletViewHandler</param-value>
 </context-param>
 
 <context-param>
  <param-name>org.richfaces.SKIN</param-name>
  <param-value>blueSky</param-value>
 </context-param>

<!-- Defining and mapping the RichFaces/Ajax4JSF filter -->
 <filter>
  <display-name>Ajax4jsf Filter</display-name>
  <filter-name>ajax4jsf</filter-name>
  <filter-class>org.ajax4jsf.Filter</filter-class>
 </filter>
 <filter-mapping>
  <filter-name>ajax4jsf</filter-name>
  <servlet-name>Faces Servlet</servlet-name>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>FORWARD</dispatcher>
  <dispatcher>INCLUDE</dispatcher>
 </filter-mapping>


 <!-- Authorization filter -->
 <filter>
    <filter-name>userSessionFilter</filter-name>
    <filter-class>com.abc.view.util.AuthorizationFilter</filter-class>
 </filter>
 <filter-mapping>
    <filter-name>userSessionFilter</filter-name>
    <url-pattern>/*</url-pattern>
 </filter-mapping>

  
 <servlet>
  <servlet-name>Faces Servlet</servlet-name>
  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
 </servlet>
 <servlet-mapping>
  <servlet-name>Faces Servlet</servlet-name>
  <url-pattern>*.jsf</url-pattern>
 </servlet-mapping>
 <session-config>
  <session-timeout>10</session-timeout>
 </session-config>
 <welcome-file-list>
  <welcome-file>index.jsp</welcome-file>
 </welcome-file-list>
 <error-page>
  <exception-type>javax.faces.application.ViewExpiredException</exception-type>
  <location>/errorTimeOut.html</location>
 </error-page>
 <security-constraint>
  <display-name>Restrict XHTML files</display-name>
  <web-resource-collection>
   <web-resource-name>XHTML</web-resource-name>
   <url-pattern>*.xhtml</url-pattern>
  </web-resource-collection>
  <auth-constraint>
   <description>Grant access only for developers</description>
   <role-name>developer</role-name>
  </auth-constraint>
 </security-constraint>
 <security-role>
  <description>System developers</description>
  <role-name>developer</role-name>
 </security-role>
</web-app>
 

We use the below web.xml to test on JBoss 5:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
 <display-name>abc</display-name>
 <!-- enabling JBossSerialization -->
 <context-param>
  <param-name>com.sun.faces.serializationProvider</param-name>
  <param-value>org.jboss.web.jsf.integration.serialization.JBossSerializationProvider</param-value>
 </context-param>
 <!-- startup messages -->
 <context-param>
  <param-name>com.sun.faces.displayConfiguration</param-name>
  <param-value>true</param-value>
 </context-param>
 <!-- JSF Config params -->
 <context-param>
  <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
  <param-value>.xhtml</param-value>
 </context-param>
 <context-param>
  <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
  <param-value>server</param-value>
 </context-param>
 <context-param>
  <param-name>facelets.REFRESH_PERIOD</param-name>
  <param-value>1</param-value>
 </context-param>
 <!-- tells to JSF to not render comments in jsf files -->
 <context-param>
  <param-name>facelets.SKIP_COMMENTS</param-name>
  <param-value>true</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.enableRestoreViewCompatibility</param-name>
  <param-value>true</param-value>
 </context-param>
 <!-- Environment  -->
 <context-param>
  <param-name>facelets.DEVELOPMENT</param-name>
  <param-value>true</param-value>
 </context-param>
 <!-- JSF-JBoss config -->
 <context-param>
  <param-name>com.sun.faces.numberOfViewsInSession</param-name>
  <param-value>15</param-value>
 </context-param>
 <context-param>
  <param-name>numberOfLogicalViews</param-name>
  <param-value>15</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.verifyObjects</param-name>
  <param-value>false</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.forceLoadConfiguration</param-name>
  <param-value>false</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.disableVersionTracking</param-name>
  <param-value>false</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.enableHtmlTagLibValidator</param-name>
  <param-value>false</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.preferXHTML</param-name>
  <param-value>false</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.compressViewState</param-name>
  <param-value>true</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.responseBufferSize</param-name>
  <param-value>4096</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.clientStateWriteBufferSize</param-name>
  <param-value>8192</param-value>
 </context-param>
 <context-param>
  <param-name>com.sun.faces.validateXml</param-name>
  <param-value>false</param-value>
 </context-param>
 <context-param>
  <description>Added in Mojarra 1.2_05.  See wiki.jboss.org/wiki/Wiki.jsp?page=UpgradeToMojarra1_2_08</description>
  <param-name>com.sun.faces.enableLazyBeanValidation</param-name>
  <param-value>true</param-value>
 </context-param>
 <context-param>
  <description>Added in Mojarra 1.2_05.  See wiki.jboss.org/wiki/Wiki.jsp?page=UpgradeToMojarra1_2_08</description>
  <param-name>com.sun.faces.enabledLoadBundle11Compatibility</param-name>
  <param-value>false</param-value>
 </context-param>
 <context-param>
  <description>Added in Mojarra 1.2_05.  See wiki.jboss.org/wiki/Wiki.jsp?page=UpgradeToMojarra1_2_08</description>
  <param-name>com.sun.faces.clientStateTimeout</param-name>
  <param-value>none</param-value>
 </context-param>
 <context-param>
  <description>Added in Mojarra 1.2_05.  See wiki.jboss.org/wiki/Wiki.jsp?page=UpgradeToMojarra1_2_08</description>
  <param-name>com.sun.faces.serializeServerState</param-name>
  <param-value>false</param-value>
 </context-param>
 <context-param>
  <description>Added in Mojarra 1.2_08.  See wiki.jboss.org/wiki/Wiki.jsp?page=UpgradeToMojarra1_2_08</description>
  <param-name>com.sun.faces.enableViewStateIdRendering</param-name>
  <param-value>true</param-value>
 </context-param>
 <context-param>
  <description>Added in Mojarra 1.2_08. See wiki.jboss.org/wiki/Wiki.jsp?page=UpgradeToMojarra1_2_08</description>
  <param-name>com.sun.faces.enableScriptsInAttributeValues</param-name>
  <param-value>true</param-value>
 </context-param>
 <context-param>
  <param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
  <param-value>false</param-value>
 </context-param>
 <!-- RichFaces config -->
 <context-param>
  <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
  <param-value>com.sun.facelets.FaceletViewHandler</param-value>
 </context-param>
 <context-param>
  <param-name>org.richfaces.SKIN</param-name>
  <param-value>blueSky</param-value>
 </context-param>
 <filter>
  <display-name>Ajax4jsf Filter</display-name>
  <filter-name>ajax4jsf</filter-name>
  <filter-class>org.ajax4jsf.Filter</filter-class>
 </filter>
 <filter-mapping>
  <filter-name>ajax4jsf</filter-name>
  <servlet-name>Faces Servlet</servlet-name>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>FORWARD</dispatcher>
  <dispatcher>INCLUDE</dispatcher>
 </filter-mapping>
 
 <!-- Authorization filter -->
 <filter>
  <filter-name>userSessionFilter</filter-name>
  <filter-class>com.abc.view.util.AuthorizationFilter</filter-class>
 </filter>
 <filter-mapping>
  <filter-name>userSessionFilter</filter-name>
  <url-pattern>/*</url-pattern>
 </filter-mapping>
 
 <!-- Servelet config -->
 <servlet>
  <servlet-name>Faces Servlet</servlet-name>
  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
 </servlet>
 <servlet-mapping>
  <servlet-name>Faces Servlet</servlet-name>
  <url-pattern>*.jsf</url-pattern>
 </servlet-mapping>
 <session-config>
  <session-timeout>10</session-timeout>
 </session-config>
 <welcome-file-list>
  <welcome-file>index.jsp</welcome-file>
 </welcome-file-list>
 <error-page>
  <exception-type>javax.faces.application.ViewExpiredException</exception-type>
  <location>/errorTimeOut.html</location>
 </error-page>
 <security-constraint>
  <display-name>Restrict XHTML files</display-name>
  <web-resource-collection>
   <web-resource-name>XHTML</web-resource-name>
   <url-pattern>*.xhtml</url-pattern>
  </web-resource-collection>
  <auth-constraint>
   <description>Grant access only for developers</description>
   <role-name>developer</role-name>
  </auth-constraint>
 </security-constraint>
  <security-role>
  <description>System developers</description>
  <role-name>developer</role-name>
 </security-role>
</web-app>

The thing is: no matter what web.xml we use, we get the same problem on managed-beans: neither constructors nor methods flagged with @PostConstruct aren't called.

Given your bean definitions and your faces-config snipper, a commandButton with an 'action="#{welcome.doSomething}"' should see the construction of a request-scope object of type Welcome and the firing of the action method.

We realized this problem with JBoss exactly because whenever we fire a button or hyperlink (having an action=#{welcome.doSomething} like you said), 'doSomething()' manipulates objects that should be initilized on 'init()' and, since it isn't called, we got exceptions. After analizing the logs, we figured out this problem.

The only flaw I can see is that you're using inheritance, and there are issues with inheriting annotations, but I don't think that applies in your case, since the annotation is on the inheriting object class.

I see your point.
We have a managed-bean called 'Login' (the only one session-scoped) which isn't a subclasse of 'BaseBean':

public class Login {

	private static final Logger log = Logger.getLogger(Login.class);

	private String loginUsername;
	private String loginUserpwd;
	private String errorMessage;
	
	public Login() {
		log.debug("Login constructor");
	}

	@PostConstruct
	public void init() {
		log.debug("hello init");
		
		// etc...
	
	}
	
	public String connectUser() {
		// some code
		
		// retrieve the sessionId, debug purposes
		//true = if the session does not exist, getSession create a new one 
		HttpSession httpSession = (HttpSession) FacesContext.getCurrentInstance().getExternalContext().getSession(true);
		log.debug("sessionId = " + httpSession.getId());
	
	// etc...

Well, we runned the application on JBoss, we got the following logs:

13:46:34,088 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)] Started in 1m:38s:245ms
13:47:41,986 INFO  [STDOUT] DEBUG     0 - com.abc.view.bean.Login.<init>(Login.java:29) - Login constructor
13:51:35,822 INFO  [STDOUT] DEBUG233899 - com.abc.view.bean.Login.postIdenfication(Login.java:79) - sessionId = 548FD8FE3310C30DBB40554FBEB2AA45

Running on Tomcat yields:

DEBUG     0 - com.abc.view.bean.Login.<init>(Login.java:29) - Login constructor
DEBUG     0 - com.abc.view.bean.Login.init(Login.java:34) - hello init
DEBUG  4110 - com.abc.view.bean.Login.postIdenfication(Login.java:79) - sessionId = 8ABF83F072786A607BD204E9B763971B

What I concluded so far
I said in the title that the managed beans weren't constructed when deploying on Jboss. It's wrong (thinking in terms of Java, it would be a very weird situation...).
However, the methods flagged with the annotation @PostConstruct aren't called. We don't have this problem with Tomcat.

I'm considering to use the "straighforward" workaround: call my @PostConstruct flagged methods in the constructor.

My reformulated question
Does anyone have any idea about what's going on with @PostConstruct and JBoss?

Thanks a lot
Max

[Kavita Tipnis]

Perhaps the JBoss container is expecting a different @PostConstruct method signature
For Instance , instead of

@PostConstruct
public void init(){
}

@PostConstruct
public void create(){
}

I just remember reading this somewhere, did not have to try it but you can give it a try

[Max Neves]

Hi Kavita, thanks for replying

No, you can give the name you want to the method(s) annotated with @PostConstruct, it doesn't matter.

Anyway, I tried your suggestion and it doesn't work:

 
public class Login {

	private static final Logger log = Logger.getLogger(Login.class);
	
	public Login() {
		log.debug("constructor called");
		this.init(); // workaround !!!!
	}

	@PostConstruct
	public void init() {
		log.debug("hello init");
	}
	
	@PostConstruct
	public void create() {
		log.debug("hello create");
	}
	
	@PostConstruct
	public void foo() {
		log.debug("hello foo");
	}

	// code

	private void postIdenfication() {
	// code

 

When executed on JBoss, the application generates the logs below:

17:00:15,347 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)] Started in 1m:35s:117ms
17:00:30,024 INFO  [STDOUT] DEBUG     0 - com.xxx.view.bean.Login.<init>(Login.java:29) - constructor called
17:00:30,055 INFO  [STDOUT] DEBUG     0 - com.xxx.view.bean.Login.<init>(Login.java:29) - constructor called
17:00:30,055 INFO  [STDOUT] DEBUG    47 - com.xxx.view.bean.Login.init(Login.java:35) - hello init
17:00:30,055 INFO  [STDOUT] DEBUG    47 - com.xxx.view.bean.Login.init(Login.java:35) - hello init
17:00:33,153 INFO  [STDOUT] DEBUG  3145 - com.xxx.view.bean.Login.postIdenfication(Login.java:90) - sessionId = 16493C082EF84AA83D977DA8F2136BF7

Conclusion: the annotation @PostConstruct doesn't work at all

I googled at lot and I wasn't able to find any issue with Jboss and @PostConstruct

Any help will be welcome - I'm confused!

[Kavita Tipnis]

Might sound silly, but do you have an import for PostConstruct?

[Max Neves]

Kavita Tipnis wrote:Might sound silly, but do you have an import for PostConstruct?

Hi, sure I do. If I didn't, the application wouldn't have started.
By the way, I'm using Javax annotations:

import javax.annotation.PostConstruct;

Does JBoss require another "kind" of annotation?
I mean, has JBoss its own annotations?

[Kavita Tipnis]

Sorry, but happened to read that issue somewhere
here is something that might be helpful
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187631#4187631

[Kavita Tipnis]

Ok, it looks like this issue is still prevalent in JBoss, they have suggested an alternate import(org.jboss.seam.annotations.intercept.PostConstruct)
on the one of the issues, but not sure if it resolved the problem, and I don't see the point because you are not using seam anyways.
So you might be better off doing it the old way

[Max Neves]

Hi,

Kavita Tipnis wrote:Sorry, but happened to read that issue somewhere
here is something that might be helpful
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187631#4187631

I read it but I'm not using EJB, so I don't know if the clue applies to my case.

Kavita Tipnis wrote:Ok, it looks like this issue is still prevalent in JBoss, they have suggested an alternate import(org.jboss.seam.annotations.intercept.PostConstruct)
on the one of the issues, but not sure if it resolved the problem, and I don't see the point because you are not using seam anyways.
So you might be better off doing it the old way

I'm not sure neither that using a Seam annotation will solve this problem.
Anyway, even if it does, I'm not using Seam at all and putting Seam in my application "just" to solve that doesn't sound brilliant to me.

I posted this problem on JBoss forum but I got no answer so far.
I'll code a very simple JSF application to run on JBoss to test the @PostConstruct as soon as I can.

Thank you guys.

[Josh Peters]

I've been tackling precisely the same issue; so far I've got nothing too. Please post back if you ever determine your issue.

[Josh Peters]

My issue is solved! I had the JSR 250 api listed as a dependency in my Maven build, and I was distributing the JARs with the WAR project. Changing the scope of that dependency to provided solved my issue.

I've been chewing on that stupid issue for days!

Hope this helps someone else.

[Max Neves]

Josh Peters wrote:My issue is solved! I had the JSR 250 api listed as a dependency in my Maven build, and I was distributing the JARs with the WAR project. Changing the scope of that dependency to provided solved my issue.

I've been chewing on that stupid issue for days!

Hope this helps someone else.

Hi Josh,
I didn't get it, how have you managed to fix the problem? Just by kicking the jsr250 JAR?
My problem is: I dont use jsr250 at all, and so I continue having any idea about how to solve this silly situation

[Josh Peters]

Well, my problem was that both JBoss and my WAR were trying to provide the JSR 250 API. Since I use Maven to build things, my solution was to exclude that JAR from the final result of my build.

Perhaps JBoss doesn't have those jars available to it (are you running on a minimal config server or something more)?

Good luck.