You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "Viggo Navarsete (JIRA)" <ji...@apache.org> on 2011/03/22 13:31:05 UTC
[jira] [Created] (OPENEJB-1449) OpenEJB uses a WELD implementation
that is too verbose on INFO logging, making it look like there are errors
OpenEJB uses a WELD implementation that is too verbose on INFO logging, making it look like there are errors
------------------------------------------------------------------------------------------------------------
Key: OPENEJB-1449
URL: https://issues.apache.org/jira/browse/OPENEJB-1449
Project: OpenEJB
Issue Type: Task
Affects Versions: 3.2
Reporter: Viggo Navarsete
WELD logs the following:
{code}
INFO: Could not install our singleton service
org.apache.webbeans.exception.WebBeansConfigurationException: Already using another custom SingletonService!
at org.apache.webbeans.config.WebBeansFinder.setSingletonService(WebBeansFinder.java:67)
at org.apache.openejb.cdi.CdiBuilder.initializeOWB(CdiBuilder.java:54)
at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:88)
at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:63)
at org.apache.openejb.OpenEJB.init(OpenEJB.java:276)
at org.apache.openejb.OpenEJB.init(OpenEJB.java:255)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
at org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
at org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
at org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at com.tracetracker.mds.adm.business.RbacBeanTest.setUp(RbacBeanTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.Surefire.run(Surefire.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017)
Apache OpenEJB 3.2-SNAPSHOT build: 20110317-07:11
http://openejb.apache.org/
Mar 22, 2011 1:19:03 PM org.apache.openejb.cdi.CdiBuilder build
as INFO! Since this happens (at least for us..) for EVERY test we're running using OpenEJB, it looks like something wrong is happening all the time, and it is confusing. This happens in OpenEJB 3.2-SNAPSHOT.
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENEJB-1449) OpenEJB uses a WELD
implementation that is too verbose on INFO logging, making it look like
there are errors
Posted by "David Blevins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017216#comment-13017216 ]
David Blevins commented on OPENEJB-1449:
----------------------------------------
Got something in there that does it. Very inappropriate but effective. It changes the root logger level from INFO to WARNING.
Anyone know how we could set org.apache.openejb and org.apache.openwebbeans to WARNING level? Seems java.uti.logging does not work like log4j and all loggers are direct children of the root logger. Can't see a way to configure things in the "middle"
> OpenEJB uses a WELD implementation that is too verbose on INFO logging, making it look like there are errors
> ------------------------------------------------------------------------------------------------------------
>
> Key: OPENEJB-1449
> URL: https://issues.apache.org/jira/browse/OPENEJB-1449
> Project: OpenEJB
> Issue Type: Task
> Affects Versions: 4.0
> Reporter: Viggo Navarsete
>
> WELD logs the following:
> {code}
> INFO: Could not install our singleton service
> org.apache.webbeans.exception.WebBeansConfigurationException: Already using another custom SingletonService!
> at org.apache.webbeans.config.WebBeansFinder.setSingletonService(WebBeansFinder.java:67)
> at org.apache.openejb.cdi.CdiBuilder.initializeOWB(CdiBuilder.java:54)
> at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:88)
> at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:63)
> at org.apache.openejb.OpenEJB.init(OpenEJB.java:276)
> at org.apache.openejb.OpenEJB.init(OpenEJB.java:255)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
> at org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
> at javax.naming.InitialContext.init(InitialContext.java:223)
> at javax.naming.InitialContext.<init>(InitialContext.java:197)
> at com.tracetracker.mds.adm.business.RbacBeanTest.setUp(RbacBeanTest.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017)
> Apache OpenEJB 3.2-SNAPSHOT build: 20110317-07:11
> http://openejb.apache.org/
> Mar 22, 2011 1:19:03 PM org.apache.openejb.cdi.CdiBuilder build
> as INFO! Since this happens (at least for us..) for EVERY test we're running using OpenEJB, it looks like something wrong is happening all the time, and it is confusing. This happens in OpenEJB 3.2-SNAPSHOT.
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OPENEJB-1449) OpenEJB uses a WELD implementation
that is too verbose on INFO logging, making it look like there are errors
Posted by "Jean-Louis MONTEIRO (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Louis MONTEIRO closed OPENEJB-1449.
----------------------------------------
Resolution: Invalid
We do not use Weld. We use OpenWebBeans as the CDI implementation. You can configure log level using JUL configuration.
> OpenEJB uses a WELD implementation that is too verbose on INFO logging, making it look like there are errors
> ------------------------------------------------------------------------------------------------------------
>
> Key: OPENEJB-1449
> URL: https://issues.apache.org/jira/browse/OPENEJB-1449
> Project: OpenEJB
> Issue Type: Task
> Affects Versions: 4.0
> Reporter: Viggo Navarsete
>
> WELD logs the following:
> {code}
> INFO: Could not install our singleton service
> org.apache.webbeans.exception.WebBeansConfigurationException: Already using another custom SingletonService!
> at org.apache.webbeans.config.WebBeansFinder.setSingletonService(WebBeansFinder.java:67)
> at org.apache.openejb.cdi.CdiBuilder.initializeOWB(CdiBuilder.java:54)
> at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:88)
> at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:63)
> at org.apache.openejb.OpenEJB.init(OpenEJB.java:276)
> at org.apache.openejb.OpenEJB.init(OpenEJB.java:255)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
> at org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
> at javax.naming.InitialContext.init(InitialContext.java:223)
> at javax.naming.InitialContext.<init>(InitialContext.java:197)
> at com.tracetracker.mds.adm.business.RbacBeanTest.setUp(RbacBeanTest.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017)
> Apache OpenEJB 3.2-SNAPSHOT build: 20110317-07:11
> http://openejb.apache.org/
> Mar 22, 2011 1:19:03 PM org.apache.openejb.cdi.CdiBuilder build
> as INFO! Since this happens (at least for us..) for EVERY test we're running using OpenEJB, it looks like something wrong is happening all the time, and it is confusing. This happens in OpenEJB 3.2-SNAPSHOT.
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira