deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Beikov <>
Subject Re: BeanManagerProvider polluting logs
Date Fri, 10 May 2013 23:21:06 GMT
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
> 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 <>
>> To:
>> 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 <>
>>>>   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
>>>>   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 -
>>>>   MessageBundleExtension -
>>>>   MessageBundleInvocationHandler -
>>>>   CoreConfigSource -
>>>>   CoreClassDeactivator -
>>>>   Finally the @ApplicationScoped and @Named MessageBundle I use -
>>>>   Thanks in advance!
>>>>   --
>>>>   Mit freundlichen Grüßen,
>>>>   ------------------------------**------------------------------**
>>>>   ------------
>>>>   *Christian Beikov*

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message