[JBoss JIRA] (WFCORE-1915) ParseUtils.parseAttributeValue should not fail due to DMR type conversions
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1915:
----------------------------------------
Summary: ParseUtils.parseAttributeValue should not fail due to DMR type conversions
Key: WFCORE-1915
URL: https://issues.jboss.org/browse/WFCORE-1915
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha11
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha12
The task of ParseUtils.parseAttributeValue is to convert a string into a ModelNode. The type of the ModelNode is not particularly important, as later code will do type conversion. And, it is *not* the job of this method to do validation; there is other code that does that. So, the type conversion this method does should not be allowed to produce failures. Continuing to try the conversion is ok, although not required, but if a conversion can't succeed the pre-conversion ModelType.STRING node should be returned.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 1 month
[JBoss JIRA] (WFCORE-1198) CLI does not resolve multiple properties if one property is undefined
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1198?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1198:
-------------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1289316|https://bugzilla.redhat.com/show_bug.cgi?id=1289316] from POST to MODIFIED
> CLI does not resolve multiple properties if one property is undefined
> ---------------------------------------------------------------------
>
> Key: WFCORE-1198
> URL: https://issues.jboss.org/browse/WFCORE-1198
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.4.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 2.0.5.Final
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1289316 description:
> {noformat}
> Multiple property substitution is working with EAP 6.4.3+, however, if a variable amongst the multiple variables is empty or has no value, then the subsequent property in the CLI command is not substituted.
> For example :
> cat props.properties
> -----------------------------------------
> PROFILE-NAME=TestProfile
> SERVER-INSTANCE-NUMBER=TestInstance
> APP-VERSION=
> VAR=test
> -----------------------------------------
> cat test.cli :
> ---------------------------------------
> /host=master/server-config=${PROFILE-NAME}${APP-VERSION}${SERVER-INSTANCE-NUMBER}${VAR}:add(auto-start=true, group="${PROFILE-NAME}${APP-VERSION}-server-group")
> ---------------------------------------
> and if I execute "./jboss-cli.sh --connect --file=test.cli --properties=props.properties" then I have the following in the host.xml ":
> ----------
> ...
> <server name="TestProfile${SERVER-INSTANCE-NUMBER}test" group="TestProfile-server-group" auto-start="true"/>
> ...
> -----------
> Note APP-VERSION had no value, and so the subsequent SERVER-INSTANCE-NUMBER was not properly resolved
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 1 month
[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-7418:
-------------------------------------
Excellent, thanks! The web workers approach does look interesting. I assume an approach like that would benefit from having some kind of description on the resource indicating it may be a slow runtime resource.
> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7418
> URL: https://issues.jboss.org/browse/WFLY-7418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch, Web Console
> Reporter: James Perkins
> Assignee: James Perkins
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 1 month
[JBoss JIRA] (WFCORE-1892) Support rejection-style testing for capabilities-enabled subsystem in test framework
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1892?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-1892:
-----------------------------------
Description:
Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.
An example of this can be found in the singleton subsystem:
/subsystem=singleton:add(default=mypolicy)
/subsystem=singleton/singleton-policy=mypolicy:add(...)
So the test fails for the 1st parsed operation
{noformat}
{
"operation" => "add",
"address" => [("subsystem" => "singleton")],
"default" => "simple"
}
{noformat}
with
{noformat}
java.lang.AssertionError: WFLYCTL0369: Required capabilities are not available:
org.wildfly.clustering.singleton.policy.simple; There are no known registration points which can provide this capability.
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.jboss.as.model.test.ModelTestUtils.checkOutcome(ModelTestUtils.java:121)
at org.jboss.as.model.test.ModelTestUtils.checkFailedTransformedBootOperations(ModelTestUtils.java:509)
at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejections(SingletonTransformersTestCase.java:130)
at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejectionsEAP700(SingletonTransformersTestCase.java:105)
{noformat}
I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.
was:
Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.
An example of this can be found in the singleton subsystem:
/subsystem=singleton:add(default=mypolicy)
/subsystem=singleton/singleton-policy=mypolicy:add(...)
I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.
> Support rejection-style testing for capabilities-enabled subsystem in test framework
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1892
> URL: https://issues.jboss.org/browse/WFCORE-1892
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 3.0.0.Alpha10
> Reporter: Radoslav Husar
> Assignee: Kabir Khan
>
> Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.
> An example of this can be found in the singleton subsystem:
> /subsystem=singleton:add(default=mypolicy)
> /subsystem=singleton/singleton-policy=mypolicy:add(...)
> So the test fails for the 1st parsed operation
> {noformat}
> {
> "operation" => "add",
> "address" => [("subsystem" => "singleton")],
> "default" => "simple"
> }
> {noformat}
> with
> {noformat}
> java.lang.AssertionError: WFLYCTL0369: Required capabilities are not available:
> org.wildfly.clustering.singleton.policy.simple; There are no known registration points which can provide this capability.
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.jboss.as.model.test.ModelTestUtils.checkOutcome(ModelTestUtils.java:121)
> at org.jboss.as.model.test.ModelTestUtils.checkFailedTransformedBootOperations(ModelTestUtils.java:509)
> at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejections(SingletonTransformersTestCase.java:130)
> at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejectionsEAP700(SingletonTransformersTestCase.java:105)
> {noformat}
> I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 1 month
[JBoss JIRA] (WFLY-3549) Deadlock during shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3549?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3549:
-----------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1213817|https://bugzilla.redhat.com/show_bug.cgi?id=1213817] from POST to MODIFIED
> Deadlock during shutdown
> ------------------------
>
> Key: WFLY-3549
> URL: https://issues.jboss.org/browse/WFLY-3549
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: David Lloyd
> Fix For: 8.2.0.Final
>
>
> This deadlock appeared in an Arquillian test:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "undefined":
> waiting to lock monitor 0x00007f67a421bfa8 (object 0x00000000e0700480, a org.jboss.as.threads.ScheduledThreadPoolService),
> which is held by "MSC service thread 1-2"
> "MSC service thread 1-2":
> waiting for ownable synchronizer 0x00000000e0700618, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "undefined"
> Java stack information for the threads listed above:
> ===================================================
> "undefined":
> at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121)
> - waiting to lock <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService)
> at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:704)
> at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1006)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1163)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> "MSC service thread 1-2":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000e0700618> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:781)
> at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:695)
> at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1397)
> at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:759)
> at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53)
> at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67)
> - locked <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> Found 1 deadlock.
> {noformat}
> Looks like two MSC service threads exited and tried to terminate the thread pool at the same time. And because the MSC threads are not daemon threads, the entire JVM hangs and blocks the Arquillian test that was waiting for the container to shut down.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 1 month
[JBoss JIRA] (WFLY-7434) Improve undefined statistics-enabled attribute testing in infinispan subsystem for EAP 6.2
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-7434:
------------------------------------
Summary: Improve undefined statistics-enabled attribute testing in infinispan subsystem for EAP 6.2
Key: WFLY-7434
URL: https://issues.jboss.org/browse/WFLY-7434
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Priority: Minor
The test file clustering/infinispan/extension/src/test/resources/org/jboss/as/clustering/infinispan/subsystem/infinispan-transformer-reject.xml specifies {code}statistics-enabled="false"{code} for all caches and cache-containers thus the situation when its undefined is never tested.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 1 month
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Radoslav Husar reassigned WFCORE-1836:
--------------------------------------
Fix Version/s: 3.0.0.Alpha11
Assignee: Radoslav Husar (was: Brian Stansberry)
Resolution: Done
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Fix For: 3.0.0.Alpha11
>
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 1 month
[JBoss JIRA] (WFLY-7432) KeyStore requires set CredentialReference which is optional.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7432?page=com.atlassian.jira.plugin.... ]
Hynek Švábek reassigned WFLY-7432:
----------------------------------
Assignee: Peter Skopek (was: Darran Lofthouse)
> KeyStore requires set CredentialReference which is optional.
> ------------------------------------------------------------
>
> Key: WFLY-7432
> URL: https://issues.jboss.org/browse/WFLY-7432
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> In EAP7.1.0.DR7 keystore uses credentialReference with clear-text attribute for password instead of password attribute.
> But there is problem with credential reference element which is optional.
> *Scenario:*
> I want to create KeyStore with minimum required settings.
> But this CLI command */subsystem=elytron/key-store=keyStore:add(type=JKS)* ends with error
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.org.jboss.as.controller.security.CredentialReference"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.keyStore is missing [org.wildfly.security.credential-store-client.org.jboss.as.controller.security.CredentialReference]"]
> },
> "rolled-back" => true
> }
> Resource description says this
> {code}
> "credential-reference" => {
> "type" => OBJECT,
> "description" => "The reference to credential stored in CredentialStore under defined alias or clear text password.",
> "expressions-allowed" => false,
> "nillable" => true,
> "value-type" => {
> "store" => {
> "type" => STRING,
> "description" => "The name of the credential store holding the alias to credential.",
> "expressions-allowed" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "alias" => {
> "type" => STRING,
> "description" => "The alias which denotes stored secret or credential in the store.",
> "expressions-allowed" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "type" => {
> "type" => STRING,
> "description" => "The type of credential this reference is denoting.",
> "expressions-allowed" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "clear-text" => {
> "type" => STRING,
> "description" => "Secret specified using clear text. Check credential store way of supplying credential/secrets to services.",
> "expressions-allowed" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {code}
> *NOTE*
> EAP7.1.0.DR6 works fine with "password" attribute.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 1 month