Hi folks! a.) I resolved the MessageBundle stuff already
b.) You will only see those messages if not in ProjectStage Production c.) nope, this message is _not_ useless but rather important! If you do create a @Dependent scoped bean via BeanProvider, then there is a good chance that you end up with a mem leak... For releasing a non-normalscoped bean you will need to take care of it yourself by storing away the CreationalContext. But we don't get this from BeanProvider. The solution is to either rework the code to normal injection, or to keep the CreationalContext. LieGrue, strub ----- Original Message ----- > From: Christian Beikov <[email protected]> > To: [email protected] > Cc: > Sent: Friday, 10 May 2013, 23:44 > Subject: Re: BeanManagerProvider polluting logs > > So is there a workaround for this annoyance? Btw I set > ear-subdeployments-isolated to false, so if that can be the cause for > that it would be nice to know. Not that I would want to set it to true, > but I am just curious about what effect the isolated classloading would > have on the DS when put into EAR/lib. Would the classloading still work > properly? > > Have you looked at my code regarding MessageBundle? I think that there > is something wrong. When the bean is @ApplicationScoped there should be > only one call to BeanLifecycle.create(Bean<T>, CreationalContext<T>) > right? > > Mit freundlichen Grüßen, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 10.05.2013 23:26, schrieb Christian Kaltepoth: >> Hey, >> >> actually I was thinking about whether it would be a good idea to completely >> remove this BeanManagerProvider warning. I doubt that it is very useful. It >> seems to be caused by the fact that AS7 sends the extension events with a >> different context classloader in EAR deployments. I'm note sure if this > is >> a AS7 bug or not, but it seems like many uses are affected by this log >> flooding although the BeanManagerProvider works fine. >> >> Christian >> >> >> >> 2013/5/10 Christian Beikov <[email protected]> >> >>> Hey there, >>> >>> a quick question again. I am facing a problem regarding >>> BeanManagerProvider when deploying my app as EAR with two WARs. The >>> BeanManagerInfo.booted flag seems to be false and therefore it prints > like >>> 200 Messages per HTTP Request into my log file. >>> >>> Deltaspike API and Impl are both in EAR/lib. I am using 0.3-incubating. >>> Furthermore I use JBoss AS 7.1.0.Final which comes with Weld 1.1.5 > AFAIK. >>> >>> I found two main places where the BeanManagerProvider was excessively >>> requested. >>> >>> One of these places is the constructor of my custom > javax.faces.context.**ExceptionHandler. >>> Is it a good idea to cache the ExceptionHandler instance in the >>> javax.faces.context.**ExceptionHandlerFactory? If it was, that would at >>> least reduce the messages a bit for now. >>> >>> The second place I found to be a heavy user of the > BeanManagerProvider.**getInstance() >>> method is in a custom BeanLifcycle class for the MessageBundle beans. > The >>> code there is mostly from PartialBeanLifecycle(the method which is > calling >>> the getInstance() method so often is the createHandlerInstance() > method). I >>> only removed some lines that handeled abstract classes etc. It seems > that >>> although I defined the Bean to be @ApplicationScoped, it gets created > on >>> every access. Maybe I did something wrong in there too? >>> >>> Can anyone help me please? Also see the code I use for the > MessageBundle >>> stuff. >>> >>> MessageBundleBeanLifecycle - http://pastebin.com/4g8HyPqG >>> MessageBundleExtension - http://pastebin.com/Gg48VmaZ >>> MessageBundleInvocationHandler - http://pastebin.com/X6eP0FkG >>> CoreConfigSource - http://pastebin.com/utW2CFka >>> CoreClassDeactivator - http://pastebin.com/C11Pu9L1 >>> >>> Finally the @ApplicationScoped and @Named MessageBundle I use - >>> http://pastebin.com/D2kxNmiR >>> >>> Thanks in advance! >>> >>> -- >>> >>> Mit freundlichen Grüßen, >>> ------------------------------**------------------------------** >>> ------------ >>> *Christian Beikov* >>> >> >> >
