June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4900) Re-creating a logging handler fails with message "JBAS014749: Operation handler failed: null"

by Masafumi Miura (JIRA)

Masafumi Miura created AS7-4900: ----------------------------------- Summary: Re-creating a logging handler fails with message "JBAS014749: Operation handler failed: null" Key: AS7-4900 URL: https://issues.jboss.org/browse/AS7-4900 Project: Application Server 7 Issue Type: Bug Components: CLI, Logging Affects Versions: 7.1.2.Final (EAP) Environment: AS 7.1.2 EAP 6.0.0 Beta2 Reporter: Masafumi Miura Assignee: Alexey Loubyansky Re-creating a logging handler using (:add, :remove, :add) fails with message "JBAS014749: Operation handler failed: null". For instance, 1. Add a logging handler: {noformat:title=$./jboss-cli.sh --connect --file=/tmp/test/logging-add.cli} #1 /subsystem=logging/periodic-rotating-file-handler=TESTLOG:add(suffix=.yyyy-MM-dd,autoflush=true,append=true,file={"relative-to" => "jboss.server.log.dir","path" => "TESTLOG.log"}) #2 /subsystem=logging/periodic-rotating-file-handler=TESTLOG:write-attribute(name=formatter,value="%d %-5p [%c{1}](%t) - %m%n") #3 /subsystem=logging/logger=org.jboss.support.test:add(level=ERROR,handlers=["TESTLOG"],use-parent-handlers=false) The batch executed successfully. {noformat} 2. Remove the logging handler: {noformat:title=$./jboss-cli.sh --connect --file=/tmp/test/logging-remove.cli} #1 /subsystem=logging/logger=org.jboss.support.test:remove #2 /subsystem=logging/periodic-rotating-file-handler=TESTLOG:remove The batch executed successfully. {noformat} 3. Add the logging handler again: {noformat:title=$./jboss-cli.sh --connect --file=/tmp/test/logging-add.cli} #1 /subsystem=logging/periodic-rotating-file-handler=TESTLOG:add(suffix=.yyyy-MM-dd,autoflush=true,append=true,file={"relative-to" => "jboss.server.log.dir","path" => "TESTLOG.log"}) #2 /subsystem=logging/periodic-rotating-file-handler=TESTLOG:write-attribute(name=formatter,value="%d %-5p [%c{1}](%t) - %m%n") #3 /subsystem=logging/logger=org.jboss.support.test:add(level=ERROR,handlers=["TESTLOG"],use-parent-handlers=false) Failed to execute batch: {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => "JBAS014749: Operation handler failed: null"}} {noformat} Then JBoss shows the following ERROR in server.log: {noformat:title=server.log} ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) JBAS014612: Operation ("write-attribute") failed - address: ([ ("subsystem" => "logging"), ("periodic-rotating-file-handler" => "TESTLOG") ]): java.lang.NullPointerException at org.jboss.as.logging.handlers.FormatterSpec$PatternFormatterSpec.apply(FormatterSpec.java:62) [jboss-as-logging-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.logging.handlers.AbstractLogHandlerWriteAttributeHandler.applyUpdateToRuntime(AbstractLogHandlerWriteAttributeHandler.java:93) [jboss-as-logging-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:116) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractWriteAttributeHandler.execute(AbstractWriteAttributeHandler.java:138) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$WriteAttributeHandler.execute(GlobalOperationHandlers.java:503) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:85) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:473) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:126) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.1.2.Final.jar:7.1.2.Final] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:286) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:491) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.6.0_24] at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24] at org.jboss.threads.JBossThread.run(JBossThread.java:122) {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
5
0 / 0

[JBoss JIRA] (AS7-3641) Lock down HornetQ default cluster user

by Justin Bertram (JIRA)

Justin Bertram created AS7-3641: ----------------------------------- Summary: Lock down HornetQ default cluster user Key: AS7-3641 URL: https://issues.jboss.org/browse/AS7-3641 Project: Application Server 7 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram The HornetQ default cluster user is a security hole. AS7 should plug this hole when it starts HornetQ. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
5
0 / 0

