March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1004) Subject / security domain overrides null values from CRI for a datasource with allow-multiple-users

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1004?page=com.atlassian.jira.plugin... ] Ivo Studensky updated JBJCA-1004: --------------------------------- The committed changes have been reverted. Attaching the patch to this jira. > Subject / security domain overrides null values from CRI for a datasource with allow-multiple-users > --------------------------------------------------------------------------------------------------- > > Key: JBJCA-1004 > URL: https://issues.jboss.org/browse/JBJCA-1004 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > Attachments: JBJCA-1004-tests.patch, JBJCA-1004.patch > > > An issue cloned from JBPAPP6-1323 for the upstream. > DataSource configured with security-domain using org.picketbox.datasource.security.CallerIdentityLoginModule is able to create correct connection > when one of ds.getConection(username, password) is set to null. > Null parameter is substituted using value of corresponding field from the security-domain. > The datasource is defined using <allow-multiple-users/>. > See test org.jboss.as.test.integration.jca.security.DsWithCallerIdentityLoginModuleTestCase at https://github.com/pskopek/jboss-as/tree/JBPAPP-9583. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1004) Subject / security domain overrides null values from CRI for a datasource with allow-multiple-users

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1004?page=com.atlassian.jira.plugin... ] Ivo Studensky updated JBJCA-1004: --------------------------------- Attachment: JBJCA-1004.patch JBJCA-1004-tests.patch > Subject / security domain overrides null values from CRI for a datasource with allow-multiple-users > --------------------------------------------------------------------------------------------------- > > Key: JBJCA-1004 > URL: https://issues.jboss.org/browse/JBJCA-1004 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > Attachments: JBJCA-1004-tests.patch, JBJCA-1004.patch > > > An issue cloned from JBPAPP6-1323 for the upstream. > DataSource configured with security-domain using org.picketbox.datasource.security.CallerIdentityLoginModule is able to create correct connection > when one of ds.getConection(username, password) is set to null. > Null parameter is substituted using value of corresponding field from the security-domain. > The datasource is defined using <allow-multiple-users/>. > See test org.jboss.as.test.integration.jca.security.DsWithCallerIdentityLoginModuleTestCase at https://github.com/pskopek/jboss-as/tree/JBPAPP-9583. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1585) Upgrade log4j

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1585?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1585 at 3/15/13 8:40 AM: --------------------------------------------------------- jboss-logging: * meta-logging framework, does the same as what JGroups org.jgroups.logging already does * Easy to use * Provides logging adapters for JBoss, log4j, JUL and slf4j * Does *not* provide adapter for log4j2 or logback I think I'm going to go with log4j2 for now, with the following changes: * Hack support for setting the level at runtime * Use only the CORE JAR and copy the relevant part of the API JAR (creation of loggers) into JGroups's Log4j2LogImpl was (Author: belaban): jboss-logging: * meta-logging framework, does the same as what JGroups org.jgroups.logging already does * Easy to use ** Provides logging adapters for JBoss, log4j, JUL and slf4j ** Does *not* provide adapter for log4j2 or logback I think I'm going to go with log4j2 for now, with the following changes: * Hack support for setting the level at runtime * Use only the CORE JAR and copy the relevant part of the API JAR (creation of loggers) into JGroups's Log4j2LogImpl > Upgrade log4j > ------------- > > Key: JGRP-1585 > URL: https://issues.jboss.org/browse/JGRP-1585 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > log4j has some heavy synchronization, which can sometimes lead to code blocking up to 30 seconds (see [1]). > Investigate whether we should switch to log42 [2]. Perhaps we can simply program against the API (30K) and not even ship the implementation ? > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51047 > [2] http://logging.apache.org/log4j/2.x/ -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1585) Upgrade log4j

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1585?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1585: -------------------------------- jboss-logging: * meta-logging framework, does the same as what JGroups org.jgroups.logging already does * Easy to use ** Provides logging adapters for JBoss, log4j, JUL and slf4j ** Does *not* provide adapter for log4j2 or logback I think I'm going to go with log4j2 for now, with the following changes: * Hack support for setting the level at runtime * Use only the CORE JAR and copy the relevant part of the API JAR (creation of loggers) into JGroups's Log4j2LogImpl > Upgrade log4j > ------------- > > Key: JGRP-1585 > URL: https://issues.jboss.org/browse/JGRP-1585 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > log4j has some heavy synchronization, which can sometimes lead to code blocking up to 30 seconds (see [1]). > Investigate whether we should switch to log42 [2]. Perhaps we can simply program against the API (30K) and not even ship the implementation ? > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51047 > [2] http://logging.apache.org/log4j/2.x/ -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6367) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/AS7-6367?page=com.atlassian.jira.plugin.s... ] Philippe Marschall commented on AS7-6367: ----------------------------------------- Could somebody confirm that the description is accurate? This is currently blocking our migration to AS 7.x. If it's accurate we need to come up with some kind of work around, otherwise it's a configuration issue on our side. > Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms > ------------------------------------------------------------------------------------------------------------ > > Key: AS7-6367 > URL: https://issues.jboss.org/browse/AS7-6367 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.3.Final (EAP) > Reporter: Derek Horton > Assignee: jaikiran pai > > My confusion is around the remoting/security-realm setup in the use case > where multiple EJBs are deployed that use different security-domains and > the EJBs will be invoked by remote standalone clients. For example, > ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to > be in the sec-domain-Y security-domain. > In this situation, the authentication checks are going to be handled by > the security-realm that is associated with the remote connector that is > configured to be used by the EJB subsystem. > It looks like the security-realm can either handle the authentication > checks directly (properties file, ldap, etc) or it can defer to the > jaas security-domain. In both of those situations, it seems that the > EJBs are limited to a single authentication point. The EJB > authentication is either going to be handled by a single security-realm > or the security-realm will defer to a single security-domain. > I could configure the security-domain to have multiple login modules. I > assume the same thing could be done with the security-realm. > Basically the problem that I am trying to solve boils down to this: the > authentication checks for remote EJBs appear to be checked by either a > single security-realm or a single security-domain. Is there a way to > change this? > One idea I had was to add another remote connector to the EJB subsystem. > Unfortunately, this does not appear to be possible. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1008) Assert.fail() cannot be surrounded with a try-catch block which catches a general Throwable

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1008?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1008: ----------------------------------- Fix Version/s: 1.1.0.Beta5 Affects Version/s: 1.1.0.Beta4 > Assert.fail() cannot be surrounded with a try-catch block which catches a general Throwable > ------------------------------------------------------------------------------------------- > > Key: JBJCA-1008 > URL: https://issues.jboss.org/browse/JBJCA-1008 > Project: IronJacamar > Issue Type: Bug > Components: Test suite > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > > In IJ test suite there are occurrences of Assert.fail(String) surrounding with a try-catch block that catches a general Throwable. This effectively means that AssertionError produced by Assert.fail() is eaten by the following catch clause, usually quietly. And then such a test passes instead of it fails. > Affected tests: > {noformat} > adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2SecurityDomainMultipleUsersTestCase.java > core/src/test/java/org/jboss/jca/core/connectionmanager/connections/InterleavingTestCase.java > deployers/src/test/java/org/jboss/jca/deployers/annotations/AnnotationsTestCase.java > embedded/src/test/java/org/jboss/jca/embedded/unit/ShrinkWrapTestCase.java > {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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1004) Subject / security domain overrides null values from CRI for a datasource with allow-multiple-users

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1004?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1004: ----------------------------------- Fix Version/s: 1.1.0.Beta5 Affects Version/s: 1.1.0.Beta4 > Subject / security domain overrides null values from CRI for a datasource with allow-multiple-users > --------------------------------------------------------------------------------------------------- > > Key: JBJCA-1004 > URL: https://issues.jboss.org/browse/JBJCA-1004 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > > An issue cloned from JBPAPP6-1323 for the upstream. > DataSource configured with security-domain using org.picketbox.datasource.security.CallerIdentityLoginModule is able to create correct connection > when one of ds.getConection(username, password) is set to null. > Null parameter is substituted using value of corresponding field from the security-domain. > The datasource is defined using <allow-multiple-users/>. > See test org.jboss.as.test.integration.jca.security.DsWithCallerIdentityLoginModuleTestCase at https://github.com/pskopek/jboss-as/tree/JBPAPP-9583. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6722) Quoted script parameters are not properly parsed in the bash script

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6722?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6722: ---------------------------------------------- pkremens(a)redhat.com made a comment on [bug 918030|https://bugzilla.redhat.com/show_bug.cgi?id=918030] James, this is not a question for QE. John Doyle should decide, which option is more acceptable from customers point of view. I did some tests and scripts from your PR are working as you said. (I don't have Solaris results yet as there was some maintenance in lab) https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Scri... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Scri... I also notice, that this issue is quite same when it comes to special characters in path (see https://issues.jboss.org/browse/JBPAPP-10411 that was for EAP5). If you look at console outputs of runs with '#' and '$' in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Smok... it is a quite same error. I tried to run same job with standalone.sh from PR but result was the same (see https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Play...) > Quoted script parameters are not properly parsed in the bash script > ------------------------------------------------------------------- > > Key: AS7-6722 > URL: https://issues.jboss.org/browse/AS7-6722 > Project: Application Server 7 > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.0.0.Alpha1 > > > Quotes are added to parameters passed via the command line. When checking the parameters for the {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} properties quoted parameters are not found. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-122) Concurrency Utilities for Java EE (JSR-236)

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-122?page=com.atlassian.jira.plugin.s... ] Shelly McGowan edited comment on JBEE-122 at 3/15/13 7:58 AM: -------------------------------------------------------------- The ExecutorNotAvailableException class has been removed from the Specification. I'll remove it from this project in preparation for an Alpha1 release. jsr-236 mail list reference: http://java.net/projects/concurrency-ee-spec/lists/users/archive/2013-02/... and also verified it is not in RI API JavaDoc b04. was (Author: shelly.mcgowan): The ExecutorNotAvailableException class has been removed from the Specification. I'll remove it from this project in preparation for an Alpha1 release. jsr-236 mail list reference: http://java.net/projects/concurrency-ee-spec/lists/users/archive/2013-02/... and verified it is not in RI API JavaDoc b04. > Concurrency Utilities for Java EE (JSR-236) > -------------------------------------------- > > Key: JBEE-122 > URL: https://issues.jboss.org/browse/JBEE-122 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-javaee-concurrency-api > Reporter: Shelly McGowan > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > These APIs are required as part of our Java EE 7 implementation. > They should be added to the org.jboss.spec project: > {code} > <dependency> > <groupId>org.jboss.spec.javax.enterprise.concurrent</groupId> > <artifactId>jboss-concurrent-api_1.0_spec</artifactId> > <version>1.0.0.Final-SNAPSHOT</version> > </dependency> > {code} > Project can be created in http://github.com/jboss/jboss-concurrent-api_spec -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4605) Deployment error

by Chris VDS (JIRA)

[ https://issues.jboss.org/browse/AS7-4605?page=com.atlassian.jira.plugin.s... ] Chris VDS commented on AS7-4605: -------------------------------- i have the same error after power failure. server (in domain mode) fails to start up. > Deployment error > ---------------- > > Key: AS7-4605 > URL: https://issues.jboss.org/browse/AS7-4605 > Project: Application Server 7 > Issue Type: Bug > Components: Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 7.1.2.Final (EAP) > > > [Host Controller] 15:09:15,993 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) Operation ("add") failed - address: ([("deployment" => "jboss-as-helloworld-mdb.war")]) - failure description: "JBAS010876: No deployment content with hash 7ba3e87a0079895f0aad95c16739b513fd5a28d8 is available in the deployment content repository for deployment 'jboss-as-helloworld-mdb.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." -- 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

13 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 March 2013