deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Beikov <christian.bei...@gmail.com>
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
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 <christian.beikov@gmail.com>
>> To: deltaspike-users@incubator.apache.org
>> 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 <christian.beikov@gmail.com>
>>>
>>>>   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*
>>>>
>>>


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