June 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: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1060997|https://bugzilla.redhat.com/show_bug.cgi?id=1060997] from VERIFIED to CLOSED > 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 was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3046: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1038993|https://bugzilla.redhat.com/show_bug.cgi?id=1038993] from VERIFIED to CLOSED > Not possible change the object store type from hornetq to jdbc via cli commands > ------------------------------------------------------------------------------- > > Key: WFLY-3046 > URL: https://issues.jboss.org/browse/WFLY-3046 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Final > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.1.0.CR1, 8.1.0.Final > > > When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file. > How to reproduce: > # ./bin/standalone.xml (start eap 6.2.0.GA) > # ./bin/jboss-cli.sh -c (connect to running eap) > # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true) > # :reload > # /subsystem=transactions/log-store=log-store:read-attribute(name=type) > # /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true) > # :reload > # /subsystem=transactions/log-store=log-store:read-attribute(name=type) > The object store stays to be set to hornetq and no change happens in the standalone.xml file. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2831) Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2831?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2831: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1059260|https://bugzilla.redhat.com/show_bug.cgi?id=1059260] from VERIFIED to CLOSED > Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2831 > URL: https://issues.jboss.org/browse/WFLY-2831 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Fix For: 8.0.0.Final > > > The striping of square brackets around IPv6 addresses doesn't work in > org.jboss.as.test.integration.security.common.Utils.getSecondaryTestAddress(ManagementClient, boolean), it causes failures of AdvancedLdapLoginModuleTestCase. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2912) Generic JMS adapter does not deploy correctly in domain mode.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2912?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2912: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1064299|https://bugzilla.redhat.com/show_bug.cgi?id=1064299] from VERIFIED to CLOSED > Generic JMS adapter does not deploy correctly in domain mode. > ------------------------------------------------------------- > > Key: WFLY-2912 > URL: https://issues.jboss.org/browse/WFLY-2912 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Final > Reporter: Tom Ross > Assignee: Stefano Maestri > Fix For: 8.1.0.CR1, 8.1.0.Final > > > When trying to use generic resource adapter with third part JMS providers like TIBCO it is necessary to use generic RA provided in JBoss EAP 6.2. Unfortunately it would appear that when trying to use in domain mode the RA does not get deployed full, though it works perfectly in standalone mode. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin console setup redirects to http address

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2498: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1029687|https://bugzilla.redhat.com/show_bug.cgi?id=1029687] from VERIFIED to CLOSED > Logout of secured (ssl) admin console setup redirects to http address > ---------------------------------------------------------------------- > > Key: WFLY-2498 > URL: https://issues.jboss.org/browse/WFLY-2498 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Web Console > Reporter: Chris Dolphy > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > > Description of problem: > Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2950) jboss-cli using https-remoting: command not executed if certificate is unrecognised

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2950?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2950: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from VERIFIED to CLOSED > jboss-cli using https-remoting: command not executed if certificate is unrecognised > ----------------------------------------------------------------------------------- > > Key: WFLY-2950 > URL: https://issues.jboss.org/browse/WFLY-2950 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI, Domain Management > Affects Versions: 8.0.0.Final > Environment: Windows 7 Pro > Reporter: Darren Jones > Assignee: Darran Lofthouse > Labels: cli, shutdown > Fix For: 8.1.0.CR1, 8.1.0.Final > > > When using the https management interface from jboss-cli, commands passed with a command line option (such as --command=:shutdown) are not executed if the server certificate is unrecognised - even if accepting the certificate [T]emporarily or [P]ermenantly. > It appears to be due to the CommandContextImpl.handleSSLFailure() method, which calls error("Unable to connect..."). The error() method sets the exitCode to 1. So, when CliLauncher.processCommands() subsequently runs, it sees that the cmdCtx.exitCode is 1 and ignores any commands. > I guess the handleSSLFailure needs to reset the exitCode to 0 if the user chooses [T] or [P]. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2538) Certificate acceptance causing command entered on starting the CLI to be skipped.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2538?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2538: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from VERIFIED to CLOSED > Certificate acceptance causing command entered on starting the CLI to be skipped. > --------------------------------------------------------------------------------- > > Key: WFLY-2538 > URL: https://issues.jboss.org/browse/WFLY-2538 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.0.0.Beta1 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > e.g. > {noformat} > ./jboss-cli.sh -c shutdown > Accept certificate? [N]o, [T]emporarily, [P]ermenantly : T > {noformat} > The shutdown command is not executed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2521) EJB backing cache's can generate large retention from cancelled tasks in its scheduled executor's DelayedWorkQueue

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2521?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2521: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1031199|https://bugzilla.redhat.com/show_bug.cgi?id=1031199] from VERIFIED to CLOSED > EJB backing cache's can generate large retention from cancelled tasks in its scheduled executor's DelayedWorkQueue > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-2521 > URL: https://issues.jboss.org/browse/WFLY-2521 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Beta1 > Reporter: Aaron Ogburn > Assignee: Paul Ferraro > Fix For: 8.0.0.CR1 > > > EJB backing cache's frequently cancel remove and passivation tasks with each access and replace them with new ones. Per http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledTh... cancelled tasks are not removed from queue until their scheduled delay passes. > So due to the java ScheduledThreadPoolExecutor's lazy cancelled task removal, this scheduled task cancellation and recreation model can potentially churn up quite a number of queued cancelled tasks sitting in the executor's DelayedWorkQueue. With longer timeouts and frequent ejb access, this can generate substantial heap overhead. > It should be pretty easy to help limit any such build up by calling purge() [1] on the scheduled executor. Likely don't want to purge with each cancel, so perhaps a purge() could be called on a configurable time delay or after a configurable amount of cancels? > [1] http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolE... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-803) SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-803?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-803: -------------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1069885|https://bugzilla.redhat.com/show_bug.cgi?id=1069885] from VERIFIED to CLOSED > SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache > ------------------------------------------------------------------------------------------------------ > > Key: SECURITY-803 > URL: https://issues.jboss.org/browse/SECURITY-803 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-803.patch > > > In EAP 6, when using the SecureIdentityLoginModule to encrypt datasource passwords, the results are not cached by the JAAS cache. In EAP 5, the results are cached. This can lead to a performance issue. > The root cause appears to be that the EAP 6 JAAS cache does not allow for a JAAS cache key to be null. > The issue only occurs when the application that uses the datasource is not secured. In this situation, the principal is null when isValid() and updateCache() are called. When the application is secured, the results are cached. I think it is working because the result of the SecureIdentityLoginModule are cached using the authenticated user's principal as the cache key. > Workaround: > Use vault for encrypting the database password. This does not use a JAAS login module so the JAAS cache and login module are completely avoided. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3477) For LDAP referrals we also need the option to the use referral connection for the group search for group to principal

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3477?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3477: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1066488|https://bugzilla.redhat.com/show_bug.cgi?id=1066488] from VERIFIED to CLOSED > For LDAP referrals we also need the option to the use referral connection for the group search for group to principal > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3477 > URL: https://issues.jboss.org/browse/WFLY-3477 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Alpha1 > > > For security realms where a referral was handled in the user searching stage we should also have the option to stay with the new connection for the group search where group to principal is used. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

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 June 2014