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:[email protected]]
Gesendet: Sonntag, 12. Mai 2013 15:57
An: [email protected]
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 <[email protected]>
>> To: "[email protected]"
>> <[email protected]>; Mark Struberg
>> <[email protected]>
>> 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 <[email protected]>
>>
>>> @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 <[email protected]>
>>>
>>>> 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 <[email protected]>
>>>> > To: "[email protected]" <
>>>> [email protected]>
>>>> > 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 <[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/BeanM
>> anagerProvider.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
>>>> >>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>
