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 Sun, 12 May 2013 13:57:05 GMT
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 <christian@kaltepoth.de>
>> To: "deltaspike-users@incubator.apache.org" <deltaspike-users@incubator.apache.org>;
Mark Struberg <struberg@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 <christian@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 <struberg@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 <struberg@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 <christian@kaltepoth.de>
>>>>   >>  To: "deltaspike-users@incubator.apache.org"
>>>>   > <deltaspike-users@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 <christian.beikov@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
>>


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