February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2047) testConnection should account for deployment classloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2047?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2047: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1007181|https://bugzilla.redhat.com/show_bug.cgi?id=1007181] from MODIFIED to ON_QA > testConnection should account for deployment classloader > -------------------------------------------------------- > > Key: WFLY-2047 > URL: https://issues.jboss.org/browse/WFLY-2047 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Alpha4 > Environment: All > Reporter: Jay Kumar SenSharma > Assignee: Stefano Maestri > Fix For: 9.0.0.CR1 > > > If a DataSource is created as following: > ++++++++++++++++ > <datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true"> > <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url> > <driver>oracle</driver> > <pool> > <min-pool-size>1</min-pool-size> > <max-pool-size>15</max-pool-size> > </pool> > <security> > <user-name>Test</user-name> > <password>testPassword</password> > </security> > </datasource> > <drivers> > <driver name="oracle" module="com.oracle.jdbc6"> > <driver-class>oracle.jdbc.driver.OracleDriver</driver-class> > </driver> > <driver name="h2" module="com.h2database.h2"> > <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class> > </driver> > </drivers> > ++++++++++++++++ > Then while testing the DataSource the Wildfly throws the following Exception: > +++++++++++++++++++++ > 16:47:10,498 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21] > at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final] > Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base)) > at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101) > at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458) > at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411) > at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490) > at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202) > at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33) > at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474) > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > ++++++++++++++++++++++ -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-795) AdvancedLdap login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-795: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1065515|https://bugzilla.redhat.com/show_bug.cgi?id=1065515] from MODIFIED to ON_QA > AdvancedLdap login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-795 > URL: https://issues.jboss.org/browse/SECURITY-795 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Derek Horton > Fix For: Negotiation_2_2_7 > > Attachments: SECURITY-795.patch > > > AdvancedLdap login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2995) Using a log4j appender as a custom-handler should invoke the activateOptions if required

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2995?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2995: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1066607|https://bugzilla.redhat.com/show_bug.cgi?id=1066607] from MODIFIED to ON_QA > Using a log4j appender as a custom-handler should invoke the activateOptions if required > ---------------------------------------------------------------------------------------- > > Key: WFLY-2995 > URL: https://issues.jboss.org/browse/WFLY-2995 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.0.1.Final > > > Currently the {{OptionHandler.activateOptions}} is only invoked during construction of a log4j appender. This invocation should happen if any property is updated or added. The invocation of this method should also only happen once. Multiple invocation could result in errors or leave the appender in an invalid state. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-822) MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-822?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-822: ---------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1054984|https://bugzilla.redhat.com/show_bug.cgi?id=1054984] from MODIFIED to ON_QA > MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL > --------------------------------------------------------------------------------------------------- > > Key: WFLY-822 > URL: https://issues.jboss.org/browse/WFLY-822 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading, Server > Environment: Java 6u31 > Reporter: Zachary Bedell > Assignee: jaikiran pai > Labels: classloader, mbean, modules > Fix For: 8.0.0.Alpha3 > > Attachments: SarTcclTst.tbz > > > When an MBean is loaded from jboss-service.xml within an EAR, the TCCL should point to the EAR deployment so that config files and other resources can be classloaded from the EAR. Under JBoss 7.1.1.Final, the TCCL in a module loaded MBean's start() method is the module's ClassLoader. No reference to the EAR deployment's classloader is available, thus EAR resources are not available within the MBean. > It appears that org.jboss.as.service.AbstractService::invokeLifecycleMethod() incorrectly sets the TCCL to the module's defining classloader rather than the EAR's: > {{{ > protected void invokeLifecycleMethod(final Method method) throws InvocationTargetException, IllegalAccessException { > if (method != null) { > final ClassLoader old = SecurityActions.setThreadContextClassLoader(mBeanInstance.getClass().getClassLoader()); > try { > method.invoke(mBeanInstance); > } finally { > SecurityActions.resetThreadContextClassLoader(old); > } > } > } > }}} -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer + PropertyResolver is broken for vault expressions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-371: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1058959|https://bugzilla.redhat.com/show_bug.cgi?id=1058959] from MODIFIED to ON_QA > DefaultPropertyReplacer + PropertyResolver is broken for vault expressions > -------------------------------------------------------------------------- > > Key: JBMETA-371 > URL: https://issues.jboss.org/browse/JBMETA-371 > Project: JBoss Metadata > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: common > Affects Versions: 7.0.4.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Final > > > The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname". > This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value". -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calculating next timeout

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2840: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1059914|https://bugzilla.redhat.com/show_bug.cgi?id=1059914] from MODIFIED to ON_QA > @Schedule EJB Timer not using timezone when calculating next timeout > -------------------------------------------------------------------- > > Key: WFLY-2840 > URL: https://issues.jboss.org/browse/WFLY-2840 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 8.0.0.Final > > > With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour. > The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern. If it did, then the timer should continue to fire every minute. > {code} > @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*") > {code} > 21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014 > {code} > import javax.ejb.Schedule; > import javax.ejb.Singleton; > import javax.ejb.Startup; > @Startup > @Singleton > public class ScheduleTest { > @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*") > public void helloWorld(Timer time) { > System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo()); > } > } > {code} -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2198: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1053426|https://bugzilla.redhat.com/show_bug.cgi?id=1053426] from MODIFIED to ON_QA > Remote Naming throws the same exception for different causes > ------------------------------------------------------------ > > Key: WFLY-2198 > URL: https://issues.jboss.org/browse/WFLY-2198 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported. > We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. > If all the the servers specified are not not running: > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) > If one of the servers is running, but the client's username/password are incorrect > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-795) AdvancedLdap login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-795: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1065513|https://bugzilla.redhat.com/show_bug.cgi?id=1065513] from MODIFIED to ON_QA > AdvancedLdap login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-795 > URL: https://issues.jboss.org/browse/SECURITY-795 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Derek Horton > Fix For: Negotiation_2_2_7 > > Attachments: SECURITY-795.patch > > > AdvancedLdap login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-797: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1067612|https://bugzilla.redhat.com/show_bug.cgi?id=1067612] from MODIFIED to ON_QA > Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-797 > URL: https://issues.jboss.org/browse/SECURITY-797 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-797.patch > > > If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles. > It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-796) LdapExtended login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-796?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-796: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1067599|https://bugzilla.redhat.com/show_bug.cgi?id=1067599] from MODIFIED to ON_QA > LdapExtended login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-796 > URL: https://issues.jboss.org/browse/SECURITY-796 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-796.patch > > > LdapExtended login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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, 1 month

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