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/BeanManagerProvider.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
