March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4065) TS: Migrate from Surefire to Failsafe maven plugin.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-4065?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-4065: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.2.0.Alpha1) > TS: Migrate from Surefire to Failsafe maven plugin. > --------------------------------------------------- > > Key: AS7-4065 > URL: https://issues.jboss.org/browse/AS7-4065 > Project: Application Server 7 > Issue Type: Enhancement > Components: Test Suite > Reporter: Ondrej Zizka > Assignee: Jakub Senko > Fix For: 8.0.0.Alpha1 > > Attachments: AS7-failsafe-surefire.html.zip > > > Surefire aims at unit testing. > Failsafe, unlike Surefire, binds to two build phases - integration-tests and verify. > That not only moves test execution to the correct phase, but also brings possibility to test several issues present in the testsuite - like skipping successive Surefire executions in a single module if former fails (not affected by -fae). > -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6114) lower messaging's min-large-message-size value in standalone-full.xml

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6114?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6114: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.2.0.Alpha1) > lower messaging's min-large-message-size value in standalone-full.xml > --------------------------------------------------------------------- > > Key: AS7-6114 > URL: https://issues.jboss.org/browse/AS7-6114 > Project: Application Server 7 > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.Alpha1 > > > AS7's messaging subsystem defines 2 attributes: > journal-file-size => 10MiB > min-large-message-size => 100KiB > However, for startup performance issue, the standalone-full.xml sets the journal-file-size at 1OOKiB. This leads to issues since it's the same value than the min-large-message-size. > If we want to keep a low journal-file-size value in standalone-full.xml, the min-large-message-size must also bet set appropriately (eg 75KiB?) > For production use, however, we should suggest to the users to remove the journal-file-size and min-large-message-size from standalone-full.xml to use the default values (resp. 10MiB & 100KiB) -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6177) Failed to execute goal on project jboss-as-clustering-jgroups

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6177?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6177: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.2.0.Alpha1) > Failed to execute goal on project jboss-as-clustering-jgroups > ------------------------------------------------------------- > > Key: AS7-6177 > URL: https://issues.jboss.org/browse/AS7-6177 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 7.2.0.Alpha1 > Reporter: Tom Jenkinson > Assignee: Radoslav Husar > Priority: Minor > Fix For: 8.0.0.Alpha1 > > Attachments: AS7-build-failed.txt > > > Failed to execute goal on project jboss-as-clustering-jgroups: Could not resolve dependencies for project org.jboss.as:jboss-as-clustering-jgroups:jar:7.2.0.Alpha1-SNAPSHOT: Failure to find org.jboss.as:jboss-as-clustering-common:jar:tests:7.2.0.Alpha1-SNAPSHOT -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-5919) Optimize OSGi subsystem bootstrap

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5919?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-5919: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.2.0.CR1) > Optimize OSGi subsystem bootstrap > --------------------------------- > > Key: AS7-5919 > URL: https://issues.jboss.org/browse/AS7-5919 > Project: Application Server 7 > Issue Type: Feature Request > Components: OSGi > Reporter: Thomas Diesler > Fix For: 8.0.0.Alpha1 > > > The OSGi subsystem in AS7 is alrady activated lazily. However, in many cases users only want to deploy a simple artefact that "happens to be" an OSGi bundle (i.e. a JDBC driver) and do not want to deploy a large set of interconnected bundles that make up a complex modular enterprise application. For those cases the OSGi subsystem should bootstrap in a jiffy and we should not see a performance impact that is worth talking about. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6610) Invocation access control context management

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6610?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6610: ---------------------------------- Fixed in my privileged_fixes AS branch, but some tests are still failing... > Invocation access control context management > -------------------------------------------- > > Key: AS7-6610 > URL: https://issues.jboss.org/browse/AS7-6610 > Project: Application Server 7 > Issue Type: Sub-task > Components: Application Client, CDI / Weld, EJB, JMS, POJO, REST, Security, Web > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.0.0.Alpha1 > > > We need to ensure that as part of our security context propagation that we're properly handling access control contexts. For example, an async EJB invocation should have the exact same access control profile as a direct EJB invocation. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-4714) Reintroduce the feature to allow EJB invocations over HTTP

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-4714?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-4714: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: Open To Community) (was: 7.2.0.Alpha1) > Reintroduce the feature to allow EJB invocations over HTTP > ---------------------------------------------------------- > > Key: AS7-4714 > URL: https://issues.jboss.org/browse/AS7-4714 > Project: Application Server 7 > Issue Type: Feature Request > Components: EJB > Affects Versions: 7.1.1.Final > Reporter: jaikiran pai > Assignee: Eduardo Martins > Fix For: 8.0.0.Alpha1 > > > There have been requests from users to resurrect the feature from previous JBoss AS versions to allow EJB invocation over HTTP. Most recent discussion about this is here http://lists.jboss.org/pipermail/jboss-as7-dev/2012-April/005808.html -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6610) Invocation access control context management

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6610?page=com.atlassian.jira.plugin.s... ] David Lloyd reassigned AS7-6610: -------------------------------- Assignee: David Lloyd > Invocation access control context management > -------------------------------------------- > > Key: AS7-6610 > URL: https://issues.jboss.org/browse/AS7-6610 > Project: Application Server 7 > Issue Type: Sub-task > Components: Application Client, CDI / Weld, EJB, JMS, POJO, REST, Security, Web > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.0.0.Alpha1 > > > We need to ensure that as part of our security context propagation that we're properly handling access control contexts. For example, an async EJB invocation should have the exact same access control profile as a direct EJB invocation. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6083) ConcurrentModificationException in ConfigAdminService

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6083?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6083: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.2.0.Alpha1) > ConcurrentModificationException in ConfigAdminService > ----------------------------------------------------- > > Key: AS7-6083 > URL: https://issues.jboss.org/browse/AS7-6083 > Project: Application Server 7 > Issue Type: Bug > Components: ConfigAdmin, OSGi > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 8.0.0.Alpha1 > > > {code} > 12:07:46,616 ERROR [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011026: Framework Error: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT > at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:110) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final] > at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:167) > at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final] > at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final] > at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:522) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final] > at org.jboss.osgi.framework.internal.DefaultStartLevelPlugin.increaseStartLevel(DefaultStartLevelPlugin.java:265) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final] > at org.jboss.osgi.framework.internal.FrameworkActive.start(FrameworkActive.java:131) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37] > Caused by: java.util.ConcurrentModificationException > at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373) [rt.jar:1.6.0_37] > at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:384) [rt.jar:1.6.0_37] > at org.jboss.as.configadmin.service.ConfigAdminServiceImpl.addListener(ConfigAdminServiceImpl.java:249) > at org.jboss.as.osgi.configadmin.DomainModelPersistenceManager.start(DomainModelPersistenceManager.java:68) > at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:84) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final] > {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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-5891) Explicitly define public APIs for the OSGi subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5891?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-5891: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.2.0.Alpha1) > Explicitly define public APIs for the OSGi subsystem > ---------------------------------------------------- > > Key: AS7-5891 > URL: https://issues.jboss.org/browse/AS7-5891 > Project: Application Server 7 > Issue Type: Task > Components: OSGi > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 8.0.0.Alpha1 > > > All subsystem modules should have an export element -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6216) Some javax.* bundles show version 0.0.0 in AS7

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6216?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6216: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.2.0.CR1) > Some javax.* bundles show version 0.0.0 in AS7 > ---------------------------------------------- > > Key: AS7-6216 > URL: https://issues.jboss.org/browse/AS7-6216 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.2.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Cheng Fang > Fix For: 8.0.0.Alpha1 > > > Some javax bundles that we configure by default do not show valid bundle version info > javax.jws.api:0.0.0 > javax.ws.rs.api:0.0.0 > The javax.persistence.api has its metadata defined in jbosgi-xservice.properties like this > {code} > Bundle-SymbolicName: hibernate-jpa-2.0-api > Bundle-Version: 1.0.1.Final > Export-Package: javax.persistence.spi;version="2.0.0",javax.persistence.criteria;version="2.0.0",javax.persistence;version="2.0.0",javax.persistence.metamodel;version="2.0.0" > {code} > This should be replaced by metadata coming from the artefacts manifest. > Generally, all javax api artefacts should have valid OSGi metadata -- 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, 4 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 March 2013