October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2131) read-operation-names to return a filtered list of allowed operations

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2131: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056] from NEW to MODIFIED > read-operation-names to return a filtered list of allowed operations > -------------------------------------------------------------------- > > Key: WFLY-2131 > URL: https://issues.jboss.org/browse/WFLY-2131 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Alexey Loubyansky > Assignee: Kabir Khan > Fix For: 8.0.0.Beta1 > > > As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1756) Add access-control parameter to read-operation-description operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1756: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056] from NEW to MODIFIED > Add access-control parameter to read-operation-description operation > -------------------------------------------------------------------- > > Key: WFLY-1756 > URL: https://issues.jboss.org/browse/WFLY-1756 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.0.0.Beta1 > > > Similar to read-resource-description -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1569: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from POST to MODIFIED > Not possible to reload server when JTS transactions are activated > ----------------------------------------------------------------- > > Key: WFLY-1569 > URL: https://issues.jboss.org/browse/WFLY-1569 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.0.0.Alpha1 > Reporter: Ondřej Chaloupka > Assignee: Stefano Maestri > > When transactions are set for JTS being used > - <jts/> tag under transactions subsystem > - transactions="on" under jacorb subsystem > then it is not possible to reload the server. > The reload causes the following exception being shown. > {code} > 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed > at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409) > at org.jacorb.poa.POA.set_servant(POA.java:1979) > at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] > 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] > Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67) > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) > ... 5 more > {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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2249) NPE during redeployment of a war

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2249?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-2249: ------------------------------------ Perhaps we should have a null pointer check in that code. Are you setup to debug WildFly 8 and catch the NPE at PersistenceUnitParseProcessor.java:126? Would be good to know the npe cause and more details. > NPE during redeployment of a war > -------------------------------- > > Key: WFLY-2249 > URL: https://issues.jboss.org/browse/WFLY-2249 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 8.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Scott Marlow > > When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm... > {code} > ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: java.lang.NullPointerException > at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126) > at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1] > ... 5 more > {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, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-289) PackageBuilder throws NPE when a declared class extends another, undeclared one

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-289: ------------------------------------- Summary: PackageBuilder throws NPE when a declared class extends another, undeclared one Key: DROOLS-289 URL: https://issues.jboss.org/browse/DROOLS-289 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Davide Sottara Assignee: Mark Proctor Parent class(es) used with declare must be declared themselves. However, instead of returning a compilation error, the package builder throws a runtime NPE -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-84) LoggingMXBean is not being set during log manager initialization

by James Perkins (JIRA)

James Perkins created LOGMGR-84: ----------------------------------- Summary: LoggingMXBean is not being set during log manager initialization Key: LOGMGR-84 URL: https://issues.jboss.org/browse/LOGMGR-84 Project: JBoss Log Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Debugging seems to show the static {{LoggingMXBean}} being set in the {{org.jboss.logmanager.LogManager}} constructor, but some time later the static instance is reinitialized to {{null}} in the {{java.util.logging.LogManager}}. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1623) Access Control: read-children-resources

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1623?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-1623. ------------------------------------ Fix Version/s: 8.0.0.Beta1 Resolution: Done Please start a thread on the dev list if more information is needed. > Access Control: read-children-resources > --------------------------------------- > > Key: WFLY-1623 > URL: https://issues.jboss.org/browse/WFLY-1623 > Project: WildFly > Issue Type: Clarification > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > Fix For: 8.0.0.Beta1 > > > What priviledges apply to a read-children-resources operation? The ones of the parent resource or the ones for each child resource? -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1729) Provide an access control user guide chapter

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1729?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-1729. ------------------------------------ Resolution: Duplicate Issue > Provide an access control user guide chapter > -------------------------------------------- > > Key: WFLY-1729 > URL: https://issues.jboss.org/browse/WFLY-1729 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1736) CommandLineArgumentUsage class substring value discarded

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1736?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-1736: ----------------------------------- Fix Version/s: 8.0.0.CR1 > CommandLineArgumentUsage class substring value discarded > -------------------------------------------------------- > > Key: WFLY-1736 > URL: https://issues.jboss.org/browse/WFLY-1736 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.0.0.Alpha4 > Reporter: Cheng Fang > Assignee: Brian Stansberry > Fix For: 8.0.0.CR1 > > > CommandLineArgumentUsage class has a substring call but return value discarded: > {code} > if( input.get(0).length() > width ){ > String tooLong = input.remove(0); > tooLong.substring(0, width-5); > input.add("Command removed. Too long."); > } > {code} > FindBugs also finds a static field should be final: > {code} > protected static List<String> instructions = new ArrayList<String>(); > {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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1741) RBAC: Response headers don't match payload structure

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1741?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-1741: ---------------------------------------- I don't understand. It's looks fine to me. What do you think it should look like? > RBAC: Response headers don't match payload structure > ---------------------------------------------------- > > Key: WFLY-1741 > URL: https://issues.jboss.org/browse/WFLY-1741 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > > the 'relative-address' header doesn't match the response structure: > (hint: the 'data-source' element is missing) > {noformat} > [standalone@localhost:9990 /] /subsystem=datasources:read-children-resources(child-type=data-source){roles=monitor} > { > "outcome" => "success", > "result" => { > "ExampleDS" => { > "allocation-retry" => undefined, > "allocation-retry-wait-millis" => undefined, > [...] } > }, > "response-headers" => {"access-control" => [ { > "absolute-address" => [ > ("subsystem" => "datasources"), > ("data-source" => "ExampleDS") > ], > "relative-address" => [("data-source" => "ExampleDS")], > "filtered-attributes" => [ > "user-name", > "security-domain", > "password" > ] > } > ]} > } > {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

12 years, 7 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 October 2013