[JBoss JIRA] (WFLY-1180) CLI: Embedded Arrays need to be updatable easily
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1180?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-1180:
----------------------------------------
This should use the server-side stuff [~ctomc] added to WF9 this summer.
> CLI: Embedded Arrays need to be updatable easily
> ------------------------------------------------
>
> Key: WFLY-1180
> URL: https://issues.jboss.org/browse/WFLY-1180
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jim Tyrrell
> Assignee: Alexey Loubyansky
> Labels: eap6-ux
>
> In the EAP 6 pilot we were presented a long string to create a Database Security Realm, it appears there is no way to update a single value. For example being able to change the string of the SQL of a principalsQuery or rolesQuery for example. Without having to put in the entire vale.
> /profile=default/subsystem=security/security-domain=DB_domain:add(authentication=[{"code" => "Database", "flag" => "required", "module-options"=>[("principalsQuery"=>"Select password from UsersTable.....
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFLY-3340) Authentication "module-options" inconsistently hash vs list of key/values
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3340?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3340:
----------------------------------------
Is this still an issue with latest master? I don't believe it is.
> Authentication "module-options" inconsistently hash vs list of key/values
> -------------------------------------------------------------------------
>
> Key: WFLY-3340
> URL: https://issues.jboss.org/browse/WFLY-3340
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: RHEL 6.4, x86_64
> Reporter: Chris Pitman
> Assignee: Alexey Loubyansky
> Labels: automation, cli, configuration_management
>
> When adding an authentication mechanism to a security domain it is possible to set the module-options with a hash (which is great!). However, as soon as a reload occurs they revert back into a list of key-value pairs. This only makes sense if order matters (which I hope it doesn't) or if keys can be repeated (again, hope not).
> Configuration management tools should only change a value when it needs to, and this is way easier if the value that is set is the same value that is read. Hashes are also far easier to work with in ruby/puppet/chef.
> Steps to reproduce:
> 1. Set the module_options on an already existing authentication mechanism:
> {code}
> /subsystem=security/security-domain=servlet-security-quickstart/authentication=classic:write-attribute(name=login-modules, value=[{"code" => "Database","flag"=>"required","module-options"=>{"dsJndiName" =>
> "java:jboss/datasources/ServletSecurityDS", "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?", "role
> sQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"}}])
> {code}
> 2. Read the resource (notice that module-options is till a nice easy to use hash!)
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "module-options" => {
> "dsJndiName" => "java:jboss/datasources/ServletSecurityDS",
> "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?",
> "rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"
> },
> "flag" => "required",
> "code" => "Database"
> }]},
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> 3. Reload, then read-resource
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "code" => "Database",
> "flag" => "required",
> "module-options" => [
> ("dsJndiName" => "java:jboss/datasources/ServletSecurityDS"),
> ("principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?"),
> ("rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?")
> ]
> }]}
> }
> {code}
> 4. module-options is now a list of key-value pairs, and is not equal to what it was set to before
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFLY-3340) Authentication "module-options" inconsistently hash vs list of key/values
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3340?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3340:
-----------------------------------
Component/s: Domain Management
Security
(was: CLI)
> Authentication "module-options" inconsistently hash vs list of key/values
> -------------------------------------------------------------------------
>
> Key: WFLY-3340
> URL: https://issues.jboss.org/browse/WFLY-3340
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: RHEL 6.4, x86_64
> Reporter: Chris Pitman
> Assignee: Alexey Loubyansky
> Labels: automation, cli, configuration_management
>
> When adding an authentication mechanism to a security domain it is possible to set the module-options with a hash (which is great!). However, as soon as a reload occurs they revert back into a list of key-value pairs. This only makes sense if order matters (which I hope it doesn't) or if keys can be repeated (again, hope not).
> Configuration management tools should only change a value when it needs to, and this is way easier if the value that is set is the same value that is read. Hashes are also far easier to work with in ruby/puppet/chef.
> Steps to reproduce:
> 1. Set the module_options on an already existing authentication mechanism:
> {code}
> /subsystem=security/security-domain=servlet-security-quickstart/authentication=classic:write-attribute(name=login-modules, value=[{"code" => "Database","flag"=>"required","module-options"=>{"dsJndiName" =>
> "java:jboss/datasources/ServletSecurityDS", "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?", "role
> sQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"}}])
> {code}
> 2. Read the resource (notice that module-options is till a nice easy to use hash!)
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "module-options" => {
> "dsJndiName" => "java:jboss/datasources/ServletSecurityDS",
> "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?",
> "rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"
> },
> "flag" => "required",
> "code" => "Database"
> }]},
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> 3. Reload, then read-resource
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "code" => "Database",
> "flag" => "required",
> "module-options" => [
> ("dsJndiName" => "java:jboss/datasources/ServletSecurityDS"),
> ("principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?"),
> ("rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?")
> ]
> }]}
> }
> {code}
> 4. module-options is now a list of key-value pairs, and is not equal to what it was set to before
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFLY-2765) Incremental redeployment (single file update) over management API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2765?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2765:
-----------------------------------
Component/s: Domain Management
> Incremental redeployment (single file update) over management API
> -----------------------------------------------------------------
>
> Key: WFLY-2765
> URL: https://issues.jboss.org/browse/WFLY-2765
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 8.0.0.CR1
> Reporter: Ondrej Zizka
> Labels: deploy, deployment, incremental, redeployment
> Fix For: 9.0.0.Beta1
>
>
> (Based on JBDS use case - see EAP6-1)
> See also https://mojo.redhat.com/docs/DOC-934058 for notes
> By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc.
> Use cases:
> Big .war's, mainly on remote
> Cloud deployments
> Also, you loose sessions etc.
> "JSP recompile on file update" - mgmt API operation - added in WildFly 8?
> Not expected to work in domain mode.
> Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFLY-3166) can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3166:
-----------------------------------
Component/s: JCA
(was: ConfigAdmin)
> can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-3166
> URL: https://issues.jboss.org/browse/WFLY-3166
> Project: WildFly
> Issue Type: Bug
> Components: CLI, JCA, Web Console
> Affects Versions: 8.0.0.Final
> Environment: Red Hat Enterprise Linux Server release 5.5
> Reporter: Fai Gao
> Assignee: Stefano Maestri
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but the lable of enabled didn't turn to √(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
> "rolled-back" => true
> }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1] ("subsystem" => "datasources"),
> [Server:fserver1] ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]
> I tried in the standalone mode,it worked.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-408) Add a TRACE level category for the operations used to start a server.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-408?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-2256 to WFCORE-408:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-408 (was: WFLY-2256)
Component/s: Domain Management
Logging
(was: Domain Management)
(was: Logging)
Fix Version/s: (was: Awaiting Volunteers)
> Add a TRACE level category for the operations used to start a server.
> ---------------------------------------------------------------------
>
> Key: WFCORE-408
> URL: https://issues.jboss.org/browse/WFCORE-408
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, Logging
> Reporter: Darran Lofthouse
>
> Sometimes after being able to start a server from the XML configuration it is useful to be able to identify the actual operations that are executed to start the server.
> From a development perspective this is useful for double checking the operations are as we expect.
> From an end user perspective this can be useful to identify the set of equivalent operations needed if the same was to be achieved in a CLI script.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-407) JBAS018040: Failed to start context
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-407?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-407:
-----------------------------------------
The 'enabled' attribute means the admin wants the server to attempt to install this deployment into the runtime. It doesn't indicate success or failure. A separate attribute would be needed to track the running state of the deployment.
> JBAS018040: Failed to start context
> -----------------------------------
>
> Key: WFCORE-407
> URL: https://issues.jboss.org/browse/WFCORE-407
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: Redhat Linux 4 (??). Kernel version is: 2.6.18-194.26.1.el5
> Reporter: B K
> Assignee: Heiko Braun
> Labels: jboss
>
> The error found in the server log files was:
> 13:58:40,009 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./apex: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./apex: JBAS018040: Failed to start context
> Occurence details:
> 1. The issue occured following a restart of the application server
> Analysis details:
> 1. From the perspective of the JBOSS 7 admin console ... the admin console shows that the "apex.war" application is deployed and "enabled". I believe it should not display "enabled" as the context has failed to start and it is NOT capable of servicing requests.
> Details to reproduce:
> 1. Download Oracle Apex Listener 1.1.4 from:
> http://www.oracle.com/technetwork/developer-tools/apex-listener/downloads...
> 2. Unzip the war file e.g jar xvf apex.war
> 3. Modify the web.xml by adding:
> <context-param>
> <param-name>config.dir</param-name>
> <param-value>/opt/jboss/apex_config_dir</param-value>
> </context-param>
> 4. Create the path "/opt/jboss/apex_config_dir".
> 5. Zip the war file.
> cd locationContaining the Web-INF directory
> jar cvf apex.war *
> 6. Deploy war file and enable via admin console. Stop Server. Start server.
> 7. Exception occurs.
> NOTE: there could be an additional step to reproduce. Will detail if above does not work.
> NOTE2: I can redeploy the above application and get it working again by removing some files that are auto generated by apex.war (so a partial bit of this issue is probably application related).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-407) JBAS018040: Failed to start context
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-407?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-780 to WFCORE-407:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-407 (was: WFLY-780)
Issue Type: Enhancement (was: Bug)
Component/s: Domain Management
(was: Domain Management)
Steps to Reproduce: (was: See description)
> JBAS018040: Failed to start context
> -----------------------------------
>
> Key: WFCORE-407
> URL: https://issues.jboss.org/browse/WFCORE-407
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: Redhat Linux 4 (??). Kernel version is: 2.6.18-194.26.1.el5
> Reporter: B K
> Assignee: Heiko Braun
> Labels: jboss
>
> The error found in the server log files was:
> 13:58:40,009 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./apex: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./apex: JBAS018040: Failed to start context
> Occurence details:
> 1. The issue occured following a restart of the application server
> Analysis details:
> 1. From the perspective of the JBOSS 7 admin console ... the admin console shows that the "apex.war" application is deployed and "enabled". I believe it should not display "enabled" as the context has failed to start and it is NOT capable of servicing requests.
> Details to reproduce:
> 1. Download Oracle Apex Listener 1.1.4 from:
> http://www.oracle.com/technetwork/developer-tools/apex-listener/downloads...
> 2. Unzip the war file e.g jar xvf apex.war
> 3. Modify the web.xml by adding:
> <context-param>
> <param-name>config.dir</param-name>
> <param-value>/opt/jboss/apex_config_dir</param-value>
> </context-param>
> 4. Create the path "/opt/jboss/apex_config_dir".
> 5. Zip the war file.
> cd locationContaining the Web-INF directory
> jar cvf apex.war *
> 6. Deploy war file and enable via admin console. Stop Server. Start server.
> 7. Exception occurs.
> NOTE: there could be an additional step to reproduce. Will detail if above does not work.
> NOTE2: I can redeploy the above application and get it working again by removing some files that are auto generated by apex.war (so a partial bit of this issue is probably application related).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-406) Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-406?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-53 to WFCORE-406:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-406 (was: WFLY-53)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.CR1
(was: 9.0.0.Beta1)
> Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-406
> URL: https://issues.jboss.org/browse/WFCORE-406
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: FreeBSD, OpenJDK 1.6
> Reporter: Brian Stansberry
> Priority: Minor
> Fix For: 1.0.0.CR1
>
>
> Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the description says it's not nillable.
> Specifically, PlatformMBeanDescriptions.getThreadingResource()'s THREAD_CPU_TIME_ENABLED attribute, although there may well be others.
> This leads to this unit test failure on jvms where the UOE is thrown:
> failure message="thread-cpu-time-enabled is undefined"
> type="junit.framework.AssertionFailedError">junit.fra mework.AssertionFailedError: thread-cpu-time-enabled is undefined
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.validateResource(PlatformMBeanResourceUn
> itTestCase.java:595)
> at org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.basicResourceTest(PlatformMBeanResourceUnitTestCase.java:563)
> at
> org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.testThreadingMXBean(PlatformMBeanResourceUnitTestCase.java:340)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months