[JBoss JIRA] (AS7-4786) MSC controller hangs when loading an ear with multiple persistence units on a single CPU core machine

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-4786?page=com.atlassian.jira.plugin.s... ] Scott Marlow updated AS7-4786: ------------------------------ Fix Version/s: 7.1.3.Final (EAP) Git Pull Request: https://github.com/jbossas/jboss-as/pull/2407 (was: https://github.com/jbossas/jboss-as/pull/2407) Forum Reference: https://community.jboss.org/thread/200411 (was: https://community.jboss.org/thread/200411) Added additional pull request https://github.com/jbossas/jboss-as/pull/2489 > MSC controller hangs when loading an ear with multiple persistence units on a single CPU core machine > ----------------------------------------------------------------------------------------------------- > > Key: AS7-4786 > URL: https://issues.jboss.org/browse/AS7-4786 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.1.Final > Environment: Centos 6, single core lib-virt VM > Reporter: Wouter De Borger > Assignee: Scott Marlow > Labels: hibernate, naming, race > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > Attachments: hungas7.txt > > > When deploying an EAR with two persistence units on single core machines, the server hangs. > When increasing the number of cores to two, the same server just works. > I traced the bug to the method in org.jboss.as.naming.WritableServiceBasedNamingStore.unbind > The container attempts to register "hibernate/SessionFactory" twice. > The first time it works, the second time it hangs on the wait statement. > I suspect a race condition in the ServiceControllerImpl. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
0
0 / 0

[JBoss JIRA] (AS7-4983) Jboss AS 7.1.1 / Jboss EAP 6.0 Beta2 : Jboss use weakeness cipher algorithm (Blowfish 56 bits)) to encrypted DataSource Password

by Yannick LE NY (JIRA)

Yannick LE NY created AS7-4983: ---------------------------------- Summary: Jboss AS 7.1.1 / Jboss EAP 6.0 Beta2 : Jboss use weakeness cipher algorithm (Blowfish 56 bits)) to encrypted DataSource Password Key: AS7-4983 URL: https://issues.jboss.org/browse/AS7-4983 Project: Application Server 7 Issue Type: Bug Components: Domain Management, Security Affects Versions: 7.1.2.Final (EAP) Environment: Jboss EAP 6.0 Beta2 Jboss AS 7.1.1 Linux RHEL 5.4 JDK 1.6.0_24 Reporter: Yannick LE NY Assignee: Brian Stansberry Fix For: 7.1.3.Final (EAP) In Jboss EAP 6.0 Beta2 or Jboss AS 7.1.1, Jboss use weakeness cipher algorithm (Blowfish 56bits) to encrypted DataSource Password. http://middlewaremagic.com/jboss/?p=1026 said : "JBoss AS7 uses picketbox security implementations. In this example we will see how we can provide an Encrypted Password for our DataSources rather than using the ClearText Password. The picketbox provides us a class for encrypting the Cleartext passwords using class "org.picketbox.datasource.security.SecureIdentityLoginModule"." When you search about the org.picketbox.datasource.security.SecureIdentityLoginModule java class on the Internet, you find this source file http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... . In the file SecureIdentityLoginModule.java, we can see that this is the weakness Blowfish cipher algorithm (line Cipher cipher = Cipher.getInstance("Blowfish"); ) that is used by the Cipher getInstance function : (http://docs.oracle.com/javase/6/docs/api/javax/crypto/Cipher.html#getInst... ) Blowfish info : http://en.wikipedia.org/wiki/Blowfish_%28cipher%29 Weakness because, by default, the JDK use Blowfish with 56 bits key : Source : http://docs.oracle.com/javase/1.5.0/docs/guide/security/CryptoSpec.html#AppB Extract : The SunJCE provider uses the following default keysizes: KeyGenerator : Blowfish: 56 bits org.picketbox.datasource.security.SecureIdentityLoginModule class use javax.crypto.Cipher class. As you can see at : http://docs.oracle.com/javase/6/docs/api/javax/crypto/Cipher.html#getInst..., getInstance function can use several cipher Algorithms. The cipher Algorithms available are : http://docs.oracle.com/javase/1.5.0/docs/guide/security/CryptoSpec.html#AppA (part Cipher) http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/Cry... Then can you replace the weakness Blowfish Cipher Algorithm used to encrypted DataSource Password by AES-256 ? Note : The security team in my big company want now that all the application servers used in the company use strong cipher algorithm as 3DES used by Oracle Weblogic 10 or as AES-256 used by Oracle Weblogic 11. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
3
0 / 0

[JBoss JIRA] (AS7-4786) MSC controller hangs when loading an ear with multiple persistence units on a single CPU core machine

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-4786?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-4786: ----------------------------------- updated https://github.com/jbossas/jboss-as/pull/2407 code change and retested. > MSC controller hangs when loading an ear with multiple persistence units on a single CPU core machine > ----------------------------------------------------------------------------------------------------- > > Key: AS7-4786 > URL: https://issues.jboss.org/browse/AS7-4786 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.1.Final > Environment: Centos 6, single core lib-virt VM > Reporter: Wouter De Borger > Assignee: Scott Marlow > Labels: hibernate, naming, race > Fix For: 7.2.0.Alpha1 > > Attachments: hungas7.txt > > > When deploying an EAR with two persistence units on single core machines, the server hangs. > When increasing the number of cores to two, the same server just works. > I traced the bug to the method in org.jboss.as.naming.WritableServiceBasedNamingStore.unbind > The container attempts to register "hibernate/SessionFactory" twice. > The first time it works, the second time it hangs on the wait statement. > I suspect a race condition in the ServiceControllerImpl. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
0
0 / 0

