March 2013 - jboss-jira - Jboss List Archives

[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 commented on JBEE-122: ------------------------------------- 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] (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: -------------------------------- log4j2: * Requires 2 JARs: API and CORE ** We could copy the required API code (mainly LogManager.getLogger()) into JGroups's LogFactory ... * The level cannot be set at runtime, unless we downcast the Logger to its implementation class (setting the level is not exposed in the interface). > 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-4268) Add JMS bridge to Messaging subsystem

by dpocock (JIRA)

[ https://issues.jboss.org/browse/AS7-4268?page=com.atlassian.jira.plugin.s... ] dpocock commented on AS7-4268: ------------------------------ I understand the documentation refers to non-existent JARs. Can you give a specific example for connecting to prior versions of JBoss, for example, if HornetQ is running in JBoss AS 7.x, how to bridge a topic from a JBoss 4.2 / JBossMQ environment? Which JBossMQ JARs have to be copied, where to put them, etc? > Add JMS bridge to Messaging subsystem > ------------------------------------- > > Key: AS7-4268 > URL: https://issues.jboss.org/browse/AS7-4268 > Project: Application Server 7 > Issue Type: Task > Components: JMS > Affects Versions: 7.1.1.Final > Reporter: Justin Bertram > Assignee: Jeff Mesnil > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > Currently there is no pre-defined way to deploy a JMS bridge (i.e. org.hornetq.jms.bridge.impl.JMSBridgeImpl) in AS7. In JBoss AS 6 and earlier you could deploy the bridge as an MBean or JBoss MC bean, but the current configuration schema in AS7 simply doesn't support it. The bridge is a nice feature so we need a way to deploy it. > > It doesn't make sense to add the JMS bridge to a <hornetq-server> because the bridge can operate independently of a local HornetQ server. It really needs its own subsystem. -- 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-3694) Allow management client to associate metadata with DeploymentUnit

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-3694?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reassigned AS7-3694: ----------------------------------- Assignee: Brian Stansberry (was: Thomas Diesler) Brian, I'm having a hard time rebasing your changes - too many conflicts that I'm not sure what to do about. I rebased the base line here https://github.com/jbossas/jboss-as/pull/4232 Perhaps you could have another stab? > Allow management client to associate metadata with DeploymentUnit > ----------------------------------------------------------------- > > Key: AS7-3694 > URL: https://issues.jboss.org/browse/AS7-3694 > Project: Application Server 7 > Issue Type: Feature Request > Components: OSGi, Server > Reporter: Thomas Diesler > Assignee: Brian Stansberry > Priority: Critical > Fix For: 8.0.0.Alpha1 > > > Currently there is no way to pass some metadata through the deployment API such that they could show up with the DU. > As a client I'd like to say autostart=false and in my DUP I'd like to pick that up and not start a deployment (i.e. a bundle) automatically > Generally it should be possible for the client to set some properties for the deployment in a generic way such that they get associated with the DeploymentUnit > For an OSGi deployment it would be necessary to be able to define that start behaviour and the start level. -- 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 edited comment on JBJCA-1004 at 3/15/13 6:12 AM: --------------------------------------------------------------- The fix has been tested by IJ test suite and by JDBC TCK tests and committed to the 1.0 branch. was (Author: istudens): The fix has been tested by IJ test suite and by JDBC TCK tests. > 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 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final > > > 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-1008) Assert.fail() cannot be surrounded with a try-catch block which catches a general Throwable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1008?page=com.atlassian.jira.plugin... ] Ivo Studensky commented on JBJCA-1008: -------------------------------------- Fixed in the 1.0 branch. I cannot see any other Assert.??? occurrences inside of a try-catch-Throwable block in the IJ test suite. > 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 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final > > > 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-1008) Assert.fail() cannot be surrounded with a try-catch block which catches a general Throwable

by Ivo Studensky (JIRA)

Ivo Studensky created JBJCA-1008: ------------------------------------ Summary: 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 Reporter: Ivo Studensky Assignee: Ivo Studensky Fix For: 1.0.16.Final 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 Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1004?page=com.atlassian.jira.plugin... ] Ivo Studensky commented on JBJCA-1004: -------------------------------------- The fix has been tested by IJ test suite and by JDBC TCK tests. > 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 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final > > > 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-3694) Allow management client to associate metadata with DeploymentUnit

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-3694?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reassigned AS7-3694: ----------------------------------- Assignee: Thomas Diesler (was: Brian Stansberry) > Allow management client to associate metadata with DeploymentUnit > ----------------------------------------------------------------- > > Key: AS7-3694 > URL: https://issues.jboss.org/browse/AS7-3694 > Project: Application Server 7 > Issue Type: Feature Request > Components: OSGi, Server > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Priority: Critical > Fix For: 8.0.0.Alpha1 > > > Currently there is no way to pass some metadata through the deployment API such that they could show up with the DU. > As a client I'd like to say autostart=false and in my DUP I'd like to pick that up and not start a deployment (i.e. a bundle) automatically > Generally it should be possible for the client to set some properties for the deployment in a generic way such that they get associated with the DeploymentUnit > For an OSGi deployment it would be necessary to be able to define that start behaviour and the start level. -- 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-6738) The value wait-time of the EJB bean statistic is not calculated

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/AS7-6738?page=com.atlassian.jira.plugin.s... ] Wolf-Dieter Fink reassigned AS7-6738: ------------------------------------- Assignee: Wolf-Dieter Fink (was: jaikiran pai) > The value wait-time of the EJB bean statistic is not calculated > --------------------------------------------------------------- > > Key: AS7-6738 > URL: https://issues.jboss.org/browse/AS7-6738 > Project: Application Server 7 > Issue Type: Feature Request > Components: EJB > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Minor > > If the statistic for EJB calls is enabled with > /subsystem=ejb3:write-attribute(name=enable-statistics, value=true) > call statistics are caclulated but the wait-time is never set even if a pool overload is forced. -- 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