Unable to locate BeanManager with Weld on plain Tomcat #243

Closed
michelepra opened this Issue Apr 29, 2016 · 8 comments

Projects

None yet

3 participants

@michelepra

like this mojarra issue omnifaces is unable to locate BeanManager.
I made a patch to solve this issue that is like mojarra code in file com.sun.faces.util.Util.java accepted patch.

Map<String, Object> applicationMap = facesContext.getExternalContext().getApplicationMap();
result = (BeanManager) applicationMap.get("org.jboss.weld.environment.servlet.javax.enterprise.inject.spi.BeanManager");

@BalusC
Member
BalusC commented Apr 30, 2016

I will add this, but the correct solution, however, is to register bean manager in JNDI via /META-INF/context.xml.

@michelepra

I agree with you that correct solution is register bean manager in JNDI, but sometimes (like mojarra issue say) JNDI fail to detect.
For example try with an empty maven project with all depedency required by omnifaces, set jetty-maven-plugin with correct configuration for using weld in particular set bean manager in JNDI (you can use listener or other jetty specific file configuration). Run goal jetty:run and you can see that bean manager is not retrived by JNDI, with jetty:run-war bean manager was correctly detected.
I don't know if this is only a jetty-maven-plugin (or tomcat) issue but there is a reason why developers of mojarra accepted this workaround as valid solution.

I hope you add this soon. Thanks

@arjantijms
Member

I don't know if this is only a jetty-maven-plugin (or tomcat) issue but there is a reason why developers of mojarra accepted this workaround as valid solution.

Thanks for mentioning that. (btw we are also among the developers of Mojarra ;))

If possible, could you also try to address the issue with the developers of the jetty-maven-plugin? If it's also fixed there this would increase the chances of it working for anyone greatly. Thanks again!

@BalusC
Member
BalusC commented May 2, 2016

Same problem happens with Tomcat when you incorrectly use tomcat:run instead of tomcat:run-war. Moreover, CDI bean management and injection wouldn't work at all in many cases, resulting in PropertyNotFoundException: Target unreachable over all place.

@BalusC BalusC closed this in 4b9ff42 May 21, 2016
@BalusC
Member
BalusC commented May 21, 2016

Implemented, OmniFaces does now not anymore require /META-INF/context.xml on Tomcat+Weld.

Fix is available in today's 2.4-SNAPSHOT.

@BalusC BalusC added a commit that referenced this issue Jun 3, 2016
@BalusC BalusC Revert "Fix #243: grab Weld BeanManager from ServletContext when not …
…in JNDI"

This reverts commit 4b9ff42.
1d4d0ed
@BalusC BalusC added a commit that referenced this issue Jun 3, 2016
@BalusC BalusC Fix #243: grab Weld BeanManager from ServletContext when not in JNDI
(previous fix was reverted because initialization failed in Payara)
f222550
@BalusC
Member
BalusC commented Jun 3, 2016

It caused a mysterious initialization fail in Payara. The ApplicationListener was completely skipped. I have therefore reverted the fix and implemented an alternate fix (which is more clean after all).

@BalusC BalusC added a commit that referenced this issue Jun 3, 2016
@BalusC BalusC Revert "Fix #243: grab Weld BeanManager from ServletContext when not …
…in JNDI (previous fix was reverted because initialization failed in Payara)"

This reverts commit f222550.
8f0e2e7
@BalusC
Member
BalusC commented Jun 3, 2016

The alternate fix caused a deploy fail in WildFly as it violated a servlet spec "Programmatically added Listener is not allowed to programmatically register Filters/Servlets". The ApplicationListener is now back to @WebListener, but there will be no FacesContext available as it runs before JSF's own listener and then there will be also no ServletContext (which the alternate fix was relying on).

I will look back later.

@BalusC BalusC reopened this Jun 3, 2016
@BalusC BalusC added a commit that closed this issue Jun 8, 2016
@BalusC BalusC Fix #243: finally a solution which works for all servers.
Tested in Payara 4.1.1.161, Tomcat 8.0.35, WildFly 10.0.0.
09136be
@BalusC BalusC closed this in 09136be Jun 8, 2016
@BalusC
Member
BalusC commented Jun 8, 2016

Today's latest 2.4-SNAPSHOT with the fix works now in Tomcat/Payara/WildFly.

@BalusC BalusC added a commit that referenced this issue Jun 18, 2016
@BalusC BalusC #243: remove unnecessary check. 3a332d4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment