February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2753) Workaround for auditlog syslog appName not being configurable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2753: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1053355|https://bugzilla.redhat.com/show_bug.cgi?id=1053355] from MODIFIED to ON_QA > Workaround for auditlog syslog appName not being configurable > ------------------------------------------------------------- > > Key: WFLY-2753 > URL: https://issues.jboss.org/browse/WFLY-2753 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.CR1 > Reporter: Kyle Lape > Assignee: Kyle Lape > Fix For: 8.0.0.Final > > > Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2668) Cannot execute "ssh $USER@$HOST service wildfly-init-redhat.sh restart" correctly in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2668?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2668: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1044461|https://bugzilla.redhat.com/show_bug.cgi?id=1044461] from MODIFIED to ON_QA > Cannot execute "ssh $USER@$HOST service wildfly-init-redhat.sh restart" correctly in domain mode > ------------------------------------------------------------------------------------------------ > > Key: WFLY-2668 > URL: https://issues.jboss.org/browse/WFLY-2668 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: RHEL 6 > Reporter: Takayuki Konishi > Assignee: Takayuki Konishi > Fix For: 8.0.0.Final > > > WildFly keep grabing a terminal after executing "ssh $USER@$HOST service wildfly-init-redhat.sh restart" in domain mode. > How reproducible: 100% -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2514) Using directory grouping by-type results in the wrong logging.properties file being used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2514?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2514: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1031129|https://bugzilla.redhat.com/show_bug.cgi?id=1031129] from MODIFIED to ON_QA > Using directory grouping by-type results in the wrong logging.properties file being used > ---------------------------------------------------------------------------------------- > > Key: WFLY-2514 > URL: https://issues.jboss.org/browse/WFLY-2514 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.0.0.CR1 > > > When defining servers with {{directory-grouping="by-type"}} the wrong directory is used in the {{ManagedServerBootCmdFactory}}. This causes the {{domain/configuration/logging.properties}} to always be used which is the incorrect configuration to use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2869) Incorrect closing of JMS connections causes subsequent tests to fail

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2869?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2869: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1061678|https://bugzilla.redhat.com/show_bug.cgi?id=1061678] from MODIFIED to ON_QA > Incorrect closing of JMS connections causes subsequent tests to fail > -------------------------------------------------------------------- > > Key: WFLY-2869 > URL: https://issues.jboss.org/browse/WFLY-2869 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.CR1 > Reporter: Jan Martiska > Assignee: Jan Martiska > > RunAsMDBUnitTestCase and GetCallerPrincipalTestCase call stop() to close a JMS connection, which is wrong, it should use close(). This causes the later running AuthenticationTestCase.testAuthentication_ReAuth_ViaServlet (or potentially other tests) to fail due to a timeout, having this in the log: > {noformat} > 0m19:53:28,973 INFO [org.jboss.arquillian.testenricher.cdi.container.BeanManagerProducer] (pool-1-thread-1) BeanManager not found. > [0m[33m19:53:29,218 WARN [org.hornetq.core.client] (Finalizer) HQ212016: I am closing a core ClientSession you left open. Please make sure you close all ClientSessions explicitly before letting them go out of scope! 28,182,273: java.lang.Exception > at org.hornetq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:91) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:912) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:317) > at org.hornetq.jms.client.HornetQConnection.authorize(HornetQConnection.java:648) > at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:676) > at org.hornetq.jms.client.HornetQConnectionFactory.createQueueConnection(HornetQConnectionFactory.java:119) > at org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.testMDBLifecycle(GetCallerPrincipalTestCase.java:300) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) [:1.7.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) [:1.7.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) [:1.7.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) [:1.7.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214) > at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) [:1.7.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) [:1.7.0_45] > at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) [:1.7.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) [rt.jar:1.7.0_45] > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) [rt.jar:1.7.0_45] > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) [rt.jar:1.7.0_45] > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) [rt.jar:1.7.0_45] > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) [rt.jar:1.7.0_45] > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) [rt.jar:1.7.0_45] > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_45] > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) [rt.jar:1.7.0_45] > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1469) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:730) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:952) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45] > at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45] > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager module needs a dependency on javax.mail.api

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1300: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 971076|https://bugzilla.redhat.com/show_bug.cgi?id=971076] from MODIFIED to ON_QA > org.jboss.log4j.logmanager module needs a dependency on javax.mail.api > ---------------------------------------------------------------------- > > Key: WFLY-1300 > URL: https://issues.jboss.org/browse/WFLY-1300 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.0.0.Alpha1 > > > Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-314) EE subsystem global modules should support annotation flag

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-314?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-314: ---------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1009166|https://bugzilla.redhat.com/show_bug.cgi?id=1009166] from MODIFIED to ON_QA > EE subsystem global modules should support annotation flag > ---------------------------------------------------------- > > Key: WFLY-314 > URL: https://issues.jboss.org/browse/WFLY-314 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: EE > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha1 > > > Annotation indexes aren't imported with modules by default, but you can specify the annotation flag in the manifest Dependencies line or the annotation attribute in jboss-deployment-structure.xml. > The EE subsystem's global modules section does not let you specify that option, which means you can't define EJB interceptors and similar things in global modules. It should let you do that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1351) Incorrect exception handling in CoreGroupCommunicationService#handle

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1351?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1351: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 963448|https://bugzilla.redhat.com/show_bug.cgi?id=963448] from MODIFIED to ON_QA > Incorrect exception handling in CoreGroupCommunicationService#handle > -------------------------------------------------------------------- > > Key: WFLY-1351 > URL: https://issues.jboss.org/browse/WFLY-1351 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Dennis Reed > Assignee: Paul Ferraro > Fix For: 8.0.0.Alpha3 > > > org/jboss/as/clustering/impl/CoreGroupCommunicationService#handle catches and hides any internal exceptions, and just returns null instead. > This breaks callers of CoreGroupCommunicationService when they get a null value where it's not expected (after verifying that the response was not flagged as an exception) > java.lang.NullPointerException > at org.jboss.as.clustering.lock.AbstractClusterLockSupport.lock(AbstractClusterLockSupport.java:157) > It also catches an exception from the called method, and returns it as the return value, instead of just throwing it as an exception so it can be properly returned as an exception inside JGroups' RequestCorrelator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2319) LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2319: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1014911|https://bugzilla.redhat.com/show_bug.cgi?id=1014911] from MODIFIED to ON_QA > LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-2319 > URL: https://issues.jboss.org/browse/WFLY-2319 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Beta1 > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Fix For: 8.0.0.Final > > Attachments: LdapSearching.tgz > > > The following code: - > {code} > Hashtable env = new Hashtable(); > env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory"); > env.put("java.naming.security.authentication", "simple"); > env.put("java.naming.provider.url", "ldap://localhost:10389"); > env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system"); > env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret"); > SearchControls ctl = null; > String attrArr[] = new String[1]; > attrArr[0] = "sn"; > ctl = new SearchControls(2, 0L, 0, attrArr, false, false); > String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org"; > String filter = "(uid=UserOne)"; > NamingEnumeration nenum = null; > DirContext ictx = null; > ictx = new InitialDirContext(env); > nenum = ictx.search(base, filter, ctl); > {code} > Results in the following exception: - > {noquote} > 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org' > 13:03:45,599 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025) > 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840) > 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034) > {noquote} > Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works. > The underlying issue is that the default InitialContext implementation contains the following method: - > {code} > protected Context getURLOrDefaultInitCtx(String name) > throws NamingException { > if (NamingManager.hasInitialContextFactoryBuilder()) { > return getDefaultInitCtx(); > } > String scheme = getURLScheme(name); > if (scheme != null) { > Context ctx = NamingManager.getURLContext(scheme, myProps); > if (ctx != null) { > return ctx; > } > } > return getDefaultInitCtx(); > } > {code} > As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-153) Fix logging of "Standard expiration of session X failed; switching to a brute force cleanup. Problem is null"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-153?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-153: ---------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 900552|https://bugzilla.redhat.com/show_bug.cgi?id=900552] from MODIFIED to ON_QA > Fix logging of "Standard expiration of session X failed; switching to a brute force cleanup. Problem is null" > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-153 > URL: https://issues.jboss.org/browse/WFLY-153 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 8.0.0.Alpha2 > > > I am seeing exception with missing reason > {noformat} > 19:54:12,862 WARN [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session 7TYWbrkMf6UGi4WUu2Z3VUam failed; switching to a brute force cleanup. Problem is null > {noformat} > Looks like the actual exception is not well propagated to the message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2513) BDA ID contains absolute the path of the deployment location

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2513?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2513: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1029099|https://bugzilla.redhat.com/show_bug.cgi?id=1029099] from MODIFIED to ON_QA > BDA ID contains absolute the path of the deployment location > ------------------------------------------------------------ > > Key: WFLY-2513 > URL: https://issues.jboss.org/browse/WFLY-2513 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Beta1 > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Fix For: 8.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014