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

Unable to locate BeanManager with Weld on plain Tomcat #243

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

Comments

Projects
None yet
3 participants
@michelepra

michelepra commented Apr 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Apr 30, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@michelepra

michelepra May 2, 2016

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

michelepra commented May 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms May 2, 2016

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!

Member

arjantijms commented May 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC May 2, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC May 21, 2016

Member

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

Fix is available in today's 2.4-SNAPSHOT.

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 added a commit that referenced this issue Jun 3, 2016

BalusC added a commit that referenced this issue Jun 3, 2016

Fix #243: grab Weld BeanManager from ServletContext when not in JNDI
(previous fix was reverted because initialization failed in Payara)
@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Jun 3, 2016

Member

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

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 added a commit that referenced this issue Jun 3, 2016

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.
@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Jun 3, 2016

Member

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.

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 closed this in 09136be Jun 8, 2016

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Jun 8, 2016

Member

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

Member

BalusC commented Jun 8, 2016

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

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