Ah oki, well this one is another one, sorry. Was talking about the @Dependent messages with BeanProvider#getContextualReference.
Are there already Jira issues created for the others? Like to solve them before the release. LieGrue, strub ----- Original Message ----- > From: Christian Kaltepoth <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Saturday, 11 May 2013, 10:26 > Subject: Re: BeanManagerProvider polluting logs > > 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 >