[JBoss JIRA] (JBRULES-3540) .AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)

by Abhishek Srivastava (JIRA)

Abhishek Srivastava created JBRULES-3540: -------------------------------------------- Summary: .AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) Key: JBRULES-3540 URL: https://issues.jboss.org/browse/JBRULES-3540 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.4.0.Final Environment: Red Hat Enterprise Linux Server release 5.3 (Tikanga). JDK1.6.0_31 Reporter: Abhishek Srivastava Assignee: Mark Proctor We are using drools to create a RuleEngine. The rules are specified using Excel sheet and are getting compiled properly. But when the rules are executed, the dynamically generated Java-classes are giving the following security exception: Stack trace: Detail: Exception executing consequence for rule "FSA_Unmapped_Line" in spike.rules: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1283) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1209) at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1442) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) at com.xxx.yyy.process(RulesEngine.java:50) at com.xxx.yyy.performBaselineProcessing(AbstractRuleSource.java:366) at com.xxx.yyy.RuleSource$RuleProcess.run(RuleSource.java:81) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.xxx.yyy.LocalSecurityManager.checkPermission(LocalSecurityManager.java:37) at java.lang.ClassLoader.getParent(ClassLoader.java:1257) at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:583) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at spike.rules.Rule_FSA_Unmapped_Line_d3888b5292c7457598c050ce9919d032.defaultConsequence(Rule_FSA_Unmapped_Line_d3888b5292c7457598c050ce9919d032.java:7) at spike.rules.Rule_FSA_Unmapped_Line_d3888b5292c7457598c050ce9919d032DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) at spike.rules.Rule_FSA_Unmapped_Line_d3888b5292c7457598c050ce9919d032DefaultConsequenceInvoker.evaluate(Unknown Source) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1273) ... 10 more We are having a SecurityManager installed to manage the permissions. Please note that with drools-5.3.1, the RuleEngine was working fine and the issue started coming as soon as we migrated to version 5.4. We have tried to use JANINO java compiler, but that does not resolve the problem. Granting RuntimePermission to get/create ClassLoader is not an option as it will leave security loophole and we cannot do this. Kindly fix this issue in drools-5.4 and let us know an ETA for the patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
1
0 / 0

[JBoss JIRA] (AS7-4978) System properties are not expanded in jvm-options

by Enguerrand Dibanda (JIRA)

Enguerrand Dibanda created AS7-4978: --------------------------------------- Summary: System properties are not expanded in jvm-options Key: AS7-4978 URL: https://issues.jboss.org/browse/AS7-4978 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.2.Final (EAP) Reporter: Enguerrand Dibanda - System properties are not expanded when passed to the <jvm-options> tag of a domain mode jvm configuration. - Problem is still present in jboss-as-7.2.0.Alpha1-SNAPSHOT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
2
0 / 0

[JBoss JIRA] (AS7-4938) cli commands should show response headers if they are available in the results

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created AS7-4938: -------------------------------------- Summary: cli commands should show response headers if they are available in the results Key: AS7-4938 URL: https://issues.jboss.org/browse/AS7-4938 Project: Application Server 7 Issue Type: Task Components: CLI Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 Some of the commands translate into operations that may require, e.g., a server restart. This information comes in operation response headers that are not shown to the user, which is bad. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
1
0 / 0

[JBoss JIRA] (AS7-4906) CLI API: provide mechanism to read CLI output

by Dominik Pospisil (JIRA)

Dominik Pospisil created AS7-4906: ------------------------------------- Summary: CLI API: provide mechanism to read CLI output Key: AS7-4906 URL: https://issues.jboss.org/browse/AS7-4906 Project: Application Server 7 Issue Type: Feature Request Components: CLI Affects Versions: 7.2.0.Alpha1 Reporter: Dominik Pospisil Assignee: Alexey Loubyansky CLI provides Java API to connect to CLI and execute commands. However, it does not seem possible to read CLI output using this API. This limits API usability for testing purposes to non-verbose commands only. It would be nice if the API provies a way how to read console output. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
4
0 / 0

[JBoss JIRA] (AS7-4866) add support for value converters for operation property values

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created AS7-4866: -------------------------------------- Summary: add support for value converters for operation property values Key: AS7-4866 URL: https://issues.jboss.org/browse/AS7-4866 Project: Application Server 7 Issue Type: Task Components: CLI Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky At the moment, value converters (which is the base for the simplified dmr format) are supported only for command arguments but not operation requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
1
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 2012