Skip to content
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

Sporadic deployment issues with Weblogic 12.2.1 #440

Closed
pklog opened this Issue Mar 5, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@pklog
Copy link

commented Mar 5, 2018

We recently started utilizing Omnifaces 2.6.4 in our web application and not soon after started to get random deployment failures which would force us to cycle weblogic to recover. I say random because it seems to be a race condition surrounding when WELD is initialized vs when JSF/Omnifaces is initialized. We found your compatibility matrix in the wiki indicating that 2.4 is the recommended version for WL 12.2.1. We moved to that version and deployments are no longer failing. I created a script that wraps a command line deployment utility and am able to routinely get a failed deployment with versions 2.5+ within 30 attempts. Once we roll back to 2.4, I've cycled through the deployment 60+ times without issue.

I created a basic JSF app that depends on Omnifaces 2.6.4 and Primefaces 6.1 to verify the problem. Looking at the WELD jar that contains SimpleCdi, the manifest reports that it is version 2.3.2.

I think this surrounds WELD because you changed how you get a handle on CDI in org.omnifaces.ApplicationListener between version 2.4 and 2.5.

When a deployment does fail, I get the "NOPE" error from omnifaces explaining the system requirements and the fact that Omnifaces couldn't initialize.

Thanks for any light you can shed on this issue.

The relevant stack is:

java.lang.IllegalArgumentException: CDI BeanManager instance is not available in this environment.
  at org.omnifaces.ApplicationListener.checkCDIImplAvailable(ApplicationListener.java:204)
  at org.omnifaces.ApplicationListener.checkCDI11Available(ApplicationListener.java:118)
  at org.omnifaces.ApplicationListener.contextInitialized(ApplicationListener.java:78)
  at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:705)
  ...
Caused By: java.lang.reflect.InvocationTargetException
  at sun.reflect.GeneratedMethodAccessor1974.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.omnifaces.ApplicationListener.checkCDIImplAvailable(ApplicationListener.java:204)
  ...
Caused By: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328: Unable to identify the correct BeanManager. The calling class sun.reflect.GeneratedMethodAccessor1974 is not placed in bean archive
  at com.goolge.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
  at com.goolge.common.cache.LocalCache.get(LocalCache.java:3937)
  at com.goolge.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
  at com.goolge.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
  at com.goolge.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4830)
  at org.jboss.weld.SimpleCDI.getBeanManager((SimpleCDI.java:105)
  at org.jboss.weld.SimpleCDI.getBeanManager(SimpleCDI.java:38)
  at sun.reflect.GeneratedMethodAccessor1974.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.omnifaces.ApplicationListener.checkCDIImplAvailable(ApplicationListener.java:204)
  ...
Caused By: org.jbos.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class sun.reflect.GeneratedMethodAccessor1974 is not placed in bean archive
  at org.jbos.weld.SimpleCDI.unsatisfiedBeanManager(SimpleCDI.java:89)
  at com.oracle.injection.provider.weld.WlsWeldProvider$WlsEnhancedWeld.unsatisfiedBeanManager(WlsWeldProvider.java:48)
  at org.jboss.weld.SimpleCDI$ClassNameToBeanManager.findBeanManager(SimpleCDI.java:67)
  at org.jboss.weld.SimpleCDI$ClassNameToBeanManager.load(SimpleCDI.java:47)
  at org.jboss.weld.SimpleCDI$ClassNameToBeanManager.load(SimpleCDI.java:40)
  at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527)
  at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2319)
  at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2282)
  at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2197)
  at com.goolge.common.cache.LocalCache.get(LocalCache.java:3937)
  at com.goolge.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
  at com.goolge.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
  at com.goolge.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4830)
  at org.jboss.weld.SimpleCDI.getBeanManager((SimpleCDI.java:105)
  at org.jboss.weld.SimpleCDI.getBeanManager(SimpleCDI.java:38)
  at sun.reflect.GeneratedMethodAccessor1974.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.omnifaces.ApplicationListener.checkCDIImplAvailable(ApplicationListener.java:204)
  ...

@BalusC

This comment has been minimized.

Copy link
Member

commented Mar 24, 2018

Before 2.5 it looks up for CDI BeanManager in JNDI.

After 2.5 it pokes CDI.current().getBeanManager(), which apparently is prone to timing errors in WebLogic (it's not initialized first thing during webapp startup).

Perhaps I'd better add the JNDI lookup back as fallback.

BalusC added a commit that referenced this issue Mar 24, 2018

@BalusC

This comment has been minimized.

Copy link
Member

commented Mar 24, 2018

It's available in today's latest 2.6.9-SNAPSHOT.

Please give it a try and let me know.

@pklog

This comment has been minimized.

Copy link
Author

commented Apr 1, 2018

Hi BalusC, Thanks for working a fix for this. I finally got around to trying this out and it seems to have done the trick, but noticed I never see the log message you added with your change. Do you know how to force Weblogic to log a "FINE" log message? I tried adding org.omnifaces.util=Trace to the server's Logging > General > Logger severity properties configuration, but that doesn't seem to help unless I haven't hit the condition yet. I said "Trace" because that is broadest debug it mentions.

@BalusC BalusC closed this Apr 14, 2018

@BalusC

This comment has been minimized.

Copy link
Member

commented Apr 14, 2018

It's logged via JULI (logging.properties).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.