You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by Christian Beikov <ch...@gmail.com> on 2013/05/10 22:24:20 UTC
BeanManagerProvider polluting logs
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*
Re: BeanManagerProvider polluting logs
Posted by Gerhard Petracek <ge...@gmail.com>.
hi @ all,
since it isn't the only issue, we already have [1] for it.
regards,
gerhard
[1] https://issues.apache.org/jira/browse/DELTASPIKE-335
2013/5/11 Mark Struberg <st...@yahoo.de>
> Txs Christian!
>
> Guess it will be hard to create a unit test for this scenario. This would
> require 2 independent webapps in an EAR. Not sure how this would work with
> Arquillian...
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Christian Kaltepoth <ch...@kaltepoth.de>
> > To: "deltaspike-users@incubator.apache.org" <
> deltaspike-users@incubator.apache.org>; Mark Struberg <st...@yahoo.de>
> > Cc:
> > Sent: Saturday, 11 May 2013, 12:36
> > Subject: Re: BeanManagerProvider polluting logs
> >
> > I created an issue to track this:
> >
> > https://issues.apache.org/jira/browse/DELTASPIKE-362
> >
> >
> > 2013/5/11 Christian Kaltepoth <ch...@kaltepoth.de>
> >
> >> @Mark:
> >>
> >> My guess is that AS7 uses some other context classloader for EAR
> >> deployments when sending the AfterBeanDiscovery event. In this case
> looking
> >> up the BeanManager with the webapp's context classloader won't
> > work. Just
> >> an idea.
> >>
> >>
> >>
> >> 2013/5/11 Mark Struberg <st...@yahoo.de>
> >>
> >>> Hi!
> >>>
> >>> Looked at the real thing now ;)
> >>>
> >>> I'm not yet sure why it doesn't work in your case Christian.
> > Actually the
> >>> 'isBooted' flag already gets stored separately for each WAR in
> > the EAR. We
> >>> have a Map<ClassLoader, BeanManagerInfo> for exactly that reason.
> >>>
> >>> I'll be around on IRC working on DS issues in the afternoon if you
> > like
> >>> to ping us for a more in depth analysis.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>> > From: Mark Struberg <st...@yahoo.de>
> >>> > To: "deltaspike-users@incubator.apache.org" <
> >>> deltaspike-users@incubator.apache.org>
> >>> > Cc:
> >>> > Sent: Saturday, 11 May 2013, 10:31
> >>> > Subject: Re: BeanManagerProvider polluting logs
> >>> >
> >>> > 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 <ch...@kaltepoth.de>
> >>> >> To: "deltaspike-users@incubator.apache.org"
> >>> > <de...@incubator.apache.org>
> >>> >> 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 <ch...@gmail.com>
> >>> >>
> >>> >>> 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
> >>> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Christian Kaltepoth
> >> Blog: http://blog.kaltepoth.de/
> >> Twitter: http://twitter.com/chkal
> >> GitHub: https://github.com/chkal
> >>
> >>
> >
> >
> > --
> > Christian Kaltepoth
> > Blog: http://blog.kaltepoth.de/
> > Twitter: http://twitter.com/chkal
> > GitHub: https://github.com/chkal
> >
>
Re: BeanManagerProvider polluting logs
Posted by Christian Beikov <ch...@gmail.com>.
Thanks! I already thought of that too, but also wanted to report the issue.
It could have been that i configured something wrong but as it turns out
not.
2013/5/13 Maik Ebert <m....@paysafecard.com>
> Hi,
>
> Just for your information. We face the same problem.
>
> We now deactivated the logs for BeanMangerProvider like this:
> <logger
> category="org.apache.deltaspike.core.api.provider.BeanManagerProvider">
> <level name="ERROR"/>
> </logger>
>
> That's okay because the BeanManagerProvider does only log that one
> message. So we do not hide anything important at the moment.
> But it nevertheless feels like a workaround.
>
> Greetings,
>
> Maik
> -----Ursprüngliche Nachricht-----
> Von: Christian Beikov [mailto:christian.beikov@gmail.com]
> Gesendet: Sonntag, 12. Mai 2013 15:57
> An: deltaspike-users@incubator.apache.org
> Betreff: Re: BeanManagerProvider polluting logs
>
> You can set which Webapp is the one that should be used for testing for an
> EAR, so it shouldn't be a problem.
> Look at the Testable class:
>
> |@Deployment
> static EnterpriseArchive create() {
> return ShrinkWrap.create(EnterpriseArchive.class)
> .addAsModule(...some..war..)
> .addAsModule(
> Testable.archiveToTest(
> ShrinkWrap.create(WebArchive.class)
> .addXYZ(...)
> )
> );
> }|
>
>
>
> Mit freundlichen Grüßen,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 11.05.2013 12:46, schrieb Mark Struberg:
> > Txs Christian!
> >
> > Guess it will be hard to create a unit test for this scenario. This
> would require 2 independent webapps in an EAR. Not sure how this would work
> with Arquillian...
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Christian Kaltepoth <ch...@kaltepoth.de>
> >> To: "deltaspike-users@incubator.apache.org"
> >> <de...@incubator.apache.org>; Mark Struberg
> >> <st...@yahoo.de>
> >> Cc:
> >> Sent: Saturday, 11 May 2013, 12:36
> >> Subject: Re: BeanManagerProvider polluting logs
> >>
> >> I created an issue to track this:
> >>
> >> https://issues.apache.org/jira/browse/DELTASPIKE-362
> >>
> >>
> >> 2013/5/11 Christian Kaltepoth <ch...@kaltepoth.de>
> >>
> >>> @Mark:
> >>>
> >>> My guess is that AS7 uses some other context classloader for EAR
> >>> deployments when sending the AfterBeanDiscovery event. In this case
> looking
> >>> up the BeanManager with the webapp's context classloader won't
> >> work. Just
> >>> an idea.
> >>>
> >>>
> >>>
> >>> 2013/5/11 Mark Struberg <st...@yahoo.de>
> >>>
> >>>> Hi!
> >>>>
> >>>> Looked at the real thing now ;)
> >>>>
> >>>> I'm not yet sure why it doesn't work in your case Christian.
> >> Actually the
> >>>> 'isBooted' flag already gets stored separately for each WAR in
> >> the EAR. We
> >>>> have a Map<ClassLoader, BeanManagerInfo> for exactly that reason.
> >>>>
> >>>> I'll be around on IRC working on DS issues in the afternoon if
> >>>> you
> >> like
> >>>> to ping us for a more in depth analysis.
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>> > From: Mark Struberg <st...@yahoo.de>
> >>>> > To: "deltaspike-users@incubator.apache.org" <
> >>>> deltaspike-users@incubator.apache.org>
> >>>> > Cc:
> >>>> > Sent: Saturday, 11 May 2013, 10:31
> >>>> > Subject: Re: BeanManagerProvider polluting logs
> >>>> >
> >>>> > 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 <ch...@kaltepoth.de>
> >>>> >> To: "deltaspike-users@incubator.apache.org"
> >>>> > <de...@incubator.apache.org>
> >>>> >> 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/BeanM
> >> anagerProvider.java#L170
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> 2013/5/11 Christian Beikov <ch...@gmail.com>
> >>>> >>
> >>>> >>> 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
> >>>> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Christian Kaltepoth
> >>> Blog: http://blog.kaltepoth.de/
> >>> Twitter: http://twitter.com/chkal
> >>> GitHub: https://github.com/chkal
> >>>
> >>>
> >>
> >> --
> >> Christian Kaltepoth
> >> Blog: http://blog.kaltepoth.de/
> >> Twitter: http://twitter.com/chkal
> >> GitHub: https://github.com/chkal
> >>
>
>
--
<br/>
<br/>
Mit freundlichen Grüßen,<br/>
<hr/>
<b>Christian Beikov</b><br/>
Blazebit Design & Developing<br/>
<a href="http://www.blazebit.com">http://www.blazebit.com</a><br/>
AW: BeanManagerProvider polluting logs
Posted by Maik Ebert <m....@paysafecard.com>.
Hi,
Just for your information. We face the same problem.
We now deactivated the logs for BeanMangerProvider like this:
<logger category="org.apache.deltaspike.core.api.provider.BeanManagerProvider">
<level name="ERROR"/>
</logger>
That's okay because the BeanManagerProvider does only log that one message. So we do not hide anything important at the moment.
But it nevertheless feels like a workaround.
Greetings,
Maik
-----Ursprüngliche Nachricht-----
Von: Christian Beikov [mailto:christian.beikov@gmail.com]
Gesendet: Sonntag, 12. Mai 2013 15:57
An: deltaspike-users@incubator.apache.org
Betreff: Re: BeanManagerProvider polluting logs
You can set which Webapp is the one that should be used for testing for an EAR, so it shouldn't be a problem.
Look at the Testable class:
|@Deployment
static EnterpriseArchive create() {
return ShrinkWrap.create(EnterpriseArchive.class)
.addAsModule(...some..war..)
.addAsModule(
Testable.archiveToTest(
ShrinkWrap.create(WebArchive.class)
.addXYZ(...)
)
);
}|
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 11.05.2013 12:46, schrieb Mark Struberg:
> Txs Christian!
>
> Guess it will be hard to create a unit test for this scenario. This would require 2 independent webapps in an EAR. Not sure how this would work with Arquillian...
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Christian Kaltepoth <ch...@kaltepoth.de>
>> To: "deltaspike-users@incubator.apache.org"
>> <de...@incubator.apache.org>; Mark Struberg
>> <st...@yahoo.de>
>> Cc:
>> Sent: Saturday, 11 May 2013, 12:36
>> Subject: Re: BeanManagerProvider polluting logs
>>
>> I created an issue to track this:
>>
>> https://issues.apache.org/jira/browse/DELTASPIKE-362
>>
>>
>> 2013/5/11 Christian Kaltepoth <ch...@kaltepoth.de>
>>
>>> @Mark:
>>>
>>> My guess is that AS7 uses some other context classloader for EAR
>>> deployments when sending the AfterBeanDiscovery event. In this case looking
>>> up the BeanManager with the webapp's context classloader won't
>> work. Just
>>> an idea.
>>>
>>>
>>>
>>> 2013/5/11 Mark Struberg <st...@yahoo.de>
>>>
>>>> Hi!
>>>>
>>>> Looked at the real thing now ;)
>>>>
>>>> I'm not yet sure why it doesn't work in your case Christian.
>> Actually the
>>>> 'isBooted' flag already gets stored separately for each WAR in
>> the EAR. We
>>>> have a Map<ClassLoader, BeanManagerInfo> for exactly that reason.
>>>>
>>>> I'll be around on IRC working on DS issues in the afternoon if
>>>> you
>> like
>>>> to ping us for a more in depth analysis.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> > From: Mark Struberg <st...@yahoo.de>
>>>> > To: "deltaspike-users@incubator.apache.org" <
>>>> deltaspike-users@incubator.apache.org>
>>>> > Cc:
>>>> > Sent: Saturday, 11 May 2013, 10:31
>>>> > Subject: Re: BeanManagerProvider polluting logs
>>>> >
>>>> > 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 <ch...@kaltepoth.de>
>>>> >> To: "deltaspike-users@incubator.apache.org"
>>>> > <de...@incubator.apache.org>
>>>> >> 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/BeanM
>> anagerProvider.java#L170
>>>> >>
>>>> >>
>>>> >>
>>>> >> 2013/5/11 Christian Beikov <ch...@gmail.com>
>>>> >>
>>>> >>> 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
>>>> >>>>
>>>>
>>>
>>>
>>> --
>>> Christian Kaltepoth
>>> Blog: http://blog.kaltepoth.de/
>>> Twitter: http://twitter.com/chkal
>>> GitHub: https://github.com/chkal
>>>
>>>
>>
>> --
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
Re: BeanManagerProvider polluting logs
Posted by Christian Beikov <ch...@gmail.com>.
You can set which Webapp is the one that should be used for testing for
an EAR, so it shouldn't be a problem.
Look at the Testable class:
|@Deployment
static EnterpriseArchive create() {
return ShrinkWrap.create(EnterpriseArchive.class)
.addAsModule(...some..war..)
.addAsModule(
Testable.archiveToTest(
ShrinkWrap.create(WebArchive.class)
.addXYZ(...)
)
);
}|
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 11.05.2013 12:46, schrieb Mark Struberg:
> Txs Christian!
>
> Guess it will be hard to create a unit test for this scenario. This would require 2 independent webapps in an EAR. Not sure how this would work with Arquillian...
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Christian Kaltepoth <ch...@kaltepoth.de>
>> To: "deltaspike-users@incubator.apache.org" <de...@incubator.apache.org>; Mark Struberg <st...@yahoo.de>
>> Cc:
>> Sent: Saturday, 11 May 2013, 12:36
>> Subject: Re: BeanManagerProvider polluting logs
>>
>> I created an issue to track this:
>>
>> https://issues.apache.org/jira/browse/DELTASPIKE-362
>>
>>
>> 2013/5/11 Christian Kaltepoth <ch...@kaltepoth.de>
>>
>>> @Mark:
>>>
>>> My guess is that AS7 uses some other context classloader for EAR
>>> deployments when sending the AfterBeanDiscovery event. In this case looking
>>> up the BeanManager with the webapp's context classloader won't
>> work. Just
>>> an idea.
>>>
>>>
>>>
>>> 2013/5/11 Mark Struberg <st...@yahoo.de>
>>>
>>>> Hi!
>>>>
>>>> Looked at the real thing now ;)
>>>>
>>>> I'm not yet sure why it doesn't work in your case Christian.
>> Actually the
>>>> 'isBooted' flag already gets stored separately for each WAR in
>> the EAR. We
>>>> have a Map<ClassLoader, BeanManagerInfo> for exactly that reason.
>>>>
>>>> I'll be around on IRC working on DS issues in the afternoon if you
>> like
>>>> to ping us for a more in depth analysis.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> > From: Mark Struberg <st...@yahoo.de>
>>>> > To: "deltaspike-users@incubator.apache.org" <
>>>> deltaspike-users@incubator.apache.org>
>>>> > Cc:
>>>> > Sent: Saturday, 11 May 2013, 10:31
>>>> > Subject: Re: BeanManagerProvider polluting logs
>>>> >
>>>> > 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 <ch...@kaltepoth.de>
>>>> >> To: "deltaspike-users@incubator.apache.org"
>>>> > <de...@incubator.apache.org>
>>>> >> 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 <ch...@gmail.com>
>>>> >>
>>>> >>> 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
>>>> >>>>
>>>>
>>>
>>>
>>> --
>>> Christian Kaltepoth
>>> Blog: http://blog.kaltepoth.de/
>>> Twitter: http://twitter.com/chkal
>>> GitHub: https://github.com/chkal
>>>
>>>
>>
>> --
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
Re: BeanManagerProvider polluting logs
Posted by Mark Struberg <st...@yahoo.de>.
Txs Christian!
Guess it will be hard to create a unit test for this scenario. This would require 2 independent webapps in an EAR. Not sure how this would work with Arquillian...
LieGrue,
strub
----- Original Message -----
> From: Christian Kaltepoth <ch...@kaltepoth.de>
> To: "deltaspike-users@incubator.apache.org" <de...@incubator.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Saturday, 11 May 2013, 12:36
> Subject: Re: BeanManagerProvider polluting logs
>
> I created an issue to track this:
>
> https://issues.apache.org/jira/browse/DELTASPIKE-362
>
>
> 2013/5/11 Christian Kaltepoth <ch...@kaltepoth.de>
>
>> @Mark:
>>
>> My guess is that AS7 uses some other context classloader for EAR
>> deployments when sending the AfterBeanDiscovery event. In this case looking
>> up the BeanManager with the webapp's context classloader won't
> work. Just
>> an idea.
>>
>>
>>
>> 2013/5/11 Mark Struberg <st...@yahoo.de>
>>
>>> Hi!
>>>
>>> Looked at the real thing now ;)
>>>
>>> I'm not yet sure why it doesn't work in your case Christian.
> Actually the
>>> 'isBooted' flag already gets stored separately for each WAR in
> the EAR. We
>>> have a Map<ClassLoader, BeanManagerInfo> for exactly that reason.
>>>
>>> I'll be around on IRC working on DS issues in the afternoon if you
> like
>>> to ping us for a more in depth analysis.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> > From: Mark Struberg <st...@yahoo.de>
>>> > To: "deltaspike-users@incubator.apache.org" <
>>> deltaspike-users@incubator.apache.org>
>>> > Cc:
>>> > Sent: Saturday, 11 May 2013, 10:31
>>> > Subject: Re: BeanManagerProvider polluting logs
>>> >
>>> > 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 <ch...@kaltepoth.de>
>>> >> To: "deltaspike-users@incubator.apache.org"
>>> > <de...@incubator.apache.org>
>>> >> 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 <ch...@gmail.com>
>>> >>
>>> >>> 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
>>> >>>>
>>>
>>
>>
>>
>> --
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
>>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
Re: BeanManagerProvider polluting logs
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
I created an issue to track this:
https://issues.apache.org/jira/browse/DELTASPIKE-362
2013/5/11 Christian Kaltepoth <ch...@kaltepoth.de>
> @Mark:
>
> My guess is that AS7 uses some other context classloader for EAR
> deployments when sending the AfterBeanDiscovery event. In this case looking
> up the BeanManager with the webapp's context classloader won't work. Just
> an idea.
>
>
>
> 2013/5/11 Mark Struberg <st...@yahoo.de>
>
>> Hi!
>>
>> Looked at the real thing now ;)
>>
>> I'm not yet sure why it doesn't work in your case Christian. Actually the
>> 'isBooted' flag already gets stored separately for each WAR in the EAR. We
>> have a Map<ClassLoader, BeanManagerInfo> for exactly that reason.
>>
>> I'll be around on IRC working on DS issues in the afternoon if you like
>> to ping us for a more in depth analysis.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>> > From: Mark Struberg <st...@yahoo.de>
>> > To: "deltaspike-users@incubator.apache.org" <
>> deltaspike-users@incubator.apache.org>
>> > Cc:
>> > Sent: Saturday, 11 May 2013, 10:31
>> > Subject: Re: BeanManagerProvider polluting logs
>> >
>> > 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 <ch...@kaltepoth.de>
>> >> To: "deltaspike-users@incubator.apache.org"
>> > <de...@incubator.apache.org>
>> >> 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 <ch...@gmail.com>
>> >>
>> >>> 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
>> >>>>
>>
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
Re: BeanManagerProvider polluting logs
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
@Mark:
My guess is that AS7 uses some other context classloader for EAR
deployments when sending the AfterBeanDiscovery event. In this case looking
up the BeanManager with the webapp's context classloader won't work. Just
an idea.
2013/5/11 Mark Struberg <st...@yahoo.de>
> Hi!
>
> Looked at the real thing now ;)
>
> I'm not yet sure why it doesn't work in your case Christian. Actually the
> 'isBooted' flag already gets stored separately for each WAR in the EAR. We
> have a Map<ClassLoader, BeanManagerInfo> for exactly that reason.
>
> I'll be around on IRC working on DS issues in the afternoon if you like to
> ping us for a more in depth analysis.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Mark Struberg <st...@yahoo.de>
> > To: "deltaspike-users@incubator.apache.org" <
> deltaspike-users@incubator.apache.org>
> > Cc:
> > Sent: Saturday, 11 May 2013, 10:31
> > Subject: Re: BeanManagerProvider polluting logs
> >
> > 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 <ch...@kaltepoth.de>
> >> To: "deltaspike-users@incubator.apache.org"
> > <de...@incubator.apache.org>
> >> 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 <ch...@gmail.com>
> >>
> >>> 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
> >>>>
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
Re: BeanManagerProvider polluting logs
Posted by Mark Struberg <st...@yahoo.de>.
Hi!
Looked at the real thing now ;)
I'm not yet sure why it doesn't work in your case Christian. Actually the 'isBooted' flag already gets stored separately for each WAR in the EAR. We have a Map<ClassLoader, BeanManagerInfo> for exactly that reason.
I'll be around on IRC working on DS issues in the afternoon if you like to ping us for a more in depth analysis.
LieGrue,
strub
----- Original Message -----
> From: Mark Struberg <st...@yahoo.de>
> To: "deltaspike-users@incubator.apache.org" <de...@incubator.apache.org>
> Cc:
> Sent: Saturday, 11 May 2013, 10:31
> Subject: Re: BeanManagerProvider polluting logs
>
> 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 <ch...@kaltepoth.de>
>> To: "deltaspike-users@incubator.apache.org"
> <de...@incubator.apache.org>
>> 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 <ch...@gmail.com>
>>
>>> 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
>>>>
Re: BeanManagerProvider polluting logs
Posted by Mark Struberg <st...@yahoo.de>.
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 <ch...@kaltepoth.de>
> To: "deltaspike-users@incubator.apache.org" <de...@incubator.apache.org>
> 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 <ch...@gmail.com>
>
>> 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 <ch...@gmail.com>
>>>> To:
> deltaspike-users@incubator.**apache.org<de...@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 <ch...@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*
>>>>>>
>>>>>>
>>>>>
>>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
Re: BeanManagerProvider polluting logs
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
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 <ch...@gmail.com>
> 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 <ch...@gmail.com>
>>> To: deltaspike-users@incubator.**apache.org<de...@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 <ch...@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*
>>>>>
>>>>>
>>>>
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
Re: BeanManagerProvider polluting logs
Posted by Christian Beikov <ch...@gmail.com>.
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 <ch...@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 <ch...@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*
>>>>
>>>
Re: BeanManagerProvider polluting logs
Posted by Mark Struberg <st...@yahoo.de>.
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 <ch...@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 <ch...@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*
>>>
>>
>>
>
Re: BeanManagerProvider polluting logs
Posted by Christian Beikov <ch...@gmail.com>.
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 <ch...@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*
>>
>
>
Re: BeanManagerProvider polluting logs
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
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 <ch...@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*
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal