Sorry, but I'm a bit confused now. Which error message are we talking about? I thought you are referring to:
When using the BeanManager to retrieve Beans before the Container is started, non-portable behaviour results! See: https://github.com/apache/incubator-deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/provider/BeanManagerProvider.java#L170 2013/5/11 Christian Beikov <[email protected]> > Am 11.05.2013 00:29, schrieb Mark Struberg: > > Hi folks! >> >> a.) I resolved the MessageBundle stuff already >> > What do you mean by resolved? Is the default implementation now capable of > handling @Named? In which version of DS is/will that (be) included? > > >> b.) You will only see those messages if not in ProjectStage Production >> > Also in DS 0.3? To me it seems pretty straight forward, it just emmits a > warning via a logger... > > 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. >> > Do you have a solution for that I could possibly just pick up? > Unfortunately I am no CDI expert like you and I will probably waste some > hours which you could save me :) > >> >> LieGrue, >> strub >> > > > Mit freundlichen Grüßen, > ------------------------------**------------------------------** > ------------ > *Christian Beikov* > >> >> >> >> ----- Original Message ----- >> >>> From: Christian Beikov <[email protected]> >>> To: >>> deltaspike-users@incubator.**apache.org<[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* >>>>> >>>>> >>>> > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
