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 <[email protected]> > 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 > >> > > -- <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/>
